アクティブなフェールオーバー クラスター メンバーシップからノードが削除される際に問題が発生する
この記事では、アクティブなフェールオーバー クラスターのメンバーシップからノードがランダムに削除される問題を解決する方法について説明します。
現象
問題が発生すると、次のようなイベントがシステム イベント ログに記録されます。
このイベントは、削除されたノードを除き、クラスター内のすべてのノードに記録されます。 このイベントが発生する理由は、クラスター内にあるいずれかのノードがそのノードをダウン状態としてマークしたためです。 その後、他のすべてのノードにそのイベントが通知されます。 ノードに通知されると、それらのノードは停止し、ダウンしたノードへのハートビート接続を切断します。
ノードがダウンしたと表示される原因
Windows Server フェールオーバー クラスター内のすべてのノードは、このネットワーク上のクラスター ネットワーク通信を許可するように設定されたネットワーク経由で相互に通信します。 ノードは、これらのネットワーク全体のハートビート パケットを他のすべてのノードに送信します。 これらのパケットは他のノードによって受信され、応答が返されることになっています。 クラスター内の各ノードには、ネットワークが稼働していて、他のノードが稼働していることを確認するために監視する独自のハートビートがあります。 次の例は、この動作を明確にするのに役立ちます。
これらのパケットのいずれかが返されない場合、特定のハートビートは失敗したと見なされます。 たとえば、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 によって作成された、「パーティション分割 された」クラスターネットワークのブログを参照してください。
これで、ハートビート プロセスのしくみはわかりましたが、プロセスが失敗する原因として知られている原因がいくつかあります。
実際のネットワーク ハードウェアの障害です。 ノード間のどこかのネットワークでパケットが失われた場合、ハートビートは失敗します。 関係する両方のノードからのネットワーク トレースによって、このことが明らかになります。
ネットワーク接続用のプロファイルは、ドメインからパブリックにバウンスし、再びドメインに戻る可能性があります。 これらの変更の移行中に、ネットワーク I/O がブロックされる可能性があります。 ネットワーク プロファイルの操作ログを確認することで、この問題が発生していないかどうかを確認できます。 このログを見つけるには、イベント ビューアーを開き、Applications and Services Logs\Microsoft\Windows\NetworkProfile\Operational に移動します。 イベント ID 1135 に記載されているノード上のこのログのイベントを確認し、この時点でプロファイルが変更されているかどうかを確認します。 その場合は、「 Windows 7 または Windows Server 2008 R2 でネットワークの場所プロファイルが "ドメイン" から "パブリック" に変更されるを参照してください。
サーバーで IPv6 が有効になっているが、Windows ファイアウォールの受信と送信に対して次の 2 つのルールが無効になっている場合:
- コア ネットワーク - 近隣探索の提供情報
- コア ネットワーク - 近隣探索の要請
ウイルス対策ソフトウェアもこのプロセスに干渉する可能性があります。 問題があると思われる場合は、ソフトウェアを無効化またはアンインストールしてテストします。 この時点でウイルスからの保護が解除されているため、ご自身の責任でこれを行ってください。
ネットワークの待機時間によっても発生する可能性があります。 パケットはノード間で失われない可能性がありますが、タイムアウト期間が切れる前に十分な速度でノードに到達しない可能性があります。
IPv6 は、フェールオーバー クラスタリングがハートビートに使用する既定のプロトコルです。 ハートビート自体は、ポート 3343 を介して通信する UDP ユニキャスト ネットワーク パケットです。 このトラフィックを通過できるように適切に構成されていないスイッチ、ファイアウォール、またはルーターがある場合は、このような問題が発生する可能性があります。
IPsec セキュリティ ポリシーの更新もこの問題の原因となる可能性があります。 具体的な問題は、IPsec グループ ポリシーの更新中に、すべての IPsec セキュリティ アソシエーション (SA) が、セキュリティが強化された Windows ファイアウォール (WFAS) によって破棄されることです。 この問題が発生している間は、すべてのネットワーク接続がブロックされます。 Active Directory での認証の実行に遅延がある場合にセキュリティ アソシエーションを再ネゴシエーションすると、これらの遅延 (すべてのネットワーク通信がブロックされている場合) もクラスターハートビートの通過をブロックし、5 秒のしきい値内で応答しない場合は、クラスターの正常性監視によってノードがダウンとして検出されます。
古いまたは旧式のネットワーク カード ドライバーやファームウェア。 場合によっては、ネットワーク カードやスイッチの単純な設定ミスでハートビートが失われることもあります。
最新のネットワーク カードと仮想ネットワーク カードでパケット損失が発生している可能性があります。 これは、パフォーマンス モニターを開き、カウンター "Network Interface\Packets Received Discarded" を追加することで追跡できます。このカウンターは累積的であり、サーバーが再起動されるまでだけ増加します。 ここで多数のパケットがドロップされているのは、ネットワーク カードの受信バッファーが低すぎるか、サーバーのパフォーマンスが遅く、受信トラフィックを処理できないことを示している可能性があります。 各ネットワーク カードの製造元は、これらの設定をネットワーク カードのプロパティで公開するかどうかを選択します。そのため、製造元の Web サイトを参照してこれらの値を増やす方法を確認し、推奨値を使用する必要があります。 VMware で実行している場合、次のブログでは、これが問題であるかどうかを確認する方法や、変更する設定に関する VMware の記事を示す方法など、これについてもう少し詳しく説明しています。
これらのイベントがログに記録される最も一般的な理由を次に示しますが、その他の理由も考えられます。 このブログのポイントは、プロセスについての洞察を提供し、何を探すべきかについてのアイデアを提供することでした。 この問題を回避するために、次の値を最大値に上げるものもあります。
| パラメーター | Default | Range |
|---|---|---|
| SameSubnetDelay | 1000 ミリ秒 | 250 ～ 2000 ミリ秒 |
| CrossSubnetDelay | 1000 ミリ秒 | 250 ～ 4000 ミリ秒 |
| SameSubnetThreshold | 5 | 3 ～ 10 |
| CrossSubnetThreshold | 5 | 3 ～ 10 |
これらの値を最大値に増やすと、イベントとノードの削除が解消され、問題がマスクされる可能性があります。 何も修正されません。 最善の方法は、ハートビート エラーの根本原因を見つけて修正する方法です。 これらの値を増やす唯一の本当のニーズは、ノードが異なる場所に存在し、ネットワーク待機時間を克服できないマルチサイト シナリオです。