web-dev-qa-db-ja.com

LVMを含むMDADMRAID5を縮小する

計画:

私は数年前からパーソナルサーバーでRaid5アレイを拡張してきましたが、このアプリケーションにより適したものに移行する時が来ました。メディアやバックアップなどを含む6x8TBドライブを蓄積しました。

すべてのドライブを収容するためにSynology8ベイデバイスを購入しましたが、データを移動しようとしています。ここから問題が発生します...

追加の8TBデバイスを1つ購入し、Raid5から1つのデバイスに障害が発生し、2つを使用してSynologyでRaid1ボリュームを作成しました。 Synologyでは、別のドライブ(または5)を追加するときにRaid1をRaid5にアップグレードできます。私は8TBのデータをこの新しいドライブに移動し、元の40TBのレイドボリュームから合計16TBをクリアするために、私が置いているストレージスペースのすべてのビットを使用しました。

計画では、元のボリュームを24tbに減らし、Raid5を3 + 2 Raid6に再形成し、余分な2つのドライブを故障させてSynologyに追加し、残りのスペースのほとんどを移動します。 Rinceが繰り返され、すべてのデータが交差している必要があります。

これまでの手順:

/ dev/md127は/ srv/mediaにマウントされ、LVMにvg_data/lv_mediaが含まれています。まず、ボリュームをアンマウントします。

umount /srv/media

続行する前に、fsが正常であることを確認してください

e2fsck -ff /dev/vg_data/lv_media

LVMの論理ボリュームを空き量(16tb)だけ減らします

lvreduce -L -16t -r -v vg_data/lv_media

LVMがセグメントを作成した場所を調べます(私が何年にもわたってそれらを割り当てたので、lv_mediaはもはや隣接していません)

pvs -v --segments /dev/md127

一部のセグメントは物理ボリュームの終わりに向かっており、中央に空き領域のギャップがあります。後続のセグメントをドライブの先頭に近いギャップに手動で移動します。これには、セグメントの分割や新しいセグメントの作成が含まれる可能性がありますが、私の場合は、十分なスペースを解放するためにセグメントを移動する必要がありました。

pvmove --alloc anywhere /dev/md127:4982784-5046783 /dev/md127:284672-348671

LVM PVのサイズを変更して、RAID上のスペースを解放します。

pvresize -v --setphysicalvolumesize 24000g /dev/md127

RAIDを縮小します(再形成する前に)

mdadm --grow /dev/md127 --size=25769803776

そして、これは私が立ち往生しているところです。 mdadm RAIDは、LVMが使用しているスペースが少なくなったことを確認/確認することを拒否し、すでに割り当てられているスペースを超えてアレイを縮小できないと文句を言います。

mdadm:/ dev/md127のデバイスサイズを設定できません:デバイスにスペースが残っていません

安全に配列のサイズを小さくする方法についてのアイデアはありますか?

4
mythos

@frostschutzあなたの美しさ!どうしてそれを見逃したのかわかりませんが、先週はあまりにも多くのマニュアルページを読んだに違いありません!

mdadm --grow /dev/md127 --array-size=25769803776

これは、サイズ変更後もデータが損なわれていないことを確認するための一時的で安全な可逆的な方法です。そうでない場合は、データに影響を与えることなく、同じ方法でサイズを復元できます。

e2fsck -ff /dev/mapper/vg_data-lv_media

このチェックはエラーなしで合格したので、準備は完了です。 Raid5からRaid6への変更により、移行に必要のない複雑さが増すようです。アレイの形状を変更する最も安全な方法は、プロセスにスペアを追加することです。

mdadm --grow /dev/md127 -l5 -n4 --backup-file /srv/cache/raid.backup

バックアップファイルはSSDにあり、少しでも役立つことを願っています。これまでのところ順調に進んでおり、この話にハッピーエンドがあれば、この答えを受け入れます...

1
mythos