Azure VM 上の SQL Server の Always On 可用性グループ

  • [アーティクル]

適用対象:Azure VM 上の SQL Server

この記事では、Azure 仮想マシン (VM) 上の SQL Server の Always On 可用性グループ (AG) について説明します。

開始するには、可用性グループのチュートリアルをご覧ください。

概要

Azure 仮想マシン上の Always On 可用性グループは、オンプレミスの Always On 可用性グループと似ており、基盤となる Windows Server フェールオーバー クラスターに依存しています。 ただし、仮想マシンは Azure でホストされているため、VM の冗長性や Azure ネットワーク上でのトラフィックのルーティングなど、追加の考慮事項もいくつかあります。

次の図は、Azure VM 上の SQL Server の可用性グループを示しています。

Availability Group

注意

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

VM の冗長性

冗長性と高可用性を向上させるには、SQL Server VM を同じ可用性セットに配置するか、異なる可用性ゾーンに配置する必要があります。

一連の VM を同じ可用性セットに配置すると、機器の障害が原因で発生するデータ センター内での停止から保護され (可用性セット内の VM はリソースを共有しません)、更新からも保護されます (可用性セット内の VM は同時に更新さません)。

可用性ゾーンによって、データ センター全体の障害から保護されます。各ゾーンは、リージョン内の一連のデータ センターを表します。 リソースがさまざまな可用性ゾーンに配置されるようにすることで、データ センターレベルの停止によってすべての VM がオフラインになることはなくなります。

Azure VM を作成するときは、可用性セットと可用性ゾーンのどちらを構成するかを選択する必要があります。 Azure VM が両方に参加することはできません。

可用性ゾーンは、可用性セットよりも可用性が優れている場合がありますが (99.99% 対 99.95%)、パフォーマンスも考慮する必要があります。 可用性セット内の VM を、相互に近接していることが保証される近接配置グループに配置することができ、それらの間のネットワーク待ち時間が最小限になります。 異なる Availability Zones に配置されている VM では、それらの間のネットワーク待ち時間が大きくなり、プライマリとセカンダリのレプリカ間のデータ同期にかかる時間が長くなる可能性があります。 これにより、プライマリ レプリカに待機時間が発生する可能性があるだけでなく、予定外のフェールオーバーが発生した場合にデータが失われる可能性が高くなります。 提案されたソリューションを負荷の下でテストし、パフォーマンスと可用性両方の SLA を満たすことを確認することが重要です。

接続

可用性グループ リスナーに接続するためのオンプレミス エクスペリエンスに一致するよう、SQL Server VM を同じ仮想ネットワーク内の複数のサブネットにデプロイします。 複数のサブネットを使用すると、トラフィックをリスナーにルーティングするための分散ネットワーク名 (DNN) や Azure Load Balancer への余分な依存関係が不要になります。

SQL Server VM を 1 つのサブネットにデプロイする場合、仮想ネットワーク名 (VNN) と Azure Load Balancer を構成するか、または分散ネットワーク名 (DNN) を構成して可用性グループ リスナーにトラフィックをルーティングすることができます。 この 2 つの違いを確認してから、可用性グループに対して分散ネットワーク名 (DNN) または仮想ネットワーク名 (VNN) をデプロイします。

DNN を使用すると、ほとんどの SQL Server 機能は可用性グループに対して透過的に機能しますが、特定の機能については、特別な考慮が必要となる場合があります。 詳細については、AG と DNN の相互運用性に関する記事を参照してください。

また、VNN リスナーと DNN リスナーの機能には、注意が必要な動作の違いがいつくかあります。

  • フェールオーバー時間: DNN リスナーを使うと、ネットワーク ロード バランサーによって障害イベントが検出されてルーティングが変更されるまで待つ必要がないため、フェールオーバー時間が短縮されます。
  • 既存の接続: フェールオーバー可用性グループ内の特定のデータベースに対する接続は閉じられますが、フェールオーバー処理中も DNN によってオンライン状態が維持されるため、プライマリ レプリカへの他の接続は開いたままになります。 これは、可用性グループがフェールオーバーすると通常はプライマリ レプリカへのすべての接続が閉じられ、リスナーはオフラインになり、プライマリ レプリカはセカンダリの役割に移行するという従来の VNN 環境とは異なります。 DNN リスナーを使用する場合は、フェールオーバー時に接続が新しいプライマリ レプリカにリダイレクトされるように、必要に応じてアプリケーションの接続文字列を調整します。
  • 開いているトランザクション: フェールオーバー可用性グループ内のデータベースに対して開かれているトランザクションは、閉じられ、ロールバックされるので、手動で再接続する必要があります。 たとえば、SQL Server Management Studio で、クエリ ウィンドウを閉じて、新しいウィンドウを開きます。

Azure で VNN リスナーを設定するには、ロード バランサーが必要です。 Azure のロード バランサーには、主に外部 (パブリック) と内部の 2 つのオプションがあります。 外部 (パブリック) ロード バランサーは、インターネットに面しており、インターネット経由でアクセスできるパブリック仮想 IP に関連付けられています。 内部ロード バランサーは、同じ仮想ネットワーク内のクライアントのみをサポートします。 どちらのタイプのロード バランサーの場合でも、Direct Server Return を有効にする必要があります。

この場合でも、サービス インスタンスに直接接続することで、各可用性レプリカに個別に接続できます。 また、可用性グループはデータベース ミラーリング クライアントとの下位互換性があるため、レプリカがデータベース ミラーリングと同様に、次のように構成されていれば、データベース ミラーリング パートナーのように可用性レプリカに接続できます。

  • 1 つのプライマリ レプリカと 1 つのセカンダリ レプリカがある。
  • セカンダリ レプリカが読み取り不可として構成されている ([読み取り可能なセカンダリ] オプションが [いいえ] に設定されている)。

ADO.NET または SQL Server Native Client を使用する、このデータベース ミラーリングと同様の構成に対応するクライアント接続文字列の例を以下に示します。

Data Source=ReplicaServer1;Failover Partner=ReplicaServer2;Initial Catalog=AvailabilityDatabase;

クライアント接続の詳細については、以下を参照してください。

単一サブネットにはロード バランサーが必要である

従来のオンプレミスの Windows Server フェールオーバー クラスター (WSFC) で可用性グループ リスナーを作成すると、指定した IP アドレスを持つリスナーの DNS レコードが作成され、この IP アドレスは、オンプレミス ネットワーク上のスイッチとルーターの ARP テーブルの現在のプライマリ レプリカの MAC アドレスにマップされます。 クラスターはこれを行うために Gratuitous ARP (GARP) を使い、これによって、フェールオーバー後に新しいプライマリが選ばれるたびに、IP から MAC への最新のマッピングがネットワークにブロードキャストされます。 この場合、IP アドレスはリスナーのもので、MAC は現在のプライマリ レプリカのものです。 GARP は、スイッチとルーターに関する ARP テーブルのエントリを強制的に更新し、リスナー IP アドレスに接続するすべてのユーザーは、現在のプライマリ レプリカにシームレスにルーティングされます。

セキュリティ上の理由から、パブリック クラウド (Azure、Google、AWS) でのブロードキャストは許可されないため、Azure での ARP と GARP の使用はサポートされていません。 ネットワーク環境でのこの違いに対処するため、単一のサブネット可用性グループ内の SQL Server VM は、ロード バランサーを使ってトラフィックを適切な IP アドレスにルーティングします。 ロード バランサーはリスナーに対応するフロントエンド IP アドレスで構成され、Azure Load Balancer が可用性グループ内のレプリカの状態を定期的にポーリングするようにプローブ ポートが割り当てられます。 TCP プローブに応答するのはプライマリ レプリカの SQL Server VM のみであるため、受信トラフィックはプローブに正常に応答する VM にルーティングされます。 さらに、対応するプローブ ポートが WSFC クラスター IP として構成され、プライマリ レプリカは TCP プローブに確実に応答します。

単一のサブネットに構成される可用性グループでは、ロード バランサーまたは分散ネットワーク名 (DNN) を使って、トラフィックを適切なレプリカにルーティングする必要があります。 これらの依存関係を回避するには、複数のサブネットで可用性グループを構成し、可用性グループ リスナーが各サブネット内のレプリカの IP アドレスで構成され、トラフィックを適切にルーティングできるようにします。

可用性グループを 1 つのサブネットに既に作成している場合は、マルチサブネット環境に移行できます。

リースのメカニズム

SQL Server の場合、AG リソース DLL は、AG リース メカニズムと Always On 正常性検出に基づいて、AG の正常性を判断します。 AG リソース DLL により、IsAlive 操作を介してリソースの正常性が公開されています。 リソース モニターにより、クラスターのハートビート間隔 (クラスター全体の CrossSubnetDelay 値と SameSubnetDelay 値で設定されます) で IsAlive がポーリングされます。 プライマリ ノードでは、リソース DLL に対する IsAlive の呼び出しから AG が正常でないことが返されるたびに、クラスター サービスによってフェールオーバーが開始されます。

AG リソース DLL により、内部の SQL Server コンポーネントの状態が監視されます。 sp_server_diagnostics により、HealthCheckTimeout で制御される間隔で、これらのコンポーネントの正常性が SQL Server に報告されます。

他のフェールオーバーのメカニズムとは異なり、SQL Server インスタンスはリースのメカニズムで積極的な役割を果たします。 リース メカニズムは、クラスター リソースのホストと SQL Server プロセス間の LooksAlive 検証として使用されます。 このメカニズムは、両者 (クラスター サービスと SQL Server サービス) が頻繁に接触していることを確認する目的で使用されます。互いの状態を確認し、最終的にはスプリットブレインを防止します。

Azure VM で AG を構成するときは、多くの場合、これらのしきい値をオンプレミス環境での構成とは異なる構成にする必要があります。 Azure VM のベスト プラクティスに従ってしきい値設定を構成するには、クラスターのベスト プラクティスに関する記事を参照してください。

ネットワークの構成

Azure Load Balancer または分散ネットワーク名 (DNN) に依存しなくても可用性グループ リスナーにトラフィックをルーティングできるよう、可能な限り SQL Server VM を複数のサブネットにデプロイします。

Azure VM フェールオーバー クラスターでは、サーバー (クラスター ノード) ごとに 1 つの NIC を推奨しています。 Azure ネットワークは物理的な冗長性を備えているので、Azure VM フェールオーバー クラスターに NIC を追加する必要はありません。 クラスター検証レポートで、1 つのネットワークでしかノードに到達できないという警告が出ますが、Azure VM フェールオーバー クラスターではこの警告を無視して構いません。

基本的な可用性グループ

基本的な可用性グループでは複数のセカンダリ レプリカを使用できず、セカンダリ レプリカへの読み取りアクセス権がないので、基本的な可用性グループにはデータベース ミラーリング接続文字列を使用できます。 接続文字列を使用すると、リスナーが不要になります。 リスナーへの依存をなくすと、Azure VM 上の可用性グループに役立ちます。これは、ロード バランサーが不要になったり、追加のデータベースのために複数のリスナーを用意するときにロード バランサーに追加の IP を追加する必要がなくなるためです。

たとえば、基本的な AG (つまり、1 つのセカンダリ レプリカのみを持ち、セカンダリ レプリカで読み取りアクセスが許可されていない AG) の Replica_A または Replica_B 上の AG データベース AdventureWorks に TCP/IP を使って明示的に接続するには、クライアント アプリケーションで次のデータベース ミラーリング接続文字列を指定して、AG に正常に接続できます

Server=Replica_A; Failover_Partner=Replica_B; Database=AdventureWorks; Network=dbmssocn

デプロイ オプション

ヒント

同じ Azure 仮想ネットワーク内の複数のサブネットに SQL Server VM を作成すると、Always On 可用性グループに対して Azure Load Balancer または分散ネットワーク名 (DNN) が不要になります。

Azure VM 上の SQL Server に可用性グループをデプロイするためのオプションは複数あり、その一部は他のものよりも自動化されています。

次の表は、使用可能なオプションの比較を示しています。

Azure portal、 Azure CLI / PowerShell クイック スタート テンプレート 手動 (1 つのサブネット) 手動 (複数のサブネット)
SQL Server のバージョン 2016 以降 2016 以降 2016 以降 2012 以降 2012 以降
SQL Server のエディション Enterprise Enterprise Enterprise Enterprise、Standard Enterprise、Standard
Windows Server のバージョン 2016 以降 2016 以降 2016 以降 All All
クラスターを自動作成 はい はい はい いいえ いいえ
可用性グループとリスナーを自動的に作成する はい いいえ いいえ いいえ いいえ
リスナーとロード バランサーを別々に作成 該当なし いいえ いいえ はい なし
この方法を使用して DNN リスナーを作成可能 該当なし いいえ いいえ はい なし
WSFC クォーラムの構成 クラウド監視 クラウド監視 クラウド監視 All All
複数のリージョンを使用した DR いいえ いいえ いいえ はい はい
マルチサブネットのサポート はい いいえ いいえ 該当なし はい
既存の AD のサポート はい はい はい はい はい
同一リージョン内の複数のゾーンを使用した DR はい はい はい はい はい
AD なしの分散型 AG いいえ いいえ いいえ はい はい
クラスターなしの分散型 AG いいえ いいえ いいえ はい はい
ロード バランサーまたは DNN が必要 いいえ はい はい はい いいえ

次の手順

開始するには、HADR のベスト プラクティスを確認し、可用性グループのチュートリアルを使用して可用性グループを手動でデプロイします。

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