ec2-consistent-snapshotで取得したスナップショットからのAmazon EBS RAID0アレイの復元


8

Amazon EC2に新しいMySQLサーバーを構成し、データをEBS RAID0アレイに保存することにしました。これまでのところ、私はec2-consistent-snapshotでこれらのデバイスのスナップショットを撮ることをテストしてきました。

では、これらのスナップショットから新しいインスタンスでアレイをすばやく再構築するにはどうすればよいでしょうか。

ec2-consistent-snapshotを使用して複数のボリュームのスナップショットを作成する場合、RAIDの各デバイスにどのボリュームが使用されたかを知る方法はありません。完全に間違っているかもしれませんが、ボリューム間でデータをストライピングしているので、スナップショットの作成元のボリュームと同じRAID上の場所に各新しいボリュームを配置する必要があるのは当然です。

例:

  • RAID0構成の3x200gbボリューム。
  • vol-1はRAIDの/ dev / sdhデバイス0です
  • vol-2はRAIDの/ dev / sdh1デバイス1です
  • vol-3は、RAIDの/ dev / sdh2デバイス2です。

次のコマンドでec2スナップショットを作成しますec2-consistent-snapshot <options> vol-1 vol-2 vol-3

これで3つのスナップショットが作成されました。それらがどのデバイスであるかを追跡する唯一の方法は、ソースボリュームIDを確認し、次にソースボリュームIDがインスタンスにマウントされているデバイスを確認して、RAIDの詳細を確認することです。ソースボリュームのインスタンスの構成。

これは明らかに信じられないほど手動で行われます...高速ではありません(他のインスタンスが失敗した場合に新しいmysqlインスタンスをすばやく起動するのは明らかに難しくなります。言うまでもなく、その時点でRAID上のデバイスの位置を記録する必要がありますソースボリュームインスタンスがクラッシュした場合、RAID構成を取得する方法がないためです。

したがって、結論として:

  • ec2-consistent-snapshotとソフトウェアRAID0アレイがどのように機能するかで何か不足していますか?
  • そうでない場合、スナップショットが属するRAIDアレイのデバイス/位置がわからないという問題に関する既知の解決策/ベストプラクティスはありますか?

これが明確であることを願っています。ご協力いただきありがとうございます。

回答:


5

ボリューム間でデータをストライピングしているので、スナップショットが作成されたボリュームと同じ場所にRAID上の新しいボリュームを配置する必要があるのは当然です。

私はあなたの前提をテストしました、そしてそれは論理的に見えるかもしれませんが、観察はそうではありません。

これについて詳しく説明します。
私はあなたとまったく同じ要件を持っています。ただし、使用しているRAID0のボリュームは2つだけです。

私はUbuntu 10を使用しており、XFSでフォーマットされたRAID0デバイスを形成する2つのEBSデバイスがあります。

raid0デバイスは、次のコマンドを使用して作成していました。
sudo mdadm --create /dev/md0 --level 0 --metadata=1.1 --raid-devices 2 /dev/sdg /dev/sdh

MYSQLと、/ dev / md0を使用してデータファイルを格納するように構成された他のソフトウェアをインストールしました。

同じボリュームを使用する:行われた後、Iアンマウントすべてのもの、そうのようなレイドを停止し、それを組み立て直す sudo mdadm --assemble /dev/md0 /dev/sdh /dev/sdg 事はのためのものにかかわらずである/dev/sdg /dev/sgh、RAIDが正しく自体を再構成します。

スナップショットの使用:これを投稿して、ec2-consistent-snapshot2つのEBSディスクのスナップショットを一緒に作成します。次に、このディスクからボリュームを作成し、(ソフトウェア用に既に構成されている)新しいインスタンスに接続し、RAIDを再構築し(EBSボリュームの順序も交換してみました)、マウントして準備が整いましたトーゴ。

奇妙に聞こえますが、動作します。


したがって、基本的には、アレイを再構築する場合、どの順序で構築してもかまいません。これはディスクに書き込まれたスーパーブロックデータが原因であると思います。そのため、RAIDコントローラーはデータを元に戻す方法を知っています。これは素晴らしいです!あなたの答えをありがとう、それは私が必要としたものとほぼ同じです!
ジムルーベンシュタイン

4

私は同様の構成(RAID0 over 4 EBSボリューム)を実行しているため、ec2-consistent-snapshotで作成されたスナップショットからRAIDアレイを再構成することと同じ懸念がありました。

さいわい、RAIDアレイの各デバイスには、アレイ内の位置、アレイのUUID、アレイのレベル(RAID0など)を記録するメタデータ(スーパーブロック内)が含まれています。任意のデバイスでこのスーパーブロックをクエリするには、次のコマンドを実行します(「^ this」に一致する行は、クエリされたデバイスを示しています)。

$ sudo mdadm --examine /dev/sdb1
/dev/sdb1:
          Magic : a92b4efc
        Version : 00.90.00
           UUID : 2ca96b4a:9a1f1fbd:2f3c176d:b2b9da7c
  Creation Time : Mon Mar 28 23:31:41 2011
     Raid Level : raid0
  Used Dev Size : 0
   Raid Devices : 4
  Total Devices : 4
Preferred Minor : 0

    Update Time : Mon Mar 28 23:31:41 2011
          State : active
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0
       Checksum : ed10058a - correct
         Events : 1

     Chunk Size : 256K

      Number   Major   Minor   RaidDevice State
this     0     202       17        0      active sync   /dev/sdb1

   0     0     202       17        0      active sync   /dev/sdb1
   1     1     202       18        1      active sync   /dev/sdb2
   2     2     202       19        2      active sync   /dev/sdb3
   3     3     202       20        3      active sync   /dev/sdb4

配列の一部ではないデバイスで同じクエリを実行すると、次のようになります。

$ sudo mdadm --examine /dev/sda1
mdadm: No md superblock detected on /dev/sda1.

これは、このコマンドが実際にはデバイス自体に格納されている情報に依存し、一部の構成ファイルには依存していないことを証明しています。

RAIDデバイスから始めてRAIDアレイのデバイスを調べ、同様の情報を取得することもできます。

$ sudo mdadm --detail /dev/md0

後者ec2-describe-volumesと一緒に使用して、ec2-consistent-snaptshotのボリュームのリストを作成します(-nおよび--debugを使用すると、スナップショットを作成せずにこのコマンドをテストできます)。次のコマンドは、ディレクトリ/ mysqlがボリュームのマウントポイントであり、AWSリージョンがus-west-1であることを前提としています。

$ sudo -E ec2-consistent-snapshot --region us-west-1 --mysql --freeze-filesystem /mysql --mysql-master-status-file /mysql/master-info --description "$(date +'%Y/%m/%d %H:%M:%S') - ASR2 RAID0 (4 volumes) Snapshot" --debug -n $(ec2-describe-volumes --region us-west-1 | grep $(wget http://169.254.169.254/latest/meta-data/instance-id -O - -q) | egrep $(sudo mdadm --detail $(awk '{if($2=="/mysql") print $1}' /etc/fstab) | awk '/ \/dev\//{printf "%s ", $7}' | sed -e 's# /#|/#g') | awk '{printf "%s ", $2}')

0

これであなたの質問に答えられないことはわかっていますが、私は同様のことをしていますが、Amazonの基本ec2-create-snapshotツールとcronスクリプトを使用しています。これはec2-consistent-snapshotほど高速ではありませんが、必要な追加の制御を取得します。fsync、ロック書き込み、そして最も重要なことに、スナップショットに適切な名前を付けて、正しい順序で再構成できるようにします。


私は実際にはXFSを使用しているので、スナップショットを作成している間、ファイルシステムをフリーズします。MySQLのFLUSHおよびLOCKと組み合わせると(ec2-consistent-snapshotがこれをすべて実行します)、毎回一貫したスナップショットが必要です。問題は、今のところec2-consistent-snapshot perlスクリプトを変更することで一時ソリューションを開発したばかりのネーミングです。
ジムルーベンシュタイン
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.