3.9. 追加ソフトウェア
一般的な OpenStack デプロイメントには、OpenStack 固有のコンポーネントおよび 「サードパーティーのコンポーネント」 が含まれます。補助ソフトウェアには、クラスタリング、ロギング、モニタリング、およびアラート用のソフトウェアを含めることができます。そのため、デプロイメント設計は、CPU、RAM、ストレージ、ネットワーク帯域幅などの追加のリソース消費に対応する必要があります。
クラウドを設計するときは、次の要素を考慮してください。
- データベースおよびメッセージング
基盤となるメッセージキュープロバイダーは、必要なコントローラーサービスの数や、回復性の高いデータベース機能を提供するテクノロジーに影響を及ぼす可能性があります。たとえば、Galera で MariaDB を使用する場合、サービスのレプリケーションはクォーラムに依存します。したがって、基盤となるデータベースは、障害の発生した Galera ノードの復旧に対応するために少なくとも 3 つのノードで設定される必要があります。
ソフトウェア機能をサポートするようにノード数を増やす場合は、ラックスペースとスイッチポート密度の両方を考慮してください。
- 外部キャッシュ
Memcached は分散メモリーオブジェクトキャッシュシステムであり、Redis はキー/値のストアです。両方のシステムをクラウドにデプロイして、Identity サービスの負荷を軽減できます。たとえば、memcached サービス はトークンをキャッシュし、分散キャッシングシステムを使用して基礎となる認証システムからのボトルネックを軽減するのに役立ちます。
memcached または Redis を使用しても、これらのサービスは通常 OpenStack サービスを提供するインフラストラクチャーノードにデプロイされるため、アーキテクチャーの全体的な設計には影響しません。
- 負荷分散
多くの汎用デプロイメントでは、ハードウェアロードバランサーを使用して可用性の高い API アクセスと SSL ターミネーションを提供しますが、HAProxy などのソフトウェアソリューションも考慮することができます。ソフトウェア定義のロードバランシング実装も高可用性であることを確認する必要があります。
Keepalived や Corosync を使用する Pacemaker などのソリューションで、ソフトウェア定義の高可用性を設定できます。Pacemaker および Corosync は、OpenStack 環境の特定のサービスに基づいて、アクティブ/アクティブまたはアクティブ/パッシブの高可用性設定を提供できます。
これらのアプリケーションは、2 つ以上のノードを含むデプロイメントを必要とし、いずれかのコントローラーノードがスタンバイモードでサービスを実行できるため、設計に影響する可能性があります。
- ロギングとモニタリング
解析を容易にするために、ログを一元的に保存する必要があります。ログデータアナリティクスエンジンは、一般的な問題に警告して修正するメカニズムに関する自動化や問題通知も提供することができます。
ツールは、アーキテクチャー設計の既存のソフトウェアおよびハードウェアをサポートする限り、基本的な OpenStack ログに加えて、外部ロギングまたはモニタリングソフトウェアを使用できます。Red Hat OpenStack Platform の Operational Tools リポジトリーには、以下のツールが含まれています。