bondingで本番サーバのNIC冗長化を構築しフェイルオーバーと切り戻しを検証する

NIC冗長化が必要な背景とbondingの役割

本番サーバでNICが1枚しかない構成は、ハードウェア障害や誤ったケーブル抜去が即座にサービス断に直結します。物理的なネットワーク二重化を実現する手段として、Linuxカーネルが標準で備えるbondingドライバは長年にわたって運用現場で採用されてきました。複数のNICを1つの論理インターフェースとして束ね、冗長性やスループット向上を同時に実現できる点が特徴です。

bondingには複数の動作モード（mode）があり、用途によって選択が変わります。本番サーバのフェイルオーバー目的で最も広く使われるのはmode=1（active-backup）です。常時1枚のNICだけが通信を担い、障害検出時に待機中のNICへ切り替わります。スイッチ側にLACP（802.3ad）対応が必要なmode=4と異なり、mode=1はスイッチの設定変更なしで導入できるため、既存インフラへの影響が最小で済みます。

mode=2（balance-xor）やmode=0（balance-rr）はスループット向上を狙う構成ですが、スイッチのポートチャネル設定が必要であり、誤設定時にブロードキャストストームを引き起こすリスクがあります。フェイルオーバーを最優先にするならactive-backupを選ぶのが現場の定石です。

2026年現在の構成環境と前提条件

2026年時点でのLinux bonding設定は、ディストリビューションのネットワーク管理ツールの違いを意識する必要があります。RHEL 9系・Rocky Linux 9・AlmaLinux 9ではNetworkManagerが標準であり、従来の/etc/sysconfig/network-scripts/配下のifcfgファイルは非推奨となっています。Ubuntu 22.04 LTS以降およびDebian 12ではsystemd-networkdまたはNetplanが主流です。

bondingカーネルモジュール自体はどのディストリビューションでも同じですが、設定ファイルの書き方とコマンドが大きく異なります。以降の手順ではRHEL/Rocky Linux 9環境でのNetworkManager（nmcli）を主軸に解説し、systemd-networkd向けの差分は末尾でまとめます。

事前に確認すべき点は以下のとおりです。

• 物理NICが2枚以上存在し、それぞれのインターフェース名（例：ens3・ens4）を把握している
• NetworkManagerがアクティブであること（systemctl is-active NetworkManagerで確認）
• 対象NICに既存の接続プロファイルが紐づいている場合は事前に切断・削除が必要
• リモート作業の場合、管理用の別経路（IPMI/iDRAC/コンソール）を必ず確保する

NetworkManagerでのbonding設定手順（RHEL/Rocky 9系）

まずbond論理インターフェースの接続プロファイルを作成します。bond0という名前でmode=1・MIIモニタリング間隔100msの構成例です。

nmcli connection add type bond \
  con-name bond0 ifname bond0 \
  bond.options "mode=active-backup,miimon=100"

次にスレーブ（メンバー）インターフェースをbond0に紐づけます。ens3をプライマリ、ens4を待機系とする場合は以下のように設定します。

nmcli connection add type ethernet \
  con-name bond0-slave-ens3 ifname ens3 \
  master bond0

nmcli connection add type ethernet \
  con-name bond0-slave-ens4 ifname ens4 \
  master bond0

active-backupモードではプライマリ指定が重要です。再起動後もens3を優先させるには、スレーブプロファイルに+bond-slave.primary yesまたは接続プロファイルのプロパティで設定します。nmcliでの追記は次のとおりです。

nmcli connection modify bond0-slave-ens3 \
  +bond-slave.primary yes

bond0インターフェースにIPアドレスを設定します。静的IPの例を示します。

nmcli connection modify bond0 \
  ipv4.addresses "192.168.1.100/24" \
  ipv4.gateway "192.168.1.1" \
  ipv4.dns "192.168.1.53" \
  ipv4.method manual

設定を有効化します。リモート接続中の場合、以下のコマンド実行後に一時的に接続が途切れる可能性があるため、コンソール経由で作業するのが安全です。

nmcli connection up bond0
nmcli connection up bond0-slave-ens3
nmcli connection up bond0-slave-ens4

設定後の状態確認は/proc/net/bonding/bond0を参照します。Currently Active Slaveがens3であること、MII Status: upがスレーブ両方に表示されることを確認します。

cat /proc/net/bonding/bond0

フェイルオーバーの動作検証

フェイルオーバーの検証は、別端末から対象サーバに継続的にpingを送りながら行うのが基本です。パケットロスの発生時間でフェイルオーバー速度を評価します。

# 管理端末側でpingを継続実行
ping -i 0.2 192.168.1.100

サーバ側でプライマリNIC（ens3）をソフトウェア的にダウンさせます。物理ケーブルを抜く方法でも同等の検証が可能ですが、ソフトウェアダウンのほうが再現性が高く安全です。

ip link set ens3 down

MIIモニタリング間隔を100msに設定している場合、理論上の検出時間は100〜200ms程度です。ただし実際のパケットロス数はカーネルのスケジューリングやネットワーク経路によって1〜5パケット程度生じるケースが多く、ゼロロスを保証するものではありません。

切り替えが完了したことを次のコマンドで確認します。

cat /proc/net/bonding/bond0
# Currently Active Slave が ens4 に変わっていることを確認

また、カーネルログにフェイルオーバーの記録が残ります。

journalctl -k --since "1 minute ago" | grep -i bond

出力例としてbond0: link status definitely down for interface ens3・bond0: making interface ens4 the new active oneといったメッセージが確認できれば、フェイルオーバーが正常に動作しています。

切り戻し（フェイルバック）の確認手順

障害復旧後にプライマリNICへ自動で戻す動作（フェイルバック）は、active-backupモードではprimary_reselectオプションによって制御されます。デフォルト値はalwaysであり、プライマリが復活すると自動でアクティブスレーブが切り替わります。

ダウンさせていたens3を再度アップさせます。

ip link set ens3 up

MIIモニタリング間隔の2倍程度（デフォルト設定なら200ms前後）でens3がアップリンク検出され、/proc/net/bonding/bond0のCurrently Active Slaveがens3に戻ることを確認します。pingの継続結果でもパケットロスがほぼ生じないことが確認できれば、フェイルバックは正常です。

運用シナリオによっては自動フェイルバックを無効にしたい場面もあります。例えばNIC交換後に手動で切り戻しタイミングを制御したい場合、primary_reselect=failureを指定することで、待機系から戻るのをプライマリ障害時のみに限定できます。本番環境では計画作業のウィンドウを確保した上で切り戻すポリシーが多く見られます。

運用上の注意点と2026年環境での差分

MIIモニタリングとARPモニタリングの使い分けについて整理します。miimonはNICの物理リンク状態を監視するため、スイッチポートのダウンは検出できますが、スイッチ上流の障害（L3経路の切断など）は検出できません。外部ゲートウェイへの到達性まで監視したい場合はarp_interval・arp_ip_targetを組み合わせます。ただし両方を同時に有効にすることはできないため、要件に合わせて選択します。

bondingとteamingの選択について、RHEL 9時点でNetworkTeamingは非推奨となっており、RHEL 10では削除が予定されています。2026年現在の新規構築では迷わずbondingを選択するのが順当な判断です。既存のteaming設定が残っている環境では、bonding移行の計画を立てておくことが推奨されます。

Ubuntu/Debian系でsystemd-networkdを使う場合の差分を補足します。/etc/systemd/network/配下に.netdevファイルでbondインターフェースを定義し、.networkファイルでIPアドレスとスレーブの紐づけを設定します。Netplan（Ubuntu 22.04以降）を使う場合は/etc/netplan/*.yamlにbondingブロックを記述し、netplan applyで反映します。いずれの場合もbondingカーネルモジュール自体の動作は共通です。

仮想環境（KVM・VMware・Hyper-V）やクラウド（AWS・Azure）上のVMでは、bondingの動作制約に注意が必要です。ハイパーバイザーやクラウドのSDNが独自のNIC冗長化を提供している場合、ゲストOS上でのbonding設定が期待どおりに機能しないことがあります。特にAWSのENAドライバ環境ではactive-backupのみが公式サポートされており、LACPモードは非推奨です。物理サーバへの導入と同等の検証を、仮想環境でも必ず本番投入前に実施することが重要です。

設定変更後の永続性確認も忘れてはなりません。nmcli connection showで該当プロファイルがGENERAL.STATE: activatedとなっていること、そして実際に再起動後も設定が維持されることをステージング環境で確認してから本番に適用する流れが、現場での標準的なアプローチです。