背景と理由：1Gbpsの壁を打ち破る
昨年、私の主要な本番用ストレージサーバーがパフォーマンスの限界に達しました。標準的な1Gbpsリンクは、日常的なオフィスのトラフィックであれば余裕で処理できます。しかし、毎晩の4TBのバックアップと、25個以上のコンテナにわたる大量のDockerイメージのプルが重なると、途端に厳しくなります。これらの作業が重なっている間、ネットワークレイテンシは軽快な2msから300ms以上に跳ね上がり、Webサービスが実質的に停止状態に陥りました。私は選択を迫られました。10GbpsスイッチとSFP+モジュールに2,500ドルを投じるか、サーバーの筐体にすでにある4つの未使用のイーサネットポートを活用するかです。
リンクアグリゲーション・コントロールプロトコル（LACP）の実装は、論理的な解決策でした。このIEEE 802.3ad規格は、複数の物理インターフェースを1つの論理的なパイプにまとめます。これは、既存のハードウェアの寿命を延ばす必要がある人にとって不可欠なスキルです。LACPには2つの大きなメリットがあります。スループットの合計値を向上させることと、シームレスなフェイルオーバーを提供することです。ケーブルが一本抜けたりポートが故障したりしても, トラフィックは接続を切断することなく残りのリンクに移行します。
高トラフィック環境で数ヶ月使用した後も、安定性は完璧に保たれています。注意点として、LACPを使用しても単一の1GBファイルの転送が2Gbpsになるわけではありません。代わりに、利用可能なすべてのリンクにわたって、複数のユニークなトラフィックフローを分散させます。これにより、一人のヘビーユーザーが接続全体を飽和させ、チームの他のメンバーの速度を低下させるのを防ぐことができます。
インストール：Linux環境の準備
最近のLinuxカーネルにはデフォルトでボンディングのサポートが含まれていますが、適切な管理ユーティリティが必要です。UbuntuやDebianシステムは、歴史的に ifenslave パッケージに依存してきました。現在では Netplan や NetworkManager が主要な処理を行いますが、念のためボンディングモジュールの準備ができているか確認します。
# ボンディングツールのインストール
sudo apt update && sudo apt install ifenslave -y
# カーネルモジュールが有効であることを確認
lsmod | grep bondingネットワークサービスは通常、必要に応じてモジュールをロードします。上記のコマンドが何も返さなくても心配はいりません。設定を適用すれば有効になります。今回のラボ環境では、eno1 と eno2 という2つの物理インターフェースを使用し、これらを bond0 という新しい論理インターフェースにマージします。
設定：Linux側（NetplanとNMCLI）
サーバー環境では、私は Netplan を好んで使用します。YAMLの構文はクリーンで、バージョン管理との相性も抜群です。このセットアップでは、transmit-hash-policy が重要です。私は layer3+4 を使用しています。これはIPアドレスとポート番号に基づいてトラフィックをハッシュ化するため、HTTPSとデータベースのトラフィックが混在していても均等な分散が保証されるからです。
方法1：Netplan（Ubuntu/Debianに最適）
# /etc/netplan/01-netcfg.yaml
network:
version: 2
renderer: networkd
ethernets:
eno1:
dhcp4: no
eno2:
dhcp4: no
bonds:
bond0:
interfaces: [eno1, eno2]
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+4sudo netplan apply を実行して変更を確定させます。SSH経由で作業している場合は、sudo netplan try を使用してください。これにより安全タイマーが追加され、アクセスできなくなった場合に設定が元に戻るため、わざわざデータセンターまで車を走らせる事態を防げます。
方法2：NetworkManager（RHEL/AlmaLinux/Rockyに最適）
RHELベースのシステムでアドホックな変更を行うには、nmcli ツールの方が高速です。セカンダリクラスタのボンディングを構築するために、以下のコマンドを使用しました。
# ボンドインターフェースの定義
nmcli connection add type bond con-name bond0 ifname bond0 bond.options "mode=802.3ad,lacp_rate=1,mii=100,xmit_hash_policy=layer3+4"
# 物理「スレーブ」ポートの割り当て
nmcli connection add type ethernet con-name bond0-port1 ifname eno1 master bond0
nmcli connection add type ethernet con-name bond0-port2 ifname eno2 master bond0
# 静的IP詳細の設定
nmcli connection modify bond0 ipv4.addresses 192.168.1.51/24 ipv4.method manual ipv4.gateway 192.168.1.1
# リンクの有効化
nmcli connection up bond0スイッチ側：LACP / ポートチャネル
よくある落とし穴は、サーバーを設定してもスイッチ側の設定を忘れてしまうことです。802.3adを使用しているため、スイッチもネゴシエーションに能動的に参加する必要があります。スイッチが設定されていないと、スパニングツリープロトコル（STP）が二重接続をネットワークループと誤認し、ポートを完全に無効化してしまう可能性があります。
Ciscoのハードウェアでは、以下のコマンドを使用してポートをグループ化します。
interface range GigabitEthernet1/0/1 - 2
channel-group 1 mode active
description LinuxサーバーへのLACP接続
exit
interface Port-channel 1
switchport mode access
switchport access vlan 10
spanning-tree portfastモードを active に設定することは必須です。これにより、スイッチがサーバーに対してLACPパケットを送信するようになります。UbiquitiやMikroTikのユーザーは、GUIで「Aggregate」または「Bonding」を探し、モードが「Static/On」ではなく、明示的に 802.3ad に設定されていることを確認してください。
検証とモニタリング：動作の確認
ランプが点滅しているからといって、リンクが正常であると思い込まないでください。Linuxにおける信頼できる情報源は proc ファイルシステムです。このファイルは、LACPネゴシエーションのリアルタイムな状態を示します。
cat /proc/net/bonding/bond0「Partner Mac Address」を確認してください。これがすべてゼロになっている場合、サーバーはスイッチからデータを受信できていません。スイッチのMACアドレスと、「LACP activity: active」というステータスが表示されている必要があります。また、eno1 と eno2 の両方が「up」とマークされていることを確認してください。
実際のトラフィックを確認するには、nload を使用します。bond0 を監視すると合計のスループットが表示され、物理ポートを個別に確認することでロードバランシングが効果的に機能していることがわかります。
# 個別のリンクバランスを監視
nload eno1 eno2負荷テスト中、同期バックアップ時にサーバーは1.85Gbpsに達しました。これにより、layer3+4 ハッシュが両方のケーブルに負荷を効果的に分散させていることが確認できました。問題が発生した場合は、dmesg | grep bond を最初に確認して、リンクフラップエラーやドロップされたLACPパケットを探してください。
