第6章 Composable Services and Custom Roles
オーバークラウドは通常、コントローラーノード、コンピュートノード、異なるストレージノード種別など、事前定義されたロールのノードで設定されます。これらのデフォルトの各ロールには、director ノード上にあるコアの Heat テンプレートコレクションで定義されているサービスセットが含まれます。ただし、コアの Heat テンプレートのアーキテクチャーは、以下のような設定を行う手段を提供します。
- カスタムロールの作成
- 各ロールへのサービスの追加と削除
本章では、カスタムロールのアーキテクチャー、コンポーザブルサービス、およびそれらを使用する方法について説明します。
ガイドラインおよび制限事項
コンポーザブルノードのアーキテクチャーには、以下のガイドラインおよび制限事項があることに注意してください。
-
サポートされているスタンドアロンカスタムロールに任意の
systemdマネージドサービスを割り当てることができます。 - Pacemaker マネージドサービスを分割することはできません。これは、Pacemaker がオーバークラウドクラスター内の各ノードで同じサービスセットを管理するためです。Pacemaker マネージドサービスを分割すると、クラスターのデプロイエラーが発生する可能性があります。これらのサービスは、コントローラーのロールのままにしておく必要があります。
- Red Hat OpenStack Platform 9 から 10 へのアップグレードプロセス中に、カスタムロールおよびコンポーザブルサービスに変更することはできません。アップグレードスクリプトは、デフォルトのオーバークラウドロールにのみ対応できます。
- 初回のデプロイメント後に追加のカスタムロールを作成してそれらをデプロイし、既存のサービスをスケーリングすることができます。
- オーバクラウドのデプロイ後には、ロールのサービスリストを変更することはできません。オーバークラウドのデプロイ後にサービスリストを変更すると、デプロイでエラーが発生して、ノード上に孤立したサービスが残ってしまう可能性があります。
サポートされているカスタムロールアーキテクチャー
カスタムロールとコンポーザブルサービスは Red Hat OpenStack Platform 10 の新機能であり、限られた数のコンポーザブルサービスの組み合わせのみが、この初期段階でテストおよび検証されています。Red Hat は、カスタムロールとコンポーザブルサービスを使用する場合、次のアーキテクチャーをサポートします。
- アーキテクチャー 1 - モノリシックコントローラー
- すべての Controller サービスが単一の Controller ロールに含まれます。これがデフォルトです。詳細は、「サービスアーキテクチャー: モノリシックコントローラー」 を参照してください。
- アーキテクチャー 2 - スプリットコントローラー
コントローラーサービスは、次の 2 つのロールに分割されます。
- コントローラー PCMK - データベースやロードバランシングなどのコア Pacemaker マネージドサービス
- Controller Systemd - systemd で管理される OpenStack Platform サービス
詳細は、「サービスアーキテクチャー: スプリットコントローラー」 を参照してください。
- アーキテクチャー 3 - スタンドアロンのロール
- OpenStack Platform サービスをカスタムロールに分割する場合を除いて、アーキテクチャー 1 またはアーキテクチャー 2 を使用します。詳細は、「サービスアーキテクチャー: スタンドアロンロール」 を参照してください。
6.1. カスタムロールアーキテクチャーの調査
オーバークラウドの作成プロセスでは、ロールデータを含むテンプレートを使用してそのロールを定義します。デフォルトのテンプレートは /usr/share/openstack-tripleo-heat-templates/roles_data.yaml にあり、すべてのデフォルトのロールタイプ (Controller、Compute、BlockStorage、ObjectStorage、および CephStorage) を定義します。
カスタムの roles_data.yaml ファイルを作成する場合は、Controller のロールを常に最初に定義する必要があります。このロールは、プライマリーロールとして扱われます。
それぞれのロールには以下のパラメーターが含まれます。
- name
-
(必須) 空白または特殊文字を含まないプレーンテキスト形式のロール名。選択した名前により、他のリソースとの競合が発生しないことを確認します。たとえば、
Networkの代わりにNetworkerを名前に使用します。ロール名に関する推奨事項については、たとえば 「サービスアーキテクチャー: スプリットコントローラー」 を参照してください。 - CountDefault
- (任意) このロールにデプロイするデフォルトのノード数を定義します。
- HostnameFormatDefault
(任意) このロールに対するホスト名のデフォルトの形式を定義します。デフォルトの命名規則では、以下の形式が使用されます。
[STACK NAME]-[ROLE NAME]-[NODE ID]
たとえば、コントローラーノード名はデフォルトで以下のように命名されます。
overcloud-controller-0 overcloud-controller-1 overcloud-controller-2 ...
- ServicesDefault
- (任意) ノード上で追加するデフォルトのサービス一覧を定義します。詳しくは、「コンポーザブルサービスアーキテクチャーの考察」を参照してください。
これらのオプションは、新しいロールを作成し、含めるサービスを定義する手段を提供します。
openstack overcloud deploy コマンドは、roles_data.yaml ファイルのパラメーターを overcloud.j2.yaml Heat テンプレートに統合します。特定の時点で overcloud.j2.yaml heat テンプレートは roles_data.yaml のロールの一覧を繰り返し適用し、対応する各ロール固有のパラメーターとリソースを作成します。
たとえば、overcloud.j2.yaml Heat テンプレートの各ロールのリソースの定義は、以下のスニペットのようになります。
{{role.name}}:
type: OS::Heat::ResourceGroup
depends_on: Networks
properties:
count: {get_param: {{role.name}}Count}
removal_policies: {get_param: {{role.name}}RemovalPolicies}
resource_def:
type: OS::TripleO::{{role.name}}
properties:
CloudDomain: {get_param: CloudDomain}
ServiceNetMap: {get_attr: [ServiceNetMap, service_net_map]}
EndpointMap: {get_attr: [EndpointMap, endpoint_map]}
...
このスニペットには、Jinja2 ベースのテンプレートが {{role.name}} の変数を組み込み、各ロール名を OS::Heat::ResourceGroup リソースとして定義しているのが示されています。これは、次に roles_data.yaml のそれぞれの name パラメーターを使用して、対応する各 OS::Heat::ResourceGroup リソースを命名します。
