第10章 基本的なネットワーク分離

特定の種別のネットワークトラフィックを分離してホストできるように、分離されたネットワークを使用するようにオーバークラウドを設定します。Red Hat OpenStack Platform には、このネットワーク分離を設定するための環境ファイルのセットが含まれています。ネットワーク設定のパラメーターをさらにカスタマイズするために、追加の環境ファイルが必要になる場合もあります。

  • ネットワーク分離を有効にするための環境ファイル (/usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml)
  • ネットワークのデフォルト値を設定するための環境ファイル (/usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml)
  • IP 範囲、サブネット、仮想 IP 等のネットワーク設定を定義するための network_data ファイル。以下の例では、デフォルトのファイルをコピーし、それをご自分のネットワークに合わせて編集する方法について説明します。
  • 各ノードの NIC レイアウトを定義するためのテンプレート。オーバークラウドのコアテンプレートコレクションには、さまざまなユースケースに対応する複数のデフォルトが含まれます。
  • NIC を有効にするための環境ファイル。以下の例では、environments ディレクトリーにあるデフォルトファイルを使用しています。
注記

前述の一覧のファイルは一部 Jinja2 形式のファイルで、.j2.yaml の拡張子を持つものがあります。director は、デプロイメント中にこれらのファイルを .yaml バージョンにレンダリングします。

10.1. ネットワーク分離

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

オーバークラウドネットワークのその他の機能 (「カスタムコンポーザブルネットワーク」および「カスタムネットワークインターフェーステンプレート」を参照) は、network-isolation.yaml 環境ファイルに依存します。したがって、デプロイメントコマンドにレンダリングした環境ファイルを追加する必要があります。

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

10.2. 分離ネットワーク設定の変更

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

手順

  1. デフォルトの network_data.yaml ファイルをコピーします。

    $ cp /usr/share/openstack-tripleo-heat-templates/network_data.yaml /home/stack/.
  2. network_data.yaml ファイルのローカルコピーを編集し、ご自分のネットワーク要件に応じてパラメーターを変更します。たとえば、内部 API ネットワークには以下のデフォルトネットワーク情報が含まれます。

    - name: InternalApi
      name_lower: internal_api
      vip: true
      vlan: 201
      ip_subnet: '172.16.2.0/24'
      allocation_pools: [{'start': '172.16.2.4', 'end': '172.16.2.250'}]

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

  • vlan: このネットワークに使用する VLAN ID を定義します。
  • ip_subnet および ip_allocation_pools: ネットワークのデフォルトサブネットおよび IP 範囲を設定します。
  • gateway: ネットワークのゲートウェイを設定します。この値を使用して、外部ネットワークまたは必要に応じて他のネットワークのデフォルトルートを定義します。

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

10.3. ネットワークインターフェーステンプレート

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

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

heat_template_version
使用する構文のバージョン
description
テンプレートを説明する文字列
parameters
テンプレートに追加するネットワークパラメーター
resources
parameters で定義したパラメーターを取得し、それらをネットワークの設定スクリプトに適用します。
outputs
設定に使用する最終スクリプトをレンダリングします。

/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 バージョンにレンダリングする方法は、「「カスタムネットワークインターフェーステンプレート」」で説明します。この YAML バージョンを、カスタマイズのベースとして使用することができます。

10.4. デフォルトのネットワークインターフェーステンプレート

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

注記

NIC テンプレートを有効にするそれぞれの環境ファイルには、接尾辞 .j2.yaml が使われます。これはレンダリング前の Jinja2 バージョンです。デプロイメントには、接尾辞に .yaml が使われるレンダリング済みのファイル名を指定するようにしてください。

NIC ディレクトリー説明環境ファイル

single-nic-vlans

単一の NIC (nic1) がコントロールプレーンネットワークにアタッチされ、VLAN 経由でデフォルトの Open vSwitch ブリッジにアタッチされる。

environments/net-single-nic-with-vlans.j2.yaml

single-nic-linux-bridge-vlans

単一の NIC (nic1) がコントロールプレーンネットワークにアタッチされ、VLAN 経由でデフォルトの Linux ブリッジにアタッチされる。

environments/net-single-nic-linux-bridge-with-vlans

bond-with-vlans

コントロールプレーンネットワークが nic1 にアタッチされる。ボンディング構成の NIC (nic2 および nic3) が VLAN 経由でデフォルトの Open vSwitch ブリッジにアタッチされる。

environments/net-bond-with-vlans.yaml

multiple-nics

コントロールプレーンネットワークが nic1 にアタッチされる。それ以降の NIC は network_data.yaml ファイルで定義されるネットワークに割り当てられる。デフォルトでは、Storage が nic2 に、Storage Management が nic3 に、Internal API が nic4 に、Tenant が br-tenant ブリッジ上の nic5 に、External がデフォルトの Open vSwitch ブリッジ上の nic6 に割り当てられる。

environments/net-multiple-nics.yaml

注記

外部ネットワークを使用しないオーバークラウドデプロイ用の環境ファイル (例: net-bond-with-vlans-no-external.yaml) や IPv6 デプロイメント用の環境ファイル (例: net-bond-with-vlans-v6.yaml) も存在します。これらは後方互換のために提供されるもので、コンポーザブルネットワークでは機能しません。

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

  • compute.yaml
  • controller.yaml
  • ceph-storage.yaml

10.5. 基本的なネットワーク分離の有効化

director には、基本的なネットワーク分離を有効にするためのテンプレートが含まれています。これらのファイルは、/usr/share/openstack-tripleo-heat-templates/environments ディレクトリーにあります。たとえば、テンプレートを使用して、基本的なネットワーク分離の VLAN が設定された単一の NIC にオーバークラウドをデプロイすることができます。以下のシナリオでは、net-single-nic-with-vlans テンプレートを使用します。

手順

  1. openstack overcloud deploy コマンドを実行する際に、以下のレンダリング済み環境ファイルを追加するようにしてください。

    • カスタム network_data.yaml ファイル
    • デフォルトネットワーク分離ファイルのレンダリング済みファイル名
    • デフォルトネットワーク環境ファイルのレンダリング済みファイル名
    • デフォルトネットワークインターフェース設定ファイルのレンダリング済みファイル名
    • 設定に必要なその他の環境ファイル

以下に例を示します。

$ 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 \
    ...

10.5.1. カスタムコンポーザブルネットワーク

特定のネットワークトラフィックを異なるネットワークでホストする場合は、カスタムコンポーザブルネットワークを作成することができます。オーバークラウドに追加のコンポーザブルネットワークを設定するには、以下のファイルおよびテンプレートを設定する必要があります。

  • ネットワーク分離を有効にするための環境ファイル (/usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml)
  • ネットワークのデフォルト値を設定するための環境ファイル (/usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml)
  • デフォルト以外の追加ネットワークを作成するためのカスタム network_data ファイル
  • カスタムネットワークをロールに割り当てるためのカスタム roles_data ファイル
  • 各ノードの NIC レイアウトを定義するためのテンプレート。オーバークラウドのコアテンプレートコレクションには、さまざまなユースケースに対応する複数のデフォルトが含まれます。
  • NIC を有効にするための環境ファイル。以下の例では、environments ディレクトリーにあるデフォルトファイルを使用しています。
  • ネットワーク設定パラメーターをカスタマイズするその他の環境ファイル。以下の例では、OpenStack サービスとコンポーザブルネットワークのマッピングをカスタマイズするための環境ファイルを用いています。
注記

前述の一覧のファイルは一部 Jinja2 形式のファイルで、.j2.yaml の拡張子を持つものがあります。director は、デプロイメント中にこれらのファイルを .yaml バージョンにレンダリングします。

10.5.1.1. コンポーザブルネットワーク

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

  • Control Plane
  • Internal API
  • Storage
  • Storage Management
  • Tenant
  • External
  • Management (オプション)

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

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

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

10.5.1.2. コンポーザブルネットワークの追加

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

手順

  1. デフォルトの network_data.yaml ファイルをコピーします。

    $ cp /usr/share/openstack-tripleo-heat-templates/network_data.yaml /home/stack/.
  2. network_data.yaml ファイルのローカルコピーを編集し、新規ネットワーク用のセクションを追加します。

    - name: StorageBackup
      name_lower: storage_backup
      vlan: 21
      vip: true
      ip_subnet: '172.21.1.0/24'
      allocation_pools: [{'start': '171.21.1.4', 'end': '172.21.1.250'}]
      gateway_ip: '172.21.1.1'

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

name
人間が判読可能なネットワークの名前を設定します。必須のパラメーターは、このパラメーターだけです。判読性を向上させるために、name_lower を使用して名前を正規化することもできます。たとえば、InternalApiinternal_api に変更します。
name_lower
ネットワーク名の小文字バージョンを設定します。director は、この名前を roles_data.yaml ファイルのロールに割り当てられる該当ネットワークにマッピングします。
vlan
このネットワークに使用する VLAN を設定します。
vip: true
新規ネットワーク上に仮想 IP アドレス (VIP) を作成します。この IP は、サービス/ネットワーク間のマッピングパラメーター (ServiceNetMap) に一覧表示されるサービスのターゲット IP として使用されます。仮想 IP は Pacemaker を使用するロールにしか使用されない点に注意してください。オーバークラウドの負荷分散サービスにより、トラフィックがこれらの IP から対応するサービスのエンドポイントにリダイレクトされます。
ip_subnet
デフォルトの IPv4 サブネットを CIDR 形式で設定します。
allocation_pools
IPv4 サブネットの IP 範囲を設定します。
gateway_ip
ネットワークのゲートウェイを設定します。
routes

ネットワークに新たなルートを追加します。それぞれの追加ルートが含まれる JSON リストを使用します。それぞれのリスト項目には、ディクショナリーの値のマッピングが含まれます。構文例を以下に示します。

  routes: [{'destination':'10.0.0.0/16', 'nexthop':'10.0.2.254'}]
subnets

このネットワーク内にある追加のルーティングされたサブネットを作成します。このパラメーターでは、ルーティングされたサブネット名の小文字バージョンが含まれる dict 値をキーとして指定し、vlanip_subnetallocation_pools、および gateway_ip パラメーターをサブネットにマッピングする値として指定します。このレイアウトの例を以下に示します。

- name: StorageBackup
  name_lower: storage_backup
  vlan: 200
  vip: true
  ip_subnet: '172.21.0.0/24'
  allocation_pools: [{'start': '171.21.0.4', 'end': '172.21.0.250'}]
  gateway_ip: '172.21.0.1'
  subnets:
    storage_backup_leaf1:
      vlan: 201
      ip_subnet: '172.21.1.0/24'
      allocation_pools: [{'start': '171.21.1.4', 'end': '172.21.1.250'}]
      gateway_ip: '172.19.1.254'

このマッピングは、スパイン/リーフ型デプロイメントで一般的に使用されます。詳しくは、『スパイン/リーフ型ネットワーク』を参照してください。

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

10.5.1.3. ロールへのコンポーザブルネットワークの追加

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

手順

  1. カスタム roles_data.yaml ファイルがまだない場合には、デフォルトをご自分のホームディレクトリーにコピーします。

    $ cp /usr/share/openstack-tripleo-heat-templates/roles_data.yaml /home/stack/.
  2. カスタム roles_data.yaml ファイルを編集します。
  3. ネットワークを追加するロールの networks 一覧にネットワーク名を追加します。たとえば、StorageBackup ネットワークを Ceph Storage ロールに追加するには、以下のスニペット例を使用します。

    - name: CephStorage
      description: |
        Ceph OSD Storage node role
      networks:
        - Storage
        - StorageMgmt
        - StorageBackup
  4. カスタムネットワークを対応するロールに追加したら、ファイルを保存します。

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

10.5.1.4. コンポーザブルネットワークへの OpenStack サービスの割り当て

各 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.yaml ファイルで vip: true と設定されているネットワークに適用されます。オーバークラウドの負荷分散サービスにより、トラフィックが仮想 IP から特定のサービスのエンドポイントにリダイレクトされます。

注記

デフォルトサービスの全一覧は、/usr/share/openstack-tripleo-heat-templates/network/service_net_map.j2.yaml ファイルの ServiceNetMapDefaults パラメーターに記載されています。

10.5.1.5. カスタムコンポーザブルネットワークの有効化

デフォルト NIC テンプレートの 1 つを使用してカスタムコンポーザブルネットワークを有効にします。以下の例では、VLAN が設定された単一 NIC のテンプレート (net-single-nic-with-vlans) を使用します。

手順

  1. openstack overcloud deploy コマンドを実行する際に、以下のファイルを追加するようにしてください。

    • カスタム network_data.yaml ファイル
    • ネットワーク/ロール間の割り当てを定義するカスタム roles_data.yaml ファイル
    • デフォルトネットワーク分離のレンダリング済みファイル名
    • デフォルトネットワーク環境ファイルのレンダリング済みファイル名
    • デフォルトネットワークインターフェース設定のレンダリング済みファイル名
    • サービスの再割り当て等、ネットワークに関連するその他の環境ファイル

以下に例を示します。

$ 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 \
    ...

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

重要

管理ネットワーク等の新しいカスタムネットワークを導入する場合は、テンプレートを再度レンダリングする必要がある点に注意してください。ネットワーク名を roles_data.yaml ファイルに追加するだけでは不十分です。

10.5.1.6. デフォルトネットワークの名前変更

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

  • InternalApi
  • External
  • Storage
  • StorageMgmt
  • Tenant

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

手順

  1. network_data.yaml ファイルで、名前を変更する各ネットワークの name_lower パラメーターに新しい名前を入力します。

    - name: InternalApi
      name_lower: MyCustomInternalApi
  2. service_net_map_replace パラメーターに、name_lower パラメーターのデフォルト値を追加します。

    - name: InternalApi
      name_lower: MyCustomInternalApi
      service_net_map_replace: internal_api

10.5.2. カスタムネットワークインターフェーステンプレート

10章基本的なネットワーク分離」を設定したら、実際の環境内のノードに適したカスタムネットワークインターフェーステンプレートのセットを作成することができます。たとえば、以下のファイルを含めることができます。

  • ネットワーク分離を有効にするための環境ファイル (/usr/share/openstack-tripleo-heat-templates/environments/network-isolation.yaml)
  • ネットワークのデフォルト値を設定するための環境ファイル (/usr/share/openstack-tripleo-heat-templates/environments/network-environment.yaml)
  • 各ノードの NIC レイアウトを定義するためのテンプレート。オーバークラウドのコアテンプレートコレクションには、さまざまなユースケースに対応する複数のデフォルトが含まれます。カスタム NIC テンプレートを作成するには、デフォルトの Jinja2 テンプレートをレンダリングしてカスタムテンプレートのベースにします。
  • NIC を有効にするためのカスタム環境ファイル。以下の例では、カスタムインターフェーステンプレートを参照するカスタム環境ファイル (/home/stack/templates/custom-network-configuration.yaml) を用いています。
  • ネットワーク設定パラメーターをカスタマイズするその他の環境ファイル
  • ネットワークをカスタマイズする場合には、カスタム network_data.yaml ファイル
  • 追加のネットワークまたはカスタムコンポーザブルネットワークを作成する場合には、カスタム network_data.yaml ファイルおよびカスタム roles_data.yaml ファイル
注記

前述の一覧のファイルは一部 Jinja2 形式のファイルで、.j2.yaml の拡張子を持つものがあります。director は、デプロイメント中にこれらのファイルを .yaml バージョンにレンダリングします。

10.5.2.1. カスタムネットワークアーキテクチャー

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

  • NIC1 (プロビジョニング)

    • Provisioning / Control Plane
  • NIC2 (コントロールグループ)

    • Internal API
    • Storage Management
    • External (パブリック API)
  • NIC3 (データグループ)

    • Tenant Network (VXLAN トンネリング)
    • Tenant VLAN / Provider VLAN
    • Storage
    • External VLAN (Floating IP/SNAT)
  • NIC4 (管理)

    • Management

10.5.2.2. カスタマイズのためのデフォルトネットワークインターフェーステンプレートのレンダリング

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

手順

  1. process-templates.py スクリプトを使用して、openstack-tripleo-heat-templates コレクションのコピーをレンダリングします。

    $ cd /usr/share/openstack-tripleo-heat-templates
    $ ./tools/process-templates.py -o ~/openstack-tripleo-heat-templates-rendered

    これにより、すべての Jinja2 テンプレートがレンタリング済みの YAML バージョンに変換され、結果が ~/openstack-tripleo-heat-templates-rendered に保存されます。

    カスタムネットワークファイルまたはカスタムロールファイルを使用する場合には、それぞれ -n および -r オプションを使用して、それらのファイルを含めることができます。

    $ ./tools/process-templates.py -o ~/openstack-tripleo-heat-templates-rendered -n /home/stack/network_data.yaml -r /home/stack/roles_data.yaml
  2. 複数 NIC の例をコピーします。

    $ cp -r ~/openstack-tripleo-heat-templates-rendered/network/config/multiple-nics/ ~/templates/custom-nics/
  3. ご自分のネットワーク構成に適するように、custom-nics のテンプレートセットを編集します。

10.5.2.3. ネットワークインターフェースのアーキテクチャー

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

パラメーター

parameters セクションには、ネットワークインターフェース用の全ネットワーク設定パラメーターが記載されます。これには、サブネットの範囲や VLAN ID などが含まれます。heat テンプレートは、その親テンプレートから値を継承するので、このセクションは、変更せずにそのまま維持するべきです。ただし、ネットワーク環境ファイルを使用して一部のパラメーターの値を変更することが可能です。

リソース

resources セクションには、ネットワークインターフェースの主要な設定を指定します。大半の場合、変更する必要があるのは resources セクションのみです。各 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:

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

重要

カスタム NIC テンプレートを作成する場合には、各 NIC テンプレートについて run-os-net-config.sh スクリプトの場所を絶対パスに設定する必要があります。スクリプトは、アンダークラウドの /usr/share/openstack-tripleo-heat-templates/network/scripts/run-os-net-config.sh に保存されています。

10.5.2.4. ネットワークインターフェースの参照

ネットワークインターフェースの設定には、以下のパラメーターが含まれます。

interface

単一のネットワークインターフェースを定義します。この設定では、実際のインターフェース名 (eth0、eth1、enp0s25) または番号によるインターフェース (nic1、nic2、nic3) を使用して各インターフェースを定義します。

  - type: interface
    name: nic2

表10.1 interface のオプション

オプションデフォルト説明

name

 

インターフェース名

use_dhcp

False

DHCP を使用して IP アドレスを取得します。

use_dhcpv6

False

DHCP を使用して v6 の IP アドレスを取得します。

addresses

 

インターフェースに割り当てられる IP アドレスの一覧

routes

 

インターフェースに割り当てられるルートの一覧。詳細な情報は、「routes」を参照してください。

mtu

1500

接続の最大伝送単位 (MTU: Maximum Transmission Unit)

primary

False

プライマリーインターフェースとしてインターフェースを定義します。

defroute

True

DHCP サービスにより提供されるデフォルトのルートを使用します。use_dhcp または use_dhcpv6 を選択した場合に限り有効です。

persist_mapping

False

システム名の代わりにデバイスのエイリアス設定を記述します。

dhclient_args

なし

DHCP クライアントに渡す引数

dns_servers

なし

インターフェースに使用する DNS サーバーの一覧

ethtool_opts

 

特定の NIC で VXLAN を使用する際にスループットを向上させるには、このオプションを "rx-flow-hash udp4 sdfn" に設定します。

vlan

VLAN を定義します。parameters セクションから渡された VLAN ID およびサブネットを使用します。

以下に例を示します。

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

表10.2 vlan のオプション

オプションデフォルト説明

vlan_id

 

VLAN ID

device

 

VLAN の接続先となる親デバイス。VLAN が OVS ブリッジのメンバーではない場合に、このパラメーターを使用します。たとえば、このパラメーターを使用して、ボンディングされたインターフェースデバイスに VLAN を接続します。

use_dhcp

False

DHCP を使用して IP アドレスを取得します。

use_dhcpv6

False

DHCP を使用して v6 の IP アドレスを取得します。

addresses

 

VLAN に割り当てられる IP アドレスの一覧

routes

 

VLAN に割り当てられるルートの一覧。詳細な情報は、「routes」を参照してください。

mtu

1500

接続の最大伝送単位 (MTU: Maximum Transmission Unit)

primary

False

プライマリーインターフェースとして VLAN を定義します。

defroute

True

DHCP サービスにより提供されるデフォルトのルートを使用します。use_dhcp または use_dhcpv6 を選択した場合に限り有効です。

persist_mapping

False

システム名の代わりにデバイスのエイリアス設定を記述します。

dhclient_args

なし

DHCP クライアントに渡す引数

dns_servers

なし

VLAN に使用する DNS サーバーの一覧

ovs_bond

Open vSwitch で、複数の インターフェース を結合するボンディングを定義します。これにより、冗長性や帯域幅が向上します。

以下に例を示します。

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

表10.3 ovs_bond のオプション

オプションデフォルト説明

name

 

ボンディング名

use_dhcp

False

DHCP を使用して IP アドレスを取得します。

use_dhcpv6

False

DHCP を使用して v6 の IP アドレスを取得します。

addresses

 

ボンディングに割り当てられる IP アドレスの一覧

routes

 

ボンディングに割り当てられるルートの一覧。詳細な情報は、「routes」を参照してください。

mtu

1500

接続の最大伝送単位 (MTU: Maximum Transmission Unit)

primary

False

プライマリーインターフェースとしてインターフェースを定義します。

members

 

ボンディングで使用するインターフェースオブジェクトの一覧

ovs_options

 

ボンディング作成時に OVS に渡すオプションのセット

ovs_extra

 

ボンディングのネットワーク設定ファイルで OVS_EXTRA パラメーターとして設定するオプションのセット

defroute

True

DHCP サービスにより提供されるデフォルトのルートを使用します。use_dhcp または use_dhcpv6 を選択した場合に限り有効です。

persist_mapping

False

システム名の代わりにデバイスのエイリアス設定を記述します。

dhclient_args

なし

DHCP クライアントに渡す引数

dns_servers

なし

ボンディングに使用する DNS サーバーの一覧

ovs_bridge

Open vSwitch で、複数の interfaceovs_bondvlan オブジェクトを接続するブリッジを定義します。

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

注記

複数のブリッジがある場合は、デフォルト名の bridge_name を受け入れるのではなく、個別のブリッジ名を使用する必要があります。個別の名前を使用しないと、コンバージフェーズ時に 2 つのネットワークボンディングが同じブリッジに配置されます。

外部の 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}
注記

OVS ブリッジは、Networking サービス (neutron) サーバーに接続して設定データを取得します。OpenStack の制御トラフィック (通常 Control Plane および Internal API ネットワーク) が OVS ブリッジに配置されていると、OVS がアップグレードされたり、管理ユーザーやプロセスによって OVS ブリッジが再起動されたりする度に、neutron サーバーへの接続が失われます。これにより、ダウンタイムが発生します。このような状況でダウンタイムが許容されない場合は、コントロールグループのネットワークを OVS ブリッジではなく別のインターフェースまたはボンディングに配置する必要があります。

  • Internal API ネットワークをプロビジョニングインターフェース上の VLAN および 2 番目のインターフェース上の OVS ブリッジに配置すると、最小の設定を行うことができます。
  • ボンディングを実装する場合は、少なくとも 2 つのボンディング (4 つのネットワークインターフェース) が必要です。コントロールグループを Linux ボンディング (Linux ブリッジ) に配置します。PXE ブート用のシングルインターフェースへの LACP フォールバックをスイッチがサポートしていない場合には、このソリューションには少なくとも 5 つの NIC が必要となります。

表10.4 ovs_bridge のオプション

オプションデフォルト説明

name

 

ブリッジ名

use_dhcp

False

DHCP を使用して IP アドレスを取得します。

use_dhcpv6

False

DHCP を使用して v6 の IP アドレスを取得します。

addresses

 

ブリッジに割り当てられる IP アドレスの一覧

routes

 

ブリッジに割り当てられるルートの一覧。詳細な情報は、「routes」を参照してください。

mtu

1500

接続の最大伝送単位 (MTU: Maximum Transmission Unit)

members

 

ブリッジで使用するインターフェース、VLAN、およびボンディングオブジェクトの一覧

ovs_options

 

ブリッジ作成時に OVS に渡すオプションのセット

ovs_extra

 

ブリッジのネットワーク設定ファイルで OVS_EXTRA パラメーターとして設定するオプションのセット

defroute

True

DHCP サービスにより提供されるデフォルトのルートを使用します。use_dhcp または use_dhcpv6 を選択した場合に限り有効です。

persist_mapping

False

システム名の代わりにデバイスのエイリアス設定を記述します。

dhclient_args

なし

DHCP クライアントに渡す引数

dns_servers

なし

ブリッジに使用する DNS サーバーの一覧

linux_bond

複数の インターフェース を結合する Linux ボンディングを定義します。これにより、冗長性や帯域幅が向上します。bonding_options パラメーターには、カーネルベースのボンディングオプションを指定するようにしてください。

以下に例を示します。

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

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

表10.5 linux_bond のオプション

オプションデフォルト説明

name

 

ボンディング名

use_dhcp

False

DHCP を使用して IP アドレスを取得します。

use_dhcpv6

False

DHCP を使用して v6 の IP アドレスを取得します。

addresses

 

ボンディングに割り当てられる IP アドレスの一覧

routes

 

ボンディングに割り当てられるルートの一覧。「routes」を参照してください。

mtu

1500

接続の最大伝送単位 (MTU: Maximum Transmission Unit)

primary

False

プライマリーインターフェースとしてインターフェースを定義します。

members

 

ボンディングで使用するインターフェースオブジェクトの一覧

bonding_options

 

ボンディングを作成する際のオプションのセット

defroute

True

DHCP サービスにより提供されるデフォルトのルートを使用します。use_dhcp または use_dhcpv6 を選択した場合に限り有効です。

persist_mapping

False

システム名の代わりにデバイスのエイリアス設定を記述します。

dhclient_args

なし

DHCP クライアントに渡す引数

dns_servers

なし

ボンディングに使用する DNS サーバーの一覧

linux_bridge

複数の interfacelinux_bondvlan オブジェクトを接続する Linux ブリッジを定義します。外部のブリッジは、パラメーターに 2 つの特殊な値も使用します。

  • bridge_name: 外部ブリッジ名に置き換えます。
  • interface_name: 外部インターフェースに置き換えます。

以下に例を示します。

      - 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}

表10.6 linux_bridge のオプション

オプションデフォルト説明

name

 

ブリッジ名

use_dhcp

False

DHCP を使用して IP アドレスを取得します。

use_dhcpv6

False

DHCP を使用して v6 の IP アドレスを取得します。

addresses

 

ブリッジに割り当てられる IP アドレスの一覧

routes

 

ブリッジに割り当てられるルートの一覧。詳細な情報は、「routes」を参照してください。

mtu

1500

接続の最大伝送単位 (MTU: Maximum Transmission Unit)

members

 

ブリッジで使用するインターフェース、VLAN、およびボンディングオブジェクトの一覧

defroute

True

DHCP サービスにより提供されるデフォルトのルートを使用します。use_dhcp または use_dhcpv6 を選択した場合に限り有効です。

persist_mapping

False

システム名の代わりにデバイスのエイリアス設定を記述します。

dhclient_args

なし

DHCP クライアントに渡す引数

dns_servers

なし

ブリッジに使用する DNS サーバーの一覧

routes

ネットワークインターフェース、VLAN、ブリッジ、またはボンディングに適用するルートの一覧を定義します。

以下に例を示します。

  - type: interface
    name: nic2
    ...
    routes:
      - ip_netmask: 10.1.2.0/24
        default: true
        next_hop:
          get_param: EC2MetadataIp
オプションデフォルト説明

ip_netmask

なし

接続先ネットワークの IP およびネットマスク

default

False

このルートをデフォルトルートに設定します。ip_netmask: 0.0.0.0/0 の設定と等価です。

next_hop

なし

接続先ネットワークに到達するのに使用するルーターの IP アドレス

10.5.2.5. ネットワークインターフェースレイアウトの例

以下のスニペットはコントローラーノードの 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 ブリッジを作成します。その結果、以下のレイアウトが作成されます。

  • NIC1 (プロビジョニング)

    • Provisioning / Control Plane
  • NIC2 (コントロールグループ)

    • Internal API
    • Storage Management
    • External (パブリック API)
  • NIC3 (データグループ)

    • Tenant Network (VXLAN トンネリング)
    • Tenant VLAN / Provider VLAN
    • Storage
    • External VLAN (Floating IP/SNAT)
  • NIC4 (管理)

    • Management

10.5.2.6. カスタムネットワークにおけるネットワークインターフェーステンプレートの考慮事項

コンポーザブルネットワークを使用する場合には、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

10.5.2.7. カスタムネットワーク環境ファイル

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

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

  • OS::TripleO::[ROLE]::Net::SoftwareConfig: [FILE]

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

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

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

10.5.2.8. ネットワーク環境パラメーター

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

パラメーター説明タイプ

ControlPlaneDefaultRoute

コントロールプレーン上のルーターの IP アドレスで、コントローラーノード以外のロールのデフォルトルートとして使用されます。ルーターの代わりに IP マスカレードを使用する場合には、この値をアンダークラウドの IP に設定します。

文字列

ControlPlaneSubnetCidr

コントロールプレーン上で使用される IP ネットワークの CIDR ネットマスク。コントロールプレーンのネットワークが 192.168.24.0/24 を使用する場合には、CIDR は 24 になります。

文字列 (ただし、実際には数値)

*NetCidr

特定のネットワークの完全なネットワークおよび CIDR ネットマスク。このパラメーターのデフォルト値は、network_data.yaml ファイルで規定するネットワークの ip_subnet に自動的に設定されます。例: InternalApiNetCidr: 172.16.0.0/24

文字列

*AllocationPools

特定のネットワークに対する IP 割り当て範囲。このパラメーターのデフォルト値は、network_data.yaml ファイルで規定するネットワークの allocation_pools に自動的に設定されます。例: InternalApiAllocationPools: [{'start': '172.16.0.10', 'end': '172.16.0.200'}]

ハッシュ

*NetworkVlanID

特定ネットワーク上のノードの VLAN ID。このパラメーターのデフォルト値は、network_data.yaml ファイルで規定するネットワークの vlan に自動的に設定されます。例: InternalApiNetworkVlanID: 201

数値

*InterfaceDefaultRoute

特定のネットワークのルーターアドレスで、ロールのデフォルトルートとして、あるいは他のネットワークへのルートに使用することができます。このパラメーターのデフォルト値は、network_data.yaml ファイルで規定するネットワークの gateway_ip に自動的に設定されます。例: InternalApiInterfaceDefaultRoute: 172.16.0.1

文字列

DnsServers

resolv.conf に追加する DNS サーバーの一覧。通常は、最大で 2 つのサーバーが許可されます。

コンマ区切りリスト

EC2MetadataIp

オーバークラウドノードのプロビジョニングに使用されるメタデータサーバーの IP アドレス。この値をコントロールプレーン上のアンダークラウドの IP アドレスに設定します。

文字列

BondInterfaceOvsOptions

ボンディングインターフェースのオプション (例: BondInterfaceOvsOptions: "bond_mode=balance-slb")

文字列

NeutronExternalNetworkBridge

OpenStack Networking (neutron) に使用する外部ブリッジ名のレガシー値。この値はデフォルトでは空欄になっています。したがって、NeutronBridgeMappings で複数の物理ブリッジを定義することができます。通常は、この値をオーバーライドしないでください。

文字列

NeutronFlatNetworks

neutron プラグインで設定するフラットネットワークを定義します。外部ネットワークを作成できるように、デフォルト値は datacentre に設定されています (例: NeutronFlatNetworks: "datacentre")。

文字列

NeutronBridgeMappings

使用する論理ブリッジから物理ブリッジへのマッピング。デフォルト値は、ホストの外部ブリッジ (br-ex) を物理名 (datacentre) にマッピングします。OpenStack Networking (neutron) プロバイダーネットワークまたは Floating IP ネットワークを作成する際に、論理名を参照します。例: NeutronBridgeMappings: "datacentre:br-ex,tenant:br-tenant"

文字列

NeutronPublicInterface

ネットワーク分離を使用しない場合に、ネットワークノード向けに br-ex にブリッジするインターフェースを定義します。通常、ネットワークを 2 つしか持たない小規模なデプロイメント以外では使用しません。例: NeutronPublicInterface: "eth0"

文字列

NeutronNetworkType

OpenStack Networking (neutron) のテナントネットワーク種別。複数の値を指定するには、コンマ区切りリストを使用します。利用可能なネットワークがすべてなくなるまで、最初に指定した種別が使用されます。その後、次の種別が使用されます。例: NeutronNetworkType: "vxlan"。デフォルトの ML2 メカニズムドライバーである ML2/OVN メカニズムドライバーでは、vxlan はサポートされない点に注意してください。

文字列

NeutronTunnelTypes

neutron テナントネットワークのトンネリング種別。複数の値を指定するには、コンマ区切りの文字列を使用します (例: NeutronTunnelTypes: 'gre,vxlan')。デフォルトの ML2 メカニズムドライバーである ML2/OVN メカニズムドライバーでは、vxlan はサポートされない点に注意してください。

文字列 / コンマ区切りリスト

NeutronTunnelIdRanges

テナントネットワークの割り当てに使用可能にする GRE トンネリングの ID 範囲 (例: NeutronTunnelIdRanges "1:1000")

文字列

NeutronVniRanges

テナントネットワークの割り当てに使用可能にする VXLAN VNI の ID 範囲 (例: NeutronVniRanges: "1:1000")

文字列

NeutronEnableTunnelling

すべてのトンネル化ネットワークを有効にするか完全に無効にするかを定義します。トンネル化ネットワークを作成する予定がないことが明確な場合を除き、このパラメーターは有効のままにしてください。デフォルト値は true です。

ブール値

NeutronNetworkVLANRanges

サポートする ML2 および Open vSwitch VLAN マッピングの範囲。デフォルトでは、物理ネットワーク datacentre 上の任意の VLAN を許可するように設定されています。複数の値を指定するには、コンマ区切りリストを使用します (例: NeutronNetworkVLANRanges: "datacentre:1:1000,tenant:100:299,tenant:310:399")。

文字列

NeutronMechanismDrivers

neutron テナントネットワークのメカニズムドライバー。デフォルト値は ovn です。複数の値を指定するには、コンマ区切りの文字列を使用します (例: NeutronMechanismDrivers: 'openvswitch,l2population')。

文字列 / コンマ区切りリスト

10.5.2.9. カスタムネットワーク環境ファイルの例

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: "''"

10.5.2.10. カスタム NIC を使用したネットワーク分離の有効化

ネットワーク分離およびカスタム NIC テンプレートを使用してオーバークラウドをデプロイするには、オーバークラウドのデプロイメントコマンドに該当するすべてのネットワーク環境ファイルを追加します。

手順

  1. openstack overcloud deploy コマンドを実行する際に、以下のファイルを追加します。

    • カスタム network_data.yaml ファイル
    • デフォルトネットワーク分離のレンダリング済みファイル名
    • デフォルトネットワーク環境ファイルのレンダリング済みファイル名
    • カスタム 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 \
    ...
  • まず network-isolation.yaml ファイルを指定し、次に network-environment.yaml ファイルを指定します。それに続く custom-network-configuration.yaml は、前の 2 つのファイルからの OS::TripleO::[ROLE]::Net::SoftwareConfig リソースを上書きします。
  • コンポーザブルネットワークを使用する場合には、このコマンドに network_data.yaml および roles_data.yaml ファイルを含めます。

10.5.3. その他のネットワーク設定

本章では、「「カスタムネットワークインターフェーステンプレート」」で説明した概念および手順に続いて、オーバークラウドネットワークの要素を設定する際に役立つその他の情報を提供します。

10.5.3.1. カスタムインターフェースの設定

インターフェースは個別に変更を加える必要がある場合があります。以下の例では、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

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

番号によるインターフェースの順序は、名前によるネットワークインターフェース種別の順序に対応します。

  • eth0eth1 などの ethX。これらは、通常オンボードのインターフェースです。
  • eno0eno1 などの enoX。これらは、通常オンボードのインターフェースです。
  • enp3s0enp3s1ens3 などの英数字順の enX インターフェース。これらは、通常アドオンのインターフェースです。

番号による NIC スキームには、アクティブなインターフェースだけが含まれます (たとえば、インターフェースにスイッチに接続されたケーブルがあるかどうかが考慮されます)。4 つのインターフェースを持つホストと、6 つのインターフェースを持つホストがある場合は、nic1 から nic4 を使用して各ホストで 4 本のケーブルだけを結線します。

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

注記

通常、os-net-config はすでに接続済みの UP 状態のインターフェースしか登録しません。ただし、カスタムマッピングファイルを使用してインターフェースをハードコーディングすると、DOWN 状態のインターフェースであっても登録されます。

インターフェースは、環境ファイルを使用してエイリアスにマッピングされます。以下の例では、各ノードの 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 セクションに表示されます。

注記

NetConfigDataLookup パラメーターは、事前にプロビジョニングされたノードへのデプロイメント時に適用されません。事前にプロビジョニングされたノードでカスタムインターフェースマッピングを使用する場合は、デプロイメントの前に各ノードに /etc/os-net-config/mapping.yaml ファイルを作成する必要があります。以下に示す /etc/os-net-config/mapping.yaml ファイルのインターフェースマッピングの例を使用します。

interface_mapping:
  nic1: em1
  nic2: em2

10.5.3.2. ルートおよびデフォルトルートの設定

ホストのデフォルトルートは、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
注記

defroute パラメーターは、DHCP で取得したルートにのみ適用されます。

固定 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

10.5.3.3. ポリシーベースのルーティングの設定

重要

この機能は、本リリースでは テクノロジープレビュー として提供しているため、Red Hat では全面的にはサポートしていません。これは、テスト用途にのみご利用いただく機能で、実稼働環境にデプロイすべきではありません。テクノロジープレビュー機能についての詳しい情報は、「対象範囲の詳細」を参照してください。

コントローラーノードで、異なるネットワークからの無制限のアクセスを設定するには、ポリシーベースのルーティングを設定します。複数のインターフェースを持つホストでは、ポリシーベースのルーティングはルーティングテーブルを使用し、送信元のアドレスに応じて特定のインターフェース経由でトラフィックを送信することができます。送信先が同じであっても、異なる送信元からのパケットを異なるネットワークにルーティングすることができます。

たとえば、デフォルトのルートが External ネットワークの場合でも、パケットの送信元アドレスに基づいてトラフィックを Internal API ネットワークに送信するようにルートを設定することができます。インターフェースごとに特定のルーティングルールを定義することもできます。

Red Hat OpenStack Platform では os-net-config ツールを使用してオーバークラウドノードのネットワーク属性を設定します。os-net-config ツールは、コントローラーノードの以下のネットワークルーティングを管理します。

  • /etc/iproute2/rt_tables ファイルのルーティングテーブル
  • /etc/sysconfig/network-scripts/rule-{ifname} ファイルの IPv4 ルール
  • /etc/sysconfig/network-scripts/rule6-{ifname} ファイルの IPv6 ルール
  • /etc/sysconfig/network-scripts/route-{ifname} のルーティングテーブル固有のルート

前提条件

手順

  1. ~/templates/custom-nics ディレクトリーからのカスタム NIC テンプレートに route_table および interface エントリーを作成し、インターフェースのルートを定義し、デプロイメントに関連するルールを定義します。

    $network_config:
      network_config:
    
      - type: route_table
        name: <custom>
        table_id: 200
    
      - type: interface
        name: em1
        use_dhcp: false
        addresses:
          - ip_netmask: {get_param: ExternalIpSubnet}
        routes:
          - ip_netmask: 10.1.3.0/24
            next_hop: {get_param: ExternalInterfaceDefaultRoute}
            table: 200
        rules:
          - rule: "iif em1 table 200"
            comment: "Route incoming traffic to em1 with table 200"
          - rule: "from 192.0.2.0/24 table 200"
            comment: "Route all traffic from 192.0.2.0/24 with table 200"
          - rule: "add blackhole from 172.19.40.0/24 table 200"
          - rule: "add unreachable iif em1 from 192.168.1.0/24"
  2. run-os-net-config.sh スクリプトの場所を、作成する各カスタム NIC テンプレートの絶対パスに設定します。スクリプトは、アンダークラウドの /usr/share/openstack-tripleo-heat-templates/network/scripts/ ディレクトリーにあります。

    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
  3. ご自分のデプロイメントに該当するその他の環境ファイルと共に、カスタム NIC 設定およびネットワーク環境ファイルをデプロイメントコマンドに追加します。

    $ openstack overcloud deploy --templates \
    -e ~/templates/<custom-nic-template>
    -e <OTHER_ENVIRONMENT_FILES>

検証手順

  • コントローラーノードで以下のコマンドを入力して、ルーティング設定が正しく機能していることを確認します。

    $ cat /etc/iproute2/rt_tables
    $ ip route
    $ ip rule

10.5.3.4. ジャンボフレームの設定

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

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

ジャンボフレームは、Storage、Storage Management、Internal API、Tenant ネットワークのすべてにメリットをもたらします。

警告

ルーターは、通常レイヤー 3 の境界を超えてジャンボフレームでのデータを転送することができません。接続性の問題を回避するには、プロビジョニングインターフェース、外部インターフェース、および Floating IP インターフェースのデフォルト MTU を変更しないでください。

- 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

10.5.3.5. ジャンボフレームを細分化するための ML2/OVN ノースバウンドパス MTU 検出の設定

内部ネットワーク上の仮想マシンがジャンボフレームを外部ネットワークに送信する場合、内部ネットワークの最大伝送単位 (MTU) が外部ネットワークの MTU より大きいと、ノースバウンドフレームが外部ネットワークの容量を容易に超過してしまいます。

ML2/OVS はこのオーバーサイズパケットの問題を自動的に処理し、ML2/OVN は TCP パケットについてこの問題を自動的に処理します。

ただし、ML2/OVN メカニズムドライバーを使用するデプロイメントで、オーバーズのノースバウンド UDP パケットを適切に処理するには、追加の設定手順を実施する必要があります。

以下の手順により、ML2/OVN ルーターが ICMP の「fragmentation needed」パケットを送信元の仮想マシンに返すように設定します。この場合、送信元アプリケーションはペイロードをより小さなパケットに分割することができます。

注記

East-West トラフィックでは、OVN は East-West パスの最少 MTU を超えるパケットの断片化をサポートしていません。

前提条件

  • RHEL 8.2.0.4 以降 (kernel-4.18.0-193.20.1.el8_2 以降)

手順

  1. カーネルバージョンを確認します。

    ovs-appctl -t ovs-vswitchd dpif/show-dp-features br-int
  2. 出力に Check pkt length action: No の文字列が含まれる場合、または Check pkt length action の文字列が含まれない場合は、RHEL 8.2.0.4 またはそれ以降にアップグレードしてください。あるいは、MTU がより小さい外部ネットワークにジャンボフレームを送信しないでください。
  3. 出力に Check pkt length action: Yes の文字列が含まれる場合は、ml2_conf.ini の [ovn] セクションに以下の値を設定します。

    ovn_emit_need_to_frag = True

10.5.3.6. Floating IP のためのネイティブ VLAN の設定

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

ネットワーク分離環境ファイルの 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 の使用率がやや低くなる可能性があります。

10.5.3.7. トランキングされたインターフェースでのネイティブ VLAN の設定

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

アドレスまたはルートのステートメントをブリッジに移動する場合は、対応する VLAN インターフェースをそのブリッジから削除します。該当する全ロールに変更を加えます。External ネットワークはコントローラーのみに存在するため、変更する必要があるのはコントローラーのテンプレートだけです。Storage ネットワークは全ロールにアタッチされているため、Storage ネットワークがデフォルトの VLAN の場合には、全ロールを変更する必要があります。

10.5.4. ネットワークインターフェースボンディング

カスタムネットワーク設定では、さまざまなボンディングオプションを使用することができます。

10.5.4.1. ネットワークインターフェースボンディングおよび Link Aggregation Control Protocol (LACP)

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

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

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

重要

Red Hat では、OVS カーネルボンディング (type: ovs_bond) ではなく Linux カーネルボンディング (type: linux_bond) を使用することを推奨します。ユーザーモードボンディング (type: ovs_dpdk_bond) は、カーネルモードブリッジ (type: ovs_bridge) ではなくユーザーモードブリッジ (type: ovs_user_bridge) と共に使用します。ただし、ovs_bridgeovs_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

10.5.4.2. Open vSwitch ボンディングのオプション

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

注記

このサポートには Open vSwitch 2.11 以降が必要です。

OVS ボンディングモード

用途

備考

互換性のある LACP オプション

active-backup

高可用性 (active-passive)

 

off

balance-slb

スループットの向上 (active-active)

  • パフォーマンスは、パケットあたりの追加パース量の影響を受けます。
  • vhost-user ロック競合が生じる可能性があります。

active、passive、または off

balance-tcp (テクノロジープレビューのみ)

推奨されない (active-active)

  • L4 ハッシュに必要な再循環が、パフォーマンスに影響を及ぼします。
  • balance-slb と同様に、パフォーマンスはパケットあたりの追加パース量の影響を受け、vhost-user ロック競合が生じる可能性があります。
  • LACP を有効にする必要があります。

active または passive

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

parameter_defaults:
  BondInterfaceOvsOptions: "bond_mode=balance-slb"

10.5.4.3. Linux ボンディングのオプション

ネットワークインターフェースのテンプレートにおいて、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"
  • mode: LACP を有効にします。
  • lacp_rate: LACP パケットの送信間隔を 1 秒または 30 秒に定義します。
  • updelay: インターフェースをトラフィックに使用する前にそのインターフェースがアクティブである必要のある最低限の時間を定義します。この最小設定は、ポートフラッピングによる停止を軽減するのに役立ちます。
  • miimon: ドライバーの MIIMON 機能を使用してポートの状態を監視する間隔 (ミリ秒単位)

10.5.4.4. 一般的なボンディングオプション

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

表10.7 ボンディングオプション

bond_mode=balance-slb

送信元の MAC アドレスと出力の VLAN に基づいてフローのバランスを取り、トラフィックパターンの変化に応じて定期的にリバランスを行います。ボンディングを balance-slb に設定することにより、リモートスイッチについての知識や協力なしに限定された形態の負荷分散が可能となります。SLB は送信元 MAC アドレスと VLAN の各ペアをリンクに割り当て、そのリンクを介して、対象の MAC アドレスと LAN からのパケットをすべて伝送します。このモードはトラフィックパターンの変化に応じて定期的にリバランスを行う、送信元 MAC アドレスと VLAN の番号に基づいた、簡単なハッシュアルゴリズムを使用します。このモードは、Linux ボンディングドライバーで使用されているモード 2 のボンディングに類似しています。このモードを使用すると、スイッチが LACP を使用するように設定されていない場合でも、負荷分散機能を有効にすることができます。

bond_mode=active-backup

このモードは、アクティブな接続が失敗した場合にスタンバイの NIC がネットワーク操作を再開するアクティブ/スタンバイ構成のフェイルオーバーを提供します。物理スイッチに提示される MAC アドレスは 1 つのみです。このモードには、特別なスイッチのサポートや設定は必要なく、リンクが別のスイッチに接続された際に機能します。このモードは、負荷分散機能は提供しません。

lacp=[active|passive|off]

Link Aggregation Control Protocol (LACP) の動作を制御します。LACP をサポートしているのは特定のスイッチのみです。お使いのスイッチが LACP に対応していない場合には bond_mode=balance-slb または bond_mode=active-backup を使用してください。

other-config:lacp-fallback-ab=true

フォールバックとして bond_mode=active-backup に切り替わるように LACP の動作を設定します。

other_config:lacp-time=[fast|slow]

LACP のハートビートを 1 秒 (高速) または 30 秒 (低速) に設定します。デフォルトは低速です。

other_config:bond-detect-mode=[miimon|carrier]

リンク検出に miimon ハートビート (miimon) またはモニターキャリア (carrier) を設定します。デフォルトは carrier です。

other_config:bond-miimon-interval=100

miimon を使用する場合には、ハートビートの間隔をミリ秒単位で設定します。

other_config:bond_updelay=1000

フラッピングを防ぐためにアクティブ化してリンクが Up の状態である必要のある時間 (ミリ秒単位)

other_config:bond-rebalance-interval=10000

ボンディングメンバー間のリバランシングフローの間隔 (ミリ秒単位)。ボンディングメンバー間のリバランシングフローを無効にするには、この値をゼロに設定します。

10.5.5. ノード配置の制御

デフォルトでは、director はノードのプロファイルタグに従って、それぞれのロールのノードを無作為に選択します。ただし、特定のノード配置を定義することもできます。これは、以下のシナリオで役に立ちます。

  • 特定のノード ID (例: controller-0controller-1) を割り当てる
  • カスタムのホスト名を割り当てる
  • 特定の IP アドレスを割り当てる
  • 特定の仮想 IP アドレスを割り当てる
注記

予測可能な IP アドレス、仮想 IP アドレス、ネットワークのポートを手動で設定すると、割り当てプールの必要性が軽減されます。ただし、新規ノードがスケーリングされた場合に対応できるように、各ネットワーク用の割り当てプールは維持することを推奨します。定義された固定 IP アドレスは、必ず割り当てプール外となるようにしてください。割り当てプールの設定に関する詳しい情報は、「カスタムネットワーク環境ファイル」を参照してください。

10.5.5.1. 特定のノード ID の割り当て

特定のノードにノード ID を割り当てることができます (例: controller-0controller-1compute-0、および compute-1)。

手順

  1. デプロイメント時に Compute スケジューラーが照合するノード別ケイパビリティーとして、この ID を割り当てます。

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

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

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

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

    以下のパラメーターを使用して、他のロール種別のスケジューラーヒントを設定します。

    • コントローラーノードの場合: ControllerSchedulerHints
    • コンピュートノードの場合: ComputeSchedulerHints
    • Block Storage ノードの場合: BlockStorageSchedulerHints
    • Object Storage ノードの場合: ObjectStorageSchedulerHints
    • Ceph Storage ノードの場合: CephStorageSchedulerHints
    • カスタムロールの場合: [ROLE]SchedulerHints ([ROLE] はロール名に置き換えます)
  3. overcloud deploy コマンドに scheduler_hints_env.yaml 環境ファイルを追加します。
注記

プロファイルの照合よりもノード配置が優先されます。スケジューリングが機能しなくならないように、プロファイル照合用に設計されたフレーバー (computecontrol) ではなく、デプロイメント用のデフォルトの baremetal フレーバーを使用します。環境ファイルで、それぞれのフレーバーパラメーターを baremetal に設定します。

parameter_defaults:
  OvercloudControllerFlavor: baremetal
  OvercloudComputeFlavor: baremetal

10.5.5.2. カスタムのホスト名の割り当て

「特定のノード 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-novacompute-0: overcloud-compute-prod-abc-0

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

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

10.5.5.3. 予測可能な IP の割り当て

作成される環境をより細かく制御するために、director はそれぞれのネットワークにおいてオーバークラウドノードに特定の IP アドレスを割り当てることができます。

手順

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

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

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

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

    • コントローラーノードの場合: ControllerIPs
    • コンピュートノードの場合: ComputeIPs
    • Ceph Storage ノードの場合: CephStorageIPs
    • Block Storage ノードの場合: BlockStorageIPs
    • Object Storage ノードの場合: SwiftStorageIPs
    • カスタムロールの場合: [ROLE]IPs ([ROLE] はロール名に置き換えます)

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

      たとえば、予測可能な IP アドレスを持つ 3 つの Ceph Storage ノードをオーバークラウドにデプロイする場合は、以下の構文例を使用します。

      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 設定と競合しないようにしてください。

      重要

      オーバークラウドノードが削除された場合に、そのノードのエントリーを IP の一覧から削除しないでください。IP の一覧は、下層の heat インデックスをベースとしています。このインデックスは、ノードを削除した場合でも変更されません。IP の一覧で特定のエントリーが使用されなくなったことを示すには、IP の値を DELETED または UNUSED 等に置き換えてください。エントリーは変更または追加するのみとし、IP の一覧から決して削除すべきではありません。

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

    重要

    ネットワーク分離の機能を使用する場合には、network-isolation.yaml ファイルの後に 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]

10.5.5.4. 予測可能な仮想 IP の割り当て

各ノードへの予測可能な 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'}]
      OVNDBsVirtualFixedIPs: [{'ip_address':'172.16.0.7'}]

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

注記

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

10.5.6. オーバークラウドのパブリックエンドポイントでの SSL/TLS の有効化

デフォルトでは、オーバークラウドはオーバークラウドサービスに暗号化されていないエンドポイントを使用します。オーバークラウドで SSL/TLS を有効にするには、SSL/TLS 証明書を設定し、それをオーバークラウドのデプロイメントコマンドに追加する必要があります。

注記

このプロセスで有効になるのは、パブリック API エンドポイント向けの SSL/TLS だけです。Internal API や Admin API は暗号化されません。

前提条件

  • パブリック API のエンドポイントを定義するためのネットワーク分離
  • openssl-perl パッケージがインストールされていること

10.5.6.1. 署名ホストの初期化

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

手順

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

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

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

10.5.6.2. 認証局の作成

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

手順

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

    $ openssl genrsa -out ca.key.pem 4096
    $ openssl req  -key ca.key.pem -new -x509 -days 7300 -extensions v3_ca -out ca.crt.pem
  2. openssl req コマンドは、認証局に関する特定の情報を要求します。要求されたら、それらの情報を入力してください。

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

10.5.6.3. クライアントへの認証局の追加

SSL/TLS を使用して通信する必要のある任意の外部クライアントに、認証局を追加することができます。

手順

  1. Red Hat OpenStack Platform 環境にアクセスする必要のある各クライアントに認証局ファイルをコピーします。

    $ sudo cp ca.crt.pem /etc/pki/ca-trust/source/anchors/
  2. 各クライアントに認証局ファイルをコピーしたら、それぞれのクライアントで以下のコマンドを実行し、証明書を認証局のトラストバンドルに追加します。

    $ sudo update-ca-trust extract

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

10.5.6.4. SSL/TLS 鍵の作成

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

$ openssl genrsa -out server.key.pem 2048

10.5.6.5. SSL/TLS 証明書署名要求の作成

オーバークラウドの証明書署名要求を作成します。

手順

  1. カスタマイズを実施できるように、デフォルトの OpenSSL 設定ファイルをコピーします。

    $ cp /etc/pki/tls/openssl.cnf .
  2. カスタムの 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 つに設定します。

    • SSL/TLS でアクセスするのに IP を使用する場合には、パブリック API に仮想 IP を使用します。この仮想 IP は、環境ファイルで PublicVirtualFixedIPs パラメーターを使用して設定します。詳細は、「予測可能な仮想 IP の割り当て」を参照してください。予測可能な仮想 IP を使用していない場合には、director は ExternalAllocationPools パラメーターで定義する範囲から最初の IP アドレスを割り当てます。
    • SSL/TLS でアクセスするのに完全修飾ドメイン名を使用する場合には、代わりにドメイン名を使用します。

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

  3. 以下のコマンドを実行し、証明書署名要求 (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 証明書を作成します。

10.5.6.6. 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
注記

openssl-perl パッケージがインストールされていない場合、このコマンドの実行に失敗し /etc/pki/CA/newcerts: No such file or directory というエラーメッセージが表示されます。

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

  • v3 拡張機能を指定する設定ファイル。-config オプションを使って設定ファイルを追加します。
  • 認証局を使用して証明書を生成し署名するために「SSL/TLS 証明書署名要求の作成」で設定した証明書署名要求。-in オプションを使って証明書署名要求を追加します。
  • 証明書への署名を行う、「認証局の作成」で作成した認証局。-cert オプションを使って認証局を追加します。
  • 「認証局の作成」で作成した認証局の秘密鍵。-keyfile オプションを使って秘密鍵を追加します。

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

10.5.6.7. SSL/TLS の有効化

手順

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

    $ cp -r /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-tls.yaml ~/templates/.
  2. このファイルを編集して、下記のパラメーターに以下の変更を加えます。

    SSLCertificate

    証明書ファイル (server.crt.pem) の内容を SSLCertificate パラメーターにコピーします。

    parameter_defaults:
      SSLCertificate: |
        -----BEGIN CERTIFICATE-----
        MIIDgzCCAmugAwIBAgIJAKk46qw6ncJaMA0GCSqGS
        ...
        sFW3S2roS4X0Af/kSSD8mlBBTFTCMBAj6rtLBKLaQ
        -----END CERTIFICATE-----
    重要

    この証明書の内容に新しく追加する行は、すべて同じレベルにインデントする必要があります。

    SSLIntermediateCertificate

    中間証明書がある場合、中間証明書のコンテンツを SSLIntermediateCertificate パラメーターにコピーします。

    parameter_defaults:
      SSLIntermediateCertificate: |
        -----BEGIN CERTIFICATE-----
        sFW3S2roS4X0Af/kSSD8mlBBTFTCMBAj6rtLBKLaQbIxEpIzrgvpBCwUAMFgxCzAJB
        ...
        MIIDgzCCAmugAwIBAgIJAKk46qw6ncJaMA0GCSqGSIb3DQE
        -----END CERTIFICATE-----
    重要

    この証明書の内容に新しく追加する行は、すべて同じレベルにインデントする必要があります。

    SSLKey

    秘密鍵 (server.key.pem) の内容を SSLKey パラメーターにコピーします。

    parameter_defaults:
      ...
      SSLKey: |
        -----BEGIN RSA PRIVATE KEY-----
        MIIEowIBAAKCAQEAqVw8lnQ9RbeI1EdLN5PJP0lVO
        ...
        ctlKn3rAAdyumi4JDjESAXHIKFjJNOLrBmpQyES4X
        -----END RSA PRIVATE KEY-----
    重要

    この秘密鍵の内容に新しく追加する行は、すべて同じレベルにインデントする必要があります。

10.5.6.8. ルート証明書の注入

証明書の署名者がオーバークラウドのイメージにあるデフォルトのトラストストアに含まれない場合には、オーバークラウドのイメージに認証局を注入する必要があります。

手順

  1. heat テンプレートコレクションから inject-trust-anchor-hiera.yaml 環境ファイルをコピーします。

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

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

CAMap

オーバークラウドに注入する各認証局 (CA) の内容を一覧にして定義します。オーバークラウドには、アンダークラウドとオーバークラウド両方の証明書を署名するのに使用する CA ファイルが必要です。ルート認証局ファイル (ca.crt.pem) の内容をエントリーにコピーします。CAMap パラメーターの例を以下に示します。

parameter_defaults:
  CAMap:
    ...
    undercloud-ca:
      content: |
        -----BEGIN CERTIFICATE-----
        MIIDlTCCAn2gAwIBAgIJAOnPtx2hHEhrMA0GCS
        BAYTAlVTMQswCQYDVQQIDAJOQzEQMA4GA1UEBw
        UmVkIEhhdDELMAkGA1UECwwCUUUxFDASBgNVBA
        -----END CERTIFICATE-----
    overcloud-ca:
      content: |
        -----BEGIN CERTIFICATE-----
        MIIDBzCCAe+gAwIBAgIJAIc75A7FD++DMA0GCS
        BAMMD3d3dy5leGFtcGxlLmNvbTAeFw0xOTAxMz
        Um54yGCARyp3LpkxvyfMXX1DokpS1uKi7s6CkF
        -----END CERTIFICATE-----
重要

この認証局の内容に新しく追加する行は、すべて同じレベルにインデントする必要があります。

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

10.5.6.9. DNS エンドポイントの設定

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

注記

この環境ファイルが初回のデプロイメントに含まれていない場合は、TLS-everywhere のアーキテクチャーで再デプロイすることはできません。

すべてのフィールドのホスト名およびドメイン名を設定し、必要に応じてカスタムネットワークのパラメーターを追加します。

CloudDomain
ホストの DNS ドメイン
CloudName
オーバークラウドエンドポイントの DNS ホスト名
CloudNameCtlplane
プロビジョニングネットワークエンドポイントの DNS 名
CloudNameInternal
Internal API エンドポイントの DNS 名
CloudNameStorage
ストレージエンドポイントの DNS 名
DnsServers
使用する DNS サーバーの一覧。設定済みの DNS サーバーには、パブリック API の IP アドレスに一致する設定済みの CloudName へのエントリーが含まれていなければなりません。
CloudNameStorageManagement

ストレージ管理エンドポイントの DNS 名

  1. 新規または既存の環境ファイルのいずれかで、パラメーターのデフォルトセクションに使用する DNS サーバーの一覧を追加します。

    parameter_defaults:
      DnsServers: ["10.0.0.254"]
      ....

10.5.6.10. オーバークラウド作成時の環境ファイルの追加

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

  • SSL/TLS を有効化する環境ファイル (enable-tls.yaml)
  • DNS ホスト名を設定する環境ファイル (cloudname.yaml)
  • ルート認証局を注入する環境ファイル (inject-trust-anchor-hiera.yaml)
  • パブリックエンドポイントのマッピングを設定するための環境ファイル:

    • パブリックエンドポイントへのアクセスに DNS 名を使用する場合には、/usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-endpoints-public-dns.yaml を使用します。
    • パブリックエンドポイントへのアクセスに IP アドレスを使用する場合には、/usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-endpoints-public-ip.yaml を使用します。

デプロイメントコマンドの例:

$ 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

10.5.6.11. SSL/TLS 証明書の更新

これ以降、証明書を更新する必要がある場合:

  • enable-tls.yaml ファイルを編集して、SSLCertificateSSLKeySSLIntermediateCertificate のパラメーターを更新してください。
  • 認証局が変更された場合には、inject-trust-anchor-hiera.yaml ファイルを編集して、CAMap パラメーターを更新してください。

新しい証明書の内容が記載されたら、デプロイメントコマンドを再度実行します。

$ 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

10.5.7. Identity Management を使用した内部およびパブリックエンドポイントでの SSL/TLS の有効化

特定のオーバークラウドエンドポイントで SSL/TLS を有効化することができます。多数の証明書数が必要となるため、director は Red Hat Identity Management (IdM) サーバーと統合して認証局として機能し、オーバークラウドの証明書を管理します。このプロセスでは、novajoin を使用してオーバークラウドノードを IdM サーバーに登録します。

OpenStack 全コンポーネントの TLS サポートのステータスを確認するには、「TLS Enablement status matrix」を参照してください。

10.5.7.1. CA へのアンダークラウドの追加

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

手順

  1. アンダークラウドノードで、python3-novajoin パッケージをインストールします。

    $ sudo dnf install python3-novajoin
  2. アンダークラウドノードで novajoin-ipa-setup スクリプトを実行します。値はデプロイメントに応じて調整します。

    $ sudo /usr/libexec/novajoin-ipa-setup \
        --principal admin \
        --password <IdM admin password> \
        --server <IdM server hostname> \
        --realm <overcloud cloud domain (in upper case)> \
        --domain <overcloud cloud domain> \
        --hostname <undercloud hostname> \
        --precreate

    ここで設定したワンタイムパスワード (OTP) を使用して、アンダークラウドを登録します。

10.5.7.2. IdM へのアンダークラウドの追加

アンダークラウドを IdM に登録して novajoin を設定します。undercloud.conf ファイルの [DEFAULT] セクションで、以下の設定を行います。

手順

  1. novajoin サービスを有効にします。

    [DEFAULT]
    enable_novajoin = true
  2. アンダークラウドノードを IdM に登録できるように、ワンタイムパスワード (OTP) を設定します。

    ipa_otp = <otp>
  3. neutron の DHCP サーバーが提供するオーバークラウドのドメイン名が IdM ドメインと一致するようにします。たとえば、小文字の kerberos レルム。

    overcloud_domain_name = <domain>
  4. アンダークラウドに適切なホスト名を設定します。

    undercloud_hostname = <undercloud FQDN>
  5. アンダークラウドのネームサーバーとして IdM を設定します。

    undercloud_nameservers = <IdM IP>
  6. より大規模な環境の場合には、novajoin の接続タイムアウト値を見直します。undercloud.conf ファイルで、undercloud-timeout.yaml という名前の新規ファイルへの参照を追加します。

    hieradata_override = /home/stack/undercloud-timeout.yaml

    undercloud-timeout.yaml に以下のオプションを追加します。タイムアウト値は秒単位で指定することができます (例: 5)。

    nova::api::vendordata_dynamic_connect_timeout: <timeout value>
    nova::api::vendordata_dynamic_read_timeout: <timeout value>
  7. undercloud.conf ファイルを保存します。
  8. アンダークラウドのデプロイコマンドを実行して、既存のアンダークラウドに変更を適用します。

    $ openstack undercloud install

10.5.7.3. オーバークラウド DNS の設定

IdM 環境を自動検出して、登録をより簡単にするには、IdM を DNS サーバーとして使用することができます。

手順

  1. アンダークラウドに接続します。

    $ source ~/stackrc
  2. DNS ネームサーバーとして IdM を使用するようにコントロールプレーンサブネットを設定します。

    $ openstack subnet set ctlplane-subnet --dns-nameserver  <idm_server_address>
  3. IdM サーバーを使用するように環境ファイルの DnsServers パラメーターを設定します。

    parameter_defaults:
      DnsServers: ["<idm_server_address>"]

    このパラメーターは、通常カスタムの network-environment.yaml ファイルで定義されます。

10.5.7.4. novajoin を使用するためのオーバークラウドの設定

手順

  1. IdM 統合を有効化するには、/usr/share/openstack-tripleo-heat-templates/environments/predictable-placement/custom-domain.yaml 環境ファイルのコピーを作成します。

    $ cp /usr/share/openstack-tripleo-heat-templates/environments/predictable-placement/custom-domain.yaml \
      /home/stack/templates/custom-domain.yaml
  2. /home/stack/templates/custom-domain.yaml 環境ファイルを編集して、デプロイメントに適した CloudDomainCloudName* の値を設定します。

    parameter_defaults:
      CloudDomain: lab.local
      CloudName: overcloud.lab.local
      CloudNameInternal: overcloud.internalapi.lab.local
      CloudNameStorage: overcloud.storage.lab.local
      CloudNameStorageManagement: overcloud.storagemgmt.lab.local
      CloudNameCtlplane: overcloud.ctlplane.lab.local
  3. オーバークラウドのデプロイプロセスで以下の環境ファイルを追加します。

    • /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-internal-tls.yaml
    • /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-everywhere-endpoints-dns.yaml
    • /home/stack/templates/custom-domain.yaml

      以下に例を示します。

      openstack overcloud deploy \
        --templates \
         -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-internal-tls.yaml \
         -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-everywhere-endpoints-dns.yaml \
         -e /home/stack/templates/custom-domain.yaml \

      デプロイされたオーバークラウドノードは、自動的に IdM に登録されます。

  4. これで設定されるのは、内部エンドポイント向けの TLS だけです。外部エンドポイントには、/usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-tls.yaml 環境ファイル (カスタムの証明書と鍵を追加するために編集する必要あり) で TLS を追加する通常の方法を使用することができます。

    openstack overcloud deploy \
      --templates \
      -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-internal-tls.yaml \
      -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-everywhere-endpoints-dns.yaml \
      -e /home/stack/templates/custom-domain.yaml \
      -e /home/stack/templates/enable-tls.yaml
  5. また、IdM を使用して公開証明書を発行することもできます。その場合には、/usr/share/openstack-tripleo-heat-templates/environments/services/haproxy-public-tls-certmonger.yaml 環境ファイルを使用する必要があります。

    openstack overcloud deploy \
      --templates \
       -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/enable-internal-tls.yaml \
       -e /usr/share/openstack-tripleo-heat-templates/environments/ssl/tls-everywhere-endpoints-dns.yaml \
       -e /home/stack/templates/custom-domain.yaml \
       -e /usr/share/openstack-tripleo-heat-templates/environments/services/haproxy-public-tls-certmonger.yaml
注記

novajoin を使用して、既存のデプロイメントに TLS everywhere (TLS-e) を実装することができなくなりました。TLS-e を使用して Red Hat OpenStack Platform の既存のデプロイメントを強化する方法は、「「Ansible を使用した TLS-e の実装」」を参照してください。

10.5.8. Ansible を使用した TLS-e の実装

Red Hat では、アンダークラウドおよびオーバークラウドに TLS-e を設定するのに、novajoin を使用するデフォルトの方式よりも、新たな Ansible ベースの tripleo-ipa を使用する方式を推奨しています。以下の手順を使用して、Red Hat OpenStack Platform の新規インストール、または TLS-e の設定が必要な既存のデプロイメントのいずれかに、TLS-e を実装することができます。事前にプロビジョニングされたノードに TLS-e を設定した Red Hat OpenStack Platform をデプロイする場合は、この方式を使用する必要があります。

注記

既存の環境に TLS-e を実装する場合は、引き続き openstack undercloud installopenstack overcloud deploy コマンド等のコマンドを実行する必要があります。これらの手順はべき等性を持ち、更新されたテンプレートおよび設定ファイルと一致するように既存のデプロイメント設定を調整するだけです。

10.5.8.1. アンダークラウドでの TLS-e の設定

前提条件

stack ユーザーの作成など、アンダークラウドの設定手順がすべて完了していること。詳細は、『director のインストールと使用方法』を参照してください。

手順

  1. ホストファイルを設定します。

    アンダークラウドの /etc/resolv.conf に、適切な検索ドメインおよびネームサーバーを設定します。たとえば、デプロイメントドメインが example.com で FreeIPA サーバーのドメインが bigcorp.com の場合、以下の行を /etc/resolv.conf に追加します。

    search example.com bigcorp.com
    nameserver $IDM_SERVER_IP_ADDR
  2. 必要なソフトウェアをインストールします。

    sudo yum install -y python3-ipalib python3-ipaclient krb5-devel
  3. ご自分の環境に固有の値で環境変数をエクスポートします。

    export IPA_DOMAIN=bigcorp.com
    export IPA_REALM=BIGCORP.COM
    export IPA_ADMIN_USER=$IPA_USER
    export IPA_ADMIN_PASSWORD=$IPA_PASSWORD
    export IPA_SERVER_HOSTNAME=ipa.bigcorp.com
    export UNDERCLOUD_FQDN=undercloud.example.com
    export USER=stack
    export CLOUD_DOMAIN=example.com
    注記

    IdM のユーザー認証情報は、新しいホストおよびサービスを追加できる管理ユーザーでなければなりません。

  4. アンダークラウドで undercloud-ipa-install.yaml Ansible Playbook を実行します。

    ansible-playbook \
    --ssh-extra-args "-o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null" \
    /usr/share/ansible/tripleo-playbooks/undercloud-ipa-install.yaml
  5. undercloud.conf に以下のパラメーターを追加します。

    undercloud_nameservers = $IDM_SERVER_IP_ADDR
    overcloud_domain_name = example.com
  6. アンダークラウドをデプロイします。

    openstack undercloud install

検証

以下の手順を実施して、アンダークラウドが正しく登録されたことを確認します。

  1. IdM のホストを一覧表示します。

    $ kinit admin
    $ ipa host-find
  2. アンダークラウドに /etc/novajoin/krb5.keytab が存在することを確認します。

    ls /etc/novajoin/krb5.keytab
注記

novajoin というディレクトリー名は、従来の方式に対応させる目的でのみ使用されています。

10.5.8.2. オーバークラウドでの TLS-e の設定

TLS everywhere (TLS-e) を設定したオーバークラウドをデプロイする場合、アンダークラウドおよびオーバークラウドの IP アドレスは自動的に IdM に登録されます。

注記

IP アドレスの自動登録を無効にするには、IDMModifyDNS heat パラメーターを false に設定します。

parameter_defaults:
    ....
    IdMModifyDNS: false
  1. オーバークラウドをデプロイする前に、以下のような内容で YAML ファイル tls-parameters.yaml を作成します。お使いの環境に固有の値を選択してください。

    • DnsServers パラメーターの値は、IdM サーバーの IP アドレスを反映させる必要があります。
    • IdM サーバーのドメインがクラウドのドメインと異なる場合は、DnsSearchDomains パラメーターに追加します。たとえば、DnsSearchDomains: ["example.com", "bigcorp.com"] のように設定します。
    • 事前にプロビジョニングされたノードが無い限り、IDMInstallClientPackages パラメーターの値を false に設定する必要があります。
    • OS::TripleO::Services::IpaClient パラメータに示す値は、enable-internal-tls.yaml ファイルのデフォルト設定を上書きします。openstack overcloud deploy コマンドで、enable-internal-tls.yaml の後に tls-parameters.yaml ファイルを指定するようにします。
    • アクティブ/アクティブとして設定された cinder と共に分散コンピュートノード (DCN) アーキテクチャーを実行している場合は、EnableEtcdInternalTLS パラメーターを追加して true に設定する必要があります。

      parameter_defaults:
          DnsSearchDomains: ["example.com"]
          DnsServers: ["192.168.1.13"]
          CloudDomain: example.com
          CloudName: overcloud.example.com
          CloudNameInternal: overcloud.internalapi.example.com
          CloudNameStorage: overcloud.storage.example.com
          CloudNameStorageManagement: overcloud.storagemgmt.example.com
          CloudNameCtlplane: overcloud.ctlplane.example.com
          IdMServer: freeipa-0.redhat.local
          IdMDomain: redhat.local
          IdMInstallClientPackages: False
      
      resource_registry:
            OS::TripleO::Services::IpaClient: /usr/share/openstack-tripleo-heat-templates/deployment/ipa/ipaservices-baremetal-ansible.yaml
  2. オーバークラウドをデプロイします。デプロイメントコマンドに tls-parameters.yaml を追加する必要があります。

    DEFAULT_TEMPLATES=/usr/share/openstack-tripleo-heat-templates/
    CUSTOM_TEMPLATES=/home/stack/templates
    
    openstack overcloud deploy \
    -e ${DEFAULT_TEMPLATES}/environments/ssl/tls-everywhere-endpoints-dns.yaml \
    -e ${DEFAULT_TEMPLATES}/environments/services/haproxy-public-tls-certmonger.yaml \
    -e ${DEFAULT_TEMPLATES}/environments/ssl/enable-internal-tls.yaml \
    -e ${CUSTOM_TEMPLATES}/tls-parameters.yaml \
    ...
  3. keystone にエンドポイント一覧のクエリーを行い、各エンドポイントが HTTPS を使用していることを確認します。

    openstack overcloud endpoint list

10.5.9. デバッグモード

オーバークラウド内の特定のサービスに DEBUG レベルロギングモードを有効化または無効化することができます。

サービスのデバッグモードを設定するには、それぞれのデバッグパラメーターを設定します。たとえば、OpenStack Identity (keystone) は KeystoneDebug パラメーターを使用します。

  • 環境ファイルの parameter_defaults セクションでパラメーターを設定します。

    parameter_defaults:
      KeystoneDebug: True

KeystoneDebug パラメーターを True に設定すると、標準の keystone ログファイル /var/log/containers/keystone/keystone.logDEBUG レベルのログで更新されます。

デバッグパラメーターの全一覧は、『オーバークラウドのパラメーター』「デバッグパラメーター」を参照してください。

10.5.10. ポリシー

オーバークラウド内の特定のサービスに対してアクセスポリシーを設定することができます。サービスに対してポリシーを設定するには、そのサービスのポリシーが含まれるハッシュ値でそれぞれのポリシーのパラメーターを設定します。

  • OpenStack Identity (keystone) には KeystonePolicies パラメーターを使用します。このパラメーターを環境ファイルの parameter_defaults セクションで設定します。

    parameter_defaults:
      KeystonePolicies: { keystone-context_is_admin: { key: context_is_admin, value: 'role:admin' } }
  • OpenStack Compute (nova) には NovaApiPolicies パラメーターを使用します。このパラメーターを環境ファイルの parameter_defaults セクションで設定します。

    parameter_defaults:
      NovaApiPolicies: { nova-context_is_admin: { key: 'compute:get_all', value: '@' } }

ポリシーパラメーターの全一覧は、『オーバークラウドのパラメーター』「ポリシーパラメーター」を参照してください。

10.5.11. ストレージの設定

本章では、オーバークラウドのストレージオプションを設定するためのさまざまな方法について説明します。

重要

オーバークラウドは、デフォルトのストレージオプションにローカルおよび LVM のストレージを使用します。これらのオプションはエンタープライズレベルのオーバークラウドではサポートされないので、本章で説明するストレージオプションの 1 つを使用するようにオーバークラウドを設定する必要があります。

10.5.11.1. NFS ストレージの設定

NFS 共有を使用するようにオーバークラウドを設定するには、コア heat テンプレートコレクションの既存の環境ファイルを変更する必要があります。

重要

Red Hat では、認定済みのストレージバックエンドおよびドライバーを使用することを推奨します。Red Hat では、汎用 NFS バックエンドの NFS を使用することを推奨していません。認定済みのストレージバックエンドおよびドライバーと比較すると、その機能に制限があるためです。たとえば、汎用 NFS バックエンドは、ボリュームの暗号化やボリュームのマルチアタッチなどの機能をサポートしません。サポート対象のドライバーについての情報は、Red Hat Ecosystem Catalog を参照してください。

注記

director のさまざまな heat パラメーターにより、NFS バックエンドまたは NetApp NFS Block Storage バックエンドが NetApp 機能 (NAS secure と呼ばれる) をサポートするかどうかが制御されます。

  • CinderNetappNasSecureFileOperations
  • CinderNetappNasSecureFilePermissions
  • CinderNasSecureFileOperations
  • CinderNasSecureFilePermissions

通常のボリューム操作に干渉するため、Red Hat では、この機能を有効にすることを推奨していません。director はデフォルトでこの機能を無効にするため、Red Hat OpenStack Platform はこの機能をサポートしません。

注記

Block Storage (cinder) サービスおよび Compute (nova) サービスには、NFS バージョン 4.0 以降を使用する必要があります。

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

手順

  1. ファイルを stack ユーザーのホームディレクトリーにあるテンプレートディレクトリーにコピーします。

    $ cp /usr/share/openstack-tripleo-heat-templates/environments/storage-environment.yaml ~/templates/.
  2. 以下のパラメーターを変更してください。

    CinderEnableIscsiBackend
    iSCSI バックエンドを有効にするパラメーター。この値を false に設定します。
    CinderEnableRbdBackend
    Ceph Storage バックエンドを有効にするパラメーター。この値を false に設定します。
    CinderEnableNfsBackend
    NFS バックエンドを有効にするパラメーター。この値を true に設定します。
    NovaEnableRbdBackend
    Nova エフェメラルストレージ用に Ceph Storage を有効にするパラメーター。この値を false に設定します。
    GlanceBackend
    Image サービスに使用するバックエンドを定義するパラメーター。イメージ用にファイルベースのストレージを使用するには、この値を file に設定します。オーバークラウドは、Image サービス (glance) 用にマウントされた NFS 共有にこれらのファイルを保存します。
    CinderNfsMountOptions
    ボリュームストレージ用の NFS マウントオプション
    CinderNfsServers
    ボリュームストレージ用にマウントする NFS 共有。たとえば、192.168.122.1:/export/cinder と設定します。
    GlanceNfsEnabled
    GlanceBackendfile に設定した場合、GlanceNfsEnabled パラメーターを使用して、イメージが NFS 経由で共有の場所に保管されるのを有効にします。これにより、すべてのコントローラーノードがイメージにアクセスすることができます。GlanceNfsEnabled パラメーターを false に設定すると、オーバークラウドはイメージをコントローラーノードのファイルシステムに保管します。この値を true に設定します。
    GlanceNfsShare
    イメージストレージ用にマウントする NFS 共有。たとえば、192.168.122.1:/export/glance と設定します。
    GlanceNfsOptions
    イメージストレージ用の NFS マウントオプション

    storage-environment.yaml 環境ファイルには、Red Hat OpenStack Platform (RHOSP) の Block Storage (cinder) サービスおよび Image (glance) サービス用に、さまざまなストレージオプションを設定するためのパラメーターが含まれます。以下の例で、オーバークラウドが NFS 共有を使用するように設定する方法を説明します。

    parameter_defaults:
      CinderEnableIscsiBackend: false
      CinderEnableRbdBackend: false
      CinderEnableNfsBackend: true
      NovaEnableRbdBackend: false
      GlanceBackend: file
    
      CinderNfsServers: 192.0.2.230:/cinder
    
      GlanceNfsEnabled: true
      GlanceNfsShare: 192.0.2.230:/glance

    これらのパラメーターは、heat テンプレートコレクションの一部として統合されます。この例を使用して、使用する Block Storage サービスおよび Image サービス用に NFS マウントポイントを 2 つ作成します。

    重要

    Image サービスが /var/lib ディレクトリーにアクセスできるようにするには、GlanceNfsOptions パラメーターに _netdev,bg,intr,context=system_u:object_r:container_file_t:s0 オプションを追加します。この SELinux コンテンツを設定しないと、Image サービスはマウントポイントに書き込みを行うことができません。同じ NFS サーバーを共有するように複数のサービスを設定する際に問題が発生した場合は、Red Hat サポートにお問い合わせください。

  3. オーバークラウドをデプロイする際に、storage-environment.yaml 環境ファイルを追加します。

10.5.11.2. Ceph Storage の設定

以下のいずれかの方法を使用して、Red Hat Ceph Storage を Red Hat OpenStack Platform のオーバークラウドに統合します。

固有の Ceph Storage Cluster を持つオーバークラウドの作成
オーバークラウドの作成中に Ceph Storage クラスターを作成することができます。director は、データの格納に Ceph OSD を使用する Ceph Storage ノードのセットを作成します。director は、オーバークラウドのコントローラーノードに Ceph Monitor サービスもインストールします。このため、組織が 3 台の高可用性コントローラーノードで構成されるオーバークラウドを作成する場合には、Ceph Monitor も高可用性サービスになります。詳しい情報は、『コンテナー化された Red Hat Ceph を持つオーバークラウドのデプロイ』を参照してください。
既存 Ceph Storage クラスターのオーバークラウドへの統合
既存の Ceph Storage クラスターがある場合には、デプロイメント中にこのクラスターを Red Hat OpenStack Platform のオーバークラウドに統合することができます。これは、オーバークラウドの設定とは独立して、クラスターの管理やスケーリングが可能であることを意味します。詳しい情報は、『オーバークラウドの既存 Red Hat Ceph クラスターとの統合』を参照してください。

10.5.11.3. 外部の Object Storage クラスターの使用

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

注記

外部 Object Storage (swift) クラスター上のユーザーアカウントを手動で管理する必要があります。

前提条件

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

手順

  1. 以下の内容を記載した swift-external-params.yaml という名前の新しいファイルを作成します。

    • EXTERNAL.IP:PORT は、外部プロキシーの IP アドレスとポートに置き換えます。
    • SwiftPassword の行の AUTHTOKEN は、外部プロキシーの authtoken パスワードに置き換えます。

      parameter_defaults:
        ExternalPublicUrl: 'https://EXTERNAL.IP:PORT/v1/AUTH_%(tenant_id)s'
        ExternalInternalUrl: 'http://192.168.24.9:8080/v1/AUTH_%(tenant_id)s'
        ExternalAdminUrl: 'http://192.168.24.9:8080'
        ExternalSwiftUserTenant: 'service'
        SwiftPassword: AUTHTOKEN
  2. このファイルを swift-external-params.yaml として保存します。
  3. デプロイメントに該当するその他の環境ファイルと共に、以下の外部 Object Storage サービスの環境ファイルを指定して、オーバークラウドをデプロイします。

    openstack overcloud deploy --templates \
    -e [your environment files] \
    -e /usr/share/openstack-tripleo-heat-templates/environments/swift-external.yaml \
    -e swift-external-params.yaml

10.5.11.4. 外部の Ceph Object Gateway を使用するための Ceph Object Store の設定

Red Hat OpenStack Platform (RHOSP) director は、外部の Ceph Object Gateway (RGW) を Object Store サービスとして設定することをサポートしています。外部 RGW サービスで認証するには、Identity サービス (keystone) のユーザーとそのロールを確認するように RGW を設定する必要があります。

外部 Ceph Object Gateway の設定方法に関する詳細は、『Ceph Object Gateway ガイドでの Keystone の使用』「Keystone 認証を使用するように Ceph Object Gateway を設定」を参照してください。

手順

  1. カスタム環境ファイル (swift-external-params.yaml 等) に以下の parameter_defaults を追加し、実際のデプロイメントに合わせて値を調整します。

    parameter_defaults:
       ExternalSwiftPublicUrl: 'http://<Public RGW endpoint or loadbalancer>:8080/swift/v1/AUTH_%(project_id)s'
       ExternalSwiftInternalUrl: 'http://<Internal RGW endpoint>:8080/swift/v1/AUTH_%(project_id)s'
       ExternalSwiftAdminUrl: 'http://<Admin RGW endpoint>:8080/swift/v1/AUTH_%(project_id)s'
       ExternalSwiftUserTenant: 'service'
       SwiftPassword: 'choose_a_random_password'
    注記

    サンプルコードスニペットには、お使いの環境で使用する値とは異なるパラメーター値が含まれる場合があります。

    • リモート RGW インスタンスがリッスンするデフォルトのポートは 8080 です。外部 RGW の設定方法によっては、ポートが異なる場合があります。
    • オーバークラウドで作成した swift ユーザーは、SwiftPassword パラメーターで定義したパスワードを使用します。rgw_keystone_admin_password を使用し、Identity サービスに対する認証に同じパスワードを使用するように外部 RGW インスタンスを設定する必要があります。
  2. Ceph 設定ファイルに以下のコードを追加して、Identity サービスを使用するように RGW を設定します。変数の値を実際の環境に応じて調整します。

        rgw_keystone_api_version: 3
        rgw_keystone_url: http://<public Keystone endpoint>:5000/
        rgw_keystone_accepted_roles: 'member, Member, admin'
        rgw_keystone_accepted_admin_roles: ResellerAdmin, swiftoperator
        rgw_keystone_admin_domain: default
        rgw_keystone_admin_project: service
        rgw_keystone_admin_user: swift
        rgw_keystone_admin_password: <Password as defined in the environment parameters>
        rgw_keystone_implicit_tenants: 'true'
        rgw_keystone_revocation_interval: '0'
        rgw_s3_auth_use_keystone: 'true'
        rgw_swift_versioning_enabled: 'true'
        rgw_swift_account_in_url: 'true'
    注記

    デフォルトでは、director は Identity サービスに以下のロールとユーザーを作成します。

    • rgw_keystone_accepted_admin_roles: ResellerAdmin, swiftoperator
    • rgw_keystone_admin_domain: default
    • rgw_keystone_admin_project: service
    • rgw_keystone_admin_user: swift
  3. 追加の環境ファイルを指定してオーバークラウドをデプロイします。

    openstack overcloud deploy --templates \
    -e <your environment files>
    -e /usr/share/openstack-tripleo-heat-templates/environments/swift-external.yaml
    -e swift-external-params.yaml

10.5.11.5. イメージのインポート法および共有ステージングエリアの設定

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

以下の方法でイメージをインポートすることができます。

web-download
web-download メソッドを使用して、URL からイメージをインポートする。
glance-direct
glance-direct メソッドを使用して、ローカルボリュームからイメージをインポートする。
10.5.11.5.1. glance-settings.yaml ファイルの作成およびデプロイメント

カスタム環境ファイルを使用して、インポートパラメーターを設定します。これらのパラメーターは、コア heat テンプレートコレクションのデフォルト値を上書きします。以下の環境コンテンツは、相互運用可能なイメージのインポート用パラメーターの例です。

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

GlanceBackendGlanceNfsEnabled、および GlanceNfsShare パラメーターについては、『オーバークラウドの高度なカスタマイズ』「ストレージの設定」の章に説明があります。

相互運用可能なイメージのインポートに関する 2 つの新たなパラメーターを使用して、インポート法および共有 FNS ステージングエリアを定義します。

GlanceEnabledImportMethods
利用可能なインポート法として web-download (デフォルト) および glance-direct を定義します。このパラメーターが必要になるのは、web-download に加えて別の方法を有効にする場合に限ります。
GlanceStagingNfsShare
glance-direct インポート法で使用する NFS ステージングエリアを設定します。この領域は、高可用性クラスター設定のノード間で共有することができます。このパラメーターを使用する場合は、GlanceNfsEnabled パラメーターを true に設定する必要もあります。

手順

  1. 新規ファイルを作成します (例: glance-settings.yaml)。サンプルの構文を使用して、このファイルを設定します。
  2. デプロイメントに該当するその他の環境ファイルと共に、glance-settings.yaml ファイルを openstack overcloud deploy コマンドに追加します。

    $ openstack overcloud deploy --templates -e glance-settings.yaml

環境ファイルの使用に関する詳細については、『オーバークラウドの高度なカスタマイズ』「オーバークラウド作成時の環境ファイルの追加」セクションを参照してください。

10.5.11.5.2. イメージの Web インポートソースの制御

Web インポートによるイメージダウンロードのソースを制限することができます。そのためには、オプションの glance-image-import.conf ファイルに URI のブラックリストおよびホワイトリストを追加します。

3 段階のレベルで、イメージソースの URI をホワイトリスト登録またはブラックリスト登録することができます。

  • スキームレベル (allowed_schemes、disallowed_schemes)
  • ホストレベル (allowed_hosts、disallowed_hosts)
  • ポートレベル (allowed_ports、disallowed_ports)

レベルにかかわらず、ホワイトリストとブラックリストの両方を指定した場合には、ホワイトリストが優先されブラックリストは無視されます。

Image サービスは、以下の判断ロジックを使用してイメージソースの URI を検証します。

  1. スキームを確認する。

    1. スキームが定義されていない場合: 拒否する。
    2. ホワイトリストがあり、そのスキームがホワイトリストに記載されていない場合: 拒否する。記載されている場合: c 項をスキップして 2 項に進む。
    3. ブラックリストがあり、そのスキームがブラックリストに記載されている場合: 拒否する。
  2. ホスト名を確認する。

    1. ホスト名が定義されていない場合: 拒否する。
    2. ホワイトリストがあり、そのホスト名がホワイトリストに記載されていない場合: 拒否する。記載されている場合: c 項をスキップして 3 項に進む。
    3. ブラックリストがあり、そのホスト名がブラックリストに記載されている場合: 拒否する。
  3. URI にポートが含まれていれば、ポートを確認する。

    1. ホワイトリストがあり、そのポートがホワイトリストに記載されていない場合: 拒否する。記載されている場合: b 項をスキップして 4 項に進む。
    2. ブラックリストがあり、そのポートがブラックリストに記載されている場合: 拒否する。
  4. 有効な URI として受け入れる。

(ホワイトリストに登録する、あるいはブラックリストに登録しないことにより) スキームを許可した場合には、URI にポートを含めないことでそのスキームのデフォルトポートを使用する URI は、すべて許可されます。URI にポートが含まれている場合には、URI はデフォルトの判断ロジックに従って検証されます。

10.5.11.5.2.1. 例

たとえば、FTP のデフォルトポートは 21 です。ftp はホワイトリストに登録されたスキームなので、URL ftp://example.org/some/resource は許可されます。しかし、21 はポートのホワイトリストに含まれていないので、同じリソースへの URL であっても ftp://example.org:21/some/resource は拒否されます。

allowed_schemes = [http,https,ftp]
disallowed_schemes = []
allowed_hosts = []
disallowed_hosts = []
allowed_ports = [80,443]
disallowed_ports = []
10.5.11.5.2.2. イメージのインポートに関するブラックリストおよびホワイトリストのデフォルト設定

glance-image-import.conf ファイルは、以下のデフォルトオプションが含まれるオプションのファイルです。

  • allowed_schemes: [http, https]
  • disallowed_schemes: ブランク
  • allowed_hosts: ブランク
  • disallowed_hosts: ブランク
  • allowed_ports: [80, 443]
  • disallowed_ports: ブランク

デフォルトの設定を使用する場合、エンドユーザーは http または https スキームを使用する URI にしかアクセスすることができません。ユーザーが指定することのできるポートは、80 および 443 だけです。ユーザーはポートを指定する必要はありませんが、指定する場合には 80 または 443 のどちらかでなければなりません。

glance-image-import.conf ファイルは、Image サービスのソースコードツリーの etc/ サブディレクトリーにあります。お使いの Red Hat OpenStack Platform のリリースに対応する正しいブランチを使用してください。

10.5.11.5.3. イメージインポート時のメタデータ注入による仮想マシン起動場所の制御

エンドユーザーは Image サービスにイメージをアップロードし、それらのイメージを使用して仮想マシンを起動することができます。これらのユーザーの提供する (非管理者) イメージは、特定のコンピュートノードセットで起動する必要があります。インスタンスのコンピュートノードへの割り当ては、イメージメタデータ属性で制御されます。

Image Property Injection プラグインにより、メタデータ属性がインポート時にイメージに注入されます。属性を指定するには、glance-image-import.conf ファイルの [image_import_opts] および [inject_metadata_properties] セクションを編集します。

Image Property Injection プラグインを有効にするには、以下の行を [image_import_opts] セクションに追加します。

[image_import_opts]
image_import_plugins = [inject_image_metadata]

メタデータの注入を特定ユーザーが提供したイメージに制限するには、ignore_user_roles パラメーターを設定します。たとえば、property1 に関する 1 つの値および property2 に関する 2 つの値を任意の非管理者ユーザーがダウンロードしたイメージに注入するには、以下の設定を使用します。

[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

パラメーター ignore_user_roles は、プラグインが無視する Keystone ロールのコンマ区切りリストです。つまり、イメージインポートの呼び出しを行うユーザーにこれらのロールが設定されている場合、プラグインはイメージに属性を注入しません。

パラメーター inject は、インポートされたイメージのイメージレコードに注入される属性と値のコンマ区切りリストです。それぞれの属性と値は、コロン (「:」) で区切る必要があります。

glance-image-import.conf ファイルは、Image サービスのソースコードツリーの etc/ サブディレクトリーにあります。お使いの Red Hat OpenStack Platform のリリースに対応する正しいブランチを使用してください。

10.5.11.6. Image サービス用 cinder バックエンドの設定

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

重要

デフォルトでは、1 つのプロジェクトで作成可能な最大のボリューム数は 10 です。

手順

  1. Image サービスのバックエンドに cinder を設定するには、以下の行を環境ファイルに追加します。

    parameter_defaults:
      GlanceBackend: cinder
  2. cinder バックエンドが有効な場合には、デフォルトで以下のパラメーターおよび値が設定されます。

    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****
  3. cinder_store_ パラメーターにカスタムのユーザー名またはその他のカスタムの値を使用するには、parameter_defaultsExtraConfig パラメーターを追加してカスタムの値を指定します。

    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')}"

10.5.11.7. 1 つのインスタンスにアタッチすることのできる最大ストレージデバイス数の設定

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

ガイドラインおよび留意事項

  • インスタンスがサポートするストレージディスクの数は、ディスクが使用するバスにより異なります。たとえば、IDE ディスクバスでは、アタッチされるデバイスは 4 つに制限されます。
  • アクティブなインスタンスを持つコンピュートノードで max_disk_devices_to_attach を変更した場合に、最大数がインスタンスにすでにアタッチされているデバイスの数より小さいと、再ビルドが失敗する可能性があります。たとえば、インスタンス A に 26 のデバイスがアタッチされている場合に、max_disk_devices_to_attach を 20 に変更すると、インスタンス A を再ビルドする要求は失敗します。
  • コールドマイグレーション時には、設定されたストレージデバイスの最大数は、移行する元のインスタンスにのみ適用されます。移動前に移行先が確認されることはありません。つまり、コンピュートノード A に 26 のディスクデバイスがアタッチされていて、コンピュートノード B の最大ディスクデバイスアタッチ数が 20 に設定されている場合に、26 のデバイスがアタッチされたインスタンスをコンピュートノード A からコンピュートノード B に移行するコールドマイグレーションの操作は成功します。ただし、これ以降、コンピュートノード B でインスタンスを再ビルドする要求は失敗します。すでにアタッチされているデバイスの数 26 が、設定された最大値の 20 を超えているためです。
  • 設定された最大値は、退避オフロード中のインスタンスには適用されません。これらのインスタンスはコンピュートノードを持たないためです。
  • 多数のディスクデバイスをインスタンスにアタッチすると、インスタンスのパフォーマンスが低下する可能性があります。お使いの環境がサポートすることのできる限度に基づいて、最大数を調整します。
  • マシン種別 が Q35 のインスタンスは、最大で 500 のディスクデバイスをアタッチすることができます。

10.5.11.8. Image サービスのキャッシュ機能を使用したスケーラビリティーの向上

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

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

手順

  1. 環境ファイルの GlanceCacheEnabled パラメーターの値を true に設定します。これにより、glance-api.conf heat テンプレートの flavor の値が自動的に keystone+cachemanagement に設定されます。

    parameter_defaults:
        GlanceCacheEnabled: true
  2. オーバークラウドを再デプロイする際に、openstack overcloud deploy コマンドにその環境ファイルを追加します。
  3. オプション: オーバークラウドを再デプロイする際に、glance_cache_pruner を異なる頻度に調節します。5 分間の頻度の例を以下に示します。

    parameter_defaults:
      ControllerExtraConfig:
        glance::cache::pruner::minute: '*/5'

    ファイルシステムを使い果たす状況を回避するために、ご自分のニーズに合わせて頻度を調節します。異なる頻度を選択する場合は、以下の要素を考慮に入れます。

    • 実際の環境でキャッシュするファイルのサイズ
    • 利用可能なファイルシステムの容量
    • 環境がイメージをキャッシュする頻度

10.5.11.9. サードパーティーのストレージの設定

以下の環境ファイルは、コア heat テンプレートコレクション /usr/share/openstack-tripleo-heat-templates にあります。

Dell EMC Storage Center

Block Storage (cinder) サービス用に単一の Dell EMC Storage Center バックエンドをデプロイします。

環境ファイルは /usr/share/openstack-tripleo-heat-templates/environments/cinder-dellsc-config.yaml にあります。

設定に関する詳しい情報は、『Dell Storage Center Back End Guide』を参照してください。

Dell EMC PS Series

Block Storage (cinder) サービス用に単一の Dell EMC PS Series バックエンドをデプロイします。

環境ファイルは /usr/share/openstack-tripleo-heat-templates/environments/cinder-dellps-config.yaml にあります。

設定に関する詳しい情報は、『Dell EMC PS Series Back End Guide』を参照してください。

NetApp ブロックストレージ

Block Storage (cinder) サービス用に NetApp ストレージアプライアンスをバックエンドとしてデプロイします。

環境ファイルは /usr/share/openstack-tripleo-heat-templates/environments/storage/cinder-netapp-config.yaml にあります。

NetApp Block Storage についての詳しい情報は、NetApp の Block Storage Service (Cinder) に関するドキュメントを参照してください。

10.5.12. セキュリティーの強化

以下の項では、オーバークラウドのセキュリティーを強化するための推奨事項について説明します。

10.5.12.1. オーバークラウドのファイアウォールの管理

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

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

ManageFirewall
ファイアウォールルールを自動管理するかどうかを定義します。このパラメーターを true に設定すると、Puppet は各ノードでファイアウォールを自動的に設定することができます。ファイアウォールを手動で管理する場合には false に設定してください。デフォルトは true です。
PurgeFirewallRules
ファイアウォールルールを新規設定する前に、デフォルトの Linux ファイアウォールルールを完全削除するかどうかを定義します。デフォルトは false です。

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

port
ルールに関連付けられたポート
dport
ルールに関連付けられた宛先ポート
sport
ルールに関連付けられた送信元ポート
proto
ルールに関連付けられたプロトコル。デフォルトは tcp です。
action
ルールに関連付けられたアクションポリシー。デフォルトは accept です。
jump
ジャンプ先のチェーン。設定されている場合には action を上書きします。
state
ルールに関連付けられた状態の配列。デフォルトは ['NEW'] です。
source
ルールに関連付けられた送信元の IP アドレス
iniface
ルールに関連付けられたネットワークインターフェース
chain
ルールに関連付けられたチェーン。デフォルトは INPUT です。
destination
ルールに関連付けられた宛先の CIDR

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

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 つのファイアウォールルールが 全ノードに適用されます。

注記

各ルール名はそれぞれの iptables ルールのコメントになります。各ルール名は 3 桁のプレフィックスで始まり、Puppet が最終の iptables ファイルで定義済みの全ルールの順序を設定するのに役立ちます。デフォルトの Red Hat OpenStack Platform ルールでは、000 から 200 までの範囲のプレフィックスを使用します。

10.5.12.2. Simple Network Management Protocol (SNMP) 文字列の変更

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

注記

文字列パラメーターを使用して ExtraConfig インターフェースを設定する場合には、heat および Hiera が文字列をブール値と解釈しないように、'"<VALUE>"' の構文を使用する必要があります。

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

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

snmp::ro_community
IPv4 の読み取り専用 SNMP コミュニティー文字列。デフォルト値は public です。
snmp::ro_community6
IPv6 の読み取り専用 SNMP コミュニティー文字列。デフォルト値は public です。
snmp::ro_network
デーモンへの RO クエリー が許可されるネットワーク。この値は文字列または配列のいずれかです。デフォルト値は 127.0.0.1 です。
snmp::ro_network6
デーモンへの IPv6 RO クエリー が許可されるネットワーク。この値は文字列または配列のいずれかです。デフォルト値は ::1/128 です。
tripleo::profile::base::snmp::snmpd_config
安全弁として snmpd.conf ファイルに追加する行の配列。デフォルト値は [] です。利用できるすべてのオプションについては、SNMP 設定ファイル に関する Web ページを参照してください。

以下に例を示します。

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

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

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

snmp::com2sec
IPv4 セキュリティー名
snmp::com2sec6
IPv6 セキュリティー名

以下に例を示します。

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

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

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

10.5.12.3. HAProxy の SSL/TLS の暗号およびルールの変更

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

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

tripleo::haproxy::ssl_cipher_suite
HAProxy で使用する暗号スイート
tripleo::haproxy::ssl_options
HAProxy で使用する SSL/TLS ルール

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

  • 暗号: 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
  • ルール: no-sslv3 no-tls-tickets

環境ファイルを作成して、以下の内容を記載します。

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
注記

暗号のコレクションは、改行せずに 1 行に記述します。

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

10.5.12.4. Open vSwitch ファイアウォールの使用

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

  • iptables_hybrid: Networking サービス (neutron) が iptables/ハイブリッドベースの実装を使用するように設定します。
  • openvswitch: Networking サービスが OVS ファイアウォールのフローベースのドライバーを使用するように設定します。

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

重要

Open vSwitch (OVS) ファイアウォールドライバーによるマルチキャストトラフィックの処理は、iptables ファイアウォールドライバーの場合とは異なります。iptables の場合、デフォルトでは VRRP トラフィックは拒否されます。したがって、VRRP トラフィックがエンドポイントに到達できるようにするには、セキュリティーグループルールで VRRP を有効にする必要があります。OVS の場合、すべてのポートが同じ OpenFlow コンテキストを共有し、ポートごとに個別にマルチキャストトラフィックを処理することはできません。セキュリティーグループはすべてのポート (ルーター上のポートなど) には適用されないため、OVS は RFC 4541 の定義に従って NORMAL アクションを使用してマルチキャストトラフィックを全ポートに転送します。

注記

iptables_hybrid オプションには、OVS-DPDK との互換性はありません。openvswitch オプションには、OVS ハードウェアオフロードとの互換性はありません。

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

NeutronOVSFirewallDriver: openvswitch
  • NeutronOVSFirewallDriver: セキュリティーグループを実装する時に使用するファイアウォールドライバーの名前を設定します。設定可能な値は、お使いのシステム構成により異なります。例としては、noopopenvswitch、および iptables_hybrid 等が挙げられます。デフォルト値である空の文字列を指定すると、サポートされている構成となります。

10.5.12.5. セキュアな root ユーザーアクセスの使用

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

  1. アンダークラウドノードに stack ユーザーとしてログインします。
  2. 各オーバークラウドノードには heat-admin ユーザーアカウントがあります。このユーザーアカウントにはアンダークラウドのパブリック SSH 鍵が含まれており、アンダークラウドからオーバークラウドノードへのパスワード無しの SSH アクセスが可能です。アンダークラウドノードで、heat-admin ユーザーとして SSH 経由でオーバークラウドノードにログインします。
  3. sudo -iroot ユーザーに切り替えます。

root ユーザーのセキュリティーレベルの引き下げ

状況によっては、root ユーザーへの直接 SSH アクセスが必要な場合があります。このような場合には、各オーバークラウドノードで root ユーザーの SSH 制限を引き下げることができます。

警告

この方法は、デバッグのみを目的としています。したがって、実稼働環境での使用は推奨されません。

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

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

parameter_defaults:
  NodeRootPassword: "p@55w0rd!"

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

  • OS::TripleO::NodeUserData リソースは、初回ブートの cloud-init 段階に root ユーザーを設定するテンプレートを参照します。
  • NodeRootPassword パラメーターは root ユーザーのパスワードを設定します。このパラメーターの値は、任意の値に変更してください。環境ファイルにはパスワードがプレーンテキスト形式の文字列として記載されるので、セキュリティーリスクと見なされます。

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

10.5.13. モニタリングツールの設定

モニタリングツールは、可用性のモニタリングと集中ロギングに使用できるオプションのツールスイートです。可用性のモニタリングを使用して全コンポーネントの機能を監視し、集中ロギングを使用して Red Hat OpenStack Platform 環境全体のすべてのログを一箇所で確認します。

モニタリングツールの設定に関する詳しい情報は、『監視ツール設定ガイド』を参照してください。

10.5.14. ネットワークプラグインの設定

director には、サードパーティーのネットワークプラグインを設定する際に使用できる環境ファイルが含まれています。

10.5.14.1. Fujitsu Converged Fabric (C-Fabric)

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

  1. 環境ファイルを templates サブディレクトリーにコピーします。

    $ cp /usr/share/openstack-tripleo-heat-templates/environments/neutron-ml2-fujitsu-cfab.yaml /home/stack/templates/
  2. resource_registry で絶対パスを使用するように編集します。

    resource_registry:
      OS::TripleO::Services::NeutronML2FujitsuCfab: /usr/share/openstack-tripleo-heat-templates/puppet/services/neutron-plugin-ml2-fujitsu-cfab.yaml
  3. /home/stack/templates/neutron-ml2-fujitsu-cfab.yamlparameter_defaults を確認します。

    • NeutronFujitsuCfabAddress: C-Fabric の telnet IP アドレス (文字列)
    • NeutronFujitsuCfabUserName: 使用する C-Fabric ユーザー名 (文字列)
    • NeutronFujitsuCfabPassword: C-Fabric ユーザーアカウントのパスワード (文字列)
    • NeutronFujitsuCfabPhysicalNetworks: physical_network 名と対応する vfab ID を指定する <physical_network>:<vfab_id> タプルの一覧 (コンマ区切りリスト)
    • NeutronFujitsuCfabSharePprofile: 同じ VLAN ID を使用する neutron ポート間で C-Fabric pprofile を共有するかどうかを決定するパラメーター (ブール値)
    • NeutronFujitsuCfabPprofilePrefix: pprofile 名のプレフィックス文字列 (文字列)
    • NeutronFujitsuCfabSaveConfig: 設定を保存するかどうかを決定するパラメーター (ブール値)
  4. デプロイメントにテンプレートを適用するには、openstack overcloud deploy コマンドで環境ファイルを指定します。

    $ openstack overcloud deploy --templates -e /home/stack/templates/neutron-ml2-fujitsu-cfab.yaml [OTHER OPTIONS] ...

10.5.14.2. Fujitsu FOS Switch

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

手順

  1. 環境ファイルを templates サブディレクトリーにコピーします。

    $ cp /usr/share/openstack-tripleo-heat-templates/environments/neutron-ml2-fujitsu-fossw.yaml /home/stack/templates/
  2. resource_registry で絶対パスを使用するように編集します。

    resource_registry:
      OS::TripleO::Services::NeutronML2FujitsuFossw: /usr/share/openstack-tripleo-heat-templates/puppet/services/neutron-plugin-ml2-fujitsu-fossw.yaml
  3. /home/stack/templates/neutron-ml2-fujitsu-fossw.yamlparameter_defaults を確認します。

    • NeutronFujitsuFosswIps: 全 FOS スイッチの IP アドレス (コンマ区切りリスト)
    • NeutronFujitsuFosswUserName: 使用する FOS ユーザー名 (文字列)
    • NeutronFujitsuFosswPassword: FOS ユーザーアカウントのパスワード (文字列)
    • NeutronFujitsuFosswPort: SSH 接続に使用するポート番号 (数値)
    • NeutronFujitsuFosswTimeout: SSH 接続のタイムアウト時間 (数値)
    • NeutronFujitsuFosswUdpDestPort: FOS スイッチ上の VXLAN UDP 宛先のポート番号 (数値)
    • NeutronFujitsuFosswOvsdbVlanidRangeMin: VNI および物理ポートのバインディングに使用する範囲内の最小の VLAN ID (数値)
    • NeutronFujitsuFosswOvsdbPort: FOS スイッチ上の OVSDB サーバー用のポート番号 (数値)
  4. デプロイメントにテンプレートを適用するには、openstack overcloud deploy コマンドで環境ファイルを指定します。

    $ openstack overcloud deploy --templates -e /home/stack/templates/neutron-ml2-fujitsu-fossw.yaml [OTHER OPTIONS] ...

10.5.15. Identity の設定

director には、Identity サービス (keystone) の設定に役立つパラメーターが含まれています。

10.5.15.1. リージョン名

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

parameter_defaults:
  KeystoneRegion: 'SampleRegion'

10.5.16. その他の設定

10.5.16.1. オーバークラウドノードカーネルの設定

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

ExtraKernelModules

読み込むカーネルモジュール。モジュール名は、空の値を持つハッシュキーとして一覧表示されます。

  ExtraKernelModules:
    <MODULE_NAME>: {}
ExtraKernelPackages

ExtraKernelModules で定義されるカーネルモジュールを読み込む前にインストールするカーネル関連のパッケージ。パッケージ名は、空の値を持つハッシュキーとして一覧表示されます。

  ExtraKernelPackages:
    <PACKAGE_NAME>: {}
ExtraSysctlSettings

適用する sysctl 設定のハッシュ。value キーを使用して、各パラメーターの値を設定します。

  ExtraSysctlSettings:
    <KERNEL_PARAMETER>:
      value: <VALUE>

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

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

10.5.16.2. サーバーコンソールの設定

オーバークラウドノードからのコンソール出力は、常にサーバーコンソールに送信される訳ではありません。サーバーコンソールでこの出力を表示するには、ハードウェアの正しいコンソールを使用するようにオーバークラウドを設定する必要があります。この設定を行うには、以下のいずれかの方法を使用します。

  • オーバークラウドロールごとに KernelArgs heat パラメータを変更する
  • オーバークラウドノードをプロビジョニングするのに director が使用する overcloud-full.qcow2 イメージをカスタマイズする

前提条件

デプロイメント時の heat を使用した KernelArgs の変更

  1. アンダークラウドホストに stack ユーザーとしてログインします。
  2. source コマンドで stackrc 認証情報ファイルを読み込みます。

    $ source stackrc
  3. 以下の内容で環境ファイル overcloud-console.yaml を作成します。

    parameter_defaults:
      <role>Parameters:
        KernelArgs: "console=<console-name>"

    <role> を設定するオーバークラウドロールの名前に置き換え、<console-name> を使用するコンソールの ID に置き換えます。たとえば、デフォルトロールのすべてのオーバークラウドノードが tty0 を使用するように設定するには、以下のスニペットを使用します。

    parameter_defaults:
      ControllerParameters:
        KernelArgs: "console=tty0"
      ComputeParameters:
        KernelArgs: "console=tty0"
      BlockStorageParameters:
        KernelArgs: "console=tty0"
      ObjectStorageParameters:
        KernelArgs: "console=tty0"
      CephStorageParameters:
        KernelArgs: "console=tty0"
  4. -e オプションを使用して、overcloud-console-tty0.yaml ファイルをデプロイメントコマンドに追加します。

overcloud-full.qcow2 イメージの変更

  1. アンダークラウドホストに stack ユーザーとしてログインします。
  2. source コマンドで stackrc 認証情報ファイルを読み込みます。

    $ source stackrc
  3. overcloud-full.qcow2 イメージのカーネル引数を変更して、ハードウェアの正しいコンソールを設定します。たとえば、コンソールを tty0 に設定します。

    $ virt-customize --selinux-relabel -a overcloud-full.qcow2 --run-command 'grubby --update-kernel=ALL --args="console=tty0"'
  4. イメージを director にインポートします。

    $ openstack overcloud image upload --image-path overcloud-full.qcow2
  5. オーバークラウドをデプロイします。

検証

  1. アンダークラウドからオーバークラウドノードにログインします。

    $ ssh heat-admin@<IP-address>

    <IP-address> をオーバークラウドノードの IP アドレスに置き換えます。

  2. /proc/cmdline ファイルの内容を調べ、console= パラメータが使用するコンソールの値に設定されていることを確認します。

    [heat-admin@controller-0 ~]$ cat /proc/cmdline
    BOOT_IMAGE=(hd0,msdos2)/boot/vmlinuz-4.18.0-193.29.1.el8_2.x86_64 root=UUID=0ec3dea5-f293-4729-b676-5d38a611ce81 ro console=tty0 console=ttyS0,115200n81 no_timer_check crashkernel=auto rhgb quiet

10.5.16.3. 外部の負荷分散機能の設定

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

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

10.5.16.4. IPv6 ネットワークの設定

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

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