アクティブなフェールオーバー クラスター メンバーシップからノードが削除される際に問題が発生する

この記事では、アクティブなフェールオーバー クラスター メンバーシップからノードがランダムに削除される問題を解決する方法について説明します。

現象

問題が発生すると、次のようなイベントがシステム イベント ログに記録されます。

イベント 1135 の例のスクリーンショット。

このイベントは、削除されたノードを除き、クラスター内のすべてのノードでログに記録されます。 このイベントの理由は、クラスター内のいずれかのノードがそのノードをダウンとマークしたためです。 その後、イベントの他のすべてのノードに通知します。 ノードに通知されると、ダウンしたノードへのハートビート接続を中止し、切断します。

ノードがマークダウンされた原因

Windows 2008 または 2008 R2 フェールオーバー クラスター内のすべてのノードは、このネットワーク上のクラスター ネットワーク通信を許可するように設定されているネットワーク経由で相互に通信します。 ノードは、これらのネットワーク経由でハートビート パケットを他のすべてのノードに送信します。 これらのパケットは他のノードによって受信され、応答が送信されます。 クラスター内の各ノードには、ネットワークが稼働していて、他のノードが稼働していることを確認するために監視する独自のハートビートがあります。 次の例は、この動作を明確にするのに役立ちます。

相互に通信している 2 つのノードの図。

これらのパケットのいずれかが返されない場合、特定のハートビートは失敗したと見なされます。 たとえば、W2K8-R2-NODE2 は要求を送信し、W2K8-R2-NODE1 からハートビート パケットに応答を受信して、ネットワークとノードが稼働しているかどうかを判断します。 W2K8-R2-NODE1 が W2K8-R2-NODE2 に要求を送信し、W2K8-R2-NODE1 が応答を受け取らない場合、ハートビートが失われたと見なされ、W2K8-R2-NODE1 はその要求を追跡します。 この応答が見つからない場合、W2K8-R2-NODE1 は、別のハートビート要求が受信されるまでネットワークをダウンとして表示できます。

既定では、クラスター ノードには、接続がマークダウンされるまでの 5 秒で 5 つのエラーの制限があります。 そのため、W2K8-R2-NODE1 がその期間内に 5 回応答を受け取らない場合、W2K8-R2-NODE2 への特定のルートがダウンしていると見なされます。 他のルートがまだ稼働していると見なされる場合、W2K8-R2-NODE2 はアクティブメンバーとして残ります。

すべてのルートが W2K8-R2-NODE2 に対してマークダウンされている場合、アクティブなフェールオーバー クラスター メンバーシップから削除され、最初のセクションに表示されたイベント 1135 がログに記録されます。 W2K8-R2-NODE2 では、クラスター サービスが終了してから再起動され、クラスターへの再参加が試行されます。

3 つ以上のノードでダウンする特定のルートを処理する方法の詳細については、Jeff Hughes によって作成 された "パーティション分割された" クラスター ネットワーク のブログを参照してください。

ハートビート プロセスのしくみがわかったので、プロセスが失敗する既知の原因の一部は何ですか?

  1. 実際のネットワーク ハードウェア障害。 ノード間のどこかのワイヤでパケットが失われた場合、ハートビートは失敗します。 関係する両方のノードからのネットワーク トレースによって、これが明らかになります。

  2. ネットワーク接続のプロファイルは、ドメインからパブリックにバウンスし、ドメインに再び戻る可能性があります。 これらの変更の移行中に、ネットワーク I/O をブロックできます。 ネットワーク プロファイルの運用ログを調べることで、これが該当するかどうかを確認チェック。 このログを見つけるには、イベント ビューアーを開き、[アプリケーションとサービス] ログ\Microsoft\Windows\NetworkProfile\Operational に移動します。 イベント ID 1135 に記載されているノードのこのログ内のイベントを確認し、プロファイルがこの時点で変更されているかどうかを確認します。 その場合は、「 ネットワークの場所プロファイルが Windows 7 または Windows Server 2008 R2 の "ドメイン" から "パブリック" に変更される」を参照してください。

  3. サーバーでは IPv6 が有効になっていますが、Windows ファイアウォールでは受信と送信に対して次の 2 つの規則が無効になっています。

    • コア ネットワーク - 近隣探索アドバタイズ
    • コア ネットワーク - 近隣探索要請
  4. ウイルス対策ソフトウェアも、このプロセスを妨げている可能性があります。 これが疑われる場合は、ソフトウェアを無効またはアンインストールしてテストします。 この時点でウイルスから保護されていないため、自己責任でこれを行ってください。

  5. ネットワーク上の待機時間によって、これが発生する可能性もあります。 パケットはノード間で失われない可能性がありますが、タイムアウト期間が切れる前に十分な速度でノードに到達しない可能性があります。

  6. IPv6 は、フェールオーバー クラスタリングがハートビートに使用する既定のプロトコルです。 ハートビート自体は、ポート 3343 経由で通信する UDP ユニキャスト ネットワーク パケットです。 このトラフィックを通過できるようにスイッチ、ファイアウォール、またはルーターが正しく構成されていない場合は、このような問題が発生する可能性があります。

  7. IPsec セキュリティ ポリシーの更新によって、この問題が発生する可能性もあります。 特定の問題は、IPSec グループ ポリシーの更新中に、すべての IPsec セキュリティ アソシエーション (CA) がセキュリティ強化 (WFAS) の Windows ファイアウォールによって破棄されるということです。 この問題が発生している間は、すべてのネットワーク接続がブロックされます。 Active Directory での認証の実行に遅延がある場合にセキュリティ アソシエーションを再ネゴシエーションする場合、これらの遅延 (すべてのネットワーク通信がブロックされている場合) もクラスターハートビートの通過をブロックし、5 秒のしきい値内で応答しない場合、クラスターの正常性監視によってノードがダウンとして検出されます。

  8. 古いまたは古いネットワーク カードドライバーやファームウェア。 場合によっては、ネットワーク カードまたはスイッチの単純な構成ミスによって、ハートビートが失われる可能性もあります。

  9. 最新のネットワーク カードと仮想ネットワーク カードでパケット損失が発生している可能性があります。 これは、パフォーマンス モニターを開き、カウンター "ネットワーク インターフェイス\パケットが破棄されました" を追加することで追跡できます。このカウンターは累積的であり、サーバーが再起動されるまでだけ増加します。 ここで多数のパケットがドロップされるのは、ネットワーク上の受信バッファーカードが低すぎるか、サーバーのパフォーマンスが遅く、受信トラフィックを処理できないことを示している可能性があります。 各ネットワーク カード製造元は、これらの設定をネットワーク カードのプロパティで公開するかどうかを選択するため、製造元の Web サイトを参照して、これらの値を増やす方法と推奨値を使用する必要があります。 VMware で実行している場合、次のブログでは、これが問題であるかどうかを確認する方法や、変更する設定に関する VMware の記事を示す方法など、これについてもう少し詳しく説明しています。

    VMware ESX のフェールオーバー クラスター メンバーシップから削除されるノード

これらは、これらのイベントがログに記録される最も一般的な理由ですが、他の理由もあります。 このブログのポイントは、プロセスに関するいくつかの洞察を提供し、何を探すべきかのアイデアを提供することです。 次の値を最大値に引き上げて、この問題を停止しようとします。

パラメーター 既定値 範囲
SameSubnetDelay 1000 ミリ秒 250-2000 ミリ秒
CrossSubnetDelay 1000 ミリ秒 250 から 4000 ミリ秒
SameSubnetThreshold 5 3-10
CrossSubnetThreshold 5 3-10

これらの値を最大値に増やすと、イベントとノードの削除が解消され、問題が解決される可能性があります。 何も修正されません。 最善の方法は、ハートビート エラーの根本原因を調べ、修正する方法です。 これらの値を増やす唯一の実際のニーズは、ノードが異なる場所に存在し、ネットワーク待機時間を克服できないマルチサイト シナリオです。