Windows Server 2012 R2 のネットワークの注意事項 - SMB Multichannel (2)
前回 の内容から、SMB 通信限定、かつ障害対応を無視できるのであれば Multichannel の方が優れているように感じたでしょう。
しかし、その決断をするにはまだ早いかもしれません。
確かに机上ではそうなのですが、実環境では実はそう簡単ではないのです。
複数のネットワークでラウンドロビン？
下図は前回も紹介した SMB Multichannel によるラウンドロビン。
ファイルを細切れにして並列転送することでワイヤースピード超えを実現します。
仕組みは非常に簡単であり、実装は難しそうには見えません。
ではなぜ、多くの NIC Team ではラウンドロビンを実装しないのでしょうか？
上図は２台のサーバーだけの世界でしたが、
実際の環境では各セグメントに様々なデバイスが繋がっています。
ここで少し考えてみてください。
- Multichannel を構成する複数のネットワークは全く同格でしょうか？
- 一部のネットワークは業務系や管理系だったりしないでしょうか？
- それぞれの負荷は均等でしょうか？
- 一部のネットワークだけ高性能なスイッチにしていないでしょうか...？
そうです。実際の環境では、複数のネットワークパスを利用してラウンドロビンで並列転送しても、なかなか順番どおりに届かない のです。
この図のとおり、宛先ホストはランダムに届くピースをジグゾーパズルのように埋めていかなければなりません。
「シーケンシャルでもパラレルでも、遅いネットワークに引きずられるので結局同じなのでは？」と思われる方もいるでしょう。しかし、ピースがランダムで虫食い状態に埋めていくのと、端から順番にピースが届くのでは、受信サーバーの負担は全然違います。
道路にバイパスができて到着地までルートが増えると渋滞は減るでしょう。
しかし、２つのルートの所要時間は全く同じとは限りません。走行する時間帯によって差も生じます。
もし、ゴール地点ではゼッケンの順番どおりに駐車しなければならない場合、
駐車場は虫食いだらけ。広大の駐車スペースを確保して各車の到着を待つことになってしまいます。
これに対し、NIC Team はシーケンシャル転送です。
送られて来るピースは順序保証されているため、各車はゼッケンの番号どおりに到着します。適度に溜まったところで解散できるため（メモリ解放）、駐車スペースがそれほど確保できなくても回していけるのです。
実環境では１台のサーバーがやり取りする相手は１台だけではありません。
“サーバー” なのですから複数の相手と同時にやり取りすることの方が多いはず。
広大な駐車スペースとジグゾーパズルが何セットも必要になりますが、はたしてそのサーバーは効率的に動けるでしょうか...？
