現在、VM ホスト上の NIC チームにリンク ステータスのみを使用していますが、最近、2 つのスイッチのうちの 1 つにメモリ エラーが発生し、トラフィックの通過が停止するという問題が発生しました。すべての VM ホストがダウンし、そのスイッチを手動でシャットダウンするまで、ほとんどのゲスト (すでにそのパスを使用していた) も応答しなくなりました。
Linux ボンディング環境では、リンク ステータスを検出する別の方法として arp_intervals を使用できますが、VMWare ではビーコン プロービングのみを使用できます。BP は、接続をテストするホストを選択せず、また 3 つ以上のインターフェイスが必要であるという点で arp_interval とは異なります。
すべてのVMホストには4つのNICがあるため、3つのNIC要件はそれほど問題にはなりません。ただし、ドキュメントには少なくとも3つの個別の物理NIC（pNIC）が必要であるとのみ記載されていますが、すべての例には3つの個別の物理スイッチもあり、それが要件であるかどうかは記載されていません。この答えを探していたところ、これブログにはこう書かれています。
「vSwitch 内の複数の pNIC が同じ pSwitch に接続されている場合は、ビーコン プロービングを使用しないでください。これにより、pSwitch 上の 2 つ以上のポートに同じ MAC アドレスが表示されることになり、「非常に悪い」ことになります。」
私たちの構成には、この問題をさらに悪化させるだけの 3 つのスイッチがあるわけではなく、予備テストの一部では、同じスイッチに接続されていることに関連して、説明のつかないリンク フラッピングの問題が発生していました。
では、ビーコン プローブには 3 つの個別の物理スイッチも必要ですか? 私の構成ではリンク ステータスのみに制限されますか? また、半ば修辞的に言えば、NIC チーミングのオプションとして arp_interval がないのはなぜですか?
答え1
ビーコン プローブでは、ビーコンが最もよく機能する方法であるため、少なくとも 3 つの pNIC を使用することをお勧めします。ESXi は、物理 NIC カードからブロードキャスト パケットを送信します。同じ vSwitch 内の他の pNIC は、他の pNIC からパケットを受信するかどうかを待機します。どの pNIC もブロードキャストを受信しない場合、ESXi はダウン リンクであると想定します。
3 つの pNIC すべてを同じスイッチに接続し、ビーコン プローブを使用すると、リンク ステータスの方が簡単なのでリソースの無駄になります。リンクはオンですか、オフですか? 構成の問題 (STP またはポート ブロック) は、リンク ステータスでは表示されません。
ビーコン プローブの目的と設計は、pNIC を異なる pSwitch に接続することでした。これは、pNIC が接続されたスイッチ以外のダウンストリーム スイッチを「テスト」するために使用されていたためです。BP は、たとえば iSCSI SAN のダウンストリームにある 3 番目の pSwitch に障害が発生したかどうかを判断できます。リンク ステータスではそれを検出できませんが、BP では検出できます。次に、ESXi サーバーは、何をすべきかを判断できます。リンク ステータスは、SAN が利用できない場合でも、SAN にパケットを送信しようとし続けます。