演習 - Business Critical の高可用性

  • 10 分

この演習では、データベースを Business Critical レベルにアップグレードします。 読み取りレプリカとパフォーマンスの向上がどのようにして提供されるのかを確認します。

前の演習で使用した ostress ツールを使用して、ワークロードを作成します。 その後、Azure Cloud Shell で Azure PowerShell モジュールを使用してフェールオーバーを開始します。 最後に、フェールオーバーが ostress ワークロードに与える影響を確認します。

Azure SQL の Business Critical サービス レベルでの基本的な高可用性

この演習では、次の手順を行います。

  1. 前の演習のデータベースを Business Critical レベルにデプロイする。
  2. ostress ワークロードを実行する。
  3. PowerShell を使用してフェールオーバーを開始する。
  4. Ostress で結果を表示する。
  5. 読み取り可能なセカンダリに接続する。

同じデータベースを Business Critical レベルにデプロイする

前のモジュールでは、T-SQL を使用してデータベースをスケーリングする方法について学習しました。 この演習の目標は、前の演習で使用したデータベースを General Purpose から Business Critical にアップグレードすることです。 データベースをアップグレードするには、Azure Cloud Shell を使用します。 フェールオーバーの頻度には制限があるため、同じサンプル データベースを使用しますが、AdventureWorks-bc という名前にします。

  1. このページの右側にある Azure Cloud Shell ターミナルで、次の PowerShell スクリプトを実行して環境を構成します。

    $resourceGroup = "<rgn>[sandbox resource group name]</rgn>"
$database = "AdventureWorks-bc"
$server = Get-AzureRmSqlServer -ResourceGroupName $resourceGroup
$server = $server.ServerName

# Specify your default resource group and Azure SQL Database logical server
az configure --defaults group=$resourceGroup sql-server=$server

# Confirm the defaults are set
az configure --list-defaults

  2. 次のコマンドを実行して、Business Critical サービス レベルにデータベースを作成します。

    az sql db create --name $database `
--edition BusinessCritical `
--family Gen5 `
--capacity 2 `
--sample-name AdventureWorksLT `
--read-scale Enabled `
--zone-redundant false

    このコマンドは、完了するまでに時間がかかります。 実行中に、使用されているいくつかのパラメーターを確認できます。

    • family: このパラメーターでは、ハードウェアの世代を指定します。 前の演習との一貫性を保つために、Gen5 を使用しました。

    • capacity: このパラメーターでは、DTU または仮想コアの数を指定します。 前の演習との一貫性を保つために、2 仮想コアを使用しました。

    • sample-name: 前の演習との一貫性を保つために、AdventureWorksLT データベース サンプルを使用しました。

    • edition: このパラメーターの名前は少し紛らわしいものです。 実際にはサービス レベルのことであり、SQL Server で使用されているエディションとは異なります。

    • read-scale: このオプションは既定では有効になっていませんが、それに関連する追加コストはありません。 これを有効にすると、セカンダリ レプリカの 1 つを読み取り可能なセカンダリとして使用できるようになります。

    • zone-redundant: このパラメーターは、既定で false に設定されます。 追加コストなしで "マルチ AZ" デプロイを使用したい場合は、true に設定できます。 Availability Zones については、次のユニットで詳しく学習します。

      Note

      Availability Zones は、特定のリージョンでのみ使用できます。 現在、Azure SQL Managed Instance では使用できません。

  3. データベースが作成された後、Azure Cloud Shell の出力に、更新に関する詳細情報が表示されます。 2 つの主要なカテゴリが表示されます (ただし、他のいくつかのプロパティの下にインジケーターも表示されます)。

    • currentServiceObjectiveName: BC_Gen5_2 でなければなりません。 BC は Business Critical のことです。
    • currentSku:
      • name: BC_Gen5 でなければなりません。
      • tier: BusinessCritical でなければなりません。

  4. サービス レベルを確認するもう 1 つの方法は、Azure portal でお使いのデータベースに移動することです。 [概要] タブで、[価格レベル] を確認します。

    ヒント

    これらの更新を表示するには、他にも多くの方法があります。 もう 1 つの方法は、SSMS を使用することです。 データベースを右クリックして [プロパティ]>[SLO の構成] を選択することで、変更内容を表示できます。

ostress ワークロードを実行する

前の演習と同様に、Azure SQL データベースへのクエリを繰り返し実行するには、ostress を使用します。

  1. 前の演習で使用したコマンド プロンプトを閉じた場合は、ローカル コンピューターで新しいコマンド プロンプト ウィンドウを開きます。 cd を使用して、前にクローンまたはダウンロードしたリポジトリの、可用性モジュールが含まれるディレクトリに移動します。 たとえば、次のコマンドを使用できます。

    cd C:\Users\username\mslearn-azure-sql-fundamentals\05-Availability

    ostress ワークロードによって接続され、簡易クエリが 5 万回実行されます。

  2. 次の ostress スクリプトを使用して、ワークロードを実行します。 serverName を、ご利用の Azure SQL Database 論理サーバーの名前に置き換えます。 password を、ご利用のパスワードに置き換えます。 このコマンドは、前の演習とは少し異なります。 ここでは、データベース名は AdventureWorks-bc です。

    .\ostress.exe -S"serverName.database.windows.net" -Q"SELECT COUNT(*) FROM SalesLT.Customer" -U"cloudadmin" -d"AdventureWorks-bc" -P"password" -n1 -r50000

    ワークロードが正常に実行されている場合は、コマンド プロンプト ウィンドウに、クエリの結果 847 が繰り返し表示されます。

    完了する前に ostress ワークロードの実行を停止する場合は、ターミナルの Ctrl + C キーを押します。

    ワークロードを再度実行する場合は、そのコマンドをもう一度実行できます。

フェールオーバーを開始して結果を表示する

  1. このブラウザーとコマンド プロンプト ウィンドウを同時に表示できるように、ウィンドウを構成します。

  2. Azure Cloud Shell ターミナルで次のコードを実行します。 このコマンドは、前の演習で使用したものと同じです。

    # create a failover
Invoke-AzSqlDatabaseFailover -ResourceGroupName $resourceGroup `
    -ServerName $server `
    -DatabaseName $database

  3. このコマンドが実行されている間、ターミナルに表示されるすべての変更を確認する必要があります。 フェールオーバーが行われている間は、データベースにアクセスできないことがわかります。 この時間は非常に短いものです。 切断された後、約 5 秒後には再接続されるはずです。 このフェールオーバーは、General Purpose レベルのものより 6 倍以上高速です。

    Business Critical サービス レベルのデータベースまたはマネージド インスタンスには、基本的に Always On 可用性グループがバックグラウンドでデプロイされていることに注意してください。そのため、フェールオーバーすると、Azure によっていずれかのセカンダリにリダイレクトされるため、バックエンドのポインターが変更されます。 フェールオーバーが General Purpose よりはるかに高速なのはそのためです。

読み取り専用レプリカに接続する

read-scale パラメーターを有効にしたので、読み取り専用のワークロードにセカンダリ レプリカの 1 つを使用することができます。 アプリケーションで読み取り専用レプリカにアクセスするには、データベースの接続文字列に次のパラメーターを追加するだけです。

ApplicationIntent=ReadOnly;

  1. SSMS で、新しいクエリ接続を作成します。 ([ファイル]>[新規]>[データベース エンジン クエリ] を選択します。)

    クエリ接続の作成方法を示すスクリーンショット。

  2. [サーバーへの接続] ダイアログ ボックスで、Azure SQL Database 論理サーバーへの接続に使用していた構成を使用します。 (つまり、[SQL Server 認証] を使用します)。[オプション] を選択します。

    [サーバーへの接続] ダイアログ ボックスを示すスクリーンショット。

  3. [接続プロパティ] を選択してから、[すべてリセット] を選択します。 [データベースへの接続] で [サーバーの参照] を選択して、AdventureWorks-bc データベースを選択します。 [OK] を選択します。

  4. [追加の接続パラメーター] を選択し、以下をテキスト ボックスに貼り付けます。 [接続] を選択します。

    ApplicationIntent=ReadOnly;

    SSMS では、読み取り専用で接続するサーバーとデータベースを指定する必要があります。 これは、サーバーに読み取り可能なセカンダリに関して異なる機能を持つ複数のデータベースが存在する可能性があるためです。

  5. テストとして、新しいデータベース エンジン クエリに対して次のクエリを試します。 その結果を確認します。 想定したとおりのものですか。

    SELECT DATABASEPROPERTYEX(DB_NAME(), 'Updateability')

    読み取り専用の応答を示すスクリーンショット。

  6. 必要に応じて、追加の接続パラメーターを再接続して更新できます。 (ReadOnly を ReadWrite に置き換えます)。読み取り書き込みプライマリ レプリカにアクセスしていることを確認します。 ReadWrite が既定値であるため、何も選択しない場合は、次のようになります。

    読み取り書き込みの応答を示すスクリーンショット。