AWS

2013年12月17日

このエントリーをはてなブックマークに追加

S3-backedで一歩先行く使い捨て生活

docker-top-logo

前回に続いてPrivate Docker Registry。前回やり残していた検証、

S3 Storage : 使い捨ての良き友

まだ動作検証してないけども、S3と連携させられる所までは分かっている。

この後の戦略・シナリオは、

  1. s3 config済みのカスタムregistryイメージを作成(Dockerfile経由で)
  2. カスタムregistryコンテナを起動
  3. カスタムregistryイメージをpush

ここまで済ませておけば、必要な時にプライベートregistryコンテナを起動すれば良い。カスタムregistryでさえも、気軽に使い捨てられる。この辺の検証は、また別のエントリで。

残り検証作業をしてみた。

検証環境
  • CentOS 6.5
  • kernel-2.6.32-431.el6.x86_64
  • docker-io-0.7.0-14.el6.x86_64
  • lxc-0.9.0-2.el6.x86_64
  • s3cmd-1.0.1-1.el6.noarch
事前準備:S3 bucket

新規作成でも既存バケットでも、どちらでも良い。s3cmdでバケットを新規作成する場合の例。

$ s3cmd mb s3://private-docker-registry
Bucket 's3://private-docker-registry' created

※本書用にでっち上げたバケット名

事前準備:Dockerイメージ用ファイル

イメージビルド用に必要なファイルを用意/配置しておく。

  1. Dockerfile
  2. config.xml
1: Dockerfile
$ cat Dockerfile
FROM stackbrew/registry

ADD config.yml /docker-registry/config.yml
2: config.xml(docker-registry用)

コンテナイメージに焼き込むdocker-registry用config.xml

# The common' part is automatically included (and possibly overriden by all
# other flavors)
common:
    # Bucket for storage
    boto_bucket: ***s3 bucket名***

    # Amazon S3 Storage Configuration
    s3_access_key: ***s3_access_key****
    s3_secret_key: ***s3_secret_key***
    s3_bucket: ***s3 bucket名***
    s3_encrypt: 1
    s3_secure: 1

    # Set a random string here
    secret_key: ***適切なパスフレーズ***

priv:
    storage: s3
    storage_path: /priv

privターゲットは、環境変数SETTINGS_FLAVOR用で、privでなくても良い。

イメージビルド
$ sudo docker build -t registry.private .
Uploading context 10240 bytes
Step 1 : FROM stackbrew/registry
 ---> 3321c2caa0cf
Step 2 : ADD config.yml /docker-registry/config.yml
 ---> ad03546fac66
Successfully built ad03546fac66
コンテナ作成

今回は -e=SETTINGS_FLAVOR=priv を指定して起動。これにより、private用途の設定内容を指定して起動可能となる。

$ sudo docker run -d -p 5000:5000 -e=SETTINGS_FLAVOR=priv registry.private
411732c40b673a7ef8bfde9c4a696a0446096d30c488b66e6bf790b0caf5b21b
接続テスト
$ curl -v http://localhost:5000/
* About to connect() to localhost port 5000 (#0)
*   Trying 127.0.0.1... connected
* Connected to localhost (127.0.0.1) port 5000 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.0.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: localhost:5000
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: gunicorn/18.0
< Date: Tue, 17 Dec 2013 11:22:17 GMT
< Connection: keep-alive
< Expires: -1
< Content-Type: application/json
< Pragma: no-cache
< Cache-Control: no-cache
< Content-Length: 31
< X-Docker-Registry-Version: 0.6.2
< X-Docker-Registry-Config: priv
<
* Connection #0 to host localhost left intact
* Closing connection #0
"docker-registry server (priv)"

"docker-registry server (priv)" となってる。これにより、SETTINGS_FLAVORがprivである事を確認出来る。

いよいよS3-backed Private Registryにpush

イメージ取得とtag打ちは、前回の作業により既に終わってるものとする。

sudo docker push 127.0.0.1:5000/ubuntu
The push refers to a repository [127.0.0.1:5000/ubuntu] (len: 1)
Sending image list
Pushing repository 127.0.0.1:5000/ubuntu (1 tags)
Pushing 8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c

Pushing tags for rev [8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c] on {http://127.0.0.1:5000/v1/repositories/ubuntu/tags/latest}

clientサイドとしては、何か変化してるのかどうかすら、分からない。

S3バケットを覗いてみる
$ s3cmd ls s3://private-docker-registry/
                       DIR   s3://private-docker-registry/priv/

/priv/ ディレクトリが作成されている。これは "storage_path: /priv" と一致する。

$ s3cmd ls s3://private-docker-registry/priv/
                       DIR   s3://private-docker-registry/priv/images/
                       DIR   s3://private-docker-registry/priv/repositories/

その配下には、 /images/ と /repositories/ が作成されている。

$ s3cmd ls s3://private-docker-registry/priv/images/
                       DIR   s3://private-docker-registry/priv/images/8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c/

その先にはハッシュ値のディレクトリが存在。これの値は、push時にも出力されていたイメージID。

$ s3cmd ls s3://private-docker-registry/priv/images/8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c/
2013-12-17 11:24        78   s3://private-docker-registry/priv/images/8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c/_checksum
2013-12-17 11:23        68   s3://private-docker-registry/priv/images/8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c/ancestry
2013-12-17 11:23       437   s3://private-docker-registry/priv/images/8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c/json
2013-12-17 11:23  71488718   s3://private-docker-registry/priv/images/8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c/layer

遂に実態オブジェクトが現れた。pushの裏側でs3バケットにオブジェクトが正しく登録されていた事が分かる。

気軽に使い捨てる

これだけでは使い捨て感を得られないので、使い捨てしてみる。

  1. private registryコンテナを破棄
  2. 新private registryコンテナを作成
  3. ローカルからイメージを一度削除
  4. 新private registry経由でイメージをpull
private registryコンテナを破棄
$ sudo docker kill 411732c40b673a7ef8bfde9c4a696a0446096d30c488b66e6bf790b0caf5b21b
新private registryコンテナを作成
$ sudo docker run -d -p 5000:5000 -e=SETTINGS_FLAVOR=priv registry.private
febb22cad222594f2158bf240b199deda243bbc976bcf7b956c689b1c3cddffe
新private registryコンテナが起動してる事を確認
$ sudo docker ps
CONTAINER ID        IMAGE                                    COMMAND                CREATED             STATUS              PORTS                    NAMES
febb22cad222        127.0.0.1:5000/registry.private:latest   /bin/sh -c cd /docke   32 seconds ago      Up 31 seconds       0.0.0.0:5000->5000/tcp   evil_brown
イメージ削除前に存在有無確認
$ sudo docker images 127.0.0.1:5000/ubuntu
REPOSITORY              TAG                 IMAGE ID            CREATED             SIZE
127.0.0.1:5000/ubuntu   latest              8dbd9e392a96        8 months ago        128 MB (virtual 128 MB)
ローカルからイメージを削除
$ sudo docker rmi 127.0.0.1:5000/ubuntu
Untagged: 8dbd9e392a964056420e5d58ca5cc376ef18e2de93b5cc90e868a1bbc8318c1c
ローカルにイメージが無い事を確認
$ sudo docker images 127.0.0.1:5000/ubuntu
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
pullしてイメージを取得
$ sudo docker pull 127.0.0.1:5000/ubuntu
Pulling repository 127.0.0.1:5000/ubuntu
8dbd9e392a96: Download complete
再びローカルにイメージが作成された事を確認
$ sudo docker images 127.0.0.1:5000/ubuntu
REPOSITORY              TAG                 IMAGE ID            CREATED             SIZE
127.0.0.1:5000/ubuntu   latest              8dbd9e392a96        8 months ago        128 MB (virtual 128 MB)

無事、復活。

あとがき

private registry構築により、複数リポジトリを扱ってみると、DockerイメージがGitライクに操作出来てる事を再認識させられる。実によく出来てる。

  • 成果物としてDockerイメージリポジトリごと納品するケースも出て来るだろうか
  • S3-backedにしておけばオブジェクトが無くなる心配はほぼ皆無で、心配事を減らせるか

遊べそうな事ばかり増えて行く。

参考文献



編集
@hansode at 22:30|PermalinkComments(0)TrackBack(0)

2011年08月12日

このエントリーをはてなブックマークに追加

動いてた物が動かなくなる

Amazon RDS用の運用スクリプトを書いていた時の出来事。 作業場所を移動して作業を再開したタイミングでエラーが出て動かなくなってしまった。 原因調査の旅の始まり。

エラーメッセージ

<ErrorResponse xmlns="http://rds.amazonaws.com/doc/2010-07-28/">
  <Error>
    <Type>Sender</Type>
    <Code>RequestExpired</Code>
    <Message>Request has expired. Timestamp date: 2011-08-12T02:28:49.000Z</Message>
  </Error>
  <RequestId>04efc58a-c48d-11e0-951b-dfc50e2855f7</RequestId>
</ErrorResponse>
検証環境
  • Ubuntu 10.04.3 Server LTS
  • right_aws 2.1.0
  • ruby 1.8.7p249
  • virtualbox 4.0.2 r72916
  • windows 7 (32bit)
結論から述べれば、実行環境の時間がズレていた

スクリプトの動作的に問題はないはずだと思っていたので、時刻問題だと推測。 時刻を確認してみると、、およそ15分遅れていた。


$ sudo ntpdate -b time.nist.gov
12 Aug 11:45:43 ntpdate[8462]: step time server 192.43.244.18 offset 946.878185 sec

時刻を同期させあとは、スクリプトが期待する動きになった。

あと書き

単なる凡ミス。手元の開発環境だからと言う理由で時刻同期設定をサボっていた自分が悪い。

続きを読む


編集
@hansode at 12:40|PermalinkComments(0)TrackBack(0)

2010年09月27日

このエントリーをはてなブックマークに追加

きっかけは『インスタンスを起動出来ない』と言う報告

ホームディレクトリを整理していたら出て来たスクリプト。

以前、EC2のインスタンスを起動出来ない原因を調査した。
その時の原因は、

pk.pemとcert.pemがペアではなかった事

ごく稀なケース。
複数のキーペアを管理し切れなかった結果なのだろう。

調査報告時に殴り書きしたシェルスクリプトが下記のvalidate-keypair.sh。

▼validate-keypair.sh


#!/bin/bash
#
# http://blog.hansode.org/
#
LANG=C


pk=$1
cert=$2


function usage() {
  cat <<EOS
usage:
 $ $0 [ pk.pem ] [ cert.pem ]
EOS
  exit 1
}

[ -f "${pk}" ] || usage
[ -f "${cert}" ] || usage

function gen_cert_pubkey() {
  openssl x509 -pubkey -in ${cert} -noout
}

function gen_pk_pubout() {
  openssl rsa -pubout -in  ${pk} 2>/dev/null
}

echo "generating cert pubkey..."
gen_cert_pubkey | sed 's,^,D:,'
echo "generated."

echo "generating pk pubout..."
gen_pk_pubout | sed 's,^,D:,'
echo "generated."

echo "validating..."
diff <(gen_cert_pubkey) <(gen_pk_pubout)

[ $? = 0 ] && {
  echo valid
  exit 0
} || {
  echo invalid
  exit 1
}

▼使用例


$ ./validate-keypair.sh pk-a1b2c3d4e5f6.pem cert-a1b2c3d4e5f6.pem

後書き

ファイル名の命名規則からペアであるか、ペアでないかを見分けられる。
通常、pk-*****.pem と cert-****.pem には同じ文字列が含まれている。

運用ルール等により、pk.pemとcert.pemへリネームする必要が出ると、ファイル名から推測出来なくなる。
悪意を持ってペアではないファイル名を、見た目上のペアにする事は可能。

インスタンスを起動出来ない原因追求に役に立てたら嬉しい限り。

続きを読む


編集
@hansode at 15:00|PermalinkComments(0)TrackBack(0)

2010年08月12日

このエントリーをはてなブックマークに追加

wakame-fuel環境構築スクリプト用のリポジトリを作ったをAMI化

wakame-fuel環境構築スクリプトを実行した状態になっている。

▼AWS情報

  • us-east-1
  • ami-b2bc56db
  • wakame-fuel-ami-us/wakame-fuel-0.5.1_ubuntu-10.04_20100811.01.manifest.xml

▼wakame-fuel情報

  • wakame-0.5.1インストール済み
  • wakameユーザー追加済み
  • プロジェクトディレクトリ /home/wakame/wakame.proj/ 作成済み

管理対象が無い

やはり、これもまたwakame-fuelが入っているだけで意味が無いに等しい。
ApacheやNginx、MySQLなどは未インストールなのだから。

普段からwakame-fuel環境構築慣れしている自分には意味がある。
wakame-fuelだけ入った環境をすぐに調達出来て嬉しい場合、それが大半であるのだから。

さあ、この課題をどう解決する?続きは次回へ。




編集
@hansode at 10:50|PermalinkComments(0)TrackBack(0)

2010年08月02日

このエントリーをはてなブックマークに追加

まずはUbuntu-10.04用

作ったキッカケは幾つかある

  • やるべき作業が何か、明確になった
  • そして、毎回同じ作業が面倒臭い
  • 作業者による作業ムラを無くす

使用例

▼検証環境

  • us-east-1
  • ami-2d4aa444
  • ubuntu-images-us/ubuntu-lucid-10.04-i386-server-20100427.1.manifest.xml
  • Ubuntu-10.04 LTS

ひとまず、wakame-fuel環境のみ構築

▼Git未使用

$ cd /tmp

$ wget http://github.com/hansode/wakame-fuel-builder/raw/master/ubuntu/10.04/01_setup-base.sh
$ sudo sh ./01_setup-base.sh

▼Git使用

$ sudo apt-get install git-core
$ cd /tmp

$ git clone git://github.com/hansode/wakame-fuel-builder.git
$ cd wakame-fuel-builder/ubuntu/10.04/
$ sudo ./01_setup-base.sh

5分ほどでwakame-fuel環境構築が完了する。


ベースは出来上がる

ベースだけではwakame-fuelを使う意味が無い。
スケール対象となるシステムが必要だ。

今回は、ここに触れずに終わる。




編集
@hansode at 17:05|PermalinkComments(0)TrackBack(0)

2010年05月21日

このエントリーをはてなブックマークに追加

Amazon EC2特有仕様により、環境構築に苦戦した

忘れないうちに手順をまとめておく。
苦戦要因は、IPアドレスだ。

Amazon EC2には、ローカルIPアドレスと、グローバルIPアドレスが存在する。
インスタンス内ではローカルIPアドレスを使用。

通常、Hinemosマネージャーに指定するのはIPアドレス。
果たして、Hinemosマネージャーに指定するIPアドレスは…?


▼動作実績環境

  • CentOS-5.5(x86_64)
  • Linux 2.6.21.7-2.fc8xen
  • Hinemos 3.1.4


事前作業

▼Security Groupに新グループ追加

  • tcp
    • 1098
    • 1099
    • 3873
    • 4444
    • 4445
    • 4446
    • 4457
    • 8009
    • 8080
    • 8083
    • 24457
  • udp
    • 514

追加したグループを指定し、インスタンス起動する


作業内容

▼必要に応じてインストール


# yum -y update
# yum -y install wget

▼Hinemosマネージャをダウンロード、伸張


# cd /tmp/
# wget 'http://sourceforge.jp/frs/redir.php?m=iij&f=%2Fhinemos%2F45345%2Fhinemos_manager-3.1.4_rhel5_32.tar.gz'
# tar zxvf hinemos_manager-3.1.4_rhel5_32.tar.gz
# cd Hinemos_Manager-3.1.4_rhel5_32/

▼syslog-ngインストール時にエラーになるので、syslog-ng.confのテンプレートを修正


# cp -pi syslog-ng_setup.conf syslog-ng_setup.conf.0
# vi syslog-ng_setup.conf
# diff syslog-ng_setup.conf.0 syslog-ng_setup.conf
21c21
< source s_net { tcp(ip(0.0.0.0) port(514) max-connections(70)); tcp6(ip(::0) port(1514)); udp(ip(0.0.0.0) port(514)); udp6(ip(::0) port(514)); };
---
> source s_net { tcp(ip(0.0.0.0) port(514) max-connections(70)); udp(ip(0.0.0.0) port(514)); };

※EC2のLinuxカーネルがIPv6を使えない為、IPv6アドレスにportをbindする際、起動に失敗する。失敗させないための策。

▼インストールスクリプトを実行


# export LANG=C
# ./manager_installer_EN.sh
Hinemos installation will be started, is that OK?(Y/N default:Y)
>>enter<<

The installation user and the installation directory are created.


User hinemos is created.
Creating mailbox file: File exists
Changing password for user hinemos.
New UNIX password:********
BAD PASSWORD: it is based on a dictionary word
Retype new UNIX password:>>hinemos<<
passwd: all authentication tokens updated successfully.
User hinemos was created.
Installation directory /opt/hinemos was created.

Manager's IP address is set.
Please input IP address of the server which installed Hinemos manager.
[[ Public DNS Name ]]※ここでIPアドレスではなく、Public DNS Nameを指定する
Is it [[ Public DNS Name ]]? (Y/N default:Y)

Please input JBoss boot user name.(hinemos/root default:hinemos)
>>enter<<
hinemos is correct? (Y/N default:Y)
>>enter<<
Start copying required files into the installation directory.
Please input ftp server's IP address needed by corrective run (default:127.0.0.1)
>>enter<<

JRE
Do you agree to the above license terms? [yes or no]
yes
Starting system logger:                                    [  OK  ]

/etc/hosts is changed.
May I change /etc/hosts? (Y/N)
Y

/etc/hosts was changed.
Please confirm it after the end of the installation.

The database is initialized.
waiting for postgres to start...
done
postgres started
ALTER ROLE
waiting for server to shut down.... done
server stopped

LDAP is initialized.
The initialization of LDAP was completed.

Hinemos manager installation was completed.

▼初回起動テスト


# su - hinemos -c /opt/hinemos/bin/hinemos_start.sh
Hinemos starting

waiting for postgres to start...
done
postgres started

waiting for slapd to start...
done
slapd started

waiting for jboss to start...
......................done
jboss started
Hinemos started

▼システム起動時にHinemosが起動するように設定


# cp -pi /etc/rc.local /tmp/rc.local.0
# vi /etc/rc.local
# diff /tmp/rc.local.0 /etc/rc.local
9a10,11
>
> /usr/bin/id hinemos && su - hinemos -c /opt/hinemos/bin/hinemos_start.sh

▼/etc/hostsを修正


# cp -pi /etc/hosts /tmp/hosts.0
# diff /tmp/hosts.0 /etc/hosts
2c2,3
< [[ Public DNS Name ]]      domU-12-34-56-78-AB-90
---
> [[ Internal IPv4 ]]        domU-12-34-56-78-AB-90
> [[ Internal IPv4 ]]        [[ Public DNS Name ]]

インストールスクリプトは、IPアドレス指定を想定しているので、/etc/hostsが不正内容となる。その対応修正。

▼システム再起動


# reboot

▼この後、Hinemosクライアントを利用

  • user: hinemos
  • pass: ********
  • host: jnp://[[ Public DNS Name ]]:1099

ログインに成功したら環境構築成功。


あと書き

Amazon EC2では「Public DNS Name」を上手に利用するべきだと分かった。

  • 内部で名前解決するとローカルIPアドレス
  • 外部で名前解決すると、グローバルIPアドレス
  • ルーティングの関係?で、インスタンス内からグローバルIPアドレスへは通信出来ない
  • 唯一、内外共通で利用出来るのが「Public DNS Name」と言う訳だ

これは別エントリで改めてまとめる予定。




編集
@hansode at 20:25|Permalink
このエントリーをはてなブックマークに追加

自分でシンプル環境を構築しよう

前回は、Xen domU用イメージ作成スクリプトを作った。
今回はAmazon EC2用イメージ作成スクリプトだ。

▼動作実績環境

  • CentOS-5.4(x86_64)
  • Linux 2.6.18-164.15.1.el5xen
  • yum 3.2.22
使用例

▼CentOS-5.5(2010/05/21現在最新)のツリーを作る


$ git clone git://github.com/hansode/vmbuilder.git
$ cd vmbuilder/ec2/redhat/
$ sudo make-domu-tree.sh --dist=centos --ver=5.5 --arch=i386

※ --dist=fedora とすると、fedoraのツリーが構築される。


誰かが作るであろう最新版CentOSのAMIを、もう、待つ必要がない。
次はDebian系のイメージに着手予定。




編集
@hansode at 15:10|PermalinkComments(0)TrackBack(0)

2010年05月06日

このエントリーをはてなブックマークに追加

EBS Backed domUを構築しよう

iSCSIのおかげで手軽にデバイスをattach/detach可能になった。

環境を構築する場合、S3 BackedよりはEBS Backedが便利だ。
そこで、EBS BackedのdomUを構築し、複製から復元を行う。

▼戦略

  1. dom0
    1. iSCSIデバイスに対し、ファイルシステム構築
    2. iSCSIデバイス内に最小構成環境を構築
    3. domUの仮想デバイスとしてiSCSIデバイスを指定し、起動
  2. domU-1
    1. ログイン
    2. ホスト名を記録したファイルを生成
  3. zfs
    1. 起動中domUのVolumeからsnapshotを作成
    2. 作成したsnapshotから、cloneして新規Volume作成
    3. cloneしたVolumeを、iSCSIターゲットとして公開
  4. dom0
    1. cloneして生成したiSCSIターゲットに接続
    2. 新iSCSIデバイスを仮想デバイスとして指定し、新たにdomUを起動
  5. domU-2
    1. ログイン
    2. clone元domUとは違うdomUである事を確認

複製元domU環境

▼domUの種イメージ用ツリーを作成


dom0$ cd /tmp
dom0$ git clone git://github.com/hansode/vmbuilder.git
dom0$ sudo /tmp/vmbuilder/xen/redhat/make-domu-tree.sh --dist=fedora --ver=8 --arch=i386

▼iSCSIデバイスにファイルシステムを構築し、ツリーの内容を同期


dom0$ sudo mkfs.ext3 /dev/sdc
dom0$ sudo /dev/sdc /mnt
dom0$ sudo rsync -avx /tmp/fedora-8_i386/ /mnt/
dom0$ sudo umount /mnt

▼domU-1起動準備


dom0$ cd /home/xen/domu
dom0$ sudo mkdir fc8-ebs-backed-sdc
dom0$ cd fc8-ebs-backed-sdc
dom0$ sudo vi ebs-backed.cfg

▼domU-1用cfg作成


name        = 'fc8-ebs-backed-sdc'
memory      = '256'
vcpus       = 1
bootroader  = '/usr/bin/pygrub'
root        = '/dev/xvda ro'
vfb         = [ ]
disk        = [ 'phy:/dev/sdc,xvda,w' ]
vif         = [ '' ]
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'

▼domU-1起動


dom0$ sudo xm create -c ./ebs-backed.cfg
...(省略)...

▼domU-1にログイン


login: root
domU-1# touch `hostname`

/root/`hostname`として識別可能


domUを量産

▼起動中インスタンスのVolumeからスナップショット作成


zfs$ time pfexec zfs snapshot rpool/ebs/vol-001@`date +%Y-%m-%d-%H:%M:%S`
zfs$ zfs list -t snapshot |grep rpool/ebs
rpool/ebs/vol-001@2010-04-28-18:35:29             0      -   793M  -
zfs$ pfexec zfs clone rpool/ebs/vol-001@2010-04-28-18:35:29 rpool/ebs/vol-001.ebs-backed.clone
zfs$ zfs list |grep rpool/ebs/
rpool/ebs/vol-001                   1.81G   206G   793M  -
rpool/ebs/vol-001.ebs-backed.clone      0   205G   793M  -

▼iSCSIターゲット設定


zfs$ pfexec zfs set shareiscsi=on rpool/ebs/vol-001.ebs-backed.clone
zfs$ iscsitadm list target rpool/ebs/vol-001.ebs-backed.clone
Target: rpool/ebs/vol-001.ebs-backed.clone
    iSCSI Name: iqn.1986-03.com.sun:02:5a2e64d3-ef9b-4404-ed53-90fa4a0b83ae
    Connections: 0
a

▼iSCSI接続


dom0# iscsiadm -m discovery -t sendtargets -p 192.168.1.21
192.168.1.21:3260,1 iqn.1986-03.com.sun:02:8353afa5-f355-61f2-84ee-fac93b2e3eb7
192.168.1.21:3260,1 iqn.1986-03.com.sun:02:5a2e64d3-ef9b-4404-ed53-90fa4a0b83ae
dom0# iscsiadm -m node -l -T iqn.1986-03.com.sun:02:5a2e64d3-ef9b-4404-ed53-90fa4a0b83ae
Logging in to [iface: default, target: iqn.1986-03.com.sun:02:5a2e64d3-ef9b-4404-ed53-90fa4a0b83ae, portal: 192.168.1.21,3260]
Login to [iface: default, target: iqn.1986-03.com.sun:02:5a2e64d3-ef9b-4404-ed53-90fa4a0b83ae, portal: 192.168.1.21,3260]: successful

▼iSCSIデバイス名を確認


dom0# ls -la /dev/disk/by-path/ | grep iqn.1986-03.com.sun:02:5a2e64d3-ef9b-4404-ed53-90fa4a0b83ae
lrwxrwxrwx 1 root root   9 Apr 28 18:44 ip-192.168.1.21:3260-iscsi-iqn.1986-03.com.sun:02:5a2e64d3-ef9b-4404-ed53-90fa4a0b83ae-lun-0 -> ../../sdd
項目内容
IQNiqn.1986-03.com.sun:02:5a2e64d3-ef9b-4404-ed53-90fa4a0b83ae
デバイス名/dev/sdd

▼domU-2起動準備


dom0# cd /home/xen/domu
dom0# mkdir fc8-ebs-backed-sdc
dom0# cd fc8-ebs-backed-sdd
dom0# sudo vi ebs-backed.cfg

▼domU-2用cfg作成


name        = 'fc8-ebs-backed-sdd'
memory      = '256'
vcpus       = 1
bootroader  = '/usr/bin/pygrub'
root        = '/dev/xvda ro'
vfb         = [ ]
disk        = [ 'phy:/dev/sdd,xvda,w' ]
vif         = [ '' ]
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'

▼起動前のdomU一覧確認


dom0# xm list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0  3773     4     r-----    330.9
fc8-ebs-backed-sdc                           2   256     1     -b----     16.1

domUが1つ起動している事が分かる

▼domU-2を起動


dom0# xm create -c ./ebs-backed.cfg

▼domU-2にログイン


login: root
domU-2# 

▼clone元のdomU-1で生成したファイルの存在を確認


domU-2# ls
node184.shinjuku.axsh.intra

▼domU-2のホスト名を確認


domU-2# hostname
node189.shinjuku.axsh.intra

別物出ある事を確認

▼ログイン記録を確認してみると


domU# last
root     xvc0                          Wed Apr 28 18:47   still logged in
reboot   system boot  2.6.21-2950.fc8x Wed Apr 28 18:47          (00:02)
root     xvc0                          Wed Apr 28 18:36 - crash  (00:10)
reboot   system boot  2.6.21-2950.fc8x Wed Apr 28 18:31          (00:17)

wtmp begins Wed Apr 28 18:31:12 2010

起動中にcloneすると、crash扱いされている。



あと書き

以上の様に、あっさり手軽にdomUを複製出来る事が分かる。

今回は起動中domUのVolumeからsnapshot、cloneした。
あらかじめ種Volumeを作っておき、種Volumeをcloneして行けばdomUを手軽に量産可能だ。

まだまだ手作業が多い。
今後は手順を単純化して行く。

続きを読む


編集
@hansode at 15:50|PermalinkComments(0)TrackBack(0)

2010年04月27日

このエントリーをはてなブックマークに追加

続・Amazon EBSに対する基本操作をしてみる

▼戦略

  1. zfs
    1. domUにattach済volumeからsnapshot作成
    2. 作成したsnapshotからcloneを作成
    3. 作成したcloneからvolumeを作成
    4. volumeをiSCSIターゲット化
  2. dom0
    1. iSCSIイニシエータからiSCSIターゲットにログイン
    2. iSCSIデバイスをdomUにattach
  3. domU
    1. domUからattach済volumeをマウント
    2. ファイルシステムの内容確認

snapshot作成

▼snapshot作成前の状態確認


zfs$ zfs list | grep rpool/ebs
rpool/ebs                 1.03G   206G    21K  /rpool/ebs
rpool/ebs/vol-001         1.03G   207G  78.8M  -

この時はvol-001のみ存在している

▼snapshotを作成


zfs$ pfexec zfs snapshot rpool/ebs/vol-001@`date +%Y-%m-%s-%H:%M:%S`

▼作成したsnapshotの状態を確認


zfs$ zfs list -t snapshot |grep rpool/ebs
rpool/ebs/vol-001@2010-04-1272361747-18:49:07      0      -  78.8M  -

「rpool/ebs/vol-001@2010-04-1272361747-18:49:07」が作成された


snapshotからvolume作成

▼snapshotからcloneによりvolumeを作成


zfs$ pfexec zfs clone rpool/ebs/vol-001@2010-04-1272361747-18:49:07 rpool/ebs/vol-001.clone

▼clone後のvolumeの状態を確認


zfs$ zfs list | grep rpool/ebs
rpool/ebs                 1.11G   206G    21K  /rpool/ebs
rpool/ebs/vol-001         1.11G   207G  78.8M  -
rpool/ebs/vol-001.clone       0   206G  78.8M  -

「rpool/ebs/vol-001.clone」が作成された


dom0にiSCSIデバイスを割り当て

▼cloneされたvolumeをiSCSIターゲットに追加


zfs$ pfexec zfs set shareiscsi=on rpool/ebs/vol-001.clone

▼iSCSIターゲットの状態を確認


zfs$ iscsitadm list target
Target: rpool/ebs/vol-001
    iSCSI Name: iqn.1986-03.com.sun:02:8353afa5-f355-61f2-84ee-fac93b2e3eb7
    Connections: 1
Target: rpool/ebs/vol-001.clone
    iSCSI Name: iqn.1986-03.com.sun:02:54f28b67-e6c0-ed9c-e40c-a45aa81c4efa
    Connections: 0

「rpool/ebs/vol-001.clone」がiSCSIターゲットにエントリされている
IQNは「iqn.1986-03.com.sun:02:54f28b67-e6c0-ed9c-e40c-a45aa81c4efa」

▼iSCSIイニシエータからiSCSIターゲットを確認


dom0# iscsiadm -m discovery -t sendtargets -p 192.168.1.21
192.168.1.21:3260,1 iqn.1986-03.com.sun:02:8353afa5-f355-61f2-84ee-fac93b2e3eb7
192.168.1.21:3260,1 iqn.1986-03.com.sun:02:54f28b67-e6c0-ed9c-e40c-a45aa81c4efa

▼iSCSIターゲットに接続


dom0# iscsiadm -m node -l
Logging in to [iface: default, target: iqn.1986-03.com.sun:02:8353afa5-f355-61f2-84ee-fac93b2e3eb7, portal: 192.168.1.21,3260]
Logging in to [iface: default, target: iqn.1986-03.com.sun:02:54f28b67-e6c0-ed9c-e40c-a45aa81c4efa, portal: 192.168.1.21,3260]
iscsiadm: Could not login to [iface: default, target: iqn.1986-03.com.sun:02:8353afa5-f355-61f2-84ee-fac93b2e3eb7, portal: 192.168.1.21,3260]:
iscsiadm: initiator reported error (15 - already exists)
Login to [iface: default, target: iqn.1986-03.com.sun:02:54f28b67-e6c0-ed9c-e40c-a45aa81c4efa, portal: 192.168.1.21,3260]: successful

ログインに成功

▼iSCSIデバイスを確認


dom0# ls -la /dev/disk/by-path/ | grep iqn.1986-03.com.sun:02:54f28b67-e6c0-ed9c-e40c-a45aa81c4efa
lrwxrwxrwx 1 root root   9 Apr 27 19:04 ip-192.168.1.21:3260-iscsi-iqn.1986-03.com.sun:02:54f28b67-e6c0-ed9c-e40c-a45aa81c4efa-lun-0 -> ../../sdd

「/dev/sdd」にマッピングされた


domUにvolumeを割り当て

▼domUに割り当てる


dom0# xm block-attach fc8-001 phy:/dev/sdd xvdd w

/dev/sddを/dev/xvdとして割り当てる

▼domUのデバイスを確認


domU# dmesg |grep xvdd
 xvdd: unknown partition table
domU# fdisk -l /dev/xvdd

Disk /dev/xvdd: 1073 MB, 1073741824 bytes
255 heads, 63 sectors/track, 130 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000

Disk /dev/xvdd doesn't contain a valid partition table

domUにてブロックデバイスとして認識されている

▼マウント前の状況確認


domU# mount |grep /dev/xvd
/dev/xvda on / type ext3 (rw)
/dev/xvdc on /mnt type ext3 (rw)

/dev/xvddはマウントされてない

▼/dev/xvddをマウント


domU# mkdir /mnt2
domU# mount /dev/xvdd /mnt2/

/dev/xvddを/mnt2へマウント

▼マウント後の状態確認


domU# mount |grep /dev/xvd
/dev/xvda on / type ext3 (rw)
/dev/xvdc on /mnt type ext3 (rw)
/dev/xvdd on /mnt2 type ext3 (rw)

/dev/xvddが/mnt2へマウントされた

▼ファイルシステムの内容を確認


domU# ls -la /mnt2
total 30781
drwxr-xr-x  3 root root     4096 Apr 27 18:32 .
drwxr-xr-x 22 root root     1024 Apr 27 19:16 ..
-rw-r--r--  1 root root 10485760 Apr 27 18:32 10m.img
-rw-r--r--  1 root root 20971520 Apr 27 18:32 20m.img
drwx------  2 root root    16384 Apr 27 18:30 lost+found

domU# ls -la /mnt
total 30781
drwxr-xr-x  3 root root     4096 Apr 27 18:32 .
drwxr-xr-x 22 root root     1024 Apr 27 19:16 ..
-rw-r--r--  1 root root 10485760 Apr 27 18:32 10m.img
-rw-r--r--  1 root root 20971520 Apr 27 18:32 20m.img
drwx------  2 root root    16384 Apr 27 18:30 lost+found

domU# ls -la /mnt | md5sum
1722eb2df6ced256bc63506f8f9d195e  -
domU# ls -la /mnt2 | md5sum
1722eb2df6ced256bc63506f8f9d195e  -

/mntと/mnt2の内容が同じ事を確認

▼新volumeに対してファイル操作


domU# cd /mnt2/
domU# time dd if=/dev/zero of=30m.img bs=1M count=30
30+0 records in
30+0 records out
31457280 bytes (31 MB) copied, 0.17256 s, 182 MB/s

real    0m0.238s
user    0m0.000s
sys     0m0.136s

domU# ls -la
total 61537
drwxr-xr-x  3 root root     4096 Apr 27 19:20 .
drwxr-xr-x 22 root root     1024 Apr 27 19:16 ..
-rw-r--r--  1 root root 10485760 Apr 27 18:32 10m.img
-rw-r--r--  1 root root 20971520 Apr 27 18:32 20m.img
-rw-r--r--  1 root root 31457280 Apr 27 19:20 30m.img
drwx------  2 root root    16384 Apr 27 18:30 lost+found

30m.imgが新規生成された。

▼/mntと/mnt2の状態確認


domU# ls -la /mnt | md5sum
1722eb2df6ced256bc63506f8f9d195e  -
domU# ls -la /mnt2 | md5sum
567c65c8a4c6992be86491afadf58f63  -

domU# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/xvda               416484    382754     12226  97% /
tmpfs                   134484         0    134484   0% /dev/shm
/dev/xvdc              1032088     64852    914808   7% /mnt
/dev/xvdd              1032088     95608    884052  10% /mnt2

/mntと/mnt2が別物出ある事を確認出来る


これにより、Amazon EBSの基本操作まで確認出来た。
今後の作業後は、手順を簡略化して行く。

続きを読む


編集
@hansode at 19:30|PermalinkComments(0)TrackBack(0)

2010年04月26日

このエントリーをはてなブックマークに追加

Amazon EBSに対する基本操作をしてみる

そろそろ外堀から内堀へ攻め入る。

▼戦略

  1. dom0
    1. domUを起動
    2. domUに対し、iSCSIデバイスをattach
  2. domU
    1. デバイスを確認
    2. ファイルシステムを構築
    3. マウント
    4. ddでファイルを新規作成
  3. zfs
    1. dedupの変化を観察
  4. domU
    1. デバイスをアンマウント
  5. dom0
    1. iSCSIデバイスをdetach

※attachとdetachの検証だけなら、iSCSIは不用であるが、そこは議論の対象外。



暫定的に最小構成domUを用意

▼サンプルdomU用意ディレクトリ準備


dom0# mkdir -p /home/xen/domu
dom0# cd /home/xen/domu/
dom0# mkdir fc8-001
dom0# cd fc8-001/

▼Fedra Core 8のイメージを用意


dom0# cp /path/to/mntpool/sdc2/fc8_i386_420mb.img ./.

※イメージ構築方法は本題から逸れるので、今回は省略する

▼cfg生成


name        = 'fc8-001'
memory      = '256'
vcpus       = 1
bootroader  = '/usr/bin/pygrub'
root        = '/dev/xvda ro'
vfb         = [ ]
disk        = [ 'tap:aio:/home/xen/domu/fc8-001/fc8_i386_420mb.img,xvda,w' ]
vif         = [ '' ]
on_poweroff = 'destroy'
on_reboot   = 'restart'
on_crash    = 'restart'

「/」パーティションのみの最小構成domU

▼domU起動


dom0# xm create ./fc8_i386_420mb.cfg
dom0# xm list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0  3773     4     r-----     40.0
fc8-001                                      1   256     1     -b----     17.7

▼domUへログイン


domU# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/xvda               416484    382680     12300  97% /
tmpfs                   134484         0    134484   0% /dev/shm

サンプルdomUが起動した



インスタンスに対してEBS Volumeのような操作を行う

▼dom0のiSCSIデバイスをdomUへattach


dom0# xm block-attach fc8-001 phy:/dev/sde xvde w

▼domUでデバイス確認


domU# dmesg | grep xvde
 xvde: unknown partition table

domU# fdisk -l /dev/xvde

Disk /dev/xvde: 1073 MB, 1073741824 bytes
255 heads, 63 sectors/track, 130 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Disk identifier: 0x00000000

Disk /dev/xvde doesn't contain a valid partition table

fdiskの出力結果から、/dev/xvdeとして認識され、1Gである事が分かる。

▼attachしたデバイスにファイルシステム構築


domU# mkfs.ext3 /dev/xvde
mke2fs 1.40.2 (12-Jul-2007)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
131072 inodes, 262144 blocks
13107 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=268435456
8 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376

Writing inode tables: done
Creating journal (8192 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 33 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

▼/dev/xvdeを/mntへマウント


domU# mount /dev/xvde /mnt
domU# mount
/dev/xvda on / type ext3 (rw)
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)
/dev/xvde on /mnt type ext3 (rw)

iSCSIデバイス/dev/sdeは、domUにて、/dev/xvdeが/mntへマウントする所まで成功



domUから操作し、dedupの変化を観測してみる

▼作業前のpool状態


zfs$ zpool list
NAME    SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
rpool   230G  17.9G   212G     7%  1.00x  ONLINE  -

DEDUPは 1.00x

▼/dev/zeroから10Mイメージを生成


domU# cd /mnt/
domU# time dd if=/dev/zero of=10m.img bs=1M count=10
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 0.017983 s, 583 MB/s

real    0m0.021s
user    0m0.000s
sys     0m0.016s

▼iSCSIターゲットにてpoolの状態確認


zfs$ zpool list
NAME    SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
rpool   230G  17.9G   212G     7%  1.69x  ONLINE  -

DEDUPは1.69x

▼/dev/zeroから20Mイメージを生成


domU# time dd if=/dev/zero of=20m.img bs=1M count=20
20+0 records in
20+0 records out
20971520 bytes (21 MB) copied, 0.093933 s, 223 MB/s

real    0m0.114s
user    0m0.000s
sys     0m0.096s

zfs$ zpool list
NAME    SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
rpool   230G  18.0G   212G     7%  2.08x  ONLINE  -

dedupの数値に変化がある事を観測

▼DEDUPの変化履歴

  1. 1.00x
  2. 1.69x
  3. 2.08x

▼detachするため、umount


domU# cd /
domU# umount /mnt

▼domUからVolumeをdetach


dom0# xm block-detach fc8-001 xvde

▼domUからデバイスが取り外された事を確認


domU# ls -la /dev/xvd*
brw-r----- 1 root disk 202, 0 Apr 26 20:50 /dev/xvda

/dev/xvdeが無い事を確認。つまり、detachされた。


次回はSnapshot

続きを読む


編集
@hansode at 21:30|PermalinkComments(0)TrackBack(0)