第2章 アーキテクチャー
director には、OpenStack 環境自体の設定、デプロイ、管理にネイティブの OpenStack API を使用することを推奨します。つまり、director を使用した統合には、それらのネイティブ OpenStack API および補助コンポーネントとの統合が必要となることになります。このような API を使用する主な利点は、十分に文書化されていること、アップストリームで統合テストが幅広く行われていること、成熟していること、また OpenStack 基本知識を持つユーザーであればより簡単に director の機能の仕組みを理解できることなどです。また、OpenStack API を使用すると、director が自動的に OpenStack のコア機能拡張、セキュリティー修正プログラム、バグの修正を自動的に継承することになります。
Red Hat OpenStack Platform director は、完全な OpenStack 環境のインストールおよび管理を行うためのツールセットです。director は、主に OpenStack プロジェクト TripleO (「OpenStack-On-OpenStack」の略語) をベースとしてます。このプロジェクトは、OpenStack のコンポーネントを活用して、完全に機能する OpenStack 環境をインストールします。これには、OpenStack ノードとして使用するベアメタルシステムのプロビジョニングや制御を行う新たな OpenStack のコンポーネントが含まれます。director により、効率的で堅牢性の高い、完全な Red Hat OpenStack Platform 環境を簡単にインストールできます。
Red Hat OpenStack Platform director は、アンダークラウドとオーバークラウドという 2 つの主要な概念を使用します。この director 自体は、アンダークラウドとして知られている単一システムの OpenStack 環境を形成する OpenStack コンポーネントのサブセットで構成されています。アンダークラウドは、ワークロードを実行できるように実稼働レベルのクラウドを構築できる管理システムとして機能します。この実稼働レベルのクラウドはオーバークラウドです。オーバークラウドおよびアンダークラウドに関する詳しい情報は、『 director のインストールと使用方法』 を参照してください。
director には、オーバークラウド構成を構築するためのツール、ユーティリティー、テンプレートのサンプルが同梱されています。director は、設定データ、パラメーター、ネットワークトポロジーの情報を取得し、Ironic、Heat、Puppet などのコンポーネントとともにその情報を使用して、オーバークラウドのインストール環境をオーケストレーションします。
パートナーにはさまざまな異なる要件があります。director のアーキテクチャーを理解すると、統合の際にどのコンポーネントが重要となるかを理解するのに役立ちます。
2.1. コアコンポーネント
本セクションでは、Red Hat OpenStack Platform director のコアコンポーネントをいくつか考察して、それらのコンポーネントがオーバークラウドの作成にどのように貢献するのかを説明します。
2.1.1. Ironic
Ironic は、セルフサービスのプロビジョニングを使用してエンドユーザーに専用のベアメタルホストを提供します。director は、Ironic を使用してオーバークラウドのベアメタルハードウェアのライフサイクルを管理します。Ironic には、ベアメタルノードを定義するネイティブの API があります。director で OpenStack 環境をプロビジョニングする管理者は、特定のドライバーを使用して、Ironic にノードを登録する必要があります。ハードウェアの多くで Intelligent Platform Management Interface (IPMI) 電源管理機能がサポートされているため、IPMI が主要なサポートドライバーとなっています。しかし、Ironic には HP iLO または Dell DRAC などのベンダー固有のドライバーも含まれています。Ironic は、ノードの電源管理を制御し、イントロスペクションメカニズムを使用して、ハードウェアの情報や ファクト を収集します。director は、イントロスペクションプロセスから取得した情報を使用して、コントローラーノード、コンピュートノード、ストレージノードなど、さまざまな OpenStack 環境のロールとノードを照合します。たとえば、ディスクが 10 個あるノードが検出された場合は、ストレージノードとしてプロビジョニングされる可能性が高いです。
director でのハードウェアサポートを希望するパートナーは、Ironic のドライバーに対応している必要があります。
2.1.2. Heat
Heat は、アプリケーションスタックのオーケストレーションエンジンとして機能します。これにより、組織では、クラウドにデプロイする前に特定のアプリケーションの要素を定義することができます。このプロセスでは、複数のインフラストラクチャーリソース (例: インスタンス、ネットワーク、ストレージボリューム、Elastic IP アドレスなど) や設定用のパラメーターセットなどが含まれるスタックテンプレートを作成します。Heat は、指定の依存関係チェーンに基づいてこれらのリソースを作成して、リソースの可用性を監視し、必要に応じてスケーリングします。これらのテンプレートにより、アプリケーションスタックは移植可能となり、常に同じ結果が得られるようになります。
director は、ネイティブの OpenStack Heat API を使用して、オーバークラウドのデプロイに関連するリソースのプロビジョニングおよび管理を行います。これには、1 ノードロールあたりのプロビジョニングするノードの数、各ノードに設定するソフトウェアコンポーネント、それらのコンポーネントとノードの種別を director が設定する順序の定義などの詳細情報が含まれます。また director は、デプロイメントのトラブルシューティングやデプロイメント後の変更を容易に行うためにも Heat を使用します。
以下の例は、コントローラーノードのパラメーターを定義する Heat テンプレートのスニペットです。
NeutronExternalNetworkBridge:
description: Name of bridge used for external network traffic.
type: string
default: 'br-ex'
NeutronBridgeMappings:
description: >
The OVS logical->physical bridge mappings to use. See the Neutron
documentation for details. Defaults to mapping br-ex - the external
bridge on hosts - to a physical name 'datacentre' which can be used
to create provider networks (and we use this for the default floating
network) - if changing this either use different post-install network
scripts or be sure to keep 'datacentre' as a mapping network name.
type: string
default: "datacentre:br-ex"Heat は、director に含まれるテンプレートで Ironic を呼び出してノードの電源を入れるなど、オーバークラウドの作成を簡素化します。標準の Heat ツールを使用して作成中のオーバークラウドのリソース (およびステータス) を表示することができます。たとえば、Heat ツールを使用して、入れ子状のアプリケーションスタックとしてオーバークラウドを表示することができます。
Heat には、実稼働向けの OpenStack クラウドを宣言および作成するための幅広く強力な構文があります。ただし、事前にパートナーのソリューションとの統合に関する知識とスキルが必要です。パートナーのテクノロジーを統合するユースケースにはすべて、Heat のテンプレートが必要です。
2.1.3. Puppet
Puppet は、設定管理および実行ツールです。マシンの最終的な状態を記述して、その状態を保持するメカニズムとして使用します。この最終的な状態は、Puppet マニフェストで定義します。Puppet では、以下の 2 つのモードがサポートされています。
- マニフェスト形式の手順がローカルで実行されるスタンドアロンモード
- Puppet マスターと呼ばれる中央サーバーからマニフェストを取得するサーバーモード
管理者は、ノードに新しいマニフェストをアップロードしてローカルで実行する方法と、クライアント/サーバーモデルで Puppet マスターで変更する方法のいずれかを使用して変更を加えます。
Puppet は director のさまざまな場所で使用されています。
- アンダークラウドホストで Puppet をローカルで使用して、undercloud.conf に記述された設定に従ってパッケージのインストールや設定を行います。
- ベースのオーバークラウドイメージに openstack-puppet-modules パッケージを注入します。これらの Puppet モジュールは、デプロイメント後の設定に使用できます。デフォルトでは、すべての OpenStack サービスが含まれたイメージを作成して、各ノードに使用します。
- Heat 経由で追加の Puppet マニフェストとパラメーターをノードに渡して、オーバークラウドのデプロイメントの後にその設定を適用します。これには、ノードの種別に依存するサービスの有効化や起動、OpenStack の設定の適用などが含まれます。
ノードに Puppet hieradata を渡します。Puppet モジュールやマニフェストには、マニフェストの一貫性を確保するためのサイトやノード固有のパラメーターはありません。hieradata はパラメーター値の形式で機能し、Puppet モジュールをプッシュして、他のエリアで参照することができます。たとえば、マニフェスト内の MySQL パスワードを参照するには、この情報を hieradata として保存して、マニフェスト内でこの hieradata を参照します。
hieradata を表示します。
[root@localhost ~]# grep mysql_root_password hieradata.yaml # View the data in the hieradata file openstack::controller::mysql_root_password: ‘redhat123'
Puppet マニフェストで hieradata を参照します。
[root@localhost ~]# grep mysql_root_password example.pp # Now referenced in the Puppet manifest mysql_root_password => hiera(‘openstack::controller::mysql_root_password')
パートナーが統合するサービスで、パッケージをインストールしたり、サービスを有効化したりする必要がある場合には、その要件を満たすための Puppet モジュールを作成することを検討してください。たとえば、現在の OpenStack Puppet モジュールを取得する方法に関する情報は、「OpenStack Puppet モジュールの取得」を参照してください。
2.1.4. TripleO および TripleO Heat テンプレート
前述したように、director はアップストリームの TripleO プロジェクトをベースにしています。このプロジェクトは、以下の作業を行う OpenStack サービスセットを統合します。
- オーバークラウドイメージの保存 (Glance)
- オーバークラウドのオーケストレーション (Heat)
- ベアメタルマシンのプロビジョニング (Ironic および Nova)
TripleO には、Red Hat がサポートするオーバークラウド環境を定義する Heat テンプレートコレクションが含まれます。director は、Heat を使用してこのテンプレートコレクションを読み込み、オーバークラウドスタックをオーケストレーションします。
2.1.5. コンポーザブルサービス
Red Hat OpenStack Platform の各機能側面は、コンポーザブルサービスに細分化されます。つまり、さまざまなサービスを組み合わせて異なるロールを定義できるということです。たとえば、管理者はネットワークエージェントをデフォルトのコントローラーノードからスタンドアロンの Networker ノードに移すことができます。
コンポーザブルサービスのアーキテクチャーに関する詳しい情報は、「6章コンポーザブルサービス」を参照してください。
2.1.6. コンテナー化されたサービスおよび Kolla
Red Hat OpenStack Platform の各主要サービスは、コンテナー内で実行されます。このことにより、それぞれのサービスが、ホストから独立した専用の分離名前空間内に維持されます。この構成には、以下のような特徴があります。
- Red Hat カスタマーポータルからコンテナーイメージをプルして実行することで、サービスのデプロイメントが実施される。
-
podmanコマンドを実行し、サービスの起動/停止などの管理機能を操作する。 - コンテナーをアップグレードするには、新しいコンテナーイメージをプルし、既存のコンテナーを新しいバージョンのコンテナーに置き換える必要がある。
Red Hat OpenStack Platform は、kolla ツールセットによりビルド/管理されるコンテナーセットを使用します。
2.1.7. Ansible
OpenStack Platform では、Ansible を使用してコンポーザブルサービスのアップグレードに関する特定の機能がアクティブ化されます。この機能には、特定サービスの起動/停止やデータベースアップグレードの実施が含まれます。これらのアップグレードタスクは、コンポーザブルサービスのテンプレートで定義されます。
