web-dev-qa-db-ja.com

raid-1 madmを使用して、既存の8TBEBSディスクをライブで縮小します。可能ですか?リスク?

初期状況
Amazonに8 TB EBSドライブ(ext4、パーティションなしで直接マウント))があります
私は何年もの間sw-raidを使用していなかったので、その方法でディスクを縮小できるという私の仮定は間違っているかもしれません。

ゴール
このEBSドライブを本番システムでライブで5TB(-3TB)に縮小したい
ドライブは常に100〜200mb /秒で書き込まれます(本番データベースとツール)

問題 AmazonはEBSの縮小を提供していません。私が見つけた(そして過去に使用した)唯一の解決策は、2番目のEBSを作成し、通常は「rsync」を使用してすべてをコピーすることでした。
それはオプションではありません。EBSは遅く、サイズが2TBを超えるファイル(データベースファイル)を永続的に変更するシステムがあることを考えると、rsyncは変更に追いつくことができませんでした。

アイデア EXT4 8TBディスクをRAID-1に「変換」することを考えました(最初は2番目のディスクがありません)。ディスクの最後にメタデータを追加するメタデータバージョンを使用します(そのためにファイルシステムを縮小することができます)。

最初の質問 8TBディスクのmd0を作成するときに、EXT4として再度マウントし、それがレイドディスクであることを無視するのを妨げるものはありますか?
私が理解したように、唯一の変更は、実際には「メタデータ」が追加(追加)されることです。したがって、「合法的に」通常のext4ディスクである必要がありますか?
本当 ?そして、それをMD0としてマウントし、それに書き込むとき、それはまだ本当ですか?

それがリスクのないことを考えると、2番目のディスクがない状態でmd0を作成し、それをマウントします(したがって、関連するサーバーの数分のダウンタイム)

ここで、ファイルシステムのサイズを3TB小さくしてから、mdadm --grow(shrink)md0を合計サイズ5TBに縮小します。
次に、2番目のEBSドライブ(5TB)を2番目のディスクとしてレイドに追加して同期させたいと思います。

2番目の質問それはできますか?そのように5TBのディスクを追加しますか?

番目の質問
今すぐ元の8TBディスクを取り外して、シングルディスクmd0を使い続けるか、md0のext4を直接マウントして、raidをまったく使用しないようにします。

Mdadmが適切でない場合、LVMは対応していますか? (ext4との互換性が維持されているようで、完了後に直接マウントに戻ることができるため、mdadmにアクセスしました。LVMでは不可能です)

長いテキストでごめんなさい。私は何かを逃したと思います。その問題を解決するためにmdadmを使用して言及された他の記事や回答がないほど簡単なことはありません。

1
John

冒険のための確かな計画のように聞こえます。あなたが説明した技術的な方法はしっかりしているように聞こえ、うまくいくはずです。それでもなお、これは別のマシンで事前にテストする必要があり、移行部分を検証するために、特に稼働している必要があるため、より多くの時間が必要になります。

上記の質問を読んだことによるいくつかのメモを要約します。

  • 関係するリスクはビジネスリスクです。あなたはそれを100-200MBのデータベース書き込みを伴うライブシステムとして説明しています。このデータは、進行中のビジネスからのものである可能性があります。技術的な詳細に加えて、この移行にはインスタンスが数時間停止するリスクが含まれていることを明確にする必要があります。復旧の目的だけでなく、計画停止中にオフラインデータベースを使用して移行することをお勧めします。
  • アイデアはしっかりしているように聞こえ、おそらくうまくいくでしょう。必要なすべての詳細を取得するために、テストと時間をかけて投資する必要があります。
  • ディスク上にパーティションテーブルがないため、ext4を縮小し、ディスクの最後にメタデータを使用してmdraidを作成しても問題ないとおっしゃいました。これは、ext4パーティションのデータには影響しません。これはext4メタデータと重複するため、ディスクの先頭にあるメタデータでは確実に機能しません。
  • メタデータはディスクの最後に追加されますが、直接ではありません。正確な位置は、ブロックサイズ、ブロックの量、その他の詳細などのハードドライブのプロパティによって異なります。これもこの設定でつまずく石です。別の管理者がext4を拡張した場合、最終的にmdadmメタデータを強制終了します。
  • missingディスクを使用してRAIDを作成することは可能ですが、どのディスクがmissingであるかを指定する必要があります。
  • raid-1の場合、これは通常のディスクとして扱うことができるという仮定は正しいと思います。 /dev/sd<x>が使用されている限り、ブロックの複製とメタデータの更新、事実上レイドメカニズムはアクティブになりません。したがって、後で接続されたボリュームを同期するには、マウントを/dev/md<x>に移行する必要があります。
  • 5 TBディスクを追加すると機能するはずです。この時点で、これはmdadmのコア機能であり、障害が発生したraid-1ディスクを置き換えます。この段階では、上記の手順は関係ありません。
  • メタデータブロックは次の成長後の未定義の時点で消滅するため、移行後にレイドを削除します。これにより、ボリューム上のデータが完全に失敗するリスクがあります。このような最終的なアクションのためにレイドを維持する必要がある場合は、最初にメタデータを使用してレイドを作成し、ext4を/dev/<mdx>の上にのみ作成することが重要です。
  • Lvmではなくmdadmのルートを選択することをお勧めします。将来的には、どちらもカーネルレベルのレイドブロックレイヤーを使用します。 mdadmはlvmよりも柔軟性があります。 raidとlvmを組み合わせて必要とする場合、そのmdadmがraid部分に使用されるのが一般的です。 ebsとext4を簡単に拡張できるはずなので、lvmをセットアップから除外しても問題ありません。

実用的なヒント:このようなサイズのディスクで最近のext4ツールを使用してください。

2
hargut