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

RAIDの容量は、すべての物理ディスクが大きなものに交換されても変わらないことがあります。なぜなら、交換プロセスと拡張プロセスは別だからです。まず、必要なすべてのメンバーが大きくなり、完全にリビルドされていることを確認してください。その後、RAIDデバイス、仮想ディスク、パーティション、ストレージプール、ファイルシステムの各層が拡張されているかを確認します。どの層かがまだ古い境界で終わっている場合、NASは引き続き古い使用可能容量を報告します。

必要なすべてのRAIDメンバーが実際に大きくなっていることを確認する

トレイ上のドライブラベルではなく、まずアレイメンバーリストから始めてください。各ディスクのモデル、シリアル番号、報告サイズ、ベイ、RAIDの役割を記録します。クラシックなミラーやパリティグループは通常、最小のアクティブメンバーより多くのスペースを露出できないため、古いディスク1台、容量不足の交換ディスク1台、またはアレイに受け入れられていないメンバー1台があると、グループ全体のサイズが以前のままになることがあります。これが、ミラーでディスクを1台だけ交換しても使用可能容量は増えず、交換準備状態が改善される理由でもあります。

「正常」なダッシュボードのバッジだけに頼らないでください。交換ディスクがホットスペア、未使用デバイス、または故障候補ではなく、アクティブなメンバーであることを確認してください。リビルドやリシルバーが100％完了し、アレイが冗長状態に戻ってから次の交換を開始したことを確認してください。大きなドライブでミラーを順次交換して拡張する方法に関するZimaSpaceの関連ガイドでは、交換シーケンスが完了するまで容量が通常固定される理由を説明しています。

NASが交換ディスクを古いサイズとして報告している場合、そのメンバーのパーティションテーブルやコントローラーの表示を調べてください。一部のアレイはディスク全体ではなくパーティションを使用しており、コピーされたパーティションレイアウトが古い終端を保持していることがあります。また、一部のコントローラーはドライブのフルネイティブ容量ではなく、仮想化または切り詰められたサイズを表示することもあります。アレイを拡張する前にメンバーサイズの不一致を修正してください。不整合な基盤の上で拡張すると、ストレージスタックの回復が困難になる可能性があります。

RAID層が拡張されているか確認する

物理メンバーが大きくなったからといって、RAIDデバイスの容量が自動的に大きくなるわけではありません。ストレージパスは物理ディスク、RAIDデバイスまたは仮想ディスク、パーティション、ストレージプールまたはボリュームマネージャー、ファイルシステムという別々の層として考えてください。最初の層は新しいサイズを示していても、その上のすべての層がまだ古い境界で終わっている場合があります。したがって、正しい診断の質問は「新しいディスクは見えていますか？」ではなく「どの層で報告されるサイズの増加が止まっていますか？」です。

ソフトウェアRAIDは、必要なすべてのメンバーが交換された後に別途拡張操作が必要なことが多いです。実用的なmdadm拡張手順では、明示的な拡張ステップが実行されるまでアレイは古いサイズのままであることが示されています。アプライアンス管理のNASシステムでは、同じ操作が「拡張」「増加」「容量最大化」「RAIDグループのサイズ変更」として表示されることがあります。ハードウェアRAIDでは、OSが追加のセクターを認識する前に仮想ディスクの拡張が必要な場合があります。

アレイがクリーンで冗長性があり、未解決の読み取りエラー、タイムアウト、リセットエラーがない場合にのみ拡張操作を開始してください。現在のアレイ状態を保存し、代替不可能なデータの別のバックアップを確認してください。拡張はメタデータを書き込み、数時間かかることがあります。アレイが劣化している場合やドライブが繰り返し切断されている間に開始すると、容量の問題がデータ整合性のリスクに変わります。

未完了のリビルドと拡張ステップの未実行を区別する

未完了のリビルドと拡張操作の未実行は同じ見かけの症状を引き起こすことがありますが、証拠は異なります。未完了のリビルド中は、新しいディスクがまだ同期中であったり、アレイが劣化していたり、期待されるメンバー数や冗長性レベルが回復していない場合があります。拡張ステップが欠落している場合は、すべてのメンバーがアクティブで正常ですが、RAIDデバイスは依然として正確に古いサイズを報告します。

何かを変更する前に各層のサイズを比較してください。物理メンバーの一つが小さい場合はメンバーの不一致を解決します。すべてのメンバーが大きいがRAIDデバイスが古い場合はRAIDレベルの拡張制御を使用します。RAIDデバイスが大きいがパーティションやファイルシステムが古い場合はメンバーディスクに触るのをやめて上位層の作業を行います。ユーザーは上位層のリサイズ問題をディスク交換失敗と誤解し、最もリスクの高い部分を不必要に繰り返すことがよくあります。

再構築が完了しても空き容量が配列に割り当てられたとは限りません。Super Userの大容量交換ディスクに関する議論では、大容量交換だけではRAIDグループのサイズは変わらないと強調されています。このパターンは診断の手がかりとして扱い、普遍的なコマンドシーケンスとは考えないでください。具体的な操作はNASがmdadm、ZFS、Btrfs、LVM、ハードウェアコントローラー、または独自のストレージマネージャーを使用しているかによって異なります。

パーティション、プール、ファイルシステムを順番に拡張する

RAIDデバイス自体が大きなサイズを報告したら、次の層を飛ばさずに確認します。基盤となる配列が大きくなっていても、パーティションは古いセクターで終わっている場合があります。ストレージスタックがパーティション化されたRAIDメンバーを使用している場合は、開始セクターとタイプを保持しつつ正しいパーティションを拡張してください。RAIDデバイスがボリュームマネージャーやストレージプールに直接供給している場合は、その層を再スキャンして新しい領域を認識させます。

ディスク交換時にもパーティションレイアウトは重要です。Server Faultのmdadmメンバー交換に関する議論では、交換用パーティションは配列が大容量を使用できるように十分なスペースを提供しなければならないと指摘されています。別のシステムから破壊的なコマンドをコピーしないでください。リサイズ前に現在の開始・終了セクター、ファイルシステムの種類、マウントポイント、ボリュームマネージャーの関係を記録してください。

最後にファイルシステムを拡張します。ファイルシステムは、RAIDデバイス、パーティション、およびプールが既に提供しているスペースのみを使用できます。ファイルシステムの操作が完了したら、ブロックデバイスのサイズ、ファイルシステムのサイズ、マウントされた空き容量、およびNASダッシュボードを比較してください。これら4つすべてで一貫した増加が確認できれば、拡張が途中で止まらずユーザーが見えるストレージ層に達したことを意味します。

既存のRAIDレイアウトが成長できない場合を知る

一部のRAID実装は、すべてのディスクが大きくてもメンバー交換後に既存の仮想ディスクを拡張できません。その他は特定のRAIDレベル、メンバー数、パーティションレイアウト、ファームウェアバージョンでのみ成長をサポートします。静的ボリュームは新しいアレイへの移行が必要な場合があり、コントローラーは元のボリュームを拡大する代わりに追加の論理ボリュームを作成して余分なセクターを公開することがあります。

システムが文書化された、または明確に検証された成長パスを提供しない場合、アレイがメディアまたはリンクエラーを報告する場合、または唯一の提案された操作がテスト済みバックアップなしにメタデータを再作成する場合は停止してください。より安全な代替策は、新しい適切なサイズのアレイを作成し、データをコピーして検証し、サービスを切り替え、復元チェックが合格するまで古いストレージを保持することです。ホームNASバックアップスケジュールの設定に関するZimaSpaceの記事は、アレイの可用性と復元可能なコピーを分離するのに役立ちます。

拡張は、アレイが冗長で、必要なすべてのメンバーが正常で、RAIDデバイスが期待される大きなブロック範囲を示し、上位のストレージレイヤーがそれに一致し、実際のファイルが書き込み、読み取り、検証できる場合にのみ完了します。物理ディスクが大きくてもRAID実装が成長できない場合、容量が変わらないのはプラットフォームの制限であり、交換失敗ではありません。

よくある質問

より大きなドライブ1台でRAID 1の容量は増えますか？

通常は不要です。従来の2台ミラーは通常、小さい方のアクティブメンバーによって制限されます。もう一方のメンバーを交換し、リビルドを完了してから、必要なアレイ、パーティション、プール、ファイルシステムの拡張を行ってください。

RAIDドライブをすべて交換した後、再起動は必要ですか？

再起動は一部のシステムでデバイス検出を更新することがありますが、必要な成長操作の代わりにはなりません。再起動の前後で各レイヤーの報告サイズを確認し、再検出と拡張を混同しないようにしてください。

アレイが成長している間もNASを使い続けられますか？

多くのシステムはオンライン成長中にアクセスを許可しますが、別の障害が発生するとパフォーマンスが低下しリスクが増加します。検証済みのバックアップを維持し、重い書き込みを減らし、エラーを監視し、特定のRAID実装の制限に従ってください。