Red Hat Training

A Red Hat training course is available for Red Hat OpenStack Platform

第6章 コンポーザブルサービスとカスタムロール

オーバークラウドは通常、コントローラーノード、コンピュートノード、異なるストレージノード種別など、事前定義されたロールのノードで構成されます。これらのデフォルトの各ロールには、director ノード上にあるコア Heat テンプレートコレクションで定義されているサービスセットが含まれます。ただし、コア Heat テンプレートのアーキテクチャーは、以下のような設定を行う手段を提供します。

  • カスタムロールの作成
  • 各ロールへのサービスの追加と削除

これにより、異なるロール上に異なるサービスの組み合わせを作成することができます。本章では、カスタムロールのアーキテクチャー、コンポーザブルサービス、およびそれらを使用する方法について説明します。

6.1. サポートされるロールアーキテクチャー

カスタムロールとコンポーザブルサービスを使用する場合には、以下のアーキテクチャーを使用することができます。

アーキテクチャー 1: デフォルトアーキテクチャー
デフォルトの roles_data ファイルを使用します。すべてのコントローラーサービスが単一の Controller ロールに含まれます。
アーキテクチャー 2: サポートされるスタンドアロンのロール
/usr/share/openstack-tripleo-heat-templates/roles 内の事前定義済みファイルを使用して、カスタムの roles_data ファイルを生成します。
アーキテクチャー 3: カスタムコンポーザブルサービス
専用の ロール を作成し、それらを使用してカスタムの roles_data ファイルを生成します。限られたコンポーザブルサービスの組み合わせしかテスト/検証されていない点に注意してください。Red Hat では、すべてのコンポーザブルサービスの組み合わせに対してサポートを提供することはできません。

6.2. ロール

6.2.1. roles_data ファイルの検証

オーバークラウドの作成プロセスでは、roles_data ファイルを使用して、そのオーバークラウドのロールを定義します。roles_data ファイルには、YAML 形式のロール一覧が含まれます。roles_data 構文の短い例を以下に示します。

- name: Controller
  description: |
    Controller role that has all the controler services loaded and handles
    Database, Messaging and Network functions.
  ServicesDefault:
    - OS::TripleO::Services::AuditD
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::CephClient
    ...
- name: Compute
  description: |
    Basic Compute Node role
  ServicesDefault:
    - OS::TripleO::Services::AuditD
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::CephClient
    ...

コア Heat テンプレートコレクションには、デフォルトの roles_data ファイルが /usr/share/openstack-tripleo-heat-templates/roles_data.yaml に含まれています。デフォルトのファイルは、以下のロール種別を定義します。

  • Controller
  • Compute
  • BlockStorage
  • ObjectStorage
  • CephStorage.

openstack overcloud deploy コマンドにより、デプロイ中にこのファイルが追加されます。このファイルは、-r 引数を使用して、カスタムの roles_data ファイルで上書きすることができます。以下に例を示します。

$ openstack overcloud deploy --templates -r ~/templates/roles_data-custom.yaml

6.2.2. roles_data ファイルの作成

カスタムの roles_data ファイルは、手動で作成することができますが、個別のロールテンプレートを使用して自動生成することも可能です。director は、ロールテンプレートの管理とカスタムの roles_data ファイルの自動生成を行うためのコマンドをいくつか提供しています。

デフォルトロールのテンプレートを一覧表示するには、openstack overcloud role list コマンドを使用します。

$ openstack overcloud role list
BlockStorage
CephStorage
Compute
ComputeHCI
ComputeOvsDpdk
Controller
...

ロールの YAML 定義を確認するには、openstack overcloud role show コマンドを使用します。

$ openstack overcloud role show Compute

カスタムの roles_data ファイルを生成するには、openstack overcloud roles generate コマンドを使用して、複数の事前定義済みロールを単一のロールに統合します。たとえば、以下のコマンドは、ControllerComputeNetworker のロールを単一のファイルに統合します。

$ openstack overcloud roles generate -o ~/roles_data.yaml Controller Compute Networker

-o は、作成するファイルの名前を定義します。

これにより、カスタムの roles_data ファイルが作成されます。ただし、上記の例では、ControllerNetworker ロールを使用しており、その両方に同じネットワークエージェントが含まれています。これは、ネットワークサービスが Controller から Networker ロールにスケーリングされることを意味します。オーバークラウドは、Controller ノードと Networker ノードの間で、ネットワークサービスの負荷のバランスを取ります。

この Networker ロールをスタンドアロンにするには、独自のカスタム Controller ロールと、その他の必要なロールを作成することができます。これにより、独自のカスタムロールから roles_data ファイルを生成できるようになります。

このディレクトリーを、コア Heat テンプレートコレクションから stack ユーザーのホームディレクトリーにコピーします。

$ cp -r /usr/share/openstack-tripleo-heat-templates/roles ~/.

このディレクトリー内でカスタムロールファイルを追加または変更します。このディレクトリーをカスタムロールのソースとして使用するには、前述したロールのサブコマンドに --roles-path オプションを指定します。以下に例を示します。

$ openstack overcloud roles generate -o my_roles_data.yaml \
  --roles-path ~/roles \
  Controller Compute Networker

このコマンドにより、~/roles ディレクトリー内の個々のロールから、単一の my_roles_data.yaml ファイルが生成されます。

注記

デフォルトのロールコレクションには、NetworkerMessagingDatabase のロール用のサービスが含まれていない ControllerOpenStack ロールも含まれています。ControllerOpenStack は、スタンドアロンの NetworkerMessagingDatabase ロールと組み合わせて使用することができます。

6.2.3. サポートされるカスタムロール

以下の表で、/usr/share/openstack-tripleo-heat-templates/roles 内の全サポート対象ロールを説明します。

ロール説明ファイル

BlockStorage

OpenStack Block Storage (cinder) ノード

BlockStorage.yaml

CephAll

完全なスタンドアロンの Ceph Storage ノード。OSD、MON、Object Gateway (RGW)、Object Operations (MDS)、Manager (MGR)、および RBD Mirroring が含まれます。

CephAll.yaml

CephFile

スタンドアロンのスケールアウト Ceph Storage ファイルロール。OSD および Object Operations (MDS) が含まれます。

CephFile.yaml

CephObject

スタンドアロンのスケールアウト Ceph Storage オブジェクトロール。OSD および Object Gateway (RGW) が含まれます。

CephObject.yaml

CephStorage

Ceph Storage OSD ノードロール

CephStorage.yaml

ComputeAlt

代替のコンピュートノードロール

ComputeAlt.yaml

ComputeDVR

DVR 対応のコンピュートノードロール

ComputeDVR.yaml

ComputeHCI

ハイパーコンバージドインフラストラクチャーを持つコンピュートノード。Compute および Ceph OSD サービスが含まれます。

ComputeHCI.yaml

ComputeInstanceHA

コンピュートインスタンス HA ノードロール。environments/compute-instanceha.yaml 環境ファイルと共に使用します。

ComputeInstanceHA.yaml

ComputeLiquidio

Cavium Liquidio Smart NIC を持つコンピュートノード

ComputeLiquidio.yaml

ComputeOvsDpdkRT

コンピュート OVS DPDK RealTime ロール

ComputeOvsDpdkRT.yaml

ComputeOvsDpdk

コンピュート OVS DPDK ロール

ComputeOvsDpdk.yaml

ComputePPC64LE

ppc64le サーバー用 Compute ロール

ComputePPC64LE.yaml

ComputeRealTime

リアルタイムのパフォーマンスに最適化された Compute ロール。このロールを使用する場合には、overcloud-realtime-compute イメージが利用可能で、ロール固有のパラメーター IsolCpusList および NovaVcpuPinSet がリアルタイムコンピュートノードのハードウェアに適切に設定されている必要があります。

ComputeRealTime.yaml

ComputeSriovRT

コンピュート SR-IOV RealTime ロール

ComputeSriovRT.yaml

ComputeSriov

コンピュート SR-IOV ロール

ComputeSriov.yaml

Compute

標準のコンピュートノードロール

Compute.yaml

ControllerAllNovaStandalone

データベース、メッセージング、ネットワーク設定、および OpenStack Compute (nova) コントロールコンポーネントを持たないコントローラーロール。DatabaseMessagingNetworker、および Novacontrol ロールと組み合わせて使用します。

ControllerAllNovaStandalone.yaml

ControllerNoCeph

コアコントローラーサービスは組み込まれているが Ceph Storage (MON) コンポーネントを持たないコントローラーロール。このロールはデータベース、メッセージング、およびネットワーク機能を処理しますが、Ceph Storage 機能は処理しません。

ControllerNoCeph.yaml

ControllerNovaStandalone

OpenStack Compute (nova) コントロールコンポーネントが含まれないコントローラーロール。Novacontrol ロールと組み合わせて使用します。

ControllerNovaStandalone.yaml

ControllerOpenstack

データベース、メッセージング、およびネットワーク設定コンポーネントが含まれないコントローラーロール。DatabaseMessaging、および Networker ロールと組み合わせて使用します。

ControllerOpenstack.yaml

ControllerStorageNfs

すべてのコアサービスが組み込まれ、Ceph NFS を使用するコントローラーロール。このロールはデータベース、メッセージング、およびネットワーク機能を処理します。

ControllerStorageNfs.yaml

Controller

すべてのコアサービスが組み込まれたコントローラーロール。このロールはデータベース、メッセージング、およびネットワーク機能を処理します。

Controller.yaml

Database

スタンドアロンのデータベースロール。Pacemaker を使用して Galera クラスターとして管理されるデータベース。

Database.yaml

HciCephAll

ハイパーコンバージドインフラストラクチャーおよびすべての Ceph Storage サービスを持つコンピュートノード。OSD、MON、Object Gateway (RGW)、Object Operations (MDS)、Manager (MGR)、および RBD Mirroring が含まれます。

HciCephAll.yaml

HciCephFile

ハイパーコンバージドインフラストラクチャーおよび Ceph Storage ファイルサービスを持つコンピュートノード。OSD および Object Operations (MDS) が含まれます。

HciCephFile.yaml

HciCephMon

ハイパーコンバージドインフラストラクチャーおよび Ceph Storage ブロックサービスを持つコンピュートノード。OSD、MON、および Manager が含まれます。

HciCephMon.yaml

HciCephObject

ハイパーコンバージドインフラストラクチャーおよび Ceph Storage オブジェクトサービスを持つコンピュートノード。OSD および Object Gateway (RGW) が含まれます。

HciCephObject.yaml

IronicConductor

Ironic Conductor ノードロール

IronicConductor.yaml

Messaging

スタンドアロンのメッセージングロール。Pacemaker を使用して管理される RabbitMQ。

Messaging.yaml

Networker

スタンドアロンのネットワーク設定ロール。単独で OpenStack Networking (neutron) エージェントを実行します。

Networker.yaml

Novacontrol

スタンドアロンの nova-control ロール。単独で OpenStack Compute (nova) コントロールエージェントを実行します。

Novacontrol.yaml

ObjectStorage

Swift オブジェクトストレージノードロール

ObjectStorage.yaml

Telemetry

すべてのメトリックおよびアラームサービスを持つ Telemetry ロール

Telemetry.yaml

6.2.4. ロールパラメーターの考察

各ロールは、以下のパラメーターを使用します。

name
(必須) 空白または特殊文字を含まないプレーンテキスト形式のロール名。選択した名前により、他のリソースとの競合が発生しないことを確認します。たとえば、Network の代わりに Networker を名前に使用します。
description
(オプション) プレーンテキスト形式のロールの説明
tags

(オプション) ロールのプロパティーを定義するタグの YAML リスト。このパラメーターを使用してcontrollerprimary タグの両方で、プライマリーロールを定義します。

- name: Controller
  ...
  tags:
    - primary
    - controller
  ...
重要

プライマリーロールをタグ付けしない場合には、最初に定義されたロールがプライマリーロールになります。このロールがコントローラーロールとなるようにしてください。

networks
ロール上で設定するネットワークの一覧。デフォルトのネットワークには、ExternalInternalApiStorageStorageMgmtTenantManagement が含まれます。
CountDefault
(任意) このロールにデプロイするデフォルトのノード数
HostnameFormatDefault

(任意) このロールに対するホスト名のデフォルトの形式を定義します。デフォルトの命名規則では、以下の形式が使用されます。

[STACK NAME]-[ROLE NAME]-[NODE ID]

たとえば、コントローラーノード名はデフォルトで以下のように命名されます。

overcloud-controller-0
overcloud-controller-1
overcloud-controller-2
...
disable_constraints
(任意) director のデプロイ時に OpenStack Compute (nova) および OpenStack Image Storage (glance) の制約を無効にするかどうかを定義します。事前プロビジョニング済みのノードでオーバークラウドをデプロイする場合に使用します。詳しくは、『director のインストールと使用方法』「事前にプロビジョニングされたノードを使用した基本的なオーバークラウドの設定」の章を参照してください。
disable_upgrade_deployment
(任意) 特定のロールのアップグレードを無効にするかどうかを定義します。これにより、1 つのロールのノードを個別にアップグレードしてサービスの可用性を確保する方法が提供されます。たとえば、Compute と Swift Storage のロールにこのパラメーターを使用します。
upgrade_batch_size
(任意) アップグレード中に 1 回にまとめて実行するタスクの数を定義します。1 つのタスクは、1 ノードあたりの 1 アップグレードステップとして数えられます。デフォルトのバッチサイズは 1 です。これは、アップグレードプロセスによって各ノードで 1 回に実行されるアップグレードステップは 1 つであることを意味します。バッチサイズを大きくすると、ノードで同時に実行されるタスクの数が増えます。
ServicesDefault
(任意) ノード上で追加するデフォルトのサービス一覧を定義します。詳しくは、「コンポーザブルサービスアーキテクチャーの考察」を参照してください。

これらのパラメーターは、新規ロールの作成方法を指定するのに加えて、追加するサービスを定義します。

openstack overcloud deploy コマンドは、roles_data ファイルのパラメーターをいくつかのJinja2 ベースのテンプレートに統合します。たとえば、特定の時点で 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 ファイルのそれぞれの name パラメーターを使用して、対応する各 OS::Heat::ResourceGroup リソースを命名します。

6.2.5. 新規ロールの作成

以下の例は、OpenStack Dashboard (horizon) のみをホストする新しい Horizon ロールを作成することを目的としています。このような場合には、新規ロールの情報が含まれるカスタムの roles ディレクトリーを作成します。

デフォルトの roles ディレクトリーのカスタムコピーを作成します。

$ cp -r /usr/share/openstack-tripleo-heat-templates/roles ~/.

~/roles/Horizon.yaml という名前の新規ファイルを作成して、ベースおよびコアの OpenStack Dashboard サービスが含まれた Horizon ロールを新規作成します。以下に例を示します。

- name: Horizon
  CountDefault: 1
  HostnameFormatDefault: '%stackname%-horizon-%index%'
  ServicesDefault:
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::Ntp
    - OS::TripleO::Services::Snmp
    - OS::TripleO::Services::Sshd
    - OS::TripleO::Services::Timezone
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::SensuClient
    - OS::TripleO::Services::FluentdClient
    - OS::TripleO::Services::AuditD
    - OS::TripleO::Services::Collectd
    - OS::TripleO::Services::MySQLClient
    - OS::TripleO::Services::Apache
    - OS::TripleO::Services::Horizon

また、CountDefault1 に設定して、デフォルトのオーバークラウドには常に Horizon ノードが含まれるようにした方がよいでしょう。

既存のオーバークラウド内でサービスをスケーリングする場合には、既存のサービスを Controller ロール上に保持します。新規オーバークラウドを作成して、OpenStack Dashboard がスタンドアロンのロールに残るようにするには、Controller ロールの定義から OpenStack Dashboard コンポーネントを削除します。

- name: Controller
  CountDefault: 1
  ServicesDefault:
    ...
    - OS::TripleO::Services::GnocchiMetricd
    - OS::TripleO::Services::GnocchiStatsd
    - OS::TripleO::Services::HAproxy
    - OS::TripleO::Services::HeatApi
    - OS::TripleO::Services::HeatApiCfn
    - OS::TripleO::Services::HeatApiCloudwatch
    - OS::TripleO::Services::HeatEngine
    # - OS::TripleO::Services::Horizon                # Remove this service
    - OS::TripleO::Services::IronicApi
    - OS::TripleO::Services::IronicConductor
    - OS::TripleO::Services::Iscsid
    - OS::TripleO::Services::Keepalived
    ...

roles ディレクトリーをソースに使用して、新しい roles_data ファイルを生成します。

$ openstack overcloud roles generate -o roles_data-horizon.yaml \
  --roles-path ~/roles \
  Controller Compute Horizon

このロールに新しいフレーバーを定義して、特定のノードをタグ付けできるようにする必要がある場合があります。この例では、以下のコマンドを使用して horizon フレーバーを作成します。

$ openstack flavor create --id auto --ram 6144 --disk 40 --vcpus 4 horizon
$ openstack flavor set --property "cpu_arch"="x86_64" --property "capabilities:boot_option"="local" --property "capabilities:profile"="horizon" horizon

以下のコマンドを実行して、ノードを新規フレーバーにタグ付けします。

$ openstack baremetal node set --property capabilities='profile:horizon,boot_option:local' 58c3d07e-24f2-48a7-bbb6-6843f0e8ee13

以下の環境ファイルのスニペットを使用して、Horizon ノードの数とフレーバーを定義します。

parameter_defaults:
  OvercloudHorizonFlavor: horizon
  HorizonCount: 1

openstack overcloud deploy コマンドの実行時には、新しい roles_data ファイルと環境ファイルを指定します。以下に例を示します。

$ openstack overcloud deploy --templates -r ~/templates/roles_data-horizon.yaml -e ~/templates/node-count-flavor.yaml

デプロイメントが完了すると、コントローラーノードが 1 台、コンピュートノードが 1 台、Networker ノードが 1 台の 3 ノード構成のオーバークラウドが作成されます。オーバークラウドのノード一覧を表示するには、以下のコマンドを実行します。

$ openstack server list

6.3. コンポーザブルサービス

6.3.1. ガイドラインおよび制限事項

コンポーザブルノードのアーキテクチャーには、以下のガイドラインおよび制限事項があることに注意してください。

Pacemaker により管理されないサービスの場合:

  • スタンドアロンのカスタムロールにサービスを割り当てることができます。
  • 初回のデプロイメント後に追加のカスタムロールを作成してそれらをデプロイし、既存のサービスをスケーリングすることができます。

Pacemaker により管理されるサービスの場合:

  • スタンドアロンのカスタムロールに Pacemaker の管理対象サービスを割り当てることができます。
  • Pacemaker のノード数の上限は 16 です。Pacemaker サービス (OS::TripleO::Services::Pacemaker) を 16 のノードに割り当てた場合には、それ以降のノードは、代わりに Pacemaker Remote サービス (OS::TripleO::Services::PacemakerRemote) を使用する必要があります。同じロールで Pacemaker サービスと Pacemaker Remote サービスを割り当てることはできません。
  • Pacemaker の管理対象サービスが割り当てられていないロールには、Pacemaker サービス (OS::TripleO::Services::Pacemaker) を追加しないでください。
  • OS::TripleO::Services::Pacemaker または OS::TripleO::Services::PacemakerRemote のサービスが含まれているカスタムロールはスケールアップまたはスケールダウンできません。

一般的な制限事項

  • メジャーバージョン間のアップグレードプロセス中にカスタムロールとコンポーザブルサービスを変更することはできません。
  • オーバクラウドのデプロイ後には、ロールのサービスリストを変更することはできません。オーバークラウドのデプロイの後にサービスリストを変更すると、デプロイでエラーが発生して、ノード上に孤立したサービスが残ってしまう可能性があります。

6.3.2. コンポーザブルサービスアーキテクチャーの考察

Heat のコアテンプレートコレクションには、コンポーザブルサービスのテンプレートが 2 セット含まれています。

  • puppet/services には、コンポーザブルサービスを設定するためのベーステンプレートが含まれています。
  • docker/services には、主要な OpenStack Platform サービスのコンテナー化されたテンプレートが含まれます。これらのテンプレートは、一部のベーステンプレートの拡張として機能し、そのベーステンプレートを参照します。

各テンプレートには目的を特定する記述が含まれています。たとえば、ntp.yaml サービステンプレートには以下のような記述が含まれます。

description: >
  NTP service deployment using puppet, this YAML file
  creates the interface between the HOT template
  and the puppet manifest that actually installs
  and configure NTP.

これらのサービステンプレートは、Red Hat OpenStack Platform デプロイメント固有のリソースとして登録されます。これは、overcloud-resource-registry-puppet.j2.yaml ファイルで定義されている一意な Heat リソース名前空間を使用して各リソースを呼び出すことができることを意味します。サービスはすべて、リソース種別に OS::TripleO::Services 名前空間を使用します。

一部のリソースは、コンポーザブルサービスのベーステンプレートを直接使用します。以下に例を示します。

resource_registry:
  ...
  OS::TripleO::Services::Ntp: puppet/services/time/ntp.yaml
  ...

ただし、コアサービスにはコンテナーが必要なため、コンテナーサービステンプレートを使用してください。たとえば、keystone のコンテナー化されたサービスには、以下を使用します。

resource_registry:
  ...
  OS::TripleO::Services::Keystone: docker/services/keystone.yaml
  ...

これらのコンテナー化されたテンプレートは、通常、Puppet の設定を含めるためにベーステンプレートを参照します。たとえば、docker/services/keystone.yaml テンプレートには、KeystoneBase パラメーター内のベーステンプレートの出力が保管されます。

KeystoneBase:
  type: ../../puppet/services/keystone.yaml

コンテナー化されたテンプレートには、ベーステンプレートからの機能とデータを組み入れることができます。

overcloud.j2.yaml Heat テンプレートには、roles_data.yaml ファイル内の各カスタムロールのサービス一覧を定義するための Jinja2-based コードのセクションが含まれています。

{{role.name}}Services:
  description: A list of service resources (configured in the Heat
               resource_registry) which represent nested stacks
               for each service that should get installed on the {{role.name}} role.
  type: comma_delimited_list
  default: {{role.ServicesDefault|default([])}}

デフォルトのロールの場合は、これにより次のサービス一覧パラメーターが作成されます: ControllerServicesComputeServicesBlockStorageServicesObjectStorageServicesCephStorageServices

roles_data.yaml ファイル内の各カスタムロールのデフォルトのサービスを定義します。たとえば、デフォルトの Controller ロールには、以下の内容が含まれます。

- name: Controller
  CountDefault: 1
  ServicesDefault:
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::CephMon
    - OS::TripleO::Services::CephExternal
    - OS::TripleO::Services::CephRgw
    - OS::TripleO::Services::CinderApi
    - OS::TripleO::Services::CinderBackup
    - OS::TripleO::Services::CinderScheduler
    - OS::TripleO::Services::CinderVolume
    - OS::TripleO::Services::Core
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::Keystone
    - OS::TripleO::Services::GlanceApi
    - OS::TripleO::Services::GlanceRegistry
...

これらのサービスは、次に ControllerServices パラメーターのデフォルト一覧として定義されます。

環境ファイルを使用してサービスパラメーターのデフォルト一覧を上書きすることもできます。たとえば、環境ファイルで ControllerServicesparameter_default として定義して、roles_data.yaml ファイルからのサービス一覧を上書きすることができます。

6.3.3. ロールへのサービスの追加と削除

サービスの追加と削除の基本的な方法では、ノードロールのデフォルトサービス一覧を作成してからサービスを追加/削除します。たとえば、OpenStack Orchestration (heat) をコントローラーノードから削除する場合には、デフォルトの roles ディレクトリーのカスタムコピーを作成します。

$ cp -r /usr/share/openstack-tripleo-heat-templates/roles ~/.

~/roles/Controller.yaml ファイルを編集して、ServicesDefault パラメーターのサービス一覧を変更します。OpenStack Orchestration のサービスまでスクロールしてそれらを削除します。

    - OS::TripleO::Services::GlanceApi
    - OS::TripleO::Services::GlanceRegistry
    - OS::TripleO::Services::HeatApi            # Remove this service
    - OS::TripleO::Services::HeatApiCfn         # Remove this service
    - OS::TripleO::Services::HeatApiCloudwatch  # Remove this service
    - OS::TripleO::Services::HeatEngine         # Remove this service
    - OS::TripleO::Services::MySQL
    - OS::TripleO::Services::NeutronDhcpAgent

新しい roles_data ファイルを生成します。以下に例を示します。

$ openstack overcloud roles generate -o roles_data-no_heat.yaml \
  --roles-path ~/roles \
  Controller Compute Networker

openstack overcloud deploy コマンドを実行する際には、この新しい roles_data ファイルを指定します。以下に例を示します。

$ openstack overcloud deploy --templates -r ~/templates/roles_data-no_heat.yaml

このコマンドにより、コントローラノードには OpenStack Orchestration のサービスがインストールされない状態でオーバークラウドがデプロイされます。

注記

また、カスタムの環境ファイルを使用して、roles_data ファイル内のサービスを無効にすることもできます。無効にするサービスを OS::Heat::None リソースにリダイレクトします。以下に例を示します。

resource_registry:
  OS::TripleO::Services::HeatApi: OS::Heat::None
  OS::TripleO::Services::HeatApiCfn: OS::Heat::None
  OS::TripleO::Services::HeatApiCloudwatch: OS::Heat::None
  OS::TripleO::Services::HeatEngine: OS::Heat::None

6.3.4. 無効化されたサービスの有効化

一部のサービスはデフォルトで無効化されています。これらのサービスは、overcloud-resource-registry-puppet.j2.yaml ファイルで null 操作 (OS::Heat::None) として登録されます。たとえば、Block Storage のバックアップサービス (cinder-backup) は無効化されています。

  OS::TripleO::Services::CinderBackup: OS::Heat::None

このサービスを有効化するには、puppet/services ディレクトリー内の対応する Heat テンプレートにリソースをリンクする環境ファイルを追加します。一部のサービスには、environments ディレクトリー内に事前定義済みの環境ファイルがあります。たとえば、Block Storage のバックアップサービスは、以下のような内容を含む environments/cinder-backup.yaml ファイルを使用します。

resource_registry:
  OS::TripleO::Services::CinderBackup: ../puppet/services/pacemaker/cinder-backup.yaml
...

これにより、デフォルトの null 操作のリソースが上書きされ、これらのサービスが有効になります。openstack overcloud deploy コマンドの実行時に、以下の環境ファイルを指定します。

$ openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/cinder-backup.yaml
ヒント

サービスの有効化/無効化の方法についてのその他の例は、『OpenStack Data Processing』「Installation」を参照してください。この項には、オーバークラウドで OpenStack Data Processing サービス (sahara) を有効にする手順が記載されています。

6.3.5. サービスなしの汎用ノードの作成

Red Hat OpenStack Platform では、OpenStack サービスを一切設定しない汎用の Red Hat Enterprise Linux 7 ノードを作成することができます。これは、コアの Red Hat OpenStack Platform 環境外でソフトウェアをホストする必要がある場合に役立ちます。たとえば、OpenStack Platform は Kibana や Sensu (『Monitoring Tools Configuration Guide』を参照) などのモニタリングツールとの統合を提供します。Red Hat は、それらのモニタリングツールに対するサポートは提供しませんが、director では、それらのツールをホストする汎用の Red Hat Enterprise Linux 7 ノードの作成が可能です。

注記

汎用ノードは、ベースの Red Hat Enterprise Linux 7 イメージではなく、ベースの overcloud-full イメージを引き続き使用します。これは、ノードには何らかの Red Hat OpenStack Platform ソフトウェアがインストールされていますが、有効化または設定されていないことを意味します。

汎用ノードを作成するには、ServicesDefault 一覧なしの新規ロールが必要です。

- name: Generic

カスタムの roles_data ファイル (roles_data_with_generic.yaml) にそのロールを追加します。既存の Controller ロールと Compute ロールは必ず維持してください。

また、プロビジョニングするノードを選択する際には、必要な汎用 Red Hat Enterprise Linux 7 ノード数とフレーバーを指定する環境ファイル (generic-node-params.yaml) も追加することができます。以下に例を示します。

parameter_defaults:
  OvercloudGenericFlavor: baremetal
  GenericCount: 1

openstack overcloud deploy コマンドを実行する際に、ロールのファイルと環境ファイルの両方を指定します。以下に例を示します。

$ openstack overcloud deploy --templates -r ~/templates/roles_data_with_generic.yaml -e ~/templates/generic-node-params.yaml

このコマンドにより、コントローラーノードが 1 台、コンピュートノードが 1 台、汎用 Red Hat Enterprise Linux 7 ノードが 1 台の 3 ノード構成の環境がデプロイされます。