PVE のクラスターネットワークを分離してみる
今に始まったことじゃないけど、バックアップを実行するタイミングでノードのシステムログに次のメッセージが残る。
Dec 28 07:38:29 x300 corosync[1085]: [KNET ] link: host: 3 link: 0 is down
Dec 28 07:38:29 x300 corosync[1085]: [KNET ] host: host: 3 (passive) best link: 0 (pri: 1)
Dec 28 07:38:29 x300 corosync[1085]: [KNET ] host: host: 3 has no active links
Dec 28 07:38:29 x300 corosync[1085]: [KNET ] link: Resetting MTU for link 0 because host 3 joined
Dec 28 07:38:29 x300 corosync[1085]: [KNET ] host: host: 3 (passive) best link: 0 (pri: 1)
Dec 28 07:38:29 x300 corosync[1085]: [KNET ] pmtud: Global data MTU changed to: 1397短い時間だけどクラスター間の通信が途絶えて復帰したときに発生するメッセージ。大規模なクラスターなら目的に応じてネットワークを分離するところ、DeskMini X300 の LAN インターフェースは１つしかないから、当たり前だけどクラスターネットワークも VM も ceph も同じインターフェースを使用しているので仕方ない。
これを、改めて次の PVE 管理ガイドに基づいて、USB LAN アダプターを追加してクラスターネットワークを分離してみる。
パラメータなしでクラスターを作成すると、通常、corosync クラスター ネットワークは Web インターフェースおよび VM のネットワークと共有されます。設定によっては、ストレージ トラフィックも同じネットワーク経由で送信されることがあります。corosync は時間重視のリアルタイム アプリケーションであるため、これを変更することをお勧めします。
バックアップ時に切れるなら、バックアップ用ネットワークとして PBS との通信だけを分離すればいいのでは？というのも御尤もです。が、まずはクラスターが正常であってほしいから、次の手順に従ってクラスターネットワークを分離する。
- 既にクラスターを作成済みなので、PVE 管理ガイドの「クラスター作成後に分離」のとおり実行する。
- 新規にクラスターを構成するときに分離する場合は「クラスター作成時に分離」のとおり。
具体的な作業は次のとおり。
◇USB LAN アダプター
各ノードで設定する。
本来なら Ethernet 拡張ボードを使用したいところだけど、DeskMini にはその余地はない。特に GbE 対応の USB LAN アダプターは熱くなる傾向がありそうなので、Linux で動作する、比較的新しく、かつ、発熱量の少なそうな RTL8156BG チップを使用している Planex の USB-LAN2500R2 にしてみた。2.5 Gbps の実力は HUB や L2SW を所有していないから今のところ宝の持ち腐れ。
DeskMini X300 の背面には使っていない USB 3.2 Gen1 Type-A があるから、今更だけど LAN アダプターも Type-A を選択。
USB LAN アダプターを接続すると、PVE 管理画面のノード＞システム＞ネットワークに enx1cc0350749c9 のようなネットデバイスとして認識される。念の為、コマンド ethtools で確認すると次のように正しく認識されている。まだ LAN ケーブルは接続していない。
root@x300:~# ethtool enx1cc0350749c9
Settings for enx1cc0350749c9:
Supported ports: [ TP MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
2500baseT/Full
Supported pause frame use: No
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Full
2500baseT/Full
Advertised pause frame use: No
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Speed: 10Mb/s
Duplex: Half
Auto-negotiation: on
Port: MII
PHYAD: 32
Transceiver: internal
Supports Wake-on: pumbg
Wake-on: g
Current message level: 0x00007fff (32767)
drv probe link timer ifdown ifup rx_err tx_err tx_queued intr tx_done rx_status pktdata hw wol
Link detected: no
続いて、このネットデバイスに IP アドレスを設定する。あくまでもクラスター専用のネットワークだから、VM 等を接続することはない。なので、下画像のとおり、シンプルにデバイスに直接 IP アドレスを設定することにした。ゲートウェイも不要。
間違っても IP アドレスに重複の無いことに注意しつつ、設定に間違いがなければ「設定を適用」ボタンをクリックする。
最後に LAN ケーブルを接続するのだが、できれば専用の HUB を使用することで他のネットワークと完全に分離することが望ましいけど、自鯖だしということで L2SW の空きポートに接続することにした。タグ VLAN をポートに設定してアクセスポートにすることで、接続されるタグなし端末にタグを付けてくれる。今回は空きポート３つに 192.168.2.0/24 を対象とする vlan を設定した。
で、ping で各ノード間の通信に問題のないことを確認する。
◇/etc/pve/corosync.conf
クラスター内の１つのノードで corosync.conf を編集する。/etc/corosync/corosync.conf は PVE が書き換えてくれるから何もしない。
具体的な手順は PVE 管理ガイドの 5.11. Corosync Configuration のとおり。
まずは次のコマンド
cp /etc/pve/corosync.conf /etc/pve/corosync.conf.newで更新用のファイルを作成して作業する。corosync.conf はファイルの更新と同時に設定が反映されるから、誤って中途半端な設定で保存・更新してしまわないための手順。
併せて、
cp /etc/pve/corosync.conf /etc/pve/corosync.conf.bakを実行して、問題があれば元に戻せるように準備しておく。
自分の環境だと corosync.conf は次のとおり。各ノードの ring0_addr の変更と併せて、忘れずに config_version を増やしておくこと。
logging {
debug: off
to_syslog: yes
}
nodelist {
node {
name: x300
nodeid: 1
quorum_votes: 1
ring0_addr: 192.168.2.3
}
node {
name: x301
nodeid: 2
quorum_votes: 1
ring0_addr: 192.168.2.4
}
node {
name: x302
nodeid: 3
quorum_votes: 1
ring0_addr: 192.168.2.5
}
}
quorum {
provider: corosync_votequorum
}
totem {
cluster_name: Cluster
config_version: 4
interface {
linknumber: 0
}
ip_version: ipv4-6
link_mode: passive
secauth: on
version: 2
}
正しく設定されていることを確認したら、
mv /etc/pve/corosync.conf.new /etc/pve/corosync.confとして新しい設定ファイルを有効化して、問題が無いことを次のコマンドで確認する。
systemctl status corosync
journalctl -b -u corosync
systemctl status corosync は次のとおり、IP アドレスが変更されたメッセージが表示されている。
● corosync.service - Corosync Cluster Engine
Loaded: loaded (/lib/systemd/system/corosync.service; enabled; preset: enabled)
Active: active (running) since Sat 2024-12-28 12:52:31 JST; 7h ago
Docs: man:corosync
man:corosync.conf
man:corosync_overview
Main PID: 1126 (corosync)
Tasks: 9 (limit: 76840)
Memory: 136.8M
CPU: 6min 24.467s
CGroup: /system.slice/corosync.service
└─1126 /usr/sbin/corosync -f
12月 28 12:56:24 x300 corosync[1126]: [TOTEM ] A new membership (1.15f) was formed. Members joined: 3
12月 28 12:56:24 x300 corosync[1126]: [QUORUM] Members[3]: 1 2 3
12月 28 12:56:24 x300 corosync[1126]: [MAIN ] Completed service synchronization, ready to provide service.
12月 28 12:56:24 x300 corosync[1126]: [KNET ] pmtud: Global data MTU changed to: 1397
12月 28 20:16:57 x300 corosync[1126]: [CFG ] Config reload requested by node 1
12月 28 20:16:57 x300 corosync[1126]: [TOTEM ] new config has different address for link 0 (addr changed from 192.168.1.3 to 192.168.2.3). Internal value was NOT changed.
12月 28 20:16:57 x300 corosync[1126]: [TOTEM ] new config has different address for link 0 (addr changed from 192.168.1.4 to 192.168.2.4). Internal value was NOT changed.
12月 28 20:16:57 x300 corosync[1126]: [TOTEM ] new config has different address for link 0 (addr changed from 192.168.1.5 to 192.168.2.5). Internal value was NOT changed.
12月 28 20:16:57 x300 corosync[1126]: [CFG ] Cannot configure new interface definitions: To reconfigure an interface it must be deleted and recreated. A working interface needs to be available to corosync at all times
12月 28 20:16:57 x300 corosync[1126]: [KNET ] pmtud: MTU manually set to: 0
クラスターが正しく動作していれば、corosync.conf.bak は削除しても良い。
もし何かしらのエラーが生じていたら、各ノードで corosync をリスタートしてみる。
systemctl restart corosyncリスタート直後は管理画面のノードに x 印が付くかもしれないが、しばらく経つと正常になるハズ。
最後に
USB LAN アダプターの信頼性には疑問の残るところではあるが、しばらくこれで様子をみてみよう。