3.7. 可用性
OpenStack は、少なくとも 2 つのサーバーを使用する場合、高可用性のデプロイメントを提供できます。サーバーは、RabbitMQ メッセージキューサービスおよび MariaDB データベースサービスからすべてのサービスを実行できます。
クラウド内でサービスをスケーリングする場合、バックエンドサービスもスケーリングする必要があります。サーバーの使用状況と応答時間、およびシステムの負荷テストの監視と報告は、スケーリングの決定に役立ちます。
- 単一障害点を避けるために、OpenStack サービスは複数のサーバーにまたがってデプロイする必要があります。これらのサービスをメンバーとして複数の OpenStack サーバーを持つ高可用性ロードバランサーの背後に配置すると、API の可用性を実現できます。
- デプロイメントに十分なバックアップ機能があることを確認します。たとえば、高可用性を使用する 2 つのインフラストラクチャーコントローラーノードを持つデプロイメントでは、1 つのコントローラーが失われた場合でも、もう一方のコントローラーからクラウドサービスを実行できます。
- OpenStack インフラストラクチャーはサービスを提供することが必須であり、特に SLA を操作する場合には常に利用可能でなければなりません。コアインフラストラクチャーに必要な電源のスイッチ、ルート、および冗長性の数や、可用性の高いスイッチインフラストラクチャーに多様なルートを提供するためにネットワークの関連ボンディングを検討します。使用するネットワークバックエンドのタイプに特に注意してください。ネットワークバックエンドの選択方法は、2章Networking In-Depthを参照してください。
- ライブマイグレーション用にコンピュートホストを設定しておらず、コンピュートホストに障害が発生すると、コンピュートインスタンスとそのインスタンスに保存されているデータはすべて失われる可能性があります。コンピュートホストのアップタイムを確保するには、エンタープライズストレージまたは OpenStack Block ストレージで共有ファイルシステムを使用できます。
外部ソフトウェアを使用して、サービスの可用性またはしきい値の制限を確認し、適切なアラームを設定することができます。Red Hat OpenStack Platform の Operational Tools リポジトリーには以下が含まれます。
OpenStack で高可用性を使用するリファレンスアーキテクチャーについては、Ceph Storage を使用した高可用性 Red Hat OpenStack Platform 6 のデプロイ を参照してください。