オーバークラウドの高度なカスタマイズ

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

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 に保存されています。

このテンプレートコレクションの主なファイルおよびディレクトリーは、以下のとおりです。

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

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

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

version: 1.0
name: myovercloud
description: 'My Overcloud Plan'
template: overcloud.yaml
environments:
- path: overcloud-resource-registry-puppet.yaml
- path: environments/docker.yaml
- path: environments/docker-ha.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 -

ケイパビリティーマップは、プラン内の環境ファイルとそれらの依存関係のマッピングを提供します。director の Web UI で環境ファイルを記述および有効化するには、このファイルを使用します。オーバークラウドプランで検出されるカスタムの環境ファイルの中で、capabilities-map.yaml にリストされていないファイルは、Web UI の 2 デプロイメントの設定の指定 > 全体の設定 の Other サブタブに一覧表示されます。

デフォルトのファイルは、/usr/share/openstack-tripleo-heat-templates/capabilities-map.yaml にあります。

ケイパビリティーマップの構文の例を以下に示します。

topics: 1
  - title: My Parent Section
    description: This contains a main section for different environment files
    environment_groups: 2
      - name: my-environment-group
        title: My Environment Group
        description: A list of environment files grouped together
        environments: 3
          - file: environment_file_1.yaml
            title: Environment File 1
            description: Enables environment file 1
            requires: 4
              - dependent_environment_file.yaml
          - file: environment_file_2.yaml
            title: Environment File 2
            description: Enables environment file 2
            requires: 5
              - dependent_environment_file.yaml
          - file: dependent_environment_file.yaml
            title: Dependent Environment File
            description: Enables the dependent environment 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'

OpenStack Networking (neutron) API 用の Heat テンプレート (puppet/services/neutron-api.yaml) には、分散仮想ルーティング (DVR) を有効化/無効化するためのパラメーターが含まれています。このパラメーターのデフォルト値は false です。ただし、環境ファイルで以下の設定を使用して有効にすることができます。

parameter_defaults:
  NeutronEnableDVR: true

特定の設定では、RabbitMQ サーバーのファイル記述子の上限を高くする必要がある場合があります。puppet/services/rabbitmq.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 テンプレート (~/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 にはフックのセットが用意されており、初回起動が完了してコア設定が開始する前に、特定ノードロールのカスタム設定が提供されます。これには、以下のフックが含まれます。

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

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 セクションには以下のパラメーターが含まれます。

次に、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) を作成します。

description: >
  Extra hostname configuration

parameters:
  servers:
    type: json
  nameserver_ip:
    type: string
  DeployIdentifier:
    type: string

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 からの設定がオーバークラウド内の全ノードに適用されます。

登録ファイルを Heat テンプレートコレクションからコピーします。

$ cp -r /usr/share/openstack-tripleo-heat-templates/extraconfig/pre_deploy/rhel-registration ~/templates/.

~/templates/rhel-registration/environment-rhel-registration.yaml ファイルを編集し、登録の方法と詳細に適用されるパラメーターの値を変更します。

デプロイメントコマンド (openstack overcloud deploy) は、-e オプションを使用して環境ファイルを追加します。~/templates/rhel-registration/environment-rhel-registration.yaml と ~/templates/rhel-registration/rhel-registration-resource-registry.yaml の両方を追加します。以下に例を示します。

$ openstack overcloud deploy --templates [...] -e /home/stack/templates/rhel-registration/environment-rhel-registration.yaml -e /home/stack/templates/rhel-registration/rhel-registration-resource-registry.yaml

以下の設定により、my-openstack アクティベーションキーを使用してオーバークラウドノードを Red Hat カスタマーポータルに登録し、1a85f9223e3d5e43013e3d6e8ff506fd のプールをサブスクライブします。

parameter_defaults:
  rhel_reg_auto_attach: ""
  rhel_reg_activation_key: "my-openstack"
  rhel_reg_org: "1234567"
  rhel_reg_pool_id: "1a85f9223e3d5e43013e3d6e8ff506fd"
  rhel_reg_repos: "rhel-7-server-rpms,rhel-7-server-extras-rpms,rhel-7-server-rh-common-rpms,rhel-ha-for-rhel-7-server-rpms,rhel-7-server-openstack-13-rpms,rhel-7-server-rhceph-3-osd-rpms,rhel-7-server-rhceph-3-mon-rpms,rhel-7-server-rhceph-3-tools-rpms"
  rhel_reg_method: "portal"
  rhel_reg_sat_repo: ""
  rhel_reg_base_url: ""
  rhel_reg_environment: ""
  rhel_reg_force: ""
  rhel_reg_machine_name: ""
  rhel_reg_password: ""
  rhel_reg_release: ""
  rhel_reg_sat_url: ""
  rhel_reg_server_url: ""
  rhel_reg_service_level: ""
  rhel_reg_user: ""
  rhel_reg_type: ""
  rhel_reg_http_proxy_host: ""
  rhel_reg_http_proxy_port: ""
  rhel_reg_http_proxy_username: ""
  rhel_reg_http_proxy_password: ""

以下の設定により、my-openstack アクティベーションキーを使用してオーバークラウドノードを sat6.example.com の Red Hat Satellite 6 Server に登録し、1a85f9223e3d5e43013e3d6e8ff506fd のプールをサブスクライブします。この場合は、アクティベーションキーで有効化するレポジトリーも指定します。

parameter_defaults:
  rhel_reg_activation_key: "my-openstack"
  rhel_reg_org: "1"
  rhel_reg_pool_id: "1a85f9223e3d5e43013e3d6e8ff506fd"
  rhel_reg_method: "satellite"
  rhel_reg_sat_url: "http://sat6.example.com"
  rhel_reg_sat_repo: "rhel-7-server-satellite-tools-6.2-rpms"
  rhel_reg_repos: ""
  rhel_reg_auto_attach: ""
  rhel_reg_base_url: ""
  rhel_reg_environment: ""
  rhel_reg_force: ""
  rhel_reg_machine_name: ""
  rhel_reg_password: ""
  rhel_reg_release: ""
  rhel_reg_server_url: ""
  rhel_reg_service_level: ""
  rhel_reg_user: ""
  rhel_reg_type: ""
  rhel_reg_http_proxy_host: ""
  rhel_reg_http_proxy_port: ""
  rhel_reg_http_proxy_username: ""
  rhel_reg_http_proxy_password: ""

以下の設定により、my-openstack アクティベーションキーを使用してオーバークラウドノードを sat5.example.com の Red Hat Satellite 5 Server に登録し、サブスクリプションを自動的にアタッチします。この場合は、アクティベーションキーで有効化するレポジトリーも指定します。

parameter_defaults:
  rhel_reg_auto_attach: ""
  rhel_reg_activation_key: "my-openstack"
  rhel_reg_org: "1"
  rhel_reg_method: "satellite"
  rhel_reg_sat_url: "http://sat5.example.com"
  rhel_reg_repos: ""
  rhel_reg_base_url: ""
  rhel_reg_environment: ""
  rhel_reg_force: ""
  rhel_reg_machine_name: ""
  rhel_reg_password: ""
  rhel_reg_pool_id: ""
  rhel_reg_release: ""
  rhel_reg_server_url: ""
  rhel_reg_service_level: ""
  rhel_reg_user: ""
  rhel_reg_type: ""
  rhel_reg_sat_repo: ""
  rhel_reg_http_proxy_host: ""
  rhel_reg_http_proxy_port: ""
  rhel_reg_http_proxy_username: ""
  rhel_reg_http_proxy_password: ""

以下のサンプルパラメーターは、必要な登録方法向けの HTTP プロキシーの設定値を設定します。

parameter_defaults:
  ...
  rhel_reg_http_proxy_host: "proxy.example.com"
  rhel_reg_http_proxy_port: "8080"
  rhel_reg_http_proxy_username: "proxyuser"
  rhel_reg_http_proxy_password: "p@55w0rd!"
  ...

一部の状況では、異なるサブスクリプションタイプに異なるロールを登録する必要がある場合があります。たとえば、コントローラーノードのみを OpenStack Platform サブスクリプションにサブスクライブして、Ceph Storage ノードを Ceph Storage サブスクリプションにするとします。本項では、ロールごとに別々のサブスクリプションを割り当てるのに役立つ高度な登録方法をいくつか紹介します。

ControllerRegistrationConfig:
  type: OS::Heat::SoftwareConfig
  properties:
    group: script
    config: |
      #!/bin/sh
      sudo subscription-manager register --org 1234567 \
        --activationkey "my-openstack"
      sudo subscription-manager attach --pool 1a85f9223e3d5e43013e3d6e8ff506fd
      sudo subscription-manager repos --enable rhel-7-server-rpms \
        --enable rhel-7-server-extras-rpms \
        --enable rhel-7-server-rh-common-rpms \
        --enable rhel-ha-for-rhel-7-server-rpms \
        --enable rhel-7-server-openstack-13-rpms \
        --enable rhel-7-server-rhceph-3-mon-rpms

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

このスクリプトでは、一式の subscription-manager コマンドを使用してシステムを登録し、サブスクリプションをアタッチして、必要なリポジトリーを有効化します。

フックについての詳しい情報は、4章設定フックを参照してください。

---
- name: Register Controller nodes
  hosts: Controller
  become: yes
  vars:
    repos:
      - rhel-7-server-rpms
      - rhel-7-server-extras-rpms
      - rhel-7-server-rh-common-rpms
      - rhel-ha-for-rhel-7-server-rpms
      - rhel-7-server-openstack-13-rpms
      - rhel-7-server-rhceph-3-mon-rpms
  tasks:
    - name: Register system
      redhat_subscription:
        activationkey: my-openstack
        org_id: 1234567
        pool_ids: 1a85f9223e3d5e43013e3d6e8ff506fd
    - name: Disable all repos
      command: "subscription-manager repos --disable *"
    - name: Enable Controller node repos
      command: "subscription-manager repos --enable {{ item }}"
      with_items: "{{ repos }}"

このプレイには、アクティベーションキーを使用したノードの登録、自動的に有効化されたリポジトリーの無効化、コントローラーノードに関連したリポジトリーのみの有効化の 3 つのタスクが含まれています。リポジトリーは repos 変数でリストされます。

オーバークラウドのデプロイ後には、以下のコマンドを実行して、Ansible がオーバークラウドに対して Playbook (ansible-osp-registration.yml) を実行することができます。

$ ansible-playbook -i /usr/bin/tripleo-ansible-inventory ansible-osp-registration.yml

このコマンドは、動的インベントリースクリプトを実行して、ホストとそのグループの一覧を取得し、Playbook の hosts パラメーターで定義されているグループ (この場合は Controller グループ) 内のノードに、その Playbook のタスクを適用します。

オーバークラウドでの Ansible 自動化の実行に関する詳しい情報は、director のインストールと使用方法の オーバークラウド作成後のタスクの実行 を参照してください。

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

resource_registry:
  OS::TripleO::Services::Rhsm: /usr/share/openstack-tripleo-heat-templates/extraconfig/services/rhsm.yaml

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

parameter_defaults:
  RhsmVars:
    rhsm_repos:
      - rhel-7-server-rpms
      - rhel-7-server-extras-rpms
      - rhel-7-server-rh-common-rpms
      - rhel-ha-for-rhel-7-server-rpms
      - rhel-7-server-openstack-13-rpms
      - rhel-7-server-rhceph-3-osd-rpms
      - rhel-7-server-rhceph-3-mon-rpms
      - rhel-7-server-rhceph-3-tools-rpms
    rhsm_activation_key: "my-openstack"
    rhsm_org_id: "1234567"

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

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

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

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

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

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

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

これらの手順は、オーバークラウドで rhsm を有効化して設定します。ただし、5章オーバークラウドの登録 に記載の rhel-registration の方法を使用している場合には、これを無効にして Ansible ベースの方法に切り替える必要があります。rhel-registration の方法から Ansible ベースの方法に切り替えるには、以下の手順に従ってください。

rhel-registration の方法では、バッシュスクリプトを実行してオーバークラウドの登録を処理します。この方法のスクリプトと環境ファイルは、/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/extraconfig/services/rhsm.yaml

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

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

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

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

director は、OpenStack Platform のコアサービスをオーバークラウド上にコンテナーとしてインストールします。コンテナー化されたサービス用のテンプレートは、/usr/share/openstack-tripleo-heat-templates/docker/services/ にあります。これらのテンプレートは、それぞれのコンポーザブルサービステンプレートを参照します。たとえば、OpenStack Identity (keystone) のコンテナー化されたサービスのテンプレート (docker/services/keystone.yaml) には、以下のリソースが含まれます。

  KeystoneBase:
    type: ../../puppet/services/keystone.yaml
    properties:
      EndpointMap: {get_param: EndpointMap}
      ServiceData: {get_param: ServiceData}
      ServiceNetMap: {get_param: ServiceNetMap}
      DefaultPasswords: {get_param: DefaultPasswords}
      RoleName: {get_param: RoleName}
      RoleParameters: {get_param: RoleParameters}

type は、それぞれの OpenStack Identity (keystone) コンポーザブルサービスを参照して、そのテンプレートから outputs データをプルします。コンテナー化されたサービスは、独自のコンテナー固有データにこのデータをマージします。

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

- name: Keystone
  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::Fluentd
    - OS::TripleO::Services::AuditD
    - OS::TripleO::Services::Collectd
    - OS::TripleO::Services::MySQLClient
    - OS::TripleO::Services::Docker
    - OS::TripleO::Services::Keystone

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

Red Hat は、Red Hat Container Catalog (registry.redhat.io) で、事前にビルドされたコンテナーイメージを提供しています。これらのイメージを修正して、さらにレイヤーを追加することができます。これは、認定済みのサードパーティードライバーの RPM をコンテナーに追加する場合に役立ちます。

最新の openstack-keystone イメージをカスタマイズする方法を、以下の例で説明します。ただし、これらの手順は、他のイメージにも適用することができます。

サードパーティーのハードウェアをブロックストレージのバックエンドとして使用するには、ベンダープラグインをデプロイする必要があります。以下の例で、Dell EMC ハードウェアをブロックストレージのバックエンドとして使用するために、ベンダープラグインをデプロイする方法について説明します。

デフォルトでは、オーバークラウドはサービスをプロビジョニングネットワークに割り当てます。ただし、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 が指定されます。

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

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

デフォルトの network_data.yaml ファイルをコピーし、コピーを修正してデフォルトの分離ネットワークを設定します。

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

-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 バージョンにレンダリングする方法は、11章カスタムネットワークインターフェイステンプレートで説明します。この 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) が使用されます。

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

-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 つを使用してカスタムコンポーザブルネットワークを有効にします。以下の例では、VLAN が設定された単一 NIC のテンプレート (net-single-nic-with-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 への割り当てを以下のようにマッピングすることができます。

カスタムインターフェイステンプレートの設定を簡素化するには、デフォルト NIC テンプレートの Jinja2 構文をレンダリングし、レンダリング済みのテンプレートをカスタム設定のベースとして使用します。

「カスタマイズのためのデフォルトネットワークインターフェイステンプレートのレンダリング」でレンダリングするカスタム NIC テンプレートには、parameters および resources セクションが含まれます。

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

ネットワークインターフェイス種別 ovs_bridge には、パラメーター name を使用します。

外部の tripleo ネットワークに OVS ブリッジを定義している場合は、bridge_name および interface_name の値を維持します。デプロイメントフレームワークが、これらの値を自動的にそれぞれ外部ブリッジ名および外部インターフェイス名に置き換えるためです。

以下に例を示します。

      - 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.yaml および roles_data.yaml ファイルで定義したネットワークおよびロールが含まれます。レンダリングされた 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 にエントリーが事前定義されます。

resource_registry:
  OS::TripleO::NodeUserData: /usr/share/openstack/tripleo-heat-templates/firstboot/os-net-config-mappings.yaml
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

トランキングされたインターフェイスまたはボンディングに、ネイティブ 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

Red Hat OpenStack Platform (RHOSP) Networking サービス (neutron) は、netfilter 接続追跡を使用してステートフルファイアウォールを構築し、仮想ネットワークでネットワークアドレス変換 (NAT) を提供します。カーネルスペースが最大接続制限に達し、nf_conntrack: table full, dropping packet などのエラーが発生する状況がいくつかあります。接続追跡 (conntrack) の制限を増やして、これらのタイプのエラーを回避できます。RHOSP デプロイメントで、1 つ以上のロール、またはすべてのノードの conntrack 制限を増やすことができます。

複数の物理 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"

Linux ボンディングオプションの詳細については、7.7.1結合モジュールディレクティブ を参照してください。

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

以下の手順では、特定のノードにノード 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 を割り当てることもできます。コア Heat テンプレートコレクションにある environments/ips-from-pool-all.yaml 環境ファイルを使用します。

このファイルを stack ユーザーの templates ディレクトリーにコピーしてください。

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

ips-from-pool-all.yaml ファイルには、2 つの主要セクションがあります。

1 番目のセクションは、デフォルトよりも優先される resource_registry の参照セットです。この参照では、director に対して、ノード種別のある特定のポートに特定の IP を使用するように指示を出します。適切なテンプレートの絶対パスを使用するように各リソースを編集してください。以下に例を示します。

  OS::TripleO::Controller::Ports::ExternalPort: /usr/share/openstack-tripleo-heat-templates/network/ports/external_from_pool.yaml
  OS::TripleO::Controller::Ports::InternalApiPort: /usr/share/openstack-tripleo-heat-templates/network/ports/internal_api_from_pool.yaml
  OS::TripleO::Controller::Ports::StoragePort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_from_pool.yaml
  OS::TripleO::Controller::Ports::StorageMgmtPort: /usr/share/openstack-tripleo-heat-templates/network/ports/storage_mgmt_from_pool.yaml
  OS::TripleO::Controller::Ports::TenantPort: /usr/share/openstack-tripleo-heat-templates/network/ports/tenant_from_pool.yaml

デフォルトの設定では、全ノード種別上にあるすべてのネットワークが、事前に割り当てられた IP を使用するように設定します。特定のネットワークやノード種別がデフォルトの IP 割り当てを使用するように許可するには、環境ファイルからノード種別やネットワークに関連する resource_registry のエントリーを削除するだけです。

2 番目のセクションは、実際の IP アドレスを割り当てる parameter_defaults です。各ノード種別には、関連するパラメーターが指定されます。

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

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

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

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

以下に例を示します。

$ openstack overcloud deploy --templates \
  -e /usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml \
  -e ~/templates/ips-from-pool-all.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 ファイルは、すべての署名済み証明書の記録を保管します。このファイルが存在しているかどうかを確認してください。存在していない場合には、空のファイルを作成します。

$ sudo touch /etc/pki/CA/index.txt

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

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

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

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

$ sudo openssl genrsa -out ca.key.pem 4096
$ sudo 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.yaml 環境ファイルをコピーします。

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

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

複数の CA を注入する場合には、inject-trust-anchor-hiera.yaml 環境ファイルを使用することができます。たとえば、アンダークラウドとオーバークラウド両方の CA を同時に注入することができます。

parameter_defaults:
  CAMap:
    undercloud-ca:
      content: |
        -----BEGIN CERTIFICATE-----
        ... cert content ...
        -----END CERTIFICATE-----
    overcloud-ca:
      content: |
        -----BEGIN CERTIFICATE-----
        ... cert content ...
        -----END CERTIFICATE-----

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.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 サーバーとして使用することを検討してください。

デフォルトでは、既存の Red Hat OpenStack Platform 13 オーバークラウドは、特定のエンドポイントを TLS で暗号化しません。たとえば、以下の出力には、https の代わりに http を使用する URL が含まれます。これらは暗号化されません。

+----------------------------------+-----------+--------------+--------------+---------+-----------+--------------------------------------------------------+
| ID                               | Region    | Service Name | Service Type | Enabled | Interface | URL                                                    |
+----------------------------------+-----------+--------------+--------------+---------+-----------+--------------------------------------------------------+
| 0ad11e943e1f4ff988650cfba57b4031 | regionOne | nova         | compute      | True    | internal  | http://172.16.2.17:8774/v2.1                           |
| 1413eb9ef38a45b8bee1bee1b0dfe744 | regionOne | swift        | object-store | True    | public    | https://overcloud.lab.local:13808/v1/AUTH_%(tenant_id)s |
| 1a54f13f212044b0a20468861cd06f85 | regionOne | neutron      | network      | True    | public    | https://overcloud.lab.local:13696                       |
| 3477a3a052d2445697bb6642a8c26a91 | regionOne | placement    | placement    | True    | internal  | http://172.16.2.17:8778/placement                      |
| 3f56445c0dd14721ac830d6afb2c2cd4 | regionOne | nova         | compute      | True    | admin     | http://172.16.2.17:8774/v2.1                           |
| 425b1773a55c4245bcbe3d051772ebba | regionOne | glance       | image        | True    | internal  | http://172.16.2.17:9292                                |
| 57cf09fa33ed446f8736d4228bdfa881 | regionOne | placement    | placement    | True    | public    | https://overcloud.lab.local:13778/placement             |
| 58600f3751e54f7e9d0a50ba618e4c54 | regionOne | glance       | image        | True    | public    | https://overcloud.lab.local:13292                       |
| 5c52f273c3284b068f2dc885c77174ca | regionOne | neutron      | network      | True    | internal  | http://172.16.2.17:9696                                |
| 8792a4dd8bbb456d9dea4643e57c43dc | regionOne | nova         | compute      | True    | public    | https://overcloud.lab.local:13774/v2.1                  |
| 94bbea97580a4c4b844478aad5a85e84 | regionOne | keystone     | identity     | True    | public    | https://overcloud.lab.local:13000                       |
| acbf11b5c76d44198af49e3b78ffedcd | regionOne | swift        | object-store | True    | internal  | http://172.16.1.9:8080/v1/AUTH_%(tenant_id)s           |
| d4a1344f02a74f7ab0a50c5a7c13ca5c | regionOne | keystone     | identity     | True    | internal  | http://172.16.2.17:5000                                |
| d86c241dc97642419ddc12533447d73d | regionOne | placement    | placement    | True    | admin     | http://172.16.2.17:8778/placement                      |
| de7d6c34533e4298a2752852427a7030 | regionOne | glance       | image        | True    | admin     | http://172.16.2.17:9292                                |
| e82086062ebd4d4b9e03c7f1544bdd3b | regionOne | swift        | object-store | True    | admin     | http://172.16.1.9:8080                                 |
| f8134cd9746247bca6a06389b563c743 | regionOne | keystone     | identity     | True    | admin     | http://192.168.24.6:35357                              |
| fe29177bd29545ca8fdc0c777a7cf03f | regionOne | neutron      | network      | True    | admin     | http://172.16.2.17:9696                                |
+----------------------------------+-----------+--------------+--------------+---------+-----------+--------------------------------------------------------+

以降のセクションで、これらのエンドポイントを TLS を使用して暗号化する方法について説明します。

現在、TLS Everywhere のその場アップグレードには、オーバークラウドノードを IdM に登録することができないという既知の問題があります。回避策としては、overcloud deploy を実行する前に、すべてのオーバークラウドノードから /etc/ipa/ca.crt/ を削除する方法があります。詳細は、Bug 1732564 を参照してください。

回避策を適用する 1 つの方法として、以下のスクリプトが挙げられます。デプロイメントに合わせてこのスクリプトを変更しなければならない場合があります。

[stack@undercloud-0 ~]$ vi rm-ca.crt-dir.sh
#!/bin/bash

source /home/stack/stackrc
NODES=$(openstack server list -f value -c Networks|sed s/ctlplane=//g)

for NODE in $NODES
do
    ssh heat-admin@$NODE sudo rm -rf /etc/ipa/ca.crt/
Done

[stack@undercloud-0 ~]$ bash rm-ca.crt-dir.sh

本セクションでは、既存のデプロイメントで TLS によるエンドポイントの暗号化を有効にする方法、さらにエンドポイントが正しく設定されていることを確認する方法について説明します。

TLS everywhere を有効にする場合、ドメインの構造化方法に応じて、さまざまなアップグレードパスを利用することができます。以下の例では、サンプルドメイン名を使用してアップグレードパスを説明します。

本セクションの以降の手順で、上記のさまざまな組み合わせを使用して、この統合を設定する方法について説明します。

オーバークラウドの再デプロイメントが完了したら、すべてのエンドポイントが TLS で暗号化されていることを確認します。以下の例では、すべてのエンドポイントが https を使用するように設定されています。したがって、TLS 暗号化が使用されていることが分かります。

+----------------------------------+-----------+--------------+----------------+---------+-----------+---------------------------------------------------------------+
| ID                               | Region    | Service Name | Service Type   | Enabled | Interface | URL                                                           |
+----------------------------------+-----------+--------------+----------------+---------+-----------+---------------------------------------------------------------+
| 0fee4efdc4ae4310b6a139a25d9c0d9c | regionOne | neutron      | network        | True    | public    | https://overcloud.lab.local:13696                              |
| 220558ab1d2445139952425961a0c89a | regionOne | glance       | image          | True    | public    | https://overcloud.lab.local:13292                              |
| 24d966109ffa419da850da946f19c4ca | regionOne | placement    | placement      | True    | admin     | https://overcloud.internalapi.lab.local:8778/placement         |
| 27ac9e0d22804ee5bd3cd8c0323db49c | regionOne | nova         | compute        | True    | internal  | https://overcloud.internalapi.lab.local:8774/v2.1              |
| 31d376853bd241c2ba1a27912fc896c6 | regionOne | swift        | object-store   | True    | admin     | https://overcloud.storage.lab.local:8080                       |
| 350806234c784332bfb8615e721057e3 | regionOne | nova         | compute        | True    | admin     | https://overcloud.internalapi.lab.local:8774/v2.1              |
| 49c312f4db6748429d27c60164779302 | regionOne | keystone     | identity       | True    | public    | https://overcloud.lab.local:13000                              |
| 4e535265c35e486e97bb5a8bc77708b6 | regionOne | nova         | compute        | True    | public    | https://overcloud.lab.local:13774/v2.1                         |
| 5e93dd46b45f40fe8d91d3a5d6e847d3 | regionOne | keystone     | identity       | True    | admin     | https://overcloud.ctlplane.lab.local:35357                     |
| 6561984a90c742a988bf3d0acf80d1b6 | regionOne | swift        | object-store   | True    | public    | https://overcloud.lab.local:13808/v1/AUTH_%(tenant_id)s        |
| 76b8aad0bdda4313a02e4342e6a19fd6 | regionOne | placement    | placement      | True    | public    | https://overcloud.lab.local:13778/placement                    |
| 96b004d5217c4d87a38cb780607bf9fb | regionOne | placement    | placement      | True    | internal  | https://overcloud.internalapi.lab.local:8778/placement         |
| 98489b4b107f4da596262b712c3fe883 | regionOne | glance       | image          | True    | internal  | https://overcloud.internalapi.lab.local:9292                   |
| bb7ab36f30b14b549178ef06ec74ff84 | regionOne | glance       | image          | True    | admin     | https://overcloud.internalapi.lab.local:9292                   |
| c1547f7bf9a14e9e85eaaaeea26413b7 | regionOne | neutron      | network        | True    | admin     | https://overcloud.internalapi.lab.local:9696                   |
| ca66f499ec544f42838eb78a515d9f1e | regionOne | keystone     | identity       | True    | internal  | https://overcloud.internalapi.lab.local:5000                   |
| df0181358c07431390bc66822176281d | regionOne | swift        | object-store   | True    | internal  | https://overcloud.storage.lab.local:8080/v1/AUTH_%(tenant_id)s |
| e420350ef856460991c3edbfbae917c1 | regionOne | neutron      | network        | True    | internal  | https://overcloud.internalapi.lab.local:9696                   |
+----------------------------------+-----------+--------------+----------------+---------+-----------+---------------------------------------------------------------+

本項では、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 テンプレートは tht/puppet/services/glance-api.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

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

デフォルトでは、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'

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 を有効化した場合には (15章オーバークラウドのパブリックエンドポイントでの 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 を参照してください。