コントローラーの設定¶

高可用性コントローラーの概要¶

OpenStack は、HTTP(s) API としてエンドユーザーに公開されるサービス群です。さらに、その内部利用のために、OpenStack は SQL データベースサーバーと AMQP ブローカーを必要とします。すべてのコンポーネントが動作している、物理サーバーはよくコントローラーと呼ばれます。このモジュール型の OpenStack アーキテクチャーにより、すべてのコンポーネントを複製して、それらを別々のコントローラーで実行できます。すべてのコンポーネントを冗長にすることにより、OpenStack の高可用性を実現できます。

一般的に、すべての OpenStack コンポーネントは 3 つのカテゴリーに分割できます。

• OpenStack API: これらは HTTP のステートレスサービスです。Python で書かれていて、簡単に冗長化でき、かなり簡単に負荷分散できます。
• SQL リレーショナルデータベースサーバーは、他のコンポーネントにより利用されるステートフルな状態を提供します。サポートされるデータベースは、MySQL、MariaDB、PostgreSQL です。SQL データベースを冗長化することは複雑です。
• Advanced Message Queuing Protocol (AMQP) は、OpenStack 内部のステートフルな通信サービスを提供します。

一般的な配備のアーキテクチャー¶

OpenStack の高可用性のために基本的な 2 つのアーキテクチャーを推奨します。

アーキテクチャーは、クラスターにより管理されるサービス群により異なります。

どちらも Pacemaker や Veritas のようなクラスターマネージャーを使用して、複数のマシンにまたがるさまざまなサービスの動作を協調させます。私たちは FOSS に注力しているため、Pacemaker のアーキテクチャーを参照します。

伝統的に、Pacemaker は全方位的なソリューションとして位置づけられてきました。しかしながら、OpenStack サービスが成熟するにつれて、徐々にアクティブ/アクティブ設定にて動作でき、依存している API の消失に自然に耐えられます。

この点を考慮して、いくつかのベンダーは、cinder-volume などのアクティブ/パッシブモードで動作させる必要があるサービス、Galera などの複数の状態を持つサービス、RabbitMQ のように複雑なブートストラップ手順を持つサービスに Pacemaker を使用することを制限しています。

実際のオーケストレーションを必要としない、大多数のサービスは各ノードにおいて systemd により処理されます。このアプローチは、クラスターでサービスのアップグレードや位置の変更を調整する必要性を避けます。また、Corosync の 16 ノード制限を超えて簡単にスケールするという利点を得られます。しかしながら一般的に、障害レポートを集約するために、Nagios や Sensu のようなエンタープライズモニタリングソリューションを追加する必要があります。