OSD が落ちる原因を調べてみた

◇結論

随分遠回りしてしまったけど、2.5inch SSD では限界らしく、各ノードの OSD を NVMe な M.2 SSD に変更したら安定運用できている。

◇エラーログ

dmesg | grep ata で検索すると、ノードの起動直後は問題なく 6 Gbps で接続できていても、何かしら負荷がかかると link down と up を繰り返して 1.5 Gbps になってしまい、最終的に OSD が落ちていた。

[134587.161994] ata1.00: exception Emask 0x10 SAct 0x4000000 SErr 0x40d0000 action 0xe frozen
[134587.162002] ata1.00: irq_stat 0x00000040, connection status changed
[134587.162005] ata1: SError: { PHYRdyChg CommWake 10B8B DevExch }
[134587.162009] ata1.00: failed command: READ FPDMA QUEUED
[134587.162011] ata1.00: cmd 60/08:d0:80:67:70/00:00:74:00:00/40 tag 26 ncq dma 4096 in
[134587.162020] ata1.00: status: { DRDY }
[134587.162024] ata1: hard resetting link
[134588.042153] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
[134588.099886] ata1.00: configured for UDMA/33
[134588.111911] ata1: EH complete

◇確認したこと

DeskMini X300 が 2 台（node A、node B）と H470（node C） の 3 ノードで運用している。

SSD の交換（効果なし）

いつも node A の OSD が落ちていたからログを確認したところ、どうやら物理的な問題とのことだった。SATA のケーブルを差し替えても改善しなかったので 2.5 inch SSD の不具合を疑い、新品の SSD（WD Blue SA510）を購入して取り替えてみた。でも相変わらず OSD は落ちた。

PVE 再インストール（効果なし）

物理的な要因だけでなく、例えば ATA 関係のドライバーに問題がある可能性も無くはないから PVE を再インストールしてみたけどダメだった。

M/B 交換（効果なし）

今更ではあるけど DeskMini X300 を購入して、node A の起動用 M.2 SSD と OSD 用の 2.5 inch SSD、メモリ、CPU、SATA ケーブルを全て新しい DeskMini X300 に載せ替えて確認したところ、相変わらず node A'  の OSD が落ちた。

メモリ交換（効果なし）

SSD 以外のパーツに問題があるかもしれないと思って、正常だった node B のメモリと交換してみたが、結果は同じく node A の OSD が落ちた。もちろん node B は通常運用。

M.2 SSD 交換（効果なし）

node B と交換可能な残るパーツとしては M.2 SSD と CPU。取り敢えず容易に交換できる M.2 SSD を入れ替えてみたところ、node A ではなく、node B の OSD が落ちた。
この時点では、node A の CPU は問題なく、M.2 SSD に何かしらの問題があると思って手持ちの別 M.2 SSD に入れ替えて PVE をインストールしたところ、今度は node A が落ちた。

2.5inch SSD を諦めた（解消！）

こうなると何が何だか解らないが、Proxmox の Wiki によると、PVE でクラスタを構成して Ceph を運用する場合に注意する点として、推奨されるネットワークやディスクの性能が高いことがある。

The volume of traffic, especially during recovery, will interfere with other services on the same network, especially the latency sensitive Proxmox VE corosync cluster stack can be affected, resulting in possible loss of cluster quorum. Moving the Ceph traffic to dedicated and physical separated networks will avoid such interference, not only for corosync, but also for the networking services provided by any virtual guests.

※Google 翻訳
特にリカバリ中のトラフィック量は、同じネットワーク上の他のサービスに干渉し、特に遅延の影響を受けやすい Proxmox VE corosync クラスター スタックが影響を受け、クラスター クォーラムが失われる可能性があります。Ceph トラフィックを専用の物理的に分離されたネットワークに移動すると、corosync だけでなく、仮想ゲストによって提供されるネットワーク サービスに対しても、このような干渉を回避できます。

推奨事項を満たしていないのは承知のうえの DeskMini クラスタ。OSD が落ちる直接の原因では無さそうだけど、できることはやってみようということで 3 ノードとも OSD を M.2 SSD にしたところ、OSD が落ちることは無くなった。
node C は H470 ではなく、購入した DeskMini X300 に CPU Ryzen 5300G を新規購入したもの。その他のパーツは H470 で使っていたものを流用した。

3 ノードとも OSD として使用する M.2 SSD は、それまで PVE 用だった 1TB の M.2 SSD を使用。
代わりの PVE 用 M.2 SSD は取り敢えず手持ちの 500 GB を使用した。
2.5 inch SSD はお蔵入り。

◇終わりに

余った H470 にはメモリと起動用 M.2 SSD を調達して、2.5 inch SSD を倉庫に PBS をインストールした。今のところ ATA に関するエラーログは出ていない。ただし、データストアを ZFS にすると正常にバックアップできなかったから directory としている。

これまでは VM に PBS をインストールしてノードの物理ディスクをアタッチしていた。それを、物理 PC に変更してクラスタの外に出したことで、少しはノードにかかる負担は減少するかな。