コミュニティソリューション

ZimaOS RAID 5の拡張が停止:アレイとファイルシステムを確認

A four-disk RAID5 expansion on ZimaOS 1.4.1 reached 100%, then appeared stuck while Storage and Files reported different capacities.

結論:RAID 5を再構築する前に、アレイサイズとファイルシステムサイズを個別に確認する

旧1.4.1 UIでは、紛らわしい状態が表示されていました。拡張は100%に達し、Storageには大きくなった36 TBの合計容量が表示される一方、Filesには以前とほぼ同じ使用可能容量が表示され、拡張操作も停止したままでした。これは、mdアレイは拡張されたものの、ファイルシステムまたはUI側のリサイズ・更新が完了していない可能性を示します。1つの容量カードだけを見て成功と判断したり、別の表示だけを見て失敗と判断したりしないでください。

ZimaOSのRAID5設定で、12 TBディスク4台が表示され、以前100%に達した後、拡張が0%で停止している状態
拡張が100%に達した後、Storageには大きな未フォーマット容量が表示されているにもかかわらず、UIは0%の「RAIDを拡張中」状態に戻りました。
ZimaOSのFilesで、拡張後もRAID5のメインストレージが以前の使用可能容量を表示している状態
Filesビューには拡張前の使用可能容量が表示されたままで、アレイだけが拡張されたのか、ファイルシステムも拡張されたのか分からない状態になっていました。
ZimaOSのStorage概要で、RAID5の拡張状態と大きくなった36 TBの合計容量が表示されている状態
Storageには36 TBの大きな合計容量が表示されながら、拡張中の状態も表示されていました。このため、UIの容量表示だけでは処理の完了を確認できませんでした。
RAID5拡張後、36 TBの合計容量が表示されたZimaOSストレージ容量の拡大画像
12 TBディスクを4台目として追加した後、Storageインターフェースに表示された新しい合計容量を拡大して示しています。

ステップ1:RAIDメンバー数とアレイの状態を確認する

cat /proc/mdstat
sudo mdadm --detail /dev/mdX

新しいディスクがアクティブなメンバーになっていること、アレイの状態が正常であること、reshapeやrecoveryがまだ実行中でないことを確認してください。mdadmアレイの状態は、基盤となるLinux RAIDのリファレンスです。

ステップ2:ブロックデバイスとファイルシステムのサイズを確認する

lsblk -f
df -h

mdデバイスのサイズは大きくなっているのに、マウントされたファイルシステムが以前のサイズを報告している場合、RAIDレイヤーは拡張されていますが、ファイルシステムは拡張されていません。これは、ディスクのreshapeに失敗した場合とは別の問題です。

ファイルシステムの拡張コマンドを無闇に実行しない

EXT4、BTRFSなどのファイルシステムでは、使用する拡張ツールが異なります。まずFSTYPEを確認してください。EXT4ではresize2fsが該当するツールですが、BTRFSではファイルシステムのリサイズ方法が異なります。EXT4ファイルシステムのリサイズで、EXTの拡張方法を確認できます。

現在のZimaOSドキュメントでは、RAID 5は拡張可能とされている

現在のRAID関連資料には、RAID 5は時間をかけてドライブを追加することで拡張できると明記されています。したがって、旧1.4.1での挙動は、RAID 5の拡張がサポートされていない証拠ではなく、過去の拡張またはUIの問題と考えられます。ZimaOSのRAID5拡張が、現在の基準となります。

数日かかるreshapeの前に負荷の高いアプリを停止する

元のユーザーは後に、コンテナを停止し、処理中にFilesやStorageを操作しないことで、2回とも再構築と拡張に成功しました。これは運用上の注意点として有用ですが、Filesを開いたままにしていたことが元の失敗の原因だと証明するものではありません。安全策としては、長時間のreshape中の書き込みとUI操作を減らすことであり、特定のブラウザタブを根本原因と断定することではありません。

reshapeの途中で、復旧に必要な場合を除いて再起動しない

RAIDのreshapeはストレージに対する大がかりな処理です。/proc/mdstatに進行中の処理が表示されている場合は、システムに本当の障害が発生していない限り、完了するまで待ってください。突然の電源断はリスクを高めます。可能であれば、長時間の拡張にはUPSを使用してください。

別のドライブを追加する前にバックアップする

RAID 5はメンバー1台の故障に耐えられますが、reshapeではすべてのディスクへのアクセスが増加するため、バックアップの代わりにはなりません。数日かかる処理を始める前に、ZimaOSのバックアップを完了してください。

UIが0%のまま「拡張中」と表示される場合

アレイとファイルシステムが正常で、ファイルシステムが新しいサイズを認識していることを確認できたなら、UIまたはサービス側の古い状態が原因である可能性が高くなります。ストレージ処理が終了してから再起動し、その後もう一度確認してください。進捗表示を消すためだけに、アレイを解除して再作成しないでください。

再構築は最後の復旧手段にする

元のユーザーは最終的にバックアップを取り、RAIDを解除して再構築しました。これは成功しましたが、破壊的な手順です。現在は、再構築を選ぶ前に、CLIの状態、最新のドキュメント、バックアップを使って、問題が実際にアレイ、ファイルシステム、UIのどこにあるのかを特定してください。RAIDの復旧では、復旧の境界について説明しています。

よくある質問

なぜStorageにはFilesより大きな容量が表示されるのですか?

RAIDのブロックデバイスは拡張されている一方で、ファイルシステムまたはFiles UIには以前のサイズが表示されている可能性があります。

ZimaOSではドライブを追加してRAID 5を拡張できますか?

現在のZimaOSドキュメントでは、RAID 5は時間をかけてドライブを追加することで拡張できると説明されています。

拡張中はFilesを閉じるべきですか?

アクティブな書き込みを減らすのは妥当ですが、元のスレッドから、Filesタブを開いていたことが失敗の原因だとは証明できません。

resize2fsはいつ実行すべきですか?

ファイルシステムがEXTであり、基盤となるブロックデバイスがすでに大きくなっていることを確認した後に限って実行してください。

UIが停止した場合、アレイを再構築すべきですか?

mdadmとファイルシステムの確認で実際のストレージ問題が示されるまでは、再構築しないでください。進捗表示が古い状態のままというだけでは、十分な根拠になりません。