HADR 構成のベスト プラクティス (Azure VM 上の SQL Server)

適用対象: Azure VM 上の SQL Server

Azure Virtual Machines (VM) 上の SQL Server を使用して高可用性とディザスター リカバリー (HADR) を実現するには、Windows Server フェールオーバー クラスターが使用されます。

この記事では、フェールオーバー クラスター インスタンス (FCI) と可用性グループの両方について、それらを Azure VM 上の SQL Server と共に使用する場合のクラスター構成のベスト プラクティスについて説明します。

詳しくは、このシリーズの他の記事 (チェックリスト、VM のサイズ、ストレージ、セキュリティ、HADR の構成、ベースラインの収集) をご覧ください。

チェック リスト

次のチェックリストを参照して、この記事の残りの部分で詳しく説明されている HADR のベスト プラクティスの概要を確認してください。

高可用性とディザスター リカバリー (HADR) 機能 (Always On 可用性グループやフェールオーバー クラスター インスタンスなど) は、基盤となる Windows Server フェールオーバー クラスター テクノロジに依存しています。 クラウド環境への対応を強化するように HADR 設定を変更するためのベスト プラクティスを確認してください。

Windows クラスターの場合は、次のベスト プラクティスについて検討します。

• Azure Load Balancer または分散ネットワーク名 (DNN) に依存しなくても HADR ソリューションにトラフィックをルーティングできるよう、可能な限り SQL Server VM を複数のサブネットにデプロイします。
• 一時的なネットワーク障害や Azure プラットフォーム メンテナンスによって予期しない停止が起こらないよう、クラスターを変更してパラメーターを緩和します。 詳細については、ハートビートとしきい値の設定に関する記事を参照してください。 Windows Server 2012 以降の場合は、次の推奨値を使用します。
  • SameSubnetDelay: 1 秒
  • SameSubnetThreshold: 40 ハートビート
  • CrossSubnetDelay: 1 秒
  • CrossSubnetThreshold: 40 ハートビート
• VM は可用性セットまたは別の可用性ゾーンに配置します。 詳細については、「VM の可用性の設定」を参照してください。
• クラスター ノードごとに 1 つの NIC を使用します。
• 3 つ以上の奇数の投票を使用するように、クラスターのクォーラム投票を構成します。 投票は DR リージョンに割り当てないでください。
• リソースの制約による予期しない再起動やフェールオーバーが発生しないように、リソース制限を慎重に監視します。
  • OS、ドライバー、SQL Server が最新のビルドになっていることを確認します。
  • Azure VM 上での SQL Server のパフォーマンスを最適化します。 詳細については、この記事の他のセクションを参照してください。
  • リソース制限に達しないように、ワークロードを削減または分散します。
  • 制約を回避するために、より制限の高い VM またはディスクに移行します。

SQL Server の可用性グループまたはフェールオーバー クラスター インスタンスの場合は、こちらのベスト プラクティスを検討してください。

• 予期しないエラーが頻繁に発生する場合は、この記事の残りの部分で説明されているパフォーマンスのベスト プラクティスに従ってください。
• SQL Server VM のパフォーマンスを最適化しても予期しないフェールオーバーが解決されない場合は、可用性グループまたフェールオーバー クラスター インスタンスの監視を緩和することを検討してください。 ただし、そうすることで問題の根底にある原因に対処できない場合があり、障害の可能性を減らすことで症状が表に現れない可能性があります。 その場合でも、根底にある根本原因を調査して対処しなければならない場合があります。 Windows Server 2012 以降の場合は、次の推奨値を使用します。
  • リース タイムアウト: こちらの式を使用して、リース タイムアウトの最大値を計算します。
    Lease timeout < (2 * SameSubnetThreshold * SameSubnetDelay)。
    40 秒から始めます。 先ほど推奨した緩和されている SameSubnetThreshold と SameSubnetDelay の値を使用している場合は、リース タイムアウト値が 80 秒を超えないようにしてください。
  • 指定した期間の最大エラー数: この値は 6 に設定します。
• 仮想ネットワーク名 (VNN) と Azure Load Balancer を使用して HADR ソリューションに接続する場合は、お使いのクラスターが 1 つのサブネットにしかまたがっていない場合でも、接続文字列に MultiSubnetFailover = true を指定します。
  • クライアントで MultiSubnetFailover = True がサポートされていない場合は、RegisterAllProvidersIP = 0 および HostRecordTTL = 300 を設定して、クライアント資格情報をより短期間だけキャッシュすることが必要になる可能性があります。 ただし、そうすることで、DNS サーバーに対して追加のクエリが発生する場合があります。

• 分散ネットワーク名 (DNN) を使用して HADR ソリューションに接続する場合は、以下の注意点があります。
  • MultiSubnetFailover = True をサポートするクライアント ドライバーを使用する必要があります。このパラメーターは接続文字列に含める必要があります。
  • 可用性グループの DNN リスナーに接続するときに、接続文字列内の一意の DNN ポートを使用します。
• 基本の可用性グループのデータベース ミラーリング接続文字列を使用して、ロード バランサーまたは DNN の必要性をなくします。
• 高可用性ソリューションをデプロイする前に VHD のセクター サイズを検証して、I/O の不整合を回避します。 詳細については、KB3009974 を参照してください。
• SQL Server データベース エンジン、Always On 可用性グループ リスナー、またはフェールオーバー クラスター インスタンスの正常性プローブが 49,152 から65,536 の間のポート (TCP/IP の既定の動的ポート範囲) を使うように構成されている場合は、各ポートの除外を追加します。 このようにすると、他のシステムが同じポートを動的に割り当てるのを防ぐことができます。 次の例では、ポート 59999 の除外を作成します。
  netsh int ipv4 add excludedportrange tcp startport=59999 numberofports=1 store=persistent

HADR チェックリストを他のベスト プラクティスと比べるには、総合的なパフォーマンスのベスト プラクティスのチェックリストをご覧ください。

VM 可用性設定

ダウンタイムの影響を軽減するために、次に示す VM の最適な可用性設定を検討してください。

• 近接配置グループを高速ネットワークと共に使用して、最短の待ち時間を実現します。
• 仮想マシンのクラスター ノードの配置場所を、別々の可用性ゾーン内にしてデータセンターレベルの障害から保護するか、1 つの可用性セット内にして同じデータセンター内で低遅延冗長性を確保します。
• 可用性セット内の VM では、Premium マネージド OS およびデータ ディスクを使用します。
• 各アプリケーション層に対して別々の可用性セットを構成します。

Quorum

2 ノード クラスターはクォーラム リソースなしでも機能しますが、実稼働サポートを受けるにはクォーラム リソースを使用することが必須です。 クラスターの検証で、クォーラム リソースを使用していないクラスターが合格することはありません。

技術的には、3 ノード クラスターは、クォーラム リソースがなくても 1 つのノードの損失 (2 ノードまでのダウン) に耐えることができますが、クラスターが 2 ノードまでダウンした後で、さらに別のノードの損失または通信障害が発生した場合は、クラスター化されたリソースがオフラインになり、スプリット ブレイン シナリオが妨げられるというリスクがあります。 クォーラム リソースを構成することで、1 つのノードのみをオンラインにしてクラスターのオンラインを続行できます。

ディスク監視は最も回復性の高いクォーラム オプションですが、Azure VM 上の SQL Server でディスク監視を使用するには、高可用性ソリューションにいくつかの制限を課す Azure 共有ディスクを使用する必要があります。 そのため、Azure 共有ディスクを使用してフェールオーバー クラスター インスタンスを構成する場合は、ディスク監視を使用します。それ以外の場合は、可能な限りクラウド監視を使用します。

次の表は、Azure VM 上の SQL Server で使用できるクォーラム オプションの一覧です。

• クラウド監視は、複数のサイト、複数のゾーン、複数のリージョンでのデプロイに最適です。 共有ストレージ クラスター ソリューションを使用している場合を除き、可能な限りクラウド監視を使用してください。
• ディスク監視は、最も回復性に優れたクォーラム オプションであり、Azure 共有ディスク (または共有 SCSI、iSCSI、ファイバー チャネル SAN などの共有ディスク ソリューション) を使用するすべてのクラスターに最適です。 クラスター共有ボリュームをディスク監視として使用することはできません。
• ファイル共有監視は、ディスク監視とクラウド監視がオプションとして使用できない場合に適しています。

概要については、クラスター クォーラムの構成に関するページを参照してください。

クォーラム投票

Windows Server フェールオーバー クラスターに参加しているノードのクォーラム投票を変更することができます。

ノードの投票設定を変更するときは、これらのガイドラインに従ってください。

接続性

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

HADR ソリューションを簡素化するには、可能な限り、SQL Server VM を複数のサブネットにデプロイします。 詳細については、複数サブネットの AG および複数サブネットの FCI に関するページを参照してください。

SQL Server VM が 1 つのサブネット内にある場合は、フェールオーバー クラスター インスタンスと可用性グループ リスナーの両方に対して、仮想ネットワーク名 (VNN) と Azure Load Balancer、または分散ネットワーク名 (DNN) のいずれかを構成できます。

推奨されている接続オプションは、分散ネットワーク名です (使用可能な場合)。

• ロード バランサーのリソースを維持する必要がなくなるため、エンド ツー エンド ソリューションはより堅牢になります。
• ロード バランサーのプローブを排除すると、フェールオーバー時間を最小限に抑えられます。
• DNN を使用すると、Azure VM 上の SQL Server を使用するフェールオーバー クラスター インスタンスまたは可用性グループ リスナーのプロビジョニングと管理が簡単になります。

次の制限が適用されます。

• クライアント ドライバーで MultiSubnetFailover=True パラメーターがサポートされている必要があります。
• DNN 機能は、Windows Server 2016 以降の SQL Server 2016 SP3、SQL Server 2017 CU25、SQL Server 2019 CU8 以降で使用できます。

詳細については、Windows Server フェールオーバー クラスターの概要に関するページを参照してください。

接続を構成するには、次の記事を参照してください。

• 可用性グループ: DNN を構成する、VNN を構成する
• フェールオーバー クラスター インスタンス: DNN を構成する、VNN を構成する

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

ハートビートとしきい値

クラスターのハートビートとしきい値の設定を、緩和した設定に変更します。 既定のハートビートとしきい値のクラスター設定は、高度にチューニングされたオンプレミス ネットワーク用に設計され、クラウド環境で待機時間が長くなる可能性は考慮されていません。 ハートビート ネットワークは UDP 3343 で維持されています。これは従来、TCP よりはるかに信頼性が低く、不完全な会話が発生しやすくなっています。

そのため、Azure VM 高可用性ソリューションで SQL Server のクラスター ノードを実行する場合は、より緩和した監視状態にクラスター設定を変更して、ネットワークの待機時間や障害の可能性の増加、Azure メンテナンス、またはリソースのボトルネックの発生による一時的な障害を回避します。

遅延としきい値の設定は、全体的な正常性検出に累積的な影響を与えます。 たとえば、復旧を行う前に、2 秒ごとにハートビートを送信するように CrossSubnetDelay を設定し、CrossSubnetThreshold を 10 回のハートビート失敗に設定していると、復旧アクションが実行されるまでにクラスターで可能なネットワーク許容値の合計は 20 秒になります。 一般に、ハートビートを頻繁に送信し続ける一方で、しきい値を大きくすることが推奨されています。

一時的な問題に対する許容性を高めながら、正当な停止中に復旧を確実に行うため、遅延としきい値の設定を、次の表に詳しく示す推奨値に緩和してください。

PowerShell を使用してクラスター パラメーターを変更します。

(get-cluster).SameSubnetThreshold = 40
(get-cluster).CrossSubnetThreshold = 40

(get-cluster).SameSubnetThreshold = 10
(get-cluster).CrossSubnetThreshold = 20
(get-cluster).SameSubnetDelay = 2000
(get-cluster).CrossSubnetDelay = 2000

PowerShell を使用して変更を確認します。

get-cluster | fl *subnet*

以下、具体例に沿って説明します。

• この変更は即時に行われ、クラスターやリソースを再起動する必要はありません。
• 同じサブネットの値をクロス サブネットの値より大きくしてはなりません。
• SameSubnetThreshold <= CrossSubnetThreshold
• SameSubnetDelay <= CrossSubnetDelay

お使いのアプリケーション、ビジネス ニーズ、環境に応じて、許容されるダウンタイムの長さおよび是正措置が実行されるまでの期間に基づいて、緩和した値を選択します。 既定の Windows Server 2019 の値を超えることができない場合は、可能な限り、それらと一致させることだけでも試みてください。

参照用として、次の表に既定値の詳細を示します。

詳細については、フェールオーバー クラスター ネットワークのしきい値の調整に関するページを参照してください。

緩和された監視

推奨どおりにクラスターのハートビートとしきい値の設定をチューニングしても許容度が不十分であり、実際の障害ではなく一時的な問題によるフェールオーバーが引き続き発生する場合は、AG または FCI の監視をより緩く構成できます。 一部のシナリオでは、アクティビティのレベルを考慮して、一定の期間、監視を一時的に緩和することが有益な場合があります。 たとえば、データベースのバックアップ、インデックスのメンテナンス、DBCC CHECKDB などの IO 集中型のワークロードを実行している場合は、監視を緩和することができます。アクティビティが完了したら、より厳しい値に監視を設定します。

まず、次のパラメーターを既定値から増やして監視を緩和し、必要に応じて調整します。

Transact-SQL (T-SQL) を使用して、AG と FCI の両方の正常性チェックと失敗の条件を変更します。

可用性グループの場合:

ALTER AVAILABILITY GROUP AG1 SET (HEALTH_CHECK_TIMEOUT =60000);
ALTER AVAILABILITY GROUP AG1 SET (FAILURE_CONDITION_LEVEL = 2);

フェールオーバー クラスター インスタンスの場合:

ALTER SERVER CONFIGURATION SET FAILOVER CLUSTER PROPERTY HealthCheckTimeout = 60000;
ALTER SERVER CONFIGURATION SET FAILOVER CLUSTER PROPERTY FailureConditionLevel = 2;

可用性グループの場合のみ、次の推奨パラメーターから始めて、必要に応じて調整します。

変更を行う前に、次の点を考慮してください。

• タイムアウト値は既定値を下回るほど低くしないでください。
• こちらの式を使用して、リース タイムアウトの最大値を計算しますLease timeout < (2 * SameSubnetThreshold * SameSubnetDelay)。
  40 秒から始めます。 先ほど推奨した緩和されている SameSubnetThreshold と SameSubnetDelay の値を使用している場合は、リース タイムアウト値が 80 秒を超えないようにしてください。
• 同期コミット レプリカの場合、セッション タイムアウトを大きな値に変更すると、HADR_sync_commit 待機が増える場合があります。

リースのタイムアウト

フェールオーバー クラスター マネージャーを使用して、可用性グループのリース タイムアウト設定を変更します。 詳細な手順については、SQL Server 可用性グループのリース正常性チェックに関するドキュメントを参照してください。

セッションのタイムアウト

Transact-SQL (T-SQL) を使用して、可用性グループのセッション タイムアウトを変更します。

ALTER AVAILABILITY GROUP AG1
MODIFY REPLICA ON 'INSTANCE01' WITH (SESSION_TIMEOUT = 20);

指定した期間の最大エラー数

フェールオーバー クラスター マネージャーを使用して、 [指定した期間の最大エラー数] の値を変更します。

1. ナビゲーション ウィンドウの [役割] を選択します。
2. [役割] で、クラスター化されたリソースを右クリックし、 [プロパティ] を選択します。
3. [フェールオーバー] タブを選択し、必要に応じて [指定した期間の最大エラー数] の値を増やします。

リソースの制限

VM またはディスクの制限により、クラスターの正常性に影響を与え、正常性チェックを妨げるリソースのボトルネックが発生するおそれがあります。 リソースの制限に関する問題が発生している場合は、以下を検討してください。

• Azure portal で I/O 分析 (プレビュー) を使用して、フェールオーバーの原因となるディスク パフォーマンスの問題を特定します。
• OS、ドライバー、SQL Server が最新のビルドになっていることを確認します。
• Azure Virtual Machines における SQL Server のパフォーマンス ガイドラインの説明に従って、Azure VM 環境の SQL Server を最適化してください
• 使用
• ワークロードを削減または分散して、リソースの制限を超えることなく使用率を削減してください
• 次のような機会があれば、SQL Server のワークロードを調整します
  • インデックスを追加/最適化する
  • 必要に応じて、可能であればフル スキャンで統計を更新する
  • Resource Governor (SQL Server 2014 enterprise 以降のみ) などの機能を使用して、バックアップやインデックスのメンテナンスなど、特定のワークロード時のリソース使用率を制限する。
• より制限の高い VM またはディスクに移動して、ワークロードの要求を満たす、または超えるようにします。

ネットワーク

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

サーバー (クラスター ノード) ごとに 1 つの NIC を使用します。 Azure ネットワークは物理的な冗長を備えているので、Azure 仮想マシンのゲスト クラスターに NIC を追加する必要はありません。 クラスター検証レポートには、ノードは 1 つのネットワーク上でのみ到達可能であることを警告するメッセージが表示されます。 Azure 仮想マシンのゲスト フェールオーバー クラスターでは、この警告を無視できます。

特定の VM の帯域幅の制限は NIC 間で共有され、NIC を追加しても、Azure VM 上の SQL Server の可用性グループ パフォーマンスは向上しません。 そのため、2 つ目の NIC を追加する必要はありません。

Azure の RFC に準拠していない DHCP サービスにより、特定のフェールオーバー クラスター構成の作成に失敗する可能性があります。 この失敗は、クラスター ネットワーク名に重複する IP アドレス (クラスター ノードの 1 つと同じ IP アドレスなど) が割り当てられていることが原因で発生します。 これは、Windows フェールオーバー クラスター機能に依存する、可用性グループを使用するときに問題になります。

2 ノード クラスターを作成し、オンラインにするシナリオを考えてみましょう。

1. クラスターがオンラインになると、NODE1 によって、クラスター ネットワーク名のために動的に割り当てられた IP アドレスが要求されます。
2. DHCP サービスでは要求が NODE1 自体からのものであることが認識されるため、DHCP サービスで NODE1 自体の IP アドレス以外の IP アドレスは提供されません。
3. NODE1 とフェールオーバー クラスターのネットワーク名の両方に重複するアドレスが割り当てられていることが Windows によって検出されると、既定のクラスター グループはオンラインになることができません。
4. 既定のクラスター グループは NODE2 に移動されます。 NODE2 によって、NODE1 の IP アドレスはクラスター IP アドレスとして処理され、既定のクラスター グループがオンラインになります。
5. NODE2 では、NODE1 との接続を確立しようとするときに、NODE1 の IP アドレスがそれ自体に解決されるため、NODE1 宛てのパケットは NODE2 から送信されません。 NODE2 では NODE1 との接続を確立できず、クォーラムが失われ、クラスターがシャットダウンされます。
6. NODE1 では NODE2 にパケットを送信できますが、NODE2 は応答できません。 NODE1 はクォーラムを失い、クラスターをシャットダウンします。

このシナリオは、クラスター ネットワーク名をオンラインにし、IP アドレスを Azure Load Balancer に追加するために、クラスター ネットワーク名に未使用の静的 IP アドレスを割り当てることによって回避できます。

SQL Server データベース エンジン、Always On 可用性グループ リスナー、フェールオーバー クラスター インスタンスの正常性プローブ、データベース ミラーリング エンドポイント、クラスター コア IP リソース、またはその他の SQL リソースが 49,152 から 65,536 の間のポート (TCP/IP の既定の動的ポート範囲) を使うように構成されている場合は、各ポートの除外を追加します。 これにより、他のシステム プロセスが同じポートを動的に割り当てるのを防ぐことができます。 次の例では、ポート 59999 の除外を作成します。

netsh int ipv4 add excludedportrange tcp startport=59999 numberofports=1 store=persistent

ポートが使用されていないときにポート除外を構成することが重要です。そうでないと、コマンドは "ファイルは別のプロセスで使用されているため、このプロセスからアクセスすることはできません" のようなメッセージが表示されて失敗します。

除外が正しく構成されていることを確認するには、コマンド netsh int ipv4 show excludedportrange tcp を使用します。

可用性グループ ロールの IP プローブ ポートでこの除外を設定すると、状態 10048 でイベント ID: 1069 などのイベントが防止されるはずです。 このイベントは Windows フェールオーバー クラスター イベントで見られることがあり、次のメッセージが表示されます。

Cluster resource '<IP name in AG role>' of type 'IP Address' in cluster role '<AG Name>' failed.
An Event ID: 1069 with status 10048 can be identified from cluster logs with events like:
Resource IP Address 10.0.1.0 called SetResourceStatusEx: checkpoint 5. Old state OnlinePending, new state OnlinePending, AppSpErrorCode 0, Flags 0, nores=false
IP Address <IP Address 10.0.1.0>: IpaOnlineThread: **Listening on probe port 59999** failed with status **10048**
Status [**10048**](/windows/win32/winsock/windows-sockets-error-codes-2) refers to: **This error occurs** if an application attempts to bind a socket to an **IP address/port that has already been used** for an existing socket.

この原因としては、プローブ ポートとして定義されているものと同じポートが内部プロセスで使用されることが考えられます。 プローブ ポートは Azure Load Balancer からバックエンド プール インスタンスの状態を確認する目的で使用されることを思い出してください。
バックエンド インスタンスからの応答取得を正常性プローブで失敗した場合、正常性プローブが再び成功するまで、そのバックエンド インスタンスに新しい接続は送信されません。

既知の問題

一般的に知られている問題とエラーの解決策を確認します。

リソースの競合 (特に IO) によってフェールオーバーが発生する

VM の I/O または CPU 容量を使い切ると、可用性グループがフェールオーバーする可能性があります。 フェールオーバーの直前に発生した競合を特定することは、自動フェールオーバーの原因を突き止める最も信頼性の高い方法です。

I/O 分析を使用する

Azure portal で I/O 分析 (プレビュー) を使用して、フェールオーバーの原因となるディスク パフォーマンスの問題を特定します。

VM ストレージ IO メトリックを使用して監視する

Azure Virtual Machines を監視してストレージ IO 使用率メトリックを確認し、VM またはディスクのレベルでの待ち時間を把握します。

Azure VM 全体の IO 枯渇イベントを確認するには、次の手順のようにします。

1. Azure Portal で [仮想マシン] に移動します ([SQL 仮想マシン] ではありません)。

2. [監視] の [メトリック] を選んで、[メトリック] ページを開きます。

3. [ローカル時間] を選択して、関心のある時間の範囲と、タイム ゾーン (VM に対するローカルまたは UTC/GMT のいずれか) を指定します。

   

4. [メトリックの追加] を選び、次の 2 つのメトリックを追加してグラフを表示します。

   • VM のキャッシュされた帯域幅の消費率
   • VM のキャッシュされていない帯域幅の消費率

Azure VM の HostEvent によってフェールオーバーが発生する

Azure VM の HostEvent によって可用性グループがフェールオーバーされる可能性があります。 Azure VM の HostEvent によってフェールオーバーが発生したと思われる場合は、Azure Monitor のアクティビティ ログと Azure VM の Resource Health の概要をチェックできます。

Azure Monitor のアクティビティ ログは Azure のプラットフォーム ログであり、サブスクリプション レベルのイベントに関する分析情報を提供します。 このアクティビティ ログには、リソースが変更されたときや仮想マシンが起動されたときなどの情報が含まれます。 Azure portal でアクティビティ ログを表示したり、PowerShell と Azure CLI を使用してエントリを取得したりすることができます。

Azure Monitor のアクティビティ ログを調べるには、次の手順のようにします。

1. Azure portal で仮想マシンに移動します

2. [仮想マシン] ペインで [アクティビティ ログ] を選びます

3. [期間] を選び、可用性グループがフェールオーバーされた期間を選びます。 [適用] を選択します。

   

プラットフォームによって開始された使用不可状態の根本原因に関する詳細情報が Azure にある場合、その情報は、最初に使用不可になってから最大 72 時間は Azure VM の Resource Health の概要 ページに表示されている可能性があります。 この情報は、現在、仮想マシンについてのみ利用できます。

1. Azure portal で仮想マシンに移動します
2. [正常性] ペインの [リソース正常性] を選びます。

このページから正常性イベントに基づくアラートを構成することもできます。

クラスター ノードがメンバーシップから削除された

Windows クラスターのハートビートとしきい値の設定が環境に対して厳格すぎる場合は、システム イベント ログに次のメッセージが頻繁に表示されることがあります。

Error 1135
Cluster node 'Node1' was removed from the active failover cluster membership.
The Cluster service on this node may have stopped. This could also be due to the node having
lost communication with other active nodes in the failover cluster. Run the Validate a
Configuration Wizard to check your network configuration. If the condition persists, check
for hardware or software errors related to the network adapters on this node. Also check for
failures in any other network components to which the node is connected such as hubs, switches, or bridges.

詳細については、「イベント ID 1135 のクラスターの問題のトラブルシューティング」を参照してください。

リースの有効期限が切れた、リースが無効になった

監視が環境に対して厳しすぎる場合、可用性グループまたは FCI の再起動、エラー、またはフェールオーバーが頻繁に発生することがあります。 また、可用性グループについて、SQL Server エラー ログに次のメッセージが表示される場合があります。

Error 19407: The lease between availability group 'PRODAG' and the Windows Server Failover Cluster has expired.
A connectivity issue occurred between the instance of SQL Server and the Windows Server Failover Cluster.
To determine whether the availability group is failing over correctly, check the corresponding availability group
resource in the Windows Server Failover Cluster

Error 19419: The renewal of the lease between availability group '%.*ls' and the Windows Server Failover Cluster
failed because the existing lease is no longer valid.

Connection timeout

セッション タイムアウトが可用性グループの環境に対して厳格すぎる場合は、次のメッセージが頻繁に表示されることがあります。

Error 35201: A connection timeout has occurred while attempting to establish a connection to availability
replica 'replicaname' with ID [availability_group_id]. Either a networking or firewall issue exists,
or the endpoint address provided for the replica is not the database mirroring endpoint of the host server instance.

Error 35206
A connection timeout has occurred on a previously established connection to availability
replica 'replicaname' with ID [availability_group_id]. Either a networking or a firewall issue
exists, or the availability replica has transitioned to the resolving role.

グループがフェールオーバーされない

[指定した期間の最大エラー数] の値が小さすぎて、一時的な問題による断続的なエラーが発生している場合、可用性グループが失敗した状態で終了するおそれがあります。 この値を増やして、一時的な障害をより多く許容するようにします。

Not failing over group <Resource name>, failoverCount 3, failoverThresholdSetting <Number>, computedFailoverThreshold 2.

イベント 1196 - ネットワーク名リソースで関連付けられた DNS 名の登録が失敗しました

• 各クラスター ノードの NIC 設定を調べて、外部 DNS レコードが存在しないことを確認します
• クラスターの A レコードが内部 DNS サーバーに存在することを確認します。 ない場合は、クラスターのアクセス制御オブジェクト用の新しい A レコードを手動で DNS サーバーに作成し、[同じ所有者名の DNS レコードの更新を認証されたユーザーに許可する] をオンにします。
• IP リソースがオフラインになっているリソースの "クラスター名" を取得し、それを修正します。

イベント 157 - ディスクが予期せず削除されました

これは、AG 環境で記憶域スペースのプロパティ AutomaticClusteringEnabled が True に設定されている場合に発生する可能性があります。 それを False に変更します。 また、ストレージ オプションを使用して検証レポートを実行すると、ディスクのリセットまたは予期しない削除イベントがトリガーされることがあります。 ストレージ システムの調整により、ディスクの予期しない削除イベントがトリガーされる可能性もあります。

イベント 1206 - クラスター ネットワーク名リソースをオンラインにすることができません

リソースに関連付けられているコンピューター オブジェクトを、ドメインで更新できませんでした。 ドメインでの適切なアクセス許可があることを確認します

Windows クラスタリングのエラー

通信用にクラスター サービス ポートを開いていない場合、Windows フェールオーバー クラスターまたはその接続のセットアップ中に問題が発生することがあります。

Windows Server 2019 を使用していて、Windows クラスター IP が表示されない場合は、分散ネットワーク名が構成されていますが、これは SQL Server 2019 でのみサポートされています。 以前のバージョンの SQL Server を使用している場合は、クラスターを削除し、ネットワーク名を使用して再作成することができます。

その他の Windows フェールオーバー クラスタリング イベント エラーとその解決方法については、こちらをご覧ください

次のステップ

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

• Azure VM 上の SQL Server に対する HADR 設定
• Windows Server フェールオーバー クラスターと Azure VM 上の SQL Server
• AlwaysOn 可用性グループと Azure VM 上の SQL Server
• Windows Server フェールオーバー クラスターと Azure VM 上の SQL Server
• Azure VM 上の SQL Server を使用したフェールオーバー クラスター インスタンス
• フェールオーバー クラスター インスタンスの概要