ネットワーク設定 · 5 min read · Nov 30, 2025
Linuxでのフェイルオーバーと高可用性ネットワークボンディングの設定方法
このチュートリアルでは、Linuxサーバーでのネットワークボンディングの設定方法を説明します。始める前に、ネットワークボンディングとは何か、何をするのかを説明します。Windows環境では、ネットワークボンディングはネットワークチーミングと呼ばれ、これは、主要なイーサネットケーブルのいずれかに故障や誤設定があるシナリオで、高可用性とフェイルオーバーを提供するのに役立つ機能です。
通常、これは本番目的でサーバーを設定する際に実装するべきベストプラクティスであり、必須の機能です。この機能はLinux環境の設定でも実行できますが、まずはネットワーク管理者に確認して、サーバーに接続されているスイッチがネットワークボンディングをサポートしていることを確認する必要があります。サーバー環境で実装できるボンディングモードはいくつかあります。以下は利用可能なモードのリストとその機能です:
- Balance-rr
このモードは、ラウンドロビンポリシーを介して負荷分散とフォールトトレランス(フェイルオーバー)機能を提供します。これは、最初の利用可能なスレーブから最後まで、パケットを順番に送信することを意味します。 - Active-Backup
このモードは、アクティブ-バックアップポリシーを介してフォールトトレランス機能を提供します。ボンディングイーサネットが上がると、1つのイーサネットスレーブのみがアクティブになります。他のイーサネットスレーブは、現在のアクティブスレーブが上がらなくなった場合にのみアクティブになります。このモードを選択すると、ボンディングMACアドレスが外部で1つのネットワークアダプタにのみ表示されることに気付くでしょう。これは、スイッチを混乱させないためです。 - Balance-xor
このモードは、負荷分散とフォールトトレランスを提供します。選択した送信ハッシュポリシーに基づいて送信します。代替送信ポリシーは、xmit_hash_policyオプションを介して選択できます。 - Broadcast
このモードは、フォールトトレランスのみを提供します。すべてのスレーブイーサネットインターフェースで全てを送信します。 - 802.3ad
このモードは、負荷分散とフォールトトレランスを提供します。同じ速度とデュプレックス設定を共有する集約グループを作成します。アクティブアグリゲーター内のすべてのスレーブイーサネットインターフェースを利用し、802.3ad仕様に基づいています。このモードを実装するには、ethtoolが各スレーブの速度とデュプレックスモードを取得するためのベースドライバーをサポートしている必要があります。スイッチも動的リンク集約をサポートする必要があります。通常、これには詳細な設定のためにネットワークエンジニアの介入が必要です。 - Balance-TLB
このモードは、名前のTLBが送信負荷分散を表すように、負荷分散機能を提供します。このモードでは、設定tlb_dynamic_lb = 1の場合、出力トラフィックは各スレーブの現在の負荷に応じて分配されます。設定tlb_dynamic_lb = 0の場合、負荷分散は無効になり、負荷はハッシュ分配のみを使用して分配されます。このモードでは、ethtoolが各スレーブの速度を取得するためのベースドライバーをサポートしている必要があります。 - Balance-ALB
このモードは、名前のTLBが適応負荷分散を表すように、負荷分散機能を提供します。balance-tlbと似ていますが、送信と受信のトラフィックの両方がボンディングされます。ARP交渉を達成することで負荷分散を受け取ります。ボンディングドライバーは、ローカルシステムから送信されるARP応答を傍受し、ソースハードウェアアドレスをボンド内のスレーブの一つのユニークなハードウェアアドレスで上書きします。このモードでは、ethtoolが各スレーブの速度を取得するためのベースドライバーをサポートしている必要があります。
- 予備ノート
このチュートリアルでは、Oracle Linux 6.4の32ビット版を使用しています。設定はOracle Linuxの下で行われますが、手順はCentOSやRed Hat OSディストリビューションおよび64ビットシステムにも適用されることに注意してください。私たちの例の設定の最終結果は、私が1つのイーサネットネットワークを無効にしても、ボンディングサーバーへの接続が維持されることを示します。この例では、アクティブ-バックアップポリシーであるモード1を使用してネットワークボンディングを適用する方法を示します。
- インストールフェーズ
このプロセスでは、インストールは必要ありません。サーバーのデフォルトのLinuxインストールには、ネットワークボンディング構成に必要なすべてのパッケージが含まれています。
- 設定フェーズ
設定を開始する前に、まずサーバーに少なくとも2つのイーサネットインターフェースが設定されていることを確認する必要があります。これを確認するには、ネットワーク構成フォルダに移動し、利用可能なイーサネットインターフェースをリストします。以下は手順です:
cd /etc/sysconfig/network-scripts/
ls *ifcfg*eth*結果は次のとおりです:
ifcfg-eth0 ifcfg-eth1 現在、サーバーに設定されている2つのイーサネットインターフェース、ETH0とETH1があることに注意してください。
次に、BOND0というボンディングインターフェースを設定します。このインターフェースは、ETH0とETH1の物理イーサネットインターフェースを含む仮想イーサネットインターフェースになります。以下は手順です:
vi ifcfg-bond0DEVICE=bond0
ONBOOT=yes
MASTER=yes
IPADDR=172.20.43.110
NETMASK=255.255.255.0
GATEWAY=172.20.43.1
BONDING_OPTS="mode=1 miimon=100"
TYPE=Ethernet 次に実行します:
ls *ifcfg*bon*結果は次のとおりです:
ifcfg-bond0 それでおしまいです。BOND0インターフェース内にIPアドレスを含めたことに注意してください。このIPアドレスは、サーバーに接続される唯一のIPアドレスになります。プロセスを進めるために、BOND0インターフェースに関連する物理イーサネットインターフェースを変更する必要があります。以下は手順です:
vi ifcfg-eth0DEVICE=eth0
TYPE=Ethernet
ONBOOT=yes
NM_CONTROLLED=no
MASTER=bond0
SLAVE=yes vi ifcfg-eth1DEVICE=eth1
TYPE=Ethernet
ONBOOT=yes
NM_CONTROLLED=no
MASTER=bond0
SLAVE=yes 完了しました。インターフェースETH0とETH1の変更を行いました。両方のインターフェース内のIPアドレスを削除し、MASTER = bond0を追加したことに注意してください。これは、両方のインターフェースがイーサネットBOND0インターフェースに専用の仮想インターフェースであることを確認するために必要です。
設定を進めるために、/etc/modprobe.dの下にbonding.confというボンディング設定ファイルを作成します。以下は手順です:
vi /etc/modprobe.d/bonding.confalias bond0 bonding
options bond0 mode=1 miimon=100 modprobe bonding 上記の設定に基づいて、インターフェースBOND0を使用してボンディングモジュールを設定しました。また、ボンディング設定をアクティブ-バックアップポリシーであるモード = 1を使用するように割り当てました。オプションmiimon = 100は、ボンディングサーバーがインターフェースの状態をミリ秒単位で監視する頻度を表します。上記の説明に従って、このモードはサーバーネットワーク構成においてフォールトトレランス機能を提供します。
すべてが設定されたので、新しい設定を読み込むためにネットワークサービスを再起動しましょう。以下は手順です:
service network restartインターフェースeth0をシャットダウンしています: [ OK ]
インターフェースeth1をシャットダウンしています: [ OK ]
ループバックインターフェースをシャットダウンしています: [ OK ]
ループバックインターフェースを起動しています: [ OK ]
インターフェースbond0を起動しています: [ OK ] 素晴らしい、これで上記で行った新しい設定が読み込まれました。ネットワークリストにBOND0という新しいインターフェースが表示されることに気付くでしょう。また、インターフェースETH0およびETH1にはIPアドレスが割り当てられておらず、BOND0インターフェースのみがIPを表示していることにも気付くでしょう。
ifconfigbond0 Link encap:Ethernet HWaddr 08:00:27:61:E4:88
inet addr:172.20.43.110 Bcast:172.20.43.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fe61:e488/64 Scope:Link
UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1
RX packets:1723 errors:0 dropped:0 overruns:0 frame:0
TX packets:1110 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:147913 (144.4 KiB) TX bytes:108429 (105.8 KiB) eth0 Link encap:Ethernet HWaddr 08:00:27:61:E4:88
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:1092 errors:0 dropped:0 overruns:0 frame:0
TX packets:1083 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:103486 (101.0 KiB) TX bytes:105439 (102.9 KiB) eth1 Link encap:Ethernet HWaddr 08:00:27:61:E4:88
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:632 errors:0 dropped:0 overruns:0 frame:0
TX packets:28 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:44487 (43.4 KiB) TX bytes:3288 (3.2 KiB) lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:208 errors:0 dropped:0 overruns:0 frame:0
TX packets:208 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:18080 (17.6 KiB) TX bytes:18080 (17.6 KiB) ボンディングステータスをこのコマンドで確認することもできます:
cat /proc/net/bonding/bond0Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009) Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: eth0
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0 Slave Interface: eth0
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 08:00:27:61:e4:88
Slave queue ID: 0 Slave Interface: eth1
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 08:00:27:c8:46:40
Slave queue ID: 0 上記に注意してください。ETH0とETH1のインターフェースをアクティブ-バックアップモードを使用してボンディング構成に成功裏に変換しました。また、サーバーはETH0インターフェースを使用しており、ETH1はバックアップインターフェースとして機能します。
- テストフェーズ
すべてが期待通りに設定されたので、設定が正しいことを確認するために簡単なテストを行いましょう。このテストでは、新しいサーバー(またはLinuxデスクトップ)にログインし、ボンディングサーバーにpingを送信して、テスト中に接続が途切れないか確認します。以下は手順です:
login as: root
[email protected]'s password:
Last login: Wed Sep 14 12:50:15 2016 from 172.20.43.80ping 172.20.43.110PING 172.20.43.110 (172.20.43.110) 56(84) bytes of data.
64 bytes from 172.20.43.110: icmp_seq=1 ttl=64 time=0.408 ms
64 bytes from 172.20.43.110: icmp_seq=2 ttl=64 time=0.424 ms
64 bytes from 172.20.43.110: icmp_seq=3 ttl=64 time=0.415 ms
64 bytes from 172.20.43.110: icmp_seq=4 ttl=64 time=0.427 ms
64 bytes from 172.20.43.110: icmp_seq=5 ttl=64 time=0.554 ms
64 bytes from 172.20.43.110: icmp_seq=6 ttl=64 time=0.443 ms
64 bytes from 172.20.43.110: icmp_seq=7 ttl=64 time=0.663 ms
64 bytes from 172.20.43.110: icmp_seq=8 ttl=64 time=0.961 ms
64 bytes from 172.20.43.110: icmp_seq=9 ttl=64 time=0.461 ms
64 bytes from 172.20.43.110: icmp_seq=10 ttl=64 time=0.544 ms
64 bytes from 172.20.43.110: icmp_seq=11 ttl=64 time=0.412 ms
64 bytes from 172.20.43.110: icmp_seq=12 ttl=64 time=0.464 ms
64 bytes from 172.20.43.110: icmp_seq=13 ttl=64 time=0.432 ms この間に、ボンディングサーバーに戻り、イーサネットインターフェースETH0をオフにします。以下は手順です:
ifconfig eth0eth0 Link encap:Ethernet HWaddr 08:00:27:61:E4:88
UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1
RX packets:1092 errors:0 dropped:0 overruns:0 frame:0
TX packets:1083 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:103486 (201.0 KiB) TX bytes:105439 (122.9 KiB) ifdown eth0 これで、ネットワークインターフェースETH0のサービスをオフにしました。ボンディングステータスを確認しましょう。以下は手順です:
cat /proc/net/bonding/bond0Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009) Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: eth1
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0 Slave Interface: eth1
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 08:00:27:c8:46:40
Slave queue ID: 0 ETH0インターフェースがボンディングステータスにもう存在しないことに気付くでしょう。この間に、前のテストサーバーに戻り、ボンディングサーバーへのpingを継続的に確認します。
64 bytes from 172.20.43.110: icmp_seq=22 ttl=64 time=0.408 ms
64 bytes from 172.20.43.110: icmp_seq=23 ttl=64 time=0.402 ms
64 bytes from 172.20.43.110: icmp_seq=24 ttl=64 time=0.437 ms
64 bytes from 172.20.43.110: icmp_seq=25 ttl=64 time=0.504 ms
64 bytes from 172.20.43.110: icmp_seq=26 ttl=64 time=0.401 ms
64 bytes from 172.20.43.110: icmp_seq=27 ttl=64 time=0.454 ms
64 bytes from 172.20.43.110: icmp_seq=28 ttl=64 time=0.432 ms
64 bytes from 172.20.43.110: icmp_seq=29 ttl=64 time=0.434 ms
64 bytes from 172.20.43.110: icmp_seq=30 ttl=64 time=0.411 ms
64 bytes from 172.20.43.110: icmp_seq=31 ttl=64 time=0.554 ms
64 bytes from 172.20.43.110: icmp_seq=32 ttl=64 time=0.452 ms
64 bytes from 172.20.43.110: icmp_seq=33 ttl=64 time=0.408 ms
64 bytes from 172.20.43.110: icmp_seq=34 ttl=64 time=0.491 ms 素晴らしい、ETH0インターフェースをシャットダウンしても、ボンディングサーバーにpingを送信し、アクセスできることがわかります。もう1つテストを行いましょう。ETH0インターフェースを再度オンにし、ETH1インターフェースをオフにします。
ifup eth0
cat /proc/net/bonding/bond0Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009) Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: eth1
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0 Slave Interface: eth1
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 08:00:27:c8:46:40
Slave queue ID: 0 Slave Interface: eth0
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 08:00:27:61:e4:88
Slave queue ID: 0 ETH0インターフェースがすでに上がっているので、ETH1インターフェースをシャットダウンします。
ifdown eth1cat /proc/net/bonding/bond0Ethernet Channel Bonding Driver: v3.6.0 (September 26, 2009) Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: eth0
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0 Slave Interface: eth0
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 08:00:27:61:e4:88
Slave queue ID: 0 テストサーバーに戻り、ボンディングサーバーへの継続的なpingがどうなるか確認しましょう。
64 bytes from 172.20.43.110: icmp_seq=84 ttl=64 time=0.437 ms
64 bytes from 172.20.43.110: icmp_seq=85 ttl=64 time=0.504 ms
64 bytes from 172.20.43.110: icmp_seq=86 ttl=64 time=0.401 ms
64 bytes from 172.20.43.110: icmp_seq=87 ttl=64 time=0.454 ms
64 bytes from 172.20.43.110: icmp_seq=88 ttl=64 time=0.432 ms
64 bytes from 172.20.43.110: icmp_seq=89 ttl=64 time=0.434 ms
64 bytes from 172.20.43.110: icmp_seq=90 ttl=64 time=0.411 ms
64 bytes from 172.20.43.110: icmp_seq=91 ttl=64 time=0.420 ms
64 bytes from 172.20.43.110: icmp_seq=92 ttl=64 time=0.487 ms
64 bytes from 172.20.43.110: icmp_seq=93 ttl=64 time=0.551 ms
64 bytes from 172.20.43.110: icmp_seq=94 ttl=64 time=0.523 ms
64 bytes from 172.20.43.110: icmp_seq=95 ttl=64 time=0.479 ms 素晴らしい!ボンディングサーバーがネットワークフェイルオーバー条件での災害復旧シナリオを管理できることを成功裏に構成し証明しました。
新しい投稿を受信箱で受け取る
スパムはありません。いつでも購読を解除できます。