仮想化でプリセールスしてるSEの一日

VMware から Azure まで、インフラや仮想化の最新情報をベンダー色をできるだけ抑えて綴っていきます

Windows Server 2012 R2 のネットワークの注意事項 - SMB Multichannel (1)

f:id:ogawad:20190203195637p:plain:right


前回 の最後にも少し触れたとおり、今回は「SMB マルチチャネル」について。

SMB Multichannel は Windows Server 2012 からの新機能で、 SMB トラフィックのロードバランスや帯域増強、パス障害に対応するマルチパス技術です。NIC チーミングの SMB/CIFS プロトコル限定版”と言えばイメージしやすいかもしれません。
デフォルト設定は On。つまり、デフォルトでは通信相手に対して SMB の通信パスが複数ある場合、そのすべてのパスが自動的に使われます。

Multichannel の特徴

Multichannel は SMB/CIFS プロトコルに限定で、しかもマルチホーム。
更にパス障害時の切り離しが遅い。。。
良いところが無いように思えますが、Multichannel の特徴は次の2つ。

  • Ethernet フレームを持たない InfiniBand の IPoIB や RDMA でも利用できる
  • 単一セッションのスループットが向上する可能性がある


前者については 前回 の記事のとおり。
今回取り上げたいのは後者です。NIC Team では 1Gbps のパスをリンクアグリゲーションでいくら束ねても、セッションあたりのスループットは 1Gbps から増えません。これに対し、Multichannel は単一セッションでもスループットが倍増します。

@IT Windows Insider:
Column「チーミングを行っても単一スループットは倍増しない?」
http://www.atmarkit.co.jp/ait/articles/1402/06/news129_2.html

単一セッションなのにスループットが倍増する理由

では、どうして Multichannel だとスループットが倍増するのでしょう?



これを理解するには、NIC Team と Multichannel がそれぞれどのレイヤーでコントロールしているか考えてみると早いです。
前回も解説したとおり、NIC Team は Ethernet (L2) ヘッダーの情報で送信パスを決定しますが*1、Multichannel は L7 ベースでコントロールするため、この時点では送信元や宛先に関するヘッダー情報は持っていません。このため、宛先などは一切考えず、到達できるすべてのパスを用いてラウンドロビン的に送ろうとします。


言葉では伝えにくいため図にしてみました。

まず、送信ファイルは、SMB プロトコルのブロックサイズ(ウィンドウサイズ)である 64 〜 1,024 KB に分割されます。


そして、分割されたファイルを転送する*2 のですが、、、


NIC Team の場合: 1 つのパスしか利用されません。


Multichannel の場合: 到達できるすべてのパスを利用します。


これが、NIC Team では不可能な "ワイヤースピード超え" を Multichannel であれば実現できる理由です。

では、SMB 限定用途の場合、NIC Team より Multichannel にすべきでしょうか?
このあたりについて 次回 触れたいと思います。

*1:場合によっては L3 ヘッダーも使います

*2:実際は Ethernet MTU で更に分割しますが、ややこしくなるため省略します