![[PukiWiki]](image/eucalyptus-j.png "[PukiWiki]")
※公式FAQに掲載されている日本語訳です。
いいえ、違います。Eucalyptus は構文として（文法的に） Amazon が提供するサービスのインターフェースをサポートしており、ほぼ同じ機能を実装しています（少数の例外はありますが）。しかし、内部的には明らかに異なる構造です。
Eucalyptus の元々の設計は、拡張可能であり、簡単にインストールができ、メンテナンスも楽で、とりわけ研究環境でシステム管理者が、貴重な時間を研究に費やせるようにしたものでした。私たちの方向性が確定しない間に、Amazon が提供するサービスの最終形は、ほとんどがスケーラビリティに向けられます。
もしかすると、多くの優れたユーザがスケーラビリティを求めることができるような、クラウドサービスを実現するための商用ソフトウェアを開発するすることもできたでしょうし、やろうと思えば、クラスタ群を初期状態で特定のクラウド環境に接続するよう制御することも（コミュニティ向けに配布しているオープンソースのソフトウェアに対してさえも）できたでしょう。ですが、私たちはそのような手法をとりません。
目的は、同じバックエンド(back end)環境で、複数のクラウドコンピューティングのインターフェースを利用できるようにするためです。Amazon のインターフェースを採用するのは、私たちが開発を開始した時点で実用環境にあったクラウド環境であり、それが最も商業的に成功を収めていたからです。とはいえ、インターフェース・モジュールに関しては、システムに影響を与えることがなく置き換えることができるようになる予定です（と、私たちは願っています）。
今のところは、はい、その通り製品ですが、元々はカリフォルニア大学サンタバーバラ校(UCSB)のコンピュータ・サイエンス学部での研究プロジェクトとしてスタートしたものです。その Eucalyptus の原形を開発した UCSB の MAYHEM 研究グループの研究者たちが Eucalyptus Systems（ユーカリプタス・システムズ）社を共同設立しました。オープンソースであるソフトウェアを商業的に保守できるよう努めるためにです。
Eucalyptus Systems はオープンソースを中核とするシステムをサポートします。そのための手法として、専門的なサービスの提供を商業的に行いつつ、製品開発を行います。Eucalyptus Systems 社としての目的は、オープンソースコミュニティを通して、継続的な Eucalyptus の提供・拡張・バグ修正を行うことです。
いいえ、Eucalyptus では必要ありません。対して、一般的な商用クラウド環境では、利用者はサービス利用料の支払いにクレジットカードを用いる必要があります。
Eucalyptus はユーザコミュニティにログインすることにより、マシン環境が利用可能になるように設計されています。Eucalyptus では、料金を必要とせず日常の管理ができるように "cloud administrator"(クラウド・アドミニストレータ／クラウド管理者)というインターフェースを備えています。これにより、クラウド環境の管理者が、利用者をより確実に管理できるようになります。
クラウド利用者は、cloud administrator というウェブベースの登録ページを使ってユーザ登録を行う必要があります。ユーザ登録希望者がいる場合、クラウド管理者へは登録を希望している旨のメールが送信されます。メールには、リクエストを受け付けるか拒否するかのリンクがはられています。管理者による承諾結果は、希望者に対してメールで返信が送られます。承認された場合は、希望者が Eucalyptus を利用できるように、パスワード保護されたウェブページにアクセス可能となる暗号化証明書を受け取ることができます。
Eucalyptus のサポート対象は、仮想化技術 に Xen (バージョン 3.*) を使用している Linux システムです。Debian や Ubuntu 向けの i386 / x86_64 対応のバイナリ RPM やソースを提供しているほか、その他の主要な Linux ディストリビューション向けのソースパッケージを提供しています。
Eucalyptus v1.5 は Ubuntu 9.04 JauntyJackalope から Universe archive に分類されるパッケージに組み込まれました。Ubuntu 9.04 における Eucalyptus は、他のディストリビューションで提供されている形態とは異なり、ソースコードレベルでディストリビューション内の依存性の問題が解消された状態での提供です。一方、他のディストリビューション向けの Eucalyptus パッケージ ( CentOS、openSUSE、Debian 等 ) ではすべての依存性を解決することができませんので、バイナリパッケージが提供されています。
Eucalyptus が Ubuntu だけで特殊な形態で提供できるのは、Ubuntu の商用サポートを行っている Canonical社の開発者たちによって、Eucalyptus を Ubuntu に組み込むパッケージを作成するため、多くの人的資源が投入されたためです。Eucalyptus を利用できるようにするため Ubuntu と Canonical 社が緊密に連携していることや、この影響でオープンソース・コミュニティがより大きく広がっていくことに、私たちはワクワクしています。
いいえ、そうではありません。KVM を Eucalyptus がサポートするのは、あくまで追加としての機能実装です。私たちは、これからも Xen と KVM の両方をサポートし続けます。
※訳者注：既に KVM はサポート済みです。
クラウド・コントローラによって提供される SLA (サービス水準合意)は、必要最低限のシンプルなものです。現時点のリリースおける単純な SLA は、Eucalyptus のサイトや、開発チームのためのものであり（私たちが試してみたいことは多々あるのですが）、拘束期間をもって強制するような類ではありません。この種の SLA は Amazon が提示しているような SLA に相当するものです。たとえ Amazon に登録しているクレジットカードへの請求金額を支払えなくなりますと、Amazon はサービスを「タイムアウト」（接続させないように）してしまいます。
また、私たちは、現時点において Eucalyptus へタイムアウトのような機能は実装していません。ですので、利用者かクラウド管理者が稼働中のインスタンス(VM)を終了しない限り、いずれ Eucalyptus は VM slot にインスタンスを割り当てることができなくなってしまいます。こうなってしまいますと、利用者のリクエストは失敗し、"ec2-describe-availability-zones" コマンドを実行したとしても EC2 tools は割り当て可能なインスタンスがなくなったと表示します。
※訳者注：リソースを使い尽くさないよう、しっかり管理をする必要があるようです。
Amazon には、利用者自身にインスタンスをどこに配置するか選択できるよう、"availability zone"(稼働地域)を指定する機能があります。すなわち、EC2 利用者は自分自身で故障発生に対する危険を避けたいのであれば、別々の availabilty zone 間にホストイメージを置くことができます。恐らく Amazon は、相互のゾーンに影響が発生しそうな連鎖障害（例えば、データセンタの特定の系統で停電が発生するなど）を避けるため、availability zone を物理的に離れた場所に設置しています。
対して、Eucalyptus における availability zone の考え方は多少異なります。Eucalyptus における availability zone は、Eucalyptus クラウド内において、それぞれ個々が独立したクラスタ群のことを指します。利点は、１つの availability zone の中のネットワークを非常に早くすることができることです（すなわち、クラスタによって構築されるネットワークをネイティブモードで利用できます）。一方で、クラスタ群にまたがってプライベートネットワークを構築し、そこに Eucalyptus を使おうとしても相当な性能劣化を引き起こしてしまいます。
このように、availability zone という概念におけるクラウドの配置は、連鎖障害による危険性を減らすという意味では同じといえます。しかしながら、実体は異なるものです。Eucalyptus における個々の availability zone というのは１つの「マシン」（あるいはクラスタ）に対してのものであり、Amazon の非常に広大な zone とは異なるのです。
今のところ、Eucalyptus の内部に関するバグ修正を行えるのは、プロジェクト内部の関係者のみと制限をさせていただいています。まだ開発は初期段階にあり、この段階で外部の開発者を交えつつ安定したコード提供を行うことは大変困難だと考えています。とはいえ、私たちはバグを改善するためのパッチ提供を歓迎します。パッチ提供など、私たちに協力を申し出たい場合は Contributors page? を御覧ください。Eucalyptus バージョン 1.X の開発完了後 (2009年8月末を予定しています) 、私たちはディストリビューター（開発者）の受け入れを開始します。この時点で、Eucalyptus のリリーススケジュールは、現時点よりも穏やかなものへと移行する予定です。
しかしながら、Eucalyptus がよりオープンに開かれる前であっても、貢献する方法が幾つかあります。特に、Eucalyptus 本体に手を加えることなく、Eucalyptus を利用するようなツールの開発を歓迎します。そうしたら、私たちはあなたのツールに関するプロジェクトのページを作成し、リンクをはるでしょう。
私たちの計画は、2009年の夏までに、基本的な AWS インターフェース（EC2/S3/EBS） の開発を完了することです。5月上旬現在、私たちのロードマップは次のような展開を考えています。バージョン 1.5 (v1.5) は Ubuntu 上で 2009年4月23日にリリースしました。バージョン 1.5 の凍結後、発見されたバグ等の修正を施したバージョン v1.5.1 を 2009年5月8日にリリースしました。その後、バグ修正を目的とした 1.5 シリーズ(v.1.5.2) を少なくともリリースする予定です。私たちは、これらの対応を 6月の半ばに終えたいと思っています。このリリースが 1.5 シリーズの最後のマイナーリリースだと確認が取れれば、8月末には（可能であれば）メージャーリリース (v1.6) を提供しようと思っています。なお、この 1.6 は 1.x シリーズの最後のリリースです。
リリースの規則は、次のように考えています。まず、マイナーリリースはバグ修正がメインであり、機能や内部のデータ構造に対する変更は伴いません。メジャーリリースは、主要なリリースであり、Eucalyptus 内部のサブシステム刷新や、リファクタリング（プログラムの動作を変えず、ソースレベルでの構造を変えること）を含みます。
まずはじめにトラブルシューティング?のページを御覧になることをお薦めします。
トラブルシューティングの内容に当てはまらないようであれば、問題に関するできるだけ詳細な情報をディスカッションフォーラム(Discussion Forum)の質問として投稿してみてください。遠慮なさらずに。
v1.4 現在では、Eucalyptus のイメージは、Xen で用いられているパーティションを指し示すイメージと動議のものです。Xen 上で イメージ・kernel・ramdisk の連携をさせられるのであれば、Eucalyptus でも同様のことができるでしょう（実際、私たちは バンドルやアップロードの作業を行う前に、イメージと kernel ・ ramdisk を試しに使ってみることをお勧めします）。
EC2 の一般的な環境を Eucalyptus も倣っており、VM には以下のように3つの SCSI ディスク領域が割り当てられています。
Eucalytpus 上で動作させたい AMI がある場合は、まずはダウンロードした後、アンバンドル(unbundle)する必要があります。次に、EC2 から Kernel はダウンロードできませんので、自分で kernel と ramdisk の組み合わせを見つける必要があります。また、Eucalyptus で動作を試みる前に、まずは Xen の環境で試すことをお勧めします。
関連情報は、以下のフォーラムを御覧ください。
本来であれば、そのようなことは行うべきではないのですが、解決方法(本家フォーラムでの投稿へのリンク)が Simon 氏により公開されています。
実行することは可能ですが、機能に制限がかかります。
