課題:1本のネットワークケーブルがボトルネックになる時
半年ほど前、同時接続数約1万人のEコマースサイトのデータベースクラスタを管理していました。フラッシュセールのピーク時、Grafanaのダッシュボードが真っ赤に染まりました。eth0インターフェースが950Mbpsに達し、1Gbpsのネットワークカードが限界を超えようとしていたのです。その結果、レイテンシが急増し、定期バックアップは停止し、トランザクションにはタイムアウトエラーが発生し始めました。
当時、古いスイッチインフラにSFP+ポートがなかったため、10Gbpsカードへのアップグレードは不可能でした。単に別のネットワークカードを追加して別のIPを割り当てるだけでは、アプリケーション側でロードバランスを行う必要があり、非常に複雑になります。さらに、唯一のLANケーブルのRJ45コネクタが緩んだだけで、サーバー全体が即座にオフラインになってしまうリスクもありました。
なぜLACP (802.3ad) が解決策になるのか?
Linuxは、さまざまなボンディング(Bonding)モードをサポートしています。しかし、パフォーマンスと安定性の両方が必要な場合、LACP(モード4)が最適な選択肢です。これにより、2枚の1Gbpsカードを1つの論理的な2Gbps回線として統合し、障害発生時には自動的にフェイルオーバーを行うことができます。
パケットの順序が入れ替わりやすい(out-of-order)モード0や、1本の回線しか使用しないモード1とは異なり、モード4はサーバーとスイッチの間でインテリジェントな「ハンドシェイク」を行います。1つの回線に問題が発生した場合、このプロトコルは数ミリ秒以内にその回線をグループから除外し、ユーザーのセッションを中断させることなく通信を継続します。
重要な注意点: LACPにはスイッチ側のサポートが不可欠です。サーバー側で設定しただけで、安価なアンマネージドスイッチに接続しても、システムは動作しません。
一般的なボンディングモードの比較
- Active-Backup (モード1): 安全性は高いですが、リソースが無駄になります。2枚のカードがあっても、帯域幅は1Gbpsに制限されます。
- Round-robin (モード0): 帯域幅を統合できますが、スイッチを選び、TCPパケットの到着順序が狂いやすいため通信品質が低下する恐れがあります。
- Adaptive Load Balancing (モード6): 標準的なスイッチでも動作しますが、安定性は標準的なLACPには及びません。
Linuxでの正しいLACPの実装手順
以下は、私がプロダクション環境に適用し、過去6ヶ月間安定して稼働している方法です。ネットワーク機器とサーバーの両方で並行して設定を行う必要があります。
1. スイッチの設定(Ciscoの例)
まず、物理ポートをポートチャネル(Port-Channel)にまとめます。例えば、Gi0/1とGi0/2を統合する場合:
interface Range GigabitEthernet0/1 - 2
channel-group 1 mode active
channel-protocol lacp
mode active 設定により、スイッチは接続を維持するためにLACPパケットを能動的に送信するようになります。
2. nmcliによる設定(RHEL/CentOS/AlmaLinux/Debian)
eth1 と eth2 の2つのインターフェースがあると仮定します。以下のコマンド(nmcli)を使用して bond0 という名前の仮想インターフェースを作成します:
# 最適なパラメータでbond0インターフェースを作成
nmcli connection add type bond con-name bond0 ifname bond0 bond.options "mode=4,miimon=100,lacp_rate=1,xmit_hash_policy=layer3+4"
# 物理カードをグループに追加
nmcli connection add type ethernet slave-type bond con-name bond0-eth1 ifname eth1 master bond0
nmcli connection add type ethernet slave-type bond con-name bond0-eth2 ifname eth2 master bond0
# 静的IPの設定
nmcli connection modify bond0 ipv4.addresses 192.168.1.100/24 ipv4.gateway 192.168.1.1 ipv4.method manual
# システムの有効化
nmcli connection up bond0
ヒント: xmit_hash_policy=layer3+4 を使用することをお勧めします。このオプションは、デフォルトのMACアドレスベースではなく、IPとポートの両方に基づいて負荷分散を行うため、両方の回線の帯域幅を最大限に活用できます。
3. UbuntuでのNetplanによる設定
/etc/netplan/01-netcfg.yaml ファイルを開き、内容を以下のように編集します:
network:
version: 2
ethernets:
eth1: {}
eth2: {}
bonds:
bond0:
interfaces: [eth1, eth2]
addresses: [192.168.1.100/24]
routes:
- to: default
via: 192.168.1.1
parameters:
mode: 802.3ad
mii-monitor-interval: 100
lacp-rate: fast
transmit-hash-policy: layer3+4
徹夜のデバッグから得た教訓
最も記憶に残っている失敗は、ピーク時にのみ約3%のパケットロスが発生したことです。一見するとすべてのパラメータが正常でしたが、夜の10時になるとシステムが不安定になりました。
詳細に調査した結果、LANケーブルの1本に軽微な物理障害があり、インターフェースが数ミリ秒間隔で頻繁に「up/down」を繰り返していることがわかりました。miimon=100 の設定が敏感すぎたため、ボンディングがそのカードの除外と追加を繰り返し、不安定さを引き起こしていました。
LACPの状態を最も正確に確認するには、次のコマンドを使用します:
cat /proc/net/bonding/bond0
Partner Mac Address の行に注目してください。値が 00:00:00:00:00:00 になっている場合、スイッチ側の設定が間違っているか、LACPプロトコルが認識されていません。
成功のためのチェックリスト:
- 常に
ethtool eth1で各ネットワークカードの速度(Speed)と全二重(Duplex)設定が一致していることを確認してください。 - Webサービスやデータベースの場合、負荷分散を最適化するために
layer3+4を優先的に使用してください。 - 品質の低いケーブル1本が、LACP全体のパフォーマンスを低下させる可能性があります。新しいケーブルへの交換を惜しまないでください。
LACPの実装は、単なる帯域幅の統合ではありません。これは、予測できないインフラ障害に対して、サービスの強固な保護レイヤーを構築する方法なのです。

