第22回：Eucalyptusの仕組み(2)

インスタンスの起動処理の流れ

　この流れに沿って、各コンポーネント上での処理を説明していきます。

■(1) ユーザがCLCにインスタンスの起動を要求

　CLCはユーザからのインスタンス起動の要求を受けつけると以下のチェックを行ないます。

　　・ユーザの正当性をチェック
　　・起動要求の内容の正当性をチェック
　　・起動するインスタンスに見合ったリソースの空きに関するチェック

　リソースの空きは、指定されたVM Typesの空きがあるか、利用可能なPublicIPの空きがあるか、などをチェックします。
チェックした結果がエラーの場合はユーザにエラーを返し、問題がなければ次の処理へと進みます。

　なお、起動処理の流れとは関係ありませんが、CLCは自身のクラウドにおけるリソースの空き状況を把握するために20秒毎に各CCにリソース情報の問い合わせを行っており、CCは自身のクラスターにおけるリソースの空き状況を把握するために6秒毎に各NCに対してリソース状況の確認を行なっています。

各コンポーネントにおけるDescribeResources

■(2) CLCがCCにインスタンスの起動を要求

　CLCがCCにインスタンスの起動を要求する際に以下の情報を渡します。

・マシンイメージなどの情報
・インスタンスタイプ
・キーペアの情報
・セキュリティグループなどの情報

　CCは各NCのリソース状況やEucalyptusの設定値に従いインスタンスを起動するNCを選択し、CLCにはプライベートIPとMACアドレスとNCの情報などを返します。

　CCから情報を受け取ったCLCはパブリックIPの割り当てをCCに要求します。

　なお、CCがNCを選択する際にはeucalyptus.confに設定されているSCHEDPOLICYに従います。SCHEDPOLICYについては本連載の第6回でも少し触れていますが、SCHEDPOLICYに設定できる値はGREEDYとROUNDROBINとPOWERSAVEがあります。

　GREEDYは1つめのNCのリソースが枯渇するまでそのNCでインスタンスを起動し、リソースが枯渇したら次のNCを使うようなスケジュールポリシーです。ROUNDROBINは各NCで順番にインスタンスを起動していくスケジュールポリシーで、Eucalyptusではこれがデフォルト値です。POWERSAVEはインスタンスが起動していないNCを停止させ、リソースが必要になったらWake-on-LANでNCを起動させるスケジュールポリシーですが、これはUbuntuでのみ動作します。

インスタンス起動のスケジュールポリシー

■(3) CCがNCにインスタンスの起動を要求

　CCはNCにインスタンスの起動要求を行なう前処理として、当該セキュリティグループに関する仮想ネットワークが存在するか否かをチェックし、もし該当する仮想ネットワークが存在しない場合は以下のように仮想ブリッジやVLANデバイスを作成します。これらについては短期集中連載「ユーカリプタスに学ぶ！IaaSクラウドを支えるサーバ・インフラ技術」の第2回に詳しいことが書かれていますので、併せてお読みください。

セキュリティグループ毎の仮想ネットワーク

　仮想ネットワークを作成し、CCがNCにインスタンスの起動を要求する際には以下の情報を渡します。

・マシンイメージに関する情報
・インスタンスタイプ
・キーペアの情報
・タグVLANのIDとPrivateIP用のMACアドレス

　NCにインスタンス起動要求が受け入れられたら、CCはCLCから受け取ったPublicIPをPrivateIPと関連付けるルールをiptablesに設定します。一方、命令を受け取ったNCは起動するインスタンス分のリソースを自身の空きリソースから減じて次の処理に進みます。

■(4) NC上でのマシンイメージ処理

　NCはインスタンスの起動要求を受け付けたら、要求されたマシンイメージが自身のキャッシュに存在するかチェックします。マシンイメージがキャッシュ上に存在しない場合はWalrusから以下のデータをダウンロードします。

・マシンイメージ(EMI,EKI,ERI)のマニフェストファイル
・マシンイメージ(EMI,EKI,ERI)

　なお、Walrusからマシンイメージのマニフェストファイルを取得するときはS3 APIのGetObjectを使用しますが、マニフェストに記述されたマシンイメージを取得する場合はWalrus固有 APIのGetDecryptedImageを使用します。

　このGetDecryptedImageは、文字どおり復号されたマシンイメージを要求しますが、Walrus上に復号されたマシンイメージがキャッシュされていない場合はWalrus上で復号処理が実施され、NCは復号処理が終るまでダウンロード処理を(10回まで)リトライし続けます。

　このときにあまりにも復号処理に時間がかかりすぎてリトライ要求の限界値を超えた場合は、ダウンロードがエラーとなり、インスタンスの起動処理は中止されます。ちなみにダウンロードのリトライ間隔は初回の4秒を起点に倍数で増やす仕組みになっており、1回目4秒、2回目8秒、3回目16秒……10回目2048秒となり合計で68分12秒となります。

　マシンイメージがダウンロードされたら、NCはインスタンスを起動する前にダウンロードしたマシンイメージをNC上のキャッシュに登録します(「登録」と言っても実際の処理はファイルのコピーです)。もしNC上のキャッシュがeucalyptus.confのNC_CACHE_SIZEで指定した値に逹っした場合は古いキャッシュファイルから削除され、新しいマシンイメージがキャッシュに加えられます。なお、ここの処理は「Eucalyptusのインスタンス起動で時間がかかる処理ワースト4」の1つになります(もう1つは前述のWalrus上での復号処理で、あと2つは後述します)。

　もしマシンイメージがNCのキャッシュ上に存在する場合は、Walrusからはマニフェストファイルのみダウンロードされ、NC上のキャッシュファイルの完全性をチェックします。キャッシュファイルが破損および改竄されていない場合はキャッシュからインスタンスデータの格納場所にコピーされます。このコピー処理も「Eucalyptusのインスタンス起動で時間がかかる処理ワースト4」の1つになります。

NC上でのマシンイメージ処理(ダウンロード版)	NC上でのマシンイメージ処理(キャッシュ版)

■(5) NCでのインスタンス起動処理

　NCはマシンイメージの処理が終ったのち、キーペアのSSH公開鍵をマシンイメージ(EMI)の/root/.ssh/authorized_keysに追加します。ちなみに、「なぜこのような処理をしているのか？」と不思議に思われるかもしれません。

　Eucalyptusでは、メタデータを使用できるのはMANAGEDモードとMANAGED-NOVLANモードのみであるため、SYSTEMモードやSTATICモードを利用する場合はAmazon EC2のようにメタデータからSSH公開鍵を取得するような仕組みをインスタンスに施すことができません。そのためこのような仕組みで対処するような作りになっています。

　次に、NCはswapディスクとephemeralディスクの準備を行ないます。このときNCはswapおよびephemeralディスクをddコマンドでraw形式なファイルとして作成を行ないますが、この処理も「Eucalyptusのインスタンス起動で時間がかかる処理ワースト4」の1つになります。

　というのも、swapディスクはデフォルト値が512MBですのでeucalyptus.confの設定値を変更しない限りは作成に時間を要しませんが、ephemeralディスクは連載第6回でも書きましたが、指定されたVM Typesの値とマシンイメージなどの情報を基に以下のようにサイズを算出し、その算出されたサイズのファイルを作成するため、場合によっては数GBから数十GBのファイルをddで作成することになります。

インスタンスのディスクを構成する各領域の計算式

　インスタンスデータの格納場所にこれら各種ファイルが準備できたら、NCはlibvirtで起動するためのxmlファイル(libvirt.xml)を生成し、それを以ってlibvirtにインスタンスの起動を命令します。libvirtおよびハイパーバイザーがインスタンスを起動する仕組みについては短期集中連載「ユーカリプタスに学ぶ！IaaSクラウドを支えるサーバ・インフラ技術」の第1回および第5回を参照してください。

■(6) インスタンス上での起動処理

　インスタンス上で起動処理が始まる頃にはCLCは既にインスタンスの状態をpendingからrunningに遷移させていますが、当のインスタンス自身はまだ起動処理中ですので、CLC上でrunningに遷移したからと言ってすぐにインスタンスに接続しようとするとコネクションエラーなどになる可能性があります。CLC上でrunningになっても一呼吸おいてから接続するとよいでしょう。

　そして、当のインスタンスは自身の起動処理の中でCCのDHCPサーバからPrivateIPのアドレスを取得します。

■次回はセキュリティグループの設定などを

　今回はユーザがインスタンスを起動した際の処理の仕組みについて解説しました。次回はセキュリティグループの設定をした際の処理の仕組みなどについて解説します。

　なお、最近はあまり新しいマシンイメージを増やせていないマシンイメージ工房ですが、直近ではUbuntu 11.04のマシンイメージを追加しました。

　Eucalyptus環境をUbuntuで構築している方には別段珍しくも何ともないマシンイメージですが、CentOS 5.x系 + Xenで構築している方は自前で用意する必要があったため、マシンイメージ工房で提供するようにしました。もしマシンイメージについてご意見やご要望があれば筆者もしくはJEUGのMLにポスト頂けると幸いです。

羽深 修	Eucalyptus歴はまだ1年ですが、周囲からはEucalyptus中毒と勘違いされているようです。Japan Eucalyptus User Groupの活動に参加し、オープンソースカンファレンスでネタなどを披露しています。度々Eucalyptusへのパッチも書いてます。ちなみに仕事ではCentOS + Xenという環境でEucalyptusを利用していますが、自宅のEucalyptus環境はGentoo Linux + KVMで動かしています。
志田 隆弘	主にEucalyptusやクラウドとはあまり関係のない分野でちょこちょこと活動していました。Eucalyptusはバージョン 1.3の頃からいじり始め、かれこれ2年近くEucalyptusに浸かった生活をしています。Eucalyptus 1.4が出たタイミングで、Tanacasinoという名前のGUIクライアントを作ったりしていました。最新のEucalyptusで動作するので、ぜひ使ってみてください。
田中 智文	志田さんとともに初期の頃からEucalyptusの調査・検証・使用してきました。志田さんの作成したTanacasinoのメンテナンスと機能拡張を行っています。新婚ほやほやなので家でのハック活動時間が少ないですが、Walrus Clientを作ってみたりbotoを使ってEucalyptusを操作して遊んでいます。