ネットワークケーブルがシステムの「単一障害点」になる時
午前2時、電話が激しく鳴り響く。電話の向こうでは上司が「システムがダウンした、顧客がアクセスできない」と慌てている。ログを確認すると、古くなったLANケーブルの断線、あるいはスイッチポートの故障という苦い現実に直面する。わずか数百円のハードウェア故障が、数千人のユーザーを抱えるシステムを停止させたのだ。
かつてCentOS 7のサーバー群を管理していた際、私も同じような状況に陥ったことがある。当時は各サーバーに1本のケーブルしか接続しておらず、その1本に問題が起きるとサーバーは完全に孤立してしまった。教訓は明確だ。「単一のハードウェアデバイスを盲信してはならない」ということだ。
なぜネットワークカード1枚では不十分なのか？
単一のネットワークカード（NIC）を使用することには、常に2つの大きなリスクが伴う。
- Single Point of Failure (SPOF): ネットワークカードのドライバーエラーやケーブル断線だけで、サーバーは「孤立した島」になってしまう。
- ボトルネック (Bottleneck): データベースやファイルサーバーのように帯域を消費するサービスでは、1Gbpsのポートは頻繁に90〜100%の負荷に達する。これにより、アプリケーションのレスポンス速度が目に見えて低下する。
5台の重要なサーバーをCentOS Stream 9に移行する際、私はNetwork Teamingを使用してインフラを標準化した。これは、RHEL (Red Hat Enterprise Linux) クラスのエンタープライズレベルの安定性を実現するためのソリューションだ。
TeamingかBondingか：どちらがよりモダンな選択肢か？
長年Linux管理に携わっている人なら、Bondingに馴染みがあるだろう。しかし、RHEL 7以降、Network Teamingがより強力な代替手段として登場した。
Bondingは主にカーネル（kernel）内でロジックを処理する。対して、Teamingは teamd デーモンを介してユーザー空間（user-space）で処理を行う。このアプローチにより、Teamingは柔軟性が高く、拡張性に優れ、リンク監視もよりインテリジェントになっている。
CentOS Stream 9でのNetwork Teaming設定
最低2枚の物理ネットワークカードが必要だ。ここでは、サーバーに enp1s0 と enp2s0 という2枚のカードがあるとし、それらを team0 という仮想インターフェースに統合する。
ステップ1：ハードウェアの確認
まず、既存のインターフェースをリストアップして、ネットワークカードの名前を正しく特定する。
nmcli device statusdisconnected 状態にあるカード名をメモしておく。これらを次のステップで使用する。
ステップ2：メインのTeamインターフェース作成
CentOS 9の標準ツールである nmcli を使用する。ここでは activebackup モードを設定する。このモードでは、1枚のカードがメインで動作し、もう1枚が待機系となる。メインが故障した場合、1秒以内にサブのカードが切り替わる。
nmcli connection add type team con-name team0 ifname team0 config '{"runner": {"name": "activebackup"}}'帯域幅を統合して転送速度を上げたい場合は、 activebackup を loadbalance に変更する。
ステップ3：物理カードをTeamに割り当てる
次に、2枚の物理カードを team0 の「メンバー」として追加する。
# 1枚目のカードを割り当てる
nmcli connection add type team-slave con-name team0-slave1 ifname enp1s0 master team0
# 2枚目のカードを割り当てる
nmcli connection add type team-slave con-name team0-slave2 ifname enp2s0 master team0ステップ4：IPアドレスの設定
注意：個別のカード（enp1s0, enp2s0）にIPを設定してはいけない。すべてのIPパラメータは team0 インターフェースに直接設定する必要がある。
nmcli connection modify team0 ipv4.addresses 192.168.1.100/24
nmcli connection modify team0 ipv4.gateway 192.168.1.1
nmcli connection modify team0 ipv4.dns "8.8.8.8,8.8.4.4"
nmcli connection modify team0 ipv4.method manualステップ5：システムの有効化
スレーブインターフェースを先に有効化し、その後にメインのTeamを有効化して完了だ。
nmcli connection up team0-slave1
nmcli connection up team0-slave2
nmcli connection up team0実地テスト：理論だけで満足しない
IT業界では、テストされていない設定は無意味だ。Teamの状態を確認するには、以下のコマンドを使用する。
teamdctl team0 state「荒っぽい」テストを試してみよう。稼働中のカードのLANケーブルを抜くのだ。正しく設定されていれば、サーバーへの ping は1〜2パケット失われるだけで、残りのカードで正常に動作し続けるはずだ。これで枕を高くして眠ることができる。
一般的なRunnerモード
用途に応じて、JSONファイル内で適切な runner を選択できる。
- activebackup: 冗長性を優先。設定が簡単で、スイッチ側の設定変更は不要。
- roundrobin: 各カードにパケットを順番に転送し、帯域幅を増やす。
- loadbalance: インテリジェントなアルゴリズムを使用してトラフィックを分散する。
- lacp (802.3ad): 帯域幅統合のための最もプロフェッショナルなモード。注意：スイッチ側もLACPをサポートし、対応する設定が必要。
おわりに
Network Teamingの導入は難しくないが、それによって得られる価値は絶対的な安心感だ。最近のスイッチメンテナンス時、ラックの整理のためにLANケーブルをホットプラグ（活線挿抜）したが、サービスは止まることなく動き続けた。顧客からの苦情も、アラートの赤点灯も一切なかった。
本番環境のシステムにおいて、Network Teamingは必須の標準構成と考えるべきだ。皆さんの設定が成功することを願っている。
