Azure クイックスタート テンプレートを使用して Azure VM に SQL Server の可用性グループを構成する
ヒント
可用性グループをデプロイする方法は多数あります。 デプロイを簡略化し、Always On 可用性グループに対して Azure Load Balancer または分散ネットワーク名 (DNN) を不要にするには、同じ Azure 仮想ネットワーク内の複数のサブネットに SQL Server 仮想マシン (VM) を作成します。 可用性グループを 1 つのサブネットに既に作成している場合は、マルチサブネット環境に移行できます。
この記事では、Azure において、1 つのサブネット内の SQL Server 仮想マシン (VM) で、Azure クイックスタート テンプレートを使用して、Always On 可用性グループのデプロイの構成を一部自動化する方法について説明します。 このプロセスでは、2 つの Azure クイックスタート テンプレートが使用されます。
| Template | 説明 |
|---|---|
| sql-vm-ag-setup | Windows フェールオーバー クラスターを作成し、それに SQL Server VM を参加させます。 |
| sql-vm-aglistener-setup | 可用性グループ リスナーを作成し、内部ロード バランサーを構成します。 このテンプレートは、Windows フェールオーバー クラスターが 101-sql-vm-ag-setup テンプレートを使用して作成された場合にのみ使用できます。 |
可用性グループの作成や、内部ロード バランサーの作成など、可用性グループ構成の他の部分は手動で行う必要があります。 この記事では、一連の自動および手動の手順を示します。
この記事では Azure クイックスタート テンプレートを使用して可用性グループ環境を構成しますが、Azure portal を使用して構成するか、PowerShell または Azure CLI を使用して構成するか、手動で構成することもできます。
Note
これで Azure Migrate を使用して、可用性グループ ソリューションを Azure VM 上の SQL Server にリフト アンド シフトできるようになりました。 詳細については、可用性グループの移行に関するページを参照してください。
前提条件
クイック スタート テンプレートを使用して Always On 可用性グループのセットアップを自動化するには、次の前提条件が必要です。
- Azure サブスクリプション。
- ドメイン コントローラーを含むリソース グループ。
- SQL IaaS Agent 拡張機能に登録されているのと同じ可用性セットまたは可用性ゾーンにある、1 つ以上のドメイン参加済みの、SQL Server 2016 (またはそれ以降の) Enterprise エディションを実行する Azure の VM。
- 内部 Azure Load Balancer と、SQL Server VM と同じサブネット内の可用性グループ リスナー用の使用可能な (どのエンティティにも使用されていない) IP アドレス。
アクセス許可
Azure クイックスタート テンプレートを使用して Always On 可用性グループを構成するには、次のアクセス許可が必要です。
- ドメインでコンピューター オブジェクトを作成するためのアクセス許可を持っている既存のドメイン ユーザー アカウント。 たとえばドメイン管理者アカウントは、一般に十分なアクセス許可を持っています (例: account@domain.com)。 クラスターを作成するには、このアカウントが、各 VM でローカル管理者グループに含まれている必要もあります。
- SQL Server を制御するドメイン ユーザー アカウント。
クラスターの作成
SQL Server VM が SQL IaaS Agent 拡張機能に登録されたら、SQL Server VM を SqlVirtualMachineGroups に参加させることができます。 このリソースでは、Windows フェールオーバー クラスターのメタデータが定義されています。 メタデータには、バージョン、エディション、完全修飾ドメイン名、クラスターと SQL Server の両方を管理する Active Directory アカウント、クラウド監視としてのストレージ アカウントが含まれます。
SQL Server VM を SqlVirtualMachineGroups リソース グループに追加することで、Windows フェールオーバー クラスター サービスをブートストラップし、クラスターを作成します。次にそのクラスターに、それらの SQL Server VM を参加させます。 この手順は、101-sql-vm-ag-setup クイックスタート テンプレートで自動化されます。 以下の手順を使用して実装することができます。
sql-vm-ag-setup クイックスタート テンプレートに移動します。 次に、 [Azure に配置する] を選択して、Azure portal でクイックスタート テンプレートを開きます。
必須フィールドに入力し、Windows フェールオーバー クラスターのメタデータを構成します。 省略可能なフィールドは空白のままでかまいません。
次の表では、テンプレートに必要な値を示します。
フィールド 値 サブスクリプション SQL Server VM が存在するサブスクリプション。 リソース グループ SQL Server VM が属するリソース グループ。 フェールオーバー クラスター名 新しい Windows フェールオーバー クラスターに付ける名前。 既存の VM のリスト 可用性グループに参加させて、この新しいクラスターの一部にする SQL Server VM。 これらの値はコンマとスペースで区切ります (例: SQLVM1, SQLVM2)。 SQL Server のバージョン SQL Server VM の SQL Server のバージョン。 ドロップダウン リストから選択します。 現時点では、SQL Server 2016 と SQL Server 2017 のイメージのみがサポートされています。 既存の完全修飾ドメイン名 SQL Server VM が属するドメインの既存の FQDN。 既存のドメイン アカウント テンプレートのデプロイ時に CNO が作成されるので、ドメインでのコンピューター オブジェクト作成アクセス許可を持っている既存のドメイン ユーザー アカウント。 たとえばドメイン管理者アカウントは、一般に十分なアクセス許可を持っています (例: account@domain.com)。 クラスターを作成するには、このアカウントが、各 VM でローカル管理者グループに含まれている必要もあります。 ドメイン アカウントのパスワード 前述のドメイン ユーザー アカウントのパスワード。 既存の SQL サービス アカウント 可用性グループのデプロイ時に SQL Server サービスを制御するドメイン ユーザー アカウント (例: account@domain.com)。 SQL サービス パスワード SQL Server を制御するドメイン ユーザー アカウントで使用されるパスワード。 クラウド監視の名前 クラウド監視のために作成され、使用される新しい Azure ストレージ アカウント。 この名前は変更できます。 _artifacts の場所 このフィールドは既定で設定されます。変更はしないでください。 SaS トークンとしての _artifacts の場所 このフィールドは、意図的に空白のままにされています。 使用条件に同意する場合は、 [上記の使用条件に同意する] チェック ボックスをオンにします。 次に、 [購入] を選択して、クイックスタート テンプレートのデプロイを完了します。
デプロイを監視するには、上部のナビゲーション バナーの [通知] ベル アイコンからデプロイを選択するか、Azure portal で [リソース グループ] に移動します。 [設定] の [デプロイ] を選択し、Microsoft.Template のデプロイを選択します。
Note
テンプレートのデプロイ中に指定された資格情報は、デプロイの期間中のみ保存されます。 デプロイが完了した後、これらのパスワードは削除されます。 クラスターに SQL Server VM をさらに追加する場合、それらを再度指定するように求められます。
クォーラムを構成する
ディスク監視は最も回復性の高いクォーラム オプションですが、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 のいずれかを使用して、通常どおりに可用性グループを手動で作成します。
重要
手順 4 で 101-sql-vm-aglistener-setup クイックスタート テンプレートによって自動的にそれが行われるため、この時点ではリスナーを "作成しない" でください。
ロード バランサーの作成
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 ロード バランサーを使用する必要があります。
重要
内部ロード バランサーは、SQL Server VM インスタンスと同じ仮想ネットワークに存在する必要があります。
内部ロード バランサーを作成することだけが必要です。 手順 4 では、101-sql-vm-aglistener-setup クイックスタート テンプレートによって、構成の残りの部分 (バックエンド プール、正常性プローブ、負荷分散規則など) が処理されます。
Azure ポータルで、SQL Server の仮想マシンを含んだリソース グループを開きます。
リソース グループで、 [追加] を選択します。
" ロード バランサー" を検索します。 検索結果で、Microsoft によって公開されているロード バランサーを選択します。
[Load Balancer] ペインで、[作成] を選択します。
[ロード バランサーの作成] ダイアログボックスで、次のようにロード バランサーを構成します。
設定 値 名前 ロード バランサーを表すテキスト名を入力します。 たとえば、「sqlLB」などと入力します。 Type 内部:ほとんどの実装では、内部ロード バランサーを使います。この場合、同じ仮想ネットワーク内のアプリケーションを可用性グループに接続できます。
外部: アプリケーションがパブリック インターネット接続経由で可用性グループに接続できます。Virtual Network SQL Server インスタンスが存在する仮想ネットワークを選択します。 サブネット SQL Server インスタンスが存在するサブネットを選択します。 IP アドレスの割り当て 静的 プライベート IP アドレス サブネット内の利用可能な IP アドレスを指定します。 サブスクリプション 複数のサブスクリプションを所有している場合、このフィールドが表示されます。 このリソースに関連付けられているサブスクリプションを選択します。 通常は、可用性グループのすべてのリソースについて同じサブスクリプションを選択してください。 リソース グループ SQL Server インスタンスが存在するリソース グループを選択します。 場所 Azure において SQL Server インスタンスが存在する場所を選択します。 ［作成］ を選択します
重要
各 SQL Server VM 用のパブリック IP リソースには、Standard Load Balancer と互換性のある Standard SKU が必要です。 VM のパブリック IP リソースの SKU を決定するには、 [リソース グループ] に移動し、SQL Server VM 用の [パブリック IP アドレス] リソースを選択し、 [概要] ウィンドウの [SKU] で値を見つけます。
リスナーを作成する
101-sql-vm-aglistener-setup クイックスタート テンプレートを使用して、自動的に可用性グループ リスナーを作成し、内部ロード バランサーを構成します。 テンプレートでは、Microsoft.SqlVirtualMachine/SqlVirtualMachineGroups/AvailabilityGroupListener リソースがプロビジョニングされます。 101-sql-vm-aglistener-setup クイック スタート テンプレートでは、SQL IaaS Agent 拡張機能を介して、以下の操作を行います。
- リスナーのために (デプロイ時に指定された IP アドレスの値に基づく) 新しいフロント エンド IP リソースを作成します。
- クラスターと内部ロード バランサーのネットワーク設定を構成します。
- 内部ロード バランサー、正常性プローブ、および負荷分散規則用のバックエンド プールを構成します。
- 特定の IP アドレスと名前を使用して、可用性グループ リスナーを作成します。
Note
101-sql-vm-aglistener-setup は、Windows フェールオーバー クラスターが 101-sql-vm-ag-setup テンプレートを使用して作成された場合にのみ使用できます。
内部ロード バランサーを構成して可用性グループ リスナーを作成するには、次のようにします。
sql-vm-aglistener-setup クイックスタート テンプレートに移動し、 [Azure に配置する] を選択して、Azure portal でクイックスタート テンプレートを開始します。
必須フィールドに入力して内部ロード バランサーを構成し、可用性グループ リスナーを作成します。 省略可能なフィールドは空白のままでかまいません。
次の表では、テンプレートに必要な値を示します。
フィールド 値 リソース グループ SQL Server VM と可用性グループが存在する、リソース グループ。 既存のフェールオーバー クラスター名 SQL Server VM が参加しているクラスターの名前。 既存の SQL 可用性グループ SQL Server VM が属する可用性グループの名前。 既存の VM のリスト 前述の可用性グループに属する SQL Server VM の名前。 名前はコンマとスペースで区切ります (例: SQLVM1, SQLVM2)。 リスナー リスナーに割り当てたい DNS 名。 既定では、このテンプレートによって "aglistener" という名前が指定されますが、それは変更できます。 名前は 15 文字以下にしてください。 リスナー ポート リスナーで使用するポート。 通常、このポートは既定値の 1433 にする必要があります。 これは、テンプレートで指定されているポート番号です。 ただし、既定のポートが変更されている場合は、リスナー ポートで代わりにその値を使用する必要があります。 リスナー IP リスナーで使用する IP アドレス。 このアドレスは、テンプレートのデプロイ中に作成されるので、未使用のものを指定します。 既存のサブネット SQL Server VM の内部サブネットの名前 (例: default)。 この値は、 [リソース グループ] に移動し、お使いの仮想ネットワークを選択し、 [設定] ウィンドウで [サブネット] を選択して、 [名前] の値をコピーすることにより、決定できます。 既存の内部ロード バランサー 手順 3 で作成した内部ロード バランサーの名前。 プローブ ポート 内部ロード バランサーで使用するプローブ ポート。 テンプレートでは既定で 59999 が使用されますが、この値は変更できます。 使用条件に同意する場合は、 [上記の使用条件に同意する] チェック ボックスをオンにします。 [購入] を選択して、クイックスタート テンプレートのデプロイを完了します。
デプロイを監視するには、上部のナビゲーション バナーの [通知] ベル アイコンからデプロイを選択するか、Azure portal で [リソース グループ] に移動します。 [設定] の [デプロイ] を選択し、Microsoft.Template のデプロイを選択します。
Note
デプロイが途中で失敗した場合は、101-sql-vm-aglistener-setup クイックスタート テンプレートを再デプロイする前に、PowerShell を使用して、手動で新たに作成されたリスナーを削除する必要があります。
リスナーを削除する
テンプレートで構成された可用性グループ リスナーを後で削除する必要がある場合は、SQL IaaS Agent 拡張機能を経由する必要があります。 リスナーは SQL IaaS Agent 拡張機能を介して登録されるため、SQL Server Management Studio を使用して削除するだけでは十分ではありません。
最適な方法は、PowerShell で次のコード スニペットを使用して、SQL IaaS Agent 拡張機能を通じて削除することです。 このようにすることで、SQL IaaS Agent 拡張機能から可用性グループ リスナー メタデータが削除されます。 また、可用性グループから物理的にリスナーが削除されます。
# Remove the availability group listener
# example: Remove-AzResource -ResourceId '/subscriptions/a1a11a11-1a1a-aa11-aa11-1aa1a11aa11a/resourceGroups/SQLAG-RG/providers/Microsoft.SqlVirtualMachine/SqlVirtualMachineGroups/Cluster/availabilitygrouplisteners/aglistener' -Force
Remove-AzResource -ResourceId '/subscriptions/<SubscriptionID>/resourceGroups/<resource-group-name>/providers/Microsoft.SqlVirtualMachine/SqlVirtualMachineGroups/<cluster-name>/availabilitygrouplisteners/<listener-name>' -Force
一般的なエラー
このセクションでは、いくつかの既知の問題とその考えられる解決策について説明します。
可用性グループ '<AG 名>' の可用性グループ リスナーは既に存在します。Azure クイックスタート テンプレートで可用性グループ リスナー用に選択されている可用性グループには、既にリスナーが含まれています。 それは可用性グループ内に物理的に存在するか、またはそのメタデータが SQL IaaS Agent 拡張機能内に残っています。 101-sql-vm-aglistener-setup クイック スタート テンプレートを再デプロイする前に、PowerShell を使用してリスナーを削除します。
プライマリ レプリカからの接続のみが機能する101-sql-vm-aglistener-setup テンプレートのデプロイに失敗し、内部ロード バランサーの構成が不整合な状態のままになっている場合、このような動作になる可能性があります。 バックエンド プールで可用性セットがリストされ、正常性プローブの規則と負荷分散規則が存在することを確認します。 何か足りないものがある場合、内部ロード バランサーの構成は不整合状態になります。
この動作を解決するには、PowerShell を使用してリスナーを削除し、Azure portal で内部ロード バランサーを削除した後、再び手順 3 から始めます。
BadRequest - SQL 仮想マシン リストしか更新できない このエラーは、SQL Server Management Studio (SSMS) ではリスナーを削除したが、SQL IaaS Agent 拡張機能から削除しなかった場合に、101-sql-vm-aglistener-setup テンプレートをデプロイすると発生する可能性があります。 SSMS でリスナーを削除しても、リスナーのメタデータは SQL IaaS Agent 拡張機能から削除されません。 PowerShell を使用してリソース プロバイダーからリスナーを削除する必要があります。
ドメイン アカウントが存在しない このエラーには 2 つの原因が考えられます。 指定したドメイン アカウントが存在しないか、またはユーザー プリンシパル名 (UPN) のデータがありません。 101-sql-vm-ag-setup テンプレートでは、ドメイン アカウントを UPN 形式 (つまり user@domain.com) で指定する必要がありますが、一部のドメイン アカウントはこの形式では指定されていません。 これは一般に、サーバーがドメイン コントローラーに昇格されたときにローカル ユーザーが最初のドメイン管理者アカウントに移行された場合や、ユーザーが PowerShell を使用して作成された場合に発生します。
アカウントが存在することを確認します。 その場合、2 番目の状況になっている可能性があります。 それを解決するには、次のようにします。
ドメイン コントローラーで、サーバー マネージャーの [ツール] オプションから [Active Directory ユーザーとコンピューター] ウィンドウを開きます。
左側のウィンドウで [ユーザー] を選択してアカウントに移動します。
アカウントを右クリックし、 [プロパティ] を選択します。
[アカウント] タブを選択します。 [ユーザー ログオン名] ボックスが空の場合は、これがエラーの原因です。
ユーザーの名前と一致するように [ユーザー ログオン名] ボックスに入力し、ドロップダウン リストから適切なドメインを選択します。
[適用] を選択して変更内容を保存し、 [OK] を選択してダイアログ ボックスを閉じます。
これらの変更を行った後、もう一度 Azure クイックスタート テンプレートのデプロイを試みます。
次のステップ
詳細については、以下をご覧ください。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示