director は、Heat Orchestration Template (HOT) をオーバークラウドデプロイメントプランのテンプレート形式として使用します。HOT 形式のテンプレートは、通常 YAML 形式で表現されます。テンプレートの目的は、Heat が作成するリソースのコレクションである スタック およびリソースの設定を定義/作成することです。リソースとは、コンピュートリソース、ネットワーク設定、セキュリティーグループ、スケーリングルール、カスタムリソースなどの OpenStack のオブジェクトを指します。

Heat テンプレートは、3 つの主要なセクションで構成されます。

以下に、基本的な Heat テンプレートの例を示します。

heat_template_version: 2013-05-23

description: > A very basic Heat template.

parameters:
  key_name:
    type: string
    default: lars
    description: Name of an existing key pair to use for the instance
  flavor:
    type: string
    description: Instance type for the instance to be created
    default: m1.small
  image:
    type: string
    default: cirros
    description: ID or name of the image to use for the instance

resources:
  my_instance:
    type: OS::Nova::Server
    properties:
      name: My Cirros Instance
      image: { get_param: image }
      flavor: { get_param: flavor }
      key_name: { get_param: key_name }

output:
  instance_name:
    description: Get the instance's name
    value: { get_attr: [ my_instance, name ] }

このテンプレートは、リソース種別 type: OS::Nova::Server を使用して、特定のフレーバー、イメージ、キーで my_instance というインスタンスを作成します。このスタックは、My Cirros Instance という instance_name の値を返すことができます。

Heat がテンプレートを処理する際には、テンプレートのスタックとリソーステンプレートの子スタックセットを作成します。これにより、テンプレートで定義したメインのスタックに基づいたスタックの階層が作成されます。以下のコマンドを使用して、スタック階層を表示することができます。

$ openstack stack list --nested

環境ファイルとは、Heat テンプレートをカスタマイズする特別な種類のテンプレートです。このファイルは、3 つの主要な部分で構成されます。

以下に基本的な環境ファイルの例を示します。

resource_registry:
  OS::Nova::Server::MyServer: myserver.yaml

parameter_defaults:
  NetworkName: my_network

parameters:
  MyIP: 192.168.0.1

たとえば、特定の Heat テンプレート (my_template.yaml) からスタックを作成する際に、この環境ファイル (my_env.yaml) を追加します。my_env.yaml ファイルにより、OS::Nova::Server::MyServer という新しいリソース種別が作成されます。myserver.yaml ファイルは、このリソース種別を実装する Heat テンプレートファイルで、このファイルでの設定が元の設定よりも優先されます。my_template.yaml ファイルに OS::Nova::Server::MyServer リソースを含めることができます。

MyIP は、この環境ファイルと共にデプロイを行うメインの Heat テンプレートにしかパラメーターを適用しません。この例では、my_template.yaml のパラメーターにのみ適用します。

NetworkName はメインの Heat テンプレート (上記の例では my_template.yaml) とメインのテンプレートに含まれるリソースに関連付けられたテンプレート (上記の例では OS::Nova::Server::MyServer リソースとその myserver.yaml テンプレート) の両方に適用されます。

director には、オーバークラウドのコア Heat テンプレートコレクションが含まれます。このコレクションは、/usr/share/openstack-tripleo-heat-templates に保存されています。

このコレクションには、多数の Heat テンプレートおよび環境ファイルが含まれます。このテンプレートコレクションで特に注意すべき主要なファイルおよびディレクトリーは、以下のとおりです。

プランの環境メタデータファイルにより、オーバークラウドプランに関するメタデータを定義することができます。この情報は、オーバークラウドプランのインポートとエクスポートに使用されるのに加えて、プランからオーバークラウドを作成する際にも使用されます。

プランの環境ファイルメタデータファイルには、以下のパラメーターが含まれます。

プランの環境ファイルの構文の例を以下に示します。

version: 1.0
name: myovercloud
description: 'My Overcloud Plan'
template: overcloud.yaml
environments:
- path: overcloud-resource-registry-puppet.yaml
- path: environments/containers-default-parameters.yaml
- path: user-environment.yaml
parameter_defaults:
  ControllerCount: 1
  ComputeCount: 1
  OvercloudComputeFlavor: compute
  OvercloudControllerFlavor: control
workflow_parameters:
  tripleo.derive_params.v1.derive_parameters:
    num_phy_cores_per_numa_node_for_pmd: 2

openstack overcloud deploy コマンドに -p オプションを使用して、プランの環境メタデータファイルを指定することができます。以下に例を示します。

(undercloud) $ openstack overcloud deploy --templates \
  -p /my-plan-environment.yaml \
  [OTHER OPTIONS]

以下のコマンドを使用して、既存のオーバークラウドプラン用のプランメタデータを確認することもできます。

(undercloud) $ openstack object save overcloud plan-environment.yaml --file -

デプロイメントのコマンド (openstack overcloud deploy) で -e オプションを使用して、オーバークラウドをカスタマイズするための環境ファイルを追加します。必要に応じていくつでも環境ファイルを追加することができます。ただし、後で実行される環境ファイルで定義されているパラメーターとリソースが優先されることになるため、環境ファイルの順番は重要です。たとえば、以下に示す 2 つの環境ファイルを作成したとします。

resource_registry:
  OS::TripleO::NodeExtraConfigPost: /home/stack/templates/template-1.yaml

parameter_defaults:
  RabbitFDLimit: 65536
  TimeZone: 'Japan'

resource_registry:
  OS::TripleO::NodeExtraConfigPost: /home/stack/templates/template-2.yaml

parameter_defaults:
  TimeZone: 'Hongkong'

次に両環境ファイルを指定してデプロイを実行します。

$ openstack overcloud deploy --templates -e environment-file-1.yaml -e environment-file-2.yaml

この例では、両環境ファイルに共通のリソース種別 (OS::TripleO::NodeExtraConfigPost) と共通のパラメーター (TimeZone) が含まれています。openstack overcloud deploy コマンドは、以下のプロセスを順に実行します。

これにより、オーバークラウドのデフォルト設定が以下のように変更されます。

これにより、複数の環境ファイルの値が競合することなくオーバークラウドにカスタム設定を定義することができます。

オーバークラウドの作成時に、director は /usr/share/openstack-tripleo-heat-templates にある Heat テンプレートのコアセットを使用します。このコアテンプレートコレクションをカスタマイズするには、git ワークフローで変更をトラッキングして更新をマージしてください。以下の git プロセスを使用すると、カスタムテンプレートコレクションの管理に役立ちます。

最新のコアテンプレートコレクションを格納する初期 master ブランチを作成します。このブランチは、カスタムブランチのベースとして使用し、新規テンプレートバージョンをこのブランチにマージします。

このコマンドにより、変更がコミットとして my-customizations ブランチに追加されます。master ブランチを更新するには、master から my-customizations にリベースすると、git はこれらのコミットを更新されたテンプレートに追加します。これは、カスタマイズをトラッキングして、今後テンプレートが更新された際にそれらを再生するのに役立ちます。

master ブランチに最新のコアテンプレートコレクションが含まれるようになりました。これで、my-customization ブランチを更新されたコレクションからリベースできます。

これにより、my-customizations ブランチが更新され、このブランチに追加されたカスタムコミットが再生されます。

リベース中に git で競合が発生した場合には、以下の手順を実行します。

/usr/share/openstack-tripleo-heat-templates のコア Heat テンプレートには、j2.yaml の拡張子が付いた多数のファイルが含まれています。これらのファイルには Jinja2 テンプレート構文が含まれ、director はこれらのファイルを .yaml で終わる等価な静的 Heat テンプレートにレンダリングします。たとえば、メインの overcloud.j2.yaml ファイルは overcloud.yaml にレンダリングされます。director はレンダリングされた overcloud.yaml ファイルを使用します。

Jinja2 タイプの Heat テンプレートでは、Jinja2 構文を使用して反復値のパラメーターおよびリソースを作成します。たとえば、overcloud.j2.yaml ファイルには以下のスニペットが含まれます。

parameters:
...
{% for role in roles %}
  ...
  {{role.name}}Count:
    description: Number of {{role.name}} nodes to deploy
    type: number
    default: {{role.CountDefault|default(0)}}
  ...
{% endfor %}

director が Jinja2 構文をレンダリングする場合、director は roles_data.yaml ファイルで定義されるロールを繰り返し処理し、{{role.name}}Count パラメーターにロール名を代入します。デフォルトの roles_data.yaml ファイルには 5 つのロールが含まれ、ここでの例からは以下のパラメーターが作成されます。

レンダリング済みバージョンのパラメーターの例を以下に示します。

parameters:
  ...
  ControllerCount:
    description: Number of Controller nodes to deploy
    type: number
    default: 1
  ...

director がレンダリングするのは、コア Heat テンプレートディレククトリー内の Jinja2 タイプのテンプレートおよび環境ファイルだけです。Jinja2 テンプレートをレンダリングする際の正しい設定方法を、以下のユースケースで説明します。

環境ファイル: /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.j2.yaml

director はデフォルトのコアテンプレートの場所を使用します (--templates)。director は network-isolation.j2.yaml ファイルを network-isolation.yaml にレンダリングします。openstack overcloud deploy コマンドの実行時には、-e オプションを使用してレンダリングした network-isolation.yaml ファイルの名前を指定します。

$ openstack ovecloud deploy --templates \
    -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml
    ...

環境ファイル: /home/stack/tripleo-heat-templates/environments/network-isolation.j2.yaml

director はカスタムコアテンプレートの場所を使用します (--templates /home/stack/tripleo-heat-templates)。director はカスタムコアテンプレートの network-isolation.j2.yaml ファイルを network-isolation.yaml にレンダリングします。openstack overcloud deploy コマンドの実行時には、-e オプションを使用してレンダリングした network-isolation.yaml ファイルの名前を指定します。

$ openstack ovecloud deploy --templates /home/stack/tripleo-heat-templates \
    -e /home/stack/tripleo-heat-templates/environments/network-isolation.yaml
    ...

環境ファイル: /home/stack/tripleo-heat-templates/environments/network-isolation.j2.yaml

この場合、director はカスタムコアテンプレートの場所を使用します (--templates /home/stack/tripleo-heat-templates)。しかし、選択した network-isolation.j2.yaml はカスタムコアテンプレートに存在しないので、network-isolation.yaml にはレンダリング されません。この設定ではデプロイメントに失敗します。

タイムゾーンを設定するための Heat テンプレート (puppet/services/time/timezone.yaml) には TimeZone パラメーターが含まれています。TimeZone パラメーターの値を空白のままにすると、オーバークラウドはデフォルトで時刻を UTC に設定します。

タイムゾーンの一覧を取得するには、timedatectl list-timezones コマンドを実行します。アジアのタイムゾーンを取得するコマンド例を以下に示します。

$ sudo timedatectl list-timezones|grep "Asia"

タイムゾーンを特定したら、環境ファイルの TimeZone パラメーターを設定します。以下に示す環境ファイルの例では、TimeZone の値を Asia/Tokyo に設定しています。

parameter_defaults:
  TimeZone: 'Asia/Tokyo'

新規の ML2/OVN デプロイメントではデフォルトで DVR が有効化され、新規の ML2/OVS デプロイメントではデフォルトで無効化されています。OpenStack Networking (neutron) API 用の Heat テンプレート (deployment/neutron/neutron-api-container-puppet.yaml) には、分散仮想ルーティング (DVR) を有効化/無効化するためのパラメーターが含まれています。DVR を無効にするには、環境ファイルで以下のように設定します。

parameter_defaults:
  NeutronEnableDVR: false

特定の設定では、RabbitMQ サーバーのファイル記述子の上限を高くする必要がある場合があります。deployment/rabbitmq/rabbitmq-container-puppet.yaml の Heat テンプレートを使用して RabbitFDLimit パラメーターを必要な上限値に設定することができます。以下の設定を環境ファイルに追加します。

parameter_defaults:
  RabbitFDLimit: 65536

デプロイメント時にパラメーターを初期設定し、それ以降のデプロイメント操作 (更新またはスケーリング操作など) ではそのパラメーターを無効にしなければならない場合があります。たとえば、オーバークラウドの作成時にカスタム RPM を含めるには、以下のパラメーターを追加します。

parameter_defaults:
  DeployArtifactURLs: ["http://www.example.com/myfile.rpm"]

それ以降のデプロイメントでこのパラメーターを無効にするには、パラメーターを削除するだけでは不十分です。そうではなく、パラメーターに空の値を設定します。

parameter_defaults:
  DeployArtifactURLs: []

これにより、それ以降のデプロイメント操作ではパラメーターは設定されなくなります。

[ROLE]Parameters パラメーターを使用して特定のロールのパラメーターを設定します。ここで、[ROLE] はコンポーザブルロールに置き換えてください。

たとえば、director はコントローラーノードとコンピュートノードの両方に logrotate を設定します。コントローラーノードとコンピュートノードに異なる logrotate パラメーターを設定するには、「ControllerParameters」 パラメーターと 「ComputeParameters」 パラメーターの両方が含まれる環境ファイルを作成し、特定のロールごとに logrotate パラメーターを設定します。

parameter_defaults:
  ControllerParameters:
    LogrotateMaxsize: 10M
    LogrotatePurgeAfterDays: 30
  ComputeParameters:
    LogrotateMaxsize: 20M
    LogrotatePurgeAfterDays: 15

Red Hat OpenStack Platform director は、設定用のパラメーターを多数提供しています。場合によっては、設定すべき特定のオプションとそれに対応する director のパラメーターを特定するのが困難なことがあります。director でオプションを設定するには、以下のワークフローに従ってオプションを確認し、特定のオーバークラウドパラメーターにマップしてください。

最終的なマッピングは、以下の表のとおりです。

オーバークラウドの環境ファイルで KeystoneNotificationFormat を設定すると、オーバークラウドの設定中に keystone.conf ファイルの notification_format オプションが設定されます。

director は、オーバークラウドの初回作成時に全ノードに対して設定を行います。そのために、director は OS::TripleO::NodeUserData リソース種別を使用して呼び出すことのできる cloud-init を使用します。

以下の例では、全ノード上でカスタム IP アドレスを使用してネームサーバーを更新します。各ノードの resolv.conf に特定のネームサーバーを追加するスクリプトを実行するために、まず基本的な Heat テンプレート (/home/stack/templates/nameserver.yaml) を作成します。OS::TripleO::MultipartMime リソース種別を使用して、この設定スクリプトを送信することができます。

heat_template_version: 2014-10-16

description: >
  Extra hostname configuration

resources:
  userdata:
    type: OS::Heat::MultipartMime
    properties:
      parts:
      - config: {get_resource: nameserver_config}

  nameserver_config:
    type: OS::Heat::SoftwareConfig
    properties:
      config: |
        #!/bin/bash
        echo "nameserver 192.168.1.1" >> /etc/resolv.conf

outputs:
  OS::stack_id:
    value: {get_resource: userdata}

OS::TripleO::NodeUserData リソース種別として Heat テンプレートを登録する環境ファイル (/home/stack/templates/firstboot.yaml) を作成します。

resource_registry:
  OS::TripleO::NodeUserData: /home/stack/templates/nameserver.yaml

初回起動の設定を追加するには、最初にオーバークラウドを作成する際に、その他の環境ファイルと共にこの環境ファイルをスタックに追加します。以下に例を示します。

$ openstack overcloud deploy --templates \
    ...
    -e /home/stack/templates/firstboot.yaml \
    ...

-e を使用して、オーバークラウドスタックに環境ファイルを適用します。

これにより、ノード作成後の初回起動時に設定がすべてのノードに追加されます。これ以降は (たとえば、オーバークラウドスタックの更新時)、これらのテンプレートを追加してもこれらのスクリプトは実行されません。

オーバークラウドは、OpenStack コンポーネントのコア設定に Puppet を使用します。director にはフックのセットが用意されており、初回起動が完了してコア設定が開始する前に、特定ノードロールのカスタム設定が提供されます。これには、以下のフックが含まれます。

以下の例では、ノードの resolv.conf に変数のネームサーバーを書き込むスクリプトを実行するために、まず基本的な Heat テンプレート (/home/stack/templates/nameserver.yaml) を作成します。

heat_template_version: 2014-10-16

description: >
  Extra hostname configuration

parameters:
  server:
    type: json
  nameserver_ip:
    type: string
  DeployIdentifier:
    type: string

resources:
  CustomExtraConfigPre:
    type: OS::Heat::SoftwareConfig
    properties:
      group: script
      config:
        str_replace:
          template: |
            #!/bin/sh
            echo "nameserver _NAMESERVER_IP_" > /etc/resolv.conf
          params:
            _NAMESERVER_IP_: {get_param: nameserver_ip}

  CustomExtraDeploymentPre:
    type: OS::Heat::SoftwareDeployment
    properties:
      server: {get_param: server}
      config: {get_resource: CustomExtraConfigPre}
      actions: ['CREATE','UPDATE']
      input_values:
        deploy_identifier: {get_param: DeployIdentifier}

outputs:
  deploy_stdout:
    description: Deployment reference, used to trigger pre-deploy on changes
    value: {get_attr: [CustomExtraDeploymentPre, deploy_stdout]}

上記の例では、resources セクションには以下のパラメーターが含まれます。

Heat テンプレートをロールベースのリソース種別として登録する環境ファイル (/home/stack/templates/pre_config.yaml) を作成します。たとえば、コントローラーノードだけに適用するには、ControllerExtraConfigPre フックを使用します。

resource_registry:
  OS::TripleO::ControllerExtraConfigPre: /home/stack/templates/nameserver.yaml

parameter_defaults:
  nameserver_ip: 192.168.1.1

この設定を適用するには、オーバークラウドの作成時または更新時に、その他の環境ファイルと共にこの環境ファイルをスタックに追加します。以下に例を示します。

$ openstack overcloud deploy --templates \
    ...
    -e /home/stack/templates/pre_config.yaml \
    ...

これにより、オーバークラウドの初回作成またはそれ以降の更新において、コア設定前にすべてのコントローラーノードに設定が適用されます。

オーバークラウドは、OpenStack コンポーネントのコア設定に Puppet を使用します。director にはフックが用意されており、初回起動が完了してコア設定が開始する前に、すべてのノード種別が設定されます。

以下の例では、各ノードの resolv.conf に変数のネームサーバーを追加するスクリプトを実行するために、基本的な Heat テンプレート (/home/stack/templates/nameserver.yaml) を作成します。

heat_template_version: 2014-10-16

description: >
  Extra hostname configuration

parameters:
  server:
    type: string
  nameserver_ip:
    type: string
  DeployIdentifier:
    type: string

resources:
  CustomExtraConfigPre:
    type: OS::Heat::SoftwareConfig
    properties:
      group: script
      config:
        str_replace:
          template: |
            #!/bin/sh
            echo "nameserver _NAMESERVER_IP_" >> /etc/resolv.conf
          params:
            _NAMESERVER_IP_: {get_param: nameserver_ip}

  CustomExtraDeploymentPre:
    type: OS::Heat::SoftwareDeployment
    properties:
      server: {get_param: server}
      config: {get_resource: CustomExtraConfigPre}
      actions: ['CREATE','UPDATE']
      input_values:
        deploy_identifier: {get_param: DeployIdentifier}

outputs:
  deploy_stdout:
    description: Deployment reference, used to trigger pre-deploy on changes
    value: {get_attr: [CustomExtraDeploymentPre, deploy_stdout]}

上記の例では、resources セクションには以下のパラメーターが含まれます。

次に、OS::TripleO::NodeExtraConfig リソース種別として Heat テンプレートを登録する環境ファイル (/home/stack/templates/pre_config.yaml) を作成します。

resource_registry:
  OS::TripleO::NodeExtraConfig: /home/stack/templates/nameserver.yaml

parameter_defaults:
  nameserver_ip: 192.168.1.1

この設定を適用するには、オーバークラウドの作成時または更新時に、その他の環境ファイルと共にこの環境ファイルをスタックに追加します。以下に例を示します。

$ openstack overcloud deploy --templates \
    ...
    -e /home/stack/templates/pre_config.yaml \
    ...

これにより、オーバークラウドの初回作成またはそれ以降の更新において、コア設定前にすべてのノードに設定が適用されます。

オーバークラウドの初回作成時または更新時において、オーバークラウドの作成が完了してからすべてのロールに設定の追加が必要となる可能性があります。このような場合には、以下の設定後フックを使用します。

以下の例では、各ノードの resolv.conf に変数のネームサーバーを追加するスクリプトを実行するために、まず基本的な Heat テンプレート (/home/stack/templates/nameserver.yaml) を作成します。

heat_template_version: 2014-10-16

description: >
  Extra hostname configuration

parameters:
  servers:
    type: json
  nameserver_ip:
    type: string
  DeployIdentifier:
    type: string
  EndpointMap:
    default: {}
    type: json

resources:
  CustomExtraConfig:
    type: OS::Heat::SoftwareConfig
    properties:
      group: script
      config:
        str_replace:
          template: |
            #!/bin/sh
            echo "nameserver _NAMESERVER_IP_" >> /etc/resolv.conf
          params:
            _NAMESERVER_IP_: {get_param: nameserver_ip}

  CustomExtraDeployments:
    type: OS::Heat::SoftwareDeploymentGroup
    properties:
      servers:  {get_param: servers}
      config: {get_resource: CustomExtraConfig}
      actions: ['CREATE','UPDATE']
      input_values:
        deploy_identifier: {get_param: DeployIdentifier}

上記の例では、resources セクションには以下のパラメーターが含まれます。

OS::TripleO::NodeExtraConfigPost: リソース種別として Heat テンプレートを登録する環境ファイル (/home/stack/templates/post_config.yaml) を作成します。

resource_registry:
  OS::TripleO::NodeExtraConfigPost: /home/stack/templates/nameserver.yaml

parameter_defaults:
  nameserver_ip: 192.168.1.1

この設定を適用するには、オーバークラウドの作成時または更新時に、その他の環境ファイルと共にこの環境ファイルをスタックに追加します。以下に例を示します。

$ openstack overcloud deploy --templates \
    ...
    -e /home/stack/templates/post_config.yaml \
    ...

これにより、オーバークラウドの初回作成またはそれ以降の更新において、コア設定後にすべてのノードに設定が適用されます。

Heat テンプレートコレクションには、特定のノード種別に追加の設定を渡すためのパラメーターセットが含まれています。これらのパラメーターでは、ノードの Puppet 設定用 hieradata として設定を保存します。これらのパラメーターは以下のとおりです。

デプロイ後の設定プロセスに設定を追加するには、parameter_defaults セクションにこれらのパラメーターが記載された環境ファイルを作成します。たとえば、コンピュートホストに確保するメモリーを 1024 MB に増やし VNC キーマップを日本語に指定するには、以下のように設定します。

parameter_defaults:
  ComputeExtraConfig:
    nova::compute::reserved_host_memory: 1024
    nova::compute::vnc_keymap: ja

openstack overcloud deploy を実行する際に、この環境ファイルを指定します。

Heat テンプレートコレクションを使用して、個別のノードの Puppet hieradata を設定することができます。そのためには、ノードのイントロスペクションデータの一部として保存されているシステム UUID を取得します。

$ openstack baremetal introspection data save 9dcc87ae-4c6d-4ede-81a5-9b20d7dc4a14 | jq .extra.system.product.uuid

このコマンドは、システム UUID を出力します。以下に例を示します。

"F5055C6C-477F-47FB-AFE5-95C6928C407F"

このシステム UUID は、ノード固有の hieradata を定義して per_node.yaml テンプレートを事前設定フックに登録する環境ファイルで使用します。以下に例を示します。

resource_registry:
  OS::TripleO::ComputeExtraConfigPre: /usr/share/openstack-tripleo-heat-templates/puppet/extraconfig/pre_deploy/per_node.yaml
parameter_defaults:
  NodeDataLookup: '{"F5055C6C-477F-47FB-AFE5-95C6928C407F": {"nova::compute::vcpu_pin_set": [ "2", "3" ]}}'

openstack overcloud deploy を実行する際に、この環境ファイルを指定します。

per_node.yaml テンプレートは、各システム UUID に対応するノード上に heiradata ファイルのセットを生成して、定義した hieradata を含めます。UUID が定義されていない場合には、生成される hieradata ファイルは空になります。上記の例では、per_node.yaml テンプレートは (OS::TripleO::ComputeExtraConfigPre フックに従って) 全コンピュートノード上で実行されますが、システム UUID が F5055C6C-477F-47FB-AFE5-95C6928C407F のコンピュートノードのみが hieradata を受け取ります。

これにより、特定の要件に応じて各ノードを調整することができます。

NodeDataLookup について の詳細は、『 コンテナー化された Red Hat Ceph を持つオーバークラウドのデプロイ』の「Ceph Storage クラスター設定 の設定」を参照してください。

特定の状況では、追加のコンポーネントをオーバークラウドノードにインストールして設定する必要がある場合があります。そのためには、カスタムの Puppet マニフェストを使用して、主要な設定が完了してからノードに適用します。基本的な例として、各ノードに motd をインストールするとします。そのためには、まず Puppet 設定を起動する Heat テンプレート (/home/stack/templates/custom_puppet_config.yaml) を作成します。

heat_template_version: 2014-10-16

description: >
  Run Puppet extra configuration to set new MOTD

parameters:
  servers:
    type: json

resources:
  ExtraPuppetConfig:
    type: OS::Heat::SoftwareConfig
    properties:
      config: {get_file: motd.pp}
      group: puppet
      options:
        enable_hiera: True
        enable_facter: False

  ExtraPuppetDeployments:
    type: OS::Heat::SoftwareDeploymentGroup
    properties:
      config: {get_resource: ExtraPuppetConfig}
      servers: {get_param: servers}

これは、テンプレート内に /home/stack/templates/motd.pp を追加し、設定するノードに渡します。motd.pp ファイル自体には、motd のインストールと設定を行うための Puppet クラスが含まれています。

OS::TripleO::NodeExtraConfigPost: リソース種別として Heat テンプレートを登録する環境ファイル (/home/stack/templates/puppet_post_config.yaml) を作成します。

resource_registry:
  OS::TripleO::NodeExtraConfigPost: /home/stack/templates/custom_puppet_config.yaml

オーバークラウドのスタックを作成または更新する際に、その他の環境ファイルと共にこの環境ファイルを含めます。

$ openstack overcloud deploy --templates \
    ...
    -e /home/stack/templates/puppet_post_config.yaml \
    ...

これにより、motd.pp からの設定がオーバークラウド内の全ノードに適用されます。

rhsm コンポーザブルサービスは、Ansible を介してオーバークラウドノードを登録する方法を提供します。デフォルトの roles_data ファイルの各ロールには、OS::TripleO::Services::Rhsm リソースが含まれており、これはデフォルトで無効になっています。サービスを有効にするには、このリソースを rhsm コンポーザブルサービスのファイルに登録します。

resource_registry:
  OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/deployment/rhsm/rhsm-baremetal-ansible.yaml

rhsm コンポーザブルサービスは RhsmVars パラメーターを受け入れます。これにより、登録に必要な複数のサブパラメーターを定義することができます。以下に例を示します。

parameter_defaults:
  RhsmVars:
    rhsm_repos:
      - rhel-8-for-x86_64-baseos-eus-rpms
      - rhel-8-for-x86_64-appstream-eus-rpms
      - rhel-8-for-x86_64-highavailability-eus-rpms
      - ansible-2.8-for-rhel-8-x86_64-rpms
      - advanced-virt-for-rhel-8-x86_64-rpms
      - openstack-16-for-rhel-8-x86_64-rpms
      - rhceph-4-osd-for-rhel-8-x86_64-rpms
      - rhceph-4-mon-for-rhel-8-x86_64-rpms
      - rhceph-4-tools-for-rhel-8-x86_64-rpms
      - fast-datapath-for-rhel-8-x86_64-rpms
    rhsm_username: "myusername"
    rhsm_password: "p@55w0rd!"
    rhsm_org_id: "1234567"

RhsmVars パラメーターをロール固有のパラメーター (例: ControllerParameters) と共に使用することにより、異なるノードタイプ用の特定のリポジトリーを有効化する場合に柔軟性を提供することもできます。

次の項には、rhsm コンポーザブルサービスで使う RhsmVars パラメーターと共に使用することのできるサブパラメーターの一覧を記載します。

すべての Ansible パラメーターを把握するには、ロールに関するドキュメント を参照してください。

rhsm コンポーザブルサービスがどのように機能し、どのように設定するかを理解したので、以下の手順に従って独自の登録情報を設定することができます。

以下の手順に従って、rhsm コンポーザブルサービスを有効化して設定する環境ファイルを作成します。director はこの環境ファイルを使用して、ノードを登録し、サブスクライブします。

特定のオーバークラウドロールに対して登録情報を提供することもできます。次の項では、その例を説明します。

rhsm コンポーザブルサービスをロールごとに適用することができます。たとえば、コントローラーノード、コンピュートノード、および Ceph Storage ノードに、異なる設定セットを適用することができます。

ノードを Red Hat カスタマーポータルではなく Red Hat Satellite に登録するには、rhsm コンポーザブルサービスを有効にして設定する環境ファイルを作成します。その手順を以下に示します。

これらの手順は、オーバークラウドで rhsm を有効化して設定します。ただし、以前のバージョンの Red Hat OpenStack Platform の rhel-registration メソッドを使用していた場合には、それを無効にして Ansible ベースのメソッドに切り替える必要があります。従来の rhel-registration メソッドから Ansible ベースのメソッドに切り替えるには、以下の手順に従ってください。

従来の rhel-registration メソッドは、bash スクリプトを実行してオーバークラウドの登録を処理します。このメソッド用のスクリプトと環境ファイルは、/usr/share/openstack-tripleo-heat-templates/extraconfig/pre_deploy/rhel-registration/ のコア Heat テンプレートコレクションにあります。

rhel-registration メソッドを rhsm コンポーザブルサービスに切り替えるには、以下の手順を実施します。

このメソッドは、rhel-registration パラメーターを rhsm サービスのパラメーターに置き換えて、サービスを有効化する Heat リソースを変更します。

resource_registry:
  OS::TripleO::NodeExtraConfig: rhel-registration.yaml

必要に応じて、以下を行ってください。

resource_registry:
  OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/deployment/rhsm/rhsm-baremetal-ansible.yaml

デプロイメントに /usr/share/openstack-tripleo-heat-templates/environments/rhsm.yaml 環境ファイルを追加して、サービスを有効にすることもできます。

rhel-registration メソッドから rhsm メソッドへの情報の移行を容易に行うには、以下の表を使用してパラメーターとその値をマッピングします。

これで、rhsm サービスの環境ファイルの設定が完了し、オーバークラウドの次のデプロイメント操作で追加することができます。

本項では、rhsm の設定をオーバークラウドに適用する方法について説明します。

director ベースの登録メソッドに加えて、デプロイメント後に手動で登録することもできます。

デプロイしたオーバークラウドで、手動による Ansible ベースの登録を実施することができます。そのためには、director の動的インベントリースクリプトを使用して、ホストグループとしてノードロールを定義します。続いて ansible-playbook を使用して定義したノードロールに対して Playbook を実行します。以下の例で、Playbook を使用してコントローラーノードを手動で登録する方法を説明します。

Red Hat OpenStack Platform 16.0 は、Red Hat Enterprise Linux 8.1 でサポートされています。オーバークラウドをデプロイしたら、オーバークラウドのリポジトリーを Red Hat Enterprise Linux 8.1 リリースにロックします。

$ sudo subscription-manager release --set=8.1

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

director は、OpenStack Platform のコアサービスをオーバークラウド上にコンテナーとしてインストールします。コンテナー化されたサービス用のテンプレートは、/usr/share/openstack-tripleo-heat-templates/deployment/ にあります。

コンテナー化されたサービスを使用するノードではすべて、OS::TripleO::Services::Podman サービスを有効化する必要があります。カスタムロール設定用の roles_data.yaml ファイルを作成する際には、ベースコンポーザブルサービスとともに OS::TripleO::Services::Podman サービスをコンテナー化されたサービスとして追加します。たとえば、IronicConductor ロールには、以下の定義を使用します。

- name: IronicConductor
  description: |
    Ironic Conductor node role
  networks:
    InternalApi:
      subnet: internal_api_subnet
    Storage:
      subnet: storage_subnet
  HostnameFormatDefault: '%stackname%-ironic-%index%'
  ServicesDefault:
    - OS::TripleO::Services::Aide
    - OS::TripleO::Services::AuditD
    - OS::TripleO::Services::BootParams
    - OS::TripleO::Services::CACerts
    - OS::TripleO::Services::CertmongerUser
    - OS::TripleO::Services::Collectd
    - OS::TripleO::Services::Docker
    - OS::TripleO::Services::Fluentd
    - OS::TripleO::Services::IpaClient
    - OS::TripleO::Services::Ipsec
    - OS::TripleO::Services::IronicConductor
    - OS::TripleO::Services::IronicPxe
    - OS::TripleO::Services::Kernel
    - OS::TripleO::Services::LoginDefs
    - OS::TripleO::Services::MetricsQdr
    - OS::TripleO::Services::MySQLClient
    - OS::TripleO::Services::ContainersLogrotateCrond
    - OS::TripleO::Services::Podman
    - OS::TripleO::Services::Rhsm
    - OS::TripleO::Services::SensuClient
    - OS::TripleO::Services::Snmp
    - OS::TripleO::Services::Timesync
    - OS::TripleO::Services::Timezone
    - OS::TripleO::Services::TripleoFirewall
    - OS::TripleO::Services::TripleoPackages
    - OS::TripleO::Services::Tuned

コンテナー化されたサービスのテンプレートにはそれぞれ、outputs セクションがあります。このセクションでは、director の OpenStack Orchestration (Heat) サービスに渡すデータセットを定義します。テンプレートには、標準のコンポーザブルサービスパラメーター (「ロールパラメーターの考察」を参照) に加えて、コンテナーの設定固有のパラメーターセットが含まれます。

オーバークラウドの設定には、イメージの取得先およびその保存方法を定義するための初期レジストリーの設定が必要です。コンテナーイメージを準備するのに使用することのできる環境ファイルを生成およびカスタマイズするには、以下の手順を実施します。

コンテナー準備用のデフォルトファイル (containers-prepare-parameter.yaml) には、ContainerImagePrepare heat パラメーターが含まれます。このパラメーターで、イメージのセットを準備するためのさまざまな設定を定義します。

parameter_defaults:
  ContainerImagePrepare:
  - (strategy one)
  - (strategy two)
  - (strategy three)
  ...

それぞれの設定では、サブパラメーターのセットにより使用するイメージやイメージの使用方法を定義することができます。以下の表には、ContainerImagePrepare の各設定で使用することのできるサブパラメーターの情報をまとめています。

set パラメーターには、複数の キー:値 定義を設定することができます。

ContainerImageRegistryCredentials パラメーターは、コンテナーレジストリーをそのレジストリーに対して認証を行うためのユーザー名とパスワードにマッピングします。

コンテナーレジストリーでユーザー名およびパスワードが必要な場合には、ContainerImageRegistryCredentials を使用して以下の構文で認証情報を設定することができます。

  ContainerImagePrepare:
  - push_destination: true
    set:
      namespace: registry.redhat.io/...
      ...
  ContainerImageRegistryCredentials:
    registry.redhat.io:
      my_username: my_password

上記の例の my_username および my_password を、実際の認証情報に置き換えてください。Red Hat では、個人のユーザー認証情報を使用する代わりに、レジストリーサービスアカウントを作成し、それらの認証情報を使用して registry.redhat.io コンテンツにアクセスすることを推奨します。詳しくは、「Red Hat コンテナーレジストリーの認証」を参照してください。

ContainerImageRegistryLogin パラメーターは、デプロイ中のシステムのレジストリーへのログインを制御するために使用されます。push_destination が false に設定されている、または使用されていない場合は、これを true に設定する必要があります。

  ContainerImagePrepare:
  - set:
      namespace: registry.redhat.io/...
      ...
  ContainerImageRegistryCredentials:
    registry.redhat.io:
      my_username: my_password
  ContainerImageRegistryLogin: true

ContainerImagePrepare パラメーターの値は YAML リストです。したがって、複数のエントリーを指定することができます。以下の例で、2 つのエントリーを指定するケースを説明します。この場合、director はすべてのイメージの最新バージョンを使用しますが、nova-api イメージについてのみ、16.0-44 とタグ付けされたバージョンを使用します。

ContainerImagePrepare:
- tag_from_label: "{version}-{release}"
  push_destination: true
  excludes:
  - nova-api
  set:
    namespace: registry.redhat.io/rhosp-rhel8
    name_prefix: openstack-
    name_suffix: ''
    tag: 16.0
- push_destination: true
  includes:
  - nova-api
  set:
    namespace: registry.redhat.io/rhosp-rhel8
    tag: 16.0-44

includes および excludes のパラメーターでは、各エントリーのイメージの絞り込みをコントロールするのに正規表現が使用されます。includes 設定と一致するイメージが、excludes と一致するイメージに優先します。イメージが一致するとみなされるためには、名前に includes または excludes の正規表現の値が含まれている必要があります。

イメージの準備中にイメージを変更し、変更したそのイメージで直ちにデプロイすることが可能です。イメージを変更するシナリオを以下に示します。

準備プロセス中にイメージを変更するには、変更する各イメージで Ansible ロールを呼び出します。ロールはソースイメージを取得して必要な変更を行い、その結果をタグ付けします。prepare コマンドでイメージを目的のレジストリーにプッシュし、変更したイメージを参照するように heat パラメーターを設定することができます。

Ansible ロール tripleo-modify-image は要求されたロールインターフェースに従い、変更のユースケースに必要な処理を行います。ContainerImagePrepare パラメーターの変更固有のキーを使用して、変更をコントロールします。

tripleo-modify-image ロールが処理するユースケースを選択するには、tasks_from 変数をそのロールで必要なファイルに設定します。

イメージを変更する ContainerImagePrepare エントリーを開発およびテストする場合には、イメージが想定どおりに変更されることを確認するために、追加のオプションを指定せずにイメージの準備コマンドを実行します。

sudo openstack tripleo container image prepare \
  -e ~/containers-prepare-parameter.yaml

以下の ContainerImagePrepare エントリーの例では、アンダークラウドホストで dnf リポジトリー設定を使用して、イメージのパッケージをすべて更新します。

ContainerImagePrepare:
- push_destination: true
  ...
  modify_role: tripleo-modify-image
  modify_append_tag: "-updated"
  modify_vars:
    tasks_from: yum_update.yml
    compare_host_packages: true
    yum_repos_dir_path: /etc/yum.repos.d
  ...

RPM ファイルのディレクトリーをコンテナーイメージにインストールすることができます。この機能は、ホットフィックスやローカルパッケージビルドなど、パッケージリポジトリーからは入手できないパッケージのインストールに役立ちます。たとえば、以下の ContainerImagePrepare エントリーにより、nova-compute イメージだけにホットフィックスパッケージがインストールされます。

ContainerImagePrepare:
- push_destination: true
  ...
  includes:
  - nova-compute
  modify_role: tripleo-modify-image
  modify_append_tag: "-hotfix"
  modify_vars:
    tasks_from: rpm_install.yml
    rpms_path: /home/stack/nova-hotfix-pkgs
  ...

柔軟性を高めるために、Dockerfile を含むディレクトリーを指定して必要な変更を加えることが可能です。tripleo-modify-image ロールを呼び出すと、ロールは Dockerfile.modified ファイルを生成し、これにより FROM ディレクティブが変更され新たな LABEL ディレクティブが追加されます。以下の例では、nova-compute イメージでカスタム Dockerfile が実行されます。

ContainerImagePrepare:
- push_destination: true
  ...
  includes:
  - nova-compute
  modify_role: tripleo-modify-image
  modify_append_tag: "-hotfix"
  modify_vars:
    tasks_from: modify_image.yml
    modify_dir_path: /home/stack/nova-custom
  ...

/home/stack/nova-custom/Dockerfile ファイルの例を以下に示します。USER root ディレクティブを実行した後は、元のイメージのデフォルトユーザーに戻す必要があります。

FROM registry.redhat.io/rhosp-rhel8/openstack-nova-compute:latest

USER "root"

COPY customize.sh /tmp/
RUN /tmp/customize.sh

USER "nova"

デフォルトでは、オーバークラウドはサービスをプロビジョニングネットワークに割り当てます。ただし、director はオーバークラウドのネットワークトラフィックを分離したネットワークに分割することができます。分離ネットワークを使用するために、オーバークラウドにはこの機能を有効にする環境ファイルが含まれています。director のコア Heat テンプレートの environments/network-isolation.j2.yaml ファイルは Jinja2 形式のファイルで、コンポーザブルネットワークファイル内の各ネットワークのポートおよび仮想 IP をすべて定義します。レンダリングすると、すべてのリソースレジストリーと共に network-isolation.yaml ファイルが同じ場所に生成されます。以下に例を示します。

resource_registry:
  # networks as defined in network_data.yaml
  OS::TripleO::Network::Storage: ../network/storage.yaml
  OS::TripleO::Network::StorageMgmt: ../network/storage_mgmt.yaml
  OS::TripleO::Network::InternalApi: ../network/internal_api.yaml
  OS::TripleO::Network::Tenant: ../network/tenant.yaml
  OS::TripleO::Network::External: ../network/external.yaml

  # Port assignments for the VIPs
  OS::TripleO::Network::Ports::StorageVipPort: ../network/ports/storage.yaml
  OS::TripleO::Network::Ports::StorageMgmtVipPort: ../network/ports/storage_mgmt.yaml
  OS::TripleO::Network::Ports::InternalApiVipPort: ../network/ports/internal_api.yaml
  OS::TripleO::Network::Ports::ExternalVipPort: ../network/ports/external.yaml
  OS::TripleO::Network::Ports::RedisVipPort: ../network/ports/vip.yaml

  # Port assignments by role, edit role definition to assign networks to roles.
  # Port assignments for the Controller
  OS::TripleO::Controller::Ports::StoragePort: ../network/ports/storage.yaml
  OS::TripleO::Controller::Ports::StorageMgmtPort: ../network/ports/storage_mgmt.yaml
  OS::TripleO::Controller::Ports::InternalApiPort: ../network/ports/internal_api.yaml
  OS::TripleO::Controller::Ports::TenantPort: ../network/ports/tenant.yaml
  OS::TripleO::Controller::Ports::ExternalPort: ../network/ports/external.yaml

  # Port assignments for the Compute
  OS::TripleO::Compute::Ports::StoragePort: ../network/ports/storage.yaml
  OS::TripleO::Compute::Ports::InternalApiPort: ../network/ports/internal_api.yaml
  OS::TripleO::Compute::Ports::TenantPort: ../network/ports/tenant.yaml

  # Port assignments for the CephStorage
  OS::TripleO::CephStorage::Ports::StoragePort: ../network/ports/storage.yaml
  OS::TripleO::CephStorage::Ports::StorageMgmtPort: ../network/ports/storage_mgmt.yaml

このファイルの最初のセクションには、OS::TripleO::Network::* リソースのリソースレジストリーの宣言が含まれます。デフォルトでは、これらのリソースは、ネットワークを作成しない OS::Heat::None リソースタイプを使用します。これらのリソースを各ネットワークの YAML ファイルにリダイレクトすると、それらのネットワークの作成が可能となります。

次の数セクションで、各ロールのノードに IP アドレスを指定します。コントローラーノードでは、ネットワークごとに IP が指定されます。コンピュートノードとストレージノードは、ネットワークのサブネットでの IP が指定されます。

オーバークラウドネットワークのその他の機能 (「9章カスタムコンポーザブルネットワーク」および「10章カスタムネットワークインターフェーステンプレート」を参照) は、このネットワーク分離の環境ファイルに依存します。したがって、デプロイメントコマンドにレンダリングしたファイルの名前を含める必要があります。以下に例を示します。

$ openstack overcloud deploy --templates \
    ...
    -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
    ...

network_data ファイルで、デフォルトの分離ネットワーク設定を定義します。本手順では、カスタム network_data ファイルを作成し、そのファイルをネットワーク要件に応じて設定する方法について説明します。

各ネットワークについて、以下の項目を編集します。

-n オプションを使用して、カスタム network_data ファイルをデプロイメントに含めます。-n オプションを設定しないと、デプロイメントコマンドはデフォルトのネットワーク情報を使用します。

オーバークラウドのネットワーク設定には、ネットワークインターフェースのテンプレートセットが必要です。これらのテンプレートは YAML 形式の標準の Heat テンプレートです。director がロール内の各ノードを正しく設定できるように、それぞれのロールには NIC のテンプレートが必要です。

すべての NIC のテンプレートには、標準の Heat テンプレートと同じセクションが含まれています。

/usr/share/openstack-tripleo-heat-templates/network/config のデフォルト NIC テンプレートは、Jinja2 構文のメリットを生かしてテンプレートを容易にレンダリングします。たとえば、single-nic-vlans 設定からの以下のスニペットにより、各ネットワークの VLAN セットがレンダリングされます。

{%- for network in networks if network.enabled|default(true) and network.name in role.networks %}
- type: vlan
  vlan_id:
    get_param: {{network.name}}NetworkVlanID
  addresses:
  - ip_netmask:
      get_param: {{network.name}}IpSubnet
{%- if network.name in role.default_route_networks %}

デフォルトのコンピュートノードでは、Storage、Internal API、および Tenant ネットワークのネットワーク情報だけがレンダリングされます。

- type: vlan
  vlan_id:
    get_param: StorageNetworkVlanID
  device: bridge_name
  addresses:
  - ip_netmask:
      get_param: StorageIpSubnet
- type: vlan
  vlan_id:
    get_param: InternalApiNetworkVlanID
  device: bridge_name
  addresses:
  - ip_netmask:
      get_param: InternalApiIpSubnet
- type: vlan
  vlan_id:
    get_param: TenantNetworkVlanID
  device: bridge_name
  addresses:
  - ip_netmask:
      get_param: TenantIpSubnet

デフォルトの Jinja2 ベースのテンプレートを標準の YAML バージョンにレンダリングする方法は、「10章カスタムネットワークインターフェーステンプレート」で説明します。この YAML バージョンを、カスタマイズのベースとして使用することができます。

director の /usr/share/openstack-tripleo-heat-templates/network/config/ には、ほとんどの標準的なネットワークシナリオに適するテンプレートが含まれています。以下の表は、各 NIC テンプレートセットおよびテンプレートを有効にするために使用する環境ファイルの概要をまとめたものです。

それぞれのデフォルト NIC テンプレートセットには、role.role.j2.yaml テンプレートが含まれます。このファイルは、Jinja2 を使用して各コンポーザブルロールのファイルをさらにレンダリングします。たとえば、オーバークラウドで Compute、Controller、および Ceph Storage ロールが使用される場合には、デプロイメントにより、role.role.j2.yaml をベースに以下のようなテンプレートが新たにレンダリングされます。

以下の手順で、デフォルト NIC テンプレートの 1 つを使用して基本的なネットワーク分離を有効にする方法について説明します。ここでは、単一 NIC および VLAN のテンプレート (single-nic-vlans) を用いています。

以下に例を示します。

$ openstack overcloud deploy --templates \
    ...
    -n /home/stack/network_data.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml \
    ...

デフォルトのオーバークラウドでは、以下に示す事前定義済みのネットワークセグメントのセットが使用されます。

コンポーザブルネットワークを使用して、さまざまなサービス用のネットワークを追加することができます。たとえば、NFS トラフィック専用のネットワークがある場合には、複数のロールに提供できます。

director は、デプロイメントおよび更新段階中のカスタムネットワークの作成をサポートしています。このような追加のネットワークは、Ironic ベアメタルノード、システム管理に使用したり、異なるロール用に別のネットワークを作成するのに使用したりすることができます。また、これは、トラフィックが複数のネットワーク間でルーティングされる、分離型のデプロイメント用に複数のネットワークセットを作成するのに使用することもできます。

1 つのデータファイル (network_data.yaml) で、デプロイされるネットワークの一覧を管理します。-n オプションを使用して、このファイルをデプロイメントコマンドに含めます。このオプションを指定しないと、デプロイメントにはデフォルトのファイル (/usr/share/openstack-tripleo-heat-templates/network_data.yaml) が使用されます。

以下の手順で、オーバークラウドにさらにコンポーザブルネットワークを追加する方法について説明します。

network_data ファイルでは、以下のパラメーターを使用することができます。

-n オプションを使用して、カスタム network_data ファイルをデプロイメントに含めます。-n オプションを指定しないと、デプロイメントコマンドはデフォルトのネットワークセットを使用します。

コンポーザブルネットワークをご自分の環境で定義したロールに割り当てることができます。たとえば、カスタム StorageBackup ネットワークを Ceph Storage ノードに追加することができます。

以下の手順で、オーバークラウドのロールにコンポーザブルネットワークを追加する方法について説明します。

openstack overcloud deploy コマンドを実行する際に、-r オプションを使用して roles_data ファイルを指定します。-r オプションを設定しないと、デプロイメントコマンドはデフォルトのロールセットとそれに対応する割り当て済みのネットワークを使用します。

各 OpenStack サービスは、リソースレジストリーでデフォルトのネットワーク種別に割り当てられます。これらのサービスは、そのネットワーク種別に割り当てられたネットワーク内の IP アドレスにバインドされます。OpenStack サービスはこれらのネットワークに分割されますが、実際の物理ネットワーク数はネットワーク環境ファイルに定義されている数と異なる可能性があります。環境ファイル (たとえば /home/stack/templates/service-reassignments.yaml) で新たにネットワークマッピングを定義することで、OpenStack サービスを異なるネットワーク種別に再割り当てすることができます。ServiceNetMap パラメーターにより、各サービスに使用するネットワーク種別が決定されます。

たとえば、ハイライトしたセクションを変更して、Storage Management ネットワークサービスを Storage Backup ネットワークに再割り当てすることができます。

parameter_defaults:
  ServiceNetMap:
    SwiftMgmtNetwork: storage_backup
    CephClusterNetwork: storage_backup

これらのパラメーターを storage_backup に変更すると、対象のサービスは Storage Management ネットワークではなく、Storage Backup ネットワークに割り当てられます。つまり、parameter_defaults セットを設定するのは Storage Backup ネットワーク用だけで、Storage Management ネットワーク用に設定する必要はありません。

director はカスタムの ServiceNetMap パラメーターの定義を ServiceNetMapDefaults から取得したデフォルト値の事前定義済みリストにマージして、デフォルト値を上書きします。director はカスタマイズされた設定を含む完全な一覧を ServiceNetMap に返し、その一覧は多様なサービスのネットワーク割り当ての設定に使用されます。

サービスマッピングは、Pacemaker を使用するノードの network_data ファイルで vip: true と設定されているネットワークに適用されます。オーバークラウドの負荷分散サービスにより、トラフィックが仮想 IP から特定のサービスのエンドポイントにリダイレクトされます。

以下の手順で、デフォルト NIC テンプレートの 1 つを使用してカスタムコンポーザブルネットワークを有効にする方法について説明します。ここでは、単一 NIC および VLAN (single-nic-vlans) を用いています。

以下に例を示します。

$ openstack overcloud deploy --templates \
    ...
    -n /home/stack/network_data.yaml \
    -r /home/stack/roles_data.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/net-single-nic-with-vlans.yaml \
    -e /home/stack/templates/service-reassignments.yaml \
    ...

上記の例に示すコマンドにより、追加のカスタムネットワークを含め、コンポーザブルネットワークがオーバークラウドのノード全体にデプロイされます。

network_data.yaml ファイルを使用して、デフォルトネットワークのユーザー表示名を変更することができます。

これらの名前を変更するのに、name フィールドを変更しないでください。代わりに、name_lower フィールドをネットワークの新しい名前に変更し、新しい名前で ServiceNetMap を更新します。

デフォルトの NIC テンプレートは、特定のネットワーク構成には適しない場合があります。たとえば、特定のネットワークレイアウトに適した、専用のカスタム NIC テンプレートを作成しなければならない場合があります。また、コントロールサービスとデータサービスを異なる NIC に分離しなければならない場合があります。この場合、サービス/NIC 間の割り当ては以下のマッピングとなります。

カスタムインターフェーステンプレートの設定を簡素化するために、以下の手順で、Jinja2 構文のデフォルト NIC テンプレートをレンダリングする方法について説明します。これにより、レンダリングしたテンプレートをカスタム設定のベースとして使用することができます。

本項では、custom-nics のカスタム NIC テンプレートのアーキテクチャーおよびテンプレートを編集する際の推奨事項について説明します。

resources:
  OsNetConfigImpl:
    type: OS::Heat::SoftwareConfig
    properties:
      group: script
      config:
        str_replace:
          template:
            get_file: /usr/share/openstack-tripleo-heat-templates/network/scripts/run-os-net-config.sh
          params:
            $network_config:
              network_config:

これは、os-net-config がノードでネットワークプロパティーを設定するのに使用する設定ファイルを作成するスクリプト (run-os-net-config.sh) を実行します。network_config セクションには、run-os-net-config.sh スクリプトに送信されるカスタムのネットワークインターフェースのデータが記載されます。このカスタムインターフェースデータは、デバイスの種別に基づいた順序で並べます。

以下のセクションでは、ネットワークインターフェースの種別および各ネットワークインターフェースで使用されるパラメーターを定義します。

以下に例を示します。

  - type: interface
    name: nic2

以下に例を示します。

  - type: vlan
    vlan_id:{get_param: ExternalNetworkVlanID}
    addresses:
      - ip_netmask: {get_param: ExternalIpSubnet}

以下に例を示します。

          - type: ovs_bond
            name: bond1
            members:
            - type: interface
              name: nic2
            - type: interface
              name: nic3

以下に例を示します。

      - type: ovs_bridge
        name: bridge_name
        addresses:
        - ip_netmask:
            list_join:
            - /
            - - {get_param: ControlPlaneIp}
              - {get_param: ControlPlaneSubnetCidr}
        members:
          - type: interface
            name: interface_name
      - type: vlan
        device: bridge_name
        vlan_id:
          {get_param: ExternalNetworkVlanID}
        addresses:
          - ip_netmask:
              {get_param: ExternalIpSubnet}

以下に例を示します。

      - type: linux_bond
        name: bond1
        members:
        - type: interface
          name: nic2
          primary: true
        - type: interface
          name: nic3
        bonding_options: "mode=802.3ad"

nic2 が primary: true と設定されている点に注意してください。これにより、ボンディングが必ず nic2 の MAC アドレスを使用するようになります。

以下に例を示します。

      - type: linux_bridge
        name: bridge_name
        addresses:
          - ip_netmask:
              list_join:
                - /
                - - {get_param: ControlPlaneIp}
                  - {get_param: ControlPlaneSubnetCidr}
        members:
          - type: interface
            name: interface_name
      - type: vlan
        device: bridge_name
        vlan_id:
          {get_param: ExternalNetworkVlanID}
        addresses:
          - ip_netmask:
              {get_param: ExternalIpSubnet}

以下に例を示します。

  - type: interface
    name: nic2
    ...
    routes:
      - ip_netmask: 10.1.2.0/24
        default: true
        next_hop:
          get_param: EC2MetadataIp

以下のコントローラーノード NIC テンプレートのスニペットは、コントロールグループを OVS ブリッジから分離するカスタムネットワークシナリオのための設定方法を示しています。

resources:
  OsNetConfigImpl:
    type: OS::Heat::SoftwareConfig
    properties:
      group: script
      config:
        str_replace:
          template:
            get_file: /usr/share/openstack-tripleo-heat-templates/network/scripts/run-os-net-config.sh
          params:
            $network_config:
              network_config:

              # NIC 1 - Provisioning
              - type: interface
                name: nic1
                use_dhcp: false
                addresses:
                - ip_netmask:
                    list_join:
                    - /
                    - - get_param: ControlPlaneIp
                      - get_param: ControlPlaneSubnetCidr
                routes:
                - ip_netmask: 169.254.169.254/32
                  next_hop:
                    get_param: EC2MetadataIp

              # NIC 2 - Control Group
              - type: interface
                name: nic2
                use_dhcp: false
              - type: vlan
                device: nic2
                vlan_id:
                  get_param: InternalApiNetworkVlanID
                addresses:
                - ip_netmask:
                    get_param: InternalApiIpSubnet
              - type: vlan
                device: nic2
                vlan_id:
                  get_param: StorageMgmtNetworkVlanID
                addresses:
                - ip_netmask:
                    get_param: StorageMgmtIpSubnet
              - type: vlan
                device: nic2
                vlan_id:
                  get_param: ExternalNetworkVlanID
                addresses:
                - ip_netmask:
                    get_param: ExternalIpSubnet
                routes:
                - default: true
                  next_hop:
                    get_param: ExternalInterfaceDefaultRoute

              # NIC 3 - Data Group
              - type: ovs_bridge
                name: bridge_name
                dns_servers:
                  get_param: DnsServers
                members:
                - type: interface
                  name: nic3
                  primary: true
                - type: vlan
                  vlan_id:
                    get_param: StorageNetworkVlanID
                  addresses:
                  - ip_netmask:
                      get_param: StorageIpSubnet
                - type: vlan
                  vlan_id:
                    get_param: TenantNetworkVlanID
                  addresses:
                  - ip_netmask:
                      get_param: TenantIpSubnet

                # NIC 4 - Management
                - type: interface
                  name: nic4
                  use_dhcp: false
                  addresses:
                  - ip_netmask: {get_param: ManagementIpSubnet}
                  routes:
                  - default: true
                    next_hop: {get_param: ManagementInterfaceDefaultRoute}

このテンプレートは、4 つのネットワークインターフェースを使用し、タグ付けられた複数の VLAN デバイスを、番号付きのインターフェース (nic1 から nic4) に割り当てます。nic3 では、Storage ネットワークおよび Tenant ネットワークをホストする OVS ブリッジを作成します。その結果、以下のレイアウトが作成されます。

コンポーザブルネットワークを使用する場合には、process-templates.py スクリプトによりレンダリングされる固定のテンプレートに、network_data および roles_data ファイルで定義したネットワークおよびロールが含まれます。レンダリングされた NIC テンプレートで以下の点を確認してください。

カスタムネットワークがロールで使用されなくても、各固定ファイルにはすべてのカスタムネットワークの全パラメーター定義が必要です。レンダリングされたテンプレートにこれらのパラメーターが含まれていることを確認してください。たとえば、StorageBackup ネットワークが Ceph ノードだけに追加される場合でも、すべてのロールで NIC 設定テンプレートの parameters セクションに以下の定義を含める必要があります。

parameters:
  ...
  StorageBackupIpSubnet:
    default: ''
    description: IP address/subnet on the external network
    type: string
  ...

必要な場合には、VLAN ID とゲートウェイ IP の parameters 定義を含めることもできます。

parameters:
  ...
  StorageBackupNetworkVlanID:
    default: 60
    description: Vlan ID for the management network traffic.
    type: number
  StorageBackupDefaultRoute:
	  description: The default route of the storage backup network.
	  type: string
  ...

カスタムネットワーク用の IpSubnet パラメーターは、各ロールのパラメーター定義に含まれています。ただし、Ceph ロールは StorageBackup ネットワークを使用する唯一のロールなので、Ceph ロールの NIC 設定テンプレートのみがそのテンプレートの network_config セクションの StorageBackup パラメーターを使用することになります。

      $network_config:
        network_config:
        - type: interface
          name: nic1
          use_dhcp: false
          addresses:
          - ip_netmask:
              get_param: StorageBackupIpSubnet

カスタムネットワーク環境ファイル (ここでは、/home/stack/templates/custom-network-configuration.yaml) は Heat の環境ファイルで、オーバークラウドのネットワーク環境を記述し、カスタムネットワークインターフェース設定テンプレートを参照します。IP アドレス範囲と合わせてネットワークのサブネットおよび VLAN を定義します。また、これらの値をローカルの環境用にカスタマイズします。

resource_registry のセクションには、各ノードロールのカスタムネットワークインターフェーステンプレートへの参照が含まれます。登録された各リソースには、以下の形式を使用します。

[ROLE] はロール名で、[FILE] はその特定のロールに対応するネットワークインターフェーステンプレートです。以下に例を示します。

resource_registry:
  OS::TripleO::Controller::Net::SoftwareConfig: /home/stack/templates/custom-nics/controller.yaml

parameter_defaults セクションには、各ネットワーク種別のネットワークオプションを定義するパラメーター一覧が含まれます。

以下の表は、ネットワーク環境ファイルの parameter_defaults セクションで使用することのできるパラメーターをまとめたものです。これらのパラメーターで、ご自分の NIC テンプレートのデフォルトパラメーターの値を上書きします。

NIC テンプレートを有効にしカスタムパラメーターを設定するための環境ファイルの例を、以下に示します。

resource_registry:
  OS::TripleO::BlockStorage::Net::SoftwareConfig:
    /home/stack/templates/nic-configs/cinder-storage.yaml
  OS::TripleO::Compute::Net::SoftwareConfig:
    /home/stack/templates/nic-configs/compute.yaml
  OS::TripleO::Controller::Net::SoftwareConfig:
    /home/stack/templates/nic-configs/controller.yaml
  OS::TripleO::ObjectStorage::Net::SoftwareConfig:
    /home/stack/templates/nic-configs/swift-storage.yaml
  OS::TripleO::CephStorage::Net::SoftwareConfig:
    /home/stack/templates/nic-configs/ceph-storage.yaml

parameter_defaults:
  # Gateway router for the provisioning network (or Undercloud IP)
  ControlPlaneDefaultRoute: 192.0.2.254
  # The IP address of the EC2 metadata server. Generally the IP of the Undercloud
  EC2MetadataIp: 192.0.2.1
  # Define the DNS servers (maximum 2) for the overcloud nodes
  DnsServers: ["8.8.8.8","8.8.4.4"]
  NeutronExternalNetworkBridge: "''"

以下の手順で、カスタム NIC テンプレートを使用してネットワーク分離を有効にする方法について説明します。

以下に例を示します。

$ openstack overcloud deploy --templates \
    ...
    -n /home/stack/network_data.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
    -e /usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml \
    -e /home/stack/templates/custom-network-configuration.yaml \
    ...

インターフェースは個別に変更を加える必要がある場合があります。以下の例では、DHCP アドレスでインフラストラクチャーネットワークへ接続するための 2 つ目の NIC、ボンディング用の 3 つ目/4 つ目の NIC を使用するのに必要となる変更を紹介します。

network_config:
  # Add a DHCP infrastructure network to nic2
  - type: interface
    name: nic2
    use_dhcp: true
  - type: ovs_bridge
    name: br-bond
    members:
      - type: ovs_bond
        name: bond1
        ovs_options:
          get_param: BondInterfaceOvsOptions
        members:
          # Modify bond NICs to use nic3 and nic4
          - type: interface
            name: nic3
            primary: true
          - type: interface
            name: nic4

ネットワークインターフェースのテンプレートは、実際のインターフェース名 (eth0、eth1、enp0s25) または番号付きのインターフェース (nic1、nic2、nic3) のいずれかを使用します。名前付きのインターフェース (eth0、eno2 など) ではなく、番号付きのインターフェース (nic1、nic2 など) を使用した場合には、ロール内のホストのネットワークインターフェースは、全く同じである必要はありません。たとえば、あるホストに em1 と em2 のインターフェースが指定されており、別のホストには eno1 と eno2 が指定されていても、両ホストの NIC は nic1 および nic2 として参照することができます。

番号付きのインターフェースの順序は、名前付きのネットワークインターフェースのタイプの順序と同じです。

番号付きの NIC スキームは、ライブのインターフェース (例: スイッチに接続されているケーブル) のみ考慮します。4 つのインターフェースを持つホストと、6 つのインターフェースを持つホストがある場合に、各ホストで nic1 から nic4 を使用してケーブル 4 本のみを結線します。

物理インターフェースを特定のエイリアスにハードコーディングすることができます。これにより、nic1、nic2・・・としてマッピングする物理 NIC を事前に定義することができます。また、MAC アドレスを指定したエイリアスにマッピングすることもできます。

インターフェースは、環境ファイルを使用してエイリアスにマッピングされます。以下の例では、各ノードの nic1 および nic2 にエントリーが事前定義されます。

parameter_defaults:
  NetConfigDataLookup:
    node1:
      nic1: "em1"
      nic2: "em2"
    node2:
      nic1: "00:50:56:2F:9F:2E"
      nic2: "em2"

得られた設定は、os-net-config により適用されます。これぞれのノードで、適用された設定が /etc/os-net-config/mapping.yaml の interface_mapping に表示されます。

ホストのデフォルトルートを設定するには、2 とおりの方法があります。インターフェースが DHCP を使用しており、DHCP がゲートウェイアドレスを提供している場合には、システムは対象のゲートウェイに対してデフォルトルートを使用します。それ以外の場合には、静的な IP を使用するインターフェースにデフォルトのルートを設定することができます。

Linux カーネルは複数のデフォルトゲートウェイをサポートしますが、最も低いメトリックが指定されたゲートウェイのみを使用します。複数の DHCP インターフェースがある場合には、どのデフォルトゲートウェイが使用されるかが推測できなくなります。このような場合には、デフォルトルートを使用しないインターフェースに defroute: false を設定することを推奨します。

たとえば、DHCP インターフェース (nic3) をデフォルトのルートに指定する場合があります。そのためには、以下の YAML を使用して別の DHCP インターフェース (nic2) 上のデフォルトのルートを無効にします。

# No default route on this DHCP interface
- type: interface
  name: nic2
  use_dhcp: true
  defroute: false
# Instead use this DHCP interface as the default route
- type: interface
  name: nic3
  use_dhcp: true

静的な IP が指定されたインターフェースに静的なルートを設定するには、サブネットにルートを指定します。たとえば、Internal API ネットワーク上のゲートウェイ 172.17.0.1 を経由するサブネット 10.1.2.0/24 にルートを設定します。

    - type: vlan
      device: bond1
      vlan_id:
        get_param: InternalApiNetworkVlanID
      addresses:
      - ip_netmask:
          get_param: InternalApiIpSubnet
      routes:
      - ip_netmask: 10.1.2.0/24
        next_hop: 172.17.0.1

最大伝送単位 (MTU) の設定は、単一の Ethernet フレームで転送されるデータの最大量を決定します。各フレームはヘッダー形式でデータを追加するため、より大きい値を指定すると、オーバーヘッドが少なくなります。デフォルト値が 1500 で、1500 より高い値を使用する場合には、ジャンボフレームをサポートするスイッチポートの設定が必要になります。大半のスイッチは、9000 以上の MTU 値をサポートしていますが、それらの多くはデフォルトで 1500 に指定されています。

VLAN の MTU は、物理インターフェースの MTU を超えることができません。ボンディングまたはインターフェースで MTU 値を含めるようにしてください。

ジャンボフレームは、Storage、Storage Management、Internal API、Tenant ネットワークのすべてにメリットをもたらします。テストでは、VXLAN トンネルと合わせてジャンボフレームを使用した場合に、プロジェクトのネットワークスループットが大幅に向上しました。

- type: ovs_bond
  name: bond1
  mtu: 9000
  ovs_options: {get_param: BondInterfaceOvsOptions}
  members:
    - type: interface
      name: nic3
      mtu: 9000
      primary: true
    - type: interface
      name: nic4
      mtu: 9000

# The external interface should stay at default
- type: vlan
  device: bond1
  vlan_id:
    get_param: ExternalNetworkVlanID
  addresses:
    - ip_netmask:
        get_param: ExternalIpSubnet
  routes:
    - ip_netmask: 0.0.0.0/0
      next_hop:
        get_param: ExternalInterfaceDefaultRoute

# MTU 9000 for Internal API, Storage, and Storage Management
- type: vlan
  device: bond1
  mtu: 9000
  vlan_id:
    get_param: InternalApiNetworkVlanID
  addresses:
  - ip_netmask:
      get_param: InternalApiIpSubnet

Neutron は、Neutron の外部のブリッジマッピングにデフォルトの空の文字列を使用します。これにより、物理インターフェースは br-ex の代わりに br-int を使用して直接マッピングされます。このモデルにより、VLAN または複数の物理接続のいずれかを使用した複数の Floating IP ネットワークが可能となります。

ネットワーク分離環境ファイルの parameter_defaults セクションで NeutronExternalNetworkBridge パラメーターを使用します。

  parameter_defaults:
    # Set to "br-ex" when using floating IPs on the native VLAN
    NeutronExternalNetworkBridge: "''"

ブリッジのネイティブ VLAN 上で使用する Floating IP ネットワークが 1 つのみの場合には、オプションで Neutron の外部ブリッジを設定できます。これにより、パケットが通過するブリッジは 2 つではなく 1 つとなり、Floating IP ネットワーク上でトラフィックを渡す際の CPU の使用率がやや低くなる可能性があります。

トランキングされたインターフェースまたはボンディングに、ネイティブ VLAN を使用したネットワークがある場合には、IP アドレスはブリッジに直接割り当てられ、VLAN インターフェースはありません。

たとえば、External ネットワークがネイティブ VLAN に存在する場合には、ボンディングの設定は以下のようになります。

network_config:
  - type: ovs_bridge
    name: bridge_name
    dns_servers:
      get_param: DnsServers
    addresses:
      - ip_netmask:
          get_param: ExternalIpSubnet
    routes:
      - ip_netmask: 0.0.0.0/0
        next_hop:
          get_param: ExternalInterfaceDefaultRoute
    members:
      - type: ovs_bond
        name: bond1
        ovs_options:
          get_param: BondInterfaceOvsOptions
        members:
          - type: interface
            name: nic3
            primary: true
          - type: interface
            name: nic4

複数の物理 NIC をバンドルして、単一の論理チャネルを形成することができます。この構成はボンディングとも呼ばれます。ボンディング構成にすることにより、高可用性システムに冗長性を持たせたり、スループットを向上させたりすることができます。

Red Hat OpenStack Platform では、Linux ボンディング、Open vSwitch (OVS) カーネルボンディング、および OVS-DPDK ボンディングがサポートされます。

ボンディングは、オプションの Link Aggregation Control Protocol (LACP) と共に使用することができます。LACP は動的ボンディングを作成するネゴシエーションプロトコルで、これにより負荷分散機能および耐障害性を持たせることができます。

Red Hat では、OvS カーネルボンディング (ボンディング種別: ovs_bond) ではなく Linux カーネルボンディング (ボンディング種別: linux_bond) の使用を推奨します。ユーザーモードボンディング (ボンディング種別: ovs_dpdk_bond) は、カーネルモードブリッジ (種別: ovs_bridge) ではなくユーザーモードブリッジ (種別: ovs_user_bridge) と共に使用する必要があります。ただし、ovs_bridge と ovs_user_bridge を同じノード上で組み合わせないでください。

コントロールネットワークおよびストレージネットワークの場合は、Red Hat では VLAN を使用する Linux ボンディングと LACP の組み合わせを推奨します。OVS ボンディングを使用すると、更新、ホットフィックス等の理由により OVS または neutron エージェントが再起動すると、コントロールプレーンの中断が生じる可能性があるためです。Linux ボンディング/LACP/VLAN の構成であれば、OVS の中断を懸念することなく NIC を管理できます。

1 つの VLAN を使用する Linux ボンディングの設定例を以下に示します。

params:
            $network_config:
              network_config:

              - type: linux_bond
                name: bond_api
                bonding_options: "mode=active-backup"
                use_dhcp: false
                dns_servers:
        `          get_param: DnsServers
                members:
                - type: interface
                  name: nic3
                  primary: true
                - type: interface
                  name: nic4

              - type: vlan
                vlan_id:
                  get_param: InternalApiNetworkVlanID
                device: bond_api
                addresses:
                - ip_netmask:
                    get_param: InternalApiIpSubnet

OVS ブリッジにプラグインした Linux ボンディングの例を以下に示します。

params:
            $network_config:
              network_config:

            -  type: ovs_bridge
                name: br-tenant
                use_dhcp: false
                mtu: 9000
                members:
                  - type: linux_bond
                    name: bond_tenant
                    bonding_options: "mode=802.3ad updelay=1000 miimon=100"
                    use_dhcp: false
                    dns_servers:
                      get_param: DnsServers
                    members:
                    - type: interface
                      name: p1p1
                      primary: true
                    - type: interface
                      name: p1p2
                  - type: vlan
                    device: bond_tenant
                    vlan_id: {get_param: TenantNetworkVlanID}
                    addresses:
                      -
                        ip_netmask: {get_param: TenantIpSubnet}

OVS ユーザースペースブリッジの例を以下に示します。

params:
            $network_config:
              network_config:

          -    type: ovs_user_bridge
                name: br-ex
                use_dhcp: false
                members:
                - type: ovs_dpdk_bond
                  name: dpdkbond0
                  mtu: 2140
                  ovs_options: {get_param: BondInterfaceOvsOptions}
                  #ovs_extra:
                  #- set interface dpdk0 mtu_request=$MTU
                  #- set interface dpdk1 mtu_request=$MTU
                  rx_queue:
                    get_param: NumDpdkInterfaceRxQueues
                  members:
                  - type: ovs_dpdk_port
                    name: dpdk0
                    mtu: 2140
                    members:
                    - type: interface
                      name: p1p1
                  - type: ovs_dpdk_port
                    name: dpdk1
                    mtu: 2140
                    members:
                    - type: interface
                      name: p1p2

オーバークラウドは、Open vSwtich (OVS) を介してネットワークを提供します。以下の表は、ボンディングされたインターフェースに関する OVS カーネルおよび OVS-DPDK のサポートについてまとめています。OVS/OVS-DPDK balance-tcp モードは、テクノロジープレビューとしてのみ利用可能です。

以下の例に示すように、ネットワークの環境ファイルで BondInterfaceOvsOptions パラメーターを使用して、ボンディングされたインターフェースを設定することができます。

parameter_defaults:
  BondInterfaceOvsOptions: "bond_mode=balance-slb"

ネットワークインターフェースのテンプレートにおいて、LACP を Linux ボンディングで使用することができます。以下に例を示します。

      - type: linux_bond
        name: bond1
        members:
        - type: interface
          name: nic2
        - type: interface
          name: nic3
        bonding_options: "mode=802.3ad lacp_rate=[fast|slow] updelay=1000 miimon=100"

以下の表には、これらのオプションについての説明と、ハードウェアに応じた代替手段を記載しています。

以下の手順では、特定のノードにノード ID を割り当てます。ノード ID には、controller-0、controller-1、compute-0、compute-1 などがあります。

最初のステップでは、デプロイメント時に Compute スケジューラーが照合するノード別ケイパビリティーとしてこの ID を割り当てます。以下に例を示します。

openstack baremetal node set --property capabilities='node:controller-0,boot_option:local' <id>

これにより、node:controller-0 のケイパビリティーがノードに割り当てられます。0 から始まる一意の連番のインデックスを使用して、すべてのノードに対してこのパターンを繰り返します。指定したロール (コントローラー、コンピュート、各ストレージロール) のすべてのノードが同じようにタグ付けされるようにします。このようにタグ付けしないと、Compute スケジューラーはこのケイパビリティーを正しく照合しません。

次のステップでは、Heat 環境ファイル (例: scheduler_hints_env.yaml) を作成します。このファイルは、スケジューラーヒントを使用して、各ノードのケイパビリティーと照合します。以下に例を示します。

parameter_defaults:
  ControllerSchedulerHints:
    'capabilities:node': 'controller-%index%'

これらのスケジューラーヒントを使用するには、オーバークラウドの作成時に、overcloud deploy コマンドに scheduler_hints_env.yaml 環境ファイルを追加します。

これらのパラメーターを使用して、ロールごとに同じアプローチを使用することができます。

$ openstack overcloud deploy ... --control-flavor baremetal --compute-flavor baremetal ...

「特定のノード ID の割り当て」のノード ID の設定と組み合わせて、director は特定のカスタムホスト名を各ノードに割り当てることもできます。システムの場所 (例: rack2-row12) を定義する必要がある場合や、インベントリー ID を照合する必要がある場合、またはカスタムのホスト名が必要となるその他の状況において、カスタムのホスト名は便利です。

ノードのホスト名をカスタマイズするには、「特定のノード ID の割り当て」 で作成した scheduler_hints_env.yaml ファイルなどの環境ファイルの HostnameMap パラメーターを使用します。以下に例を示します。

parameter_defaults:
  ControllerSchedulerHints:
    'capabilities:node': 'controller-%index%'
  ComputeSchedulerHints:
    'capabilities:node': 'compute-%index%'
  HostnameMap:
    overcloud-controller-0: overcloud-controller-prod-123-0
    overcloud-controller-1: overcloud-controller-prod-456-0
    overcloud-controller-2: overcloud-controller-prod-789-0
    overcloud-compute-0: overcloud-compute-prod-abc-0

parameter_defaults セクションで HostnameMap を定義し、各マッピングは、HostnameFormat パラメーターを使用して Heat が定義する元のホスト名に設定します (例: overcloud-controller-0)。また、2 つ目の値は、ノードに指定するカスタムのホスト名 (例: overcloud-controller-prod-123-0) にします。

ノード ID の配置と合わせてこの手法を使用することで、各ノードにカスタムのホスト名が指定されるようにします。

作成された環境でさらに制御を行うために、director はそれぞれのネットワークについてオーバークラウドノードに固有の IP を割り当てることができます。

予測可能な IP アドレス設定を定義する環境ファイルを作成します。

$ touch ~/templates/predictive_ips.yaml

~/templates/predictive_ips.yaml ファイルに parameter_defaults セクションを作成し、以下の構文を使用してネットワークごとに各ノードの予測可能な IP アドレス設定を定義します。

parameter_defaults:
  <role_name>IPs:
    <network>:
    - <IP_address>
    <network>:
    - <IP_address>

各ノードロールには固有のパラメーターがあります。<role_name>IPs を該当するパラメーターに置き換えます。

各パラメーターは、アドレスの一覧へのネットワーク名のマッピングです。各ネットワーク種別には、最低でもそのネットワークにあるノード数と同じ数のアドレスが必要です。director はアドレスを順番に割り当てます。各種別の最初のノードは、適切な一覧にある最初のアドレスが割り当てられ、2 番目のノードは 2 番目のアドレスというように割り当てられていきます。

たとえば、オーバークラウドに 3 つの Ceph Storage ノードが含まれる場合には、CephStorageIPs パラメーターは以下のようになります。

parameter_defaults:
  CephStorageIPs:
    storage:
    - 172.16.1.100
    - 172.16.1.101
    - 172.16.1.102
    storage_mgmt:
    - 172.16.3.100
    - 172.16.3.101
    - 172.16.3.102

最初の Ceph Storage ノードは 172.16.1.100 と 172.16.3.100 の 2 つのアドレスを取得します。2 番目は 172.16.1.101 と 172.16.3.101、3 番目は 172.16.1.102 と 172.16.3.102 を取得します。他のノード種別でも同じパターンが適用されます。

コントロールプレーンに予測可能な IP アドレスを設定するには、/usr/share/openstack-tripleo-heat-templates/environments/ips-from-pool-ctlplane.yaml ファイルを stack ユーザーの templates ディレクトリーにコピーします。

$ cp /usr/share/openstack-tripleo-heat-templates/environments/ips-from-pool-ctlplane.yaml ~/templates/.

以下の例に示すパラメーターで、新たな ips-from-pool-ctlplane.yaml ファイルを設定します。コントロールプレーンの IP アドレスの宣言に他のネットワークの IP アドレスの宣言を組み合わせ、1 つのファイルだけを使用してすべてのロールの全ネットワークの IP アドレスを宣言することができます。また、スパイン/リーフ型ネットワークに予測可能な IP アドレスを使用することもできます。それぞれのノードには、正しいサブネットからの IP アドレスを設定する必要があります。

parameter_defaults:
  ControllerIPs:
    ctlplane:
    - 192.168.24.10
    - 192.168.24.11
    - 192.168.24.12
    internal_api:
    - 172.16.1.20
    - 172.16.1.21
    - 172.16.1.22
    external:
    - 10.0.0.40
    - 10.0.0.57
    - 10.0.0.104
  ComputeLeaf1IPs:
    ctlplane:
    - 192.168.25.100
    - 192.168.25.101
    internal_api:
    - 172.16.2.100
    - 172.16.2.101
  ComputeLeaf2IPs:
    ctlplane:
    - 192.168.26.100
    - 192.168.26.101
    internal_api:
    - 172.16.3.100
    - 172.16.3.101

選択する IP アドレスは、ネットワーク環境ファイルで定義する各ネットワークの割り当てプールの範囲に入らないようにしてください (「カスタムネットワーク環境ファイル」を参照)。たとえば、internal_api の割り当ては InternalApiAllocationPools の範囲外にし、自動的に選択される IP との競合を避けるようにします。同様に、標準の予測可能な仮想 IP 配置 (「予測可能な仮想 IP の割り当て」を参照) または外部の負荷分散 (「外部の負荷分散機能の設定」を参照) のいずれでも、IP アドレスの割り当てが仮想 IP 設定と競合しないようにしてください。

デプロイメント中にこの設定を適用するには、openstack overcloud deploy コマンドで predictive_ips.yaml 環境ファイルを指定します。

以下に例を示します。

$ openstack overcloud deploy --templates \
  -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
  -e ~/templates/predictive_ips.yaml \
  [OTHER OPTIONS]

director は、各ノードの予測可能な IP アドレスの定義に加えて、クラスター化されたサービス向けに予測可能な仮想 IP (VIP) を定義する同様の機能も提供します。そのためには、「カスタムネットワーク環境ファイル」 で作成したネットワークの環境ファイルを編集して、parameter_defaults セクションに仮想 IP のパラメーターを追加します。

parameter_defaults:
  ...
  # Predictable VIPs
  ControlFixedIPs: [{'ip_address':'192.168.201.101'}]
  InternalApiVirtualFixedIPs: [{'ip_address':'172.16.0.9'}]
  PublicVirtualFixedIPs: [{'ip_address':'10.1.1.9'}]
  StorageVirtualFixedIPs: [{'ip_address':'172.18.0.9'}]
  StorageMgmtVirtualFixedIPs: [{'ip_address':'172.19.0.9'}]
  RedisVirtualFixedIPs: [{'ip_address':'172.16.0.8'}]

それぞれの割り当てプール範囲外の IP アドレスを選択します。たとえば、InternalApiAllocationPools の範囲外から、InternalApiVirtualFixedIPs の IP アドレスを 1 つ選択します。

このステップは、デフォルトの内部負荷分散設定を使用するオーバークラウドのみが対象です。外部の負荷分散機能を使用して仮想 IP を割り当てる場合には、『External Load Balancing for the Overcloud』に記載の専用の手順を使用してください。

署名ホストとは、認証局を使用して新規証明書を生成し署名するホストです。選択した署名ホスト上で SSL 証明書を作成したことがない場合には、ホストを初期化して新規証明書に署名できるようにする必要がある可能性があります。

すべての署名済み証明書の記録は、/etc/pki/CA/index.txt ファイルに含まれます。このファイルが存在しているかどうかを確認してください。存在していない場合は、必要に応じてディレクトリーのパスを作成してから、空のファイル index.txt を作成します。

$ mkdir -p /etc/pki/CA
$ sudo touch /etc/pki/CA/index.txt

/etc/pki/CA/serial ファイルは、次に署名する証明書に使用する次のシリアル番号を特定します。このファイルが存在しているかどうかを確認してください。存在していない場合は、新規ファイル serial を作成して開始値を 1000 に指定します。

$ echo '1000' | sudo tee /etc/pki/CA/serial

通常、SSL/TLS 証明書の署名には、外部の認証局を使用します。場合によっては、独自の認証局を使用する場合もあります。たとえば、内部のみの認証局を使用するように設定する場合などです。

鍵と証明書のペアを生成して、認証局として機能するようにします。

$ openssl genrsa -out ca.key.pem 4096
$ openssl req  -key ca.key.pem -new -x509 -days 7300 -extensions v3_ca -out ca.crt.pem

openssl req コマンドは、認証局に関する特定の情報を要求します。要求されたら、それらの情報を入力してください。

これらのコマンドにより、ca.crt.pem という名前の認証局ファイルが作成されます。

SSL/TLS を使用して通信する外部クライアントについては、Red Hat OpenStack Platform 環境にアクセスする必要のある各クライアントに認証局ファイルをコピーします。

$ sudo cp ca.crt.pem /etc/pki/ca-trust/source/anchors/

各クライアントに認証局ファイルをコピーしたら、それぞれのクライアントで以下のコマンドを実行し、証明書を認証局のトラストバンドルに追加します。

$ sudo update-ca-trust extract

たとえば、アンダークラウドには、作成中にオーバークラウドのエンドポイントと通信できるようにするために、認証局ファイルのコピーが必要です。

以下のコマンドを実行して、SSL/TLS 鍵 (server.key.pem) を生成します。さまざまな段階でこの鍵を使用して、アンダークラウドまたはオーバークラウドの証明書を生成します。

$ openssl genrsa -out server.key.pem 2048

次の手順では、オーバークラウドの証明書署名要求を作成します。カスタマイズするデフォルトの OpenSSL 設定ファイルをコピーします。

$ cp /etc/pki/tls/openssl.cnf .

カスタムの openssl.cnf ファイルを編集して、オーバークラウドに使用する SSL パラメーターを設定します。変更するパラメーターの種別には以下のような例が含まれます。

[req]
distinguished_name = req_distinguished_name
req_extensions = v3_req

[req_distinguished_name]
countryName = Country Name (2 letter code)
countryName_default = AU
stateOrProvinceName = State or Province Name (full name)
stateOrProvinceName_default = Queensland
localityName = Locality Name (eg, city)
localityName_default = Brisbane
organizationalUnitName = Organizational Unit Name (eg, section)
organizationalUnitName_default = Red Hat
commonName = Common Name
commonName_default = 10.0.0.1
commonName_max = 64

[ v3_req ]
# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
subjectAltName = @alt_names

[alt_names]
IP.1 = 10.0.0.1
DNS.1 = 10.0.0.1
DNS.2 = myovercloud.example.com

commonName_default は以下のいずれか 1 つに設定します。

alt_names セクションの IP エントリーおよび DNS エントリーとして、同じパブリック API の IP アドレスを追加します。DNS も使用する場合は、同じセクションに DNS エントリーとしてそのサーバーのホスト名を追加します。openssl.cnf に関する詳しい情報については、man openssl.cnf を実行します。

次のコマンドを実行し、手順 1 で作成したキーストアより公開鍵を使用して証明書署名要求を生成します (server.csr.pem)。

$ openssl req -config openssl.cnf -key server.key.pem -new -out server.csr.pem

「SSL/TLS 鍵の作成」 で作成した SSL/TLS 鍵を -key オプションで必ず指定してください。

次の項では、この server.csr.pem ファイルを使用して SSL/TLS 証明書を作成します。

以下のコマンドを実行し、アンダークラウドまたはオーバークラウドの証明書を作成します。

$ sudo openssl ca -config openssl.cnf -extensions v3_req -days 3650 -in server.csr.pem -out server.crt.pem -cert ca.crt.pem -keyfile ca.key.pem

上記のコマンドでは、以下のオプションを使用しています。

上記のコマンドにより、server.crt.pem という名前の新規証明書が作成されます。「SSL/TLS 鍵の作成」で作成した SSL/TLS キーと共にこの証明書を使用して、SSL/TLS を有効にします。

Heat テンプレートコレクションから enable-tls.yaml の環境ファイルをコピーします。

$ cp -r /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-tls.yaml ~/templates/.

このファイルを編集して、下記のパラメーターに以下の変更を加えます。

証明書の署名者がオーバークラウドのイメージにあるデフォルトのトラストストアに含まれない場合には、オーバークラウドのイメージに認証局を注入する必要があります。Heat テンプレートコレクションから inject-trust-anchor-hiera.yaml 環境ファイルをコピーします。

$ cp -r /usr/share/openstack-tripleo-heat-templates/environments/ssl/inject-trust-anchor-hiera.yaml ~/templates/.

このファイルを編集して、下記のパラメーターに以下の変更を加えます。

CAMap パラメーターを使用して、別の CA を注入することもできます。

DNS ホスト名を使用して SSL/TLS でオーバークラウドにアクセスする場合は、custom-domain.yaml ファイルを /home/stack/templates にコピーする必要があります。このファイルは、/usr/share/tripleo-heat-templates/environments/predictable-placement/ にあります。

デプロイメントコマンド (openstack overcloud deploy) は、-e オプションを使用して環境ファイルを追加します。本項の環境ファイルは、以下の順序で追加します。

以下に例を示します。

$ openstack overcloud deploy --templates [...] -e /home/stack/templates/enable-tls.yaml -e ~/templates/cloudname.yaml -e ~/templates/inject-trust-anchor-hiera.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-endpoints-public-dns.yaml

将来に証明書を更新する必要がある場合:

新規証明書の内容が記載されたら、デプロイメントを再度実行します。以下に例を示します。

$ openstack overcloud deploy --templates [...] -e /home/stack/templates/enable-tls.yaml -e ~/templates/cloudname.yaml -e ~/templates/inject-trust-anchor.yaml -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-endpoints-public-dns.yaml

オーバークラウドをデプロイする前には、アンダークラウドを認証局 (CA) に追加する必要があります。

以下の手順では、アンダークラウドを IdM に登録して novajoin を設定します。undercloud.conf で以下の設定を行います ([DEFAULT] セクション内)。

IdM 環境を自動検出して、登録をより簡単にするには、IdM を DNS サーバーとして使用することを検討してください。

本項では、NFS 共有を使用するオーバークラウドの設定方法について説明します。インストールおよび設定のプロセスは、コア heat テンプレートコレクション内にすでに存在する環境ファイルの変更がベースとなります。

コア Heat テンプレートコレクションの /usr/share/openstack-tripleo-heat-templates/environments/ には、一連の環境ファイルが格納されています。これらの環境ファイルを使用すると、director が作成したオーバークラウドにおいて、一部のサポート対象機能のカスタム設定を作成することができます。これには、ストレージを設定するための環境ファイルが含まれます。このファイルは、/usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml に保管されています。

director では、Red Hat Ceph Storage のオーバークラウドへの統合には主に 2 つの方法を提供します。

コントローラーノードでデフォルトの Object Storage サービスのデプロイメントを無効にすることによって、外部の Object Storage (swift) クラスターを再利用することができます。これにより、Object Storage のプロキシーとストレージサービスの両方が無効になり、haproxy と keystone が特定の外部 Swift エンドポイントを使用するように設定されます。

外部の Object Storage クラスターのエンドポイントの IP アドレスに加えて、外部の Object Storage クラスターの proxy-server.conf ファイルの authtoken パスワードも必要です。この情報は、openstack endpoint list コマンドを使用して確認することができます。

外部の Swift クラスターを使用して director をデプロイする場合:

OpenStack Image サービス (glance) のデフォルト設定は、OpenStack のインストール時に使用される Heat テンプレートで定義されます。Image サービスの Heat テンプレートは deployment/glance/glance-api-container-puppet.yaml です。

相互運用可能なイメージのインポートにより、以下の 2 とおりの方法でイメージをインポートすることができます。

web-download 法では、URL からイメージをインポートします。glance-direct 法では、ローカルボリュームからイメージをインポートします。

parameter_defaults:
  # Configure NFS backend
  GlanceBackend: file
  GlanceNfsEnabled: true
  GlanceNfsShare: 192.168.122.1:/export/glance

  # Enable glance-direct import method
  GlanceEnabledImportMethods: glance-direct,web-download

  # Configure NFS staging area (required for glance-direct import method)
  GlanceStagingNfsShare: 192.168.122.1:/export/glance-staging

allowed_schemes = [http,https,ftp]
disallowed_schemes = []
allowed_hosts = []
disallowed_hosts = []
allowed_ports = [80,443]
disallowed_ports = []

[image_import_opts]
image_import_plugins = [inject_image_metadata]

[DEFAULT]
[image_conversion]
[image_import_opts]
image_import_plugins = [inject_image_metadata]
[import_filtering_opts]
[inject_metadata_properties]
ignore_user_roles = admin
inject = PROPERTY1:value,PROPERTY2:value;another value

GlanceBackend パラメーターにより、Image サービスがイメージを保管するのに使用するバックエンドを設定します。

cinder_store_auth_address = http://172.17.1.19:5000/v3
cinder_store_project_name = service
cinder_store_user_name = glance
cinder_store_password = ****secret****

カスタムのユーザー名または cinder_store_ パラメーターにカスタムの値を使用する場合には、parameter_defaults に ExtraConfig 設定を追加してカスタムの値を渡します。

ExtraConfig:
    glance::config::api_config:
      glance_store/cinder_store_auth_address:
        value: "%{hiera('glance::api::authtoken::auth_url')}/v3"
      glance_store/cinder_store_user_name:
        value: <user-name>
      glance_store/cinder_store_password:
        value: "%{hiera('glance::api::authtoken::password')}"
      glance_store/cinder_store_project_name:
        value: "%{hiera('glance::api::authtoken::project_name')}"

デフォルトでは、1 つのインスタンスにアタッチすることのできるストレージデバイスの数に制限はありません。デバイスの最大数を制限するには、コンピュート環境ファイルに max_disk_devices_to_attach パラメーターを追加します。以下の例は、max_disk_devices_to_attach の値を「30」に変更する方法を示しています。

parameter_defaults:
   ComputeExtraConfig:
          nova::config::nova_config:
            compute/max_disk_devices_to_attach:
                value: '30'

glance-api キャッシュメカニズムを使用して、ローカルマシンにイメージのコピーを保存し、イメージを自動的に取得してスケーラビリティーを向上させます。Image サービスのキャッシュ機能を使用することで、複数のホスト上で glance-api を実行することができます。つまり、同じイメージをバックエンドストレージから何度も取得する必要はありません。Image サービスのキャッシュ機能は、Image サービスの動作には一切影響を与えません。

Red Hat OpenStack Platform director (tripleo) heat テンプレートを使用して Image サービスのキャッシュ機能を設定するには、以下の手順を実施します。

director には、サードパーティーのストレージプロバイダーの設定に役立つ複数の環境ファイルが含まれています。これには、以下の設定項目が含まれます。

OpenStack Platform の各コアサービスには、それぞれのコンポーザブルサービステンプレートにファイアウォールルールが含まれています。これにより、各オーバークラウドノードにファイアウォールルールのデフォルトセットが自動的に作成されます。

オーバークラウドの Heat テンプレートには、追加のファイアウォール管理に役立つパラメーターのセットが含まれています。

ManageFirewall が true に設定されている場合には、デプロイメントに追加のファイアウォールルールを作成することができます。オーバークラウドの環境ファイルで、設定フックを使用して (「Puppet: ロール用 hieradata のカスタマイズ」を参照) tripleo::firewall::firewall_rules hieradata を設定します。この hieradata は、ファイアウォールルール名とそれぞれのパラメーター (すべてオプション) を鍵として記載したハッシュです。

以下の例は、ファイアウォールルールの形式の構文を示しています。

ExtraConfig:
  tripleo::firewall::firewall_rules:
    '300 allow custom application 1':
      port: 999
      proto: udp
      action: accept
    '301 allow custom application 2':
      port: 8081
      proto: tcp
      action: accept

この設定では、ExtraConfig により、追加で 2 つのファイアウォールルールが 全ノードに適用されます。

director は、オーバークラウド向けのデフォルトの読み取り専用 SNMP 設定を提供します。SNMP の文字列を変更して、未承認のユーザーがネットワークデバイスに関する情報にアクセスするリスクを軽減することを推奨します。

オーバークラウドの環境ファイルで ExtraConfig フックを使用して、以下の hieradata を設定します。

SNMP の従来のアクセス制御設定

以下に例を示します。

parameter_defaults:
  ExtraConfig:
    snmp::ro_community: mysecurestring
    snmp::ro_community6: myv6securestring

これにより、全ノードで、読み取り専用の SNMP コミュニティー文字列が変更されます。

SNMP のビューベースのアクセス制御設定 (VACM)

以下に例を示します。

parameter_defaults:
  ExtraConfig:
    snmp::com2sec: mysecurestring
    snmp::com2sec6: myv6securestring

これにより、全ノードで、読み取り専用の SNMP コミュニティー文字列が変更されます。

詳細は man ページの snmpd.conf を参照してください。

オーバークラウドで SSL/TLS を有効化した場合には (「14章オーバークラウドのパブリックエンドポイントでの SSL/TLS の有効化」を参照)、HAProxy 設定を使用する SSL/TLS の暗号とルールを強化することをお勧めします。これにより、POODLE TLS 脆弱性 などの SSL/TLS の脆弱性を回避することができます。

オーバークラウドの環境ファイルで ExtraConfig フックを使用して、以下の hieradata を設定します。

たとえば、以下のような暗号およびルールを使用することができます。

以下の内容で環境ファイルを作成します。

parameter_defaults:
  ExtraConfig:
    tripleo::haproxy::ssl_cipher_suite: ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS
    tripleo::haproxy::ssl_options: no-sslv3 no-tls-tickets

オーバークラウドの作成時にこの環境ファイルを追加します。

Red Hat OpenStack Platform director で Open vSwitch (OVS) ファイアウォールドライバーを使用するためのセキュリティーグループを設定することができます。NeutronOVSFirewallDriver パラメーターで、使用するファイアウォールドライバーを指定することができます。

openvswitch ファイアウォールドライバーはパフォーマンスがより高く、ゲストをプロジェクトネットワークに接続するためのインターフェースとブリッジの数を削減します。

network-environment.yaml ファイルで NeutronOVSFirewallDriver パラメーターを設定します。

NeutronOVSFirewallDriver: openvswitch

オーバークラウドのイメージでは、root ユーザーのセキュリティー強化機能が自動的に含まれます。たとえば、デプロイされる各オーバークラウドノードでは、root ユーザーへの 直接の SSH アクセスを自動的に無効化されます。以下の方法を使用すると、オーバークラウドで root ユーザーにアクセスすることが引き続き可能となります。

この方法では、初回ブートの設定フック (「初回起動: 初回起動設定のカスタマイズ」を参照) を使用します。環境ファイルに以下の内容を記載してください。

resource_registry:
  OS::TripleO::NodeUserData: /usr/share/openstack-tripleo-heat-templates/firstboot/userdata_root_password.yaml

parameter_defaults:
  NodeRootPassword: "p@55w0rd!"

以下の点に注意してください。

オーバークラウドの作成時に、openstack overcloud deploy コマンドにこの環境ファイルを追加します。

/usr/share/openstack-tripleo-heat-templates/environments/neutron-ml2-fujitsu-cfab.yaml にある環境ファイルを使用して、Fujitsu Converged Fabric (C-Fabric) プラグインを有効にすることができます。

/usr/share/openstack-tripleo-heat-templates/environments/neutron-ml2-fujitsu-fossw.yaml にある環境ファイルを使用して、Fujitsu FOS Switch プラグインを有効にすることができます。

デフォルトでは、オーバークラウドのリージョンは、regionOne という名前になります。環境ファイルに KeystoneRegion エントリーを追加することによって変更できます。この設定は、デプロイ後には変更できません。

parameter_defaults:
  KeystoneRegion: 'SampleRegion'

OpenStack Platform director には、オーバークラウドノードのカーネルを設定するパラメーターが含まれています。

環境ファイルのこれらのパラメーターの構文例を以下に示します。

parameter_defaults:
  ExtraKernelModules:
    iscsi_target_mod: {}
  ExtraKernelPackages:
    iscsi-initiator-utils: {}
  ExtraSysctlSettings:
    dev.scsi.logging_level:
      value: 1

オーバークラウドは、複数のコントローラーを合わせて、高可用性クラスターとして使用し、OpenStack サービスのオペレーションパフォーマンスを最大限に保つようにします。さらに、クラスターにより、OpenStack サービスへのアクセスの負荷分散が行われ、コントローラーノードに均等にトラフィックを分配して、各ノードのサーバーで過剰負荷を軽減します。また、外部のロードバランサーを使用して、この分散を実行することも可能です。たとえば、組織で、コントローラーノードへのトラフィックの分散処理に、ハードウェアベースのロードバランサーを使用する場合などです。

外部の負荷分散機能の設定に関する詳しい情報は、全手順について『 External Load Balancing for the Overcloud 』を参照してください。

デフォルトでは、オーバークラウドは、インターネットプロトコルのバージョン 4 (IPv4) を使用してサービスのエンドポイントを設定します。ただし、オーバークラウドはインターネットプロトコルのバージョン 6 (IPv6) のエンドポイントもサポートします。これは、IPv6 のインフラストラクチャーをサポートする組織には便利です。director には、IPv6 ベースのオーバークラウドの作成に役立つ環境ファイルのセットが含まれています。

オーバークラウドでの IPv6 設定に関する詳しい情報は、全手順について『専用の IPv6 Networking for the Overcloud 』を参照してください。