この記事では、高可用性とディザスター リカバリー (HADR) のために Azure 仮想マシン (VM) 上の SQL Server で Windows Server フェールオーバー クラスター機能を使用する場合の違いについて説明します。 常時オンの可用性グループ (AG) またはフェールオーバー クラスター インスタンス (FCI) など。
Windows の機能自体の詳細については、Windows Server フェールオーバー クラスターのドキュメントを参照してください。
概要
Always On 可用性グループ (AG) やフェールオーバー クラスター インスタンス (FCI) など、Windows 上の SQL Server 高可用性ソリューションは、基盤となる Windows Server フェールオーバー クラスタリング (WSFC) サービスに依存しています。
クラスター サービスにより、ネットワーク接続とクラスター内のノードの正常性が監視されます。 この監視は、可用性グループやフェールオーバー クラスター インスタンス機能の一部として SQL Server によって行われる正常性チェックに加えて行われます。 クラスター サービスがノードに到達できない場合、またはクラスター内の AG または FCI ロールが正常ではなくなった場合、クラスター サービスによって適切な回復の操作が開始され、アプリケーションとサービスが回復され、クラスター内の同じノードまたは別のノードでオンラインになります。
クラスターの正常性の監視
高可用性を実現するには、クラスター ソリューションを構成するさまざまなコンポーネントの正常性を確保する必要があります。 クラスター サービスは、障害を検出して対応するために、いくつかのシステムおよびネットワーク パラメーターを監視してクラスターの正常性を評価します。
障害への迅速な対応と誤作動の回避のバランスを取るには、障害を宣言するためのしきい値を設定することが重要です。
監視には 2 つの戦略があります。
| 監視 | 説明 |
|---|---|
| Aggressive | ハード エラーを迅速に検出して回復することで、最高レベルの可用性を実現します。 クラスター サービスと SQL Server はどちらも一時的な障害をあまり許しません。また、一時的な障害が発生した場合、リソースが途中でフェールオーバーされる場合があります。 障害が検出されると、次の是正措置に時間がかかる場合があります。 |
| 緩和 | 一時的なネットワークの問題に対する許容度が高く、より寛容な障害検出を指定します。 一時的な障害は回避されますが、本当の意味での障害検出が遅れるリスクもあります。 |
クラウド内のクラスター環境で積極的に設定すると、早期障害や長時間の停止につながる可能性があるため、Azure VM 上のフェールオーバー クラスターには緩やかな監視戦略をお勧めします。 しきい値設定の調整の詳細については、クラスターのベスト プラクティスに関するページを参照してください。
クラスター ハートビート
ノード間のクラスター ハートビートと正常性検出に影響する主な設定です。
| 設定 | 説明 |
|---|---|
| 遅延 | ノード間でクラスター ハートビートを送信する頻度を定義します。 延期期間は、次のハートビートが送信されるまでの秒数です。 同じクラスター内では、同じサブネット上のノード間、および異なるサブネット上にあるノード間で、異なる遅延設定が構成される場合があります。 |
| しきい値 | しきい値は、クラスターによって回復の操作が行われるまでに許容できるハートビート数です。 同じクラスター内では、同じサブネット上のノード間、および異なるサブネット上のノード間で異なるしきい値設定を構成できます。 |
これらの設定の既定値は、クラウド環境では低すぎる可能性があり、一時的なネットワークの問題が原因で不要なエラーが発生する可能性があります。 許容度を高くするには、Azure VM のフェールオーバー クラスターに緩やかなしきい値設定を使用します。 詳細については、クラスターのベスト プラクティスに関するページを参照してください。
Quorum
2 ノード クラスターは クォーラム リソースなしで機能できますが、お客様は、運用環境のサポートを受けるためにクォーラム リソースを使用する必要があります。 クラスターの検証で、クォーラム リソースを使用していないクラスターが合格することはありません。
技術的には、3 ノード クラスターの場合、クォーラム リソースなしでも 1 つのノードの損失 (2 ノードにダウンします) を乗り切ることができます。 しかし、クラスターが 2 ノードまで下がると、ノードが失われたりノード間に通信エラーが発生したりした場合、スプリットブレイン シナリオを防ぐために、クラスター化されたリソースがオフラインになるリスクがあります。 クォーラム リソースを構成すると、クラスター リソースを 1 つのノードのみでオンラインに維持できます。
ディスク監視は、最も回復性の高いクォーラム オプションです。 ただし、Azure VM 上の SQL Server でディスク監視を使用するには、Azure 共有ディスクを使用する必要があります。この場合、高可用性ソリューションにいくつかの制限が課されます。 そのため、Azure 共有ディスクを使用してフェールオーバー クラスター インスタンスを構成する場合は、ディスク監視を使用します。それ以外の場合は、可能な限りクラウド監視を使用します。
次の表は、Azure VM 上の SQL Server で使用できるクォーラム オプションの一覧です。
| クラウド監視 | ディスク監視 | ファイル共有監視 | |
|---|---|---|---|
| サポートされる OS | Windows Server 2016 以降 | All | All |
| 説明 | クラウド監視はフェールオーバー クラスターのクォーラム監視の一種であり、Microsoft Azure を使用してクラスター クォーラムでの投票が提供されます。 既定のサイズは約 1 MB で、タイム スタンプだけが含まれます。 クラウド監視は、複数のサイト、複数のゾーン、および複数のリージョンでのデプロイに最適です。 共有ストレージを備えたフェールオーバー クラスター ソリューションを使用している場合を除き、可能な限りクラウド監視を使用してください。 | ディスク監視は、クラスターの使用可能記憶域グループ内にある小規模なクラスター化されたディスクです。 このディスクは可用性が高く、ノード間でフェールオーバーできます。 クラスター データベースのコピーが含まれ、既定のサイズは 1 GB 未満です。 ディスク監視は、Azure 共有ディスク (または共有 SCSI、iSCSI、ファイバー チャネル SAN などの共有ディスク ソリューション) を使用するすべてのクラスターに最適なクォーラム オプションです。 クラスター化された共有ボリュームをディスク監視として使用することはできません。 Azure 共有ディスクをディスク監視として構成します。 | ファイル共有監視は、通常 Windows Server を実行しているファイル サーバー上で構成される SMB ファイル共有です。 クラスタリング情報は witness.log ファイルに保持されますが、クラスター データベースのコピーは格納されません。 Azure では、同じ仮想ネットワーク内の別の仮想マシンにファイル共有を構成することができます。 ディスク監視やクラウド監視を使用できない環境では、ファイル共有監視を使用します。 |
概要については、クラスター クォーラムの構成に関するページを参照してください。
仮想ネットワーク名 (VNN)
可用性グループ リスナーまたはフェールオーバー クラスター インスタンスに接続するためのオンプレミス エクスペリエンスに一致するよう、SQL Server VM を同じ仮想ネットワーク内の複数のサブネットにデプロイします。 複数のサブネットを使用すると、トラフィックを HADR ソリューションにルーティングするために Azure Load Balancer にさらに依存する必要がなくなります。 詳細については、複数サブネットの AG および複数サブネットの FCI に関するページを参照してください。
従来のオンプレミス環境の場合、フェールオーバー クラスター インスタンスや Always On 可用性グループなどのクラスター化されたリソースは、トラフィックを適切なターゲット (フェールオーバー クラスター インスタンス、または Always On 可用性グループのリスナー) にルーティングするために、仮想ネットワーク名に依存しています。 仮想名は、DNS 内の IP アドレスをバインドします。 現在リソースを所有しているノードに関係なく、クライアントは仮想名または IP アドレスを使用して高可用性ターゲットに接続できます。 VNN は、クラスターによって管理されるネットワークの名前とアドレスであり、フェールオーバー イベントの発生時にネットワーク アドレスはクラスター サービスによってノード間で移動されます。 障害が発生すると、アドレスは元のプライマリ レプリカではオフラインになり、新しいプライマリ レプリカではオンラインになります。
1 つのサブネット内の Azure Virtual Machines では、クライアントからクラスター化されたリソースの仮想ネットワーク名 (フェールオーバー クラスター インスタンス、または可用性グループのリスナー) にトラフィックをルーティングするために、別のコンポーネントが必要です。 Azure 内のロード バランサーには、クラスター化された SQL Server リソースが依存する VNN の IP アドレスが保持されるため、適切な高可用ターゲットにトラフィックをルーティングするために必要です。 また、ロード バランサーによって、ネットワーク コンポーネントの障害が検出され、アドレスが新しいホストに移動されます。
ロード バランサーでは、フロント エンドに到着する受信フローが分散され、バックエンド プールによって定義されたインスタンスにそのトラフィックがルーティングされます。 トラフィック フローを構成するには、負荷分散規則と正常性プローブを使用します。 SQL Server FCI の場合、バックエンド プール インスタンスは SQL Server を実行する Azure 仮想マシンであり、可用性グループの場合、バックエンド プールはリスナーのプライマリ レプリカになることができる Azure Virtual Machinesです。 正常性プローブは既定で 10 秒ごとにライブ チェックを実行するため、ロード バランサーを使用している場合は、わずかなフェールオーバー遅延が発生します。
開始するには、 フェールオーバー クラスター インスタンス または 可用性グループに対して Azure Load Balancer を構成する方法について説明します。
サポートされる OS:All
サポートされる SQL バージョン:All
サポートされる HADR ソリューション:フェールオーバー クラスター インスタンス、可用性グループ
VNN の構成は煩雑になり、障害の原因が増え、障害検出の遅延が発生する可能性があり、別のリソースの管理に関連するオーバーヘッドとコストが発生する可能性があります。 このような制限の一部に対処するために、SQL Server には分散ネットワーク名機能のサポートが導入されました。
分散ネットワーク名 (DNN)
可用性グループ リスナーまたはフェールオーバー クラスター インスタンスに接続するためのオンプレミス エクスペリエンスに一致するよう、SQL Server VM を同じ仮想ネットワーク内の複数のサブネットにデプロイします。 複数のサブネットを使用すると、トラフィックを HADR ソリューションにルーティングするために DNN にさらに依存する必要がなくなります。 詳細については、複数サブネットの AG および複数サブネットの FCI に関するページを参照してください。
1 つのサブネットにデプロイされる SQL Server VM に関しては、分散ネットワーク名機能は、ロード バランサーを使用せずに SQL Server クライアントから SQL Server フェールオーバー クラスター インスタンスまたは可用性グループ リスナーに接続するための代替手段となりました。 DNN 機能は、Windows Server 2016 以降の SQL Server 2016 SP3、SQL Server 2017 CU25、SQL Server 2019 CU8 以降で使用できます。
DNN リソースを作成すると、クラスターではその DNS 名がクラスター内のすべてのノードの IP アドレスにバインドされます。 クライアントは、この一覧の各 IP アドレスに接続して、接続先のリソースを見つけようとします。 接続文字列に MultiSubnetFailover=True を指定することで、このプロセスを高速化できます。 この設定によって、プロバイダーはすべての IP アドレスを並行して試行するように指示されるので、クライアントから FCI またはリスナーへの瞬時の接続ができるようになります。
次の理由により、可能な場合は、ロード バランサーよりも優先して分散ネットワーク名を使用することをお勧めします。
- ロード バランサーのリソースを維持する必要がなくなるため、エンド ツー エンド ソリューションはより堅牢になります。
- ロード バランサー プローブが削除されると、フェールオーバー期間は最小限に抑えられます。
- DNN を使用すると、Azure VM 上の SQL Server を使用するフェールオーバー クラスター インスタンスまたは可用性グループ リスナーのプロビジョニングと管理が簡単になります。
ほとんどの SQL Server 機能は、DNN を使用する際に FCI と可用性グループと透過的に連携しますが、特別な考慮事項が必要な特定の機能があります。
サポートされる OS:Windows Server 2016 以降
サポートされる SQL バージョン:SQL Server 2019 CU2 (FCI) と SQL Server 2019 CU8 (AG)
サポートされる HADR ソリューション:フェールオーバー クラスター インスタンス、可用性グループ
まず、フェールオーバー クラスター インスタンスまたは可用性グループ用に分散ネットワーク名リソースを構成する方法について説明します。
DNN を他の SQL Server 機能と共に使用する場合は、さらに考慮事項があります。 詳細については、 FCI と DNN の相互運用性とAG と DNN の相互運用性に関するページを参照してください。
Note
同じクラスター上の各可用性グループまたはフェールオーバー クラスター インスタンスには、VNN リスナーでも DNN リスナーでも、独自の独立した接続ポイントが必要です。
回復の操作
障害が検出されると、クラスター サービスによって是正措置がとられます。 このアクションでは、既存のノードのリソースを再起動したり、リソースを別のノードにフェールオーバーしたりできます。 是正措置が開始されると、完了するまでに時間がかかります。
たとえば、再起動された可用性グループは、次の順序でオンラインになります。
- リスナーの IP がオンラインになる
- リスナーのネットワーク名がオンラインになる
- 可用性グループがオンラインになる
- 個々のデータベースは復旧を行います。これは、再実行ログの長さなど、いくつかの要因に応じて時間がかかる場合があります。 リスナーは、データベースが完全に復旧されるまで接続をルーティングしません。 詳細については、「フェールオーバー時間 (RTO) の推定」を参照してください。
回復には時間がかかる可能性があるため、20 秒以内に障害を検出するように設定された積極的な監視の場合、一時的なイベント (メモリを保持する Azure VM のメンテナンスなど) が発生した場合、数分間の停止が発生する可能性があります。 監視をより緩やかな値である 40 秒に設定することで、より長いサービスの中断を回避することができます。
しきい値の設定を調整するには、 クラスターのベスト プラクティス に関する詳細を参照してください。
ノードの場所
Azure 内の仮想マシン上の Windows クラスター内のノードは、同じ Azure リージョン内で物理的に分離されているか、異なるリージョンに存在する可能性があります。 この距離では、クラスター ノードを独自の施設内の場所間に分散する場合と同様に、ネットワーク待ち時間が発生する可能性があります。 クラウド環境では、リージョン内でノード間の距離を認識できない可能性がある点が異なります。 さらに、物理コンポーネントと仮想コンポーネント、ホップ数などの他の要因も、待機時間の増加につながる可能性があります。 ノード間の待機時間が気になる場合は、クラスターのノードを近接配置グループ内に配置し、ネットワークの近接性を確保することを検討してください。
リソース制限
Azure VM を構成する際には、CPU、メモリ、IO のコンピューティング リソースの制限を決定します。 購入した Azure VM よりも多くのリソースを必要とするワークロードやディスクの制限により、VM のパフォーマンスの問題が発生する可能性があります。 パフォーマンスが低下すると、クラスター サービスまたは SQL Server の高可用性機能の正常性チェックが失敗する可能性があります。 リソースのボトルネックにより、ノードまたはリソースがクラスターまたは SQL Server に表示されることがあります。
集中的な SQL IO 操作やメンテナンス操作 (バックアップ、インデックス、統計のメンテナンスなど) により、VM またはディスクが IOPS または MBPS のスループット制限に達し、IsAlive または LooksAlive チェックに対して SQL Server が応答しなくなることがあります。
SQL Server で予期しないフェールオーバーが発生している場合は、すべての パフォーマンスのベスト プラクティス に従っていることを確認し、ディスクレベルまたは VM レベルの上限についてサーバーを監視します。
Azure プラットフォームのメンテナンス
他のクラウド サービスと同様に、Azure では、定期的にそのプラットフォームを更新して、仮想マシンのホスト インフラストラクチャの信頼性、パフォーマンス、セキュリティの向上に努めています。 これらの更新の目的は、ホスティング環境のソフトウェア コンポーネントの修正から、ネットワーク コンポーネントのアップグレード、ハードウェアの使用停止まで、広い範囲に及びます。
ほとんどのプラットフォーム更新は、お客様の VM に影響しません。 影響を及ぼさない更新が不可能な場合、Azure は、お客様の VM への影響が最小となる更新メカニズムを選択します。 影響がゼロではないメンテナンスでは、ほとんどの場合、VM の一時停止は 10 秒未満です。 場合によっては、Azure はメモリ保持メンテナンスのメカニズムを使用します。 これらのメカニズムでは、最大 30 秒間 VM が一時停止され、RAM 内のメモリが保持されます。 その後、VM が再開され、クロックが自動的に同期されます。
メモリ保持メンテナンスは、Azure VM の 90% 以上で機能します。 G、M、N、および H シリーズでは機能しません。 Azure では、ライブ マイグレーション テクノロジの使用を拡大すると共に、一時停止期間を短縮するためにメモリ保持メンテナンス メカニズムの改善に取り組んでいます。 VM を別のホストにライブ移行する場合、影響を受けやすい一部のワークロード (SQL Server など) では、VM の一時停止に至るまでの数分間にわずかなパフォーマンスの低下が見られることがあります。
プラットフォームのメンテナンス中にリソースのボトルネックが発生すると、AG または FCI がクラスター サービスに表示されることがあります。 詳細については、この記事の リソース制限に関する セクションを参照してください。
積極的なクラスター監視を使用している場合は、拡張 VM の一時停止によってフェールオーバーがトリガーされる可能性があります。 多くの場合、フェールオーバーはメンテナンスの一時停止よりも多くのダウンタイムを引き起こします。 そのため、VM がメンテナンスのために一時停止されている間にフェールオーバーがトリガーされないように、緩やかな監視を使用することをお勧めします。 Azure VM でのクラスターのしきい値の設定の詳細については、クラスターの ベスト プラクティスを参照してください。
制限事項
FCI または可用性グループと Azure Virtual Machines 上の SQL Server を使用する場合は、次の制限事項を考慮してください。
MSDTC
Azure 仮想マシンでは、Windows Server 2019 の Microsoft 分散トランザクション コーディネーター (MSDTC) と、クラスター化共有ボリューム (CSV) と Azure Standard Load Balancer 上のストレージ、または Azure 共有ディスクを使用している SQL Server VM がサポートされます。
Azure Virtual Machines では、次の理由により、クラスター共有ボリュームを使用する Windows Server 2016 以前では、MSDTC はサポートされません。
- クラスター化された MSDTC リソースは、共有ストレージを使用するように構成することはできません。 Windows Server 2016 では、MSDTC リソースを作成した場合、記憶域が使用可能な場合でも、使用可能な共有記憶域は表示されません。 この問題は、Windows Server 2019 で修正されました。
- Basic Load Balance は、RPC ポートを処理しません。