EBSで組んだRAIDもバックアップ可能。複数のEBS間でクラッシュ整合性のあるスナップショットが取れます
この記事は公開されてから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が必要になります。その場合バックアップ運用で停止時間に悩むことが多いので今回のアップデートがマッチすると思います。
