アプローチの比較：LinuxネットワークボンディングにおけるNetplanとNetworkManagerの違い
重要な本番ワークロードを単一のネットワークインターフェースカード（NIC）で運用することは、運用上きわめて大きなリスクを伴います。LANケーブルの緩みやSFP+トランシーバーの故障、スイッチポートの不具合が発生するだけで、ホスト全体がオフラインになってしまいます。ネットワークボンディングは、この単一障害点（SPOF）を解消する技術です。複数の物理NICを1つの論理インターフェースに束ねることで、シームレスなフェイルオーバーと全体的なスループットの向上を実現できます。
近年のエンタープライズLinuxディストリビューションでは、主に2つのツールでネットワークを管理します。Netplan（Ubuntu 20.04/22.04/24.04およびDebian 12のデフォルト）と、NetworkManager / nmcli（RHEL 8/9、AlmaLinux、Rocky Linux、Fedoraなどの標準）です。
NetplanとNetworkManagerのアーキテクチャ
- Netplan（宣言型YAML）： Netplanは
/etc/netplan/配下のYAMLファイルを解析し、バックエンドのsystemd-networkdまたはNetworkManager向けの状態ファイルを生成します。設定をGitで管理し、cloud-init、Ansible、Terraformなどを活用する自動デプロイパイプラインと非常に相性が良い構成です。 - NetworkManager（動的デーモン＆CLI）： NetworkManagerは
nmcliを使用して実行時に動的な接続設定を行います。接続プロファイルは/etc/NetworkManager/system-connections/に保存され、ネットワークスタックを再起動することなく即座に変更を適用できます。
ボンディングモード：LACP（Mode 4）とActive-Backup（Mode 1）
接続先となる上位ネットワークスイッチの対応状況に応じて、適切なボンディングモードを選択してください。
- Mode 4（802.3ad 動的リンクアグリゲーション / LACP）： 複数のインターフェースを1つの論理パイプに束ねます。送信トラフィックは、送信ハッシュポリシー（Layer 3+4のIPおよびポートによるハッシュなど）に基づいてアクティブなリンク間で負荷分散されます。このモードを使用するには、上位スイッチ側でアクティブなLACPポートチャネル（LAG）が設定されている必要があります。
- Mode 1（Active-Backup）： 常に1つのスレーブNICのみがアクティブになります。アクティブなリンクでキャリア信号の切断（リンクダウン）が検出された場合にのみ、ミリ秒単位で待機系のスレーブが処理を引き継ぎます。スイッチ側の特別な設定は不要です。
設定手法と各モードのメリット・デメリット
Netplan
メリット：
- 見通しの良い宣言型YAML形式のため、ピアレビューやGitOpsによる構成監査が容易になります。
netplan tryコマンドにより120秒の自動ロールバックタイマーが機能し、リモート接続の切断事故を防ぐことができます。- Ubuntuエコシステム全体にプリインストールされ、密接に統合されています。
デメリット：
- インデントのルールが厳格なため、タブや不要なスペースが1つあるだけでパースエラーになります。
- 単体のネットワークサービスではなく、設定レンダラーのラッパーとして動作します。
NetworkManager (nmcli)
メリット：
nmcliのTab補完機能により、緊急時のトラブルシューティングでも迅速に手動設定が行えます。- アクティブなインターフェースに対してプロファイルの変更を即座に適用できます。
- エンタープライズ向けのRHEL、AlmaLinux、Rocky Linuxなどの環境で共通したコマンド構文が利用可能です。
デメリット：
- フラットなYAMLマニフェストと比較すると、自動化におけるテンプレート作成がやや煩雑になります。
- テストを繰り返すと、不要になった接続プロファイルやUUIDの不整合が残りやすくなります。
LACP（Mode 4）とActive-Backup（Mode 1）の比較
| 項目 | LACP (Mode 4 / 802.3ad) | Active-Backup (Mode 1) |
|---|---|---|
| スイッチの要件 | 802.3ad Port-Channel / LAGが有効化されたマネージドスイッチ | アンマネージドスイッチや独立した個別スイッチでも動作可能 |
| 利用可能な帯域幅 | 全リンクの合計容量（例：10GbE×2構成の場合、並行ストリーム全体で最大約20Gbps） | 単一インターフェースの速度に制限（例：最大10Gbps） |
| フェイルオーバー速度 | 1秒未満で検知（高速な1秒周期のLACPDUで1000ms未満） | リンクのMIIポーリング間隔に基づき通常100ms〜300ms |
推奨構成
マネージドスイッチに接続されたベアメタルのデータベースノード、ハイパーバイザー、ストレージサーバーでは、layer3+4 送信ハッシュポリシーを指定した Mode 4 (802.3ad) LACP の利用を推奨します。送信元/宛先のIPアドレスおよびTCP/UDPポート番号をハッシュ化することで、Linuxはすべての物理リンクにトラフィックを均等に分散します。
作業を始める前に、以下の点を確認してください。
- 2つの物理インターフェースが利用可能であること（例：1GbE×2の
enp3s0/enp3s1、または10GbE SFP+×2のens1f0/ens1f1）。 - 上位スイッチのポートがアクティブなLACPトランクグループに割り当てられていること（例：Cisco IOSの
channel-group 1 mode active）。 - 万が一に備え、アウトオブバンド管理（IPMI、iDRAC、シリアルコンソールなど）へのアクセス手段が確保されていること。
Dell PowerEdgeサーバー上のUbuntu 22.04 LTS環境（Intel X520 10GbEデュアルNIC構成）で稼働する2ノードのPostgreSQLレプリケーションクラスターでは、このLACP構成により、マルチスレッドのDBスナップショット転送速度が単一リンク飽和時の114 MB/sからボンド経由で218 MB/sへと向上しました。
実装手順
ステップ1：物理インターフェースの確認とカーネルモジュールのロード
システムで利用可能なネットワークインターフェースを確認します。
ip link showLinuxのボンディングモジュールをロードし、再起動後も永続的に読み込まれるよう設定します。
sudo modprobe bonding
echo "bonding" | sudo tee /etc/modules-load.d/bonding.confステップ2A：NetplanによるLACPボンディングの設定（Ubuntu / Debian）
/etc/netplan/ 配下にある主要なNetplan設定ファイル（通常は 01-netcfg.yaml または 50-cloud-init.yaml）を確認し、必ず事前にバックアップを作成します。
network:
version: 2
renderer: networkd
ethernets:
enp3s0:
dhcp4: no
enp3s1:
dhcp4: no
bonds:
bond0:
interfaces:
- enp3s0
- enp3s1
addresses:
- 192.168.1.50/24
routes:
- to: default
via: 192.168.1.1
nameservers:
addresses:
- 1.1.1.1
- 8.8.8.8
parameters:
mode: 802.3ad
lacp-rate: fast
mii-monitor-interval: 100
transmit-hash-policy: layer3+4構文を安全に検証します。変更によって接続が切断された場合でも、120秒以内にEnterキーを押さなければNetplanが自動的に以前の設定へロールバックします。
sudo netplan try問題がないことを確認したら、変更を恒久的に適用します。
sudo netplan applyステップ2B：NetworkManagerによるLACPボンディングの設定（RHEL / AlmaLinux / Rocky）
以下の nmcli コマンドを実行して、ボンドマスターを作成し、スレーブインターフェースを紐付けます。
# 1. ボンドマスタープロファイルの作成
sudo nmcli connection add type bond con-name bond0 ifname bond0 \
bond.options "mode=802.3ad,lacp_rate=fast,miimon=100,xmit_hash_policy=layer3+4" \
ipv4.addresses 192.168.1.50/24 ipv4.gateway 192.168.1.1 \
ipv4.dns "1.1.1.1 8.8.8.8" ipv4.method manual
# 2. 物理スレーブインターフェースをボンドマスターへ割り当て
sudo nmcli connection add type ethernet con-name bond0-slave1 ifname enp3s0 master bond0
sudo nmcli connection add type ethernet con-name bond0-slave2 ifname enp3s1 master bond0
# 3. スレーブリンクおよびボンドマスターの有効化
sudo nmcli connection up bond0-slave1
sudo nmcli connection up bond0-slave2
sudo nmcli connection up bond0ステップ3：ボンドステータスとLACPアグリゲーションの確認
カーネルのボンディングドライバーが出力する現在のステータスを確認します。
cat /proc/net/bonding/bond0アクティブなAggregator IDが割り当てられ、全ポートで正常なリンク速度が出ているか確認します。
Ethernet Channel Bonding Driver: v5.15.0-generic
Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer3+4 (1)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
802.3ad info
LACP rate: fast
Min links: 0
Aggregator ID: 1
Number of ports: 2
Slave Interface: enp3s0
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Aggregator ID: 1
Slave Interface: enp3s1
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Aggregator ID: 1ステップ4：フェイルオーバーの実機検証
外部マシンまたは別のターミナルから、デフォルトゲートウェイに向けて高頻度でICMP pingを実行します。
ping -i 0.2 192.168.1.1物理ポートの1つを強制的にリンクダウンさせ、インターフェース障害をシミュレートします。
sudo ip link set enp3s0 down/proc/net/bonding/bond0 を再確認すると、enp3s0 のステータスが MII Status: down に変化していることがわかります。この間もpingテストはパケットロスなしで enp3s1 を経由して継続します。インターフェースを再度有効化します。
sudo ip link set enp3s0 upLACPによって状態が再ネゴシエーションされ、1〜3秒以内に enp3s0 がアクティブなアグリゲーターへ再組み込みされます。
