kickstartのpostscript処理をコンソール出力するメモ
SpotInstance + ENI（固定IP）in VPC で財布に優しいテスト環境を作る
久しぶりの更新です。
Amazon VPCのいいところの１つは、固定プライベートIPを設定できるところですよね。
で、ちょうど固定プライベートIPで作業する必要があったので、オンデマンドm1.smallをVPC内に数インスタンス起動してたのですが、そこそこ費用がいってしまいました。
t1.microはまだVPCで使えないし、SpotInstanceだと固定プライベートIP指定で起動できないし、オンデマンドm1.smallでもそこそこ費用いくしと悩んでいたのですが、Elastic Network Interface（ENI）を使うことで、財布に優しい環境をつくることができました。
以下、やったことのメモです。
まずVPCを作っておきます。たとえば CIDR 10.0.0.0/16 で作って、Subnet を 10.0.0.0/24 としておく。このあたりは Wizardのデフォルト通りでＯＫ。
で、もう１つSubnetを作っておく。ここでは10.0.1.0/24としておく。
この状態で、SpotInstanceを10.0.0.0/24で起動する。この10.0.0.0/24に接続するeth0はdhcpにより動的にIPが定まる。一応、このインスタンスに直接アクセスするために、EIPも割り当てておく。
ここで10.0.1.0/24に接続するENIをIP指定（例：10.0.1.11）で作成し、作成したインスタンスにアタッチする。インスタンスでは/etc/sysconfig/network-scripts/ifcfg-eth1（Amazon Linuxの場合）に
DEVICE=eth1 BOOTPROTO=static IPADDR=10.0.1.11 NETMASK=255.255.255.0 ONBOOT=yes TYPE=Ethernet
を記述し、ネットワークを再起動する。これで、このSpotInstanceは固定プライベートIPが使える。
そして、この状態でAMIを作って、以降はこのAMIからSpotIntanceを起動し、同じ固定IPを持つENIをアタッチすればSpotInstanceであっても特定のサブネットに対しては常に同じIPを持つ環境を容易に再現できるようになる。
これで、財布に優しい固定プライベートIP環境ができたので実験がしやすくなりました。Yeah!
これLTネタになるかな？いや、ショボすぎだろ。
ところで
SpotInstanceはm1.mediumってお得感がありますよね。東京リージョンだとこのブログ書いている時点で
| タイプ | オンデマンド | スポット |
|---|---|---|
| m1.small | $0.092 | $0.041 |
| m1.medium | $0.184 | $0.058 |
という価格。割引率もm1.mediumの方がいいですし、$1=\80とすれば、スポットの価格差は１時間あたり1.36円。
オンデマンドのm1.smallより安いし、この価格差ならコスパ的にm1.mediumかなって感じで、m1.mediumのSpotInstanceをよく使ってます。
価格も安定していて、m1.smallだと
な感じですが、m1.mediumだと
な感じ。
まぁたまーに跳ね上がるのはSpotInstanceってことで割り切れば、m1.mediumの方が突然落とされる確率は低そうですね。今後はどうなるかわかりませんが。。。
Amazon VPCに接続するためのVyatta向け設定ファイルを作成するWebツールを作ってみました
さくらのクラウド（β）とAmazon VPCをつなげるテストをいろいろやっているのだけど、毎度Vyattaの設定ファイルとかを書くのが面倒なので、Amazon VPCからダウンロードする設定情報をVyatta向けに変換するツールを作成してみました。
ローカルで使うのであればrubyで多分書くのですが、需要があるか不明ですが他の方にも使いやすいように、Webツールという感じで公開してみました。
http://gen-vyatta-conf.fluxflex.com/
http://gen-vyatta-conf.peachbeach.info/
Javascript のみで完結していて、通信は一切しないのでPSKなどを抜くようなことは一切していません。ちなみに、Javascript はまだ勉強不足なので、いたらないところは多々あると思います、、、ご容赦を！
想定環境
とりあえず自分で試したときの環境は以下のようなイメージです。さくらのクラウド（β）で、Vyatta（6.3）をたてて、プライベートネットワーク（192.168.1.0/24）内にサーバを起動している感じです。このサーバのデフォルトゲートウェイは、Vyattaを向くように設定しておきます。
AWS では、VPC を構築して、その中に EC2 Instance を起動しているという感じとなります。
VPCの構築は以前の記事（さくらのVPSにVyattaを入れて、Amazon VPCにVPN接続 - kikumotoのメモ帳）を参照してください。
使い方
http://gen-vyatta-conf.peachbeach.info/ の使い方を簡単に説明します。
「VyattaでIPSecを利用するネットワークインターフェイス」には、Vyattaがインターネットに接しているネットワークインターフェイスを入力します。上記の図では eth0 となります。
「ローカルネットワーク情報」には、VPNで接続したいローカルネットワークを入力します。上記の図では 192.168.1.0/24 となります。
「Amazon VPC のネットワーク情報」には、Amazon VPCを構築する時に設定したVPC IP CIDR Blockを入力します。上記の図では、10.0.0.0/16 となります。
「Amazon VPCからダウンロードした設定情報」では、Amazon VPCを構築するときに Vendor を Generic としてダウンロードしたIPSec VPNの設定ファイルの内容をそのままコピペします。
以上４つのすべてを入力したら、「作成」ボタンを押します。
そうすると、下側に「Vyatta設定」と「Vyattaパケット転送スクリプト」が出力されます。これらの内容を持つファイルをVyatta内に作成します。ここでは、Vyatta設定を vpc_config.txt、Vyattaパケット転送スクリプトを vpc_setup.sh として保存したとして話を進めます。
Vyatta にて以下のように実行して設定をマージします。（警告の原因はよくわかってません）
$ configure # merge /path/to/vpc_config.txt Warning: file does NOT appear to be a valid config file. Do you want to continue? [no] Y # commit # save # exit
次に、vpc_setup.sh を実行します。
$ sudo sh /path/to/vpc_setup.sh
以上で、VPNで２つのネットワークが接続されるので、例えばさくらのサーバ側から
$ ping 10.0.1.101 PING 10.0.1.101 (10.0.1.101) 56(84) bytes of data. 64 bytes from 10.0.1.101: icmp_req=1 ttl=62 time=10.9 ms 64 bytes from 10.0.1.101: icmp_req=2 ttl=62 time=10.7 ms
とすれば、接続されていることが確認できます。
もちろん、EC2 Instance にもログインできます。
公開サイトについて
http://gen-vyatta-conf.fluxflex.com/ ですが、URLからわかるように fluxflexを使っています。
ソース自体は https://github.com/kikumoto/gen-vyatta-conf-for-vpc にあります。fluxflex の github 連携を使うようにしました。
この fluxflex の github 連携はとっても便利ですね。git pushしたらすぐデプロイされて、サイトが更新されるのでよけいなコマンドの実行が減ってとてもいいです。
2012/06/30 に fluxflex が終了なので DotCloud に移行しました。（2012/06/17）
さいごに
需要あるのか疑わしいですが、使ってもらえるとうれしいです。
Diablo版Swiftインストール：ストレージサーバ編
前回、前々回からの続きで最後にストレージサーバを構築したときの手順をメモしておく。
構成とOS環境
keystone やプロクシサーバと同様。
パッケージインストール
ストレージサーバに必要なパッケージは以下のようにしてインストールした。
# yum install python-greenlet python-netifaces # yum --disablerepo=diablo install openstack-swift-object openstack-swift-account openstack-swift-container xinetd
データ保存ディスクの準備
今回は、/dev/sdb に接続されたディスクにデータを保存する構成とした。そのために、fdisk で /dev/sdb 全体を１つのパーティションをつくり /dev/sdb1 として構成した。
これを以下のように XFS でフォーマットし、マウントしておく。
# yum -y install xfsprogs # mkfs.xfs -i size=1024 /dev/sdb1 # echo "/dev/sdb1 /srv/node/sdb1 xfs noatime,nodiratime,nobarrier,logbufs=8 0 0" >> /etc/fstab # mkdir -p /srv/node/sdb1 # mount /srv/node/sdb1 # chown -R swift:swift /srv/node
rsync
Swiftではデータの復旧などにrsyncを使うので、rsyncに関する設定をおこなっておく。まず、/etc/rsyncd.confを以下の内容で作成。address 部分は各ストレージサーバのIPに対応したものとなる。
uid = swift gid = swift log file = /var/log/rsyncd.log pid file = /var/run/rsyncd.pid address = 192.168.0.101 [account] max connections = 25 path = /srv/node/ read only = false lock file = /var/lock/account.lock [container] max connections = 25 path = /srv/node/ read only = false lock file = /var/lock/container.lock [object] max connections = 25 path = /srv/node/ read only = false lock file = /var/lock/object.lock
サービスと起動させるために、/etc/xinetd.d/rsync を以下のように記述し
service rsync
{
disable = no
flags = IPv4
socket_type = stream
wait = no
user = root
server = /usr/bin/rsync
server_args = --daemon
log_on_failure += USERID
}xinetd サービスを再起動する。
# service xinetd restart
ストレージサーバ設定
/etc/swift に account-server.conf, container-server.conf, object-server.conf を以下の内容で作成。各ファイルのbind_ipが、各ストレージサーバのIPに対応するように記述する。
account-server.conf
[DEFAULT] bind_ip = 192.168.0.101 workers = 2 mount_check = false user = swift log_facility = LOG_LOCAL2 [pipeline:main] pipeline = account-server [app:account-server] use = egg:swift#account [account-replicator] [account-auditor] [account-reaper]
container-server.conf
[DEFAULT] bind_ip = 192.168.0.101 workers = 2 mount_check = false user = swift log_facility = LOG_LOCAL2 [pipeline:main] pipeline = container-server [app:container-server] use = egg:swift#container [container-replicator] [container-updater] [container-auditor]
object-server.conf
[DEFAULT] bind_ip = 192.168.0.101 workers = 2 mount_check = false user = swift log_facility = LOG_LOCAL2 [pipeline:main] pipeline = object-server [app:object-server] use = egg:swift#object [object-replicator] [object-updater] [object-auditor]
ファイルのオーナーを修正しておく。
# chown -R swift.swift /etc/swift
以上で設定ができたので、
# swift-init main start
で起動する。
動作確認
すべてのストレージサーバをセットアップした後、以下のようにして動作確認を行った。
コンテナを作成する。
$ swift -A http://172.16.0.99:5000/v1.0 -U demo -K secrete post folder1
コンテナにファイルをアップする。
$ swift -A http://172.16.0.99:5000/v1.0 -U demo -K secrete upload folder1 file1.txt
コンテナの内容を確認
$ swift -A http://172.16.0.99:5000/v1.0 -U demo -K secrete list folder1
以上で、Diablo版Swiftの環境ができた。
今後は、これをベースにいろいろいじっていきたい。。。けれど、はたして。。。
Diablo版Swiftインストール：プロクシサーバ編
前回の記事 Diablo版Swiftインストール：keystone編 に引き続き、Swift環境として必要となるプロクシサーバを構築した時のメモ。
構成とOS環境
前回の記事の通りであるが、今回はストレージサーバのIP情報も必要となるので、それらについては以下の通り。
| ストレージ１ | 192.168.0.101/24 |
|---|---|
| ストレージ２ | 192.168.0.102/24 |
| ストレージ３ | 192.168.0.103/24 |
| ストレージ４ | 192.168.0.104/24 |
また、各ストレージには /dev/sdb としてデータ保存用ディスクが１つ接続されており、/dev/sdb1 という１つのパーティションのみ存在するものとしている。これについてはストレージサーバ編でも記述予定。
パッケージインストール
プロクシサーバに必要なパッケージは以下のようにしてインストールした。
# yum install python-greenlet python-httplib2 python-netifaces # yum --disablerepo=diablo install openstack-swift-proxy openstack-keystone memcached python-memcached xinetd
openstack-keystone はプロクシサーバが Keystone にアクセスするために利用しているので必要。
プロクシサーバの設定
まずは memcached を起動しておく。
# chkconfig memcached on #service memcached start
/etc/swift/swift.conf の記述。適当な文字列を設定しておく。
[swift-hash] # random unique string that can never change, keep it secret and do NOT lose it swift_hash_path_suffix = hogehoge_2011_10_24_xxxxxx
今回はSSLは使わないので、証明書などの作成は行わなかった。
そのうえで、/etc/swift/proxy-server.conf を以下のように作成した。
[DEFAULT] # Enter these next two values if using SSL certifications #cert_file = /etc/swift/cert.crt #key_file = /etc/swift/cert.key bind_port = 8080 workers = 8 user = swift [pipeline:main] #pipeline = healthcheck cache tempauth proxy-server pipeline = healthcheck cache swift3 keystone proxy-server [app:proxy-server] use = egg:swift#proxy allow_account_management = true account_autocreate = true #[filter:tempauth] #use = egg:swift#tempauth #user_system_root = testpass .admin https://192.168.30.133:8080/v1/AUTH_system [filter:keystone] use = egg:keystone#tokenauth auth_protocol = http auth_host = 172.16.0.99 auth_port = 5001 admin_token = 999888777666 delay_auth_decision = 0 service_protocol = http service_host = 172.16.0.99 service_port = 5000 service_pass = dTpw [filter:swift3] use = egg:swift#swift3 [filter:healthcheck] use = egg:swift#healthcheck [filter:cache] use = egg:swift#memcache memcache_servers = 172.16.0.100:11211
ringファイルの作成
ringファイルの作成は以下のスクリプトで行った。パラメータの説明などはOpenStackの大容量ストレージサービス、Swiftの使い方 − TechTargetジャパン 仮想化が詳しい。
#!/bin/bash export LANG=C set -x cd /etc/swift PART_POWER=10 REPLICAS=3 MIN_PART_HOURS=1 # # (1) Initialize builder files # swift-ring-builder account.builder create ${PART_POWER} ${REPLICAS} ${MIN_PART_HOURS} swift-ring-builder container.builder create ${PART_POWER} ${REPLICAS} ${MIN_PART_HOURS} swift-ring-builder object.builder create ${PART_POWER} ${REPLICAS} ${MIN_PART_HOURS} # # (2) Add devices # # zone 1 swift-ring-builder account.builder add z1-192.168.0.101:6002/sdb1 1 swift-ring-builder container.builder add z1-192.168.0.101:6001/sdb1 1 swift-ring-builder object.builder add z1-192.168.0.101:6000/sdb1 1 # zone 2 swift-ring-builder account.builder add z2-192.168.0.102:6002/sdb1 1 swift-ring-builder container.builder add z2-192.168.0.102:6001/sdb1 1 swift-ring-builder object.builder add z2-192.168.0.102:6000/sdb1 1 # zone 3 swift-ring-builder account.builder add z3-192.168.0.103:6002/sdb1 1 swift-ring-builder container.builder add z3-192.168.0.103:6001/sdb1 1 swift-ring-builder object.builder add z3-192.168.0.103:6000/sdb1 1 # zone 4 swift-ring-builder account.builder add z4-192.168.0.104:6002/sdb1 1 swift-ring-builder container.builder add z4-192.168.0.104:6001/sdb1 1 swift-ring-builder object.builder add z4-192.168.0.104:6000/sdb1 1 # # (3) create ring files (rebalance) # swift-ring-builder account.builder rebalance swift-ring-builder container.builder rebalance swift-ring-builder object.builder rebalance
ここで、オーナの設定をしておく。
# chown -R swift:swift /etc/swift
以上で設定が完了なので
# swift-init proxy start
でプロクシサーバを起動する。
現時点で動作確認する手段が不明なので、とりあえず 8080 ポートが python プロセスにより LISTEN されていればOK。
以上で、プロクシサーバの構築は終了。次回は最後に残ったストレージサーバについて記述予定。
Diablo版Swiftインストール：keystone編
久しぶりにSwiftをさわることなり、以前からバージョンアップもされ、特に認証機能が大きく変わったので、再度インストールを試みたのでそのときのメモ。
今回は、認証機能である keystone のインストールについてメモっておく。参考にしたのは以下のサイト。
- OpenStackの大容量ストレージサービス、Swiftの使い方 − TechTargetジャパン 仮想化
- openstack/keystone · GitHub
- OpenStack Docs: Current
ちなみに、この記事を書いている段階ではまだ各機能の詳細については理解してない。とりあえず、上記サイトを参考にして動かすことだけを目的とした。
構成
今回試した構成は以下のようなもの。
＋ーー［認証サーバ(keystone)］ ［クライアント］ーー＋ ＋ーー［プロクシサーバ］ーー＋ーー［ストレージ１］ ＋ーー［ストレージ２］ ＋ーー［ストレージ３］ ＋ーー［ストレージ４］
ゾーンはストレージノードごとに別々としたので、都合４ゾーンの構成。
なお今回は、すべて http でのアクセスを想定しての設定とした。SSL の場合はまた別途考えるかもしれないけれど。。。
認証サーバとプロクシサーバ（クライアント側に見える）のIPはそれぞれ以下の通りとしている。
| 認証サーバ | 172.16.0.99/16 |
|---|---|
| プロクシサーバ | 172.16.0.100/16 |
OS環境
今回は Scientific Linux 6.1（64bit）を利用した。実際はさくらのクラウド（β）のテンプレートを使ったので特にOS自体のインストールはしていないので、インストール方法は省略。
OpenStack Diablo 版の公開リポジトリが http://yum.griddynamics.net/yum/ にあるので、こちらを利用することにした。その準備として、まず以下のようにリポジトリ情報の元となるrpmをインストールした。
# wget http://yum.griddynamics.net/yum/master/openstack/openstack-repo-2011.3-0.2.noarch.rpm # rpm -ivh openstack-repo-2011.3-0.2.noarch.rpm
その後、diablo-centos, diablo からパッケージを取得するように /etc/yum.repos.d/openstack.repo を以下のように修正した。
[diablo-centos] name=OpenStack Diablo for CentOS baseurl=http://yum.griddynamics.net/yum/diablo-centos enabled=1 gpgcheck=1 metadata_expire=90 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-OPENSTACK [diablo] name=OpenStack Diablo baseurl=http://yum.griddynamics.net/yum/diablo enabled=1 gpgcheck=1 metadata_expire=90 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-OPENSTACK
パッケージインストール
認証サーバに必要なパッケージは以下のようにしてインストールした。
# yum install python-greenlet python-httplib2 # yum --disablerepo=diablo install openstack-keystone start-stop-daemon python-paste-deploy python-setuptools python-webob
keystoneの設定
keystoneの設定は /etc/keystone/keystone.conf に記述する。とりあえず、パッケージからインストールされたそのままを使った。
その後、keystoneを起動。
# chkconfig --add openstack-keystone # chkconfig openstack-keystone on # service openstack-keystone start
keystone が起動したらユーザやリージョンなどの初期データを登録する。このときのデータに少し嵌った。
TechTarget の記事は Diablo-4 の時のもので、このときはServiceを登録しなくてもよかったのか、Serviceの登録コマンドがなかった。このため動作しなかったのだと思うけど、github の情報や動作しなかった時のデバッグログから、Serviceの登録が必須のようであったので、初期データスクリプトを以下のようにし実行した。
#!/bin/bash BIN_DIR=/usr/bin # Tenants $BIN_DIR/keystone-manage $* tenant add admin $BIN_DIR/keystone-manage $* tenant add demo # Users $BIN_DIR/keystone-manage $* user add demo secrete demo $BIN_DIR/keystone-manage $* user add admin secrete admin # Roles $BIN_DIR/keystone-manage $* role add Admin $BIN_DIR/keystone-manage $* role add Member $BIN_DIR/keystone-manage $* role grant Admin admin SWIFT=172.16.0.100 KEYSTONE=172.16.0.99 # Services $BIN_DIR/keystone-manage $* service add swift object-store 'Swift-compatible service' $BIN_DIR/keystone-manage $* service add identity identity 'OpenStack Identity Service' #endpointTemplates $BIN_DIR/keystone-manage $* endpointTemplates add RegionOne 1 http://${SWIFT}:8080/v1/AUTH_%tenant_id% http://${SWIFT}:8080/ http://${SWIFT}:8080/v1/AUTH_%tenant_id% 1 1 $BIN_DIR/keystone-manage $* endpointTemplates add RegionOne 2 http://${KEYSTONE}:5000/v2.0 http://${KEYSTONE}:5001/v2.0 http://${KEYSTONE}:5000/v2.0 1 1 # Tokens $BIN_DIR/keystone-manage $* token add 999888777666 admin admin 2015-02-05T00:00 #Tenant endpoints $BIN_DIR/keystone-manage $* endpoint add admin 1 $BIN_DIR/keystone-manage $* endpoint add admin 2 $BIN_DIR/keystone-manage $* endpoint add demo 1 $BIN_DIR/keystone-manage $* endpoint add demo 2
ちなみに、Diablo のリリース後に keystone/manage/api.py が修正されていて、endpointTemplates の add では service id ではなく service name を記述するようになっている。なので、上記の #endpointTemplates の部分は
#endpointTemplates $BIN_DIR/keystone-manage $* endpointTemplates add RegionOne swift http://${SWIFT}:8080/v1/AUTH_%tenant_id% http://${SWIFT}:8080/ http://${SWIFT}:8080/v1/AUTH_%tenant_id% 1 1 $BIN_DIR/keystone-manage $* endpointTemplates add RegionOne identity http://${KEYSTONE}:5000/v2.0 http://${KEYSTONE}:5001/v2.0 http://${KEYSTONE}:5000/v2.0 1 1
と書くように変更しなければならないようだ。
また、もし設定をミスったりして最初からデータ登録をやり直したい場合は、openstack-keystone を停止後に /var/lib/keystone/keystone.db を削除して、再度 openstack-keystone を開始すればよい。
動作確認
以上で必要最低限の設定までできたので動作確認できる。
# curl -d '{ "auth" : {"passwordCredentials":{"username": "admin", "password": "secrete"}}}' -H "Content-type: application/json" http://localhost:5000/v2.0/tokens
と実行して
{"access": {"token": {"expires": "2011-10-23T23:29:11.643318", "id": "5bb58e2c-dd73-4858-9133-7a0e809146ec", "tenant": {"id": "1", "name": "admin"}}, "serviceCatalog": [{"endpoints": [{"adminURL": "http://172.16.0.100:8080/", "region": "RegionOne", "internalURL": "http://172.16.0.100:8080/v1/AUTH_1", "publicURL": "http://172.16.0.100:8080/v1/AUTH_1"}], "type": "object-store", "name": "swift"}, {"endpoints": [{"adminURL": "http://172.16.0.99:5001/v2.0", "region": "RegionOne", "internalURL": "http://172.16.0.99:5000/v2.0", "publicURL": "http://172.16.0.99/v2.0"}], "type": "identity", "name": "identity"}], "user": {"id": "2", "roles": [{"id": "1", "name": "Admin"}], "name": "admin"}}}
のような出力が得られる。
ポート5001に対しても同様なコマンドを実行して、同様な出力が得られることを確認できる。
その他気づいたこと
# curl http://localhost:5001/v2.0/
のようにして動作確認をするような記述がある。しかし、これを実行するとエラーとなった。
調べた感じでは、rpmパッケージとしてkeystoneを入れると、keystoneコマンドは /usr/bin/keystone というパスに存在する。しかし、/usr/lib/python2.6/site-packages/keystone 配下のソースのいくつかでは
possible_topdir = os.path.normpath(os.path.join(os.path.abspath(sys.argv[0]),
os.pardir,
os.pardir))
という記述がある。おそらく、github のディレクトリ構成そのままで動かす場合は問題ないのだと思うが、rpmパッケージ化により、この部分が機能していないように見える。
なので、とりあえずは
possible_topdir = '/usr/lib/python2.6/site-packages'
とすれば、エラーは起きなくなった。
ただし、今回Swiftを動かした範囲においてはこの修正がなくとも動作はした。
以上で、keyston の設定はおしまい。次回はプロクシサーバについて記述予定。
EC2にSwiftをインストール
分散ストレージ的なものを探していたら、OpenStackにSwiftというS３的なストレージがあることを知ったので、まずはどんなものか知るためにインストールしてみることにした。
そのときのインストールメモ。
インストール時に固定IPがあったほうがSwiftの手順に従いやすかったので、Amazon VPC内にEC2インスタンスをたててインストールしてみた。
対象の Linux は Ubuntu 10.04 で、これは Ubuntu のEC2StartersGuide - Community Help Wiki に載っている AMI を利用した。
手順の基本はChapter 3. Installing and Configuring OpenStack Object Storageの通り。若干、EC2のせい（？）なのか修正したところと、ドキュメント通りではうまくいかなかったところもあったので、その部分をメモっておく。
ちなみに、構成としては
- Porxy 兼 Auth ノード１台（IP: 10.0.0.11）
- Storage ノード５台（IP: 10.0.0.12 〜 16）
というドキュメント通りの構成。
なお、Storage ノードについては、EBS 1GB を /dev/sdb としてアタッチした。
Amzon VPC ではNICそのものに割り当てるIPを指定できるのがいいところですね。もっとも、現状だと東京リージョンにないので、US-east を使用。そのため若干コマンドうつのにストレスを感じつつ作業をしましたが。。。あと、micro 使えないので少しお財布を気にする必要もあり。立ち上げっぱなしは個人としては大変！
Ubuntuのapt設定修正
利用したAMIでは /etc/apt/sources.list で指定されている apt サーバが us-east-1.ec2.archive.ubuntu.com を指していたけれど、少なくとも試した時点ではこのサーバがいなかったので、source.list を結局以下のように記述した。
deb http://archive.ubuntu.com/ubuntu/ lucid main universe deb-src http://archive.ubuntu.com/ubuntu/ lucid main universe deb http://archive.ubuntu.com/ubuntu/ lucid-updates main universe deb-src http://archive.ubuntu.com/ubuntu/ lucid-updates main universe deb http://security.ubuntu.com/ubuntu lucid-security main universe deb-src http://security.ubuntu.com/ubuntu lucid-security main universe
python netifaces でのエラー対策
apt-get install swift openssh-server
でswiftのパッケージをインストールすると、依存関係により python-netifaces というのが入る。
EC2 での問題なのかわからないが、あとあとProxyとかのサーバを起動すると /usr/share/pyshared/swift/common/utils.py で
ValueError: You must specify a valid interface name.
というエラーが発生する。
そこで、少し調べてみた。
$ python >>> import netifaces >>> netifaces.interfaces() ['lo', 'eth0', 'dummy0', 'ifb0', 'ifb1', 'eql'] >>> netifaces.ifaddresses('eql') Traceback (most recent call last): File "<stdin>", line 1, in <module> ValueError: You must specify a valid interface name.
どうやら 'eql' というインターフェイス（？）に対して 'netifaces.ifaddresses' でアドレス情報を取得しようとして失敗しているということがわかった。
この 'eql' という文字列が取得されるのが EC2 のせいなのかどうかわからないけれど、以下のように utils.py にパッチをあてることで無理矢理回避を行った。
--- /usr/share/pyshared/swift/common/utils.py.bak
+++ utils.py
@@ -543,7 +543,9 @@
:returns: list of Strings of ip addresses
"""
addresses = []
- for interface in netifaces.interfaces():
+ interfaces = netifaces.interfaces()
+ interfaces.remove('eql')
+ for interface in interfaces:
iface_data = netifaces.ifaddresses(interface)
for family in iface_data:
if family not in (netifaces.AF_INET, netifaces.AF_INET6):
proxy-server.conf
Proxyノードの設定おいて、proxy-server.conf を記述したけれど、Installing and Configuring the Proxy Nodeの通りだと、後ほどの動作テストのときにうまくいかなった。 Wiki 側の情報（今日見たら、内容が変わっていたので、元情報がない）を見て、[filter:swauth] セクションに以下を記述した。
default_swift_cluster = local#https://10.0.0.11:8080/v1
動作確認前まで
あとはドキュメントの通りでいけた。
ちなみにZoneはノード毎にわけたので、ringにデバイスを追加するときのコマンドは以下のように実行した。
swift-ring-builder account.builder add z1-10.0.0.12:6002/sdb1 100 swift-ring-builder account.builder add z2-10.0.0.13:6002/sdb1 100 swift-ring-builder account.builder add z3-10.0.0.14:6002/sdb1 100 swift-ring-builder account.builder add z4-10.0.0.15:6002/sdb1 100 swift-ring-builder account.builder add z5-10.0.0.16:6002/sdb1 100
