OpenStack は非常に水平的にスケーラブルに設計されています。これにより、すべてのサービスを広く分散させることができます。しかし、この話を単純にするために、このガイドでは単一のクラウドコントローラーの概念を使い、より集中的な性質のサービスとして議論することにしました。
全体的なアーキテクチャの詳細については、7章参考アーキテクチャの章を参照してください。
このガイドに記述されているように、クラウドコントローラーは、データベース、メッセージキューサービス、認証・認可サービス、イメージ管理サービス、ユーザーダッシュボード、API エンドポイントを収容する１台のノードです。
クラウドコントローラーは、複数ノードで構成される OpenStack デプロイメントに対する集中管理機能を提供します。典型的には、クラウドコントローラーは認証および、メッセージキューを通じたメッセージのやりとりを管理します。
私たちの例では、クラウドコントローラーが nova-* コンポーネント群を持ちます。これは、クラウドのグローバルな状態を表し、認証のようなサービスとやりとりし、クラウドの情報をデータベースで維持し、メッセージキューを通してすべてのコンピュートノードとストレージワーカーと通信し、 API アクセスを提供します。可用性やスケーラビリティのために、あるクラウドコントローラーで動作するそれぞれのサービスを別々のノードに分離することができます。
クラウドコントローラー用のハードウェアはコンピュートノードのものと同じでかまいませんが、運用するクラウドのサイズとタイプに基づいて、もっと指定したいかもしれません。
クラウドコントローラーが管理するすべての、または一部のサービス、たとえばメッセージキューに対して仮想マシンを使うことも可能です。このガイドでは、すべてのサービスが直接クラウドコントローラー上で実行されるものと仮定します。
クラウドコントローラーのサーバーを正しくサイジングするため、および一部を仮想化するかどうか決定するため、以下を見積もるべきです。
予期されるインスタンス実行数
コンピュートノードの数
コンピュートサービスまたはストレージサービスにアクセスするユーザー数
ユーザがクラウドへ REST API でアクセスするのかダッシュボードを使うのか
ユーザーは外部のシステムに対して認証を行うのか (例えば、LDAP や Active Directory)
1 つのインスタンスがどのくらい実行され続けるのか
| 考慮事項 | 派生問題 |
|---|---|
同時に何インスタンス実行されますか？ |
データベースサーバーを負荷に応じてサイジングしてください。もし、多数のインスタンスが同時に状態を報告したり、CPU能力が必要な新規インスタンス起動のスケジューリングを行う場合は、１台のクラウドコントローラーを超えてスケールアウトしてください。 |
同時にコンピュートノードが何ノード実行されますか？ |
メッセージキューが正しくリクエストを処理することを保証し、適切にサイジングしてください。 |
どのくらいの数のユーザがAPIにアクセスしますか？ |
もし多数のユーザが複数のリクエストを発行するのであれば、クラウドコントローラーがそれらを扱えるよう、CPU負荷を確認してください。 |
どのくらいの数のユーザが ダッシュボードにアクセスしますか？ |
ダッシュボードは、APIアクセスよりもさらに多くのリクエストを発行します。そのため、もしユーザに対するインタフェースがダッシュボードなのであれば、より多くのCPUを追加してください。 |
あなたのクラウドで、何個の |
サービスごとに１コア割り当ててコントローラーをサイジングする必要があります。 |
１つのインスタンスがどのくらい実行され続けますか？ |
インスタンスの起動と停止は コンピュートノードに負荷をかけますが、それだけでなく、すべてのAPI処理とスケジューリングの必要性のために、コントローラーノードにも負荷をかけます。 |
認証システムは外部に確認を行いますか？ |
クラウドコントローラーと外部の認証システムの間のネットワーク接続性が良好であることと、クラウドコントローラーがリクエストを処理するのに十分なCPU能力があることを確認してください。 |
私たちの例には、一か所にすべての集中的なサービスが含まれていますが、サービスを異なる物理サーバーに分離するのは可能ですし、多くの場合、本当に良いアイデアです。以下は、私たちが見たデプロイメントのシナリオと、その妥当性です。
|
このデプロイメントでは、オブジェクトストレージのプロキシサーバーの I/O の空きは十分でした。そして、Glance のイメージ配信部分は、それが利用しているオブジェクトストレージと同じ物理マシンの上にあり、バックエンドに対して良好な接続性をもつことにより、恩恵を得られました。 |
専用の中央データベースサーバーを運用する |
このデプロイメントでは、すべてのサービスに対するデータベースサービスを提供する専用サーバを設置しました。これにより、データベースサーバーのアップデートを分離でき、運用がシンプルになりました。また、フェイルオーバーのためのスレーブデータベースサーバーの設置が単純になりました。 |
サービスごとに 1 台の VM を動作させる |
このデプロイメントでは、KVM を実行しているサーバー群において集中的なサービス群を動作させています。 各サービス (nova-scheduler、rabbitmq、データベース等) に対して専用 VM が作成されています。これにより、各仮想マシンにかかった負荷 (構築中にはよく分からなかったこと) に応じてリソースをチューニングすることができました。 |
外部ロードバランサーを使う |
このデプロイメントでは、組織内に高価なハードウェアロードバランサーを持っていました。彼らは複数の |
いつも問題になる一つの選択は、仮想化するかどうかです。nova-compute、swift-proxy そして swift-object といったサーバーは仮想化するべきではありません。しかし、コントローラーサーバーは問題なく仮想化することができます。通常、性能ペナルティは、単により多くのサービスを動作させることにより相殺することができます。
OpenStack Compute のほとんどの中央サービスは、現在は nova-compute も含めて、状態の情報を保存するのにデータベースを利用します。この機能を喪失することはエラーにつながります。ですので、耐故障性のために、なんらかの方法でデータベースをクラスタ化することを推奨します。
OpenStack Compute のほとんどのサーバーは、メッセージキューを利用してお互いに通信しあっています。一般論として、このメッセージキューが故障するかアクセスできなくなると、Nova のクラスタは、最後のメッセージが送信されたところの情報でとどまったまま、ゆっくり停止し、「リードオンリー」状態になります。したがって、メッセージキューもクラスタ化することを推奨します。RabbitMQ には、これを行う機能が組み込まれています。
直接であっても、コマンドラインクライアントであっても、Web ベースのダッシュボードであっても、一般ユーザーからのアクセスはAPIサービスを利用します。 API リファレンスは http://api.openstack.org/ にあります。
Amazon EC2 互換 API をサポートしたいか、OpenStack API だけなのか、選択しなければなりません。両方の API を運用する場合、イメージとインスタンスを参照する際の見え方が違うことが一つの論点になります。
例えば、EC2 API では、16 進数を含む ID を使ってインスタンスを参照するのに対して、OpenStack API では名前と数値を使います。類似の話題として、EC2 API は仮想マシンに接続するのに DNS エイリアスに頼る傾向がありますが、OpenStack では典型的には IP アドレスを使います。
もし OpenStack が正しく設定されていなければ、不正な DNS エイリアスしか得られないことによりユーザがインスタンスに接続できないという事態が容易に発生します。こうした事情にもかかわらず、EC2 互換性はユーザーをお使いのクラウドに移行させるのに役立ちます。
データベースやメッセージキューのように、１台より多くの API サーバー を置くのは良いことです。nova-api サービスを高可用にするために、伝統的な HTTP 負荷分散技術を利用することができます。
API Specifications (http://docs.openstack.org/api/api-specs.html) に OpenStack API コアのアクション、ケーパビリティ、メディアタイプが定義されています。クライアントはいつでもこのコアAPIが使えることに依存することができますし、実装者はいつでも完全にサポートすることが求められます。コアAPIの厳守を要求することにより、クライアントは同じAPIの複数の実装とやりとりする際に、最小限のレベルの機能に依存することができます。
OpenStack Compute API は拡張可能です。ある拡張は、ある API にコア定義を超えたケイパビリティを追加します。新機能、新しい MIME タイプ、アクション、状態、ヘッダ、パラメータ、そしてリソースの導入は、コア API の拡張によって達成することができます。これにより、API に対してバージョンを変更することなく新機能を導入することができ、ベンダー固有の特定の機能を導入することもできます。
さまざまなサイズ(異なる フレーバー)の仮想マシンを、異なる能力の物理 nova-compute ノードに配置するのは、一般的にコンピュータ科学で パッキング問題として研究されている難しい問題です。
この問題に対しては様々なテクニックを使うことができます。ひとつの方法は、フレーバーのサイズを線形にすること、つまり、物理ノードの容量に比例した割合にすることですが、この問題を解くことは本書のスコープ外です。スケジューリングの選択肢の助けとなるために、OpenStack Compute はいくつかの異なるタイプのスケジューリングドライバーを提供しており、この議論の全体は リファレンスマニュアル (http://docs.openstack.org/folsom/openstack-compute/admin/content/ch_scheduling.html) にあります。
可用性の目的のため、もしくは非常に大規模な環境や非常に頻繁にスケジューラーが呼び出される環境の場合には、複数の nova-scheduler サービスを動作させることを検討するべきです。nova-scheduler は完全にメッセージキューを使って通信を行うため、特別な負荷分散は必要ありません。
OpenStack Image Catalog and Delivery サービスは、 glance-api と glance-registry の２つの部分から構成されています。前者は コンピュートノードへのイメージの配送に責任を持ち、コンピュートノードはバックエンドからイメージをダウンロードするために使います。後者は、仮想マシンのイメージに関連するメタデータ情報を管理し、データベースを必要とします。
glance-api は、バックエンドの選択を可能にする抽象化レイヤであり、現在は以下をサポートしています。
OpenStack Object Storage。イメージをオブジェクトとして保存することができます。
ファイルシステム。イメージをファイルとして保存するのに、任意の伝統的なファイルシステムを使用します。
S3。Amazon S3 からイメージを取得することができます。
HTTP。Webサーバーからイメージを取得することができます。このモードでは、イメージの書き込みはできません。
OpenStack Object Storage サービスがある場合には、イメージを保存するスケーラブルな場所としてこれを利用することを推奨します。また、OpenStack 経由で新しいイメージをアップロードする必要がある場合には、他の選択肢としては、十分な性能を持ったファイルシステムや Amazon S3 があります。
OpenStack ダッシュボードは、Apache httpdの中で実行される Python の Web アプリケーションとして実装されています。したがって、そこから ネットワーク経由で (admin エンドポイントを含む) API サーバーにアクセスできるという条件の下、他の任意の Web アプリケーションと同じように取り扱うことができます。
OpenStack の認証・認可を支える概念は、よく理解され、類似の性質のシステムで広く使用されているものから得られています。ユーザは、認証に使えるクレデンシャルを持ち、１つ以上のグループ(プロジェクトまたはテナントして知られています)のメンバとなることができます。
例えば、クラウドのユーザは自分の現在のグループに属するインスタンスのみが見えるのに対して、クラウドの管理者はそのクラウドのすべてのインスタンスの一覧をとることができるでしょう。利用可能なコア数、ディスク容量等のリソースのクォータはプロジェクトに対して関連づけられています。
OpenStack Identity Service (Keystone) は、認証の判定とユーザの属性情報を提供する場となり、他の OpenStack サービスから認可のために使用されます。ポリシーは policy.json で記述されます。これらを設定するための情報については、10章プロジェクトとユーザーの管理 を参照してください。
Identity サービスは、バックエンド認証と情報保持のために種々のプラグインをサポートしています。これらの選択肢は、純粋なストレージの選択から、外部認証システムにわたり、現在は以下が含まれています。
インメモリキーバリューストア
SQL データベース
PAM
LDAP
多くのデプロイメントで SQL データベースが使われていますが、既存の認証インフラとインテグレーションする必要のある環境では、LDAP もポピュラーな選択肢です。
クラウドコントローラーは非常に多くのサービスを取り扱うため、到来するトラフィックを処理できなければなりません。例えば、クラウドコントローラー上に OpenStack Image サービスを乗せることにした場合、そのクラウドコントローラーは許容可能な速度でイメージを転送できなければなりません。
別の例としては、クラウドコントローラーがすべてのインスタンスのゲートウェイとなるような単一ホストネットワークモデルを使うことにした場合、クラウドコントローラーは外部インターネットとあなたのクラウドの間でやりとりされるすべてのトラフィックを支えられなければなりません。
10GbE のような高速な NIC を使うことを推奨します。また、10GbE NIC を2枚使って ボンディングすることもできます。束ねられた 20Gbps の速度をフルに使うことはできないかもしれませんが、異なる送信ストリームは異なる NIC を使います。例えば、クラウドコントローラーが2つのイメージを送信する場合、それぞれのイメージが別の NIC を使い、10Gbps の帯域をフルに使うことができます。
