FAQ

Eucalyptus は Amazon EC2、S3、および EBS を忠実に実装したものですか?

いいえ。Eucalyptus は Amazon のインタフェースの構文をサポートし、(いくつかの例外を除いて) 同じ機能を実装していますが、内部的にはかなり異なっています。もともと Eucalyptus は、拡張可能にすること、そしてとりわけシステム管理者の時間が最も貴重なリソースである研究機関のような環境において、インストールと保守を容易にすることを念頭に置いて設計されています。断言はできませんが、Amazon では主な設計目標をスケーラビリティに置いているはずです。別の言い方をすれば、ユーザー数という意味でのスケーラビリティが最優先され、クラウド内のすべてのクラスタの初期構成をあらかじめ決めておくことができるようなクラウドサービスを想定し、そうしたクラウドサービスのための商用ソフトウェアを (コミュニティが配布するオープンソースソフトウェアツールとしてではなく) 設計することが目的であれば、Eucalyptus は違った形で設計されていたでしょう。

Eucalyptus が Amazon のインタフェースを選んだのはなぜですか?

同じ「バックエンド」インフラを使いながら、複数のクラウド・コンピューティング・インタフェースをサポートできるようにするためです。Eucalyptus チームが開発を始めた時点では、さまざまな選択肢のうちで Amazon が最もドキュメントが整備され、商業的にも最も成功しているように思われたので、まず最初に Amazon のインタフェースを実装することにしました。ただし、インタフェースモジュールは、システムのほかの部分を変更することなく、別のものに置き換えることができます (できるはず、と Eucalyptus チームでは考えています)。

Eucalyptus は一企業の製品ですか?

現在はそうです。ただし、Eucalyptus はカリフォルニア大学サンタバーバラ校 (UCSB) コンピュータ・サイエンス学科の大学研究プロジェクトとしてスタートしました。UCSB の MAYHEM 研究グループの研究者だった Eucalyptus の原作者たちが、開発したソフトウェアを引き続き保守するためのオープンソースによる商業的試みとして共同で設立したのが、Eucalyptus Systems Inc. です。Eucalyptus Systems 社では、オープンソースコアシステムである Eucalyptus のサポートを手段として、エキスパートサービスと製品開発サービスを提供しています。その目的は、Eucalyptus Systems 社を通じて、今後も引き続き機能強化とバグ修正をオープンソースコミュニティに提供することにあります。

Eucalyptus ユーザーがシステムにアクセスするには、クレジットカードが必要ですか?

いいえ。商用クラウドでは、顧客は使用料をクレジットカードで支払います。Eucalyptus では、ユーザーコミュニティがマシンを利用できるような環境で動作するよう設計されており、ユーザーはログインすることによってマシンにアクセスできます。通常、このような環境では、ユーザーアカウンタビリティをシステム管理者が保証する必要があるため、Eucalyptus では、無料で使用できる環境で一般的に使われるインタフェースに似た「クラウド管理者」インタフェースを開発・実装しています。

クラウドユーザーは、Web ベースのサインアップページを使い、クラウド管理者に対して登録を行う必要があります。クラウド管理者は、ユーザーからアクセスの要求があると、アクセスを承認するかどうか決定を求めるメールを受け取ります。メールには要求を承認するリンクと要求を却下するリンクが含まれています。クラウド管理者が下した承認または却下の決定は、アクセスの要求を行ったユーザーにメールで伝えられます。アクセスが承認された場合、ユーザーはパスワードで保護された Web ページから、Eucalyptus で使用するのに必要な暗号化証明書をダウンロードすることができます。

どのようなソフトウェア環境がサポートされていますか?

Eucalyptus は、仮想化に Xen (バージョン 3.*) を使用する Linux システムを対象にしています。Eucalyptus チームでは、i386 および x86_64 RPM ベースのシステム用のバイナリ RPM、および Debian 用パッケージ、Ubuntu 用パッケージをバイナリとソースの両方で提供しているほか、これら以外の一般的な Linux ディストリビューションにインストールできるよう、ソースパッケージも提供しています。

Eucalyptus と Ubuntu の関係は?

Eucalyptus v1.5 は、Ubuntu の 9.04 Jaunty Jackalope リリースの Universe アーカイブにパッケージとして収められています。ほかのディストリビューション向けパッケージとは異なり、Ubuntu だけにこのような特別なパッケージを用意したのは、Ubuntu 9.04 では Eucalyptus の依存関係のすべてがディストリビューションに含まれていて、かつ、これらの依存関係がソースからビルドされたものだからです。その他の (CentOS、openSUSE、Debian 用などの) Eucalyptus パッケージには、すべての依存関係をソースからビルドしたものが含まれているわけではなく、したがってこれらの Eucalyptus パッケージは、バイナリパッケージという扱いになります。

Eucalyptus ではさまざまな技術を組み合わせて使っているので、Ubuntu 用パッケージの作成にはきわめて多くのマンパワーが必要で、Ubuntu のサポートにあたっている企業 Canonical に勤務する Ubuntu メンテナおよび開発者からの多大な協力が不可欠でした。Eucalyptus チームでは、Ubuntu および Canonical 社と密接に協力して Eucalyptus を提供できることを非常に喜ばしく思っており、こうした取り組みをオープンソースコミュニティ全体に広げたいと願っています。

Eucalyptus は最近 KVM でも利用可能になりました。今後、Xen はサポートされなくなるのでしょうか?

いいえ。KVM のサポートは Eucalyptus への機能追加です。Eucalyptus チームは今後も引き続き、Xen と KVM の両方をサポートします。

仮想マシン用「スロット」をすべて割り当ててしまったらどうなりますか?

クラウドコントローラが実装しているサービスレベルアグリーメント (SLA) は、ほとんど骨格だけのシンプルなものです。Eucalyptus チームでは、Eucalyptus を使ったサイトと開発チームがそれぞれ独自に SLA を用意することを想定しています (Eucalyptus チーム自体も試してみたいアイデアをいくつか持っています) が、現在のリリースで提供されているシンプルな SLA では、占有時間に対する制限は一切ありません。このような形の SLA は、Amazon の SLA と似ていますが、Amazon の場合、登録されたクレジットカードへの課金ができなくなると、接続を「タイムアウト」させる点が異なります。

現在のところ、Eucalyptus では Amazon のようなタイムアウトさせる機能は実装していません。したがって Eucalyptus の場合、ユーザーまたはクラウド管理者が実行中のインスタンスを終了させないと、最終的には割り当て可能な VM スロットが不足します。VM スロットが不足すると、ユーザーのリクエストは失敗し、"ec2-describe-availability-zones" コマンドを実行すると、利用可能なインスタンスはありませんというメッセージが表示されます。

Eucalyptus の「アベイラビリティゾーン」とは何ですか?

Amazon では、インスタンスの配置をユーザーがある程度コントロールできるよう、「アベイラビリティゾーン」 (Availability Zone) というものを実装しています。具体的には、障害発生の可能性をそれぞれのアベイラビリティゾーンに限定しておきたい場合、EC2 ユーザーは異なるアベイラビリティゾーンに存在するホストイメージを使用できるようになっています。おそらく Amazon は、複数のインスタンスを別々のアベイラビリティゾーンに置いて互いに隔離することで、障害がすべてのインスタンスに波及すること (停電によって 1 箇所のデータセンター全体が使用不能になる状態など) を避ける手段を講じたのでしょう。

Eucalyptus の抽象化の手法は、Amazon とはいくぶん異なります。各アベイラビリティゾーンは、Eucalyptus クラウド内の独立したクラスタに対応します。このような方式を取ることの利点は、単独のアベイラビリティゾーン内部でのネットワークをはるかに速やかに構築できることです (Eucalyptus のクラスタは、クラスタのプライベートネットワークをネイティブモードで使用します)。ただし、クラウドの配分を複数のクラスタにまたがる形で行う場合、プライベートネットワークを構築するために Eucalyptus が使っている手法では、パフォーマンスの大幅な低下は避けられません。

まとめると、Amazon と Eucalyptus の類似点は、クラウドを独立したアベイラビリティゾーンに配分することで、障害波及の可能性が低減されることです。一方、相違点は、Eucalyptus では各アベイラビリティゾーンが単一の「マシン」(すなわちクラスタ) に限定されるのに対し、Amazon ではアベイラビリティゾーンはもっと広範囲にわたるものだということです。

Eucalyptus の開発に協力することはできますか?

現在のところ、Eucalyptus 内部に対する外部開発者の方々の協力については、バグ修正に限らせていただいています。Eucalyptus はまだ開発の初期段階にあり、この段階で外部開発者の方々と一緒にコードベースを安定させる作業は手間がかかり、不可能です。しかし、バグ修正のパッチは喜んで受け取らせていただきます。このような方法で開発に協力していただける場合は、バグ修正をコードを送っていただく方法について詳しく説明したコードで貢献するにはのページを参照してください。Eucalyptus チームでは、Eucalyptus バージョン 1.X (2009 年 8 月末を予定) の完全な実装を完了した後、コア部分への貢献コードの取り込みを開始することになるでしょう。現時点では、これまでよりも大幅に余裕を持たせたリリース・スケジュールに移行する予定です。

ただし、コア部分をオープンにする前であっても、Eucalyptus プロジェクトに協力していただけるさまざまな方法があり、Eucalyptus チームでもぜひそのような方法での協力をお願いする次第です。特に、Eucalyptus 内部への変更を伴わずに Eucalyptus を使うためのツールの開発は大歓迎です。もしそうしたツールを開発していただいた場合は、開発プロジェクトについて簡単に紹介したページを用意し、そのページへのリンクを追加いたします。

Eucalyptus 開発のロードマップはどうなっていますか?

まず、2009 年夏までにベースラインとなる AWS インタフェース (EC2/S3/EBS) を完成させる予定です。そこに至るまでに、いくつかのメジャーリリースとマイナーリリースを予定しています。この予定は今後も変わるでしょうが、5 月初め時点でのロードマップは次のとおりです。2009 年 4 月 23 日に、Ubuntu とともにバージョン 1.5 (v1.5) がリリースされました。2009 年 5 月 8 日、1.5 のリリース以降に見つかったいくつかの問題を修正したマイナーリリースを v1.5.1 としてリリースしました。1.5 系列では、バグ修正を主体としたマイナーリリースを、少なくとももう一つリリースする予定です (v1.5.2)。このマイナーリリースは、6 月中旬に出したいと考えています。もしこのリリースが 1.5 系列の最後のマイナーリリースになるなら、8 月末にメジャーリリース (v1.6) を行い、(できれば) これをもってバージョン 1.X 系列の最後のリリースにしたいと考えています。

リリースに関する Eucalyptus チームのスタンスは、次のとおりです。マイナーリリースでは、バグの修正を行いますが、サポートされている機能や内部データ構造を大幅に変更することはありません。メジャーリリースは重要なリリースで、しばしば複数の Eucalyptus 内部サブシステムの大幅なリファクタリングを伴います。

Eucalyptus のインストール中または使用中に問題に遭遇しました。どうすれば問題を解決できますか?

まず、トラブルシューティングのページを参照してください。

トラブルシューティングのページで問題を解決できなかった場合は、ディスカッション・フォーラムに投稿し、遭遇した問題についてできるだけ詳しく説明してください。

  • たとえば、インスタンスの実行に関して問題があるなら、$EUCALYPTUS/var/log/eucalyptus にあるクラウドコントローラのログ (cloud-debug.log)、クラスタコントローラのログ (cc.log)、およびノードコントローラのログ (nc.log) の該当する部分を添付すると、問題の解決に結び付く可能性があります。
  • また、ネットワークに関する問題については、まずネットワークの構成のページを参照したうえで、ネットワーク構成についてできるだけ詳しく説明してください。

Eucalyptus で使うイメージはどうやって作成するのですか? AMI と EMI はどう違うのですか?

v1.4 現在、Eucalyptus のイメージは、Xen が使用するイメージ (ディスクパーティション) と同義です。Xen でイメージ、カーネル、ramdisk の組み合わせを使用できる場合は、Eucalyptus でも同じ組み合わせで動作させることができるはずです (もっと言えば、Eucalyptus でバンドルやアップロードのプロセスを実行する前に、イメージ、カーネル、ramdisk の組み合わせがきちんと動作するかどうかテストすることを推奨します)。

Eucalyptus では EC2 で使われている方法を踏襲しており、VM は 3 つの SCSI ディスクが次のような構成になっていることを前提にしています。

  • sda1: ルート・パーティション (ここに EMI がアタッチされます)
  • sda2: "ephemeral (一過性)" パーティション (追加のストレージとして使われます)
  • sda3: スワップ・パーティション

この前提を満たすためには、上のレイアウトをまねてルート・パーティションを変更する方法と (Eucalyptus チームはこの方法を推奨します)、ディスクレイアウトなどの VM パラメータを決めている Eucalyptus スクリプト (gen_libvirt_xml) に修正を加える方法があります。いずれの方法でも、前提を満たせば、どの Xen イメージも動作するはずです。

Eucalyptus で使いたい AMI があるときは、目的の AMI をダウンロードすることができ、これをバンドルできる必要があります。次に、そのイメージで動作するカーネルと ramdisk の組み合わせを見つける必要があります (EC2 からカーネルをダウンロードすることはできません)。繰り返しになりますが、この場合もまず、Eucalyptus に組み込まれていない Xen で動作するかどうか確認することを推奨します。

詳細については、ディスカッション・フォーラムの次のスレッドを参照してください。

root 以外のユーザーが Eucalyptus を再起動できるようにすることは可能ですか?

そのようにする必要はまったくありません。ただし、参考として Simon が投稿した解決策を参照してください。

Eucalyptus を 1 台のマシンで実行することはできますか?

できますが、一部の機能は利用できません。

  • 動作するネットワークモードは、SYSTEM モードと STATIC モードだけです (この 2 つのモードの制限事項もすべて適用されます)。
  • EBS インタフェースのサポートは利用できません。

ノードとの間で鍵を同期化する必要はありません (ノードコントローラが 1 つしか存在せず、しかもそのノードコントローラがローカルマシンだからです)。

"ETag from S3 did not match computed MD5 (S3 からの ETag が、計算された MD5 と一致しませんでした)" というエラーが表示されるのですが?

おそらく Ubuntu Jaunty のリポジトリからダウンロードしたバージョンの Eucalyptus に対して Euca2ools を実行した可能性が高いと思われます。該当する Eucalyptus のバージョンは v1.5.0 です。一方、Euca2ools では、少なくとも Eucalyptus は v1.5.2 である必要があります。Ubuntu Jaunty からダウンロードした Eucalyptus を使う手順については、Ubuntu Jaunty での Eucalyptus の使用に関するコミュニティ wiki を参照してください。代替策として、Eucalyptus を v1.5.2 にアップグレードする方法もあります。