先日、ご紹介した「Amazon EC2で利用できるストレージサービスAmazon EBS(Elastic Block Store)が利用可能に!」のエントリの通り、Amazon Web Servicesにて新しいストレージサービスAmazon EBS(Elastic Block Store)が使えるようになりました。
これらの詳細については「Amazon EC2で利用できるストレージサービスAmazon EBS(Elastic Block Store)が利用可能に!」をご覧ください。
今日は、この新しく追加されたサービスであるAmazon EBSの具体的な使い方やパフォーマンスについてご紹介します。
# 色々やってみたので、ちょっとボリュームあります
今回ご紹介する手順の流れは、おおまかに↓のような感じです。
- ボリューム(仮想ディスク)を作成してみる
- 動いているEC2インスタンス(仮想マシン)にAttach(取り付け)してみる
- パフォーマンスを計測してみる
- スナップショット機能を使ってボリュームのバックアップを取ってみる
- 上記で作成したスナップショットより、ボリュームを復元(リストア)してみる
- ボリュームやスナップショットを削除してみる
- 最後にまとめ
では、早速使ってみたいと思います。
ボリュームを作成してみる
前提として、基本的なセットアップやEC2インスタンス(仮想マシン)は起動しているものとします。
セットアップやEC2でのインスタンス起動については、「Amazon EC2/S3を使ってみた - 1.AWSへの登録〜S3を使う」や、「Amazon EC2/S3を使ってみた - 2.EC2が起こすイノベーション」を参考にしてください。
尚、下記例では私が実際に行ったログを貼り付けていますので、各IDやパラメータは、適宜読みかえるようにして下さい。
ちなみに、今回使用した「Amazon EC2 Command-Line Tools」のバージョンは以下となります。
$ ec2ver 1.3-24159 2008-05-05
では、まず起動しているインスタンスを確認します。
ここでは、インスタンスが稼動しているロケーションやインスタンスIDをメモしておきます。
# 参考:Amazon EC2/S3を使ってみた - 7.Availability Zoneサービスで稼動ロケーションを指定する
$ ec2-describe-instances RESERVATION r-0c16c265 xxxxxxxxxxxx default INSTANCE i-e5fa208c ami-2b5fba42 ec2-75-101-198-177.compute-1.amazonaws.com domU-12-31-39-00-A9-73.compute-1.internal running rx7_server 0 m1.small 2008-08-24T11:28:24+0000 us-east-1b aki-a71cf9ce ari-a51cf9cc
上記の例では、インスタンスの稼動ロケーションは「us-east-1b」となります。
$ ec2-create-volume -z us-east-1b -s 5 VOLUME vol-5026c339 5 us-east-1b creating 2008-08-24T11:29:52+0000
EBSボリューム(仮想ディスク)の作成を行います。
"-z"オプションで、先程メモした稼動ロケーション(上記例だと"us-east-1b")を入力、"-s"でディスクのサイズ(単位はギガバイト[GB]、上記例では5GB)を入力します。
作成後、ボリュームID(上記例だと"vol-5026c339"の部分。"ec2-describe-volumes"コマンドでも確認できます)をメモしておきます。
動いているEC2インスタンスにAttachしてみる
次に、先程作成したEBSボリュームを、既に稼動しているEC2インスタンス(仮想マシン)にAttach(取り付け)します。
$ ec2-attach-volume -d /dev/sdc -i i-e5fa208c vol-5026c339 ATTACHMENT vol-5026c339 i-e5fa208c /dev/sdc attaching 2008-08-24T11:31:27+0000
上記例では、"-d"オプションでインスタンスで認識するデバイス名を指定、"-i"オプションで、どのマシンに接続するかを識別するインスタンスID(先程メモしたもの)、最後に先程作ったボリュームを示すボリュームIDを指定します。
Attachが正常終了すると、"attached"と表示されます。("ec2-describe-volumes"コマンドで確認できます)
Client.InvalidVolume.ZoneMismatch: The volume 'vol-5026c339' is not in the same availability zone as instance 'i-25c3194c'
尚、EC2インスタンスにAttachするEBSボリュームは、稼動ロケーションを揃えておく必要があります。
揃っていない場合は、上記のようなエラーが発生します。
インスタンス上でボリュームを確認してみる
では、ボリュームをAttachできたところで、インスタンスに接続(SSHログイン)してみます。
$ ssh -i rx7_server.id root@ec2-75-101-198-177.compute-1.amazonaws.com
まず、デバイスが認識できているかですが、、、
ec2# ll /dev/sd* brw-r----- 1 root disk 8, 1 2008-08-24 07:29 /dev/sda1 brw-r----- 1 root disk 8, 2 2008-08-24 07:29 /dev/sda2 brw-r----- 1 root disk 8, 3 2008-08-24 07:29 /dev/sda3 brw-r----- 1 root disk 8, 32 2008-08-24 07:31 /dev/sdc
↑きちんと、Attachするときに指定した"/dev/sdc"で認識できていますね。
では、接続したボリュームにファイルシステムを作成します。
ec2# yes | mkfs -t ext3 /dev/sdc mke2fs 1.40.4 (31-Dec-2007) /dev/sdc is entire device, not just one partition! Proceed anyway? (y,n) Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 655360 inodes, 1310720 blocks 65536 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=1342177280 40 block groups 32768 blocks per group, 32768 fragments per group 16384 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736 Writing inode tables: done Creating journal (32768 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 30 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override.
普通にmkfsコマンドで作成しましょう。
種類は何でも良いと思いますが、上記例では普通にext3で作ってみました。
ec2# mkdir /vol ec2# mount /dev/sdc /vol
ファイルシステムも作成したところで、マウントしてみます。
ec2# df Filesystem 1K-ブロック 使用 使用可 使用% マウント位置 /dev/sda1 10321208 1136444 8660476 12% / /dev/sda2 153899044 192072 145889348 1% /mnt none 873880 0 873880 0% /dev/shm /dev/sdc 5160576 141440 4756992 3% /vol
この通り、作成した5GBのボリュームが、問題なく認識できています!
パフォーマンスを計測してみる
少し好奇心を出して、パフォーマンスを測定してみます。
今回は、IOzoneを使ってみました。
ec2# yum install iozone
私は、AmazonEC2の公式イメージ(Fedora8)を使っているので、yumでiozoneをインストールします。
次に、実際に以下3種類のパーティションにファイルサイズ[100KB|10MB|1GB]のそれぞれでiozoneコマンドを実行してみました。
- EC2ローカルボリューム
- /dev/sda1(/)
- EC2ローカルボリューム
- /dev/sda2(/mnt)
- EBSボリューム
- /dev/sdc(/vol)
コマンドは以下の通りですが、"-s"オプションの部分は、それぞれのファイルサイズに置き換えて1回ずつ実行しています。
EC2ローカル(/)
ec2# iozone -i 0 -i 1 -f /root/test -s [100k|10m|1g] KB reclen write rewrite read reread 100 4 378719 552386 855080 900820 10240 4 407657 631903 672265 670729 1048576 4 102304 138443 329611 327563
EC2ローカル(/mnt)
ec2# iozone -i 0 -i 1 -f /mnt/test -s [100k|10m|1g] KB reclen write rewrite read reread 100 4 383089 555842 891947 943890 10240 4 397869 610503 659280 649082 1048576 4 75766 73106 321124 327093
EBSボリューム(/vol)
ec2# iozone -i 0 -i 1 -f /vol/test -s [100k|10m|1g] KB reclen write rewrite read reread 100 4 404910 552812 861268 910042 10240 4 392217 591225 684536 684128 1048576 4 74660 77864 314698 322977
上記は、それほど厳密に計測した数字ではありませんが、"/"(ルートディレクトリ)でマウントしているデバイスの書き込み速度が一番速いものの、大きな差があるわけではなく、実用の範囲ではないかと思います。
この結果は、もっとしっかり測定すれば違う結果となる可能性もあるので、参考程度でお願いします。
スナップショット機能を使ってボリュームのバックアップをとってみる
Amazon EBSでは、作成したボリュームのスナップショットをAmazon S3に保存することが出来ます。
ec2# dd if=/dev/zero of=/vol/test.dump bs=1k count=102400 ec2# ll /vol/ 合計 102520 drwx------ 2 root root 16384 2008-08-24 07:33 lost+found -rw-r--r-- 1 root root 104857600 2008-08-24 07:42 test.dump
↑とりあえず、雀の涙ほどですが、動作確認のため100Mほどのテストファイルを作成します。
EC2インスタンスからログアウトして、、、
$ ec2-describe-volumes VOLUME vol-5026c339 5 us-east-1b in-use 2008-08-24T11:29:52+0000 ATTACHMENT vol-5026c339 i-e5fa208c /dev/sdc attached 2008-08-24T11:31:27+0000
お約束で、ボリュームの状態を確認します。先程使っていたID"vol-5026c339"のボリュームのスナップショットを今から作成します。
$ ec2-create-snapshot vol-5026c339 SNAPSHOT snap-edf41384 vol-5026c339 pending 2008-08-24T11:44:13+0000
↑のような感じで、"ec2-create-snapshot"コマンドで、ボリュームID("ec2-describe-volumes"コマンドで確認できます)を指定するのみです。
$ ec2-describe-snapshots SNAPSHOT snap-edf41384 vol-5026c339 completed 2008-08-24T11:44:13+0000 100%
しばらく待って、スナップショットの状態を見ると、スナップショットが終了(100%と表示)していることが確認できます。
以上で、ボリュームのバックアップは完了です。超簡単。
ちなみに、上記スナップショットの作成元のボリュームは、EC2インスタンスにAttach、そしてマウントしたままの状態ですので、サービスを稼動したままスナップショットを作成することが可能です。
ただし、ボリュームへファイルの書き込みを行っている最中に、取得したスナップショットをリストアした際に整合性を保っているかどうかの確認はしていないので、注意が必要です。
# どうなんだろ?やっぱりダメかな?
尚、スナップショットID(上記例では"snap-edf41384")は復元(リストア)する際に必要となります。(この次に紹介しますので^^;)メモしておきます。
作成したスナップショットより、ボリュームを復元(リストア)してみる
では、先程作成したスナップショット(バックアップ)から、復元(リストア)する形でボリュームを作成します。
$ ec2-create-volume --snapshot snap-edf41384 -z us-east-1b VOLUME vol-5226c33b 5 snap-edf41384 us-east-1b creating 2008-08-24T11:46:58+0000
↑のように、ボリュームを作成するコマンドと同じ"ec2-create-volume"コマンドに、"--snapshot"オプションを付けて、スナップショットID("ec2-describe-snapshots"コマンドで確認できます)を指定します。
尚、ボリューム作成時と同様に、稼動ロケーションも指定する必要があります。
上記の例では、今回作成(復元)したボリュームIDは"vol-5226c33b"となります。
$ ec2-attach-volume -d /dev/sdd -i i-e5fa208c vol-5226c33b ATTACHMENT vol-5226c33b i-e5fa208c /dev/sdd attaching 2008-08-24T11:48:15+0000
では、作成(復元)したボリュームをEC2インスタンスにAttachさせます。この辺は、前半のほうで紹介した手順と同じです。
まだ、EC2インスタンスのOS内で使用されていないデバイスを指定するようにしましょう。
$ ssh -i rx7_server.id root@ec2-75-101-198-177.compute-1.amazonaws.com
では、動作確認のため接続して、、、
ec2# mkdir /vol2 ec2# mount /dev/sdd /vol2
Attachしたボリュームをマウントします。
ec2# ll /vol 合計 102520 drwx------ 2 root root 16384 2008-08-24 07:33 lost+found -rw-r--r-- 1 root root 104857600 2008-08-24 07:42 test.dump ec2# ll /vol2 合計 102520 drwx------ 2 root root 16384 2008-08-24 07:33 lost+found -rw-r--r-- 1 root root 104857600 2008-08-24 07:42 test.dump
すると、今回の例で言うと、バックアップ元のボリュームをマウントしている"/vol"と、先程バックアップを復元(リストア)したボリュームをマウントしている"/vol2"の内容が(一応、簡単だけど)同じであることが確認できます。
ボリュームやスナップショットを削除してみる
ここまで、ボリュームを作成したり、スナップショットを作成したりなど、動作確認をしてきました。
最後に、掃除の意味を込めて、ボリュームやスナップショットの作成方法を紹介します。
ec2# umount /vol ec2# umount /vol2
まず、EC2インスタンスのOS上でマウントしているデバイスをアンマウントします。
今回の例では、スナップショットの分も含めて、2つのボリュームをマウントしていたので、以降それぞれのボリュームに対してコマンドを実行していますのでご注意ください。
EC2インスタンスからログアウトして、、、
$ ec2-describe-volumes VOLUME vol-5226c33b 5 snap-edf41384 us-east-1b in-use 2008-08-24T11:46:58+0000 ATTACHMENT vol-5226c33b i-e5fa208c /dev/sdd attached 2008-08-24T11:48:15+0000 VOLUME vol-5026c339 5 us-east-1b in-use 2008-08-24T11:29:52+0000 ATTACHMENT vol-5026c339 i-e5fa208c /dev/sdc attached 2008-08-24T11:31:27+0000
ボリュームの状況を確認します。
↑では、2つのボリュームがAttachされているのが確認できます。
(左端に"ATTACHMENT"と表示される)
$ ec2-detach-volume vol-5226c33b ATTACHMENT vol-5226c33b i-e5fa208c /dev/sdd detaching 2008-08-24T11:48:15+0000 $ ec2-detach-volume vol-5026c339 ATTACHMENT vol-5026c339 i-e5fa208c /dev/sdc detaching 2008-08-24T11:31:27+0000
Attachしている2つのボリュームをそれぞれDetach(取り外し)します。
$ ec2-describe-volumes VOLUME vol-5226c33b 5 snap-edf41384 us-east-1b available 2008-08-24T11:46:58+0000 VOLUME vol-5026c339 5 us-east-1b available 2008-08-24T11:29:52+0000
再び、ボリュームの状況を確認すると、2つともEC2インスタンスにAttachされていない状況が確認できます。
(左端に"VOLUME"と表示される)
$ ec2-delete-volume vol-5226c33b VOLUME vol-5226c33b $ ec2-delete-volume vol-5026c339 VOLUME vol-5026c339
次に、2つのボリュームをそれぞれ削除します。
$ ec2-describe-volumes VOLUME vol-5226c33b 5 snap-edf41384 us-east-1b deleting 2008-08-24T11:46:58+0000 VOLUME vol-5026c339 5 us-east-1b deleting 2008-08-24T11:29:52+0000
再び、ボリュームの状況を確認すると、2つとも"deleting"となっています。
時間が経てば削除が完了し、上記コマンドで表示されなくなります。
$ ec2-describe-snapshots SNAPSHOT snap-edf41384 vol-5026c339 completed 2008-08-24T11:44:13+0000 100%
最後にスナップショットです。
上記コマンドで、スナップショットの状況を確認します。
↑では、先程作成した1つのスナップショットが確認できます。
$ ec2-delete-snapshot snap-edf41384 SNAPSHOT snap-edf41384
上記コマンドでスナップショットが作成できます。
まとめ
ということで、Amazon EBSについても、Amazon EC2上の延長上で、非常に分かりやすい概念および操作方法で使用することが可能でした。APIが提供されているので、基本的に何でもコマンド一発で操作できます。
コマンド1つで、1GB〜1TBもの大容量の仮想ディスク(ボリューム)を即座に準備できて、即座に使うことができる。しかも、料金は使った分だけ請求される従量制でかなり安価となっています。
公式サイトのAmazon EBSの説明文を読む限りは、作成したボリュームは稼動ロケーションとは異なるロケーションにレプリカを作成している模様で、信頼性という点でも十分にありそうです。(サービスの継続性という意味での可用性は分かりませんでした)
それでもって、料金はというと、容量が1ヶ月あたり$0.1/1GBでかつ、100万のI/Oリクエスト毎に$0.1請求されますが、かなり安価な部類でしょう。
この前も書きましたが、このレベルのインフラを作ろうとすれば巨大な初期投資が必要となり、小さい企業や個人のレベルでは実現できません。
ですが、個人でも払えるレベルの料金体系から使うことが出来る、このAmazonのクラウド環境はかなり魅力です。
あとは、少しずつ日本でも普及が進んで、EC2やS3、そしてEBSの稼動ロケーションで日本が選択できる日が来れば、日本発のWebサービスでも当たり前のように使われる時代になるのではないでしょうか。
参考
- http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1667
- http://developer.amazonwebservices.com/connect/entry.jspa?externalID=1663
- Amazon Elastic Block Store (EBS)
まとめ
クラウドAMAZON EC2/S3のすべて (ITpro BOOKs)
- 作者: 並河祐貴,安達輝雄,ITpro/日経SYSTEMS
- 出版社/メーカー: 日経BP社
- 発売日: 2009/11/05
- メディア: 単行本
- 購入: 4人 クリック: 372回
- この商品を含むブログ (18件) を見る