はじめに
試してみたときに撮ったこの画像を供養したかっただけの記事です。
[‘SwitcIndependent’ is the only TeamingMode value supported in a Virtual Machine]
意訳：仮想マシン上ではチーミングモードにおいて「スイッチに依存しない」しか選択できません。
[The only valid LoadBalancingAlgorithms in a Virtual Machine are TransportPorts IPAddresss and MacAddres]
意訳：仮想マシン上では負荷分散アルゴリズムにおいて「アドレスのハッシュ」しか選択できません。
NICチーミングとは
OS上でNICをひとまとめにしてメリットを享受しようという機能です。
こちらのページにほぼ必要な情報がまとまっています。
[Windows Server 2012 R2のNICチーミング機能（LBFO）をマスターする]
https://www.atmarkit.co.jp/ait/articles/1402/06/news129_2.html
「NICチーミング」とは、複数のネットワークアダプター（NIC）を束ねることで冗長化による「可用性の向上」と負荷分散による「帯域の増強」を実現可能にする技術だ。
本家の情報を参照したければこちら。
[NIC Teaming Overview]
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831648(v=ws.11)
NIC Teaming, also known as load balancing and failover (LBFO), allows multiple network adapters on a computer to be placed into a team for the following purposes:
・Bandwidth aggregation
・Traffic failover to prevent connectivity loss in the event of a network component failure
EC2上でNICチーミングをする意味
この記事における結論としては、「無い」です。
可用性の観点
これについては過去にAWSサポートに問い合わせたことがあります。
要約すると以下のような回答で、冗長構成をとる意味は無いという趣旨でした。
AWS上におけるNICであるENIは、ソフトウェアで作成された仮想NICである。
ENIを冗長構成にして1つのEC2インスタンスにアタッチしても、物理的には同一のハードウェアで動作することになる。物理的に冗長構成を取ったことにはならず、ネットワーク経路も同一のハードウェアを経由する。
EC2インスタンスの基盤となるハードウェア・ネットワークインフラは、AWSサービス内ですでに冗長化しているため、AWS利用者がNICの可用性を考慮する必要はない。
帯域幅の観点
こちらはサポートに問い合わせたわけではありませんが、同じく意味がないと考えています。
EC2インスタンスに割り当てられるネットワーク帯域は、インスタンスタイプによって、（ENI単位でなく）インスタンス単位で決まると考えていることが理由です。
下記のドキュメントの文言はそれを表しているのだと読み取りました。
デュアルホーム接続インスタンスに対するネットワーク帯域幅を増加または倍増させる方法として、別のネットワークインターフェイスをインスタンスにアタッチする機能 (NIC チーミング設定など) は使用できません。
[ネットワークインターフェイスの設定に関するベストプラクティス]
https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/using-eni.html#best-practices-for-configuring-network-interfaces
意味がないのになぜ試したのか
オンプレの案件に対応した際に、気軽に試せる環境がAWSしかなかったからです。
結局大したことは検証できず、空調が空間の全てを支配する部屋でカチカチしていたことを思い出します。
NICチーミングの設定値の内訳
基本的にNICを複数選択してポチポチしているだけで出来上がるシンプルなもので、主だったパラメータとしては以下の通りです。
- チーミングモード
- 負荷分散モード
- スタンバイアダプター
1.チーミングモード
複数のNICを論理的にひとまとめにしたとしても、物理的にパケットを送受信する際にはいずれか1つのNICを通ることになります。その際にどのNICを経由するかを、どういった基準で決定するかを定めるパラメータが、このチーミングモードです。
サーバ側からパケットを送信するときは、NICチーミング側で使用するNICを決定します。パケットを受信する際に使用するNICは、対向のスイッチにより決定されます。受信の際にも負荷分散を行いたければ、対向のスイッチとどうにかして連携する必要があります。
1.1.「スイッチに依存しない」モード
前述の「対向のスイッチとどうにか連携する」ができない時に選択することになります。
送信する時はNICチーミング側でNICを選択（負荷分散）できますが、受信の際はスイッチより決定されたものに従うことになります。
送信側での負荷分散すらしない時（Act-Standby構成）もこのモードを選択します。
1.2.「静的チーミング」モード
「対向のスイッチとどうにか連携する」パターンの１つです。ただ、後述のモードと比較して機能的に劣後する位置付けで、あまり使いどころはないそうです。
1.3.「LACP」モード
動的チーミングモードとも呼ばれるもので、「対向のスイッチとどうにか連携する」だけでなく、障害時の挙動など、もろもろの処理を動的に行ってくれます。ただし、対向のスイッチのスペックや構成に影響を受けるため、使用可能かはよくよく検討が必要です。
2.負荷分散モード
一部の例外を除き、サーバ側から見て送信方向のパケットは、負荷分散されます。その際に、どういったアルゴリズムに基づいて分散するかを決定するパラメータです。
2.1.「アドレスのハッシュ」モード
送信先や送信元のIPアドレス、MACアドレス、ポート番号を元にハッシュ計算を行い分散します。計算した結果同じ値が導き出されるなら、常に同じNICから送信されることになります。ハッシュ計算をした結果偏ることはないのでしょうか？気になります。
2.2.「Hyper-Vポート」モード
Hyper-VをホストするサーバでNICチーミングが組まれている時に選択し得るモードです。
Hyper-Vについてちょっと寄り道をして、物理ホスト上で仮想スイッチと仮想マシンが稼働している様を思い浮かべてください。仮想マシンは仮想スイッチにぶら下がる形で稼働しています。
同一物理ホスト上の仮想マシン間の通信は仮想スイッチを経由すれば完結しますが、仮想マシンが外部の対向先と通信する際には、物理ホストのNICを経由する必要があります。それは仮想スイッチと物理ホストのNICを紐づける（アップリンクする）ことで実現します。
仮想スイッチのアップリンク先がNICチーミングであった場合、このモードを選択すると、同じ仮想マシンからの通信は常に同じNICを経由することになります。
2.3.「動的」モード
パケットの中身といった小難しい事は気にせず、単に各NICの物理的な負荷を見て分散させるモードです。1番オススメだそうです。
3.スタンバイアダプター
NICチーミング内のNICをActive-Standby構成にしたい場合、ここで選択したNICがスタンバイになります。ホットスペアのような位置づけとのことです。スタンバイから昇格するときはどのような処理になるのでしょうか？ちょっと調べきれませんでした。
冒頭の画像の意味
仮想マシン上では、それぞれ以下しか選択できないという意味でした。
・1.チーミングモードにおいては1.1.「スイッチに依存しない」モード
・2.負荷分散モードにおいては2.1.「アドレスのハッシュ」モード
EC2に限った話ではなく、仮想マシン全般でそのようです。
「他のモードを選べるようにならないの？」という質問に対して回答がなされているページを見つけましたが、私の乏しい英語力では会話のキャッチボールに失敗しているようにしか見えなかったので、深追いはやめました。
[Nic Teaming Setup Error]
https://social.technet.microsoft.com/Forums/en-US/193090d6-f7d5-4510-882c-a43a862b7f97/nic-teaming-setup-error?forum=winserver8gen
おわりに
オンプレから、（EC2をはじめとした）IaaSに切り替えることによってユーザが考慮しなくてよくなる領域というのは様々あるわけですが、こういった設定を見るにつけ、その存在が思い起こされ恩恵を感じたりします。AWSにおいてはルータすら暗黙的な存在なので、いわんやスイッチをや、というわけで、設計要素が減少していくさまを感じます。いずれ「IaaSなんてユーザの責任領域広すぎでしょ」、という時代が来るのでしょうか。
蛇足:帯域のことで思い起こされたはEBS最適化
EBS最適化とはEC2のパラメータの1つですが、何をもって最適化とされているか分かるでしょうか？答えは、「専用の帯域を確保することによってI/O性能を」です。
[20190320 AWS Black Belt Online Seminar Amazon EBS]より
https://www.slideshare.net/AmazonWebServicesJapan/20190320-aws-black-belt-online-seminar-amazon-ebs/13
普段意識することは少ないですが、EC2インスタンスとそれにアタッチされたEBSボリューム間は
ネットワークにより接続されており、物理的につながっているわけではありません。
最適化されていないインスタンスは、ボリュームに対するI/OとネットワークI/Oが同じ帯域で行われるため、ネットワークトラフィックが大きいときには、ディスクの読み書き速度に制限が生じることになります。
こういった裏側のことに思いを馳せると、少し満たされた気分になりますね。以上です。
