Linuxのネットワークボンディングと802.3ad LACP：高可用性と広帯域幅を実現するリンクアグリゲーションの設定

Table of Contents

深夜2時の障害：ケーブル1本の接触不良がクラスターを停止させた瞬間

雨の降る火曜日の午前2時14分、PagerDutyの通知でスマートフォンが一斉に鳴動しました。データベースレプリカの遅延が400秒を超え、APIゲートウェイがHTTP 504エラーを記録し始め、分散NFSマウントが即座に読み取り専用モードへと切り替わったのです。プライマリのデータベースノードが何の前触れもなくネットワークから切断されていました。

アウトオブバンドのiDRACコンソール経由でリモート接続し、ip linkを確認しました。マシン自体には何の問題もありませんでした。CPU負荷は約8%にとどまり、メモリ使用量も128 GB中42 GBと安定しており、ディスクも健全でした。しかし、インターフェースeno1のステータスはstate DOWNを示していたのです。その夜早く、新しいサーバーをラッキングしていた技術者が、光ファイバーの配線ルートを変更する際に誤って緩んでいたパッチコードに触れてしまっていました。ホストが単一の物理アップリンクに依存していたため、RJ45コネクタが1つ緩んだだけで、トランザクションキュー全体が完全にフリーズしてしまったのです。

本番環境のワークロードで1本の物理ケーブルに依存することは、防ぐことのできるリスクです。レイヤ1およびレイヤ2の障害は、遅かれ早かれ必ず発生します。

根本原因：脆弱なリンクと帯域の枯渇

ベアメタルやハイパーバイザ環境において、単一インターフェースの構成は通常、主に2つの障害モードに直面します。

物理リンクの脆弱性： SFP+トランシーバーの故障、光パッチコードの曲がり、スイッチASICのフラッピング、あるいはラック内での不意の引っ張りによって、キャリア信号は瞬時に失われます。リンクアグリゲーションがなければ、Linuxカーネルは即座にソケットを切断し、アクティブなTCP接続がすべて破棄されます。
スループットのボトルネック： 毎晩実行される500 GBのPostgreSQLバックアップ、Cephのバックフィル処理、そして通常のクライアントトラフィックが、同じ1 Gbpsや10 Gbpsの帯域を取り合うケースが多々あります。使用率が95%を超えて急上昇すると、パケットロスが増加し、pingの応答時間が0.3 msから250 msへ跳ね上がり、ノードのハートビートが途絶えてしまいます。

Linuxは、カーネルレベルのbondingモジュールによってこれら双方のボトルネックを解消します。複数の物理ネットワークインターフェースカード（NIC）を1つの論理デバイス（通常はbond0）に統合することで、カーネルは健全なアダプター間でトラフィックを分散させ、いずれかのリンクがダウンした際も数ミリ秒以内にフレームをリルートします。

一般的なボンディングモードの比較：1、0、4

適切なボンディングプロファイルの選択は、スイッチのトポロジーやワークロードに直接依存します。Linuxカーネルは7種類のボンディングモードを実装していますが、本番環境への導入は主に次の3つに絞られます。

1. Mode 1: Active-Backup

1つの物理インターフェースがすべての本番フレームを伝送します。セカンダリインターフェースは、プライマリがキャリア信号を失うまで待機状態を維持します。

スイッチ側の要件： なし。アンマネージドのデスクトップスイッチや、スタック構成を持たない独立したアクセススイッチでも動作します。
スループット： 単一リンクの速度に制限されます（例：10 Gbpsポート2基の場合でも合計10 Gbps）。
最適な用途： アップストリームでのLACPやマルチシャーシトランキングが利用できない、完全に独立した2台のスイッチへの単純なデュアルホーム構成。

2. Mode 0: Round-Robin (Balance-RR)

カーネルはアクティブな全メンバーポートにパケットを順次送信します（パケット1はeno1から、パケット2はeno2から、というように送信）。

スイッチ側の要件： LACPネゴシエーションを行わない静的なアンマネージドEtherChannel（LAG）。
スループット： 生の帯域幅を全インターフェースに分散させます。
デメリット： パケットが受信側に順番通りに届かないケースが頻繁に発生します。これによりTCPの重複ACKがトリガーされ、輻輳ウィンドウが縮小し、実際の実効転送レートが激減します。一般的なTCPトラフィックではMode 0を避ける必要があります。

3. Mode 4: IEEE 802.3ad Dynamic Link Aggregation (LACP)

Mode 4はエンタープライズの標準です。ホストとスイッチがLink Aggregation Control Protocol Data Unit（LACPDU）を交換し、リンクの状態、伝送パラメータ、ポートメンバーシップを継続的にネゴシエーションします。

スイッチ側の要件： 対応するport-channelで802.3ad LACPが有効化されたマネージドスイッチ。
スループット： 複数の並行フローにわたってリンク容量を統合します。10 Gbpsリンク2本で20 Gbpsの集約帯域幅を提供します。ただし、ハッシュポリシーの制約により、個別の単一TCPストリームセッションは最大10 Gbpsとなります。
耐障害性： ダウンしたリンクを1秒未満で検出し、確立済みのTCPストリームを中断することなく、障害の発生したポートをアクティブなアグリゲーターから除外します。

ステップバイステップ：本番環境向け802.3ad LACPの実装

Mode 4は、自動フェイルオーバーと帯域幅の集約を両立します。以下に、スイッチポートからLinux OS側までの設定手順を示します。

ステップ1：アップストリームのスイッチポートを設定する

ホスト側のネットワークファイルを変更する前に、まずスイッチ側を設定します。サーバーが未設定のスイッチポートに対してLACPネゴシエーションを開始すると、ボンドは切断状態（detached state）に陥ってしまいます。以下はCisco CatalystまたはNexusスイッチのベースライン設定です。

interface range GigabitEthernet1/0/1 - 2
 description SRV-PROD-DB01-BOND0
 channel-group 10 mode active
 channel-protocol lacp
 exit

interface Port-channel 10
 description PO10-TO-DB01
 switchport mode access
 switchport access vlan 100
 spanning-tree portfast
 no shutdown

mode activeを設定することで、スイッチ側から即座にLACPネゴシエーションフレームが開始されるようになります。

ステップ2：NetplanでLACPを設定する（UbuntuおよびDebian）

最新のUbuntu環境（20.04 LTSから24.04 LTSまで）およびDebianシステムでは、Netplanを介してインターフェースを定義します。まずip linkを実行してインターフェースを特定します。この例では、eno1とeno2を集約します。

Netplanの設定ファイル（通常は/etc/netplan/配下）を開きます。

sudo nano /etc/netplan/01-netcfg.yaml

ethernets配下に生の物理ポートを定義し、bonds配下に集約リンクを構築します。

network:
  version: 2
  renderer: networkd
  ethernets:
    eno1:
      dhcp4: no
    eno2:
      dhcp4: no
  bonds:
    bond0:
      interfaces:
        - eno1
        - eno2
      addresses:
        - 192.168.100.50/24
      routes:
        - to: default
          via: 192.168.100.1
      nameservers:
        addresses:
          - 1.1.1.1
          - 8.8.8.8
      parameters:
        mode: 802.3ad
        lacp-rate: fast
        transmit-hash-policy: layer2+3
        mii-monitor-interval: 100

押さえておくべき設定のポイント：

mode: 802.3ad: 動的LACPトランキングを有効にします。
lacp-rate: fast: カーネルにハートビートフレームを30秒ごとではなく1秒ごとに送信させ、対向機器のタイムアウト検出を高速化します。
transmit-hash-policy: layer2+3: MACアドレスとIPアドレスの双方をハッシュ化します。これにより、デフォルトのlayer2（MACのみのハッシュ）に比べて、アウトバウンドフローが各ポートへはるかに均等に分散されます。
mii-monitor-interval: 100: MIIトランシーバーのレジスタを100ミリ秒ごとにスキャンし、ハードウェアリンクの切断を即座に検知します。

構文をテストして設定を適用します。

sudo netplan try
sudo netplan apply

ステップ3：NetworkManager / nmcliでLACPを設定する（RHELおよびRocky Linux）

RHEL、AlmaLinux、Rocky Linuxでは、nmcli経由でボンドを管理し、永続的なNetworkManagerプロファイルを生成します。

# 1. ボンドマスターデバイスを作成
sudo nmcli connection add type bond con-name bond0 ifname bond0 \
  bond.options "mode=802.3ad,lacp_rate=fast,xmit_hash_policy=layer2+3,miimon=100"

# 2. 静的IPアドレスを割り当て
sudo nmcli connection modify bond0 ipv4.addresses "192.168.100.50/24" \
  ipv4.gateway "192.168.100.1" ipv4.dns "1.1.1.1 8.8.8.8" ipv4.method manual

# 3. 物理インターフェースを配下に追加
sudo nmcli connection add type ethernet con-name bond0-port1 ifname eno1 master bond0
sudo nmcli connection add type ethernet con-name bond0-port2 ifname eno2 master bond0

# 4. リンクを起動
sudo nmcli connection up bond0-port1
sudo nmcli connection up bond0-port2
sudo nmcli connection up bond0

ステップ4：/procでボンドの健全性を確認する

netplanやnmcliの終了コードは、設定ファイルが構文解析されたことしか保証しません。必ずカーネルのライブボンディング診断情報を直接確認してください。

cat /proc/net/bonding/bond0

健全な2ポートバンドルの場合、次のようなステータス行が出力されます。

Ethernet Channel Bonding Driver: v5.15.0

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer2+3 (2)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
Peer Notification Delay (ms): 0

802.3ad info
LACP rate: fast
Min links: 0
Aggregator ID: 1
Number of ports: 2
Actor Key: 9
Partner Key: 10
Partner Mac Address: 00:2a:6a:11:22:33

Slave Interface: eno1
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 52:54:00:12:34:56
Slave queue ID: 0
Aggregator ID: 1
Actor chsn state: 63
Partner chsn state: 63

Slave Interface: eno2
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 52:54:00:12:34:57
Slave queue ID: 0
Aggregator ID: 1
Actor chsn state: 63
Partner chsn state: 63

メンテナンス作業を完了とする前に、2つの重要なフィールドを確認してください。

Partner Mac Address: アップストリームのスイッチのベースMACアドレスが表示されている必要があります。すべてゼロ（00:00:00:00:00:00）になっている場合、スイッチがLACP制御フレームに応答していません。
Aggregator ID: 両方のメンバーポートがまったく同じ整数（例：1）を報告している必要があります。IDが一致していない場合、スイッチ側でポートが異なるチャネルグループに割り当てられていることを意味します。

ステップ5：本番さながらのフェイルオーバードリルを実施する

新しいボンド経由で本番のユーザーセッションをルーティングする前に、障害復旧が正しく機能するか検証します。ターミナルを2つのセッションに分割してください。

ウィンドウ1で、デフォルトゲートウェイに向けて短い間隔でpingを実行します。

ping -i 0.2 192.168.100.1

ウィンドウ2で、ケーブルが抜けた状態をエミュレートするため、プライマリリンクを管理上ダウンさせます。

sudo ip link set eno1 down

pingの出力を観察します。lacp-rate: fastと100 msのMIIポーリング間隔のおかげで、eno2がアウトバウンドトラフィックを引き継ぐまでにドロップするICMPパケットは最大でも1個に抑えられるはずです。多くの環境では、パケットロスはゼロになります。

インターフェースをオンラインに復帰させます。

sudo ip link set eno1 up

再度cat /proc/net/bonding/bond0を確認します。2秒以内にeno1がアクター状態を同期し、スイッチとキーを一致させて、自動的にアクティブなアグリゲーターへ再合流するはずです。

本番運用のチェックリスト

LACPの設定にはサーバーチームとネットワークチーム間の連携が不可欠ですが、設定しておけば不慮のネットワーク障害を大幅に排除できます。運用にあたっては以下のルールを徹底してください。

transmit-hash-policyはlayer2+3またはlayer3+4に設定する。デフォルトのレイヤ2ハッシュでは、トラフィックが単一のゲートウェイMACを経由する場合、すべてのアウトバウンドパケットが1本のリンクに集中してしまいます。
データベースノード、ストレージサーバー、クラスタのハートビートなど、30秒のLACPタイムアウトでは長すぎる環境では、lacp-rate fastを採用する。
変更作業の完了前に、/proc/net/bonding/bond0でPartner Mac Addressが取得できていること、およびAggregator IDの値が完全に一致していることを確認する。