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

適用対象:Azure VM 上の SQL Server

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

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

概要

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

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

VM の冗長性

冗長性と高可用性を高めるために、SQL Server VM は同じ 可用性セット または異なる 可用性ゾーンに存在する必要があります。

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

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

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

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

接続

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

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

ほとんどの SQL Server 機能は、DNN を使用するときに可用性グループと透過的に連携しますが、特別な考慮事項が必要な特定の機能があります。 詳細については、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;

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

• SQL Server Native Client での接続文字列キーワードの使用
• データベース ミラーリング セッションへのクライアントの接続 (SQL Server)
• ハイブリッド IT での可用性グループ リスナーへの接続
• 可用性グループ リスナー、クライアント接続、およびアプリケーションのフェールオーバー (SQL Server)
• 可用性グループでのデータベース ミラーリング接続文字列の使用

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

従来のオンプレミスの 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 を追加する必要がなくなるためです。

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

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

デプロイ オプション

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

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

関連コンテンツ

• HADR 構成のベスト プラクティス (Azure VM 上の SQL Server)
• チュートリアル: 複数のサブネットの可用性グループの前提条件 (Azure VM 上の SQL Server)
• Windows Server フェールオーバー クラスターと Azure VM 上の SQL Server
• AlwaysOn 可用性グループの概要