お仕事にて、またまたよく分からない用語が出てきました。
ので、今回はチーミングについて勉強してみます。
もくじ
１．チーミングとは
２．なぜチーミングをするのか？
３．チーミング方式① フォールトトレランス
４．チーミング方式② リンクアグリゲーション
５．チーミングしてみる
あとがき
１．チーミングとは
複数の物理NICを、論理的に１つのNICとしてまとめる技術。
（NIC＝ネットワークインタフェースカード。ネットワークに接続する時の窓口になるやつ。）
ボンディング、リンクアグリゲーションと呼ばれることもある。
２．なぜチーミングをするのか？
冗長化による、NICの高可用性を実現するため。
万が一のNICの障害や故障に備えて、複数のNICを用意し、１つが落ちても他でカバーできるようにしている。
３．チーミング方式① フォールトトレランス
チーミングのやり方は主に２つある。
そのうち１つめがフォールトトレランスと呼ばれる方式。アクティブ-スタンバイ形式の、複数のNICにより構成される。
平常時は、アクティブ側のNICが通信をしており、スタンバイ側のNICは動かない。
しかしアクティブNICに故障や障害が発生したとき、スタンバイ側のNICが、アクティブだったNICに代わって役割を果たしてくれる。二重障害が起きない限り、サービスが止まらないようになっている。
４．チーミング方式②リンクアグリゲーション
チーミング方式の２つめは、リンクアグリゲーションと呼ばれる。
フォールトトレランス方式とは異なり、平常時も各NICがActive状態となっているところが特徴である。
先ほどのフォールトトレランス方式では、平常時はスタンバイするNICがあるために、常に１つのリソースを休ませておく（活用できない）。それはリソースの有効活用ができないことを意味する。
リンクアグリゲーションでは、複数あるリソースを普段からフル活用して、負荷分散をはかることができる。
一方で、フォールトトレランス方式では、アクティブNICに万が一が起きたときに、
・万全な状態のスタンバイNICに切り替えられる
・平時と負荷が変わらない
といった安心感がある。
リンクアグリゲーションでは、平時は複数のNICで負荷分散していたところを、
障害発生時には普段より少ない数のNICで対応する必要がある。そのため、生きているNICに大きな負荷がかかり、最悪の場合落ちてしまう可能性が出てくる。
負荷をあらかじめきちんと想定して、適切な方式や適切なNICの数を設定することがとても重要である。
５．チーミングしてみる
チーミング＝NICの冗長化ということは、ネットワーク機器での設定かと思いきや、OSで設定するらしい。
ので、、Linux環境にて設定してみたいと思う。
＊環境： CentOS8
＊設定ツール： Network Manager
※Network Managerとは →以前の記事をどうぞ。
…と思ったけど、上記CentOS8のVMを動かしている土台（VMware Workstation 16 Player）が、
デフォルトではNICが１枚設定で、GUI設定画面からは変えられないことが判明。。
ということで先にそちらを変更する。
■事前準備：NICを２枚にする
VMのホスト環境にて、VMファイルを入れているフォルダ内のvmxファイルを開く。
デフォルトでは１つしかNICがないので、ethernetに関する設定も、"ethernet0"の１つしかない。
（以下、ethernetに関する設定のみ抜き出し、一部値を改変）
ethernet0.connectionType = "nat"
ethernet0.addressType = "generated"
ethernet0.virtualDev = "e1000"
ethernet0.present = "TRUE"ethernet0.pciSlotNumber = "33"
ethernet0.generatedAddress = "xxxxxxxx"
ethernet0.generatedAddressOffset = "0"
ちなみにこの状態で、VMの接続を見てみると、以下のようにethernetは１つであることが分かる。
$ nmcli device status
DEVICE TYPE STATE CONNECTION
ens33 ethernet connected ens33 ←こいつ
virbr0 bridge unmanaged --
lo loopback unmanaged --
virbr0-nic tun unmanaged --
２つめのethernetとして、ethernet1を追加してみる。（VMは必ずシャットダウンしたうえで追加。）
今回はチーミングを試したいので、ethernet0と同じ設定になるようにした。
ethernet0.connectionType = "nat"
ethernet0.addressType = "generated"
ethernet0.virtualDev = "e1000"
ethernet0.present = "TRUE"ethernet1.connectionType = "nat"
ethernet1.addressType = "generated"
ethernet1.virtualDev = "e1000"
ethernet1.present = "TRUE"
ethernet0.pciSlotNumber = "33"ethernet0.generatedAddress = "xxxxxxxx"
ethernet0.generatedAddressOffset = "0"
設定ファイルを保存してVMを起動させ、接続デバイスを見てみると…
$ nmcli device status
DEVICE TYPE STATE CONNECTION
ens33 ethernet connected ens33
ens37 ethernet connected Wired connection 1 ←増えた
virbr0 bridge unmanaged --
lo loopback unmanaged --
virbr0-nic tun unmanaged --
新しくens37というデバイスが増えているのが分かる。
ただ、接続名（CONNECTION）が、Wired connectoin 1となっており、名称にスペースが入っていると、後々面倒なことになる。
そこで、もともとあったens33にならい、ens37という名前の接続に変更したいと思う。
変更にあたり、まずはens37のUUIDをチェック。
$ nmcli connection show
NAME UUID TYPE DEVICE
ens33 899856f4-5c89-491c-aaef-b88ac83af2a9 ethernet ens33
ens37 b0965ac4-70b8-3750-8633-bd399d1e4f3c ethernet Wired connection 1
virbr0 f32e523a-b098-439f-ba9a-a567e6e571f6 bridge virbr0
testconnect-port1 e5e86453-cf45-4232-8c48-6d340505bd73 ethernet --
このUUIDを使って、nmcliで値を編集する。
まずは現状の詳細を確認。
$ nmcli connection show b0965ac4-70b8-3750-8633-bd399d1e4f3c
connection.id: Wired connection 1
connection.uuid: b0965ac4-70b8-3750-8633-bd399d1e4f3c
connection.stable-id: --
connection.type: 802-3-ethernet
connection.interface-name: ens37
：
：
一番上のconnection.idというやつを変更すればいいことが分かる。
１回のコマンドで変更する方法もあるが、ここでは対話形式で変更する。
$ nmcli connection edit b0965ac4-70b8-3750-8633-bd399d1e4f3c
===| nmcli interactive connection editor |===
Editing existing '802-3-ethernet' connection: 'b0965ac4-70b8-3750-8633-bd399d1e4f3c'
Type 'help' or '?' for available commands.
Type 'print' to show all the connection properties.
Type 'describe [<setting>.<prop>]' for detailed property description.
You may edit the following settings: connection, 802-3-ethernet (ethernet), 802-1x, dcb, sriov, ethtool, match, ipv4, ipv6, tc, proxy
nmcli>
nmcliの対話コマンドが開くので、先ほど見た"connection.id"プロパティに、値「ens37」をセット。
設定を保存する。
nmcli> set connection.id ens37
nmcli> save
設定を確認。 "connection.id"の値が変わっていることが分かる。
nmcli> print
===============================================================================
Connection profile details (ens37)
===============================================================================
connection.id: ens37
connection.uuid: b0965ac4-70b8-3750-8633-bd399d1e4f3c
connection.stable-id: --
connection.type: 802-3-ethernet
connection.interface-name: ens37
connection.autoconnect: yes
対話形式を抜ける。
nmcli> quit
これで、NICの準備が整った。
■ということで本題、チーミング
RedHatの公式ドキュメントに従って、チーミングしてみる。
Network Managerのnmcliコマンドを使用する。
①まずは空のチーム（team）を作る。作ったチームに、チーミング対象のNICを加えていくことで、加えられたNIC同士でチーミングすることができるようになる。
$ nmcli connection add type team con-name testconnect ifname testteam team.runner activebackup
Connection 'testconnect' (bc9df11a-6969-40f5-911f-340fa5dc1cf2) successfully added.
意味：
"nmcli connection add type team"の部分で、チームを作る。
"con-name testconnect"は、testconnect（名称は任意）という名前の接続を作る。
"ifname testteam"は、testteam（名称は任意）という名前の接続を作る。
"team.runner"は、ランナーの指定箇所。ランナーによって、チームがどういった動きをするかが決まってくる。
今回のように"active-backp"とすると、１つをアクティブ、その他をスタンバイとして扱う設定となり、
つまりフォールトトレランス方式でチーミングを設定するということになる。
その他、"active-backp"の代わりに、主に以下のような設定をすることもできる。
・broadcast (データは全ポートで送信される）
・round-robin (データは全ポートで順番に送信される）
・loadbalance (アクティブ Tx 負荷分散と BPF ベースの Tx ポートセレクターを使用する)
・lacp (802.3ad リンクアグリゲーション制御プロトコルを実装する）
②接続をチームに加えていく。
１つめ
$ nmcli connection add type ethernet slave-type team con-name testconnect-port1 ifname ens33 master testteam
Connection 'testconnect-port1' (e5e86453-cf45-4232-8c48-6d340505bd73) successfully added.
２つめ
$ nmcli connection add type ethernet slave-type team con-name testconnect-port2 ifname ens37 master testteam
Connection 'testconnect-port2' (871ba1c7-1773-4e68-a535-b73d77fd6388) successfully added.
③チームにIPアドレスを与える。
ここでデフォルトゲートウェイやDNSの設定も可能だが、今回はとりあえずチームのIP設定のみとする。
また、IPv6での構成も可能。
$ nmcli connection modify testconnect ipv4.addresses '192.168.227.133/24'
④設定をアクティブにする。
$ nmcli connection up testconnect
Connection successfully activated (master waiting for slaves) (D-Bus active path: /org/freedesktop/NetworkManager/ActiveConnection/6)
⑤確認！！
$teamdctl testteam state
setup:
runner: activebackup
runner:
active port:
…あれ(´・ω・`)
フォールトトレランス方式なので、active portに、アクティブな接続（ens33かens37のどちらか）が出るはずだが、出ない。。
でも今日は時間が無くなってきたので、残りは次回に回したいと思います。
2021/03/28追記：
翌日もう一度同じコマンドを打ったら、なんか成功してました。
設定反映のためには、VMを再起動する必要があったようです(^-^;
$ teamdctl testteam state
setup:
runner: activebackup
ports:
ens37
link watches:
link summary: up
instance[link_watch_0]:
name: ethtool
link: up
down count: 0
runner:
active port: ens37
この状態で、チームのIP（今回は192.168.227.133と指定）にping打ったら応答もありました。
$ ping 192.168.227.133 -c 3
PING 192.168.227.133 (192.168.227.133) 56(84) bytes of data.
64 bytes from 192.168.227.133: icmp_seq=1 ttl=64 time=0.247 ms
64 bytes from 192.168.227.133: icmp_seq=2 ttl=64 time=0.304 ms
64 bytes from 192.168.227.133: icmp_seq=3 ttl=64 time=0.241 ms
--- 192.168.227.133 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 46ms
rtt min/avg/max/mdev = 0.241/0.264/0.304/0.028 ms
あとがき
そういえば前にも可用性・サーバクラスタ構成の記事書いてました。
カタカナ用語としては違うのに、冗長化による可用性の考え方は、サーバもNICも同じなようです。
何度も書いてますが名称統一してほしいですね、、(´・ω・`)