ここからは、OpenStackの各コンポーネントをどのように実際の物理環境に配置してIaaSを構成すればよいかを見ていこう。
図1は、物理構成の一例である。各コンポーネントは、その役割から「クラウドコントローラー」「リソースプール」「オブジェクトストレージ」の三つに大別できる。この構成を例に、可用性や性能を確保するためのアーキテクチャーを解説する。
リソースプールは物理ホストを分ける
図1で示した基本構成には、多数の単一故障点（SPOF：Single Point of Failure）が見られる。IaaSにおける可用性確保の方法は、構成要素の冗長化および多重化が基本となる。ただしそのアプローチは、コンポーネントごとに異なる。投資対効果のバランスを取りつつ、それぞれで最適な物理構成をとる必要がある。
クラウドコントローラーは、一連の管理系コンポーネント（API Server / Scheduler / Keystone / RabbitMQ）を一つに集約して扱うとよい。物理構成においても、1台のホストに収容するアプローチを推奨する。構成をシンプルに保ちつつ、冗長化対策もセットで行えるからだ。
Network Controller、Compute Worker、Volume Workerから成るリソースプールは、個々のコンポーネントを別々の物理ホストに配置すべきである。サーバーやネットワーク、ストレージといったリソースへのワークロードを隔離し、可用性や拡張性を個別に最適化するという観点からだ。
構築したIaaSで提供するSLA（サービスレベル契約）の規定によっても異なるが、一般的には、機器の故障時の影響がクラウド全体に及ぶタイプのコンポーネント（Network ControllerとVolume Worker）については、性能・拡張性と可用性のバランスのとれたハードウエア構成とすべきである。 Novaは内部ステート情報をデータストア（DB）に格納しており、障害発生時もそれに基づき、リカバリーが可能である。一方で、仮想マシン（VM）上でゲストOSがどのように動作しているかなど、すべての内部ステートが管理できているわけではなく、コンポーネントによっては、冗長化困難なものもある。そのため、各コンポーネントの特徴にあわせて、冗長化のアプローチを検討すべきである。
Network Controllerから具体的にみていこう。機器の選択にあたってはネットワーク冗長化のため、多数のNICを搭載可能であることが望ましい。さらにNetwork Controllerの冗長化について対策が必要であれば、Rackspaceのリファレンスアーキテクチャー（http://referencearchitecture.org/network-design/）において、「High-Availability FlatDHCP Model」という構成が挙げられているのでそちらも参考にしてほしい。各Compute WorkerにNetwork Controllerを配置し、Network Controllerは自ホストで起動されているVMのみがアドレス変換の対象となる構成である。この構成により、Network ControllerがSPOFとはならず、物理ホスト障害の影響をそのホスト内に限定可能である。
Volume Workerは、RAIDなどの冗長化を実施し、ストレージネットワークに十分な帯域および処理能力を確保するよう配慮する。Volume WorkerはあくまでソフトウエアiSCSIターゲットの機構であるため、エンタープライズ用途においてはiSCSI外部ストレージを検討すべきだろう。
Compute Workerについては、ホスト障害の際、VMを回復させる手段はない。また機器の故障の影響は、そのホスト上で起動する仮想マシンのみに限定される。そのため、ある程度は「壊れることを前提」とし、コストパフォーマンス（CPUコア単価またはラック集約率）を重視したハードウエアの選定が有効なアプローチといえる。
GlanceとSwiftで構成されるオブジェクトストレージに関しても、やはりコストパフォーマンス（ストレージ容量単価）を重視するアプローチが有効である。冗長化の部分はSwiftのソフトウエア機能として提供されるためだ。
