Windows Server フェールオーバー クラスターと Azure VM 上の SQL Server
この記事では、高可用性とディザスター リカバリー (HADR) のために Azure VM 上の SQL Server と共に Windows Server フェールオーバー クラスター機能を使用した場合の違い (Always On の可用性グループ (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 上のフェールオーバー クラスターでは、緩やかな監視戦略をお勧めします。 しきい値設定の調整の詳細については、クラスターのベスト プラクティスに関するページを参照してください。
クラスター ハートビート
ノード間のクラスター ハートビートと正常性検出に影響する主な設定です。
| 設定 | 説明 |
|---|---|
| 遅延 | ノード間でクラスター ハートビートを送信する頻度を定義します。 延期期間は、次のハートビートが送信されるまでの秒数です。 同じクラスター内でも、同じサブネット上のノード間と、異なるサブネット上のノード間に、異なる延期期間設定を構成できます。 |
| Threshold | しきい値は、クラスターによって回復の操作が行われるまでに許容できるハートビート数です。 同じクラスター内でも、同じサブネット上のノード間と、異なるサブネット上のノード間に、異なるしきい値設定を構成できます。 |
これらの設定の既定値は、クラウド環境には低すぎる場合があります。また、一時的なネットワークの問題が原因で、不要な障害が発生する可能性があります。 許容度を高くするには、Azure VM のフェールオーバー クラスターに緩やかなしきい値設定を使用します。 詳細については、クラスターのベスト プラクティスに関するページを参照してください。
Quorum
2 ノード クラスターはクォーラム リソースなしでも機能しますが、実稼働サポートを受けるにはクォーラム リソースを使用することが必須です。 クラスターの検証で、クォーラム リソースを使用していないクラスターが合格することはありません。
技術的には、3 ノード クラスターの場合、クォーラム リソースなしでも 1 つのノードの損失 (2 ノードにダウンします) を乗り切ることができます。 しかし、クラスターが 2 ノードまで下がると、ノードが失われたりノード間に通信エラーが発生したりした場合、スプリットブレイン シナリオを防ぐために、クラスター化されたリソースがオフラインになるリスクがあります。 クォーラム リソースを構成することで、1 つのノードのみをオンラインにしてクラスター リソースのオンラインを維持できます。
ディスク監視は最も回復性の高いクォーラム オプションですが、Azure VM 上の SQL Server でディスク監視を使用するには、高可用性ソリューションにいくつかの制限を課す Azure 共有ディスクを使用する必要があります。 そのため、Azure 共有ディスクを使用してフェールオーバー クラスター インスタンスを構成する場合は、ディスク監視を使用します。それ以外の場合は、可能な限りクラウド監視を使用します。
次の表は、Azure VM 上の SQL Server で使用できるクォーラム オプションの一覧です。
| クラウド監視 | ディスク監視 | ファイル共有監視 | |
|---|---|---|---|
| サポートされる OS | Windows Server 2016 以降 | 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 仮想マシンであり、可用性グループの場合、バックエンド プールはリスナーです。 ロード バランサーを使用している場合は、フェールオーバーにわずかな遅延が発生します。正常性プローブでは、既定で 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 を使用するフェールオーバー クラスター インスタンスまたは可用性グループ リスナーのプロビジョニングと管理が簡単になります。
DNN を使用すると、ほとんどの SQL Server 機能は FCI と可用性グループに対して透過的に機能しますが、特定の機能については、特別な考慮が必要となる場合があります。
サポートされる OS:Windows Server 2016 以降
サポートされる SQL バージョン: SQL Server 2019 CU2 (FCI) と SQL Server 2019 CU8 (AG)
サポートされる HADR ソリューション: フェールオーバー クラスター インスタンス、可用性グループ
まず、フェールオーバー クラスター インスタンスまたは可用性グループ用に分散ネットワーク名リソースを構成する方法について説明します。
DNN を他の SQL Server の機能と併用する場合には、さらに考慮すべき点があります。 詳細については、FCI と DNN の相互運用性に関するページと、AG と DNN の相互運用性に関するページを参照してください。
回復の操作
障害が検出されると、クラスター サービスによって是正措置がとられます。 これにより、既存のノード上のリソースが再起動されたり、リソースが別のノードにフェールオーバーされたりする可能性があります。 是正措置が開始されると、完了するまでに時間がかかります。
たとえば、再起動された可用性グループは、次の順序でオンラインになります。
- リスナーの IP がオンラインになる
- リスナーのネットワーク名がオンラインになる
- 可用性グループがオンラインになる
- 個々のデータベースで回復が実行されますが、redo ログの長さなど、さまざまな要因によって時間がかかることがあります。 接続は、データベースが完全に回復された後にのみ、リスナーによってルーティングされます。 詳細については、「フェールオーバー時間 (RTO) の推定」を参照してください。
回復には時間がかかる可能性があるため、20 秒以内に障害を検出するように設定された積極的な監視の場合、一時的なイベント (メモリを保持する Azure VM のメンテナンスなど) が発生した場合、数分間の停止が発生する可能性があります。 監視をより緩やかな値である 40 秒に設定することで、より長いサービスの中断を回避することができます。
しきい値設定の調整の詳細については、クラスターのベスト プラクティスに関するページを参照してください。
ノードの場所
Azure 内の仮想マシン上にある Windows クラスターのノードは、同じ Azure リージョン内で物理的に分離されている場合もあれば、異なるリージョンに配置されている場合もあります。 このような距離があると、クラスターのノードが自社施設内の複数の場所に分散している場合と同じように、ネットワークの待機時間が発生する可能性があります。 クラウド環境の場合、1 つのリージョン内ではノード間の距離に気付かない可能性があるという違いがあります。 さらに、物理コンポーネントと仮想コンポーネント、ホップ数などの他の要因も、待機時間の増加につながる可能性があります。 ノード間の待機時間が気になる場合は、クラスターのノードを近接配置グループ内に配置し、ネットワークの近接性を確保することを検討してください。
リソース制限
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 Virtual Machines では、クラスター共有ボリューム (CSV) と Azure Standard Load Balancer 上のストレージを使用する Windows Server 2019、または Azure 共有ディスクを使用する SQL Server VM で、Microsoft 分散トランザクション コーディネーター (MSDTC) がサポートされます。
Azure Virtual Machines では、次の理由により、クラスター共有ボリュームを使用する Windows Server 2016 以前では、MSDTC はサポートされません。
- クラスター化された MSDTC リソースは、共有ストレージを使用するように構成することはできません。 Windows Server 2016 では、MSDTC リソースを作成した場合、ストレージが使用可能であっても、使用可能な共有ストレージは 1 つも表示されません。 この問題は、Windows Server 2019 で修正済みです。
- Basic Load Balance は、RPC ポートを処理しません。
次のステップ
Azure VM 上の SQL Server と共に Windows フェールオーバー クラスターを使用する場合の違いについて学習したので、次は高可用性の機能である可用性グループまたはフェールオーバー クラスター インスタンスについて学習します。 始める準備ができたら、推奨される構成に関するベスト プラクティスを必ず確認してください。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示