なぜすべてのドライブを交換してもRAIDの容量が変わらないのですか？

RAIDの容量は通常、ストレージスタックのある層がまだ古い境界を示しているため変わりません。すべての交換ディスクがアクティブで完全に再構築されたメンバーであることを確認し、物理ディスク、メンバーパーティション、RAIDデバイス、ボリューム層、マウントされたファイルシステムの報告サイズをこの順で比較してください。最初に古いサイズを報告する層が通常、拡張すべき層です。

すべての交換ディスクがアクティブメンバーになっていることを確認する

容量画面ではなく、まずアレイの状態を確認してください。大きなディスクがまだスペア、交換対象、再構築中、または利用不可のメンバーとしてリストされている場合、RAIDグループの共通サイズはまだ増加しません。変更を加える前に、すべてのメンバーのシリアル番号、役割、使用可能セクター数、再構築状態、エラーカウンターを記録してください。

ミラーの場合、ミラーを定義するすべてのメンバーが十分に大きくなるまで容量は通常増えません。パリティRAIDでは、現在のジオメトリに参加するすべてのメンバーがより大きなコンポーネントサイズを示す必要があります。安全な交換手順は、1台ずつディスクを交換し、クリーンな再構築を待ち、アレイを検証してから次のディスクを交換することです。ZimaSpaceの「ミラーメンバーを1台ずつ交換する方法」では、中間段階で使用可能容量が変わらない理由を説明しています。

まだ古いサイズを報告している最初のストレージ層を見つける

NASは複数の独立した容量制限を積み重ねていることがあります：物理ディスク、パーティションテーブル、RAIDメンバー、RAIDデバイス、暗号化マッピング、LVM物理ボリューム、論理ボリューム、ストレージプール、ファイルシステム。ハードウェアの交換は最初の層のみを変更します。上位のすべての層は、マウントされた共有が追加容量を使用できるように、より大きな境界を検出または通知される必要があります。

「拡張」ボタンを何度も押す代わりに、各層で表示されるサイズを書き留めてください。正しい診断は、下位層が大きいのに次の層が古いサイズのままである最初の変化点です。

交換パーティションがまだ古い境界で終わっていないか確認する

多くの交換作業では、RAIDメタデータが同じオフセットで始まるように元のパーティションテーブルをコピーします。これによりアライメントとメンバーの識別が保護されますが、古いパーティションの末尾の後に大きな未使用領域が残ることもあります。物理ディスクは大きいのに、アレイに提示されるRAIDメンバーはまだ古いサイズのままです。

テラバイト単位のラベルではなくセクター数を比較してください。同じ公称容量で販売されるドライブでも使用可能なセクター数はわずかに異なり、サイズ不足の交換パーティションはアレイがより大きな共通コンポーネントサイズを選択するのを妨げます。アクティブなメンバーでパーティションを安易に再作成せず、開始セクター、パーティションタイプ、RAIDメタデータレイアウトを保持し、検証済みバックアップ後にプラットフォームがサポートする変更のみを行ってください。

RAID層が実際に拡張されていることを確認する

正常な状態と大きなメンバーがあっても、RAIDデバイス自体が新しいジオメトリを採用しているとは限りません。ストレージシステムによっては、最後の交換と再構築後に自動的に拡張されるものもあれば、別途アレイレベルの拡張操作が必要なものもあります。Linuxのmdでは、例えば基盤となるメンバーデバイスが大きなサイズを示した後もRAIDデバイスは明示的な拡張ステップが必要です。

拡張を開始する前に、アレイがクリーンであること、すべての期待されるメンバーがアクティブであること、再構築やスクラブが実行されていないこと、最近のログに新しい読み取り、書き込み、タイムアウト、リンクエラーがないことを確認してください。拡張操作はジオメトリやコンポーネントサイズを変更するものであり、未解決の劣化状態を隠すために使うべきではありません。

RAIDの上位にある暗号化、LVM、ストレージプールの境界を調査する

RAIDデバイスが大きくなっても論理ボリュームが変わらない場合、追加のブロックは中間層で待機しています。暗号化マッピングは大きなデバイスを再スキャンする必要があるかもしれません。LVM物理ボリュームは新しいエクステントを認識しなければならず、ボリュームグループがそれらを割り当て、論理ボリュームが拡張されて初めてファイルシステムが成長できます。

容量ツールがスタックの「どこか」に空き容量を報告しても、直接ファイルシステムに飛びつかないでください。各マッピングやボリュームオブジェクトが示すサイズを検証してください。シン・プロビジョニングやプールシステムでは、未割り当てのプール空間とマウントされたファイルシステム内の空き容量は区別すべきであり、互換性はありません。

ブロックデバイスが大きくなってからファイルシステムを拡張する

ファイルシステムは、基盤となるデバイスが現在提示しているブロック範囲のみを使用できます。Ext4、XFS、Btrfs、ZFSなどのファイルシステムは、それぞれ異なる拡張ルール、マウント状態の要件、安全チェックがあります。まずファイルシステムとストレージスタックを特定し、他のプラットフォームのコマンドを借用せずにサポートされている手順を使ってください。

ZFSは最終ステップが実装依存である理由の良い例です。すべてのミラーメンバーが交換された後でも、ZFSミラーはプールが容量を認識する前に新しいデバイスサイズの拡張が必要な場合があります。Btrfsも同様に、交換が成功しても大きなデバイス境界の認識が必要なことがあります。正しい対応はメンバーデバイスを所有する層によって異なります。

プラットフォームが既存レイアウトのインプレース拡張をサポートしない場合は中止する

一部のRAIDコントローラー、アプライアンスレイアウト、パーティションスキーム、ファイルシステムは現在の構成をその場で拡張できません。拡張できるRAIDレベルが限られていたり、すべてのメンバーが完全に一致する必要がある場合もあります。管理インターフェースにサポートされた拡張パスがない場合、ディスクサイズが似ているからといって別のストレージスタックのコマンドを無理に使わないでください。

メンバーの履歴が矛盾している、アレイが劣化している、ヘルスカウンターが増加している、パーティションレイアウトを安全に変更できない、プラットフォームにインプレース拡張方法が記載されていない場合は中止し、バックアップと再作成による移行を計画してください。サポートされた拡張後は、すべての層で新しいサイズを検証し、プラットフォームの整合性チェックを実行し、通常のアプリケーションアクセスを確認し、拡張前後の状態を新しい基準として保存してください。