電子の密林を開拓する

タグ:EBS

今回は CloudWatch というか、mon-*系の監視コマンドを使ってみます。



・タグからEC2インスタンスを探す
MasterController という名前の AmazonLinux な EC2 で CloudWatch を試してみます。
MasterController というNameタグを持つインスタンスを探して、そのInstance-ID を入手します。
$ ec2-describe-instances \
     | grep -e '^TAG' \
     | grep 'MasterController' \
     | cut --fields=3
i-0f1b440c
あるいは --filter オプションを使用して以下のようにもできます。
$ ec2-describe-instances \
     --filter 'tag:Name=MasterController' \
   | grep '^INSTANCE' \
   | cut --fields=2
i-0f1b440c
書く手間は、あまり変わりませんね…。
いずれにせよ、コマンドじゃなくてAPIで探した方が良いような気がするけど…。とりあえず、今はコレでガマンしておきます。



・EC2インスタンス用のメトリックス
次に、mon-list-metrics を使って、先に入手した Instance-ID に紐づく Metrics のリストを
入手します。
⇒ mon-list-metrics コマンドだけを使っても一覧を入手できますが、既に削除済みのインスタンスに対するmetricsも表示されたりしてメンドクサイので、Instence-ID で検索したいのです。
$ mon-list-metrics \
     | egrep 'i-0f1b440c' \
     | grep -v '^"'
CPUUtilization                 AWS/EC2  {InstanceId=i-0f1b440c}
DiskReadBytes                  AWS/EC2  {InstanceId=i-0f1b440c}
DiskReadOps                    AWS/EC2  {InstanceId=i-0f1b440c}
DiskWriteBytes                 AWS/EC2  {InstanceId=i-0f1b440c}
DiskWriteOps                   AWS/EC2  {InstanceId=i-0f1b440c}
NetworkIn                      AWS/EC2  {InstanceId=i-0f1b440c}
NetworkOut                     AWS/EC2  {InstanceId=i-0f1b440c}
StatusCheckFailed              AWS/EC2  {InstanceId=i-0f1b440c}
StatusCheckFailed_Instance AWS/EC2  {InstanceId=i-0f1b440c}
StatusCheckFailed_System       AWS/EC2  {InstanceId=i-0f1b440c}

MasterController というタグが付けられたEC2インスタンスには、これだけのMetricsがあるらしいです。

しかし、もっとカンタンな方法を発見。

$ mon-list-metrics \
--dimensions "InstanceId=i-0f1b440c" \
     | egrep -v '^"'

CPUUtilization                 AWS/EC2  {InstanceId=i-0f1b440c}
DiskReadBytes                  AWS/EC2  {InstanceId=i-0f1b440c}
DiskReadOps                    AWS/EC2  {InstanceId=i-0f1b440c}
DiskWriteBytes                 AWS/EC2  {InstanceId=i-0f1b440c}
DiskWriteOps                   AWS/EC2  {InstanceId=i-0f1b440c}
NetworkIn                      AWS/EC2  {InstanceId=i-0f1b440c}
NetworkOut                     AWS/EC2  {InstanceId=i-0f1b440c}
StatusCheckFailed              AWS/EC2  {InstanceId=i-0f1b440c}
StatusCheckFailed_Instance AWS/EC2  {InstanceId=i-0f1b440c}
StatusCheckFailed_System AWS/EC2  {InstanceId=i-0f1b440c}
--dimensions オプションを使えば、簡単に Instance-ID で絞り込みできました!

で、肝心の Metrics そのものですが……。
MasterController は AmazonLinux なマイクロインスタンスなので、ローカルディスクは使用していないです(マイクロインスタンスではEBSが使用される)。つまり、Disk* 系の Metrics には あまり意味が無いというコトですね。


・EC2インスタンスの監視結果を得る
Metrics の一覧が手に入ったので、次は mon-get-stats コマンドで CloudWatch から監視結果の値を入手します。指定するパラメータは以下のようにします。
Metric     = CPUUtilization 
Statistics = Average
NameSpace = AWS/EC2
mon-get-stats --help で確認すると、Statistics には「Average, Sum, SampleCount, Maximum, Minimum」のいずれかが指定できるようです。
$ mon-get-stats \
     CPUUtilization \
     --statistics Average \
     --namespace AWS/EC2
あれ??? パラメータは足りているはずなのに、何も表示されませんね???
(このコマンド指定で何かが表示される場合もありますが、今回は表示されませんでした…。結果が表示されたり、されなかったりする理由は不明。)

気を取り直して、先ほど mon-list-metrics で指定した dimensions を設定してみます。
$ mon-get-stats \
     CPUUtilization \
     --statistics Average \
     --namespace AWS/EC2 \
     --dimensions "InstanceId=i-0f1b440c"

2013-02-17 17:13:00  23.830000000000002   Percent
2013-02-17 17:18:00  0.33399999999999996  Percent
2013-02-17 17:23:00  26.666000000000004   Percent
2013-02-17 17:28:00  0.0                  Percent
2013-02-17 17:33:00  0.0                  Percent
2013-02-17 17:38:00  1.6440000000000001   Percent
2013-02-17 17:43:00  47.18                Percent
2013-02-17 17:48:00  9.622                Percent
2013-02-17 17:53:00  18.887999999999998   Percent
2013-02-17 17:58:00  35.922000000000004   Percent
2013-02-17 18:03:00  12.334               Percent
--dimensions オプションに Instance-ID を指定したら 結果が表示されるようになりましたね。Dimensions は必須オプションではないのに……指定が必要な理由が分からないです。

他の値、ヘルスチェックの結果も見てみましょう。
$ mon-get-stats \
     StatusCheckFailed \
     --statistics Sum \
     --namespace AWS/EC2 \
     --dimensions "InstanceId=i-0f1b440c"

2013-02-17 18:25:00  0.0  Count
2013-02-17 18:30:00  0.0  Count
2013-02-17 18:35:00  0.0  Count
2013-02-17 18:40:00  0.0  Count
2013-02-17 18:45:00  0.0  Count
2013-02-17 18:50:00  0.0  Count
2013-02-17 18:55:00  0.0  Count
2013-02-17 19:00:00  0.0  Count
2013-02-17 19:05:00  0.0  Count
2013-02-17 19:10:00  0.0  Count
2013-02-17 19:15:00  0.0  Count
2013-02-17 19:20:00  0.0  Count
特にヘルスチェックに失敗するような処理もさせていないので、カウントはゼロになっていますね。



・EBSの Volume-ID を得る
MasterController(i-0f1b440c)にアタッチされた EBS の状態を確認してみましょう。
ec2-describe-volumes に --filter オプションを使って、EBS のボリュームIDを探してみます。
$ ec2-describe-volumes \
     --filter 'attachment.instance-id=i-0f1b440c' \
   | grep '^VOLUME' \
   | cut --fields=2


vol-6057ec42



・EBSに対するメトリックスを得る
では、EBS Volume(vol-6057ec42) に対する Metrics のリストを確認します。
$ mon-list-metrics \
     --namespace AWS/EBS \
     --dimensions='VolumeId=vol-6057ec42' \
   | grep -v '^"'
VolumeIdleTime           AWS/EBS  {VolumeId=vol-6057ec42}
VolumeQueueLength        AWS/EBS  {VolumeId=vol-6057ec42}
VolumeReadBytes          AWS/EBS  {VolumeId=vol-6057ec42}
VolumeReadOps            AWS/EBS  {VolumeId=vol-6057ec42}
VolumeTotalReadTime      AWS/EBS  {VolumeId=vol-6057ec42}
VolumeTotalWriteTime AWS/EBS  {VolumeId=vol-6057ec42}
VolumeWriteBytes         AWS/EBS  {VolumeId=vol-6057ec42}
VolumeWriteOps AWS/EBS  {VolumeId=vol-6057ec42}
AWS Management Console でも見たことがあるような監視項目が表示されています。




・EBSの監視結果を得る
まずは、VolumeQueueLength を見てみます。
$ mon-get-stats \
     VolumeQueueLength \
     --statistics Maximum \
     --namespace AWS/EBS \
     --dimensions "VolumeId=vol-6057ec42"
2013-02-17 19:01:00  3.06666666666667E-4  Count
2013-02-17 19:06:00  9.73333333333333E-4  Count
2013-02-17 19:11:00  2.4E-4               Count
2013-02-17 19:16:00  4.13333333333333E-4  Count
2013-02-17 19:21:00  2.13333333333333E-4  Count
2013-02-17 19:26:00  5.2E-4               Count
2013-02-17 19:31:00  2.66666666666667E-4  Count
2013-02-17 19:36:00  1.46666666666667E-4  Count
2013-02-17 19:41:00  1.46666666666667E-4  Count
2013-02-17 19:46:00  0.0                  Count
2013-02-17 19:51:00  0.0                  Count
2013-02-17 19:56:00  0.00133333333333333  Count
浮動小数点が E 表記になっているので、ものすごく見づらいです…。これをふつうの表記に変更する方法が分からない…。

VolumeQueueLength の意味は「The average number of read and write operations waiting to be completed during the period」(単位時間内に、READ/WRITE処理が待たされた回数の平均)ということらしいです。平均ってオカシイような気がするのですが…(単に「回数」じゃなくて??? ↑のコマンド実行結果にも Count [回数]って書いてあるし…)
あと、単位時間(the period)って どれぐらいなのでしょう? …と思いましたが、記録されている時間が 5分毎なので、恐らく 単位時間も5分なのでしょう。EC2の標準状態(無料)の監視間隔と同じですね。

他の値も見ておきます。
$ mon-get-stats \
     VolumeTotalWriteTime \
     --statistics Sum \
     --namespace AWS/EBS \
     --dimensions "VolumeId=vol-6057ec42"

2013-02-17 19:36:00  0.044  Seconds
2013-02-17 19:41:00  0.044  Seconds
2013-02-17 19:56:00  0.26   Seconds
2013-02-17 20:01:00  0.124  Seconds
2013-02-17 20:06:00  0.196  Seconds
2013-02-17 20:11:00  0.088  Seconds
2013-02-17 20:16:00  0.028  Seconds
2013-02-17 20:21:00  0.032  Seconds
2013-02-17 20:26:00  0.072  Seconds
VolumeTotalWriteTimeは「書き込みに処理かかった時間(=待たされた時間)」ということらしいです。これと VolumeTotalReadTime の値が高い値になったら、EBSの処理が遅延しているということになりますね…たぶん。
⇒ 実際に負荷試験するなり、実運用しているEBSから値を取得するなりしないと、ホントのところは分かりませんが…。




・まとめ???
mon-* 系コマンド(というか CloudWatch)には、Namespace / Metrics / Statistics / Dimensions / Unit / Period という値が登場しますが…。ここまでコマンドを使ってみた結果、以下のような感じになっているものと思われます。


Namespaceデータ取得元の大雑把な分類 (AWS/EC2、AWS/EBS など)
Metricsデータの種類 (CPU使用率、失敗回数、遅延時間など)
Dimensionsデータ取得元の詳細な分類(Volume-ID、Instance-ID など)
Statisticsデータの統計方法(平均、合計、最大、最小、記録回数など)
Unit データの単位 (~秒、~バイト、~ビット、~パーセント、~回、~バイト/秒 など)
Periodデータを取得/統計する単位時間 (標準の無料利用状態だと5分単位)

標準で用意されたデータを参照して利用するだけでは、単なる簡単で便利な自動監視機構にしか見えませんが…。
カスタムメトリックス(mon-put-data とか?)とアラームを使いこなせれば、もっと高度に使えそうな気がします…。
⇒ そもそも AutoScaling の基礎になっているので、そのとおりなのですが…(^^;



今回はここまで……。

今回は コマンドライン(CUI)で、ELB(ロードバランサー)を設定してみます。

手順としては以下の通り。
  • WEB用のセキュリティグループを作成
  • テンプレートとなるWEBサーバを作成
  • WEBサーバの中身を設定
  • テンプレートWEBサーバからSnapshotを作成
  • SnapshotからAMI(AmazonMachineImage)を作成
  • 不要になった テンプレート用WEBサーバを削除
  • AMIから複数台のWEBサーバを作成
  • ELBを設定し、WEBサーバを配下に加える
  • AMIから複数台のWEBサーバを作成 
  • ELBを設定し、WEBサーバを配下に加える
  • ELBの動作確認
  • ELBの削除
  • 後始末
それではやってみましょう。

前準備の手順なんて見たくない人は テキトーに読み飛ばして、ELB関連のコマンド部分だけ確認ください。


 
・セキュリティグループを作る
WEBという名前のセキュリティグループを作成し、外部から port80とport22へのアクセスを許可します。既に、相当するセキュリティグループがある場合は、ソチラを利用してもらっても構いません。
$ ec2-add-group \
     web \
     --description 'web server'

GROUP   sg-33bace32     web     web server

$ ec2-authorize \
     web \
     --protocol tcp \
     --port-range 80-80 \
     --cidr '0.0.0.0/0'

GROUP                   web
PERMISSION              web     ALLOWS  tcp     80      80      FROM    CIDR    0.0.0.0/0     ingress

$ ec2-authorize \
     web \
     --protocol tcp \
     --port-range 22-22 \
     --cidr '0.0.0.0/0'

GROUP                   web
PERMISSION              web     ALLOWS  tcp     22      22      FROM    CIDR    0.0.0.0/0     ingress
port22 の設定の際 cidr 指定で「AWS内部からだけ」というのが設定出来ればよいのですが…。やり方が良く分かりません...。まぁ、そのように設定したとしても、他人が作成したAWSインスタンスからアクセスできてしまうわけですが…。


・テンプレートとなるEC2インスタンス作成
ここでは、 innerkey という鍵ペアが存在することを前提としています。もし存在しないようなら ec2-add-keypair コマンドで作成するか、別の鍵ペアを使用してください。

作成するEC2インスタンスは、ami-20ad1221 (UbuntuOS) で、32bit マイクロ としておきます。テンプレートはAMI作成後に すぐ破棄してしまうので、TerminationProtection は利用しません。
$ ec2-run-instances \
     ami-20ad1221 \
     --group web \
     --key innerkey \
     --instance-count 1 \
     --instance-type t1.micro \
     --availability-zone ap-northeast-1a \
     --instance-initiated-shutdown-behavior stop

RESERVATION     r-31e56b32      488224276535    web
INSTANCE        i-11b39412      ami-20ad1221                    pending innerkey        0             t1.micro        2013-02-07T12:20:40+0000        ap-northeast-1a aki-ec5df7ed                  monitoring-disabled                                     ebs                                   paravirtual     xen             sg-33bace32     default false

$ ec2-describe-instances i-11b39412
RESERVATION     r-31e56b32      488224276535    web
INSTANCE        i-11b39412      ami-20ad1221    ec2-46-51-232-99.ap-northeast-1.compute.amazonaws.com ip-10-132-100-230.ap-northeast-1.compute.internal       pending innerkey        0             t1.micro        2013-02-07T12:20:40+0000        ap-northeast-1a aki-ec5df7ed                  monitoring-disabled     46.51.232.99    10.132.100.230                  ebs                                   paravirtual     xen             sg-33bace32     default false
BLOCKDEVICE     /dev/sda1       vol-4245c660    2013-02-07T12:20:43.000Z        true

$ ec2-describe-instance-status i-11b39412
     ※未だec2-run-instancesによるECインスンタンス起動処理前なので、応答が無い

$ ec2-describe-instance-status i-11b39412
INSTANCE        i-11b39412      ap-northeast-1a running 16      initializing    initializing  active
SYSTEMSTATUS    reachability    initializing
INSTANCESTATUS  reachability    initializing

$ ec2-describe-instance-status i-11b39412
INSTANCE        i-11b39412      ap-northeast-1a running 16      ok      ok      active
SYSTEMSTATUS    reachability    passed
INSTANCESTATUS  reachability    passed


・WEBサーバの中身を設定
作成した Ubuntu な EC2インスタンスにssh接続します。
$ ssh \
     -i ~/.ssh/innerkey.pem \
     -l ubuntu \
     ec2-46-51-232-99.ap-northeast-1.compute.amazonaws.com

Ubuntu 側は「WEBサーバ」となるので、Apache2 + php5 をインストールします。念のため、最初に パッケージのアップデートも実施しておきます。
ubuntu$ sudo apt-get update
ubuntu$ sudo apt-get install apache2
ubuntu$ sudo apt-get install libapache2-mod-php5
設定出来たら、apacheが動作しているかどうか確認してみます。
ubuntu$ curl 'http://localhost/'
<html><body><h1>It works!</h1>
<p>This is the default web page for this server.</p>
<p>The web server software is running but no content has been added, yet.</p>
</body></html>
WEBサーバとしての動作が確認できたら、簡単なコンテンツプログラム(php)を配備します。/var/www/ec2meta.php に以下のようなファイルを作成します。vi で作成するなら、sudo vi /var/www/ec2meta.phpですね…。
<?php
  $url = 'http://169.254.169.254';
  $data = array(
      'pattern' => 'htmlspe',
      'show' => 'quickref',
  );
  $options = array(
    'http' => array( 'method' => 'POST', 'content' => http_build_query($data) )
  );

  $pathinfo = $_SERVER['PATH_INFO'];
  if (!empty($pathinfo)) { $url .= $pathinfo; }
 
  $contents = file_get_contents( $url, false, stream_context_create( $options ) );

  if ($contents !== FALSE) { echo $contents; }
  else                     { header( 'HTTP/1.0 502 http://169.254.169.254/ does not respond.' ); }

// END of PHP //
ファイルを配備したら、動作確認してみます。
ubuntu$ curl 'http://localhost/ec2meta.php' ; echo -en "\n"
1.0
2007-01-19
2007-03-01
2007-08-29
2007-10-10
2007-12-15
2008-02-01
2008-09-01
2009-04-04
2011-01-01
2011-05-01
2012-01-12
latest
日付が並んだ後に latest が表示されればOKです。

後で必要になるので、ここで kernel-d を取得しておきます。
$ curl 'http://localhost/ec2meta.php/latest/meta-data/kernel-id' ; echo -en "\n"
aki-ec5df7ed
AWSコマンドラインプログラムがインストールされているなら、curl コマンドを使わないで 「ec2-metadata --kernel-id」というコマンドを使ってもOKです。

最後に、Ubuntu 側から exit しておきます。
ubuntu$ exit
 
・テンプレートWEBサーバからSnapshotを作成
念のため、テンプレートWEBサーバであるEC2インスタンスを停止しておきます。
$ ec2-stop-instances i-11b39412
INSTANCE        i-11b39412      running stopping

$ ec2-describe-instance-status \
     --include-all-instances \
     i-11b39412

INSTANCE        i-11b39412      ap-northeast-1a stopped 80      not-applicable  not-applicable        active
EC2の停止を確認したら、EBSからスナップショットをとります。
$ ec2-create-snapshot \
     vol-4245c660 \
     --description 'template web Ubuntu'

SNAPSHOT        snap-c2a043e1   vol-4245c660    pending 2013-02-07T12:44:43+0000              488224276535    8       template web Ubuntu

$ ec2-describe-snapshots
SNAPSHOT        snap-c2a043e1   vol-4245c660    pending 2013-02-07T12:44:43+0000              488224276535    8       template web Ubuntu

$ ec2-describe-snapshots snap-c2a043e1
SNAPSHOT        snap-c2a043e1   vol-4245c660    completed       2013-02-07T12:44:43+0000      100%    488224276535    8       template web Ubuntu

$ ec2-describe-snapshots
SNAPSHOT        snap-c2a043e1   vol-4245c660    pending 2013-02-07T12:44:43+0000              488224276535    8       template web Ubuntu
パラメータ無しの ec2-describe-snapshots ダケだと pending のままですが、確認対象の snapshot-id を与えると、ちゃんと completed になります。不思議な挙動…。
ちなみに AWS Management Console だと Completed になってます……謎すぎる。
...
しばらく放置したら、ec2-describe-snapshots ダケでも completed になりました。何かキャッシュされているんでしょうかね???


・SnapshotからAMI(AmazonMachineImage)を作成
Snapshot から AMI を作成するには ec2-register コマンドを使用します。
$ ec2-register \
     --snapshot snap-c2a043e1 \
     --kernel aki-ec5df7ed \
     --name 'web_template' \
     --description 'web template Ubuntu'

IMAGE   ami-3d76f23c

$ ec2-describe-images
IMAGE   ami-3d76f23c    488224276535/web_template       488224276535    available       private               i386    machine aki-ec5df7ed                    ebs     paravirtual     xen
BLOCKDEVICEMAPPING      /dev/sda1               snap-c2a043e1   8       true    standard
AMI の出来上がり。



不要になった テンプレート用WEBサーバを削除
テンプレートWEBサーバは既にSTOPさせてあるので、TERMINATE させます。
$ ec2-terminate-instances  i-11b39412
INSTANCE        i-11b39412      stopped terminated
これで、テンプレートWEBのEC2インスタンスは削除されました。
EBS Volume も同時に消されているはずですが、もし残っていたら ec2-delete-volumes で削除しておいてください。



・AMIから複数台のWEBサーバを作成
作成済みの AMI (ami-c15fdbc0) を使って、EC2インスタンスを二つ起動します。
$ ec2-run-instances \
     ami-3d76f23c  \
     --group web \
     --key innerkey \
     --instance-count 2 \
     --instance-type t1.micro \
     --availability-zone ap-northeast-1a \
     --instance-initiated-shutdown-behavior stop


RESERVATION     r-8bee6788      488224276535    web
INSTANCE        i-437a5b40      ami-3d76f23c                    pending innerkey        0             t1.micro        2013-02-08T10:29:33+0000        ap-northeast-1a aki-ec5df7ed                  monitoring-disabled                                     ebs                                   paravirtual     xen             sg-33bace32     default false
INSTANCE        i-417a5b42      ami-3d76f23c                    pending innerkey        1             t1.micro        2013-02-08T10:29:33+0000        ap-northeast-1a aki-ec5df7ed                  monitoring-disabled                                     ebs                                   paravirtual     xen             sg-33bace32     default false
実行開始コマンド入力した後、ec2-describe-instance-status で状況を確認します。
$ ec2-describe-instance-status i-437a5b40 i-417a5b42
INSTANCE        i-437a5b40      ap-northeast-1a running 16      ok      ok      active
SYSTEMSTATUS    reachability    passed
INSTANCESTATUS  reachability    passed
INSTANCE        i-417a5b42      ap-northeast-1a running 16      ok      ok      active
SYSTEMSTATUS    reachability    passed
INSTANCESTATUS  reachability    passed
kernel-id の指定が間違っていたり(あるいは指定忘れていたり)すると、status が impaired (傷んでる/壊れている...ぐらいの意味)になったり、passed にならないコトがあります。その場合は コマンドヒストリを見返す等して、再確認してみてください。



・ELBを設定し、WEBサーバを配下に加える
ELB(ロードバランサー)を作成するのは elb-create-lb というコマンドを使用します。

ちなみに、elb-* 系コマンドは 以前設定した環境変数の EC2_URL を参照してくれないので、コマンドラインで指定する必要があります。環境変数で指定したい場合は EC2_REGION 環境変数を設定しておいてください。

ここでは httpbalancer という名前の ELB を作成します。
$ elb-create-lb \
     httpbalancer \
     --scheme internet-facing \
     --region ap-northeast-1 \
     --availability-zones ap-northeast-1a \
     --listener 'protocol=HTTP, lb-port=80, instance-port=80'


DNS_NAME  httpbalancer-1887544794.ap-northeast-1.elb.amazonaws.com
(EC2_URL環境変数に頼っているつもりで) --region オプションを指定しないと、謎のエラーに悩まされるか、あるいは意図しない region にロードバランサーが作成されるので注意してください。

 次にELBのヘルスチェック(死活監視)を設定します。
$ elb-configure-healthcheck \
     httpbalancer \
     --region ap-northeast-1 \
     --target 'http:80/' \
     --interval 30 \
     --timeout 5 \
     --healthy-threshold 4 \
     --unhealthy-threshold 2

HEALTH_CHECK  http:80/  30  5  4  2
チェック間隔は30秒、2回チェック失敗でunhealthy扱い、4回チェック成功でhealthyに戻す…という設定にします。

ELBの配下に、先に用意した二台のWEBサーバ(EC2インスタンス)を加えます。
$ elb-register-instances-with-lb \
     httpbalancer \
     --region ap-northeast-1 \
     --instances  i-437a5b40,i-417a5b42

INSTANCE_ID  i-417a5b42
INSTANCE_ID  i-437a5b40
--instances オプションに与える instance-id は(コマンの前後にも)空白を含めたりせず 繋げて指定してください。そうしないと謎のエラーに悩まされます…(x_x;

次に作成されたロードバランサーの状態を確認してみます。
$ elb-describe-lbs --region ap-northeast-1

LOAD_BALANCER  httpbalancer  httpbalancer-1887544794.ap-northeast-1.elb.amazonaws.com  2013-02-08T11:07:45.180Z  internet-facing
すごく普通…。

そして、ロードバランサーの配下に組み込まれたWEBサーバの状態(と言うか、ロードバランサーがWEBサーバを死活確認しているのでその結果)を表示してみます。

$ elb-describe-instance-health \
     httpbalancer \
     --region ap-northeast-1

INSTANCE_ID  i-417a5b42  OutOfService  Instance registration is still in progress.  ELB
INSTANCE_ID  i-437a5b40  OutOfService  Instance registration is still in progress.  ELB

※↑ELB配下へEC2を登録している最中...という意味


$ elb-describe-instance-health \
     httpbalancer \
     --region ap-northeast-1

INSTANCE_ID  i-417a5b42  InService  N/A  N/A
INSTANCE_ID  i-437a5b40  InService  N/A  N/A

※↑ EC2のinstance-id を指定しないせず、配下のEC2インスタンスを全表示した結果。

$ elb-describe-instance-health \
     httpbalancer \
     --region ap-northeast-1 \
     --instances i-437a5b40,i-417a5b42
INSTANCE_ID  i-437a5b40  InService  N/A  N/A
INSTANCE_ID  i-417a5b42  InService  N/A  N/A

※↑ EC2のinstance-id を指定して、2つだけ表示した結果。
二つ並んだ N/A が何を意味しているのか分かりませんが、とりあえず InService なので問題ないのでしょう。



ELBの動作確認
curlコマンドを使って、ロードバランサー経由で配下のWEBサーバにアクセスしてみます。
ロードバランサーのFQDNは elb-describe-lbs コマンドで入手したものを使用します。
$ for R in $(seq 1 10) ; do \
     curl 'http://httpbalancer-1887544794.ap-northeast-1.elb.amazonaws.com/ec2meta.php/latest/meta-data/instance-id/'; \
     echo -en "\n" ; \
     done

i-437a5b40
i-417a5b42
.....
i-437a5b40
i-417a5b42
交互にアクセスが分散されていますね…。

もし、アクセスが届かない場合、FQDNの先頭に ipv6. とか dualstack. とかを付けてみると良いかもしれません。前者は IPv6 のホスト名で、後者は IPv4,IPv6共用らしいです。

これで動作確認は終わり!!! (動いてることを確認しただけですが ^^;)



ELBの削除
作成したのとは逆の手順でロードバランサーを破棄します。
まず最初にロードバランサー配下からEC2インスタンスを排除し、その後、ロードバランサーであるELBを消去します。

ELBの配下からEC2を排除するには elb-deregister-instances-from-lb コマンドを使用します。とりあえず、ECを1台だけ排除してみます。
$ elb-deregister-instances-from-lb \
     httpbalancer \
     --region ap-northeast-1 \
     --instances  i-437a5b40

INSTANCE_ID  i-417a5b42

$ elb-describe-instance-health \
     httpbalancer \
     --region ap-northeast-1 \
     --instances i-437a5b40,i-417a5b42

INSTANCE_ID  i-437a5b40  OutOfService  Instance is not currently registered with the LoadBalancer.  Instance
INSTANCE_ID  i-417a5b42  InService     N/A
指定したEC2(i-437a5b40)が排除されましたね…。残ったEC2も含めて排除してしまいましょう。
$ elb-deregister-instances-from-lb \
     httpbalancer \
     --region ap-northeast-1 \
     --instances  i-437a5b40,i-417a5b42

No instances currently registered to LoadBalancer


$ elb-describe-instance-health \
     httpbalancer \
     --region ap-northeast-1 \
     --instances i-437a5b40,i-417a5b42

INSTANCE_ID  i-437a5b40  OutOfService  Instance is not currently registered with the LoadBalancer.  Instance
INSTANCE_ID  i-417a5b42  OutOfService  Instance is not currently registered with the LoadBalancer.  Instance


$ elb-describe-instance-health \
     httpbalancer \
     --region ap-northeast-1
No instances currently registered to LoadBalancer

これで、ELBからEC2インスタンスがすべて排除されました。

最後に、ELB本体を削除します。
$ elb-delete-lb \
     httpbalancer \
     --region ap-northeast-1

Warning: Deleting a LoadBalancer can lead to service disruption to any
customers connected to the LoadBalancer. Are you sure you want to delete
this LoadBalancer? [Ny] y
OK-Deleting LoadBalancer

$ elb-describe-lbs --region  ap-northeast-1
elb-delete-lb  コマンドを使用すると、プロンプトが出て y か N で回答を求められます。y で削除できますが、めんどくさければ --force オプションで強制消去することもできます。

最後の elb-describe-lbs コマンドに対して、何も結果が表示されないので、ELBは消えたということになります。

これで、ELBの消去作業は終了。



後始末
不要になった AMI、Snapshot、EC2インスタンスを削除しておいてください。

AMI削除はec2-deregister、Snapshot削除は ec2-delete-snapshots、EC2インスタンス削除は ec2-stop-instances、ec2-terminate-instances です。

EC2のTerminationProtectionを使用しているなら「ec2-modify-instance-attribute INSTANCE_ID --disable-api-termination false 」で解除できます。


今回はここまで。

続きを読む

前回は、EBS からバックアップした EBS Snapshot を使って AMI を作成しました。
今回は、AMI ではなく、直接 EBS Volume を作成し、EC2インスタンスにマウントしてみます。


・コピー元となるEBSを持つEC2インスタンスの確認
まず、コピー元となる EC2インスタンスの instance-id を取得します。
$ curl 'http://169.254.169.254/latest/meta-data/instance-id'; echo -en "\n"
i-3b0b4738

$ ec2-describe-instances i-3b0b4738
RESERVATION     r-83af1c80      354893364746    web
INSTANCE        i-3b0b4738      ami-486cd349    ec2-54-248-161-5.ap-northeast-1.compute.amazonaws.com   ip-10-128-75-156.ap-northeast-1.compute.internal    running default 0               t1.micro        2013-01-29T11:51:35+0000    ap-northeast-1b aki-42992843                    monitoring-disabled     54.248.161.5    10.128.75.156               ebs                                     paravirtual     xen     LvWjn1358508959781      sg-c42c45c5     default false
BLOCKDEVICE     /dev/sda1       vol-765ff554    2013-01-18T11:36:03.000Z        true
TAG     instance        i-3b0b4738      Name    Master AmazonLinux
上記結果から、以下のようになっていることが分かります。
    EC2 instance-id = i-3b0b4738
    EC2 AvailabilityZone = ap-northeast-1b
    EC2 Kernel-ID = aki-42992843  (今回は使わない値ですが)
    EBS Volume = vol-765ff554
    EBS のマウント位置 : /dev/sda1



・EBSスナップショト作成
スナップショットを作成するコマンドは ec2-create-snapshot 、スナップショットの状態を確認するコマンドは ec2-describe-snapshots です。では、実行してみましょう。
$ ec2-create-snapshot \
     --description 'Master AmazonLinux' \
     vol-765ff554

SNAPSHOT         snap-1cfff33c  vol-765ff554    pending 2013-01-29T12:02:38+0000                354893364746    8   Master AmazonLinux

$ ec2-describe-snapshots
SNAPSHOT        snap-1cfff33c   vol-765ff554    completed       2013-01-29T12:02:38+0000        100%    354893364746        8       Master AmazonLinux
今回使用しているEC2インスタンスのEBSは、デフォルトの8GBしか容量が無いので 比較的すぐに pending → completed になりますね。



・スナップショットからEBSボリューム作成
EBSボリュームを作成するのは ec2-create-volume コマンドです。アタッチするEC2インスタンスと同一 AvailavilityZone に作成する方が望ましいので、そのように指定します。
$ ec2-create-volume \
     --snapshot snap-1cfff33c \
     --availability-zone ap-northeast-1b
VOLUME  vol-59ca737b    8       snap-1cfff33c   ap-northeast-1b creating        2013-01-29T13:12:08+0000        standard

$ ec2-describe-volumes
VOLUME  vol-59ca737b    8       snap-1cfff33c   ap-northeast-1b available       2013-01-29T13:12:08+0000        standard
VOLUME  vol-765ff554    8       snap-1ee78f3f   ap-northeast-1b in-use  2013-01-18T11:36:03+0000        standard
ATTACHMENT      vol-765ff554    i-3b0b4738      /dev/sda1       attached        2013-01-18T11:36:03+0000        true
ec2-describe-volume の結果にも、新しく作成されたEBSボリュームが表示されていますね。
ちなみに、下側の vol-765ff554 は もともと存在していた(コピー元の) EBSボリュームです。




・EC2インスタンスへアタッチ
ec2-attach-volume というコマンドでアタッチ(EBSをEC2へ取り付け)するらしいけれど……。デバイス名の指定が必要らしい。空いているデバイス名を探す必要がありますね。
$ mount
/dev/xvda1 on / type ext4 (rw,noatime)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)

$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/xvda1            7.9G  887M  7.0G  12% /
tmpfs                 301M     0  301M   0% /dev/shm
…わからん。
ec2-describe-instances による情報では「デフォルトのEBS は /dev/sda1 にアタッチされている」ということだったけど……。/dev/xvda1 とは何だ???

とりあえず、ec2-describe-instances の情報通り /dev/sda1 に EBSがアタッチされているのだと信じます。それに倣うのであれば、新しいEBSボリュームは /dev/sdb1 にアタッチすることになります(別に、他のデバイス名でも良いけど……/dev/sda999 とかでもOKなのかな?[謎])。
$ ec2-attach-volume vol-59ca737b --instance i-3b0b4738 --device /dev/sdb1
ATTACHMENT      vol-59ca737b    i-3b0b4738      /dev/sdb1       attaching       2013-01-29T13:33:10+0000

$ ec2-describe-instances i-3b0b4738
RESERVATION     r-83af1c80      354893364746    web
INSTANCE        i-3b0b4738      ami-486cd349    ec2-54-248-161-5.ap-northeast-1.compute.amazonaws.com   ip-10-128-75-156.ap-northeast-1.compute.internal    running default 0               t1.micro        2013-01-29T11:51:35+0000    ap-northeast-1b aki-42992843                    monitoring-disabled     54.248.161.5    10.128.75.156               ebs                                     paravirtual     xen     LvWjn1358508959781      sg-c42c45c5     default false
BLOCKDEVICE     /dev/sda1       vol-765ff554    2013-01-18T11:36:03.000Z        true
BLOCKDEVICE     /dev/sdb1       vol-59ca737b    2013-01-29T13:33:10.000Z        false
TAG     instance        i-3b0b4738      Name    Master AmazonLinux
新しく作成したEBSボリュームをEC2インスタンスにアタッチできたみたい。
次は mount してみます。ここでは /mnt/extra というディレクトリを作成し、ソコをマウントポイントにします。
$ sudo mkdir -p /mnt/extra

$ sudo mount /dev/sdb1 /mnt/extra

$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/xvda1            7.9G  887M  7.0G  12% /
tmpfs                 301M     0  301M   0% /dev/shm
/dev/xvdb1            7.9G  887M  7.0G  12% /mnt/extra

$ ls -lah /mnt/extra/
total 108K
dr-xr-xr-x 22 root root 4.0K Jan 29 11:52 .
drwxr-xr-x  3 root root 4.0K Jan 29 13:16 ..
-rw-r--r--  1 root root    0 Jan 29 11:52 .autofsck
dr-xr-xr-x  2 root root 4.0K Oct  8 17:10 bin
dr-xr-xr-x  3 root root 4.0K Oct  8 17:10 boot
drwxr-xr-x  2 root root 4.0K Jan  6  2012 dev
drwxr-xr-x 67 root root 4.0K Jan 29 11:52 etc
drwxr-xr-x  3 root root 4.0K Oct  8 18:10 home
dr-xr-xr-x 15 root root  12K Oct  8 18:10 lib
drwxr-xr-x  2 root root 4.0K Oct  8 17:06 local
drwx------  2 root root  16K Oct  8 17:06 lost+found
drwxr-xr-x  2 root root 4.0K Jan  6  2012 media
drwxr-xr-x  2 root root 4.0K Jan  6  2012 mnt
drwxr-xr-x  3 root root 4.0K Oct  8 17:08 opt
drwxr-xr-x  2 root root 4.0K Oct  8 17:06 proc
dr-xr-x---  3 root root 4.0K Jan 18 11:36 root
dr-xr-xr-x  2 root root 4.0K Oct  8 17:10 sbin
drwxr-xr-x  2 root root 4.0K Jan  6  2012 selinux
drwxr-xr-x  2 root root 4.0K Jan  6  2012 srv
drwxr-xr-x  2 root root 4.0K Oct  8 17:06 sys
drwxrwxrwt  5 root root 4.0K Jan 29 11:58 tmp
drwxr-xr-x 12 root root 4.0K Oct  8 17:06 usr
drwxr-xr-x 19 root root 4.0K Oct  8 17:10 var
mount できた。

/dev/sdb1 というデバイス名にしたはずが、なぜか /dev/xvdb1 という名前に変換されていますね…。EBS の仕組みせい? あるいは AmazonLinux は、そういう挙動をするのかしら? 分からない……。

とりあえず、マウント自体は出来ているのでヨシとしておきます。




・後始末
まずは unmount (=umountコマンド)から。
umount するデバイス名は… /dev/xvdb1 と /dev/sdb1 と、どちらで指定しても良いみたい。謎すぎる。ここでは /dev/sdb1 として umount しておきます。
$ sudo umount /dev/sdb1

$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/xvda1            7.9G  887M  7.0G  12% /
tmpfs                 301M     0  301M   0% /dev/shm
次は EBS Volume のデタッチ(切り離し)。
ec2-detach-volume コマンドに EBS Volume ID だけ指定すれば良いみたい。
$ ec2-detach-volume vol-59ca737b
ATTACHMENT      vol-59ca737b    i-3b0b4738      /dev/sdb1       detaching       2013-01-29T13:33:10+0000
あるいは、間違ったVolume をdetachしてしまうトラブルを避けるなら、instance-ID と デバイス名 を両方とも指定する方が良いかも。以下、全部指定する場合の例。指定を間違えるとエラーになっているのが分かります。
$ ec2-detach-volume \
     vol-59ca737b
\
     --instance i-3b0b4738 \
     --device /dev/sdc1
Client.InvalidAttachment.NotFound: The volume 'vol-59ca737b' is not attached to instance 'i-3b0b4738' as device '/dev/sdc1'.
    ⇒ /dev/sdc1 なんて名前のデバイスは無い

$ ec2-detach-volume \
     vol-59ca737b
\
     --instance i-3b0b4738 \
     --device /dev/xvdb1
Client.InvalidAttachment.NotFound: The volume 'vol-59ca737b' is not attached to instance 'i-3b0b4738' as device '/dev/xvdb1'.
    ⇒ umount と違って /dev/xvdb1 というデバイス名では認識されない

$ ec2-detach-volume \
     vol-59ca737b \
     --instance i-3b0b4738 \
     --device /dev/sdb1
ATTACHMENT      vol-59ca737b    i-3b0b4738      /dev/sdb1       detaching       2013-01-29T13:46:10+0000

$ ec2-describe-instances i-3b0b4738
RESERVATION     r-83af1c80      354893364746    web
INSTANCE        i-3b0b4738      ami-486cd349    ec2-54-248-161-5.ap-northeast-1.compute.amazonaws.com   ip-10-128-75-156.ap-northeast-1.compute.internal    running default 0               t1.micro        2013-01-29T11:51:35+0000    ap-northeast-1b aki-42992843                    monitoring-disabled     54.248.161.5    10.128.75.156               ebs                                     paravirtual     xen     LvWjn1358508959781      sg-c42c45c5     default false
BLOCKDEVICE     /dev/sda1       vol-765ff554    2013-01-18T11:36:03.000Z        true
TAG     instance        i-3b0b4738      Name    Master AmazonLinux
これでデタッチ(切り離し)できました。


次は、 EBS Volume の削除。ec2-delete-volume コマンドを使用します。
$ ec2-delete-volume vol-59ca737b
VOLUME  vol-59ca737b

$ ec2-describe-volumes vol-59ca737b
Client.InvalidVolume.NotFound: The volume 'vol-59ca737b' does not exist.

$ ec2-describe-volumes
VOLUME  vol-765ff554    8       snap-1ee78f3f   ap-northeast-1b in-use  2013-01-18T11:36:03+0000        standard
ATTACHMENT      vol-765ff554    i-3b0b4738      /dev/sda1       attached        2013-01-18T11:36:03+0000        true
消えました。
一個残っている EBS Volume は、起動している AamzonLinux 自身が使用しているモノですね。



残っている EBS Snapshot を確認してみます。
$ ec2-describe-snapshots
SNAPSHOT        snap-1cfff33c   vol-765ff554    completed       2013-01-29T12:02:38+0000        100%    354893364746        8       Master AmazonLinux
ところで EBS Snapshot にも VolumeID があるけど、直接 EBS として attach できるのでしょうか??? 試してみます…。
$ ec2-attach-volume vol-765ff554 --instance i-3b0b4738 --device /dev/sdc1
Client.VolumeInUse: vol-765ff554 is already attached to an instance
あら???
この VolumeID が何なのか調べてみましょう。
$ ec2-describe-volumes vol-765ff554
VOLUME  vol-765ff554    8       snap-1ee78f3f   ap-northeast-1b in-use  2013-01-18T11:36:03+0000        standard
ATTACHMENT      vol-765ff554    i-3b0b4738      /dev/sda1       attached        2013-01-18T11:36:03+0000        true
あああぁぁ…。
この VolumeID は、バックアップ取得元の EBS VolumeID ということなのですね...(つまり、最初から存在していたEBS Volume である…と)。



最後に、不要になったスナップショットを ec2-delete-snapshot コマンドで削除します。
$ ec2-delete-snapshot snap-1cfff33c
SNAPSHOT        snap-1cfff33c
$ ec2-describe-snapshots

消えました。





これで、コマンドラインから EBS ボリュームのスナップショット(バックアップ)を作成し、そこから 再度 EC2インスタンスへアタッチ可能な EBS ボリュームを作成することが出来るようになりました。



今回はここまで。








今回は、EBS (仮想化HDD)のバックアップを作成し、そこからAMI(ブートイメージ)を作成してみます。もちろん、コマンドライン(CUI)で……。


・最初のEC2インスタンス
AmazonLinux を OS として、EC2インスタンス(Micro 32bit, EBS)を起動し、その上で作業します。つまり、今回の作業は自分自身をバックアップする…ということになります。

後から必要になるので「起動したEC2インスタンス上で、自分自身の instance-idを取得」しておきます。
$ curl 'http://169.254.169.254/latest/meta-data/instance-id'; echo -en '\n'
i-3b0b4738
http://169.254.169.254/ にhttpアクセスすれば、アクセス元のEC2インスタンス情報をレスポンスとして得られます。その中に instance-id が存在するので、ソレを使うことにします。

また、同じようにしてEC2 インスタンスが使用している kernel-id も取得しておきます。
$ curl 'http://169.254.169.254/latest/meta-data/kernel-id'; echo -en '\n'
aki-42992843
kernel-id が無いと、この後 作成する AMI (AmazonMachineImage)が「正しく起動しない」ものになってしまうので…。使用しているOSやインスタンスタイプによっては、指定しなくても動作するかもしれませんが…。




・EBSのID (volume-id)を調べる
まずは、起動している AmazonLinux にマウントされている EBS の ID を調べます。
先に調べておいた EC2の instance-id をパラメータとして ec2-describe-instances コマンドを使用します。
$ ec2-describe-instances  i-3b0b4738
RESERVATION     r-83af1c80      354893364746    web
INSTANCE        i-3b0b4738      ami-486cd349    ec2-46-51-239-135.ap-northeast-1.compute.amazonaws.com  ip-10-128-75-253.ap-northeast-1.compute.internal    running default 0               t1.micro        2013-01-28T10:54:20+0000    ap-northeast-1b aki-42992843                    monitoring-disabled     46.51.239.135   10.128.75.253               ebs                                     paravirtual     xen     LvWjn1358508959781      sg-c42c45c5     default false
BLOCKDEVICE     /dev/sda1       vol-765ff554    2013-01-18T11:36:03.000Z        true
TAG     instance        i-3b0b4738      Name    Master AmazonLinux
/dev/sda1 にマウントされているのは vol-765ff554 という EBS になっているようです。

では、次に、EBS の状態を見てみましょう。
$ ec2-describe-volumes vol-765ff554
VOLUME  vol-765ff554    8       snap-1ee78f3f   ap-northeast-1b in-use  2013-01-18T11:36:03+0000        standard
ATTACHMENT      vol-765ff554    i-3b0b4738      /dev/sda1       attached        2013-01-18T11:36:03+0000        true
EBS側から見ても、どのインスタンスにマウントされているのか…というのは分かるんですね。



・EBSのスナップショットを取得する
EBSのバックアップ作成用コマンドは ec2-create-snapshot  というものらしいです。
先に入手した volume-id をパラメータとして与えて、EBS Snapshot を作成します。
⇒ 作成されたバックアップは「EBS Snapshot」と呼ばれるみたい…。単なる Snapshot でも通じるみたいだけど、自信が無いので EBS Snapshot と呼んでおきます(^^;
⇒ ここでは使っていませんが ec2-create-snapshot に --description オプションを与えることで、Snapshot にコメントを付与できるようです。
$ ec2-create-snapshot vol-765ff554
SNAPSHOT        snap-a63b3886   vol-765ff554    pending 2013-01-28T11:26:21+0000                354893364746    8
コマンドを発行した直後は「バックアップ開始依頼した」というだけであって、完了までに時間がかかります。ec2-describe-snapshots コマントを利用して、状態を確認してみます。
$ ec2-describe-snapshots snap-a63b3886
SNAPSHOT        snap-a63b3886   vol-765ff554    completed       2013-01-28T11:26:21+0000        100%    354893364746        8
意外なほど早く処理が完了してしまいますね…。時間帯によっては違うのかもしれませんが…。



・AMIの登録
作成した EBS Snapshot を、EC2インスタンスの起動イメージとして使用できるよう、AMI(Amazon Machine Image)に登録してみます。
$ ec2-register \
     --snapshot snap-a63b3886 \
     --kernel-id aki-42992843 \
     --name master_amazonlinux \
     --description 'Master AmazonLinux'
IMAGE   ami-5120a550
--kernel-id の指定を忘れると、起動できない AMI が作成されることがあるので要注意。さらに --name と --description を付与して、AMIの用途などを追記しておきます。
登録されたAMIを確認してみます。
$ ec2-describe-images ami-5120a550
IMAGE   ami-5120a550    354893364746/master_amazonlinux 354893364746    available       private         i386    machine aki-42992843     ebs     paravirtual     xen
BLOCKDEVICEMAPPING      /dev/sda1               snap-a63b3886   8       true    standard
基となった EBS Snapshot の IDも記録されていますね…。



・EBSからコマンド一発でAMI作成
ec2-create-snapshot と ec2-register を一回で同時に実行できるコマンドも存在するようです。ec2-create-image というものらしいので……さっそく実行してみましょう。
先ほど作成したものと区別するため、ここでは master2 という名前を付けておきます。
$ ec2-create-image i-3b0b4738 --name 'master2' --description 'test for ec2-create-image'
IMAGE   ami-5b20a55a
$
Broadcast message from root@ip-~
        (unknown) at 12:00 ...

The system is going down for reboot NOW!
Control-Alt-Delete pressed
Connection to ~.compute.amazonaws.com closed by remote host.
Connection to ~.compute.amazonaws.com closed.

あらら……
突然、ssh コマンドが切断されてしまいました。
というか、EC2インスタンス(AmazonLinux)自体が再起動されてしまったようです…。

どうやら、ec2-create-image コマンドを使用すると、EC2インスタンスが一時停止してしまうみたいですね…。
⇒ ということは、ec2-create-snapshot  の時も EC2インスタンスは一時停止しておいた方が良いのかなぁ…ディスクの中身の整合性なんかを考慮するなら、EC2インスタンスを停止しておいた方が良いんでしょうねぇ…。


気を取り直して、勝手に再起動した AmazonLinux に ssh で再接続し、EBS Snapshot と AMI が作成されているかどうか確認してみます。
$ ec2-describe-snapshots
SNAPSHOT        snap-a63b3886   vol-765ff554    completed       2013-01-28T11:26:21+0000        100%    354893364746        8
SNAPSHOT        snap-e3cccfc3   vol-765ff554    completed       2013-01-28T12:00:18+0000        100%    354893364746        8       Created by CreateImage(i-3b0b4738) for ami-5b20a55a from vol-765ff554

$ ec2-describe-images ami-5b20a55a
IMAGE   ami-5b20a55a    354893364746/master2    354893364746    available       private         i386    machine aki-42992843                        ebs     paravirtual     xen
BLOCKDEVICEMAPPING      /dev/sda1               snap-e3cccfc3   8       true    standard
EBS Snapshot も AMI も、(コマンド発行元のサーバが再起動されたにも関わらず)キチンと作成されているようです。AWSコマンドは、実際には http リクエストで実現されているらしいですから、これはまぁ、期待通りの動作かも。
また、kernel-id を指定しませんでしたが、自動的に反映されています。これは楽で良いですね☆



・AMIの削除
後始末として、先ほど登録した 2つの AMI を消去します。精確には「登録の解除(deregister , unregister)」という作業ですが…。

まず、AMIのIDを調べます。
$ ec2-describe-images
IMAGE   ami-5b20a55a    354893364746/master2    354893364746    available       private         i386    machine aki-42992843                        ebs     paravirtual     xen
BLOCKDEVICEMAPPING      /dev/sda1               snap-e3cccfc3   8       true    standard
IMAGE   ami-5120a550    354893364746/master_amazonlinux 354893364746    available       private         i386    machine aki-42992843                        ebs     paravirtual     xen
BLOCKDEVICEMAPPING      /dev/sda1               snap-a63b3886   8       true    standard
次に、AMIのIDを指定して消去します。
$ ec2-deregister ami-5b20a55a
IMAGE   ami-5b20a55a
$ ec2-deregister ami-5120a550
IMAGE   ami-5120a550
最後に、AMIがホントに消えたどうかの確認。
$ ec2-describe-images
レスポンス表示が何もないので、消えてますね。



・EBS Snapshot を消す
次に、やはり後始末として 作成済みの EBS Snapshot を消去します。

まず、EBS Snapshot の ID を取得します。
$ ec2-describe-snapshots
SNAPSHOT        snap-a63b3886   vol-765ff554    completed       2013-01-28T11:26:21+0000        100%    354893364746        8
SNAPSHOT        snap-e3cccfc3   vol-765ff554    completed       2013-01-28T12:00:18+0000        100%    354893364746        8       Created by CreateImage(i-3b0b4738) for ami-5b20a55a from vol-765ff554
入手した EBS Snapshot のIDを指定して、ec2-delete-snapshot コマンドを実行します。消すのは一瞬かと思いきや、以外と時間がかかります(数秒程度?)。
$ ec2-delete-snapshot snap-a63b3886
SNAPSHOT        snap-a63b3886
$ ec2-delete-snapshot snap-e3cccfc3
SNAPSHOT        snap-e3cccfc3
最後に、ホントに消えたかどうかの確認。
$ ec2-describe-snapshots

ちなみに、EBS Snapshot を AMI として使用している場合、先にAMIを消さないと EBS Snapshot は消去できません。依存関係が存在するせいでしょう



これで、EC2インスタンスに使用された EBS(仮想HDD)を コマンドラインからバックアップ、再利用する方法を手に入れたことになります。



ところで、EBS Snapshot を EBS に書き戻すにはどうすれば良いんでしょうね???[謎]

前回の続き。

作成したロードバランサーと、EC2インスタンス、EBS Snapshot、AMI を削除します。



・ロードバランサーの後始末
elb35
実験が終わったのでロードバランサーを消去します。
「Load Balancer → test-lbをチェック → Delete」で消去。


elb36
ダイアログ画面が出ますが、特に気になる警告も出ないので Yes, Delete をクリック。


elb37
ロードバランサー設定前の画面に戻りました。



・EC2インスタンスの後始末
WEBサーバとして利用した web01/web02 のEC2インスタンスも消去します。

elb38
「Instances → web01/web02を両方チェック → Actionsボタン → Stop」とクリックしていきます。両方同時にチェックできるので、STOPさせるだけなら、マトメて処理できます。


elb39
確認ダイアログが出ますが、そのまま Yes, Stop をクリックします。


elb40
しばらく待てば、web01/web02 の両方とも「stopped」の状態になります(その状態になるまで待ってください)。

次は、EC2インスタンスを TERMINATEしたいのですが……Termination Protection が設定されているので直接 TERMINATEできません。さらに、設定変更するのは1台ずつしか出来ないという……まぁ、 Protection の存在意義を考えると当然なのですが、メンドクサイです(x_x;

elb41
Instances 画面で web01 か web02 にチェックを付け、Actions ボタンから Change Terminate Protection を選択します。


elb42
「Terminate Protection を無効にするけど、ホントに良い?」と聞かれるので「Yes, Disable」をクリックします。

上記の Change Terminate Protection の手順を web02 にも同じように適用します。


両方とも Terminate Protection を解除したら、後は、前回の記事でやったように、web01/web02 の両方のインスタンスを Terminate します。
「Instances → web01/web02をチェック → Actionsボタン → Terminate」で操作できます。


elb43
結果としては、web01、web02 ともに「terminated」になって上記のような画面になるはずです。


・AMIの削除
elb44
AMI(Amazon Machine Image)は…今回の作成してあるものは たぶん実体のない名前だけだと思うのですが……残していても困るので消去しておきます。
AWS Management Console で「AMIs → 作成済みのAMIをチェック → De-register」と操作すれば消去できます。


elb45
確認画面。特に問題は無いので Yes, De-register をクリック。



elb46
消去完了画面。


elb47
消去が完了すると、上記のような画面になります。

De-register という名前の通り、AMI 単なるラベルであって、S3 とか EBS とかに保存されているものが実体なのでしょう。たぶん...。



・EBS Snapshot の削除
elb48
EBS Snapshot を削除するので、AWS Management Console で「Snapstops → 作成済みSnapshotをチェック → Delete」と操作します。



elb49
確認画面。Yes,Deleteをクリックします。



elb50
削除が完了すると、上記のような画面になります。



・削除完了の確認
elb51

ロードバランサー、EC2インスタンス、EBS snapshot、AMI とすべて削除したハズなので、EC2 Dashboard に戻って My Resources を確認します。念のため リロードボタンも押下しておいた方が良いでしょう。
「0 Running machines」「0 EBS Volumes」「0 EBS Snapshots」「0 Load Balancers」となっていれば正解。

お金がかかることなので、毎回確認しておきましょう。


これで、ELBを使ったロードバランサーの実験は終了。
次は何をしましょうか...。

このページのトップヘ