EBSで組んだRAIDもバックアップ可能。複数のEBS間でクラッシュ整合性のあるスナップショットが取れます

#Amazon EBS

#AWS

Guri / Hajime Oguri

2019.06.03

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

大栗です。

複数のEBS間で整合性のあるスナップショットを取ることができるようになった模様なので試してみます。

Taking crash-consistent snapshots across multiple Amazon EBS volumes on an Amazon EC2 instance
Amazon EBS adds ability to take point-in-time, crash-consistent snapshot across multiple EBS volumes

EBSのスナップショット

今まで複数のEBSを跨いだボリュームのスナップショットは『Amazon EBS RAID アレイのスナップショットの作成方法を教えてください。』に記載があるように、以下の手順で実行する必要がありました。

すべてのアプリケーションで RAID アレイへの書き込みを停止します。
すべてのキャッシュをディスクにフラッシュします。
ファイルシステムの凍結、RAID アレイのマウント解除、さらには EC2 インスタンスのシャットダウンなどのアクションを実行し、関連付けられている EC2 インスタンスが RAID アレイへの書き込みを停止していることを確認します。
RAID アレイに対するすべてのディスク関連アクティビティを停止する手順を行った後、アレイ内の各 EBS ボリュームのスナップショットを取得します。

RAIDなどでは複数のディスクに渡りデータを書き込むため、ディスク間で整合性がある形式でバックアップを取得していないとボリュームが破損してしまいます。そのため今まではRAIDに関わる全てのEBSをオフラインにして書き込みがない状態にしてから各々のEBSに対してスナップショットの取得を行っていました。そのためアプリケーション/ボリュームの停止時間が長くなる傾向がありました。

今回のアップデートでは、複数のEBSに跨ってクラッシュ整合性のあるスナップショットを取得できるようになったので、OSレイヤのフラッシュが不要であればディスクがオンラインのままRAIDボリュームのスナップショットを取得することも可能になります。使用するアプリケーション/ファイルシステムによって安全性が異なるのでお使いのワークロードごとにご判断下さい。

またAmazon DLMを使用してスナップショット取得の定期実行も可能になっています。

提供リージョン

以下のリージョンで提供されています。東京リージョンだけでなく大阪ローカルリージョンでも提供されているのがポイントです。

米国東部 (バージニア北部)
米国東部 (オハイオ)
米国西部 (北カリフォルニア)
米国西部 (オレゴン)
アジアパシフィック (ムンバイ)
アジアパシフィック (ソウル)
アジアパシフィック (シンガポール)
アジアパシフィック (シドニー)
アジアパシフィック (東京)
アジアパシフィック (大阪)
カナダ (中部)
EU (フランクフルト)
EU (アイルランド)
EU (ロンドン)
EU (パリ)
EU (ストックホルム)
南米 (サンパウロ)

注意点

複数ボリュームにわたるEBSスナップショットでは数ミリ秒〜数秒の短時間なI/Oの中断が発生します。時間はインスタンスに接続しているボリュームのサイズや数によって異なります。

やってみる

本内容は東京リージョンでt3.smallを使用したAmazon Linux 2(ami-00d101850e971728d)を起動したインスタンスを前提としています。またスナップショットの取得はManagement Consoleから実行します。

EBSは以下のように、ルートボリュームの他に3個アタッチしています。追加したEBSのデバイスパスは以下としています。

/dev/sdb
/dev/sdc
/dev/sdd

RAIDの設定

基本的にこちらの手順に基づいてRAIDの設定を行います。

Nitro世代のインスタンスであるためOS上からディスクを見ると以下のよう全てNVMeに見えています。

$ ls -al /dev/sd*
lrwxrwxrwx 1 root root 7  6月  2 08:26 /dev/sdb -> nvme2n1
lrwxrwxrwx 1 root root 7  6月  2 08:26 /dev/sdc -> nvme3n1
lrwxrwxrwx 1 root root 7  6月  2 08:26 /dev/sdd -> nvme1n1
$ lsblk
NAME          MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
nvme1n1       259:0    0   8G  0 disk
nvme2n1       259:1    0   8G  0 disk
nvme3n1       259:2    0   8G  0 disk
nvme0n1       259:3    0   8G  0 disk
├─nvme0n1p1   259:4    0   8G  0 part /
└─nvme0n1p128 259:5    0   1M  0 part

ディスクのIDも確認するとボリュームIDも確認できます。

$ sudo /sbin/ebsnvme-id /dev/sdb
Volume ID: vol-021186ed6f00d829b
sdb
$ sudo /sbin/ebsnvme-id /dev/sdc
Volume ID: vol-0ddf8feafcebe1a62
sdc
$ sudo /sbin/ebsnvme-id /dev/sdd
Volume ID: vol-0eac85c3155bce0f3
sdd

以下のコマンドでRAID5のボリュームを作成します。RAID0などにする場合には--levelで0を指定してください。

$ sudo mdadm --create --verbose /dev/md0 --level=5 --name=RAID --raid-devices=3 /dev/sdb /dev/sdc /dev/sdd
mdadm: layout defaults to left-symmetric
mdadm: layout defaults to left-symmetric
mdadm: chunk size defaults to 512K
mdadm: size set to 8380416K
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.

以下のコマンドでRAIDの初期化が終わったか確認します。

/proc/mdstatを見るとまだ初期化しているようです。

 cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 nvme1n1[3] nvme3n1[1] nvme2n1[0]
      16760832 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
      [=======>.............]  recovery = 39.4% (3305560/8380416) finish=1.3min speed=64249K/sec

unused devices: <none>

しばらく待つと初期化が完了します。

$ sudo cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 nvme1n1[3] nvme3n1[1] nvme2n1[0]
      16760832 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>

RAIDの情報を確認します。

$ sudo mdadm --detail /dev/md0
/dev/md0:
           Version : 1.2
     Creation Time : Sun Jun  2 08:56:38 2019
        Raid Level : raid5
        Array Size : 16760832 (15.98 GiB 17.16 GB)
     Used Dev Size : 8380416 (7.99 GiB 8.58 GB)
      Raid Devices : 3
     Total Devices : 3
       Persistence : Superblock is persistent

       Update Time : Sun Jun  2 08:58:53 2019
             State : clean
    Active Devices : 3
   Working Devices : 3
    Failed Devices : 0
     Spare Devices : 0

            Layout : left-symmetric
        Chunk Size : 512K

Consistency Policy : resync

              Name : RAID
              UUID : ec82eb37:11d64f46:b5b1d3f3:cb87639d
            Events : 18

    Number   Major   Minor   RaidDevice State
       0     259        1        0      active sync   /dev/sdb
       1     259        2        1      active sync   /dev/sdc
       3     259        0        2      active sync   /dev/sdd

xfsでフォーマットします。

$ sudo mkfs.xfs -L RAID /dev/md0
meta-data=/dev/md0               isize=512    agcount=16, agsize=261760 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=0
data     =                       bsize=4096   blocks=4188160, imaxpct=25
         =                       sunit=128    swidth=256 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=8 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

RAIDが自動的に再編成されるように/etc/mdadm.confを作成します。

$ sudo mdadm --detail --scan | sudo tee -a /etc/mdadm.conf
ARRAY /dev/md0 metadata=1.2 name=RAID UUID=ec82eb37:11d64f46:b5b1d3f3:cb87639d

ラムディスクイメージを作成します。

$ sudo dracut -H -f /boot/initramfs-$(uname -r).img $(uname -r)

マウントポイントを作成します。

$ sudo mkdir -p /mnt/raid

RAIDをマウントします。

$ sudo mount LABEL=RAID /mnt/raid

起動時にボリュームをマウントするために/etc/fstabに設定を追加します。

#
UUID=94de7db5-d3f1-476b-8f11-0787eb567c32     /           xfs    defaults,noatime  1   1
LABEL=RAID                                    /mnt/raid   xfs    defaults,nofail   0   2

問題なくマウントができるか確認します。

$ sudo mount -a

スナップショットの作成

ここではファイルシステムがオンライン状態でスナップショットを取得します。

適当なファイルをRAIDボリュームにコピーします。

$ sudo cp /var/log/messages /mnt/raid/
$ ls -al /mnt/raid/messages
-rw------- 1 root root 136218  6月  2 09:07 /mnt/raid/messages

スナップショットのコンソールからスナップショットを作成をクリックします。

Select resource typeでInstanceを選択します。これで対象のEC2にアタッチされたEBSでクラッシュ整合性があるスナップショットを取得できます。Instance IDにスナップショット対象のEC2のインスタンスIDを入力します。今回はデータボリュームだけスナップショットを取得するのでExclude root volumeにチェックを入れます。Copy tags from volumeもチェックしておきましょう。説明やタグの設定を行い、スナップショットの作成をクリックします。

スナップショットが完了するまで待ちます。

通常のスナップショット取得と異なり、インスタンス単位のでスナップショットの取得は並行して行われるようです。

スナップショットの開始時刻が同じでEBSのスナップショットが取得できました。

EBSの取り外し

スナップショットを取得したので、リストアを実施します。

まず、既存の外していきます。アンマウントしてRAIDを停止します。

$ sudo umount --verbose /mnt/raid
umount: /mnt/raid をアンマウントしました
$ sudo mdadm --misc --stop /dev/md0
mdadm: stopped /dev/md0

EBSをデタッチします。RAIDに設定したEBSを全て選択してアクションメニューのボリュームのデタッチをクリックします。

デタッチ対象を確認してデタッチするをクリックします。

しばらくするとデタッチされます。

リストアの実施

データの復旧を行います。

まずはスナップショットからEBSボリュームを作成します。

取得したスナップショットの1個を選択して、アクションメニューからボリュームの作成をクリックします。

ここではボリュームタイプやサイズはそのままで設定します。アベイラビリティーゾーンはリストアするEC2と同じにします。設定後にボリュームの作成をクリックします。

他のスナップショットも同様にEBSボリュームを作成します。

次にEC2にアタッチします。

EBSを選択してアクションメニューからボリュームのアタッチをクリックします。

インスタンスに対象EC2のインスタンスID、デバイスにデバイスパスを入力し、アタッチをクリックします。

他のEBSボリュームも同様にアタッチします。

以下のようにディスクが確認できます。

$ ls -al /dev/sd*
lrwxrwxrwx 1 root root 7  6月  2 11:57 /dev/sdb -> nvme1n1
lrwxrwxrwx 1 root root 7  6月  2 11:57 /dev/sdc -> nvme2n1
lrwxrwxrwx 1 root root 7  6月  2 11:58 /dev/sdd -> nvme3n1

$ sudo mdadm --assemble --scan /dev/md0

既存の設定のマウントを行います。

$ sudo mount -a

/proc/mdstatを見ると正常になっています。

$ cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 nvme3n1[3] nvme2n1[1] nvme1n1[0]
      16760832 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]

unused devices: <none>

ファイルを確認すると復旧されています。

$ ls -al /mnt/raid/messages
-rw------- 1 root root 136218  6月  2 09:07 /mnt/raid/messages

さいごに

EBSは16TiBまでのボリュームを作成可能で耐久性も高いので、EC2に複数のEBSをアタッチすることは減っていると思います。しかし、1個のEBSではディスクパフォーマンスが足らなかったり、非常に大きなボリュームが必要な場合には複数EBSが必要になります。その場合バックアップ運用で停止時間に悩むことが多いので今回のアップデートがマッチすると思います。