仮想スイッチ”スイッチへの通知”について(2)

前回以下の記事で、”スイッチへの通知”という設定の意味合いとその動作について図解で説明を致しました。仮想スイッチ”スイッチへの通知”について(1)

設定値としてはYesとNoがありますが、基本的にはYesで使うことがほとんどです。

※本図はvSphere ネットワークのドキュメントより抜粋
リンクとしては、こちらのリンク上に同様の記載があります。分散ポートグループの追加

今回のテーマは、”スイッチへの通知”をNoにするユースケースは？というものですが、既に答えは出ていますね。

ESXi上の仮想マシンにて、Microsoft NLBを利用するケースでは、その設定内容によっては、本項をNoにすることで正常な動作をさせることが出来ると記載があります。
Microsoft NLB がユニキャストモードで適切に機能しない (1556)

Microsoft NLBでは、ロードバランシング提供時に、仮想的なMACアドレスをNIC間で同一のものを利用する手法とそうでないものがあります。

それぞれのユースケースについては今回割愛しますが、ユニキャストモードの場合が上述しているとおり、複数のvNIC間で仮想MACアドレスをシェアします。

ここから、2つの図を用いて、”スイッチへの通知”が”No”の時と”Yes”の時を比べてみたいと思います。

こちらはユニキャストモードで動作する場合でかつ”スイッチへの通知”を”No”にした場合です。

この構成の場合、NLBクラスターの仮想MACアドレスは2つの仮想マシンで同一のものを利用します。またNLBクラスターへの通信は、物理スイッチのMACアドレステーブルがこれを学習しないため、常に通信はフラッドにより、全NLBクラスターノードがそれを受信する形となります。

ちなみにNLBが有効になることで、vNICレベルの仮想MACはマスキングされます。

一方この図は”スイッチへの通知”が”Yes”の場合です。vSphereの仮想スイッチの既定値です。

この場合、vmkernelからのRARPパケットにより、NLBクラスターの仮想MACアドレスを物理スイッチが学習をしてしまいます。

上図では、物理スイッチ Port 1に対し、NLBクラスターの仮想MACアドレスが紐付いてしまっています。

なお、RARPの発行トリガーは次の通りです。

上図では、上記トリガーにより、NLB用の仮想MACアドレスが学習をされてしまった事により、全てのNLBクラスターへの通信が、単一の仮想マシンに流れてしまうため、NLBが機能しません。

以上です。ですので、仮想マシン上で、仮想MACアドレスを利用するようなアプリケーションを利用する場合によっては、場合によってはRARPの停止が必要となります。

最後に、フォーラムで同一の質問がされていたものがありますので、こちらも共有として載せておきたいと思います。