一本のLANケーブルがシステム全体をダウンさせるとき
深夜2時、500GBのデータバックアップ処理が開始されたとします。その瞬間、シングルNICの1Gbps帯域は100%に達して飽和状態となり、データベースへの接続は完全に滞り、APIのタイムアウトが頻発します。さらに悪いことに、もしスイッチ側のポートが故障したり、誰かが誤ってRJ45コネクタを引っ掛けて抜いてしまったりすれば、サーバーは一瞬にしてネットワークから消失してしまいます。
物理層における単一障害点（SPOF）は、常にインフラ運用者の悪夢です。このリスクに対処するための標準的なアプローチが、2枚から4枚の物理ネットワークカード（NIC）を束ねて単一の論理インターフェースを構成することです。この構成には、利用可能な帯域幅を実質倍増させる効果と、万が一の障害発生時に数十ミリ秒以内にスタンバイ側のカードへ自動切り替えを行うという、2つの直接的なメリットがあります。
実戦比較：Bondingか、それともNetwork Teamingか？
Linux管理の世界では、主に2つのソリューションが利用されてきました。伝統的なBondingと、後発のNetwork Teamingです。
Bonding：カーネル空間で動作する高い安定性と実績
Bondingは、カーネルモジュールbonding.koを介して20年以上にわたりLinuxシステムを支え続けてきました。最大の強みは、その圧倒的な普及度と実績にあります。Ubuntu、Debian、Alpine、あるいは古いバージョンのCentOSであっても、追加パッケージをインストールすることなく標準機能として安定稼働します。
従来、Bondingはすべての設定変更がカーネル空間で行われるため柔軟性に欠けるとみなされることもありました。しかし、RHEL 9以降、Red Hatは公式にBondingの利用を推奨し、Teamingを非推奨（deprecated）に指定しました。最新のLinuxカーネルにおいて、Bondingのパフォーマンスが大幅に最適化されたことがその理由です。
Teaming：モジュール化を目指した分離アーキテクチャ
Network Teaming（teamdデーモンによって制御）は、データ処理自体をカーネルで行いつつ、制御ロジックをユーザー空間へ切り離したアーキテクチャを採用しています。これにより、JSON形式を用いた直感的な設定管理が可能になりました。また、IPv6環境向けのarp_pingやnsna_pingといった高度なリンク監視アルゴリズムもサポートしています。
現在運用中の環境がRHEL 7、RHEL 8、あるいはCentOS Stream 8である場合は、Teamingも依然として非常に優れた選択肢となります。
把握しておくべき4つの動作モード
- active-backup (Mode 1)： ある時点で通信を行うのは1系統のNICのみで、もう片方はスタンバイ状態を維持します。メインのリンクが切断されると、約100msでバックアップ側が処理を引き継ぎます。高可用性（HA）が求められるデータベースサーバーに最適です。
- round-robin (Mode 0)： パケットを各ポートへ順番に分散して送信します。理論上の帯域幅は倍増します。注意点： このモードはTCPストリーム上でパケットの順序逆転（packet reordering）を引き起こしやすく、スイッチ側で適切な最適化が行われていないと実効スループットが低下する恐れがあります。
- 802.3ad / LACP (Mode 4)： エンタープライズ環境で標準的に用いられる高機能なリンクアグリゲーション規格です。サーバーとスイッチの間でLACPプロトコルを用いて動的に負荷分散をネゴシエーションします。このモードを有効化する前に、CiscoやJuniperなどのスイッチ側でPort-Channelの設定を行う必要があります。
- balance-tlb / balance-alb (Mode 5 & 6)： スイッチ側の特別な設定を必要とせず、MACアドレスやARPテーブルに基づいて自動的に負荷分散を行います。
nmcliによる実践設定ガイド
物理サーバーに未使用のNICが2枚（enp1s0およびenp2s0）存在すると仮定します。これらを1つの論理インターフェースに統合し、固定IPアドレス192.168.1.150/24を割り当てる設定を進めます。
選択肢1：Linux Bondingの構成（現在の主要ディストリビューション推奨）
リンク監視インターバル（miimon）を100msとしたactive-backupモードで、仮想インターフェースbond0を作成します：
sudo nmcli connection add type bond con-name bond0 ifname bond0 bond.options "mode=active-backup,miimon=100"
2枚の物理NICをbond0のポート（スレーブ）として追加します：
sudo nmcli connection add type ethernet con-name bond0-port1 ifname enp1s0 master bond0
sudo nmcli connection add type ethernet con-name bond0-port2 ifname enp2s0 master bond0
bond0に対して固定IP、デフォルトゲートウェイ、DNSを設定します：
sudo nmcli connection modify bond0 ipv4.addresses 192.168.1.150/24 \
ipv4.gateway 192.168.1.1 \
ipv4.dns "1.1.1.1 8.8.8.8" \
ipv4.method manual
bondインターフェースと各メンバーポートを有効化します：
sudo nmcli connection up bond0
sudo nmcli connection up bond0-port1
sudo nmcli connection up bond0-port2
安全運用の注意点： SSH経由でリモートサーバーを操作する場合、現在接続に使用しているNICに対して直接設定を変更しないでください。誤設定による締め出しを防ぐため、iLOやiDRACなどのアウトオブバンド管理インターフェース、またはレスキューコンソール経由で作業を行ってください。
カーネルから直接リンクの状態を確認します：
cat /proc/net/bonding/bond0
Currently Active Slaveの行を確認することで、現在どのインターフェースがアクティブとして通信を担当しているかを把握できます。
選択肢2：teamdによるNetwork Teamingの構成
RHEL/Rocky Linux 8環境の場合は、関連パッケージをインストールします：
sudo dnf install -y teamd NetworkManager-team
activebackupランナーを指定してteam0接続プロファイルを作成します：
sudo nmcli connection add type team con-name team0 ifname team0 config '{"runner": {"name": "activebackup"}}'
物理ポートをチームのメンバーとして追加します：
sudo nmcli connection add type team-slave con-name team0-port1 ifname enp1s0 master team0
sudo nmcli connection add type team-slave con-name team0-port2 ifname enp2s0 master team0
IPアドレスを設定し、各インターフェースを起動します：
sudo nmcli connection modify team0 ipv4.addresses 192.168.1.150/24 ipv4.gateway 192.168.1.1 ipv4.method manual
sudo nmcli connection up team0
sudo nmcli connection up team0-port1
sudo nmcli connection up team0-port2
teamdctlを使用してステータスを確認します：
sudo teamdctl team0 state
実機検証：ケーブル切断シミュレーション
冗長性の信頼性を検証するために、同一LAN内の別クライアントから継続的なpingを実行します：
ping -i 0.2 192.168.1.150
サーバー側で、現在アクティブになっているNIC（例：enp1s0）を意図的にリンクダウンさせてケーブル断を模擬します：
sudo ip link set dev enp1s0 down
クライアント側のping結果を確認してください。パケットロスは高々1パケット程度、あるいは完全に無瞬断（パケットロス0%）で通信が維持され、即座にenp2s0へactiveフラグが遷移することが確認できます。
主幹ポートを復旧させる場合：
sudo ip link set dev enp1s0 up
システムは通信を乱すことなく、ポートを自動的に利用可能状態へと復帰させます。
まとめ
物理ネットワークの冗長化は、突発的なケーブル抜けやスイッチ障害からサーバーを保護するだけでなく、本番環境のインフラ運用において不可欠な基本要件です。Ubuntu、Debian、あるいはRHEL 9以降で新規にサーバーを構築する場合は、長期的な保守性と互換性を考慮し、nmcliによるBonding構成を優先するのが確実です。一方、RHEL 8上で既存のteamd環境が安定稼働している場合は、次期メジャーアップグレードのタイミングまで無理に変更せずそのまま運用を継続して問題ありません。
