Windows Serverのチーミングを検証する

広告

チーミングとはサーバーに搭載されている複数のネットワークインターフェースを仮想的に1つのインターフェースとして扱うネットワーク技術です。

チーミングには色々な方式がありますが、今回はWindows Serverに搭載されているチーミングについて性能を比較検証してみます。

特にWindows Server 2022からはHyper-Vの仮想SWにバインドする際に従来の静的チーミングやLACP(通称LBFO)は非推奨となり、SET(Software Embedded Teaming)推奨となっています。

ところがSETはどちらかというとAzureのようなクラウド環境向けのような気がしたので、昔ながら(?)のオンプレ仮想環境ではどうなのか気になるところです。

検証環境

Windows Server 2022 Standard

NIC:TP-Link TG-3468 x 2

Hyper-V上にWindows 10の仮想マシンを構築

Windows ServerのNICリンクスピードは100Mbpsに制限

ネットワーク負荷テストソフトとしてIperfを実行

仮想Windows 10からPCへパケットを送出(送信負荷の計測)

検証内容

仮想Windows 10からPCへ180秒間、Iperfによるパケット送出を行う。

送信実行中にLANケーブルの抜き取り、取り付けを行いフェイルオーバーと復旧の通信を観測する。

検証を行うチーミング方式は下記の通り。なお、負荷方式は全て動的(Dynamic)にて実施。

  • スイッチ非依存
  • 静的チーミング
  • LACP(Link Aggregation Controll Protocol)
  • SET(Software Embedded Teaming)スイッチ非依存

検証結果

グラフ化すると、それぞれ下記のようになりました(縦軸単位は送信bps、横軸単位は経過時間の秒、サンプリング間隔は1秒)。計測は仮想Windows 10のパフォーマンスモニターを利用しています。

橙色の縦線は2本接続しているLANケーブルのうち、1本を抜き取ったタイミングを示しています。片方のLANケーブルに障害は発生したと考えてください。

緑色の縦線は抜き取ったLANケーブルを再び接続したタイミングを示しています。障害の発生したLANケーブルが復旧したと考えてください。

結果の考察

縮退運転への移行

切断から縮退運転(200Mbpsリンクから100Mbpsリンク)への移行はどのチーミングモードでも大差ありませんでした。

SETだけは若干、立下りが見えますが1秒以内に100Mbpsに戻っているので気にするほどではないでしょう。

リンク復旧までの時間

抜き取ったLANケーブルを差し込んでからリンクが復旧するまでの時間はLACP方式が最も短くなりました(約7秒)。

その他の方式はあまり変わらず、おおよそ30秒前後経過してから200Mbpsリンクに戻っています。

復旧時の動作

SETの場合のみ復旧するときに立下りが発生しました。他のチーミング方式では立下りが見えませんでしたが、SETはソフトウェア処理を行う影響でオーバーヘッドが大きくなりがちなのかもしれません。

検証のまとめ

今回の検証ではオンプレ環境を想定して実際にLANケーブルをL2SWと接続してHyper-V環境を使いました。

少なくとも、この環境においてはSETチーミングの有用性は認められなかったので静的かLACPで良いでしょう。

ただし、Azureなどのクラウド基盤では結果が異なる可能性があります。また、今回は200Mbpsという比較的低速な通信での検証でしたので、高速な通信(10Gbps超)になると話はまた異なるかもしれません。

そもそもMicrosoft公式によればSETは10Gbps以上のNIC推奨です。また、Azure Stack HCIではSETしか使えないようです。

https://docs.microsoft.com/ja-jp/azure-stack/hci/concepts/host-network-requirements

SET検証についてまとめた公式情報もありますが、大前提がAzure Stack HCI環境です。

https://techcommunity.microsoft.com/t5/networking-blog/teaming-in-azure-stack-hci/ba-p/1070642

以上のことを踏まえると、Windows Server 2022では非推奨(既定ではHyper-Vの仮想スイッチをSETではない従来のチーミング(通称LBFO)には接続できない)となりましたが、10GbpsのNICを使わなかったり、ましてやAzure Stack HCI環境ではないのならあえて使う必要性は薄いでしょう。

急にサポート対象外にされる恐怖はあるかもしれませんが、、、

広告