Ubuntu Enterprise Cloudを試してみる

GW期間中にデスクトップをUbuntu 10.04 LTSに更新してから、Ubuntu Enterprise Cloud (UEC)環境も10.04を新規にインストールして、Eucalyptus 1.6.2ベースに以降しました。

システム構成

ありあわせのシステムなので、 prerequisitesを完璧にはカバーしていません。

Node Controller(NC)にはSocket AM2 + Phenom X4 9350eベースのシステムで、こちらはおおよそ推奨環境を満しています。それ以外のCloud Controller(CLC)やCluster Controller(CC)、Walrusといったシステムを含むシステムはSocket 754 + AMD MT-37ベースのシステムでHDDは最低40GB, 推奨100GBのところ60GB、メモリは最低2GBのところ、1GBしか積んでいません。

Muninで負荷を観察する限りはCCノードのメモリ不足はいまのところ顕在化していませんが、 管理系のノードにもそれなりのスペックが要求されているのは気をつけるところかもしれません。

トポロジー

図のように、CCと同じLANセグメントにあるシステムからはNCに対するルーティングがありません。 UECをデフォルトのまま入れると、このCCとNCをつなぐLANに対してはDHCPを想定した設定が行なわれます。

今回のようにCCとNCのみが存在するネットワークを構成する場合には、CCを導入した後で手動で/etc/network/interfacesを変更してIPアドレスを割り振っておく必要がありました。

管理系ネットワークにもDHCPやらDNSやら配置するかはセキュリティを考慮するとMACアドレス管理と組み合せる事を考えると手間がかかるので、台帳ベースで静的にIPアドレスを割り当てても元が取れそうです。 インストール時にパブリックネットワーク以外のNICも構成できると良かったかもしれません。

Ubuntu 10.04 LTSのデスクトップからElasticFoxを使ってみる

手元のデスクトップはUbuntu 8.04からのアップグレードで、昔からの設定がいろいろと残っています。

インスタンスの起動

インスタンスには"Extras"に並んでいる euca-debian-5.0-i386.tar.gz をベースとしました。 このアーカイブに含まれるファイルの導入自体は 以前投稿した「@IT::Ubuntuで始めるクラウドコンピューティング」にある通りです。

debian.5-0.x86.imgの中の変更方法

イメージファイルを使ってみて不具合や機能を追加したい場合には、linuxデスクトップで中身を変更してUECに追加登録することができます。 loopbackデバイスとして導入すれば良いので、/mntなど任意の場所にマウントすることができます。

/mnt直下を使うといろいろマウントする時に不便なので、/mnt/loopディレクトリを作成することにします。

$ sudo mkdir /mnt/loop

またイメージファイルのバックアップがないと困る場合が多いので、コピーを作成して変更してからUECに登録することにします。

$ sudo cp debian.5-0.x86.img debian.5-0.x86.20100506.img
$ sudo mount -o loop debian.5-0.x86.20100506.img /mnt/loop

例えばapt-getで最新のパッケージを導入したければ次のようにすることができます。

$ sudo chroot /mnt/loop
$ sudo apt-get update
$ sudo apt-get upgrade

apache2など、パッケージによっては/procや/sysがないのでプロセスの起動に失敗する場合もあります。 ですが、いまのところは/procをmountしなければいけない場面には遭遇していません。

使い終ったら$ sudo umount /mnt/loopで作業を完了しますが、/mnt/loopをカレントディレクトリとしてdaemonが起動したり、/proc, /sysがマウントされていたりするとumountに失敗します。 問題がある場合は、$ cd ~/は基本として、lsofなどを使って/mnt/loopに関連するプロセスを停止したり、/procをumountするなどする必要があります。

/procがマウントされていることは発見の方法が、いまのところなさそうなので

この点を踏まえて、使い易くするための変更をいろいろ加えていこうと思います。

/tmpのパーミッション変更

インスタンスを起動して一般ユーザで操作をしているとエラーになるタイミングがあったので、調べてみると/tmpに書き込み権限がありませんでした。 /var/lock や /var/tmp は正しく1777になっていました。

debian.5-0.x86.imgに含まれる/tmpのパーミッション

drwxr-xr-x  4 root root  4096 2009-10-19 06:18 /tmp

この部分はimgファイルを/mnt/loopにマウントして次のようなコマンドで1777に設定します。

$ sudo chmod 1777 /mnt/loop/tmp

スワップ領域の設定

NCの/etc/eucalyptus/eucalyptus.confにSWAP_SIZEを明示的に設定しなくても、デフォルトで512MBの領域が/dev/sda3に作成されています。

この領域をデフォルトで有効にするために/etc/fstabファイルを編集することにします。

変更前のdebian.5-0.x86.imgに含まれる/etc/fstabファイル

/dev/sda1        /             ext3     defaults,errors=remount-ro 0 0
proc             /proc         proc     defaults                   0 0

変更後のdebian.5-0.x86.imgに含まれる/etc/fstabファイル

/dev/sda1        /             ext3     defaults,errors=remount-ro 0 0
proc             /proc         proc     defaults                   0 0
/dev/sda3        none          swap     sw                        0 0

largeインスタンスへの対応 - /ファイルシステムの拡張

インスタンスを起動すると/ファイルシステムに1GBしか割り当てられていません。 /dev/sdaディスクのサイズ自体は”Configuration”から変更できるのですが、空き領域は/dev/sda2としてしかアクセスすることができません。

/appなどのマウントポイントを作成して/dev/sda2をマウントすることもできますが、Javaパッケージなどを導入すると/が足りなくなるので、できれば/dev/sda1を拡張したいところです。

自分が使うディスクに合せて、例えば5GBのディスクを割り当てて、'/'ファイルシステム(/dev/sda1)として4GBを使いたいといった場合には、次のように別のimgファイルに内容をコピーすることで対応できます。

$ dd if=/dev/zero of=debian.5-0.x86.20100506.4gb.img bs=1024 count=4196k
$ sudo mke2fs -j debian.5-0.x86.20100506.4gb.img
$ sudo tune2fs -c 0 -i 0 debian.5-0.x86.20100506.4gb.img

mke2fsは間違いの防止のためブロックデバイスでない場合には警告を表示します。 ファイルの内容を初期化しても問題ないか、ファイル名を確認してから'y'を入力します。

mke2fs実行時の確認メッセージ

$ sudo mke2fs -j debian.5-0.x86.20100506.4gb.img
mke2fs 1.41.11 (14-Mar-2010)
debian.5-0.x86.20100506.4gb.img is not a block special device.
Proceed anyway? (y,n) y
...

こうやって作成したext3ファイルシステムのイメージを/mnt/loop2にマウントします。

$ sudo mkdir /mnt/loop2
$ sudo mount -o loop debian.5-0.x86.20100506.4gb.img /mnt/loop2

あとは/mnt/loopにdebian.5-0.x86.imgなど元になるイメージをマウントしてから、内容をコピーします。

$ sudo rsync -av /mnt/loop/. /mnt/loop2/.
$ sudo umount /mnt/loop
$ sudo umount /mnt/loop2

これで4GBのイメージファイルができたので、swapの分も合わせて5GBほどのディスクを割り当てたインスタンスで起動することができるようになります。

/dev/sda2も便利な場合があると思います。 ただ1GBでは導入できるパッケージの数が低めに抑えられてしまうので2〜4GBのインスタンスイメージは準備しておいて損はないでしょう。

UEC環境の活用の方法

インスタンスをある程度操作できるようになれば、自動化スクリプトなどを配置しておく事も可能になります。 Walrusのディスクは任意のデバイスとして割り当てる事ができるので、あらかじめ必要なファイルを配置しておき、/dev/sdbが存在すれば監視系を導入して、/dev/sdcが存在すればWebサーバになるよう構成を変更する、といったことも可能でしょう。

いいかえると環境があるだけでは、揮発性のインスタンスイメージをいくつ起動しても本番領域としてはなかなか使えないという事になります。

UEC環境にCLC, CCサーバが存在するように、NCサーバの他にも監視系などはUEC外部に構築するといった設計が必要になるでしょう。 更新時期が近づいた既存のインフラをUECに置き換えることはお勧めですが、バランスよく対象を選定しないと障害でシステムが停止した途端に、データはあるけど、実は復旧できないシステムをUEC環境上に構築してしまうかもしれません。

ここら辺がPrivate Cloudさえもプラットフォームとして外部から提供される状況を招いているのかもしれませんが、ある程度の規模のデータセンタを持っているのであれば自社の中で技術力を保持するためにもPrivate Cloudの運用は良いトレーニングになるかもしれません。

あとは何らかの共有ファイルシステムも必要です。 HadoopのHDFSは用途が限定されるので、CCサーバを中心としてOCFS2が使えないかアイデアを試そうとしています。

使えるまでの環境をどうやって作っていくのかが腕の見せどころなのかもしれません。