クラスターのフェイルオーバーと奇妙な無償のARP動作
面倒なWindows 2008R2クラスター関連の奇妙な問題が発生しています。私は問題が何であるかについて近づいたと感じていますが、それでも何が起こっているのか完全には理解していません。
2つの2008R2サーバーで実行されている2つのノード交換2007クラスターがあります。 Exchangeクラスターアプリケーションは、「プライマリ」クラスターノードで実行すると正常に動作します。この問題は、クラスターリソースをセカンダリノードにフェイルオーバーするときに発生します。
たとえば、「プライマリ」と同じサブネット上にある「セカンダリ」ノードにクラスターをフェイルオーバーすると、フェイルオーバーは最初は正常に機能し、クラスターリソースは新しいノードで数分間機能し続けます。これは、受信ノードがネットワーク上のarpテーブルを更新した無料のarp応答パケットを送信することを意味します。しかし、x時間後（通常は5分以内）、突然クラスターサービスがpingに応答しないため、何かがarp-tablesを再度更新します。
したがって、基本的には、「プライマリノード」で実行されているときに、交換クラスタアドレスへのpingを開始します。それだけでうまくいきます。クラスターリソースグループを「セカンダリノード」にフェイルオーバーしましたが、許容できるpingの損失は1つだけです。クラスターのリソースは、フェイルオーバー後もしばらくの間応答し続け、突然pingのタイムアウトが始まります。
これは、arpテーブルが最初はセカンダリノードによって更新されるが、何か（まだ見つけていない）が誤って再度、おそらくプライマリノードのMACを使用して更新していることを示しています。
なぜこれが起こるのですか？誰かが同じ問題を経験しましたか？
クラスターはNLBを実行しておらず、問題のないプライマリノードにフェールオーバーした後、問題はすぐに停止します。
各ノードはALBとNIC teaming（intel））を使用しています。各ノードは同じサブネット上にあり、ゲートウェイなどは私が関係する限り正しく入力されています。
編集：
ネットワークバインドの順序に関連しているのではないかと思っていましたか？ノード間で確認できる唯一の違いは、ローカルのarpテーブルを表示するときだけであることに気づきました。 「プライマリ」ノードでは、ソースとしてのクラスターアドレスにarpテーブルが生成されます。 「セカンダリ」である間、ノード自身のネットワークカードから生成されます。
これに関する任意の入力？
編集：
これが接続レイアウトです。
クラスターアドレス：A.B.6.208/25 Exchangeアプリケーションアドレス：A.B.6.212/25
ノードA：3つの物理NIC。 2つはpublicと呼ばれるアドレスA.B.6.210/25でIntelチーミングを使用してチーム化しました10.0.0.138/24でプライベートと呼ばれるクラスタートラフィックに使用された最後の1つ
ノードB：3つの物理NIC。 2つはpublicと呼ばれるアドレスA.B.6.211/25でIntelチーミングを使用してチーム化しました10.0.0.139/24でプライベートと呼ばれるクラスタートラフィックに使用された最後の1つ
各ノードは、互いに接続された別々のデータセンターにあります。エンドスイッチは、DC1ではCisco、DC2ではNEXUS 5000/2000です。
編集：
もう少しテストしています。同じクラスター上に空のアプリケーションを作成し、Exchangeアプリケーションと同じサブネット上に別のIPアドレスを指定しました。この空のアプリケーションをフェイルオーバーした後、まったく同じ問題が発生しています。 1〜2分後、他のサブネット上のクライアントはアプリケーションの仮想IPにpingできません。ただし、他のサブネット上のクライアントはできませんが、同じサブネット上の別のクラスターの別のサーバーは、pingに問題はありません。しかし、元の状態にもう一度フェイルオーバーすると、状況は逆になります。したがって、同じサブネット上のクライアントは不可能になり、他のクライアントは可能になります。同じインテルネットワークカード、同じドライバー、同じチーム化設定を使用して、同じ方法で同じサブネット上に別のクラスターをセットアップします。ここではこれを見ていません。したがって、やや混乱します。
編集：
OKはさらに調査を行いました。セカンダリノードのNICチーム化が削除されました。これは機能しなかったためです。その後、いくつかの標準的な問題が発生したため、最終的に古いNIC単一の物理ネットワークカードのチーミング設定今、私は上記の問題を再現することができません。それで、それは何らかの形でチーミングに関連しています-おそらく何らかのバグですか？
編集：
失敗させることができずに、さらにフェイルオーバーを行いましたか？したがって、NICチームを削除すると、回避策のように見えます。今、インテルNIC ALBとのチーム化（以前と同様））を再確立しようとしましたが、それでもまだ失敗させることはできません。これは、問題の根本原因を正確に特定することができないという事実により、迷惑です。今は、ある種のMS/Intelの問題であるように見えます。 14日後に再発しますか？奇妙なことが発生しました。NICチームを再作成した後、古いチームが呼び出されていた「PUBLIC」にチームの名前を変更できませんでした。ウィンドウでクリーンアップされていません-サーバーは再起動されましたが！
編集：
ALBチーミングを再確立した後、OKが返されました。だから私は今いくつかの徹底的なテストをするつもりです、そして私は私の観察で戻ります。 1つ確かなことです。 Intel 82575EB NICS、ALB、Gratuitous Arpに関連しています。
私は何とかそれを聞いてうれしいです:)私は今、集中的なテストをすることによってこれを引き起こす原因を見つけるつもりです。いくつかの結果で戻ってくることを願っています。 Broadcomでこれらの問題を見たことはありません。
@Kyle Brandt：これが発生するのを見たシステムには、どのドライバーバージョンがありますか？ NICドライバーバージョンとチーミングドライバーバージョンの両方を提供してください。
11.7.32.0と9.8.17を実行しています。
これらのドライバは確かに非常に古いことを知っていますが、この問題は定期的に発生するだけなので、ドライバを更新することで問題が解決するかどうかをトラブルシューティングすることは非常に困難です。現在、私はfxがこのアクションプランを使用しようとしました：1. ALBチーミングを削除します-エラーを発生させることができませんでした2. ALBチーミングを再確立します-問題が再度発生しました3. AFT（アダプターフォールトトレランス）を再試行します-問題が再発しました4 。最新のドライバーをインストールして、ALBチーミングを再実行します（11.17.27.0で試してみました）-問題が解決しました。
繰り返しますが、この定期的な問題のトラブルシューティングは、上記の手順のどれが問題を解決したかわからないので、イライラするほど難しいと思います。おそらくそれは新しいドライバーをインストールした後だったでしょう-しかし、私は今のところ事実を知りません。
同じ問題が発生している一部の方が、いくつかのメモ/アイデア/観察事項を追加して、この問題の原因を特定できるようにしてください。
フェールオーバークラスター内のいくつかのSQL Serverインスタンスについて、マシンが誤ったARPテーブルエントリを取得するのを見始めました。
あるいは、クライアントサーバーは、正しいNICチームからのMACアドレスと物理NICの1つからのMACアドレス（必ずしも対応するNIC =そのサーバー上のチームMAC）、別のクラスターノード上。
これにより、SQLクラスターと同じLAN上のクライアントに断続的な接続障害が発生します。
この動作は、VMクライアントと物理ボックスの両方で確認されています。
これはフェイルオーバー後に発生し、数日間続きます。
これを緩和するために、より厄介なクライアントに静的なarpエントリを設定する必要がありました。
環境：
- フェールオーバークラスター内のWindows 2008 R2 SP1サーバー
- SQL Server 2008 R2インスタンス
- チーム化されたIntelギガビットNICS
- HP 28XXスイッチ
- Windows Server 2008 R2 SP1 Hyper-Vでホストされている仮想マシン
Intel NICチームは、いずれかの物理NICのMACアドレスを使用して仮想アダプターを作成します。
Intel NICチーミングソフトウェアが原因であると疑っていますが、他のトラブルシューティングの考えや解決策をいただければ幸いです。
サーバー2012を使用してクラスターホストを再構築し、インボックスNICチーム化を使用します（そのプラットフォームでのテストでこの問題を確認していなかったため）。
最新のクラスターホットフィックスが適用されていますか？かなり深刻な既知の欠陥がいくつかあります。
一時的な通信障害により、Windows Server 2008 R2フェイルオーバークラスターが機能しなくなります
https://support.Microsoft.com/kb/2550886
クラスターとアプリケーションサーバーの間にルーターが存在しない場合、フェイルオーバー操作が遅い
https://support.Microsoft.com/kb/2582281
"この問題は、アプリケーションサーバーのTCP/IPスタックがGratuitous Address Resolution Protocol（ARP）リクエストを誤って無視するために発生します。"
これは純粋に推測にすぎませんが、RLBが有効になっていると何らかの不適切な相互作用が発生する可能性があると推測されます（デフォルトで有効になっているもの、およびLazerpld、Steven、Stack Exchangeはすべて、このバグが何であれ、すべてヒットしています）。 Intelチーミングホワイトペーパー から：
受信負荷分散（RLB）はALBのサブセットです。これにより、チーム内のすべてのアダプターのTxとRxの両方にトラフィックが流れるようになります。 WindowsでRLBチームを作成すると、この機能はデフォルトでオンになります。チームの詳細設定を使用して、インテル®PROSet GUIから無効にすることができます。
RLBモードでは、クライアントがARP要求メッセージを送信してチームに接続しようとすると、Intel ANSがTCP応答としてスタックします。次に、インテルANSは、RLBアルゴリズムに従って、特定のエンドクライアントにサービスを提供するために選択されたチームのポートの1つのMACアドレスをARP応答にコピーします。クライアントはこの応答メッセージを受け取り、チームIPと指定されたMACアドレスとの一致をローカルARPテーブルに含めます。その後、このエンドクライアントからのすべてのパケットは、選択されたポートで受信されます。このモードでは、インテルANSはチームメンバーを割り当てますクライアントがサーバーへの接続を要求するときに、ラウンドロビン方式でエンドクライアント接続にサービスを提供します。チーム内のすべての有効なメンバー間でエンドクライアントを公平に分配するために、 RLBクライアントテーブルは等間隔で更新されます（デフォルトは5分です）。これは事前調整である受信バランス間隔です。レジストリ内の設定を考え出した。更新では、必要に応じて、クライアントごとに新しいチームメンバーを選択します。 Intel ANSは、影響を受けるクライアントに対して、接続する新しいMACアドレスでARP応答を開始します。すべてのクライアントのARPテーブルがIntel ANSによって更新されると、受信トラフィックの再配布が完了します。
OSはいつでもARP要求を送信でき、これらはIntel ANSドライバーの制御下にはありません。これらは、プライマリポートを介して送信されるブロードキャストパケットです。要求パケットはチームのMACアドレス（チームのプライマリポートのMACアドレス）を使用して送信されるため、チームに接続されているすべてのエンドクライアントは、チームのIPアドレスをのMACアドレスに関連付けることにより、ARPテーブルを更新しますプライマリポート。これが発生すると、それらのクライアントの受信負荷はプライマリポートに集約されます。
Rxロードバランシングを再開するために、Intel ANSは、非プライマリポートに送信していた受信ハッシュテーブル内のすべてのクライアントに、それぞれのチームメンバーのMACアドレスを使用して、Gratuitous ARPを送信します。さらに、OSによって送信されたARP要求はRLBハッシュテーブルに保存され、エンドクライアントからARP応答を受信すると、クライアントのMACアドレスがハッシュテーブルで更新されます。これは、サーバーが接続を開始するときにRLBを有効にするために使用されるメカニズムと同じです。
したがって、私の理論では、おそらくWindowsクラスタリングが仮想IPをリリースするとき、IntelドライバーはIPがリリースされたことを認識せず、それを発表し続けるということです。そうは言っても、今のところこれは理論にすぎません。
同じような問題がありますが、皆さんと違うのは、同じサブネット上のサーバーが（ランダムに）クラスターのアクティブノードを切り替え/移動せずに、いつでもSQL CLusterへのpingを停止するということです。つまり、Node Aがアクティブ、ノードBがスタンバイ、アプリケーションサーバーがSQL Serverへの接続を突然失います（ノードA-アクティブ）。ARPテーブルを確認すると、クラスターのエントリが（ノードB-スタンバイ）からのMACアドレスが設定されたIP。どういうわけか（それでも理由が見つからなかった）アプリケーションサーバーがARPテーブルを更新しました。wiresharkでスニッフィングし、それを含むARP応答を取得できませんでした変化する。
よろしく、
ビクター
本質的に同じ動作を見てきましたが、Linuxでの動作です。もう少し詳しく診断しました。
あるサーバーのalbボンドからVIFをプルダウンし、同じIPのVIFを別のサーバーの別のalbボンドで起動できます。 。 。そして、最初のサーバーからのslaveインターフェースがVIFのIPに対する未承諾のARP応答を送り続け、クライアントからのpingが最初のサーバーにルーティングされるとドロップを開始しますサーバ。まるで、RLB MACマスカレードを担当するコードの一部が、VIFが削除されたというメモを取得していないのに、ループでスタックしているようです。
編集：強調するために、元のサーバーのスレーブインターフェースは不必要なARPを吐き出してはいませんが、クライアントへの一方的なARP応答は発生しています。重要なことに、新しいクライアントをオンラインにすると、ARP要求が送信され、2番目のサーバーが応答し、すべてが正常に動作します。ただし、元のクライアントは、最初のサーバーが要請されていないARP応答のストリーム（たとえば、サービスネットワークの再起動など）を続行できなくなるまで、VIF IPで2番目のサーバーと通信できません。
私たちが学んだこと：
Intel NIC（e1000eドライバー）にのみ問題があります。さまざまなカーネルで、2.4.xまでの最新のドライバーで再現。
アルブボンドにのみ問題があります。
RHEL5.3では再現が簡単で、RHEL5.5では再現が難しいように見えますが、RHEL5.8では再現されないようです。ボンディングモジュールが5.5と5.8の間でほとんど変更されなかったため、少し変わっています。ただし、上記のレポートがWindowsに関するものである場合、NIC driver/firmware。
根本的な原因にはまだ到達していませんが、これらのNICでモード6の使用を停止するか、これらのNICの使用を完全に停止する可能性があります。いずれかが回避策のようです。問題が新しいカーネルで本当になくなった場合は、修正があるとは思えません。これは、OSのバグがNICによる望ましくない動作をくすぐっていた可能性があります。
どのNICを使用していますか？ Broadcomは偶然ですか（ホラー、ホラー）？
ファームウェア、ドライバー、チーム化ソフトウェアの更新を試しましたか？
私の経験では、バグのあるファームウェア/ドライバー/チーミングは、Windowsサーバーで大混乱を引き起こす可能性があります特にクラスタリングやHyper-Vが関与している場合。