2014年5月30日金曜日

EBS で暗号化がサポートされたのでベンチマークしてみた。

Amazon Web Service (AWS) のブロックストレージサービスEBSで暗号化がサポートされました。
使い方はとても簡単 EBS を作成するときに Encryption チェックボックスにチェックを入れるだけ。


一覧表示でもEncrypt の項目が追加されています。


残念ながら、ルートボリュームでは利用できないようです。


気になるのは暗号化による性能劣化です。マニュアルにも以下の記載があります。

 you can expect the same provisioned IOPS performance on encrypted volumes as you would with unencrypted volumes with a minimal effect on latency.
暗号化ボリュームでも最小限のレイテンシで暗号化していないボリュームと同じプロビジョンドIOPS性能を期待できる。
実際に iozone で測定してみました。使用したインスタンスサイズは、m3.midium です。
まずは暗号化なしの場合。


こんな感じです。大きくへこんだところがあるのは多分の測定時に何か撹乱要因があったのでしょう。
次は暗号化ありの場合



ほとんど違いが分かりません。ちなみにこれは書き込みの場合をグラフ化したものです。
読み込みはほとんどIOPSが出ず、メモリに収まった感じだったので、省略します。

ファイルシステムを利用した場合は、ワークロードによっても影響度が変わってくると思いますが、暗号化のオーバーヘッドはほとんど無視できるようです。


2014年5月20日火曜日

Amazon Web Service (AWS) で一つの EC2 インスタンスにいくつ EBS がつけられるか試してみた。

EC2インスタンスに何個EBSがつけられるの?

Amazon Web Service (AWS) で 一つのEC2インスタンスに何個 EBS がくっつけられるのかマニュアルを探してみたけれど、以下の記載しかなくどうもはっきりしたことが分からないので、実際にためしてみた。

やってみる

Management Console から インスタンスウィザードを起動して、"Step 4: Add Storage"のところで、"Add New Volume" を連打した。"/dev/sdb" からはじまり、"/dev/sdz" を通り過ぎて "/dev/xvdz" が表示されたあたりで、このあたりで許してあげようと思い "Launch Instance"。

結果

一見インスタンス自体は問題なく起動しようとしているように見える。がいつまでたってもSSHログインできない。get system log をみると以下のように、Bug を踏んでいた。
4394230.182195] kernel BUG at fs/sysfs/group.c:65!
[4394230.182198] invalid opcode: 0000 [#1] SMP
[4394230.182203] Modules linked in:
[4394230.182207] CPU: 0 PID: 19 Comm: xenwatch Tainted: G        W    3.10.35-43.137.amzn1.x86_64 #1
[4394230.182215] task: ffff88002492c710 ti: ffff880024936000 task.ti: ffff880024936000
[4394230.182219] RIP: e030:[<ffffffff811eb772>]  [<ffffffff811eb772>] internal_create_group+0x202/0x230
[4394230.182228] RSP: e02b:ffff880024937c50  EFLAGS: 00010246
[4394230.182232] RAX: 0000000000000400 RBX: ffff880003544000 RCX: 0000000000000000
[4394230.182236] RDX: ffffffff8184dfc0 RSI: 0000000000000000 RDI: ffff880003544080
[4394230.182241] RBP: ffff880024937c88 R08: 00000000000163c0 R09: ffff8800260163c0
[4394230.182245] R10: ffffea0000927d00 R11: ffffffff81311bb2 R12: ffff880003590000
[4394230.182250] R13: ffffffff8184dfc0 R14: 0000000000000000 R15: ffff880003544070
[4394230.182259] FS:  0000000000000000(0000) GS:ffff880026000000(0000) knlGS:0000000000000000
[4394230.182264] CS:  e033 DS: 0000 ES: 0000 CR0: 000000008005003b
[4394230.182268] CR2: 0000000000000000 CR3: 000000000180c000 CR4: 0000000000002660
[4394230.182273] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[4394230.182277] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[4394230.182281] Stack:
[4394230.182284]  ffff880003544080 ffffffff81256951 ffff880003544000 ffff880003590000
[4394230.182291]  ffff880003544000 ffff880003544070 ffff880003544070 ffff880024937c98
[4394230.182298]  ffffffff811eb7b3 ffff880024937ca8 ffffffff810f84b4 ffff880024937ce8
[4394230.182305] Call Trace:
[4394230.182311]  [<ffffffff81256951>] ? kobj_kset_leave+0x51/0x60
[4394230.182316]  [<ffffffff811eb7b3>] sysfs_create_group+0x13/0x20
[4394230.182324]  [<ffffffff810f84b4>] blk_trace_init_sysfs+0x14/0x20
[4394230.182331]  [<ffffffff8123ecfd>] blk_register_queue+0x3d/0x110
[4394230.182336]  [<ffffffff81245a0d>] add_disk+0x1cd/0x4a0
[4394230.182341]  [<ffffffff81324a1d>] blkback_changed+0xd3d/0x1010
[4394230.294407]  [<ffffffff812da098>] xenbus_otherend_changed+0x98/0xa0
[4394230.294418]  [<ffffffff812dc083>] backend_changed+0x13/0x20
[4394230.294433]  [<ffffffff812d9436>] xenwatch_thread+0xb6/0x170
[4394230.294440]  [<ffffffff81070e10>] ? wake_up_bit+0x30/0x30
[4394230.294454]  [<ffffffff812d9380>] ? unregister_xenbus_watch+0x230/0x230
[4394230.294462]  [<ffffffff8106fee0>] kthread+0xc0/0xd0
[4394230.294477]  [<ffffffff8106fe20>] ? kthread_create_on_node+0x120/0x120
[4394230.294485]  [<ffffffff8144a12c>] ret_from_fork+0x7c/0xb0
[4394230.294498]  [<ffffffff8106fe20>] ? kthread_create_on_node+0x120/0x120
[4394230.294503] Code: 8b 7d d0 89 4d c8 e8 8e e7 ff ff 4c 8b 65 d0 8b 4d c8 e9 28 ff ff ff 4c 8b 65 d0 e9 1f ff ff ff 48 83 7f 30 00 0f 85 3e fe ff ff <0f> 0b b8 ea ff ff ff e9 29 ff ff ff be c3 00 00 00 48 c7 c7 ff


以下のようなログも出力していたので、多分デバイス名の付け方に問題があったのだろう。

[4394230.181916] WARNING: at fs/sysfs/dir.c:530 sysfs_add_one+0xa5/0xd0()
[4394230.181921] sysfs: cannot create duplicate filename '/class/block/xvdt'
[4394230.181925] Modules linked in:
[4394230.181931] CPU: 0 PID: 19 Comm: xenwatch Not tainted 3.10.35-43.137.amzn1.x86_64 #1
[4394230.181937]  0000000000000009 ffff880024937b50 ffffffff8143c559 ffff880024937b88
[4394230.181945]  ffffffff8104bac1 00000000ffffffef ffff88000358acb0 ffff880024937c38
[4394230.181961]  ffff880024aad000 0000000000000001 ffff880024937be8 ffffffff8104bb2c
[4394230.181969] Call Trace:
[4394230.181986]  [<ffffffff8143c559>] dump_stack+0x19/0x1b
[4394230.181995]  [<ffffffff8104bac1>] warn_slowpath_common+0x61/0x80
[4394230.182000]  [<ffffffff8104bb2c>] warn_slowpath_fmt+0x4c/0x50
[4394230.182015]  [<ffffffff811e9955>] sysfs_add_one+0xa5/0xd0
[4394230.182020]  [<ffffffff811ea5a5>] sysfs_do_create_link_sd+0x105/0x200
[4394230.182026]  [<ffffffff811ea6c1>] sysfs_create_link+0x21/0x40
[4394230.182041]  [<ffffffff81311de4>] device_add+0x3e4/0x6d0
[4394230.182047]  [<ffffffff81310517>] ? dev_set_name+0x47/0x50
[4394230.182061]  [<ffffffff812459fd>] add_disk+0x1bd/0x4a0
[4394230.182068]  [<ffffffff81324a1d>] blkback_changed+0xd3d/0x1010
[4394230.182084]  [<ffffffff812da098>] xenbus_otherend_changed+0x98/0xa0
[4394230.182091]  [<ffffffff812dc083>] backend_changed+0x13/0x20
[4394230.182097]  [<ffffffff812d9436>] xenwatch_thread+0xb6/0x170
[4394230.182110]  [<ffffffff81070e10>] ? wake_up_bit+0x30/0x30
[4394230.182117]  [<ffffffff812d9380>] ? unregister_xenbus_watch+0x230/0x230
[4394230.182124]  [<ffffffff8106fee0>] kthread+0xc0/0xd0
[4394230.182137]  [<ffffffff8106fe20>] ? kthread_create_on_node+0x120/0x120
[4394230.182145]  [<ffffffff8144a12c>] ret_from_fork+0x7c/0xb0
[4394230.182157]  [<ffffffff8106fe20>] ? kthread_create_on_node+0x120/0x120

まとめ

AWS 的には、EBSを何個つけても問題なさそうだが、実際にたくさんEBSを付ける場合にはいろいろ考慮が必要なようだ。

2014年5月12日月曜日

RDSのMySQL でリードレプリカを作成するときの3つのポイント

RDS-MySQL のリードレプリカ

MySQL には、多くの皆さんがご存じのとおり、リードレプリカという機能がある。
簡単に言うと DB のコピーを自動的にとってくれる機能なのだが、普通に設定すると結構煩雑でちょっと面倒臭い。

Amazon Web Service (以下AWS) で、提供している RDS というサービスで、MySQL を利用することができる。このサービスではリードレプリカも簡単に設定できるようになっている。
以下のようにメニューから選んで、必要項目を入力するだけでとっても簡単。



リードレプリカをたくさん作る

たくさんの参照があって書き込みが少ないデータベース、例えば Word Press のバックエンド等ではたくさん、リードレプリカを作って負荷分散することが効果的なケースがある。

このとき RDS を利用すると簡単にたくさんのリードレプリカを作成できて、非常に便利。だがいくつか制限がある。

一つのマスターに対して作成できるリードレプリカは5つまで

一つのマスターに対して作成できるリードレプリカは5つまで。この制限を超えると以下のようなエラーが出力される。

極端にリードレプリカをたくさん増やしても、マスターへのレプリケーションの負荷が増加するので、この制限もまぁ妥当なものだろう。

リードレプリカのリードレプリカ

ではもっとたくさん作りたい場合はどうすればいいかのか。答えはリードレプリカのリードレプリカを作成すればいい。

Automated Backups を Enabled にする

ただその場合、リードレプリカ側で Automated Backups が Enabled になっていなければいけない。


デフォルトでは Enabled になっていないので以下のようにレプリカを選択して右クリックから、 "modify" を選択して、"Backup Retention Period" を 1 以上に設定する。
これをしないとそもそも "Create Read Replica" をメニューから選択することもできない。


このときに "Apply Immediately" にチェックを入れておかないと次回のメンテナンスウィンドウか、手動で再起動されるまで、設定が反映されないので忘れずに。上の例では、ドロップダウンメニューの後ろに隠れている。

リードレプリカのリードレプリカは2段まで

ただし、リードレプリカは2段までしかできない。つまりリードレプリカのリードレプリカは作れるけれど、リードレプリカのリードレプリカのリードレプリカは作れない。作成しようとすると、以下のようなエラーが出力される。あんまり段数を増やしても今度はレプリケーションの遅延が大きくなるので、この制限はまぁ妥当なものだろう。




リードレプリカは全部で30個

マスターに対してリードレプリカは5個さらに5個のリードレプリカに対して5個ずつリードレプリカができるので2段目は 5 × 5 で、25 個。一つのマスターに対して合わせて30個のリードレプリカが作成できる。
ただし 30 個まで作れるものの実際のレプリケーションの負荷もばかにならないので、よっぽど書き込みが少ない場合も除いて実際の参照用として利用できるのは2段目の25個だけだと思っていい。
また2段目まで書き込みが反映されるまでのレイテンシーも2倍以上になるので、この点も考慮する必要がある。

まとめ

RDSのリードレプリカを作成する際は以下の3つに注意する必要がある。
  1. 一つのマスターに対して5個まで。
  2. 多段レプリカは2段まで。
  3. Automated Backups を有効にする。

最後に

便利に見えるリードレプリカですが、コスト面や読み取り専用としてしか使えないなど不便なところもあるので、実際の運用としては先に以下の方法も検討した方がよい。
  • インスタンスのサイズ変更で対応できないか。
  • PIOPS を利用で改善できないか。
上記二つの方が、リードレプリカを作成するよりも簡単で効果が高い場合もあります。

2014年3月25日火曜日

AWS VPC で VPC 間接続がサポートされたので試してみた。

AWS で VPC間の接続(Peering) がサポートされたので試してみました。
現在同一リージョン内のみで接続可能です。

今回不幸にも Management Console の更新が出ていたにも関わらず、うっかり NO とか 押してしまったためにコマンドライン(ec2-apitool)で実行してみました。
aws cli は、git 版も含めて現在サポートされていないようです。

まずec2-apitoolを最新化します。現在 1.6.13.0 でピアリング関係のコマンドが追加されています。
以下はAWS LINUXで標準でインストール されているコマンドを置き換える例です。
$ wget http://s3.amazonaws.com/ec2-downloads/ec2-api-tools.zip
$ cd /opt/aws/apitools
$ sudo unzip ~/ec2-api-tools.zip
$ sudo mv ec2-api-tools-1.6.13.0 ec2-1.6.13.0
$ sudo rm -f ec2
$ sudo ln -s ec2-1.6.13.0 ec2
$ cd ec2/bin
$ sudo rm -f *.cmd
$ cd /opt/aws/bin
$sudo find /opt/aws/apitools/ec2-1.6.13.0/ -iname "ec2-*" -exec ln -f -s {} . \;
VPC はマネージメントコンソールで適当に作成しておきます。 今回は異なるアカウント間で試してみました。
ピアリングのリクエストは以下のコマンドラインで設定します。 $ ec2-create-vpc-peering-connection --region us-west-2 -c vpc-526xxxxx -p vpc-576bxxxx -o 1xxxxxxxxxx0
VPCPEERINGCONNECTION pcx-e96xxxxx Tue Apr 01 11:42:46 UTC 2014 initiating-request: Initiating Request to 1xxxxxxxxxx0
REQUESTERVPCINFO vpc-526xxxxx 10.1.0.0/16 4xxxxxxxxxx6
ACCEPTERVPCINFO vpc-576bxxxx 1xxxxxxxxxx0
ec2-create-vpc-peering-connection
  • --region : リージョンを指定します。今回はoregon を使用しました。
  • -c : 接続元のvpc-id を指定します。
  • -r : 接続先のvpc-id を指定します。
  • -o : 接続先のアカウントIDを指定します。

VPC ピアリングコネクション ID ( pcx-e96xxxxx ) を控えて、接続先に連絡します。
ピアリングリクエストをアクセプトするためには、接続先のアカウントで以下の コマンドを実行します。 $ ec2-accept-vpc-peering-connection --region us-west-2 pcx-e96xxxxx
VPCPEERINGCONNECTION pcx-e96xxxxx provisioning: Provisioning
REQUESTERVPCINFO vpc-526xxxxx 10.1.0.0/16 4xxxxxxxxxx6
ACCEPTERVPCINFO vpc-576bxxxx 10.0.0.0/16 1xxxxxxxxxx0
ec2-create-vpc-peering-connection
  • --region : リージョンを指定します。
  • pcx-e96xxxxx : 先ほど控えた VPC ピアリングコネクション ID
さらに接続元、接続先でルーティングテーブルにエントリを追加します。
[接続元]
$ec2-create-route --region us-west-2 rtb-e67xxxxx -r 10.1.0.0/16 -p pcx-e96xxxxx
ROUTE 10.0.0.0/16 pcx-e96xxxxx
[接続先]
$ec2-create-route --region us-west-2 rtb-187xxxxx -r 10.1.0.0/16 -p pcx-e96xxxxx
ROUTE 10.1.0.0/16 pcx-e96xxxxx
ec2-create-vpc-peering-connection
  • --region : リージョンを指定します。
  • -r : 相手ネットワーク の CIDRブロックを指定します。 VPC 全体でも、サブネットでもかまいません。
  • -p : VPC ピアリングコネクション ID を指定します。
両方合わせてわずか、4コマンドで接続できました。詳細は現在英語版だけですが、マニュアルを参照してください。

2014年3月3日月曜日

電力効率がいいワークキューって?

 Linux Foundation の LTSI(Long Term Support Initiative) v3.10 公開 という記事のなかで、 "電力効率のよい workqueue" という機能がマージされたとのこと。
なぜ workqueue の変更で電力効率が変わるんだ? ということで調べたメモ。
※K.T. さん情報提供ありがとうございます。

workqueue

workqueue というのは、簡単にいうとLinux カーネルのなかで処理を遅延させる 仕組みのこと。
LINUX kernelに限らず、現代のOSは機能が豊富でたくさんの仕事をしなければいけない。

一方でOSは通常のプロセスとは違い特権モードで動作しているので、 あんまりお仕事をしすぎるとユーザープロセスの動作が遅れてしまう。

本来OSの利用者は、自分のプロセスが高速に動作することを期待しているので、 OSがお仕事しすぎてユーザープロセスが遅れては本末転倒である。

そこでOSのお仕事のうち、待ちが発生するものや、今すぐにやらなくてもいいこと を順番待ちに登録(queueing)して、後から適切な時に実行するのが workqueue という仕組み。

なんで仕事の順番を替えるだけで、電力消費が減るんだろう?というのが今回の 疑問。その前に少しだけ、MPUのお話。

big.LITTLE処理

最近のARMプロセッサでは「big.LITTLE処理」という機能が搭載されている。 これは簡単に言うと、高速で消費電力が大きい(big)プロセッサ(ARM Cortex™-A15プロセッサ) と、低速で消費電力が小さい(LITTLE)プロセッサ(Cortex™-A7)を両方搭載して、 処理の内容や、タイミングなどによって使い分けようという考え方。

電力効率のよい workqueue

この"big.LITTLE処理" を workqueue に適用して、できるだけLITTLE側に処理を 振ることで電力効率を改善するというのが今回マージされた機能ということに なる。わかってみればそれほど難しい話ではない。

一般のスケジューラでは?

処理をできるだけ LITTLE 側に振るだけで、電力消費が減るならば一般のプロセス スケジューラでも適用できるのでは?と思ってちょっと調べてみた。
現在、IKS と呼ばれる方式と、GTS(big.LITTLE MP)と呼ばれる2つの方式が 提案されているようだ。IKS は cpufreq という電力管理の延長線上で big と LITTLE の切り替えを行う方式。

GTS は、スケジューラ(sched) に変更を加えてbig と LITTLEにプロセスを 割り当てる方式。

さすがに sched に手を入れた場合は影響範囲が大きいのでメインストリーム には取り込まれておらず、特定の機器で取り込まれている模様。

SMP でない環境でのスケジューリングはいろいろ議論があって面白そう。

参考

workqueue については例えば、以下のIBM developerWorks の記事などを参照
「カーネル API: 第 2 回、遅延可能な関数、カーネルのタスクレット、およびワークキュー」
http://www.ibm.com/developerworks/jp/linux/library/l-tasklets/

big.LITTLE処理
http://www.arm.com/ja/products/processors/technologies/biglittleprocessing.php

後藤弘茂のWeekly海外ニュース
「 2014年のARMのSoCの中核技術となる「big.LITTLE MP」」
http://pc.watch.impress.co.jp/docs/column/kaigai/20131220_628480.html

Linaro Blog 「big.LITTLE Software Update」
http://www.linaro.org/linaro-blog/2013/07/10/big-little-software-update/

LWN.net「 Queue work on power efficient wq 」
http://lwn.net/Articles/548281/

2014年2月27日木曜日

/proc/diskstats のメモ

こんな簡単なメモでも誰かの役に立つかもしれない
RHEL 6 kernel-2.6.32-431.5.1.el6.src.rpm から。
Field No.変数簡単な説明タイプ単位関数
1MAJOR(part_devt(hd))メジャー番号
2MINOR(part_devt(hd)マイナー番号
3disk_name(gp, hd->partno, buf)ディスク名
4ios[0]完了済み読み込みIO数カウンターblk_account_io_done
5merges[0]マージ済み読み込みIO数カウンターdrive_stat_acct
6sectors[0]完了済み読み込みセクター数カウンターblk_account_io_completion
7ticks[0]読み込みで使用された秒数カウンターミリ秒blk_account_io_done
8ios[1]完了済み書き込みIO数カウンターblk_account_io_done
9merges[1]マージ済み書き込みIO数カウンターdrive_stat_acct
10sectors[1]完了済み書き込みセクター数カウンターblk_account_io_completion
11ticks[1])書き込みで使用された秒数カウンターミリ秒blk_account_io_done
12part_in_flight(hd)実行中のIO数ゲージdrive_stat_acct,blk_account_io_done
13io_ticksIOにかかった時間カウンターミリ秒drive_stat_acct
14time_in_queueキューにIOがあった合計時間 (in_flight x io_ticks の合計)カウンターミリ秒drive_stat_acct
blk_finish_request
->blk_account_io_done
─────────────────────
2003  unsigned long duration = jiffies - req->start_time;
2011  part_stat_inc(cpu, part, ios[rw]);
2012  part_stat_add(cpu, part, ticks[rw], duration);
2013  part_round_stats(cpu, part);
2014  part_dec_in_flight(part, rw);
2015
─────────────────────

blk_update_request
->blk_account_io_completion
──────────────────────────
1981static void blk_account_io_completion(struct request *req, unsigned int bytes)
1982{
1983 if (blk_do_io_stat(req)) {
1984  const int rw = rq_data_dir(req);
1985  struct hd_struct *part;
1986  int cpu;
1987
1988  cpu = part_stat_lock();
1989  part = disk_map_sector_rcu(req->rq_disk, blk_rq_pos(req));
1990  part_stat_add(cpu, part, sectors[rw], bytes >> 9);
1991  part_stat_unlock();
1992 }
1993}
──────────────────────────

blk_insert_request
blk_queue_bio
blk_insert_cloned_request
->drive_stat_acct
──────────────────────────
1199static void part_round_stats_single(int cpu, struct hd_struct *part,
1200        unsigned long now)
1201{
1202 if (now == part->stamp)
1203  return;
1204
1205 if (part_in_flight(part)) {
1206  __part_stat_add(cpu, part, time_in_queue,
1207    part_in_flight(part) * (now - part->stamp));
1208  __part_stat_add(cpu, part, io_ticks, (now - part->stamp));
1209 }
1210 part->stamp = now;
1211}
──────────────────────────

2014年2月12日水曜日

ZFS on AWS LINUX (2) ファイルシステムの作成

前回でモジュールの導入が完了したので、今回はファイルシステムを作成します。 今回のエントリの作成に当たっては以下の文書を参考にしています。 https://pthree.org/2012/12/05/zfs-administration-part-ii-raidz/
マネージメントコンソールとコンソールを行ったり来たりするのは面倒なので、 可能な限りコンソールコマンドだけで処理しようと思います。
今回せっかくなので RAID z3 ボリュームを作成してみようと思います。 RAID z3 はトリプルパリティーを持つ非常に頑丈なファイルシステムで、 最低5台の HDD を必要とします。

事前準備

マネジメントコンソールにてIAMユーザーを作成ます。
作成時に出力されるアクセスキーとシークレットキーを取得して、 aws cli に登録します。
自分で .aws/config ファイルを編集してもいいですが、 "aws configure" コマンドが便利です。
[ec2-user@ip-10-160-162-8 ~]$ aws configure
AWS Access Key ID [None]: AKIxxxxxxxxxxxxxxxxx
AWS Secret Access Key [None]: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Default region name [None]: ap-northeast-1
Default output format [None]:
※ IAM ロールを指定してもいいですが、つけ忘れたのでwww

EBSボリュームの作成

"aws ec2 create-volume" コマンドで、EBSボリュームを作成します。 今回は、RAID Z3 ボリュームを作成するので、5つの EBS ボリュームを確保する必要があります。 同じ要領でコマンドを5回繰替えしてください。
コマンド実行時に出力される項目のうち "VolumeId" は控えておいてください。
以下の出力例では、"vol-5b4bb851" となります。
今回指定した "aws ec2 create-volume" コマンドのオプションの意味は以下の通りです。
  • "--availability-zone"
    アタッチするインスタンスと同じ、AZを指定してください。
  • "--size"
    GB 単位で必要なサイズを指定してください。
[ec2-user@ip-10-160-162-8 ~]$ aws ec2 create-volume --availability-zone ap-northeast-1a --size 10
{
"AvailabilityZone": "ap-northeast-1a",
"Attachments": [],
"Tags": [],
"VolumeType": "standard",
"VolumeId": "vol-5b4bb851",
"State": "creating",
"SnapshotId": null,
"CreateTime": "2014-02-06T07:21:27.214Z",
"Size": 10
}
続いて、"aws ec2 describe-volumes" で作成したボリュームのステータスが "available" になっていることを確認してください。
[ec2-user@ip-10-160-162-8 ~]$ aws ec2 describe-volumes
{
"Volumes": [
...............(snip)...............
{
"AvailabilityZone": "ap-northeast-1a",
"Attachments": [],
"VolumeType": "standard",
"VolumeId": "vol-5b4bb851",
"State": "available",★ここ
"SnapshotId": null,
"CreateTime": "2014-02-06T07:21:27.214Z",
"Size": 10
}
...............(snip)...............
]
}

EBSボリュームのアタッチ

インスタンスにアタッチする際にインスタンスid が必要となりますが、 不明な場合(控え忘れたともいう)はインスタンスメタデータを参照することで確認できます。
コマンドラインは以下の通りです。
[ec2-user@ip-10-160-162-8 ~]$ GET http://169.254.169.254/latest/meta-data/instance-id
i-27cc6720 ★
"aws ec2 attach-volume" コマンドを利用して EBS ボリュームをインスタンスにアタッチします。
作成した5つのEBSボリュームに対して実行してください。
今回使用した "aws ec2 attach-volume" コマンドのオプションは以下の通りです。
  • "--instance-id"
    EBSボリュームが アタッチされるインスタンスのIDです。先ほど取得した値を指定してください。
  • "--volume-id"
    アタッチするボリュームのIDです。ボリューム作成時に控えた値を指定してください。
  • "--device"
    アタッチするデバイス名です。AWS EC2 上のEBSでは、sdfからsdpを指定することが推奨されています。
    今回はsdf,sdg,sdh,sdi,sdj の5つのデバイスとして接続しました。
[ec2-user@ip-10-160-162-8 ~]$ aws ec2 attach-volume --instance-id i-27cc6720 --volume-id vol-5b4bb851 --device sdf { "AttachTime": "2014-02-06T07:31:01.035Z", "InstanceId": "i-27cc6720", "VolumeId": "vol-5b4bb851", "State": "attaching", "Device": "sdf" }
EBSボリュームのアタッチに成功すると、以下のようなログがシスログ(/var/log/messages)に出力されます。
Feb 6 07:31:04 ip-10-160-162-8 kernel: [ 1570.630510] blkfront: xvdf: barrier or flush: disabled; persistent grants: disabled; indirect descriptors: disabled;
Feb 6 07:31:04 ip-10-160-162-8 kernel: [ 1570.653521] xvdf: unknown partition table
※デバイス名がxvdf に変わってしまうことに注意してください。

ZFSボリュームの作成

ここまで、EBS作成とアタッチの手順だけですねwww。本命のzfs ボリュームの作成です。
zpool コマンドを利用して、ボリューム(正確にはストレージプール)を作成します。
以下の例では、"zpool create" コマンドで "tank" という名前のストレージプールを raidz3 で作成し、ディスク xvdf,xvdg,xvdh,xvdi,xvdj(sdf,sdg,sdh,sdi,sdj) を登録しています。
[ec2-user@ip-10-160-162-8 ~]$ sudo zpool create tank raidz3 xvd{f..j}
確認は、"zpool status" コマンド実施します。
[ec2-user@ip-10-160-162-8 ~]$ sudo zpool status tank
pool: tank
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz3-0 ONLINE 0 0 0
xvdf ONLINE 0 0 0
xvdg ONLINE 0 0 0
xvdh ONLINE 0 0 0
xvdi ONLINE 0 0 0
xvdj ONLINE 0 0 0

errors: No known data errors
この状態で、"/tank" に zfs ボリュームがマウントされています。 このほかのzfsの便利機能は、また改めて。

補足

以下のようなエラーがでてコマンドが失敗する場合があります。
[ec2-user@ip-10-160-162-8 ~]$ sudo zpool create tank raidze xvd{f..j}
Failed to load ZFS module stack.
Load the module manually by running 'insmod /zfs.ko' as root.
Failed to load ZFS module stack.
上記のエラーが出力された場合 dkms によるモジュール作成が失敗している場合があります。
モジュール作成が失敗する原因としては、"kernel-devel" および "kernel-headers" パッケージと "kernel" パッケージとの間でバージョンが一致していないことが考えられます。
バージョン不一致の原因は、yum で導入した場合に、"kernel-devel" および "kernel-headers"の 最新版が導入され、"kernel" パッケージがアップデートされていないことに起因します。
確認方法は "rpm" コマンドを例えば以下のように実行して、"kernel-devel" および "kernel-headers"と "kernel" パッケージのバージョンを確認してください。
[ec2-user@ip-10-160-162-8 ~]$ rpm -qa | grep kernel kernel-devel-3.4.76-65.111.amzn1.x86_64 kernel-headers-3.4.76-65.111.amzn1.x86_64 kernel-3.4.73-64.112.amzn1.x86_64
上記実行例では、"kernel" パッケージのバージョン は "3.4.73-64.112"で、"kernel-devel" および "kernel-headers" のパッケージバージョンは "3.4.76-65.111" なので、dkms によるパッケージ作成が失敗します。。 素直に"yum update" して、再起動で対処できます。
なお、dkms を利用している場合は、kernel アップデート後最初の一回目の再起動で、モジュールの再コンパイルが必要となるため起動に通常時よりも多くの時間がかかります。