はじめに
巷で話題のProxmox-VEと呼ばれる仮想化プラットフォームを用意する際に、手元で用意してすぐに壊すのであれば、ネットワーク冗長化は不要ですが、直近で壊す予定がない場合は、ネットワーク冗長化はしておいて損はないと考えています。今回は、LACP (IEEE 802.3ad) を用いたbondingによる冗長化について記載していきます。
検証環境
Proxmox-VE 8.3(以降、Proxmox と記載) と Cisco Catalyst Switch(以降、Switch と記載) を使用しており、相互を２本のLANケーブルで接続しています。
注意点として、今回記載した内容はリモートでの作業を想定していないので、実施の際は作業順序やコンソール接続可能な状態にしておくことを忘れないように。手順や順序を誤るとどこからも接続できなくなります。
冗長設定
それぞれ、ProxmoxとSwitchでの設定について記載します。
Proxmox
package
事前準備として、"ifupdown2"がインストールされていることを確認します。7.0以降ではデフォルトでインストールされているそうです。
"ifupdown2"をインストールすることで、GUIからネットワークの設定を反映する際に、再起動が不要になります。
With the recommended ifupdown2 package (default for new installations since Proxmox VE 7.0), it is possible to apply network configuration changes without a reboot.
If you change the network configuration via the GUI, you can click the Apply Configuration button. This will move changes from the staging interfaces.new file to /etc/network/interfaces and apply them live.
引用元：Live-Reload Network with ifupdown21
> apt list --installed | grep ifupdown2 ifupdown2/now 3.2.0-1+pmx11 all [installed,local]
configure
以下のようにProxmoxでbondingを利用する際、SwitchでLACP (IEEE 802.3ad) をサポートしている場合はこれを使用することを推奨しているため、LACP (IEEE 802.3ad) を使用します。またサポートしていない場合には、active-backupを使用しましょう。
If your switch supports the LACP (IEEE 802.3ad) protocol, then we recommend using the corresponding bonding mode (802.3ad). Otherwise you should generally use the active-backup mode.
引用元：Linux Bond2
/etc/network/interfaces を以下の通りに編集していきます。以下は例ですので、環境に合わせて書き換えてください。
auto lo
iface lo inet loopback
# physical on-bording device
iface eno1 inet manual
iface eno2 inet manual
# virtual bonding device
auto bond0
iface bond0 inet manual
bond-slaves eno1 eno2 # bondingとして扱う物理NIC
bond-miimon 100 # bondingのリンク状態を監視する間隔(ms)
bond-mode 802.3ad # LACPとして動作
bond-xmit-hash-policy layer2+3
# virtual bridge device
auto vmbr0
iface vmbr0 inet static
address 192.168.1.30/24 # bridgeに割り当てるIPアドレス(ホストにアクセスするIPアドレス)
gateway 192.168.1.254
bridge-ports bond0 # bridgeと紐づけるインターフェース
bridge-stp off
bridge-fd 0
"ifupdown2"をインストールすることで、GUIからネットワークの設定を反映する際に、再起動が不要になりますが、今回は、CUIでネットワーク設定を変更したので、以下のコマンドで設定を反映します。
If you made manual changes directly to the /etc/network/interfaces file, you can apply them by running ifreload -a
引用元：Live-Reload Network with ifupdown23
# ifreload -a
状態確認（正常時）
正常な状態の例を記載します。
### 物理NICの状態
# ip link show eno1
4: eno1: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP mode DEFAULT group default qlen 1000
link/ether aa:aa:aa:aa:aa:4c brd ff:ff:ff:ff:ff:ff
# ip link show eno2
5: eno2 <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP mode DEFAULT group default qlen 1000
link/ether aa:aa:aa:aa:aa:4c brd ff:ff:ff:ff:ff:ff permaddr aa:aa:aa:aa:aa:4d
### bondの状態
# ip link show bond0
11: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP mode DEFAULT group default qlen 1000
link/ether aa:aa:aa:aa:aa:4c brd ff:ff:ff:ff:ff:ff
### ブリッジの状態
# ip link show vmbr0
14: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether aa:aa:aa:aa:aa:4c brd ff:ff:ff:ff:ff:ff
### bondの状態
# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v6.8.12-4-pve
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 active: on
LACP rate: slow
Min links: 0
Aggregator selection policy (ad_select): stable
System priority: 65535
System MAC address: aa:aa:aa:aa:aa:4c
Active Aggregator Info:
Aggregator ID: 1
Number of ports: 2
Actor Key: 9
Partner Key: 67
Partner Mac Address: bb:bb:bb:bb:bb:46
Slave Interface: eno1
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: aa:aa:aa:aa:aa:4c
Slave queue ID: 0
Aggregator ID: 1
Actor Churn State: none
Partner Churn State: none
Actor Churned Count: 0
Partner Churned Count: 0
details actor lacp pdu:
system priority: 65535
system mac address: aa:aa:aa:aa:aa:4c
port key: 9
port priority: 255
port number: 1
port state: 61
details partner lacp pdu:
system priority: 32768
system mac address: bb:bb:bb:bb:bb:46
oper key: 67
port priority: 128
port number: 3
port state: 61
Slave Interface: eno2
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: aa:aa:aa:aa:aa:4d
Slave queue ID: 0
Aggregator ID: 1
Actor Churn State: none
Partner Churn State: none
Actor Churned Count: 0
Partner Churned Count: 0
details actor lacp pdu:
system priority: 65535
system mac address: aa:aa:aa:aa:aa:4c
port key: 9
port priority: 255
port number: 2
port state: 61
details partner lacp pdu:
system priority: 32768
system mac address: bb:bb:bb:bb:bb:46
oper key: 67
port priority: 128
port number: 4
port state: 61
状態確認（異常時）
ここでは２本のLANケーブルのうち(eno1側)を抜線後の状態を記載していまので、参考にしてください。
抜線した物理NICは、DOWNしていますが、仮想インターフェースはUPのままになっています。bond状態確認では、スレーブインターフェースとしての抜線したポートがdownしています。
### 物理NICの状態
# ip link show eno1
4: eno1: <NO-CARRIER,BROADCAST,MULTICAST,SLAVE,UP> mtu 1500 qdisc mq master bond0 state DOWN mode DEFAULT group default qlen 1000
link/ether aa:aa:aa:aa:aa:4c brd ff:ff:ff:ff:ff:ff
# ip link show eno2
5: eno2: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc mq master bond0 state UP mode DEFAULT group default qlen 1000
link/ether aa:aa:aa:aa:aa:4c brd ff:ff:ff:ff:ff:ff permaddr aa:aa:aa:aa:aa:4d
### bondの状態
# ip link show bond0
11: bond1: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP mode DEFAULT group default qlen 1000
link/ether aa:aa:aa:aa:aa:4c brd ff:ff:ff:ff:ff:ff
### ブリッジの状態
# ip link show vmbr0
14: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
link/ether aa:aa:aa:aa:aa:4c brd ff:ff:ff:ff:ff:ff
### bondの状態
# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v6.8.12-4-pve
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 active: on
LACP rate: slow
Min links: 0
Aggregator selection policy (ad_select): stable
System priority: 65535
System MAC address: aa:aa:aa:aa:aa:4c
Active Aggregator Info:
Aggregator ID: 1
Number of ports: 1
Actor Key: 9
Partner Key: 67
Partner Mac Address: bb:bb:bb:bb:bb:46
Slave Interface: eno1
MII Status: down <--リンクダウン検知で"down"に変化
Speed: Unknown <--リンクダウン検知で"Unknown"に変化
Duplex: Unknown <--リンクダウン検知で"Unknown"に変化
Link Failure Count: 1 <--リンクダウン検知でカウンタが増加
Permanent HW addr: aa:aa:aa:aa:aa:4c
Slave queue ID: 0
Aggregator ID: 1
Actor Churn State: none
Partner Churn State: none
Actor Churned Count: 0
Partner Churned Count: 0
details actor lacp pdu:
system priority: 65535
system mac address: aa:aa:aa:aa:aa:4c
port key: 0
port priority: 255
port number: 1
port state: 61
details partner lacp pdu:
system priority: 32768
system mac address: bb:bb:bb:bb:bb:46
oper key: 67
port priority: 128
port number: 3
port state: 61
Slave Interface: eno2
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: aa:aa:aa:aa:aa:4d
Slave queue ID: 0
Aggregator ID: 1
Actor Churn State: none
Partner Churn State: none
Actor Churned Count: 0
Partner Churned Count: 0
details actor lacp pdu:
system priority: 65535
system mac address: aa:aa:aa:aa:aa:4c
port key: 9
port priority: 255
port number: 2
port state: 61
details partner lacp pdu:
system priority: 32768
system mac address: bb:bb:bb:bb:bb:46
oper key: 67
port priority: 128
port number: 4
port state: 61
Switch
コンフィグを以下の通りに記載します。こちらも例ですので、環境に合わせて書き換えてください。
! interface Port-channel2 switchport access vlan 10 switchport mode access ! ! interface GigabitEthernet1/0/3 switchport access vlan 10 switchport mode access channel-protocol lacp channel-group 2 mode active ! interface GigabitEthernet1/0/4 switchport access vlan 10 switchport mode access channel-protocol lacp channel-group 2 mode active !
動作確認
冗長化したそれぞれのProxmoxノード間でpingを打ち続けた状態でLANケーブルを抜線した際の影響を確認してみました。結果を見ると、当然のことながら間隔が短い方はパケットロス率が高いことが分かります。検証で利用する分には問題なく、あくまで疎通がこれくらいの影響というだけで、実際にVMやLinuxコンテナ上でアプリケーションを動作させた場合の影響は環境によると思われます。また、外部ストレージを利用する場合はどのような影響があるのか検証してみる必要がありそうです。
・0.1秒間隔でpingを打ち続けた場合の影響
--- 192.168.1.30 ping statistics --- 500 packets transmitted, 496 received, 0.8% packet loss, time 51919ms rtt min/avg/max/mdev = 0.166/0.448/0.696/0.059 ms
・0.01秒間隔でpingを打ち続けた場合の影響
--- 192.168.1.30 ping statistics --- 500 packets transmitted, 444 received, 11.2% packet loss, time 8005ms rtt min/avg/max/mdev = 0.166/0.439/0.491/0.063 ms
おまけ
bond-miimon の監視間隔を短くした場合の断時間
以下の結果より、bond-miimon のパラメータを"10"に変更し、0.01秒間隔でpingを打った場合に多少変化はありましたが、それ以外は大きな変化はありませんでした。いずれの場合においても、疎通断から1秒以内に復活しているため、このパラメータが運用において大きな役割を果たしているとは言えないと感じました。bond-miimon のパラメータを小さくすることで多少リソースが消費されてしまうこと考えると、無理に小さくせずに公式の例にあるように、"100"で問題ないと思いました。
bond-miimon のパラメータを"100"から"10"に変更
・0.1秒間隔でpingを打ち続けた場合の影響
--- 192.168.1.30 ping statistics --- 500 packets transmitted, 496 received, 0.8% packet loss, time 51901ms rtt min/avg/max/mdev = 0.169/0.426/0.512/0.076 ms
・0.01秒間隔でpingを打ち続けた場合の影響
--- 192.168.1.30 ping statistics --- 500 packets transmitted, 475 received, 5% packet loss, time 8011ms rtt min/avg/max/mdev = 0.184/0.429/0.495/0.054 ms
bond-miimon のパラメータを"100"から"50"に変更
・0.1秒間隔でpingを打ち続けた場合の影響
--- 192.168.1.30 ping statistics --- 500 packets transmitted, 491 received, 1.8% packet loss, time 51907ms rtt min/avg/max/mdev = 0.172/0.460/0.534/0.051 ms
・0.01秒間隔でpingを打ち続けた場合の影響
--- 192.168.1.30 ping statistics --- 500 packets transmitted, 443 received, 11.4% packet loss, time 7990ms rtt min/avg/max/mdev = 0.176/0.447/0.518/0.052 ms
