Azure リージョン間に可用性グループを構成する - Azure VM 上の SQL Server
このチュートリアルでは、プライマリ レプリカに対してリモートである Azure リージョン内の Azure 仮想マシン (VM) 上に、SQL Server の Always On 可用性グループのレプリカを構成する方法について説明します。 この構成は、ディザスター リカバリー (DR) の目的に使用できます。
この記事の手順を使用して、既存のオンプレミスの可用性グループを Azure に拡張することもできます。
このチュートリアルは、1 つのリージョンの 1 つのサブネットに可用性グループを手動でデプロイするチュートリアルに基づいています。 この記事で言及しているローカル リージョンとは、1 つ目のリージョンに既に構成されている仮想マシンと可用性グループのことを指します。 リモート リージョンは、このチュートリアルで追加される新しいインフラストラクチャです。
概要
次の図は、Azure Virtual Machines での可用性グループの一般的なデプロイを示したものです。
図に示すデプロイでは、すべての仮想マシンが 1 つの Azure リージョンに存在します。 可用性グループ レプリカは、SQL-1 および SQL-2 上の自動フェールオーバーとの同期コミットを持つことができます。 このアーキテクチャを構築するには、可用性グループのテンプレートまたはチュートリアルを参照してください。
このアーキテクチャは、Azure リージョンにアクセスできなくなった場合、ダウンタイムに対して脆弱です。 この脆弱性に対処するには、別の Azure リージョンにレプリカを追加します。 次の図は、新しいアーキテクチャの概要を示したものです。
この図では、SQL-3 という名前の新しい仮想マシンが示されています。 SQL-3 は別の Azure リージョンにあります。 それは Windows Server フェールオーバー クラスターに追加され、可用性グループのレプリカをホストできます。
SQL-3 の Azure リージョンに新しい Azure ロード バランサーがあります。 このアーキテクチャでは、通常、リモート リージョン内のレプリカは非同期コミット可用性モードおよび手動フェールオーバー モードで構成されます。
Note
同じリージョン内に複数の仮想マシンがある場合は、Azure 可用性セットが必要です。 リージョン内の仮想マシンが 1 つだけの場合は、可用性セットは必要ありません。
可用性セットに仮想マシンを配置できるのは作成時のみです。 可用性セットに仮想マシンが既に存在する場合は、後で追加レプリカ用の仮想マシンを追加できます。
可用性グループのレプリカが異なる Azure リージョンの Azure 仮想マシン上にある場合は、仮想ネットワーク ピアリングまたはサイト間 VPN ゲートウェイを使用して仮想ネットワークを接続できます。
重要
このアーキテクチャでは、Azure リージョン間でレプリケートされるデータに対して送信データ料金がかかります。 「帯域幅の価格」を参照してください。
ネットワークとサブネットの作成
新しいリージョンに仮想ネットワークとサブネットを作成する前に、リモート リージョンに使用するアドレス空間、サブネット ネットワーク、クラスター IP、可用性グループ リスナーの IP アドレスを決定します。
ローカル (現在の) リージョンの詳細と、新しいリモート リージョンで設定される内容を、次の表に示します。
| Type | ローカル | リモート リージョン |
|---|---|---|
| アドレス空間 | 192.168.0.0/16 | 10.36.0.0/16 |
| サブネット ネットワーク | 192.168.15.0/24 | 10.36.1.0/24 |
| クラスターの IP | 192.168.15.200 | 10.36.1.200 |
| 可用性グループ リスナー IP | 192.168.15.201 | 10.36.1.201 |
Azure portal で新しいリージョンに仮想ネットワークとサブネットを作成するには:
Azure portal で、ご利用のリソース グループに移動して [+ 作成] を選びます。
[マーケットプレース] 検索ボックスで「仮想ネットワーク」を検索し、Microsoft の [仮想ネットワーク] タイルを選択します。
[仮想ネットワークの作成] ページで、[作成] を選択します。 次に、[基本] タブに次の情報を入力します。
- [プロジェクトの詳細] の [サブスクリプション] で、適切な Azure サブスクリプションを選択します。 [リソース グループ] で、さきほど作成した SQL-HA-RG などのリソース グループを選択します。
- [インスタンスの詳細] で、仮想ネットワークの名前 (remote_HAVNETなど) を指定します。 次に、新しいリモート リージョンを選択します。
[IP アドレス] タブで、[+ サブネットの追加] の横にある省略記号 (...) を選択します。 別のアドレス範囲が必要な場合は、[アドレス空間の削除] を選択して既存のアドレス空間を削除します。
[IP アドレス空間の追加] を選択してペインを開き、必要なアドレス空間を作成します。 このチュートリアルでは、リモート リージョンのアドレス空間として 10.36.0.0/16 を使用します。 [追加] を選択します。
[+ サブネットの追加] を選択し、次のようにします。
[サブネット名] に値 (admin など) を指定します。
仮想ネットワーク アドレス空間内に一意のサブネット アドレス範囲を指定します。
たとえば、アドレス範囲が 10.36.0.0/16 の場合は、admin サブネットについて次の値を入力します。[開始アドレス] として「10.36.1.0」、[サブネット サイズ] として「/24」です。
[追加] を選択して、新しいサブネットを追加します。
2 つの Azure リージョンの仮想ネットワークを接続する
新しい仮想ネットワークとサブネットを作成したら、相互通信が可能になるよう 2 つのリージョンを接続する準備が整います。 これは、次の 2 つの方法で行うことができます。
Azure portal を使用して仮想ネットワーク ピアリングで仮想ネットワークを接続する (推奨)
場合によっては、PowerShell を使用して仮想ネットワーク間の接続を作成する必要があります。 たとえば、異なる Azure アカウントを使っている場合、ポータルで接続を構成することはできません。 この場合は、Azure portal を使用したネットワーク間接続の構成に関するページを参照してください。
このチュートリアルでは、仮想ネットワーク ピアリングを使用します。 仮想ネットワーク ピアリングを構成するには:
Azure portal の上部にある検索ボックスに、「autoHAVNET」と入力します。これはローカル リージョン内の仮想ネットワークです。 検索結果に autoHAVNET が表示されたら、それを選択します。
[設定] で [ピアリング] を選択し、[+ 追加] を選択します。
次の情報を入力するか選択し、それ以外の設定では既定値をそのまま使用して、[追加] を選択します。
設定 値 この仮想ネットワーク [Peering link name](ピアリング リンク名) autoHAVNET からリモート仮想ネットワークへのピアリングの名前として、「autoHAVNET-remote_HAVNET」と入力します。 リモート仮想ネットワーク [Peering link name](ピアリング リンク名) リモート仮想ネットワークから autoHAVNET へのピアリングの名前として、「remote_HAVNET-autoHAVNET」と入力します。 サブスクリプション リモート仮想ネットワークのサブスクリプションを選択します。 Virtual Network リモート仮想ネットワークの名前として remote_HAVNET を選択します。 そのリモート仮想ネットワークは、autoHAVNET と同じリージョンまたは別のリージョンに存在する場合があります。 
[ピアリング] ページの [ピアリング状態] は [接続済み] です。
[接続済み] 状態が 表示されない場合は、 [更新] ボタン を選択 します。
ドメイン コントローラーを作成する
プライマリ サイトが使用できない場合に認証を提供するために、新しいリージョンにドメイン コントローラーが必要です。 新しいリージョンにドメイン コントローラーを作成するには:
- SQL-HA-RG リソース グループに戻ります。
- [+ 作成] を選択します。
- 「Windows Server 2016 Datacenter」と入力し、結果の "Windows Server 2016 Datacenter" を選択します。
- [Windows Server 2016 Datacenter] でデプロイメント モデルが [Resource Manager] に設定されていることを確認し、 [作成] を選択します。
次の表に、この 2 つのマシンの設定を示します。
| 設定 | 値 |
|---|---|
| 名前 | リモート ドメイン コントローラー: ad-remote-dc |
| VM ディスクの種類 | SSD |
| ユーザー名 | DomainAdmin |
| パスワード | Contoso!0000 |
| サブスクリプション | 該当するサブスクリプション |
| リソース グループ | SQL-HA-RG |
| 場所 | 該当する場所 |
| [サイズ] | DS1_V2 |
| Storage | マネージド ディスクを使用: はい |
| Virtual Network | remote_HAVNET |
| サブネット | admin |
| パブリック IP アドレス | VM と同じ名前 |
| ネットワーク セキュリティ グループ | VM と同じ名前 |
| 診断 | Enabled |
| 診断ストレージ アカウント | 自動的に作成 |
Azure で仮想マシンが作成されます。
ドメイン コントローラーの構成
次の手順では、ad-remote-dc マシンを corp.contoso.com のドメイン コントローラーとして構成します。
優先 DNS サーバー アドレスを設定する
優先 DNS サーバー アドレスは、VM 内で直接更新しないでください。Azure portal、PowerShell、または Azure CLI から編集する必要があります。 次の手順では、Azure portal 内で変更を行います。
Azure portal にサインインします。
ポータルの上部にある検索ボックスに、「ネットワーク インターフェイス」と入力します。 検索結果から [ネットワーク インターフェイス] を選択します。
リストから、設定を表示または変更する 2 番目のドメイン コントローラーのネットワーク インターフェイスを選択します。
[設定] で、[DNS サーバー] を選択します。
このドメイン コントローラーはプライマリ ドメイン コントローラーと同じ仮想ネットワーク内にないため、[カスタム] を選択し、
192.168.15.4などのプライマリ ドメイン コントローラーの IP アドレスを入力します。 指定した DNS サーバー アドレスは、このネットワーク インターフェイスにのみ割り当てられて、ネットワーク インターフェイス割り当て先の仮想ネットワークの DNS 設定をすべてオーバーライドします。[保存] を選択します。
Azure portal 内の仮想マシンに戻り、VM を再起動します。 仮想マシンが再起動されたら、VM をドメインに参加させることができます。
ドメインに参加する
次に、corp.contoso.com ドメインに参加します。 これを行うには、次のステップに従います。
- BUILTIN\DomainAdmin アカウントを使用して仮想マシンにリモート接続します。
- サーバー マネージャーを開き [ローカル サーバー] を選びます。
- [WORKGROUP] を選びます。
- [コンピューター名] セクションで、 [変更] を選択します。
- [ドメイン] チェック ボックスをオンにし、テキスト ボックスに「corp.contoso.com」を入力します。 [OK] を選択します。
- [Windows セキュリティ] ポップアップ ダイアログで、既定のドメイン管理者の資格情報であるアカウント (CORP\DomainAdmin) とパスワード (Contoso!0000) を指定します。
- "corp.contoso.com ドメインへようこそ" のメッセージが表示されたら、 [OK] を選択します。
- [閉じる] を選択し、ポップアップ ダイアログで [今すぐ再起動] を選択します。
ドメイン コントローラーを構成する
サーバーがドメインに参加したら、2 つ目のドメイン コントローラーとして構成できます。 これを行うには、次のステップに従います。
まだ接続していない場合は、セカンダリ ドメイン コントローラーへの RDP セッションを開き、サーバー マネージャー ダッシュボードを開きます (既定で開く場合があります)。
ダッシュボードの [役割と機能の追加] リンクを選択します。
[サーバーの役割] セクションが表示されるまで [次へ] を選択します。
[Active Directory Domain Services] と [DNS サーバー] という役割を選択します。 メッセージが表示されたら、これらの役割に必要なその他の機能を追加します。
機能のインストールが完了したら、 [サーバー マネージャー] ダッシュボードに戻ります。
左側のウィンドウで新しい [AD DS] オプションを選択します。
黄色の警告バーにある [その他] リンクを選択します。
[すべてのサーバー タスクの詳細] ダイアログ ボックスの [操作] 列で、 [このサーバーをドメイン コントローラーに昇格する] を選択します。
[デプロイ構成] で [既存のドメインにドメイン コントローラーを追加する] を選択します。
[選択] をクリックします。
管理者アカウント (CORP.CONTOSO.COM\domainadmin) とパスワード (Contoso!0000) を使用して接続します。
[フォレストからのドメインの選択] でドメインを選択し、 [OK] を選択します。
[ドメイン コントローラー オプション] で、既定値を使用し、DSRM パスワードを設定します。
Note
[DNS オプション] ページでは、この DNS サーバーの委任を作成できないという警告が表示される場合があります。 この警告は、非運用環境では無視してかまいません。
前提条件の確認のダイアログ ボックスが表示されるまで、 [次へ] を選択します。 その後、 [インストール] を選択します。
サーバーによる構成の変更が完了したら、サーバーを再起動します。
SQL Server VM の作成
ドメイン コントローラー再起動後の次の手順では、新しいリージョンに SQL Server 仮想マシンを作成します。
続行する前に、次の設計上の決定を検討してください。
ストレージ: Azure マネージド ディスク
仮想マシンのストレージには、Azure マネージド ディスクを使用します。 SQL Server 仮想マシンにはマネージド ディスクをお勧めします。 マネージド ディスクは、バックグラウンドでストレージを処理します。 さらに、マネージド ディスクを使用する仮想マシンが同じ可用性セット内にある場合、適切な冗長性を提供するために Azure でストレージ リソースが分散されます。
詳細については、「Azure マネージド ディスクの概要」を参照してください。 可用性セットのマネージド ディスクの詳細は、「可用性セット内の VM にマネージド ディスクを使用する」を参照してください。
ネットワーク: 運用中のプライベート IP アドレス
このチュートリアルでは、仮想マシンにパブリック IP アドレスを使用します。 パブリック IP アドレスを使うと、インターネット経由で仮想マシンに直接リモート接続できるため、構成手順が簡素化されます。 運用環境には、プライベート IP アドレスのみをお勧めします。 プライベート IP アドレスにより、SQL Server VM の脆弱性の占有領域が縮小します。
ネットワーク: サーバーごとに 1 つの NIC
サーバー (クラスター ノード) ごとに 1 つのネットワーク インターフェイス カード (NIC) と、1 つのサブネットを使用します。 Azure ネットワークは物理的な冗長性を備えているので、Azure VM ゲスト クラスターで NIC とサブネットを追加する必要はありません。 クラスター検証レポートで、1 つのネットワークでしかノードに到達できないという警告が出されます。 Azure VM ゲスト フェールオーバー クラスターでは、この警告を無視できます。
SQL Server VM を作成および構成する
SQL Server VM を作成するには、SQL-HA-RG リソース グループに戻り、[追加] を選択します。 適切なギャラリー項目を検索し、 [仮想マシン] を選択し、 [ギャラリーから] を選択します。 次の表の情報を使用すると、VM の作成に役立ちます。
| ページ | 設定 |
|---|---|
| 適切なギャラリー アイテムの選択 | SQL Server 2016 SP1 Enterprise on Windows Server 2016 |
| 仮想マシンの構成: 基本 | 名前 = sqlserver-2 ユーザー名 = DomainAdmin パスワード = Contoso!0000 [サブスクリプション] = 自分のサブスクリプション リソース グループ = SQL-HA-RG 場所 = 自分のリモート リージョン |
| 仮想マシンの構成: サイズ | サイズ = DS2_V2 (2 vCPU、7 GB) SSD ストレージをサポートするサイズが必要 (Premium ディスクのサポート)。 |
| 仮想マシンの構成: 設定 | ストレージ: マネージド ディスクを使用 仮想ネットワーク = remote-HAVNET サブネット = admin (10.36.1.0/24) パブリック IP アドレス = 自動的に生成されます ネットワーク セキュリティ グループ = なし [監視診断] = 有効 診断ストレージ アカウント = 自動的に生成されたストレージ アカウントを使用 |
| 仮想マシンの構成: SQL Server の設定 | SQL 接続 = プライベート (仮想ネットワーク内) ポート = 1433 SQL 認証 = 無効 ストレージの構成 = 一般 自動修正 = 日曜日 2:00 自動バックアップ = 無効 [Azure Key Vault の統合] = 無効 |
注意
また、ここで示されるマシンのサイズは、Azure 仮想マシンでの可用性グループのテストに対応しています。 運用時のワークロードに対して最適なパフォーマンスを得る方法については、「チェックリスト: Azure VM 上の SQL Server のベスト プラクティス」の SQL Server マシンのサイズと構成に関する推奨事項を参照してください。
VM が完全にプロビジョニングされたら、corp.contoso.com ドメインに参加させて、マシンに対する管理者権限を CORP\Install に付与する必要があります。
サーバーをドメインに参加させる
VM を corp.contoso.com に参加させるには、SQL Server VM に対して次の手順を使用します。
- BUILTIN\DomainAdmin を使用して仮想マシンにリモート接続します。
- サーバー マネージャーで [ローカル サーバー] を選択します。
- [ワークグループ] リンクを選択します。
- [コンピューター名] セクションで、 [変更] を選択します。
- [ドメイン] チェック ボックスをオンにし、テキスト ボックスに「corp.contoso.com」を入力します。 [OK] をクリックします。
- [Windows セキュリティ] ポップアップ ダイアログで、既定のドメイン管理者の資格情報であるアカウント (CORP\DomainAdmin) とパスワード (Contoso!0000) を指定します。
- "corp.contoso.com ドメインへようこそ" のメッセージが表示されたら、 [OK] を選択します。
- [閉じる] を選択し、ポップアップ ダイアログで [今すぐ再起動] を選択します。
アカウントの追加
次のタスクでは、SQL Server VM の管理者としてインストール アカウントを追加し、そのアカウントと SQL Server 内のローカル アカウントにアクセス許可を付与します。 その後、SQL Server サービス アカウントを更新できます。
各クラスター VM に CORP\Install ユーザーを管理者として追加する
SQL Server 仮想マシンをドメインのメンバーとして再起動した後、CORP\Install をローカルの Administrators グループのメンバーとして追加します。
VM が再起動されるまで待ってから、プライマリ ドメイン コントローラーからもう一度 RDP ファイルを開きます。 CORP\DomainAdmin アカウントを使用して sqlserver-2 にサインインします。
ヒント
前の手順では、BUILTIN 管理者アカウントを使用していました。 今はサーバーがドメイン内にあるので、必ずドメイン管理者アカウントでサインインしてください。 RDP セッションで、DOMAIN\username を指定します。
[サーバー マネージャー] で [ツール] を選択し、 [コンピューターの管理] を選択します。
[コンピューターの管理] ウィンドウで、 [ローカル ユーザーとグループ] を展開し、 [グループ] を選択します。
[Administrators] グループをダブルクリックします。
[Administrator のプロパティ] ダイアログで、[追加] ボタンを選択します。
ユーザーを「CORP\Install」と入力し、[OK] を選択します。
[OK] を選択して [管理者のプロパティ] ダイアログ ボックスを閉じます。
各 SQL Server VM にインストール アカウント用のサインインを作成する
可用性グループを構成するには、インストール アカウント (CORP\Install) を使用します。 このアカウントは、各 SQL Server VM の sysadmin 固定サーバー ロールのメンバーである必要があります。 次の手順で、インストール アカウント用のサインインを作成します。 これを両方の SQL Server VM で行います。
<MachineName>\DomainAdmin アカウントを使用して RDP でサーバーに接続します。
SQL Server Management Studio を開き、SQL Server のローカル インスタンスに接続します。
オブジェクト エクスプローラーで [セキュリティ] を選択します。
[ログイン] を右クリックします。 [新しいログイン] を選択します。
[ログイン - 新規作成] で [検索] を選択します。
[場所] を選択します。
ドメイン管理者のネットワーク資格情報を入力します。 インストール アカウント (CORP\Install) を使用します。
サインインを sysadmin 固定サーバー ロールのメンバーに設定します。
[OK] を選択します。
システム アカウントのアクセス許可を構成する
システム アカウントを作成し、適切なアクセス許可を付与するには、各 SQL Server インスタンスで次の手順を実行します。
次のスクリプトを使用して、
[NT AUTHORITY\SYSTEM]のアカウントを作成します。USE [master] GO CREATE LOGIN [NT AUTHORITY\SYSTEM] FROM WINDOWS WITH DEFAULT_DATABASE=[master] GO[NT AUTHORITY\SYSTEM]に次のアクセス許可を付与します。ALTER ANY AVAILABILITY GROUPCONNECT SQLVIEW SERVER STATE
次のスクリプトは、これらのアクセス許可を付与します。
GRANT ALTER ANY AVAILABILITY GROUP TO [NT AUTHORITY\SYSTEM] GO GRANT CONNECT SQL TO [NT AUTHORITY\SYSTEM] GO GRANT VIEW SERVER STATE TO [NT AUTHORITY\SYSTEM] GO
SQL Server サービス アカウントの設定
各 SQL Server VM で、次の手順を実行して SQL Server サービス アカウントを設定します。 ドメイン アカウントの構成時に作成したアカウントを使用します。
- [SQL Server 構成マネージャー] を開きます。
- SQL Server サービスを右クリックし、 [プロパティ] を選択します。
- アカウントとパスワードを設定します。
SQL Server 可用性グループでは、各 SQL Server VM をドメイン アカウントとして実行する必要があります。
Azure Load Balancer を作成する
SQL Server 可用性グループに対応するには、リモート リージョンにロード バランサーが必要です。 ロード バランサーには、可用性グループ リスナーと Windows Server フェールオーバー クラスターの IP アドレスが保持されます。 このセクションでは、Azure Portal でロード バランサーを作成する方法の概要を説明します。
このロード バランサーは、次のようになっている必要があります。
- 新しい仮想マシンと同じネットワーク内およびサブネット内であること。
- 可用性グループ リスナー用の静的 IP アドレスがあること。
- ロード バランサーと同じリージョン内の仮想マシンのみで構成されるバックエンド プールを含むこと。
- IP アドレスに固有の TCP ポート プローブを使用していること。
- 同じリージョン内の SQL Server インスタンスに固有の負荷分散ルールがあること。
- バックエンド プール内の仮想マシンが単一の可用性セットまたは仮想マシン スケール セットの一部でない場合は、標準のロード バランサーであること。 詳細については、「Azure Load Balancer の概要」を参照してください。
- 2 つの異なるリージョンにある 2 つの仮想ネットワークがグローバル仮想ネットワーク ピアリングを介してピアリングされている場合は、標準のロード バランサーであること。 詳細については、「Azure Virtual Network についてよく寄せられる質問 (FAQ)」を参照してください。
ロード バランサーを作成する手順は次のとおりです。
Azure portal で、対象の SQL Server インスタンスが存在するリソース グループに移動し、[+ 追加] を選択します。
「ロード バランサー」を検索します。 Microsoft が公開しているロード バランサーを選択します。
［作成］ を選択します
ロード バランサーに関して次のパラメーターを構成します。
設定 値 サブスクリプション 仮想マシンと同じサブスクリプションを使います。 リソース グループ 仮想マシンと同じリソース グループを使用します。 名前 ロード バランサーのテキスト名を使います (例: remoteLB)。 リージョン 仮想マシンと同じリージョンを使用します。 SKU [Standard] を選択します。 Type [内部] を選択します。 Azure Portal のペインは次のようになります。
[次へ: フロントエンド IP 構成] を選択します。
[フロントエンド IP 構成の追加] を選択します。
次の値を使用してフロントエンド IP アドレスを設定します。
- [名前]: フロントエンド IP 構成を識別する名前を使用します。
- [仮想ネットワーク]: 仮想マシンと同じネットワークを使用します。
- [サブネット]: 仮想マシンと同じサブネットを使用します。
- [割り当て]: [静的] を選択します。
- [IP アドレス]: サブネットで利用できるアドレスを使用します。 可用性グループ リスナーにはこのアドレスを使用します。 このアドレスはクラスター IP アドレスとは異なります。
- 可用性ゾーン: 必要に応じて、IP アドレスをデプロイする可用性ゾーンを選択します。
[追加] を選択します。
[確認および作成] を選択して構成を検証してから、[作成] を選択してロード バランサーとフロントエンド IP アドレスを作成します。
ロード バランサーを構成するには、バックエンド プールとプローブを作成し、負荷分散規則を設定する必要があります。
可用性グループ リスナーのバックエンド プールを追加する
Azure Portal で、可用性グループに移動します。 新しく作成したロード バランサーを表示するため、ビューの更新が必要な場合があります。
ロード バランサーを選び、[バックエンド プール]、[+ 追加] の順に選択します。
[名前] で、バックエンド プールの名前を指定します。
[バックエンド プールの構成] で [NIC] を選択します。
[追加] を選択して、バックエンド プールを新しく作成された SQL Server VM に関連付けます。
[仮想マシン] で、可用性グループ レプリカをホストする仮想マシンを選びます。
[追加] を選択して、仮想マシンをバックエンド プールに追加します。
[保存] を選択します。
プローブを設定する
Azure portal でロード バランサーを選び、[正常性プローブ]、[+ 追加] の順に選択します。
リスナーの正常性プローブを次のように設定します。
設定 説明 例 名前 Text SQLAlwaysOnEndPointProbe プロトコル TCP を選びます TCP [ポート] 未使用の任意のポート 59999 間隔 プローブの試行の間隔 (秒単位) 5 [追加] を選択します。
負荷分散規則を設定する
Azure portal でロード バランサーを選び、[負荷分散規則]、[+ 追加] の順に選択します。
次のようにリスナーの負荷分散規則を設定します。
設定 説明 例 名前 Text SQLAlwaysOnEndPointListener フロントエンド IP アドレス アドレスを選びます ロード バランサーの作成時に作成したアドレスを使います。 バックエンド プール バックエンド プールを選ぶ ロード バランサーを対象とする仮想マシンを含むバックエンド プールを選択します。 プロトコル TCP を選びます TCP [ポート] 可用性グループ リスナーのポートを使用する 1433 バックエンド ポート Direct Server Return に Floating IP を設定するときは、このフィールドは使われません 1433 正常性プローブ プローブに指定した名前 SQLAlwaysOnEndPointProbe セッション永続化 ドロップダウン リスト なし アイドル タイムアウト TCP 接続を開いたままにしておく時間 (分) 4 フローティング IP (ダイレクト サーバー リターン) この設定を有効にします。 警告
Direct Server Return は作成の間に設定されます。 これは変更できません。
[保存] を選択します。
SQL Server VM にフェールオーバー クラスタリングを追加する
フェールオーバー クラスタリング機能を追加するには、両方の SQL Server VM 方で次の手順を実行します。
CORP\Install アカウントを使用して RDP で SQL Server 仮想マシンに接続します。 [サーバー マネージャー] ダッシュボードを開きます。
ダッシュボードの [役割と機能の追加] リンクを選択します。
[Server Features (サーバーの機能)] セクションが表示されるまで [次へ] を選択します。
[機能] で [フェールオーバー クラスタリング] を選択します。
必要な機能を追加します。
[インストール] を選択します。
注意
このタスクは、実際に SQL Server VM をフェールオーバー クラスターに参加させる手順と共に、Azure CLI と Azure クイック スタート テンプレートを使用して自動化できるようになりました。
フェールオーバー クラスターのネットワークしきい値を調整する
SQL Server 可用性グループを使用して Azure VM で Windows フェールオーバー クラスター ノードを実行する場合は、クラスター設定をより緩やかな監視状態に変更します。 これにより、クラスターの安定性と信頼性が向上します。 詳細については、「SQL Server による IaaS: フェールオーバー クラスター ネットワークのしきい値の調整」を参照してください。
各 SQL Server VM でファイアウォールを構成する
このソリューションでは、ファイアウォールで次の TCP ポートが開いている必要があります。
- SQL Server VM:SQL Server の既定のインスタンス用のポート 1433。
- Azure Load Balancer プローブ: 使用可能な任意のポート。 例では 59999 がよく使用されます。
- クラスター コア ロードバランサーの IP アドレスの正常性プローブ: 使用可能な任意のポート。 例では 58888 がよく使用されます。
- データベース ミラーリング エンドポイント: 使用可能な任意のポート。 例では 5022 がよく使用されます。
新しい SQL Server VM 上でファイアウォールのポートを開く必要があります。 ポートを開く方法は、使用するファイアウォール ソリューションによって異なります。 次の手順は、Windows ファイアウォールでポートを開く方法を示しています。
SQL Server のスタート画面で、[セキュリティが強化された Windows ファイアウォール] を開きます。
左側のウィンドウで、 [受信の規則] を選択します。 右側のペインで [新しい規則] を選択します。
[規則の種類] で、[ポート] を選択します。
ポートに対して [TCP] を指定し、適切なポート番号を入力します。 次のスクリーンショットは、例を示しています。
[次へ] を選択します。
[操作] ページで、[接続を許可する] をオンにしたまま、[次へ] を選択します。
[プロファイル] ページで、既定の設定をそのまま使用し、[次へ] を選択します。
[名前] ページで、[名前] ボックスに規則の名前 (Azure LB Probe など) を指定し、[完了] を選択します。
Windows Server フェールオーバー クラスターに SQL Server を追加する
新しい SQL Server VM は、ローカル リージョンに存在する Windows Server フェールオーバー クラスターに追加する必要があります。
クラスターに SQL Server VM を追加するには:
RDP を使用して、既存のクラスター内の SQL Server VM に接続します。 SQL Server VM と監視サーバーの両方で管理者であるドメイン アカウントを使用します。
[サーバー マネージャー] ダッシュボードで、[ツール]、[フェールオーバー クラスター マネージャー] の順に選択します。
左側のペインで、[フェールオーバー クラスター マネージャー] を右クリックし、[クラスターに接続する] を選択します。
[クラスターの選択] ウィンドウの [クラスター名] で、<このサーバー上のクラスター> を選択します。 [OK] をクリックします。
ブラウザー ツリーで、クラスターを右クリックし、 [ノードの追加] を選択します。
ノードの追加ウィザードで、 [次へ] を選択します。
[サーバーの選択] ページで、新しい SQL Server インスタンスの名前を追加します。 [サーバー名の入力] にサーバー名を入力し、[追加] を選択してから、[次へ] を選択します。
[検証の警告] ページで、[いいえ] を選択します (運用シナリオでは、検証テストを実行する必要があります)。 次に、 [次へ] を選択します。
記憶域スペースを使用している場合は、[確認] ページで、[使用可能な記憶域をすべてクラスターに追加する] チェックボックスをオフにします。
警告
[使用可能な記憶域をすべてクラスターに追加する] をオフにしないと、クラスタリング プロセスの実行中、Windows によって仮想ディスクがデタッチされます。 その結果、仮想ディスクはディスク マネージャーやエクスプローラーに表示されなくなり、表示するためには、記憶域をクラスターから削除し、PowerShell を使って再アタッチしなければなりません。
[次へ] を選択します。
[完了] を選択します。
フェールオーバー クラスター マネージャーに、クラスターに新しいノードがあることが示され、そのノードが [ノード] コンテナーの一覧に表示されます。
Windows Server フェールオーバー クラスターの IP アドレスを追加する
注意
Windows Server 2019 の場合、クラスターで作成されるのは "クラスター ネットワーク名" ではなく、"分散サーバー名" です。 Windows Server 2019 を使用している場合は、「可用性グループ リスナーの IP アドレスを追加する」に進んでください。 クラスター ネットワーク名は、PowerShell を使用して作成できます。 詳細については、ブログ記事「フェールオーバー クラスター: クラスター ネットワーク オブジェクト」を参照してください。
次に、IP アドレス リソースを作成し、新しい SQL Server VM のクラスターに追加します。
フェールオーバー クラスター マネージャーで、クラスターの名前を選択します。 [クラスター コア リソース] の下でクラスター名を右クリックし、[プロパティ] を選択します。
[クラスターのプロパティ] ダイアログで、[IP アドレス] の下にある [追加] を選択し、リモート ネットワーク領域からクラスター名の IP アドレスを追加します。 [IP アドレス] ダイアログで [OK] を選択し、[クラスターのプロパティ] ダイアログで [OK] を選択して、新しい IP アドレスを保存します。
クラスター コア名の依存関係として IP アドレスを追加します。
[クラスターのプロパティ] ダイアログをもう一度開き、[依存関係] タブを選択します。2 つの IP アドレスの OR 依存関係を構成します。
可用性グループ リスナーの IP アドレスを追加する
リモート リージョン内のリスナー用の IP アドレスをクラスターに追加する必要があります。 IP アドレスを追加するには:
フェールオーバー クラスター マネージャーで、可用性グループの役割を右クリックします。 [リソースの追加] をポイントし、[その他のリソース] をポイントして、[IP アドレス] を選択します。
この IP アドレスを構成するには、[その他のリソース] の下にあるリソースを右クリックし、[プロパティ] を選択します。
[名前] に、新しいリソースの名前を入力します。 [ネットワーク] で、リモート データセンターからネットワークを選択します。 [静的 IP アドレス] を選択し、[アドレス] ボックスで、新しい Azure ロード バランサーから静的 IP アドレスを割り当てます。
[Apply](適用) を選択し、次に [OK] を選択します。
リスナー クライアント アクセス ポイント (ネットワーク名) クラスターに対する依存関係として、IP アドレス リソースを追加します。
リスナー クライアント アクセス ポイントを右クリックし、[プロパティ] を選択します。 [依存関係] タブを参照し、新しい IP アドレス リソースをリスナー クライアント アクセス ポイントに追加します。 次のスクリーンショットは、適切に構成された IP アドレス クラスター リソースを示したものです。
重要
クラスター リソース グループには、両方の IP アドレスが含まれます。 両方の IP アドレスが、リスナー クライアント アクセス ポイントの依存関係です。 クラスターの依存関係の構成では、OR 演算子を使います。
PowerShell でクラスターのパラメーターを設定する。
新しいリージョンのロード バランサーに構成したクラスター ネットワーク名、IP アドレス、プローブ ポートを指定して、PowerShell スクリプトを実行します。
$ClusterNetworkName = "<MyClusterNetworkName>" # The cluster name for the network in the new region (Use Get-ClusterNetwork on Windows Server 2012 or later to find the name.) $IPResourceName = "<IPResourceName>" # The cluster name for the new IP address resource. $ILBIP = "<n.n.n.n>" # The IP address of the internal load balancer in the new region. This is the static IP address for the load balancer that you configured in the Azure portal. [int]$ProbePort = <nnnnn> # The probe port that you set on the internal load balancer. Import-Module FailoverClusters Get-ClusterResource $IPResourceName | Set-ClusterParameter -Multiple @{"Address"="$ILBIP";"ProbePort"=$ProbePort;"SubnetMask"="255.255.255.255";"Network"="$ClusterNetworkName";"EnableDhcp"=0}
可用性グループを有効にする
次に、Always On 可用性グループ機能を有効にします。 新しい SQL Server VM で次の手順を実行します。
スタート画面から SQL Server 構成マネージャーを開きます。
ブラウザー ツリーで、[SQL Server サービス] を選択します。 SQL Server (MSSQLSERVER) サービスを右クリックし、[プロパティ] を選択します。
[AlwaysOn 高可用性] タブを選択し、[AlwaysOn 可用性グループを有効にする] をオンにします。
[適用] を選択します。 ポップアップ ダイアログで [OK] を選択します。
SQL Server サービスを再起動します。
可用性グループにレプリカを追加する
新しく作成された仮想マシンで SQL Server が再起動されたら、それを可用性グループにレプリカとして追加できます。
可用性グループ内のプライマリ SQL Server インスタンスへのリモート デスクトップ セッションを開き、SQL Server Management Studio (SSMS) を開きます。
SSMS のオブジェクト エクスプローラーで、[Always On 高可用性]>[可用性グループ] を開きます。 可用性グループ名を右クリックし、[レプリカの追加] を選択します。
既存のレプリカに接続し、[次へ] を選択します。
[レプリカの追加] を選択し、新しい SQL Server VM に接続します。
重要
リモート Azure リージョンのレプリカについては、手動フェールオーバーでの非同期レプリケーションに設定してください。
[最初のデータ同期を選択] ページで、[完全] を選択し、共有ネットワークの場所を指定します。 この場所としては、先に作成したバックアップ共有を使います。 この例では、\\<1 番目の SQL Server>\Backup\ でした。 [次へ] を選択します。
Note
完全同期では、SQL Server の 1 番目のインスタンスにあるデータベースの完全バックアップが作成されて、2 番目のインスタンスに復元されます。 大規模なデータベースの場合、完全同期は長時間かかる可能性があるためお勧めしません。
手動でデータベースをバックアップし、
NO RECOVERYで復元することにより、この時間を短縮できます。 可用性グループを構成する前に、2 番目の SQL Server インスタンスでNO RECOVERYを使用してデータベースが既に復元されている場合は、[結合のみ] を選択します。 可用性グループを構成した後でバックアップを作成する場合は、[最初のデータ同期をスキップ] を選択します。
[検証] ページで [次へ] を選択します。 このページは次の図のようになります。
注意
可用性グループ リスナーを構成していないことを示す、リスナー構成に関する警告が表示されます。 この警告は無視してかまいません。リスナーは既に設定されているからです。 それは、ローカル リージョンに Azure ロード バランサーを作成した後に作成されました。
[概要] ページで、[完了] を選択し、ウィザードで新しい可用性グループが構成されるまで待ちます。 [進行状況] ページで [詳細] を選択すると、進行状況が詳しく表示されます。
ウィザードで構成が完了したら、[結果] ページを調べて、可用性グループが正常に作成されたことを確認します。
[閉じる] を選択してウィザードを閉じます。
可用性グループを確認する
オブジェクト エクスプローラーで、[AlwaysOn 高可用性]、[可用性グループ] の順に展開します。 可用性グループを右クリックして [ダッシュボードの表示] をクリックします。
可用性グループ ダッシュボードが、次のスクリーンショットのように表示されます。今度は別のレプリカです。
このダッシュボードには、レプリカ、各レプリカのフェールオーバー モード、同期の状態が表示されます。
可用性グループ リスナーをチェックする
オブジェクト エクスプローラーで [Always On 高可用性] を展開し、[可用性グループ] を展開してから、[可用性グループ リスナー] を展開します。
リスナー名を右クリックし、 [プロパティ] を選択します。 これで、リスナーの両方の IP アドレスが (各リージョンに 1 つずつ) 表示されます。
複数のサブネットに対する接続を設定する
リモート データ センターのレプリカは、可用性グループの一部ですが、異なるサブネット内にあります。 このレプリカがプライマリ レプリカになった場合、アプリケーション接続のタイムアウトが発生する可能性があります。 この動作は、複数サブネット デプロイでのオンプレミスの可用性グループと同じです。 クライアント アプリケーションからの接続を許可するには、クライアント接続を更新するか、またはクラスター ネットワーク名リソースに名前解決キャッシュを構成します。
可能であれば、クラスター構成を更新して RegisterAllProvidersIP=1 を設定し、クライアント接続文字列を更新して MultiSubnetFailover=Yes を設定してください。 「MultiSubnetFailover を使用した接続」を参照してください。
接続文字列を変更できない場合は、名前解決キャッシュを構成できます。 「マルチサブネット環境で Always On リスナーに接続するとタイムアウトが発生する」を参照してください。
リモート リージョンにフェールオーバーする
リモート リージョンへのリスナー接続をテストするには、リモート リージョンにレプリカをフェールオーバーしてみます。 レプリカは非同期ですが、フェールオーバーはデータ損失の可能性に対して脆弱です。 データを失わずにフェールオーバーするには、可用性モードを同期に変更し、フェールオーバー モードを自動に設定します。 次の手順に従います。
オブジェクト エクスプローラーで、プライマリ レプリカをホストする SQL Server のインスタンスに接続します。
[Always On 可用性グループ] で、可用性グループを右クリックして [プロパティ] を選択します。
[全般] ページの [可用性レプリカ] で、ディザスター リカバリー (DR) サイトのセカンダリ レプリカを、[同期コミット] 可用性モードと [自動] フェールオーバー モードを使うように設定します。
高可用性のためにプライマリ レプリカと同じサイトにセカンダリ レプリカがある場合は、このレプリカを [非同期コミット] および [手動] に設定します。
[OK] を選択します。
オブジェクト エクスプローラーで、可用性グループを右クリックし、[ダッシュボードの表示] を選択します。
ダッシュボードで、DR サイトのレプリカが同期されていることを確認します。
オブジェクト エクスプローラーで、可用性グループを右クリックし、[フェールオーバー] を選択します。 SQL Server Management Studio で、SQL Server をフェールオーバーするためのウィザードが開きます。
[次へ] を選択し、DR サイトの SQL Server インスタンスを選択します。 もう一度 [次へ] を選択します
DR サイトの SQL Server インスタンスに接続し、[次へ] を選択します。
[概要] ページで設定を確認し、 [完了] を選択します。
接続をテストした後は、プライマリ レプリカをプライマリ データセンターに戻し、可用性モードを通常の動作設定に戻します。 次の表では、この記事で説明されているアーキテクチャの通常の動作設定を示します。
| 場所 | サーバー インスタンス | ロール | [可用性モード] | フェールオーバー モード |
|---|---|---|---|---|
| プライマリ データセンター | SQL-1 | プライマリ | 同期 | 自動 |
| プライマリ データセンター | SQL-2 | セカンダリ | 同期 | 自動 |
| セカンダリまたはリモート データセンター | SQL-3 | セカンダリ | 非同期 | マニュアル |
計画された手動フェールオーバーと強制手動フェールオーバーの詳細については、次の記事を参照してください。
次のステップ
詳細については、以下をご覧ください。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示