夜中の0時49分、Uptime KumaからDiscordに通知が来た。
❌ Your service pbs01 went down. — connect EHOSTUNREACH
バックアップサーバー（pbs01）に届かない。Proxmoxを見ると、pbs01は停止していた。
まずノードごと再起動していた
ノード③で journalctl -b（今回の起動からのログ）を見ると、記録が 0:47から始まっている。つまりpbs01だけでなく、③そのものが0:47ごろに再起動していた。
pbs01が戻ってこなかったのは、自動起動（onboot）を付け忘れていたから。HAの対象にしていたVPN・監視・パスワード管理のコンテナは、HAが起動し直してくれていた。
qm start 2020
qm set 2020 --onboot 1
再起動の前に何があったか
1つ前の起動の最後（journalctl -b -1）を見たら、原因がそのまま書いてあった。
0:45:35 corosync: link: host: 1 link: 0 is down
0:45:36 kernel: e1000e 0000:00:1f.6 nic0: Detected Hardware Unit Hang
0:45:41 pmxcfs: node lost quorum
0:46:31 watchdog-mux: watchdog expired
- LANポート（Intel I219-V、ドライバはe1000e）が固まった。送信が止まって、ほかのノードと通信できなくなった。
- クラスタの過半数（クォーラム）から外れた。
- HAの対象を載せているノードは、クォーラムを失ったまま約1分たつと、自分で強制再起動する（フェンシング）。同じVMが2台で同時に動いて壊れるのを防ぐための仕組み。
HAとしては設計どおりに動いていた。悪いのはNICのほう。
対策：オフロードを切る
e1000e（I219系）の「Hardware Unit Hang」はよく知られた症状で、NICにやらせているTSO/GSO/GRO（パケットの分割・結合）を切ると直ることが多い。
ethtool -K nic0 tso off gso off gro off
再起動しても残るように、/etc/network/interfaces の iface nic0 inet manual の下に1行足した。
iface nic0 inet manual
post-up /usr/sbin/ethtool -K nic0 tso off gso off gro off
ノード②も同じI219-Vだったので、まだ固まったことはないけど同じ設定を入れた。①はRealtekなので関係なし。
わかったこと
- HAを入れていると、NICが1回固まっただけでノードが再起動する。NIC 1本の構成だと、ネットワークの不調＝再起動になる。
- 止まったときに「何が止まったか」より「いつ起動したか」を見ると早い。
journalctl -bの最初の時刻とlast -xで一発でわかる。 - HA対象外のVMには onboot を付けておく。
またNICが固まるようなら、USBのLANアダプタを足して、クラスタ通信（corosync）の経路を2本にする予定。