技術ブログ - 毎日が成長!

‘EC2’ タグのついている投稿

HeartBeatとElastic IPを使用した冗長化構成をテストする

2011年11月4日 by yanase

こんちには! インフラエンジニアの柳瀬です!

AWSにはElastic Load BalancerやRDSのMulti-AZなど冗長化を構成する上で便利な機能が盛り込まれています。
今回は英語版のフォーラムで紹介されているElastic IPとHeartBeatを使用した冗長化を試してみました。

今回テストを行った環境は以下の通りです。

  • Ubuntu 10.04 LTS
  • HeartBeat 3.0.3

それでは環境を用意しましょう。これから記載する設定はHAを構成するノードそれぞれで行ってください。
まずはそれぞれのUbuntuにHost名を定義します。

$ vi /etc/hostname
  1 heartbeat01

次にHeartBeatをインストールして設定を行います。

$ sudo apt-get install heartbeat

$ sudo vi /etc/ha.d/ha.cf
  1 logfile         /var/log/heartbeat.log
  2 node            heartbeat01 heartbeat02
  3 keepalive       1
  4 deadtime        10
  5 ucast           eth0 10.150.170.180 #internal IP of the peer
  6 auto_failback   no

$ sudo i /etc/ha.d/haresources
  1 heartbeat01 elastic-ip

$ sudo vi /etc/ha.d/authkeys
  1 auth 1
  2 1 sha1 yourpassword

Elastic IPの付け替えのスクリプトに使用しているツールをインストールします。

$ curl https://raw.github.com/timkay/aws/master/aws -o aws
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 76826  100 76826    0     0  43721      0  0:00:01  0:00:01 --:--:-- 80869

$ sudo mv ./aws /usr/local/bin/
$ chmod +x /usr/local/bin/aws 

$ vi .awssecret
  1 YOURACCESSID
  2 YOURSECRETACCESSKEY

$ chmod 600 .awssecret
$ sudo cp .awssecret /root/

$ aws describe-addresses --region ap-northeast-1
+---------------+------------+
|   publicIp    | instanceId |
+---------------+------------+
| 111.12.123.12 | i-xxxxxxxx |
| 111.21.210.21 |            |
+---------------+------------+

最後にElastic IPのつけかえを行っているスクリプトを用意します。
※例では東京リージョンを指定していますが、こちらはそれぞれの環境で変更してください

$ sudo vi /etc/init.d/elastic-ip
  1 #!/bin/bash
  2
  3
  4 MY_ID="i-6efaef6f" # different for each node
  5 ELASTIC_IP="176.32.87.217"
  6 REGION="ap-northeast-1"
  7
  8 case $1 in
  9     start)
 10         aws associate-address "$ELASTIC_IP" -i "$MY_ID" --region "$REGION" > /dev/null
 11         echo $0 started
 12         ;;
 13     stop)
 14     aws disassociate-address "$ELASTIC_IP" --region "$REGION" > /dev/null
 15         echo $0 stopped
 16         ;;
 17     status)
 18     aws describe-addresses --region "$REGION" | grep "$ELASTIC_IP" | grep "$MY_ID" > /dev/null
 19     # grep will return true if this ip is mapped to this instance
 20     [ $? -eq 0 ] && echo $0 OK || echo $0 FAIL
 21     ;;
 22 esac

$ chmod +x /etc/init.d/elastic-ip

最後にHeartBeatを実行して準備完了です。

$ sudo /etc/init.d/heartbeat start

動作確認として以下のようにHeartBeat01のHeartBeatを停止してみると、無事にElastic IPが02に移動しています。

$ sudo /etc/init.d/heartbeat stop

これはあくまでHeartBeatを使用してElastic IPを付け替えるだけなので実際にはデータはS3に外出ししたり、lsyncdなどのツールでサーバ間で同期をとるなどの設計が必要です。
今回は通常のEC2インスタンスで実験を行いましたが、ローカルIPが固定出来てElastic Load Balancerが使えないVPCとかではニーズがありそうですね。

 

Amazon VPCの便利な機能をWordPressを例にして使ってみる

2011年9月22日 by yanase

こんにちは!インフラエンジニアの柳瀬です!
先日、東京にもオープンしたAmazon VPCがこれから注目を集めてくるに違いないと確信しているのですが、『実はその素晴らしさがあまり認知されていないのではないか?』と思う事があります。
Amazon VPCとはどのようなサービスでしょうか?

AmazonとVPN接続が出来るサービス!

と直感的に思ってしまいますが、これは個人的に半分だけ正解だと思っています。
といいますのも、VPN接続だけでなく他にもとても素晴らしい使い方が出来るからです。
今回はみなさん良くご存知のCMSであるWordPressを例にして便利な機能を使ってみたいと思います。
まず最初に今回のエントリで紹介する機能は以下となります。

  • VPC内に公開用と非公開用の2つのサブネットを作成する
  • フロントのWebサーバは公開用へ、DBサーバは非公開用へ配置する
  • DBサーバのメンテナンスはNATアドレッシングインスタンスを経由して外部へ接続する
  • 公開用と非公開用サブネット間には簡単なACL機能を設定する

■全体構成図
このような構成を組む事で、公開する必要があるインスタンスのみを公開セグメントに配置する事や(必要がないものは完全非公開のセグメントへ配置)、ACLによってネットワークレベルでのアクセス制限を実現出来るメリットがあります。

※以降の手順は以前のエントリーでVPCを作成した事が前提の手順となりますので、ご注意ください。

1.公開サブネットとNATアドレッシング
最初のポイントであるAmazon VPCでサブネットの作成はManagement Consoleから簡単に出来ます!

DBサーバが外部へ接続する為に必要となるNATアドレッシングインスタンス以下のようにAMIを検索してみてください。
作成したインスタンスを先ほど作成したVPCサブネット内で起動します。

次に起動したインスタンスを選択して、Change Source/Dest. CheckをDisableとします。

EIPの取得と割り当ても忘れずに行ってください。

改めてManagement ConsoleのVPC画面に戻り公開用サブネットに割り当てるインターネットゲートウェイを作成します。

公開用サブネットに割り当てるルートテーブルを作成します。

作成した公開用サブネットのデフォルトルート(0.0.0.0/0)に作成したインターネットゲートウェイを割り当てます。
メンテナンスは社内からVPN経由で行う場合は以下の設定を参考にしてください。

また、VPC作成時に設定したサブネットは非公開用としますので以下のように設定してください。
デフォルトルートのターゲットに先ほど起動したインスタンスを指定する事でNATして外部へアクセス出来ます。

2.WordPressインスタンスの準備
それでは実際にWordPressを構成するインスタンスを起動してみましょう。
Webインスタンスは公開用セグメント、DBインスタンスは非公開用セグメントを指定してVPC内で起動します。
Webインスタンスは外部からのアクセスを受け付けるのでEIPを付与する事を忘れないでください。
あとは通常のWordPressの構築と同様に以下の設定をインスタンスに行っていけばOKです。

  • DBインスタンス:MySQLのインストール、DB作成など
  • Webインスタンス:ApacheとPHP、WordPress

接続先のデータベースはは以下のようにDBインスタンスのローカルIPを指定してあげてください。

インストールが無事に完了すると、以下のようにブログへアクセス出来ます。

3.サブネット間のACL設定
VPC内のNetwork ACLsもManagement Consoleからoutboundとinboundの設定が簡単に出来ます。

Amazon VPCはVPN接続だけでなく、柔軟なネットワークが構築出来る素晴らしいサービスですね★
WordPressを例にあげましたが、これらの機能を使うことで色々なシステムをVPC内で運用する事が出来そうです!

 

Chefを使用してEC2インスタンスを操作するチュートリアル:その2

2011年9月15日 by yanase

こんにちは!インフラエンジニアの柳瀬です!
以前、Chefのチュートリアルを書いてから早いもので一ヶ月が経過してしまいました(すみません)。
9月号のSoftware DesignでもChefが特集されておりますし、これからより注目を浴びていきそうですね!
私も頑張って「攻め」の仕事術を学んでいきたいと思います。

knife ec2を使用してEC2インスタンスを起動と終了は以下の流れで行います。

  1. ローカルPCにOpscode社から提供されているcookbookのダウンロード
  2. Chef-Serverにcookbookをアップロードする
  3. EC2に接続するための設定を追加
  4. knife ec2による起動、動作確認
  5. apache2のrecipeを適用、動作確認
  6. EC2インスタンスのterminate、nodeリストからの削除

それではさっそく進めていきたいと思います。

1)ローカルPCにOpscode社から提供されているcookbookのダウンロード

こちらの作業はとても簡単です。
Opscode社から提供されているcookbookは以下のコマンドでダウンロード出来ます。

$ knife cookbook site vendor chef-client

2)Chef-Serverにcookbookをアップロードする

こちらの作業も以下のコマンドを実行するだけですので難しくはありません。

$ knife cookbook upload chef-client

3)EC2に接続するための設定を追加

こちらもそんなに難しいものではありません。
.chef/knife.rbにアクセスキーID、シークレットアクセスキーの情報を追記します。

$ echo "knife[:aws_access_key_id]     = \"YOUR_ACCESSKEY"\" >> .chef/knife.rb
$ echo "knife[:aws_secret_access_key] = \"YOUR_SECRET_ACCESSKEY_\"" >> .chef/knife.rb

4)knife ec2による起動、動作確認

それではいよいよEC2インスタンスの起動です。
ちなみにknifeコマンドは”knife –help”と実行する事でhelpを確認が出来ますが、EC2操作に関するhelpは以下のように実行してください。

$ knife ec2 --help

** EC2 COMMANDS **
knife ec2 instance data (options)
knife ec2 server list (options)
knife ec2 server create (options)
knife ec2 server delete SERVER [SERVER] (options)

さらに出力されたサブコマンドのhelpを参照する場合は以下のように実行します

$ knife ec2 instance data --help

現在起動しているEC2インスタンスは以下のようなコマンドを実行する事で一覧表示が出来ます

$ knife ec2 server list --region ap-southeast-1

knifeコマンドでEC2インスタンスを起動するには以下の情報を指定し、これに加えて実際は鍵を登録するユーザ名を指定します。

AWSの用語 knife ec2コマンドのオプション名
Region region
Availability Zone availability-zone
AMI ID image
Instance Type flavor
Security Group groups
Key Pairs ssh-key

それでは以下のように実行してインスタンスを起動してみます。
注意すべき点は事前にローカルのSSH公開鍵をAWSに登録した上でオプションに指定する事と、セキュリティグループもSSHアクセス可能な設定にしておく事です。

$ knife ec2 server create --run-list 'recipe[chef-client]' --region ap-southeast-1 --availability-zone ap-southeast-1a --image ami-f292eca0 --flavor t1.micro --groups yanase-develop --ssh-key yanase-ubuntu --ssh-user ubuntu

以下のコマンドでnodeとして追加されている事が確認出来ます。
実際にEC2インスタンスに接続すればchef-clientのプロセスも確認出きるはずです。

$ knife node list
i-3d87f568

5)apache2のrecipeの適用、動作確認

せっかくなので先ほど起動したインスタンスにapache2のrecipeを適用してみましょう。
まずは先ほど起動したnodeの詳細を見るとRecipeにchef-clietnが適用されている事が分かります。

$ knife node show i-3d87f568
Node Name:   i-3d87f568
Environment: _default
FQDN:        ip-10-136-21-61.ap-southeast-1.compute.internal
IP:          10.136.21.61
Run List:    recipe[chef-client]
Roles:
Recipes      chef-client
Platform:    ubuntu 10.04

それでは先ほどと同様にcookbookをダウンロードしてサーバにアップしましょう。

$ knife cookbook site vendor apache2
$ knife cookbook upload apache2

次に以下のコマンドでnodeにレシピを追加します。

$ knife node run_list add i-3d87f568 'recipe[apache2]'
run_list:
    recipe[chef-client]
    recipe[apache2]

先ほどと同じコマンドを実行するとapache2のrecipeが適用されています。

$ knife node show i-3d87f568
Node Name:   i-3d87f568
Environment: _default
FQDN:        ip-10-136-21-61.ap-southeast-1.compute.internal
IP:          10.136.21.61
Run List:    recipe[chef-client], recipe[apache2]
Roles:
Recipes      chef-client
Platform:    ubuntu 10.04

chef-clientはデフォルトで30分間隔でchef-serverにアクセスしてrecipeの適用を行いますが、待てない方は起動したインスタンスにログインして以下のコマンドを実行してください。

$ sudo chef-client

6)EC2インスタンスのterminate、nodeリストからの削除

それでは動作確認が終わったのでインスタンスをterminateします。

knife ec2 server delete i-3d87f568 --region ap-southeast-1

忘れずにnodeリストからも削除します。

$ knife node delete i-3d87f568

これで一通りの動作確認が出来ました。
しかし、これはあくまで基本的な動作確認です、実際は環境に合わせてrecipeを編集して一度に適用するなどの運用で効果を発揮します。
自分で一からrecipeの作成は大変でしょうから、Opscode社から提供されているものに修正を加えながらchefに慣れていくのも良さそうです。