背景と理由：ネットワークのボトルネックと単一障害点を克服する
6ヶ月前、私は4GB RAMを搭載した本番環境のUbuntu 22.04サーバーで、高可用性とネットワークスループットの向上の両方を確保するという共通の課題に直面していました。
単一のネットワークインターフェースは、特にピーク時の負荷や、50GBのデータベースバックアップ転送、突然のウェブトラフィックの急増といった大規模なデータ転送時に、重大なボトルネックとなっていました。そのNICが1つでも故障すれば、サーバーは孤立してしまいます。さらに、帯域幅を大量に消費するタスクは、簡単にリンクを飽和させ、全体的なパフォーマンスを低下させる可能性がありました。
そこで私は、以前から耳にはしていましたが、ライブ環境で本格的に試したことのなかったネットワークボンディングの実装を決意しました。そのコンセプトはシンプルかつ効果的です。複数の物理ネットワークインターフェースを単一の論理インターフェースに結合するのです。これにより、主に2つのメリットが得られます。
- スループットの向上（速度）： 複数のNICにトラフィックを分散させることで、サーバーが利用できる総帯域幅を効果的に増やすことができます。
- 冗長性（フェイルオーバー）： 1つの物理NICが故障した場合、トラフィックは自動的にボンディングまたはチーミング内の別のアクティブなNICに切り替わり、手動での介入なしに継続的なネットワーク接続を保証します。
これらはしばしば同じ意味で使われますが、ボンディング（bondドライバーを使用する古いカーネルレベルのアプローチ）とチーミング（teamdやNetworkManagerによって管理されることが多い、より新しく柔軟なアプローチ）を区別することは役立ちます。どちらも同様の目標を達成しますが、チーミングは一部のシナリオでより高度な機能と簡単な設定を提供します。私の本番環境では、長年の安定性から主にボンディングに焦点を当てましたが、チーミングも試しました。
私の目標は、トラフィックの急増を効率的に処理し、ネットワークハードウェアの障害に対する信頼性を提供する堅牢なネットワーク構成を確立することでした。6ヶ月間の連続稼働を経て、ネットワークボンディングとチーミングがどのように機能したかについての洞察を自信を持って共有できます。これらは期待された速度向上と冗長性のメリットを提供しただけでなく、正しく設定されれば驚くほど安定しており、管理も容易であることが証明されました。
インストール：適切なツールを入手する
設定に進む前に、必要なパッケージが必要です。従来のボンディングにはifenslaveユーティリティが不可欠です。ネットワークチーミングにはteamdデーモンが必要です。
Debian/Ubuntuベースのシステムの場合：
両方を1つのコマンドでインストールできます：
sudo apt update
sudo apt install ifenslave teamd -y
RHEL/CentOS/Fedoraベースのシステムの場合：
yumまたはdnfを使用します：
sudo dnf install ifenslave teamd -y
# または古いCentOSの場合：
sudo yum install ifenslave teamd -y
これらのパッケージがインストールされれば、システムはボンディングまたはチーミングされたインターフェースを作成する準備が整います。
設定：ボンディングまたはチーミングをセットアップする
ここからが主要な設定です。方法はLinuxディストリビューションと好みのネットワーク管理ツールによって異なります。私のUbuntu 22.04サーバーでは、netplanが標準であり、ボンディングとよく連携します。チーミングの場合、特にNetworkManagerを使用するシステムでは、nmcliが強力なコマンドラインインターフェースです。
Netplanによるネットワークボンディング (Ubuntu 22.04以降)
NetplanはYAMLファイルを使用してネットワーク構成を定義します。これらは通常/etc/netplan/にあります。ここでは、アクティブ/バックアップボンディングとバランス-RRボンディングの設定方法を示します。
アクティブ/バックアップモード（モード1）
このモードは冗長性に優れています。1つのNICがアクティブで、他のNICはスタンバイ状態を維持します。アクティブなNICが故障した場合、スタンバイNICが引き継ぎます。これは速度を向上させませんが、稼働時間を保証します。
Netplan設定ファイル（例：/etc/netplan/01-netcfg.yaml）を作成または編集します。enpXsXを実際のNIC名（例：enp1s0、enp2s0）に置き換え、IPアドレスをネットワークに合わせて調整することを忘れないでください。
network:
version: 2
renderer: networkd
ethernets:
enp1s0:
dhcp4: no
enp2s0:
dhcp4: no
bonds:
bond0:
interfaces: [enp1s0, enp2s0]
parameters:
mode: active-backup
mii-monitor-interval: 100
down-delay: 200
up-delay: 200
dhcp4: no
addresses: [192.168.1.10/24]
routes:
- to: default
via: 192.168.1.1
nameservers:
addresses: [8.8.8.8, 8.8.4.4]
mode: active-backup: ボンディングモードを指定します。mii-monitor-interval: 100: 100ミリ秒ごとにリンクステータスを確認します。down-delay: 200: リンクがダウンしたと宣言する前に200ミリ秒待ちます。up-delay: 200: リンクがアップしたと宣言する前に200ミリ秒待ちます。
バランス-RRモード（モード0）
このモード（ラウンドロビン）は、ロードバランシングとフォールトトレランスを提供します。パケットは、利用可能な最初から最後のスレーブインターフェースまで順次送信されます。これによりスループットが向上する可能性があります。ただし、パケットの再順序付けの問題なしに最適なパフォーマンスを得るには、スイッチでのLACP/802.3adサポートが必要となることが多いため、スイッチの構成を慎重に検討する必要があります。
network:
version: 2
renderer: networkd
ethernets:
enp1s0:
dhcp4: no
enp2s0:
dhcp4: no
bonds:
bond0:
interfaces: [enp1s0, enp2s0]
parameters:
mode: balance-rr
mii-monitor-interval: 100
dhcp4: no
addresses: [192.168.1.11/24]
routes:
- to: default
via: 192.168.1.1
nameservers:
addresses: [8.8.8.8, 8.8.4.4]
Netplanの設定を保存したら、適用します：
sudo netplan try
# 問題がなければ、永続的に適用します：
sudo netplan apply
NetworkManager (nmcli) を使用したネットワークチーミング
NetworkManagerは、特にデスクトップ環境やNetworkManagerがアクティブなサーバーで、チーミングを含むネットワーク構成を管理するための堅牢な方法を提供します。nmcliはそのコマンドラインインターフェースです。
アクティブ/バックアップチーミング
まず、チームマスターインターフェースを作成します：
sudo nmcli connection add type team con-name team0 ifname team0 config '{"runner": {"name": "activebackup"}}'
次に、物理NICをチームのスレーブとして追加します：
sudo nmcli connection add type team-slave con-name team0-slave1 ifname enp1s0 master team0
sudo nmcli connection add type team-slave con-name team0-slave2 ifname enp2s0 master team0
チームインターフェースのIPアドレスを設定します（例：静的IP）：
sudo nmcli connection modify team0 ipv4.addresses 192.168.1.20/24
sudo nmcli connection modify team0 ipv4.gateway 192.168.1.1
sudo nmcli connection modify team0 ipv4.dns "8.8.8.8 8.8.4.4"
sudo nmcli connection modify team0 ipv4.method manual
sudo nmcli connection up team0
またはDHCPの場合：
sudo nmcli connection modify team0 ipv4.method auto
sudo nmcli connection up team0
ロードバランシングチーミング（ラウンドロビン）
ラウンドロビンロードバランシングの場合、ランナー設定を変更します：
sudo nmcli connection add type team con-name team0-rr ifname team0-rr config '{"runner": {"name": "roundrobin"}}'
sudo nmcli connection add type team-slave con-name team0-rr-slave1 ifname enp1s0 master team0-rr
sudo nmcli connection add type team-slave con-name team0-rr-slave2 ifname enp2s0 master team0-rr
# 上記と同様にIPを設定します
sudo nmcli connection modify team0-rr ipv4.addresses 192.168.1.21/24
sudo nmcli connection modify team0-rr ipv4.gateway 192.168.1.1
sudo nmcli connection modify team0-rr ipv4.dns "8.8.8.8 8.8.4.4"
sudo nmcli connection modify team0-rr ipv4.method manual
sudo nmcli connection up team0-rr
IPアドレスの競合や問題を避けるため、チーミングやボンディング用に設定する前に、個々のNICをダウンさせることを忘れないでください。
検証と監視：すべてが機能していることを確認する
ボンディングまたはチーミングを設定したら、そのステータスを確認し、パフォーマンスを監視することが重要です。この手順により、設定が効果的であることが確認されます。
ボンディングステータスの確認
従来のボンディングの場合、/proc/net/bonding/ディレクトリに詳細情報があります：
cat /proc/net/bonding/bond0
出力には、ボンディングモード、各スレーブインターフェースのリンクステータス、MIIパラメータ、および現在アクティブなインターフェース（アクティブ/バックアップモードの場合）が表示されます。Link Status: upとSlave Interface: enp1s0（またはアクティブな方）を探してください。
チームステータスの確認
チーミングの場合、teamdctlユーティリティは非常に貴重です：
teamdctl team0 state
このコマンドは、アクティブなポート、ランナータイプ、リンクステータスなど、チームのステータスの包括的な概要を提供します。どのインターフェースがリンクされ、アクティブであるかを確認できます。
一般的なネットワークインターフェースのステータス
標準のip linkコマンドは、新しいボンディングまたはチーミングされたインターフェースとそのスレーブインターフェースを表示します：
ip link show bond0
ip link show team0
ボンディング/チームインターフェースがUP状態になっていることを確認できるはずです。
フェイルオーバーのテスト
これは冗長性にとって重要なテストです。私は本番サーバーでこのテストを何度も実行し、その完全な信頼性を確認しました。最も簡単な方法は、スレーブインターフェースに接続されているネットワークケーブルの1つを物理的に抜くことです。cat /proc/net/bonding/bond0またはteamdctl team0 stateを監視しながら、システムがリンク障害を迅速に検出し、別のアクティブなスレーブに切り替わるのを観察できるはずです。
あるいは、ip link setを使用してリンクダウンをシミュレートすることもできます（ライブシステムでは注意してください！）：
sudo ip link set enp1s0 down
# ボンディング/チームのステータスを監視
sudo ip link set enp1s0 up # 元に戻す
フェイルオーバー中には、一時的なパケットロス（通常は数回のping）が発生するかもしれませんが、接続はほぼ即座に再開され、セットアップの有効性が実証されるはずです。
パフォーマンスの監視
設定して数週間稼働させた後、すぐにそのメリットを実感しました。4GB RAMを搭載した本番環境のUbuntu 22.04サーバーで、このアプローチにより、100GBのデータベースバックアップの転送や大規模なDockerイメージのプルなど、ネットワークI/Oが大量に発生するタスクの処理時間が最大30%削減されることがわかりました。システムははるかに応答性が高くなり、フェイルオーバーメカニズムが導入されているという安心感は非常に貴重でした。
ネットワーク使用量を監視し、トラフィックが実際に分散されているか、または結合された帯域幅が利用されているかを確認するには、iftopやnloadなどのツールが非常に役立ちます：
sudo apt install iftop nload -y # まだインストールされていない場合
iftop -i bond0 # または -i team0
nload bond0 # または team0
論理インターフェースを通過する総トラフィックが表示されます。ロードバランシングモードの場合、複数の接続がある場合、基盤となる物理NIC全体にトラフィックが分散されていることを観察できるかもしれません（ただし、iftop/nloadはボンディング/チームインターフェース自体の総量を表示します）。
最後に
Linuxでのネットワークボンディングまたはチーミングの実装は、私の本番環境にとって大きなアップグレードとなりました。これは、より回復力があり、高性能なサーバーインフラストラクチャを構築するための基本的なステップです。
初期設定には、特にNetplanのYAML構文やnmcliコマンドに関して、細部への注意が必要ですが、速度と冗長性の両面における長期的な安定性とメリットは、労力をかける価値が十分にあります。6ヶ月経った今、この戦略はサーバー環境をより堅牢で応答性の高いものにし、その価値を証明したと自信を持って言えます。
