次の方法で共有

PowerShell または Az CLI を使用して Azure VM 上の SQL Server 用に単一サブネット可用性グループを構成する

  • [アーティクル]

適用対象: Azure VM 上の SQL Server

ヒント

可用性グループをデプロイする方法は多数あります。 デプロイを簡略化し、Always On 可用性グループに対して Azure Load Balancer または分散ネットワーク名 (DNN) を不要にするには、同じ Azure 仮想ネットワーク内の複数のサブネットに SQL Server 仮想マシン (VM) を作成します。 可用性グループを 1 つのサブネットに既に作成している場合は、マルチサブネット環境に移行できます。

この記事では、PowerShell または Azure CLI を使用して、Windows フェールオーバー クラスターをデプロイし、クラスターに SQL Server VM を追加し、1 つのサブネット内の Always On 可用性グループに対して内部ロード バランサーとリスナーを作成する方法について説明します。

可用性グループのデプロイは、引き続き SQL Server Management Studio (SSMS) または Transact-SQL (T-SQL) を使用して手動で実行されます。

この記事では PowerShell と Az CLI を使用して可用性グループ環境を構成しますが、 Azure portalから Azure クイックスタート テンプレートを使用して構成するか、手動で構成することもできます。

Note

これで Azure Migrate を使用して、可用性グループ ソリューションを Azure VM 上の SQL Server にリフト アンド シフトできるようになりました。 詳細については、可用性グループの移行に関するページを参照してください。

前提条件

Always On 可用性グループを構成するには、次の前提条件を満たしている必要があります。

  • Azure サブスクリプション。
  • ドメイン コントローラーを含むリソース グループ。
  • SQL IaaS Agent 拡張機能に登録されているのと "同じ" 可用性セットまたは "異なる" 可用性ゾーンにある、1 つ以上のドメイン参加済みの、SQL Server 2016 (またはそれ以降の) Enterprise エディションを実行している Azure の VM。
  • 最新バージョンの PowerShell または Azure CLI。
  • 2 つの使用可能な (どのエンティティでも使用されていない) IP アドレス。 1 つは内部ロード バランサー用です。 もう 1 つは、可用性グループと同じサブネット内の可用性グループ リスナー用です。 既存のロード バランサーを使用している場合は、使用可能な IP アドレスが可用性グループ リスナー用に 1 つだけ必要です。
  • Windows Server Core は、この記事で言及されている PowerShell コマンドでサポートされているオペレーティング システムではありません。RSAT には依存関係があり、Windows の Core インストールには含まれていないためです。

アクセス許可

Azure CLI を使用して Always On 可用性グループを構成するには、次のアカウントのアクセス許可が必要です。

  • ドメインでコンピューター オブジェクトを作成するためのアクセス許可を持っている既存のドメイン ユーザー アカウント。 たとえばドメイン管理者アカウントは、一般に十分なアクセス許可を持っています (例: account@domain.com)。 クラスターを作成するには、このアカウントが、各 VM でローカル管理者グループに含まれている必要もあります。
  • SQL Server を制御するドメイン ユーザー アカウント。

ストレージ アカウントの作成

クラスターには、クラウド監視として機能するストレージ アカウントが必要です。 いずれかの既存のストレージ アカウントを使用するか、または新しいストレージ アカウントを作成できます。 既存のストレージ アカウントを使用する場合は、次のセクションに進んでください。

次のコード スニペットは、ストレージ アカウントを作成します。

# Create the storage account
# example: az storage account create -n 'cloudwitness' -g SQLVM-RG -l 'West US' `
#  --sku Standard_LRS --kind StorageV2 --access-tier Hot --https-only true

az storage account create -n <name> -g <resource group name> -l <region> `
  --sku Standard_LRS --kind StorageV2 --access-tier Hot --https-only true

ヒント

古いバージョンの Azure CLI を使用している場合は、エラー az sql: 'vm' is not in the 'az sql' command group が表示されることがあります。 このエラーを回避するには、最新バージョンの Azure CLI をダウンロードしてください。

クラスター メタデータを定義する

Azure CLI の az sql vm group コマンド グループは、可用性グループをホストする Windows Server フェールオーバー クラスター (WSFC) サービスのメタデータを管理するものです。 クラスター メタデータには、Active Directory ドメイン、クラスター アカウント、クラウド監視として使用されるストレージ アカウント、および SQL Server バージョンが含まれています。 az sql vm group create を使用して WSFC のメタデータを定義し、最初の SQL Server VM が追加されたら、定義のとおりにクラスターが作成されるようにします。

次のコード スニペットは、クラスターのメタデータを定義します。

# Define the cluster metadata
# example: az sql vm group create -n Cluster -l 'West US' -g SQLVM-RG `
#  --image-offer SQL2017-WS2016 --image-sku Enterprise --domain-fqdn domain.com `
#  --operator-acc vmadmin@domain.com --bootstrap-acc vmadmin@domain.com --service-acc sqlservice@domain.com `
#  --sa-key '4Z4/i1Dn8/bpbseyWX' `
#  --storage-account 'https://cloudwitness.blob.core.windows.net/'
#  --cluster-subnet-type 'SingleSubnet'

az sql vm group create -n <cluster name> -l <region ex:eastus> -g <resource group name> `
  --image-offer <SQL2016-WS2016 or SQL2017-WS2016> --image-sku Enterprise --domain-fqdn <FQDN ex: domain.com> `
  --operator-acc <domain account ex: testop@domain.com> --bootstrap-acc <domain account ex:bootacc@domain.com> `
  --service-acc <service account ex: testservice@domain.com> `
  --sa-key '<PublicKey>' `
  --storage-account '<ex:https://cloudwitness.blob.core.windows.net/>'
  --cluster-subnet-type 'SingleSubnet'

クラスターに VM を追加する

クラスターに最初の SQL Server VM を追加すると、クラスターが作成されます。 az sql vm add-to-group コマンドは、前に指定された名前でクラスターを作成し、SQL Server VM にクラスター ロールをインストールした後、それらの VM をクラスターに追加します。 その後に az sql vm add-to-group コマンドを使用すると、新しく作成されたクラスターに SQL Server VM が追加されます。

次のコード スニペットはクラスターを作成し、そこに最初の SQL Server VM を追加します。

# Add SQL Server VMs to cluster
# example: az sql vm add-to-group -n SQLVM1 -g SQLVM-RG --sqlvm-group Cluster `
#  -b Str0ngAzur3P@ssword! -p Str0ngAzur3P@ssword! -s Str0ngAzur3P@ssword!
# example: az sql vm add-to-group -n SQLVM2 -g SQLVM-RG --sqlvm-group Cluster `
#  -b Str0ngAzur3P@ssword! -p Str0ngAzur3P@ssword! -s Str0ngAzur3P@ssword!

az sql vm add-to-group -n <VM1 Name> -g <Resource Group Name> --sqlvm-group <cluster name> `
  -b <bootstrap account password> -p <operator account password> -s <service account password>
az sql vm add-to-group -n <VM2 Name> -g <Resource Group Name> --sqlvm-group <cluster name> `
  -b <bootstrap account password> -p <operator account password> -s <service account password>

クラスターに他の SQL Server VM を追加するには、このコマンドを使用します。 SQL Server VM 名の -n パラメーターのみを変更してください。

クォーラムを構成する

ディスク監視は最も回復性の高いクォーラム オプションですが、Azure 共有ディスクが必要で、可用性グループに制限がいくつか適用されます。 そのため、クラウド監視は、Azure VM 上で SQL Server 向け可用性グループをホストするクラスターに推奨されるクォーラム ソリューションです。

クラスターに多数の投票がある場合は、ビジネス ニーズに最適なクォーラム ソリューションを構成します。 詳細については、SQL Server VM でのクォーラムに関する記事をご覧ください。

クラスターを検証する

Microsoft によってフェールオーバー クラスターがサポートされるためには、クラスター検証に合格する必要があります。 任意の方法 (リモート デスクトップ プロトコル (RDP) など) を使用して VM に接続し、先に進む前に、クラスターが検証に合格していることを確認します。 これに失敗すると、クラスターはサポートされていない状態のままになります。

フェールオーバー クラスター マネージャー (FCM) または次の PowerShell コマンドを使用して、クラスターを検証できます。

Test-Cluster –Node ("<node1>","<node2>") –Include "Inventory", "Network", "System Configuration"

可用性グループを作成する

SQL Server Management Studio、PowerShell、Transact-SQL のいずれかを使用して、通常どおりに可用性グループを手動で作成します。

重要

この時点では、リスナーを作成 "しないでください"。これは、以降のセクションで Azure CLI を使用して行います。

内部ロード バランサーを作成する

Note

複数のサブネットに可用性グループをデプロイする場合、ロード バランサーは必要ありません。 単一サブネット環境の場合、Windows 2016 以降で SQL Server 2019 CU8 以降をお使いのお客様は、従来の仮想ネットワーク名 (VNN) リスナーと Azure Load Balancer を分散ネットワーク名 (DNN) リスナーに置き換えることができます。 DNN を使用したい場合は、可用性グループ用に Azure Load Balancer を構成するチュートリアル手順をスキップしてください。

Always On 可用性グループ リスナーには、Azure Load Balancer の内部インスタンスが必要です。 内部ロード バランサーでは、より高速なフェールオーバーと再接続を可能にする可用性グループ リスナー用の "フローティング" IP アドレスが提供されます。 可用性グループ内の SQL Server VM が同じ可用性セットの一部である場合は、Basic ロード バランサーを使用できます。 それ以外の場合は、Standard ロード バランサーを使用する必要があります。

Note

内部ロード バランサーは、SQL Server VM インスタンスと同じ仮想ネットワークに存在する必要があります。

次のコード スニペットは、内部ロード バランサーを作成するものです。

# Create the internal load balancer
# example: az network lb create --name sqlILB -g SQLVM-RG --sku Standard `
# --vnet-name SQLVMvNet --subnet default

az network lb create --name sqlILB -g <resource group name> --sku Standard `
  --vnet-name <VNet Name> --subnet <subnet name>

重要

各 SQL Server VM 用のパブリック IP リソースには、Standard Load Balancer と互換性のある Standard SKU が必要です。 VM のパブリック IP リソースの SKU を決定するには、 [リソース グループ] に移動し、目的の SQL Server VM 用の [パブリック IP アドレス] リソースを選択して、 [概要] ウィンドウの [SKU] で値を見つけます。

リスナーを作成する

可用性グループを手動で作成したら、az sql vm ag-listener を使用してリスナーを作成できます。

"サブネット リソース ID" は、仮想ネットワーク リソースのリソース ID に追加された /subnets/<subnetname> の値です。 サブネット リソース ID を識別するには、次の操作を行います。

  1. Azure portal で、ご利用のリソース グループに移動します。
  2. 仮想ネットワーク リソースを選択します。
  3. [設定] ウィンドウで [プロパティ] を選択します。
  4. 仮想ネットワークのリソース ID を特定し、その最後に /subnets/<subnetname> を追加してサブネット リソース ID を作成します。 例:
    • 仮想ネットワークのリソース ID は /subscriptions/a1a1-1a11a/resourceGroups/SQLVM-RG/providers/Microsoft.Network/virtualNetworks/SQLVMvNet です。
    • サブネット名は default です。
    • そのため、サブネット リソース ID は /subscriptions/a1a1-1a11a/resourceGroups/SQLVM-RG/providers/Microsoft.Network/virtualNetworks/SQLVMvNet/subnets/default です。

次のコード スニペットは、可用性グループ リスナーを作成するものです。

# Create the availability group listener
# example: az sql vm group ag-listener create -n AGListener -g SQLVM-RG `
#  --ag-name SQLAG --group-name Cluster --ip-address 10.0.0.27 `
#  --load-balancer sqlilb --probe-port 59999  `
#  --subnet /subscriptions/a1a1-1a11a/resourceGroups/SQLVM-RG/providers/Microsoft.Network/virtualNetworks/SQLVMvNet/subnets/default `
#  --sqlvms sqlvm1 sqlvm2

az sql vm group ag-listener create -n <listener name> -g <resource group name> `
  --ag-name <availability group name> --group-name <cluster name> --ip-address <ag listener IP address> `
  --load-balancer <lbname> --probe-port <Load Balancer probe port, default 59999>  `
  --subnet <subnet resource id> `
  --sqlvms <names of SQL VM's hosting AG replicas, ex: sqlvm1 sqlvm2>

レプリカの数を変更する

Azure でホストされている SQL Server VM に可用性グループをデプロイすると複雑さが増します。 リソースは、リソースプロバイダーおよび仮想マシン グループによって管理されるようになります。 このため、可用性グループにレプリカを追加したり、可用性グループからレプリカを削除したりする場合は、SQL Server VM に関する情報でリスナー メタデータを更新する手順が別途発生します。 可用性グループ内のレプリカの数を変更する場合は、az sql vm group ag-listener update コマンドを使用して、SQL Server VM のメタデータでリスナーを更新する必要もあります。

レプリカを追加する

可用性グループに新しいレプリカを追加するには、次の操作を行います。

Azure CLI

  1. クラスター グループに SQL Server VM を追加します。

    
# Add the SQL Server VM to the cluster group
# example: az sql vm add-to-group -n SQLVM3 -g SQLVM-RG --sqlvm-group Cluster `
# -b Str0ngAzur3P@ssword! -p Str0ngAzur3P@ssword! -s Str0ngAzur3P@ssword!

az sql vm add-to-group -n <VM3 Name> -g <Resource Group Name> --sqlvm-group <cluster name> `
-b <bootstrap account password> -p <operator account password> -s <service account password>

  2. SQL Server Management Studio を使用して、SQL Server インスタンスを可用性グループ内のレプリカとして追加します。

  3. リスナーに SQL Server VM メタデータを追加します。

    # Update the listener metadata with the new VM
# example: az sql vm group ag-listener update -n AGListener `
# -g sqlvm-rg --group-name Cluster --sqlvms sqlvm1 sqlvm2 sqlvm3

az sql vm group ag-listener update -n <Listener> `
-g <RG name> --group-name <cluster name> --sqlvms <SQL VMs, along with new SQL VM>

レプリカの削除

可用性グループからレプリカを削除するには、次の操作を行います。

Azure CLI

  1. SQL Server Management Studio を使用して、可用性グループからレプリカを削除します。
  2. リスナーから SQL Server VM メタデータを削除します。
    # Update the listener metadata by removing the VM from the SQLVMs list
# example: az sql vm group ag-listener update -n AGListener `
# -g sqlvm-rg --group-name Cluster --sqlvms sqlvm1 sqlvm2

az sql vm group ag-listener update -n <Listener> `
-g <RG name> --group-name <cluster name> --sqlvms <SQL VMs that remain>
  3. クラスターから SQL Server VM を削除します。
    # Remove the SQL VM from the cluster
# example: az sql vm remove-from-group --name SQLVM3 --resource-group SQLVM-RG

az sql vm remove-from-group --name <SQL VM name> --resource-group <RG name>

リスナーを削除する

Azure CLI で構成された可用性グループ リスナーを後で削除する必要が生じた場合は、SQL IaaS Agent 拡張機能を使用する必要があります。 リスナーは SQL IaaS Agent 拡張機能を介して登録されるため、SQL Server Management Studio を使用して削除するだけでは十分ではありません。

最適な方法は、Azure CLI で次のコード スニペットを使用して、SQL IaaS Agent 拡張機能を通じて削除することです。 このようにすることで、SQL IaaS Agent 拡張機能から可用性グループ リスナー メタデータが削除されます。 また、可用性グループから物理的にリスナーが削除されます。

# Remove the availability group listener
# example: az sql vm group ag-listener delete --group-name Cluster --name AGListener --resource-group SQLVM-RG

az sql vm group ag-listener delete --group-name <cluster name> --name <listener name > --resource-group <resource group name>

クラスターの削除

クラスターからすべてのノードを削除して破棄し、SQL IaaS Agent 拡張機能からクラスター メタデータを削除します。 これは Azure CLI か PowerShell を使用して実行できます。

まず、クラスターからすべての SQL Server VM を削除します。

# Remove the VM from the cluster metadata
# example: az sql vm remove-from-group --name SQLVM2 --resource-group SQLVM-RG

az sql vm remove-from-group --name <VM1 name>  --resource-group <resource group name>
az sql vm remove-from-group --name <VM2 name>  --resource-group <resource group name>

これら以外にクラスターには VM がない場合、そのクラスターは破棄されます。 削除された SQL Server VM とは別に、クラスター内に他の VM がある場合、その他の VM は削除されず、クラスターは破棄されません。

次に、SQL IaaS Agent 拡張機能からクラスターのメタデータを削除します。

# Remove the cluster from the SQL VM RP metadata
# example: az sql vm group delete --name Cluster --resource-group SQLVM-RG

az sql vm group delete --name <cluster name> Cluster --resource-group <resource group name>

次のステップ

可用性グループがデプロイされたら、Azure VM 上の SQL Server に対する HADR 設定を最適化することを検討します。

詳細については、以下をご覧ください。