第7章 参考アーキテクチャ

アスタリスク (*) は、参考アーキテクチャでの設定がデフォルトのインストールの設定とは違うことを示します。

	注記
	以下の OpenStack の機能がこのガイドの参考アーキテクチャではサポートされていますが、これらは必須項目ではありません。 ダッシュボード ブロックストレージ フローティング IP アドレス ライブマイグレーション オブジェクトストレージ

この参考アーキテクチャは、OpenStack Folsom の現在のデフォルト機能をベースとして、安定性を重視して選択されました。特に、 OpenStack Folsom リリースの構成で、この文書の著者の誰も使ったことがないバックエンドや設定については、この参考アーキテクチャでは取り上げないことにしました。きっと、現在本番環境で OpenStack を使っている多くのクラウドでは同様の選択がなされていることでしょう。

まず最初に、すべての物理ノードで動作させるオペレーティングシステムを選ばなければなりません。いくつかの Linux ディストリビューションが OpenStack をサポートしていますが、我々は Ubuntu 12.04 LTS (Long Term Support) を使うことにしました。 Ubuntu 12.04 LTS は開発コミュニティの大半の人が使っており、他のディストリビューションと比較して機能の完成度が高く、今後のサポート計画もはっきりしています。

Ubuntu のデフォルトの OpenStack インストールパッケージではなく、Ubuntu Cloud Archive (https://wiki.ubuntu.com/ServerTeam/CloudArchive) を使うことをお薦めします。Cloud Archive は Canonical がサポートしているパッケージレポジトリで、このレポジトリを使うことで Ubuntu 12.04 を使い続けながら新しい OpenStack リリースにアップグレードすることができます。

Ubuntu を選択した場合、 ハイパーバイザー として KVM が最も適切です。サポートの観点ではぴったりの組み合わせであり、また (著者も含め) OpenStack の開発コミュニティからの関心も非常に高いからです。著者のほとんどが KVM を使っています。また、 KVM は機能が揃っていて、ライセンスの課金も制限もありません。

MySQL も同様の理由から選ばれました。最近開発元が変わりましたが、このデータベースは OpenStack との組み合わせで最もテストされており、 Ubuntu での動かし方についても非常によくドキュメントにまとまっています。デフォルトのデータベースである SQLite を使っていませんが、それは SQLite が本番環境での利用には適したデータベースではないからです。

OpenStack では AMQP 互換の選択肢としては ZeroMQ や Qpid などのサポートが進んでいますが、 RabbitMQ を選んだのは、Ubuntu での使いやすさと、本番環境で十分にテストされているのが理由です。また、RabbitMQ は Compute Cell といった機能でサポートされている唯一の選択肢です。 RabbitMQ はクラスタ構成にすることを推奨します。それは、メッセージキューは OpenStack システムで不可欠のコンポーネントで、RabbitMQ 自体で元々サポートされているためかなり簡単に実現することができるからです。

前の章に議論したように、OpenStack Compute のネットワークにはいくつかの選択肢があります。我々は FlatDHCP を選択し、高可用性のために マルチホスト モードを使うことをお薦めします。マルチホストモードでは、nova-network デーモンを OpenStack Compute ホスト毎に一つ動作させます。この堅牢性のメカニズムでは、ネットワーク障害が各コンピュートホスト内に閉じることが保証され、各ホストがハードウェアのネットワークゲートウェイと直接通信できます。

ライブマイグレーション は共有ストレージを使うことでサポートされます。分散ファイルシステムとして NFS を使います。

多くの小規模の構成では Object Storage サービスを仮想マシンイメージのストレージのためだけに使うのはコストがかかることなので、OpenStack Image Service (Glance) のバックエンドとしてファイルバックエンドを選択しました。あなたが設計しているクラウドで Object Storage も動かすつもりであれば、代わりに Object Storage をバックエンドとして使うのは簡単なので、使用することを是非お薦めします。

Identity サービス (keystone) のバックエンドとして、LDAP などの他の選択肢ではなく SQL バックエンドを選択しました。 SQL バックエンドはインストールが簡単で、堅牢性があります。多くのシステムで既存のディレクトリサービスと接続したいという要望があることは理解しています。その場合は、設定オプションリスト (http://docs.openstack.org/folsom/openstack-compute/admin/content/reference-for-ldap-config-options.html) を注意深く理解してから使って下さい。

Block Storage サービス (cinder) は外部のストレージノードに直接インストールされ、LVM/iSCSI プラグイン を使用します。ほとんどの Block Storage サービスのプラグインは個々のベンダー製品や実装に依存しており、そのハードウェアプラットフォームを持っているユーザしか利用できませんが、 LVM/iSCSI は堅牢性と安定性があり、一般的なハードウェアで利用できます。

このクラウドは OpenStack ダッシュボード なしで動かすことはできますが、我々はダッシュボードを、クラウドのユーザ操作のためだけでなく、オペレータ向けのツールとしてもなくてはならないものと考えています。まだ、ダッシュボードは Django を使っているため拡張しやすい柔軟なフレームワークとなっています。

参考アーキテクチャは複数のコンピュートノード、クラウドコントローラー、インスタンスストレージ用の外部の NFS ストレージサーバー、ボリューム ストレージ用の OpenStack Block Storage サーバーで構成されています。ネットワーク時刻サービス (Network Time Protocol, NTP) により全ノードの時刻が同期されます。ネットワークでは、マルチホストモードの FlatDHCPManager を使用しています。

クラウドコントローラーでは、ダッシュボード、API サービス、データベース (MySQL)、メッセージキューサーバー (RabbitMQ)、コンピューティングリソースの選択を行うスケジューラー (nova-scheduler)、 Identity サービス (keystone, nova-consoleauth), Image Service (glance-api, glance-registry), ゲストへのコンソールアクセス用サービス、ストレージリソースのスケジューラーを含む Block Storage サービス(cinder-api と cinder-scheduler) が動作します。

コンピュートノードはコンピューティングリソースを提供する場所です。この参考アーキテクチャでは、コンピュートノードで、ハイパーバイザー (KVM)、 libvirt (ハイパーバイザー用のドライバーで、ノード間でのライブマイグレーションを可能にします)、 nova-compute、 nova-api-metadata (通常はマルチホストモードの場合のみ使用されます。インスタンス固有のメタデータの取得に使われます)、 nova-vncproxy、 nova-network が動作します。

ネットワークは2つのスイッチで構成され、一つは管理やプライベートトラフィック用で、もう一つはフローティングIPなどのパブリックアクセスに使用されます。この構成をとるため、クラウドコントローラーと各コンピュートノードにはNICを2つ用意しています。OpenStack Block Storage と NFS ストレージサーバーはプライベートネットワークだけにアクセスできればよく、そのため必要なNICは1つです。ただし、可能であれば複数のNICを bonding 設定で動作させることを推奨します。フローティング IP アクセスはインターネットと直結になりますが、フラット IP アクセスは NAT 経由となります。

この参考アーキテクチャを以下のように拡張することができます。