☰

WSFC クラスター内の Windows Server 2016 ゲストがハートビート ルートのドロップによりランダムに隔離される

tag-icon • tag-icon windows-server-2016 windows-cluster
WSFC クラスター内の Windows Server 2016 ゲストがハートビート ルートのドロップによりランダムに隔離される

Hyper-V Server 2016 でホストされているゲスト Windows Server 2016 OS が 2 つあります。ゲスト OS クラスターは非常に信頼性が低く、ノードの 1 つが常に隔離されます (1 日に複数回)。

Windows Server 2012R2 クラスターも使用しています。これらは同じ Hyper-V ホストでホストされており、何の問題もありません。つまり、2012R2 と 2016 の間で同じネットワークと Hyper-V インフラストラクチャが使用されているということです。

2016 ホストの詳細な構成:

  1. ネットワーク接続では、すべてのアダプタの TCP/IPv6 がチェックされていません。これは実際にはクラスタのIPv6を無効にするものではないことは承知していますこれは NetFT によって隠しネットワーク アダプターを使用し、ハートビート用に IPv6 を IPv4 にカプセル化するためです。正常な 2012R2 ホストでも同じ構成を使用しています。
  2. 2012R2 クラスターは Witness なしでも期待どおりに動作しましたが、最初は 2016 も同じように構成しました。これらの問題のトラブルシューティングを試み、2016 クラスターにファイル共有 Witness を追加しましたが、変化はありませんでした。
  3. ネットワーク検証レポートが正常に完了しました

知っている何起こるが、知らないなぜ。何:

  1. クラスターは、ポート 3343 上の両方のノード間の複数のインターフェイスを介してハートビート UDP パケットでピンポンを実行します。パケットはおよそ 1 秒ごとに送信されます。
  2. 突然、1 つのノードがピンポンを停止し、応答しなくなります。1 つのノードは引き続きハートビートを配信しようとします。
  3. さて、クラスターのログファイルを読んで、ノードがルーティング情報の知識を削除したことを確認しました。
000026d0.000028b0::2019/06/20-10:58:06.832 ERR   [CHANNEL fe80::7902:e234:93bd:db76%6:~3343~]/recv: Failed to retrieve the results of overlapped I/O: 10060
000026d0.000028b0::2019/06/20-10:58:06.909 ERR   [NODE] Node 1: Connection to Node 2 is broken. Reason (10060)' because of 'channel to remote endpoint fe80::7902:e234:93bd:db76%6:~3343~ has failed with status 10060'
...
000026d0.000028b0::2019/06/20-10:58:06.909 WARN  [NODE] Node 1: Initiating reconnect with n2.
000026d0.000028b0::2019/06/20-10:58:06.909 INFO  [MQ-...SQL2] Pausing
000026d0.000028b0::2019/06/20-10:58:06.910 INFO  [Reconnector-...SQL2] Reconnector from epoch 1 to epoch 2 waited 00.000 so far.
000026d0.00000900::2019/06/20-10:58:08.910 INFO  [Reconnector-...SQL2] Reconnector from epoch 1 to epoch 2 waited 02.000 so far.
000026d0.00002210::2019/06/20-10:58:10.910 INFO  [Reconnector-...SQL2] Reconnector from epoch 1 to epoch 2 waited 04.000 so far.
000026d0.00002fc0::2019/06/20-10:58:12.910 INFO  [Reconnector-...SQL2] Reconnector from epoch 1 to epoch 2 waited 06.000 so far.
...
000026d0.00001c54::2019/06/20-10:59:06.911 INFO  [Reconnector-...SQL2] Reconnector from epoch 1 to epoch 2 waited 1:00.000 so far.
000026d0.00001c54::2019/06/20-10:59:06.911 WARN  [Reconnector-...SQL2] Timed out, issuing failure report.
...
000026d0.00001aa4::2019/06/20-10:59:06.939 INFO  [RouteDb] Cleaning all routes for route (virtual) local fe80::e087:77ce:57b4:e56c:~0~ to remote fe80::7902:e234:93bd:db76:~0~
000026d0.00001aa4::2019/06/20-10:59:06.939 INFO    <realLocal>10.250.2.10:~3343~</realLocal>
000026d0.00001aa4::2019/06/20-10:59:06.939 INFO    <realRemote>10.250.2.11:~3343~</realRemote>
000026d0.00001aa4::2019/06/20-10:59:06.939 INFO    <virtualLocal>fe80::e087:77ce:57b4:e56c:~0~</virtualLocal>
000026d0.00001aa4::2019/06/20-10:59:06.939 INFO    <virtualRemote>fe80::7902:e234:93bd:db76:~0~</virtualRemote>

さて、なぜそうなるのかという部分ですが...なぜそうなるのでしょうか? 分かりません。1分前に次のようにエラーが出ていることに注意してください:Failed to retrieve the results of overlapped I/Oしかし、UDPパケットが送受信されているのがまだわかります。

ワイヤーシャーク

10:59:06 にルートが削除され、1 つのノードのみが ping しましたが、pong はありませんでした。Wireshark で確認すると、ソース列に IP 10.0.0.19 と 10.250.2.10 がありません。

ワイヤーシャーク2

ルートは約 35 秒後に再度追加されますが、ノードはすでに 3 時間隔離されているため、役に立ちません。

ここで何が欠けているのでしょうか?

答え1

Windows Server 2019 フェールオーバー クラスター (Hyper-V 2019 用) でも同じ問題が発生しました。通常、サーバーで IPv6 も無効にしていますが、それが問題の原因でした。ファイル共有監視も実行されていて動作しているにもかかわらず、クラスターは多くの重大なエラーをスローし、ハード フェールオーバーを実行することがありました (?!)。

イベントログで確認したエラーと警告は次のとおりです。

フェールオーバークラスタリング イベント ID:

  • 1135 (クラスター ノード '....' がアクティブなフェールオーバー クラスター メンバーシップから削除されました)
  • 1146 (クラスター リソース ホスティング サブシステム (RHS) プロセスが終了し、再起動されます)
  • 1673 (クラスター ノード '....' が分離状態になりました。)
  • 1681 (ノード '....' 上の仮想マシンは監視されていない状態になりました。)

サービス コントロール マネージャー イベント ID:

  • 7024 (クラスターを形成するためのクラスター ノードのクォーラムが存在しません。)
  • 7031 (Cluster Service サービスが予期せず終了しました。)

フェールオーバークラスタリングクライアント

  • 81 (拡張RPCエラー情報)

あなたの調査のおかげで、重要な手がかりが得られました。隠しアダプタは依然として IPv6 を使用しています。あなたがリンクした記事には、隠しアダプタで IPv6 を無効にすることは推奨されておらず、主流でもありませんが、他のすべてのアダプタで IPv6 を無効にすることはサポートされ、テストされていると書かれていたので、何が彼の作業を妨げているのか疑問に思いました。

次のコマンドを使用して、クラスター ログを取得しました (ヒントもありがとうございます。この便利なコマンドについては知りませんでした)。

# -Destination (Folder) in my case changed to be not on the "C:\" SATADOM (this thing is slow and has few write cycles)
# -TimeSpan (in minutes) limited to one of the Failovers because these logs get HUGE otherwise.
Get-ClusterLog -Destination "E:\" -TimeSpan 5

残念ながら、すでに投稿されているものと同じログエントリがありました。

すべてのアダプタで IPv6 を再度有効にし、トンネル関連のアダプタ/構成を次のように元に戻しました。

Set-Net6to4Configuration -State Default
Set-NetTeredoConfiguration -Type Default
Set-NetIsatapConfiguration -State Default

それはうまくいきませんでした...さらに調べてみると、私は常に「不要な」IPv6 関連のファイアウォール ルールも無効にしていることに気付きました...そして、それが実際に重要な変更のようです! これらのルールは、非表示のアダプターにも影響するようです。

問題は、IPv6 は通信相手の MAC アドレスを見つけるために ARP を使用しないという点です。IPv6 は近隣探索プロトコルを使用します。また、関連するファイアウォール ルールを無効にすると、このプロトコルは機能しません。IPv4 ARP エントリは次のように確認できます。

arp -a

これでは IPv6 アドレスの MAC アドレスは表示されません。そのためには、次のものを使用できます。

netsh interface ipv6 show neighbors level=verbose

必要に応じて、次のように IPv6 アダプタ アドレスへの出力をフィルターできます。

netsh interface ipv6 show neighbors level=verbose | sls ".*fe80::1337:1337:1234:4321.*" -Context 4 |%{$_.Line,$_.Context.PostContext,""}

そうすると、これらのエントリの存続期間は非常に短いことがわかりました。クラスタ パートナーの Microsoft「フェールオーバー クラスタ仮想アダプタ」リンク ローカル アドレスのエントリの状態は、常に「到達可能」と「プローブ」の間で切り替わっていました。ただし、「到達不能」になった瞬間はわかりませんでしたが、IPv6 ルールを再度有効にすると、問題は解消されました。

Get-NetFirewallRule -ID "CoreNet-ICMP6-*" | Enable-NetFirewallRule

どういうわけか、この MAC アドレスはクラスター パートナー間で別の方法で交換されているようです (おそらく、これは「仮想リモート」アドレスであり、実際のアドレスではないためでしょうか)。そのため、このアドレスが繰り返し出現し、フェイルオーバー/検疫/分離状態が乱れることになります。

おそらく、非表示のアダプタで IPv6 を無効にすることも役立つでしょうが、これは推奨されていないため、IPv6 関連の無効化を完全にやめることにしました。いずれにせよ、これは未来です :-)

これが IPv6 を無効にしようとしている他の人たちに役立つことを願っています。

関連情報