Red Hat Summit4.2. General-Purpose アーキテクチャー
特定の技術的または環境的なニーズが不明な場合は、一般的な高可用性クラウドをデプロイできます。この柔軟なアーキテクチャー種別は、単一の OpenStack コンポーネントのサイズを強調せず、特定の環境に限定されません。
このアーキテクチャータイプは、以下のような潜在的なユースケースの 80% に対応します。
- シンプルなデータベース
- Web アプリケーションランタイム環境
- 共有アプリケーションの開発環境
- テスト環境
- スケールアップの追加ではなく、スケールアウト機能を必要とする環境
このアーキテクチャータイプは、セキュリティーを強化する必要があるクラウドドメインには推奨されません。
インストールおよびデプロイメントのドキュメントは、5章デプロイメント情報 を参照してください。
4.2.1. ユースケースの例
オンライン分類された広告会社では、プライベートクラウドに Apache Tomcat、Nginx、MariaDB を含む Web アプリケーションを実行します。ポリシーの要件を満たすために、クラウドインフラストラクチャーは会社のデータセンター内で実行されます。
会社には予測可能な負荷要件がありますが、需要の夜間に合わせてスケーリングが必要です。現在の環境には、オープンソースの API 環境を実行する会社の目標に柔軟性がありません。
現在の環境は、以下のコンポーネントで設定されています。
- Nginx と Tomcat の 120 から 140 インストールの間に、2 つの vCPU と 4 GB のメモリーがある
- それぞれ 4 つの vCPU と 8 GB の RAM を備えた 3 ノードの MariaDB および Galera クラスター。Pacemaker は、Galera ノードの管理に使用されます。
会社は、ハードウェアロードバランサーと、Web サイトを提供する複数の Web アプリケーションを実行します。環境オーケストレーションは、スクリプトと Puppet の組み合わせを使用します。この Web サイトでは、アーカイブが必要な日に大量のログデータが生成されます。
4.2.2. 設計について
この例のアーキテクチャーには、3 台のコントローラーノードと少なくとも 8 つのコンピュートノードが含まれます。静的オブジェクトには OpenStack Object Storage を使用し、その他すべてのストレージのニーズには OpenStack Block Storage を使用します。
OpenStack インフラストラクチャーコンポーネントが高可用性を確保するために、ノードは Red Hat Enterprise Linux の Pacemaker アドオンを HAProxy と共に使用します。
アーキテクチャーには、以下のコンポーネントが含まれます。
- パブリック向けネットワーク接続用のファイアウォール、スイッチ、およびハードウェアロードバランサー。
- Image、Identity、および Networking を実行する OpenStack コントローラーサービスと、サポートサービス MariaDB および RabbitMQ の組み合わせこれらのサービスは、少なくとも 3 つのコントローラーノードで高可用性向けに設定されます。
- クラウドノードは、Red Hat Enterprise Linux 用の Pacemaker アドオンを使用して高可用性用に設定されています。
- コンピュートノードは、永続ストレージを必要とするインスタンス用に OpenStack Block Storage を使用します。
- イメージなどの静的オブジェクトを提供する OpenStack Object Storage
4.2.3. アーキテクチャーコンポーネント
| コンポーネント | 説明 |
|---|---|
| Block Storage | インスタンスの永続ストレージ。 |
| Compute コントローラーサービス | コンピュート管理およびコントローラー上で実行されるスケジューリングサービス。 |
| Dashboard | OpenStack 管理用の Web コンソール。 |
| Identity | ユーザーとテナントの基本認証および承認 |
| イメージ | インスタンスの起動およびスナップショットの管理に使用するイメージを保存します。 |
| MariaDB | すべての OpenStack コンポーネントのデータベース。MariaDB サーバーインスタンスは、NetApp や Solidfire などの共有エンタープライズストレージにデータを格納します。MariaDB インスタンスに障害が発生した場合には、ストレージを別のインスタンスに再接続し、Galera クラスターに再参加する必要があります。 |
| ネットワーク | プラグインおよび Networking API を使用してハードウェアロードバランサーを制御します。OpenStack Object Storage を増やす場合は、ネットワークの帯域幅の要件を考慮する必要があります。OpenStack Object Storage は、10 GbE 以上のネットワーク接続で実行することを推奨します。 |
| オブジェクトストレージ | Web アプリケーションサーバーからログを処理およびアーカイブします。Object Storage を使用して、OpenStack Object Storage コンテナーから静的な Web コンテンツを移動したり、OpenStack イメージが管理するイメージをバックアップしたりすることもできます。 |
| テレメトリー | 他の OpenStack サービスの監視およびレポート。 |
4.2.4. コンピュートノードの要件
Compute サービスがそれぞれのコンピュートノードにインストールされている。
この汎用アーキテクチャーは 140 Web インスタンスまで実行でき、少数の MariaDB インスタンスは 292 vCPU と 584 GB RAM を必要とします。ハイパースレッディングを備えたデュアルソケット 16 進コア Intel CPU を備えた一般的な 1U サーバーでは、CPU のオーバーコミットの比率が 2:1 個と仮定すると、このアーキテクチャーには 8 つのコンピュートノードが必要です。
Web アプリケーションインスタンスは、各コンピュートノード上のローカルストレージから実行されます。Web アプリケーションインスタンスはステートレスであるため、インスタンスの 1 つに障害が発生した場合は、アプリケーションは実行を継続できます。
4.2.5. ストレージ要件
ストレージの場合は、サーバーで直接接続されたストレージでスケールアウトソリューションを使用します。たとえば、グリッド 結合ソリューションと同様の方法でコンピュートホストにストレージを入力することも、ブロックストレージだけを提供する専用ホストにも反映することができます。
コンピュートホストにストレージをデプロイする場合は、ハードウェアがストレージおよびコンピュートサービスを処理できることを確認します。
