こんな感じで
ESXi 上の VM 格納用 DataStore の空き容量が心もとない状況が続いていたので、年も変わったしと SSD を追加。
作業自体は空き Bay に追加の SSD を挿して、今まで通りだと ESXi を落として Intelligent Provisioning 上の SSA で RAID 関連の操作を行うところ、事前作業として行っていた VM の退避処理に時間を要していたため、(過去の経験から) Array の拡張だけならシステム影響がないと ESXi バンドルの SSA でオンライン拡張を実施。
[ Bay7 に SSD を追加した状態での物理ボリューム確認 ]
./ssacli ctrl slot=0 pd all show
Smart Array P440ar in Slot 0 (Embedded)
Array A
physicaldrive 1I:1:1 (port 1I:box 1:bay 1, SATA SSD, 240 GB, OK)
physicaldrive 1I:1:2 (port 1I:box 1:bay 2, SATA SSD, 240 GB, OK)
Array B
physicaldrive 1I:1:3 (port 1I:box 1:bay 3, SATA SSD, 1 TB, OK)
physicaldrive 1I:1:4 (port 1I:box 1:bay 4, SATA SSD, 1 TB, OK)
physicaldrive 2I:1:5 (port 2I:box 1:bay 5, SATA SSD, 1 TB, OK)
physicaldrive 2I:1:6 (port 2I:box 1:bay 6, SATA SSD, 1 TB, OK)
Unassigned
physicaldrive 2I:1:7 (port 2I:box 1:bay 7, SATA SSD, 1 TB, OK)←未アサインで新規認識
[ Array の拡張実施 ]
./ssacli ctrl slot=0 array B add drives=2I:1:7
[ Array B 拡張直後の物理ボリューム確認 ]
./ssacli ctrl slot=0 pd all show
Smart Array P440ar in Slot 0 (Embedded)
Array A
physicaldrive 1I:1:1 (port 1I:box 1:bay 1, SATA SSD, 240 GB, OK)
physicaldrive 1I:1:2 (port 1I:box 1:bay 2, SATA SSD, 240 GB, OK)
Array B
physicaldrive 1I:1:3 (port 1I:box 1:bay 3, SATA SSD, 1 TB, OK)
physicaldrive 1I:1:4 (port 1I:box 1:bay 4, SATA SSD, 1 TB, OK)
physicaldrive 2I:1:5 (port 2I:box 1:bay 5, SATA SSD, 1 TB, OK)
physicaldrive 2I:1:6 (port 2I:box 1:bay 6, SATA SSD, 1 TB, OK)
physicaldrive 2I:1:7 (port 2I:box 1:bay 7, SATA SSD, 1 TB, OK) ← 問題なく認識されている
[ 拡張の進捗状況確認 ]
./ssacli ctrl slot=0 ld all show
Smart Array P440ar in Slot 0 (Embedded)
Array A
logicaldrive 1 (223.54 GB, RAID 1, OK)
Array B
logicaldrive 2 (2.79 TB, RAID 5, Transforming, 1.12% complete)
と処理が開始されて順調に進んでいることを確認したところで放置して少し休憩。
休憩から戻り再度進捗を確認したところ 19% くらいのところで追加したのとは別の 2I:1:6 の SSD が Failed
./ssacli ctrl slot=0 pd all show
Smart Array P440ar in Slot 0 (Embedded)
Array A
physicaldrive 1I:1:1 (port 1I:box 1:bay 1, SATA SSD, 240 GB, OK)
physicaldrive 1I:1:2 (port 1I:box 1:bay 2, SATA SSD, 240 GB, OK)
Array B
physicaldrive 1I:1:3 (port 1I:box 1:bay 3, SATA SSD, 1 TB, OK)
physicaldrive 1I:1:4 (port 1I:box 1:bay 4, SATA SSD, 1 TB, OK)
physicaldrive 2I:1:5 (port 2I:box 1:bay 5, SATA SSD, 1 TB, OK)
physicaldrive 2I:1:6 (port 2I:box 1:bay 6, SATA SSD, 1 TB, Failed) ← 何故か bay6 が死ぬ
physicaldrive 2I:1:7 (port 2I:box 1:bay 7, SATA SSD, 1 TB, OK)
元々半死にだったのが拡張処理の負荷で力尽きたんかなぁと特に何をするでもなく、引き続き拡張処理が終わるのを見届けるべく、再度休憩。
休憩から戻り SSA で進捗を確認しようとするとコマンドが弾かれる。
あれ？っと思いラックを見たところ Bay6 だけではなく Bya5 の SSD でも障害 LED が点灯している。。
どうやら拡張処理中に 2 台の SSD で故障が続けて起こり、Array B の論理ボリュームが死んだらしい。
ESXi 自体は Array A 側に入っているので影響を受けない筈なんだけど、ssacli コマンドが使用できない。
HDD と違って SSD がこんなにポンポン壊れることがあるか？そもそも結構な数の SSD を買ってきたけど、用途は別とはいえ故障したことがなかったのでバックプレーンか接触の問題かなーと思い ESXi を落として物理的な確認を行うこととする。
正常にシャットダウンされたことを確認した上で、Bay 1 ～ 7 全ての SSD を一度抜き挿し及び挿し具合の確認を行ったうえで Intelligent Provisioning 上の SSA を起動。
コントローラステータスは正常だが何故か論理ボリュームの認識数 0、物理ボリュームの認識数 3 となっている。
7 枚の SSD 中 3 だと故障疑惑の数(2) より多いので何か動きがおかしい。
続いて論理ボリュームを確認しようとクリックしたところ SSA がハングアップ。
完全に操作を受け付けなくなったので、渋々電源 off/on を行い、再度 Intelligent Provisioning 上の SSA を起動。
先ほどと同じく論理ボリュームの認識数 0、物理ボリュームの認識数 3 となっているが、そちらの詳細確認の前にコントローラログを参照。
様々なログの中に、
“コントローラ FW が認識できないソフトウェアバージョンで操作された Array のため、管理できません(意訳)”的なメッセージが出力されていることを発見。
読んだままの意味だと ESXi 8 上の SSA は SmartArray P440ar のファームウェア 7.00 とコンパチが合っていないらしい。
じゃあ SmartArray P440ar のファームウェアを 7.00 からアップデートできれば解決するのか？と HPE サポートサイトから FW を探すと 7.20 を発見。
Linux/Windows 上で実行する形式だったけど、両方をダウンロード。
FW のアップロードは iLO から出来たよなぁと iLO に FW を食わせたところ、対応していないと怒られる。
iLO4 のユーザマニュアルを改めて読んだところ、iLO 上からアップデート出来る FW は iLO 自体と System BIOS だけらしい。。(この世代の iLO は DELL の iDRAC よりしょぼい)
ESXi 環境だと正攻法の SPP オフラインアップデートしか方法がないが、手持ちの SPP が Gen9 世代の最終版。。
HPE のサイト上でカスタム SPP を作るには有効なオンラインパスポートが必要だがこちらは残念ながら失効中。
という訳で使用不可となった Array B 内のデータ復旧はほぼ不可能なことが確定。
復旧はきっぱり諦めて ESXi が入っている Bay1、2 だけの状態で起動してみると問題なく ESXi が起動する。
Bay3 ～ 7 のどれかでも搭載した状態で電源を入れると問題ない Array A を読めなくなる。
この切り分けから Bay3 ～ 7 の SSD 内の Array 構成情報をなんとかしないと SSD を再利用できないと判断。
別筐体を用意し、搭載している SmartArray P440ar を HBA モードに切り替えた上で問題の SSD を挿したら問題なく認識したので 1 枚ずつゼロクリアを行った上で元の筐体に戻したところ Intelligent Provisioning 上の SSA が問題なく動作。
Array B を作り直した上で ESXi を起動し VM 全損状態での動作確認を行い問題なかったため、事前の退避処理が出来ていた VM の再格納と消失した VM を過去の退避データからサルベージ。
一部古すぎてサルベージした VM では不具合が出たものと、ここ最近作成した VM(この Web サーバとか)は構築時の資料を元に再構築。
ここまでの復旧作業に要した時間は都合 2.5 日と過去最大の人災トラブルとなった。。
尚、復旧のため、旧データからサルベージした PDC と健常な BDC 間で AD 認証の不具合が出たり、VM の転送が遅いなぁとスイッチの状態を見たところ、
2025/01/05-19:54:46, [FW-1038], 88318227, SW/0 | Active, WARNING, tzk-core-sw0, Sfp RX power for port 1/0/2, is below low boundary(High=1000, Low=32). Current value is 28 uW.
と、ESXi とスイッチ間の 10G ポートで光量不足のエラーが RX 側のみ出ていることを発見。
FC ケーブルを目視したら、ポート入線する際の曲げで想定外のテンションが掛かって片方のケーブル(多分 RX)の被膜が白くなっていたため、交換したところ、警告メッセージおよび出続けていた Error カウントが止まった。
ただ、エラー原因は取り除かれたけど、VM の転送が変わらず遅い。
綺麗に 40MB/s 程度でキャップが掛かっているのでソフトウェア的な帯域制御でも行われているんかな？
なんにせよ新年早々過去一レベルのトラブルを引いたけど、原因は置いておいて VM の退避を確実に行っていれば事後処理がもっと楽だったと反省。
SSA ユーティリティも FW とバージョンが合っていないんだったら、警告メッセージくらいコマンド実行時に出してほしいと思った。(他力本願)