電子の密林を開拓する

タグ:ELB

今回は コマンドライン(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 」で解除できます。


今回はここまで。

続きを読む

AWS公式ブログを書いている人(玉川憲氏)によると、ELBのIPアドレスは変化することがあるらしいです。

http://www.slideshare.net/AmazonWebServicesJapan/elb-cloudwatch-autoscaling-aws
ELBはトラフィックにあわせ、自動的にキャパシティを増減する
→ 数も増減するので、IPアドレスはそれに伴い変わる
    ・ (重要)ELBを使用するときには、DNS名を用いる
    ・独自ドメイン名には、名前解決にCNAMEを用いる
今まで、ELBには CNAME を利用する…と聞いていたけど、その理由が納得できた気がする。

同じ記事内で、ELB(TokyoRegion)がIPv6をサポートしていると書かれています。
今のところIPv6なんて(個人的には)使ってませんので、あくり興味は無いですが…。

どちらかと言えば、以下のような点の方が気になりますね…。

    ・EIPに IPv6 を割り当てできないのか?
         ⇒ ec2-allocate-address のオプションで、IPv6の指定は存在しないので
              たぶん無理かなー。

    ・ELBには EIPを割り当てできないのか?
          ⇒ CNAME使え…って言うぐらいだから、使えないんだろうなぁ…。
               グローバルIPを振れるなら、CNAME使う理由ないもんね…。


分からないことだらけで、もやもや中…。

前回の続き。

作成したロードバランサーと、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を使ったロードバランサーの実験は終了。
次は何をしましょうか...。

前回の続き。

ロードバランサーの「ヘルスチェック」の仕組みについて調べます。

WEBサーバ(EC2インスタンス)が2台、ロードバランサーが1台…が設定済みであることが前提です。



・WEBサーバの1台を停止させてみる
elb20
ロードバランサーの動作確認の一環として、web01 を強制的に停止(STOP)させてみます。
AWS Management Console から「Instances→web01→Actions→Stop」とクリックして、web01 の EC2 インスタンスを停止状態(STOP)にします。



・ロードバランサーはweb01の停止を認識する?
elb21
「Load Balancers → test-lb → Instances」をクリックして、ロードバランサーが web01 をどのように認識しているかを確認します。
↑の画面では、Out of Service となっており、理由はともかく web01 が無応答であることを認識しています。
これは期待通りですね。



・web01がSTOPした状態でhttp疎通試験してみる

ローカルPCからコマンドラインでロードバランサーに対してhttpリクエストを発行してみます。

$ for R in $(seq 1 20) ; do curl 'http://dualstack.test-lb-2062688374.ap-northeast-1.elb.amazonaws.com/ec2meta.php/latest/meta-data/public-hostname'; echo -en "\n" ; done
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com

※ホスト名は、自分のロードバランサーのものと置き換えてください。

web01が停止しているので、web02 にだけリクエストが届いているのが分かります。



・全WEBサーバを停止(STOP)させる
elb22
「Instances→web02→Actions→Stop」とクリックして、web02 もSTOPさせてしまいます。



・ロードバランサーはweb02の停止を認識する?
elb23
「Load Balancers → test-lb → Instances」をクリックして、ロードバランサーが web02 の停止(STOP)を認識しているかどうか確認します。
↑の画面では、期待通り Out of Service になっていますね。

ちなみに、WEBサーバが2台しか存在しないのに、その2台両方ともが Out of Service になってしまったので、Availability Zones で ap-northeast-1a の Healty? 項目が No となっています。これは期待通りの反応です。




・WEBサーバが存在しない状態でhttpリクエストを投げてみる
ローカルPCからコマンドラインからロードバランサーに対して http リクエストを投げてみます。

$ curl -v 'http://dualstack.test-lb-2062688374.ap-northeast-1.elb.amazonaws.com/ec2meta.php/latest/meta-data/public-hostname'
* Connected to ec2-54-248-79-114.ap-northeast-1.compute.amazonaws.com (54.248.79.114) port 80
> GET /ec2meta.php/latest/meta-data/public-hostname HTTP/1.1
User-Agent: curl/7.9.5 (i386-redhat-linux-gnu) libcurl 7.9.5 (OpenSSL 0.9.6b) (ipv6 enabled)
Host: dualstack.test-lb-2062688374.ap-northeast-1.elb.amazonaws.com
Pragma: no-cache
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*

* Connection #0 left intact
* Closing connection #0

※ホスト名は、自分のロードバランサーのものと置き換えてください。

ロードバランサーらしきものには接続しますが、そこから先は 応答がありませんね...。

こういう状態になったときのための定型文「ただいま込み合っております」とかの表示をさせたいけど、方法が分からないので今回は無視しておきます。




・WEBサーバを両方とも再起動する
elb24
STOP状態にしてあるWEBサーバを、両方とも START 状態に戻します。
「INstances→webb01/web02を両方チェック→Actionsボタン→Start」で、両方のEC2サーバを同時に START 状態にできます。



elb25
確認画面が出ますが、特に気になることもないので Yes, Start で。



・ロードバランサーは両WEB サーバを正常動作中として認識する?
elb26
「Load Balancers → test-lb → Instances」をクリックして、ロードバランサーが 両方webサーバ再起動を認識しているか確認しますが……認識してませんね。なぜ???



・ロードバランサーのヘルスチェック設定確認
elb27
「Load Balancers → test-lb → Health Check」とクリックして、ヘルスチェックの設定を確認します。
Healthy Threshold の値が 10 になってますね。Interval が 30sec になっているので、30sec × 10 = 300sec、つまりサーバーが再起動してから5分間はロードバランサーの割当配下に戻らないということですね。
これでは(動作確認が)ツライので設定を見直します。Health Check ページの下部にある「Edit Health Check」をクリックします。



・ヘルスチェックの設定変更
elb28
ダイアログが開くので、Healthy Threshold をデフォルトの10から4に変更しておきます。
これで、復活したサーバーが再度ロードバランサー割当配下に戻るまでの時間が  4 × 30sec = 2分 に短縮されます。これぐらいなら待てるかなーという数値になりました(気に入らなければ interval も含めてもっと小さい数字にしてください)。


elb29
確認のダイアログが出ますが、特に気になることもないので Close (OK)で。


・ヘルスチェック設定値の再確認
elb30
Healthy Threshold が 4 になっています。それだけ…。



・ロードバランサーは両WEB サーバを正常動作中として認識する?(再)
elb31
二分と設定したので、二分ほど待ちます(実際には 忘れて30分ほど放置しましたが…)。

「Load Balancers → test-lb → Instances」をクリックして、ロードバランサーが 両方webサーバ再起動を認識しているか確認しますが……今回は正常に認識していますね。
どちらも「In Service」となっています。



・両WEBサーバが再認識された状態でロードハランサーにhttpリクエストを投げてみる
まずは小手調べに一回だけローカルPCからリクエストを投げてみます。

$ curl -v 'http://dualstack.test-lb-2062688374.ap-northeast-1.elb.amazonaws.com/ec2meta.php/latest/meta-data/public-hostname'
* Connected to ec2-54-248-79-114.ap-northeast-1.compute.amazonaws.com (54.248.79.114) port 80
> GET /ec2meta.php/latest/meta-data/public-hostname HTTP/1.1
User-Agent: curl/7.9.5 (i386-redhat-linux-gnu) libcurl 7.9.5 (OpenSSL 0.9.6b) (ipv6 enabled)
Host: dualstack.test-lb-2062688374.ap-northeast-1.elb.amazonaws.com
Pragma: no-cache
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*

* Connection #0 left intact
* Closing connection #0
ec2-54-248-163-66.ap-northeast-1.compute.amazonaws.com

ちゃんと応答がありますね。
次は、連続でリクエストしてみます。

$ for R in $(seq 1 20) ; do curl 'http://dualstack.test-lb-2062688374.ap-northeast-1.elb.amazonaws.com/ec2meta.php/latest/meta-data/public-hostname'; echo -en "\n" ; done
ec2-54-248-25-192.ap-northeast-1.compute.amazonaws.com
ec2-54-248-163-66.ap-northeast-1.compute.amazonaws.com
ec2-54-248-25-192.ap-northeast-1.compute.amazonaws.com
ec2-54-248-163-66.ap-northeast-1.compute.amazonaws.com
ec2-54-248-25-192.ap-northeast-1.compute.amazonaws.com
ec2-54-248-163-66.ap-northeast-1.compute.amazonaws.com
ec2-54-248-25-192.ap-northeast-1.compute.amazonaws.com
ec2-54-248-163-66.ap-northeast-1.compute.amazonaws.com
ec2-54-248-25-192.ap-northeast-1.compute.amazonaws.com
ec2-54-248-163-66.ap-northeast-1.compute.amazonaws.com
ec2-54-248-25-192.ap-northeast-1.compute.amazonaws.com
ec2-54-248-163-66.ap-northeast-1.compute.amazonaws.com
ec2-54-248-25-192.ap-northeast-1.compute.amazonaws.com
ec2-54-248-163-66.ap-northeast-1.compute.amazonaws.com
ec2-54-248-25-192.ap-northeast-1.compute.amazonaws.com
ec2-54-248-163-66.ap-northeast-1.compute.amazonaws.com
ec2-54-248-25-192.ap-northeast-1.compute.amazonaws.com
ec2-54-248-163-66.ap-northeast-1.compute.amazonaws.com
ec2-54-248-25-192.ap-northeast-1.compute.amazonaws.com
ec2-54-248-163-66.ap-northeast-1.compute.amazonaws.com

連続でリクエストすると、交互にサーバが負荷分散されています。
どちらも期待通りです。

※ホスト名は、自分のロードバランサーのものと置き換えてください。




・ヘルスチェック用のindex.htmlを消してみる
ヘルスチェック用として設定されている /ndex.html のファイルを消去(リネーム)して、ヘルスチェックを失敗させてみましょう。
ここでは web02 側の Ubuntu を操作します。

  cd /var/www
  sudo mv  index.html  index.html_

ロードバランサーの状態を確認してみます。
elb32
index.html を消去してから数分待てば、Out of Service として認識されています。期待通りの挙動です。



・ヘルスチェック用のindex.htmlを復活させる
先ほど消去(リネーム)した /index.html を復元します。web02側の Ubuntu を操作します。

  cd /var/www
  sudo mv  index.html_  index.html

その後、ロードバランサーの画面を見ると、以下のようになっているはずです。
elb33
web02 が In Service 状態に戻っていますね。

EC2インスタンス自体を停止(STOP)させたときは、Out of Service から In Service に復帰するまで 相当待たされましたが、Apache のファイルを消去→復元 しただけだと、2分かからずに In Serviceに復元しているように見えます。気のせいですかね...[謎]



・Apache を停止させてみる
次は、web02 の Apache サービス自体を停止させてみます。

ubuntu@ip-10-150-191-57:/var/www$ sudo service apache2 stop
 * Stopping web server apache2
 ... waiting    ...done.
ubuntu@ip-10-150-191-57:/var/www$

この状態でロードバランサーの Instances 画面を見ると…
elb34
…期待通り(しばらくすれば) Out of Service に変化しています。

次は、web02 の apache を再開させます。

ubuntu@ip-10-150-191-57:/var/www$ sudo service apache2 start
 * Starting web server apache2
   ...done.
ubuntu@ip-10-150-191-57:/var/www$

で、もう一度 AWS Management Console で LoadBalancer を確認してみると…。
Apache を再開させるて(2分経過することなく) すぐに In Service に復帰します。
どういう理由で2分待たずに復帰するのか分からないので、ヘルスチェックのログが見たいなぁ...(どこにあるのか知らないので見られないけど ^^;)



ロードバランサー用ヘルスチェックの動作確認もできたので、今回はここまで。



次回は後始末です。

前回の続き。今回は、ロードバランサーを設定します。
以前設定した WEBサーバ(EC2インスタンス)は動作状態である…という前提です。


・ロードバランサーの設定
elb11
WEBサーバが2台用意できたので、次はロードバランサーを設定します。
AWS Management Console の EC2 Dashboard から「LoadBalancer→Create Load Balancer」で作成を開始できます。




elb12
ロードバランサーの設定画面ですが……ここでは名前(Load Balancer Name)ぐらいしか設定するものはありません。ここでは test-lb という名前にしておきます。
ポート設定は……port:80 以外使わないので、追加は不要です。



elb13
ヘルスチェック(EC2の死活確認)の設定画面。
↑はデフォルトのままですが、これでOKということにしておきましょう。



elb14
ロードバランサーの配下に従える EC2 (WEBサーバ)の割り当て画面。
ここでは web01 と web02 の両方をチェックし、割り当てておきます。




elb15
確認画面。特に気になることもないので次へ。




elb16
完了画面。特に言うことは無いです。



・ロードバランサーの状態確認
elb17
出来上がったロードバランサーの動作を確認してみます。
まず、先ほど割り当てた二台の web01 と web02 が、正しく割り当てに入っているかどうかの確認をします。

「Load Balancers → test-lb(今回作成したロードバランサー) → Instances」をクリックすると、ロードバランサー配下のEC2インスタンスの状態を確認できます。精確には、ロードバランサーから見えている EC2 インスタンスの状態……ということになりますが。

ここでは、web01、web02 ともに In Service となっているので 正常 ということですね。


・ロードバランサーのURL(FQDN)確認
elb18
ロードバランサーのURL (FQDN) は、Description のタブで確認できます。
「Load Balancers → test-lb(今回作成したロードバランサー) → Description」にあります。

URL(FQDN)は、3種類提供されていますが……。Aレコード(IPv4用…一番最初のFQDN)を使えばOKなような気もするのですが、InternetExplorer で試したところアクセスできませんでした。
仕方がないので、dualstack. ~ で始まる「A or AAAA record」というのをコピーして使用します。curl で確認するのであれば、こんな感じ。

$ for R in $(seq 1 20) ; do curl 'http://dualstack.test-lb-2062688374.ap-northeast-1.elb.amazonaws.com/ec2meta.php/latest/meta-data/public-hostname'; echo -en "\n" ; done
ec2-54-248-141-85.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-54-248-141-85.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-54-248-141-85.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-54-248-141-85.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-54-248-141-85.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-54-248-141-85.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-54-248-141-85.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-54-248-141-85.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-54-248-141-85.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com
ec2-54-248-141-85.ap-northeast-1.compute.amazonaws.com
ec2-176-34-36-129.ap-northeast-1.compute.amazonaws.com

※ホスト名は、自分のロードバランサーのものと置き換えてください。

2つのEC2インスタンスに対して、交互にアクセスが振り分けられているのが分かります。

ここまでで、基本的なロードバランサーの設定は完了しました。



記事が長いと livedoor blog に怒られるので、今回はここまで。

このページのトップヘ