8.2. オーバークラウドネットワークのカスタマイズ


オーバークラウドの物理ネットワークの設定をカスタマイズできます。たとえば、Jinja2 ansible 形式 (j2) の NIC テンプレートファイルを使用して、ネットワークインターフェイスコントローラー (NIC) の設定ファイルを作成できます。

8.2.1. カスタムネットワークインターフェイステンプレートの定義

カスタムネットワークインターフェイステンプレートのセットを作成して、オーバークラウド環境の各ノードの NIC レイアウトを定義できます。オーバークラウドのコアテンプレートコレクションには、さまざまなユースケース向けのデフォルトの NIC レイアウトのセットが含まれています。拡張子が .j2.yaml の Jinja2 形式のファイルを使用して、カスタム NIC テンプレートを作成できます。director は、デプロイメント中に Jinja2 ファイルを YAML 形式に変換します。

その後、ノード定義ファイル overcloud-baremetal-deploy.yamlnetwork_config プロパティーをカスタム NIC テンプレートに設定して、特定のノードのネットワークをプロビジョニングできます。詳細は、オーバークラウド用のベアメタルノードのプロビジョニング を参照してください。

8.2.1.1. カスタム NIC テンプレートの作成

オーバークラウド環境の各ノードの NIC レイアウトをカスタマイズするための NIC テンプレートを作成します。

手順

  1. 必要なサンプルネットワーク設定テンプレートを /usr/share/ansible/roles/tripleo_network_config/templates/ から環境ファイルディレクトリーにコピーします。

    $ cp /usr/share/ansible/roles/tripleo_network_config/templates/<sample_NIC_template> /home/stack/templates/<NIC_template>
    Copy to Clipboard Toggle word wrap
    • <sample_NIC_template> は、コピーするサンプル NIC テンプレートの名前 (single_nic_vlans/single_nic_vlans.j2 など) に置き換えます。
    • <NIC_template> は、カスタム NIC テンプレートファイルの名前 (例: single_nic_vlans.j2) に置き換えます。
  2. オーバークラウドのネットワーク環境の要件に合わせて、カスタム NIC テンプレートのネットワーク設定を更新します。NIC テンプレートの設定に使用できるプロパティーについては、ネットワークインターフェイス設定オプション を参照してください。NIC テンプレートの例は、カスタムネットワークインターフェイスの例 を参照してください。
  3. 既存の環境ファイルを作成または更新して、カスタム NIC 設定テンプレートを有効にします。

    parameter_defaults:
      ControllerNetworkConfigTemplate: '/home/stack/templates/single_nic_vlans.j2'
      CephStorageNetworkConfigTemplate: '/home/stack/templates/single_nic_vlans_storage.j2'
      ComputeNetworkConfigTemplate: '/home/stack/templates/single_nic_vlans.j2'
    Copy to Clipboard Toggle word wrap
  4. オーバークラウドがデフォルトの内部負荷分散を使用する場合は、以下の設定を環境ファイルに追加して、Redis および OVNDB に予測可能な仮想 IP を割り当てます。

    parameter_defaults:
      RedisVirtualFixedIPs: [{'ip_address':'<vip_address>'}]
      OVNDBsVirtualFixedIPs: [{'ip_address':'<vip_address>'}]
    Copy to Clipboard Toggle word wrap
    • <vip_address> は、割り当てプール範囲外の IP アドレスに置き換えます。

8.2.1.2. ネットワークインターフェイスの設定オプション

次の表では、ネットワークインターフェイスの設定に使用できるオプションを説明しています。

interface

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

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

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

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

  - type: interface
    name: nic2
Copy to Clipboard Toggle word wrap
Expand
表8.1 interface のオプション
オプションデフォルト説明

name

 

インターフェイスの名前。ネットワークインターフェイスの name には、実際のインターフェイス名 (eth0eth1enp0s25) または一連の番号付きインターフェイス (nic1nic2nic3) が使用されます。

use_dhcp

False

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

use_dhcpv6

False

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

addresses

 

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

routes

 

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

mtu

1500

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

primary

False

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

persist_mapping

False

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

dhclient_args

None

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

dns_servers

None

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

ethtool_opts

 

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

vlan

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

以下に例を示します。

  - type: vlan
    device: nic{{ loop.index + 1 }}
    mtu: {{ lookup('vars', networks_lower[network] ~ '_mtu') }}
    vlan_id: {{ lookup('vars', networks_lower[network] ~ '_vlan_id') }}
    addresses:
    - ip_netmask:
      {{ lookup('vars', networks_lower[network] ~ '_ip') }}/{{ lookup('vars', networks_lower[network] ~ '_cidr') }}
  routes: {{ lookup('vars', networks_lower[network] ~ '_host_routes') }}
Copy to Clipboard Toggle word wrap
Expand
表8.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 を定義します。

persist_mapping

False

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

dhclient_args

なし

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

dns_servers

なし

VLAN に使用する DNS サーバーのリスト

ovs_bond

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

以下に例を示します。

  members:
    - type: ovs_bond
      name: bond1
      mtu: {{ min_viable_mtu }}
      ovs_options: {{ bond_interface_ovs_options }}
      members:
      - type: interface
        name: nic2
        mtu: {{ min_viable_mtu }}
        primary: true
      - type: interface
        name: nic3
        mtu: {{ min_viable_mtu }}
Copy to Clipboard Toggle word wrap
Expand
表8.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: br-bond
    dns_servers: {{ ctlplane_dns_nameservers }}
    domain: {{ dns_search_domains }}
    members:
    - type: ovs_bond
      name: bond1
      mtu: {{ min_viable_mtu }}
      ovs_options: {{ bound_interface_ovs_options }}
      members:
      - type: interface
        name: nic2
        mtu: {{ min_viable_mtu }}
        primary: true
      - type: interface
        name: nic3
        mtu: {{ min_viable_mtu }}
Copy to Clipboard Toggle word wrap
注記

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 が必要となります。
Expand
表8.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
  mtu: {{ min_viable_mtu }}
  bonding_options: "mode=802.3ad lacp_rate=fast updelay=1000 miimon=100 xmit_hash_policy=layer3+4"
  members:
    type: interface
    name: ens1f0
    mtu: {{ min_viable_mtu }}
    primary: true
  type: interface
    name: ens1f1
    mtu: {{ min_viable_mtu }}
Copy to Clipboard Toggle word wrap
Expand
表8.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
      mtu:
        get_attr: [MinViableMtu, value]
      use_dhcp: false
      dns_servers:
        get_param: DnsServers
      domain:
        get_param: DnsSearchDomains
      addresses:
      - ip_netmask:
          list_join:
          - /
          - - get_param: ControlPlaneIp
            - get_param: ControlPlaneSubnetCidr
      routes:
        list_concat_unique:
          - get_param: ControlPlaneStaticRoutes
Copy to Clipboard Toggle word wrap
Expand
表8.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: linux_bridge
    name: bridge_name
    ...
    routes: {{ [ctlplane_host_routes] | flatten | unique }}
Copy to Clipboard Toggle word wrap
Expand
オプションデフォルト説明

ip_netmask

なし

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

default

False

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

next_hop

なし

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

8.2.1.3. カスタムネットワークインターフェイスの例

次の例は、ネットワークインターフェイステンプレートをカスタマイズする方法を示しています。

制御グループと OVS ブリッジを分離する例

以下に示すコントローラーノードの NIC テンプレートの例では、OVS ブリッジとは別に制御グループを設定します。このテンプレートは、5 つのネットワークインターフェイスを使用し、タグ付けされた複数の VLAN デバイスを、番号によるインターフェイスに割り当てます。テンプレートは、nic4 および nic5 に OVS ブリッジを作成します。

network_config:
- type: interface
  name: nic1
  mtu: {{ ctlplane_mtu }}
  use_dhcp: false
  addresses:
  - ip_netmask: {{ ctlplane_ip }}/{{ ctlplane_subnet_cidr }}
  routes: {{ ctlplane_host_routes }}
- type: linux_bond
  name: bond_api
  mtu: {{ min_viable_mtu_ctlplane }}
  use_dhcp: false
  bonding_options: {{ bond_interface_ovs_options }}
  dns_servers: {{ ctlplane_dns_nameservers }}
  domain: {{ dns_search_domains }}
  members:
  - type: interface
    name: nic2
    mtu: {{ min_viable_mtu_ctlplane }}
    primary: true
  - type: interface
    name: nic3
    mtu: {{ min_viable_mtu_ctlplane }}
{% for network in role_networks if not network.startswith('Tenant') %}
- type: vlan
  device: bond_api
  mtu: {{ lookup('vars', networks_lower[network] ~ '_mtu') }}
  vlan_id: {{ lookup('vars', networks_lower[network] ~ '_vlan_id') }}
  addresses:
  - ip_netmask: {{ lookup('vars', networks_lower[network] ~ '_ip') }}/{{ lookup('vars', networks_lower[network] ~ '_cidr') }}
  routes: {{ lookup('vars', networks_lower[network] ~ '_host_routes') }}
{% endfor %}
- type: ovs_bridge
  name: {{ neutron_physical_bridge_name }}
  dns_servers: {{ ctlplane_dns_nameservers }}
  members:
  - type: linux_bond
    name: bond-data
    mtu: {{ min_viable_mtu_dataplane }}
    bonding_options: {{ bond_interface_ovs_options }}
    members:
    - type: interface
      name: nic4
      mtu: {{ min_viable_mtu_dataplane }}
      primary: true
    - type: interface
      name: nic5
      mtu: {{ min_viable_mtu_dataplane }}
{% for network in role_networks if network.startswith('Tenant') %}
  - type: vlan
    device: bond-data
    mtu: {{ lookup('vars', networks_lower[network] ~ '_mtu') }}
    vlan_id: {{ lookup('vars', networks_lower[network] ~ '_vlan_id') }}
    addresses:
    - ip_netmask: {{ lookup('vars', networks_lower[network] ~ '_ip') }}/{{ lookup('vars', networks_lower[network] ~ '_cidr') }}
    routes: {{ lookup('vars', networks_lower[network] ~ '_host_routes') }}
Copy to Clipboard Toggle word wrap

複数の NIC の例

次の例では、2 番目の NIC を使用して、DHCP アドレスを持つインフラストラクチャーネットワークに接続し、ボンド用に別の NIC を使用します。

network_config:
  # Add a DHCP infrastructure network to nic2
  - type: interface
    name: nic2
    mtu: {{ tenant_mtu }}
    use_dhcp: true
    primary: true
  - type: vlan
    mtu: {{ tenant_mtu }}
    vlan_id: {{ tenant_vlan_id }}
    addresses:
    - ip_netmask: {{ tenant_ip }}/{{ tenant_cidr }}
    routes: {{ [tenant_host_routes] | flatten | unique }}
  - type: ovs_bridge
    name: br-bond
    mtu: {{ external_mtu }}
    dns_servers: {{ ctlplane_dns_nameservers }}
    use_dhcp: false
    members:
      - type: interface
        name: nic10
        mtu: {{ external_mtu }}
        use_dhcp: false
        primary: true
      - type: vlan
        mtu: {{ external_mtu }}
        vlan_id: {{ external_vlan_id }}
        addresses:
        - ip_netmask: {{ external_ip }}/{{ external_cidr }}
        routes: {{ [external_host_routes, [{'default': True, 'next_hop': external_gateway_ip}]] | flatten | unique }}
Copy to Clipboard Toggle word wrap

8.2.1.4. 事前にプロビジョニングされたノードの NIC マッピングのカスタマイズ

事前にプロビジョニングされたノードを使用している場合は、次のいずれかの方法を使用して、特定のノードの os-net-config マッピングを指定できます。

  • 環境ファイルで NetConfigDataLookup heat パラメーターを設定し、--network-config を指定せずに openstack overcloud node provision コマンドを実行します。
  • ノード定義ファイル overcloud-baremetal-deploy.yamlnet_config_data_lookup プロパティーを設定し、--network-config を指定して openstack overcloud node provision コマンドを実行します。
注記

事前にプロビジョニングされたノードを使用していない場合は、ノード定義ファイルで NIC マッピングを設定する必要があります。net_config_data_lookup プロパティーの設定の詳細は、ベアメタルノードのプロビジョニング属性 を参照してください。

各ノードの物理インターフェイスにエイリアスを割り当てて、nic1 または nic2 などの特定のエイリアスにマッピングする物理 NIC を事前に定義したり、MAC アドレスを特定のエイリアスにマッピングしたりできます。MAC アドレスまたは DMI キーワードを使用して特定のノードをマップしたり、DMI キーワードを使用してノードのグループをマップしたりできます。次の例では、物理インターフェイスへのエイリアスを持つ 3 つのノードと 2 つのノードグループを設定します。得られた設定は、os-net-config により適用されます。これぞれのノードで、適用された設定が /etc/os-net-config/mapping.yaml ファイルの interface_mapping セクションに表示されます。

例 1: os-net-config-mappings.yamlNetConfigDataLookup パラメーターを設定する

NetConfigDataLookup:
  node1: 
1

    nic1: "00:c8:7c:e6:f0:2e"
  node2:
    nic1: "00:18:7d:99:0c:b6"
  node3: 
2

    dmiString: "system-uuid" 
3

    id: 'A8C85861-1B16-4803-8689-AFC62984F8F6'
    nic1: em3
  # Dell PowerEdge
  nodegroup1: 
4

    dmiString: "system-product-name"
    id: "PowerEdge R630"
    nic1: em3
    nic2: em1
    nic3: em2
  # Cisco UCS B200-M4"
  nodegroup2:
    dmiString: "system-product-name"
    id: "UCSB-B200-M4"
    nic1: enp7s0
    nic2: enp6s0
Copy to Clipboard Toggle word wrap

1
指定の MAC アドレスに node1 をマップし、このノードの MAC アドレスのエイリアスとして nic1 を割り当てます。
2
node3 をシステム UUID "A8C85861-1B16-4803-8689-AFC62984F8F6" を持つノードにマップし、このノード上の em3 インターフェイスのエイリアスとして nic1 を割り当てます。
3
dmiString パラメーターは有効な文字列キーワードに設定する必要があります。有効な文字列キーワードのリストは、DMIDECODE(8) のマニュアルページを参照してください。
4
nodegroup1 内のすべてのノードを製品名 "PowerEdge R630" のノードにマップし、これらのノード上の名前付きインターフェイスのエイリアスとして nic1nic2、および nic3 を割り当てます。
注記

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

例 2: overcloud-baremetal-deploy.yamlnet_config_data_lookup プロパティーを設定する (特定のノード)

- name: Controller
  count: 3
  defaults:
    network_config:
      net_config_data_lookup:
        node1:
          nic1: "00:c8:7c:e6:f0:2e"
        node2:
          nic1: "00:18:7d:99:0c:b6"
        node3:
          dmiString: "system-uuid"
          id: 'A8C85861-1B16-4803-8689-AFC62984F8F6'
          nic1: em3
        # Dell PowerEdge
        nodegroup1:
          dmiString: "system-product-name"
          id: "PowerEdge R630"
          nic1: em3
          nic2: em1
          nic3: em2
        # Cisco UCS B200-M4"
        nodegroup2:
          dmiString: "system-product-name"
          id: "UCSB-B200-M4"
          nic1: enp7s0
          nic2: enp6s0
Copy to Clipboard Toggle word wrap

例 3: overcloud-baremetal-deploy.yamlnet_config_data_lookup プロパティーを設定する (ロールの全ノード)

- name: Controller
  count: 3
  defaults:
    network_config:
      template: templates/net_config_bridge.j2
      default_route_network:
      - external
  instances:
  - hostname: overcloud-controller-0
    network_config:
      net_config_data_lookup:
        nic1: 'XX:XX:XX:XX:XX:XX'
        nic2: 'YY:YY:YY:YY:YY:YY'
        nic3: 'ens1f0'
Copy to Clipboard Toggle word wrap

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

特定のネットワークトラフィックを異なるネットワークでホストする場合は、カスタムコンポーザブルネットワークを作成することができます。Director は、ネットワーク分離が有効になっているデフォルトのネットワークトポロジーを提供します。この設定は /usr/share/openstack-tripleo-heat-templates/network-data-samples/default-network-isolation.yaml にあります。

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

  • Internal API
  • ストレージ
  • Storage Management
  • Tenant
  • External

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

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

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

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

手順

  1. 利用可能なサンプルネットワーク設定ファイルをリストします。

    $ ll /usr/share/openstack-tripleo-heat-templates/network-data-samples/
    -rw-r--r--. 1 root root 1554 May 11 23:04 default-network-isolation-ipv6.yaml
    -rw-r--r--. 1 root root 1181 May 11 23:04 default-network-isolation.yaml
    -rw-r--r--. 1 root root 1126 May 11 23:04 ganesha-ipv6.yaml
    -rw-r--r--. 1 root root 1100 May 11 23:04 ganesha.yaml
    -rw-r--r--. 1 root root 3556 May 11 23:04 legacy-routed-networks-ipv6.yaml
    -rw-r--r--. 1 root root 2929 May 11 23:04 legacy-routed-networks.yaml
    -rw-r--r--. 1 root root  383 May 11 23:04 management-ipv6.yaml
    -rw-r--r--. 1 root root  290 May 11 23:04 management.yaml
    -rw-r--r--. 1 root root  136 May 11 23:04 no-networks.yaml
    -rw-r--r--. 1 root root 2725 May 11 23:04 routed-networks-ipv6.yaml
    -rw-r--r--. 1 root root 2033 May 11 23:04 routed-networks.yaml
    -rw-r--r--. 1 root root  943 May 11 23:04 vip-data-default-network-isolation.yaml
    -rw-r--r--. 1 root root  848 May 11 23:04 vip-data-fixed-ip.yaml
    -rw-r--r--. 1 root root 1050 May 11 23:04 vip-data-routed-networks.yaml
    Copy to Clipboard Toggle word wrap
  2. 必要なサンプルネットワーク設定ファイルを /usr/share/openstack-tripleo-heat-templates/network-data-samples から環境ファイルディレクトリーにコピーします。

    $ cp /usr/share/openstack-tripleo-heat-templates/network-data-samples/default-network-isolation.yaml /home/stack/templates/network_data.yaml
    Copy to Clipboard Toggle word wrap
  3. network_data.yaml 設定ファイルを編集して、新しいネットワークのセクションを追加します。

    - name: StorageBackup
      vip: false
      name_lower: storage_backup
      subnets:
        storage_backup_subnet:
          ip_subnet: 172.16.6.0/24
          allocation_pools: [{'start': '172.16.6.4', 'end': '172.16.6.250'}]
          gateway_ip: 172.16.6.1
    Copy to Clipboard Toggle word wrap

    環境のその他のネットワーク VIP 属性を設定します。ネットワーク属性の設定に使用できるプロパティーの詳細は、ネットワーク定義ファイルの設定オプション を参照してください。

  4. Red Hat Ceph Storage をデプロイし、NFS を使用している場合は、分離された StorageNFS ネットワークを含めるようにしてください。以下は、そのようなファイルの例です。

    • /usr/share/openstack-tripleo-heat-templates/network-data-samples/ganesha.yaml
    • /usr/share/openstack-tripleo-heat-templates/network-data-samples/ganesha-ipv6.yaml

      VLAN ID やサブネット範囲などのネットワーク設定をカスタマイズします。IPv4 または IPv6 が不要な場合は、対応するサブネットを除外できます。

      以下に例を示します。

      - name: StorageNFS
        enabled: true
        vip: true
        name_lower: storage_nfs
        subnets:
          storage_nfs_subnet:
            vlan: 70
            ip_subnet: 172.17.0.0/20
            allocation_pools: [{'start': '172.17.0.4', 'end': '172.17.0.250'}]
          storage_nfs_ipv6_subnet:
            ipv6_subnet: fd00:fd00:fd00:7000::/64
            ipv6_allocation_pools:
              - start: fd00:fd00:fd00:7000::4
              - end: fd00:fd00:fd00:7000::fffe
      Copy to Clipboard Toggle word wrap
    • このネットワークは、オーバークラウドデプロイメントと、オーバークラウドのデプロイ後にセットアップされる Networking サービス (neutron) プロバイダーネットワークにより共有され、Compute サービス (nova) 仮想マシンのようなコンシューマーが共有をマウントするために使用されます。
    • オーバークラウド Networking サービス StorageNFS プロバイダーネットワークのサブネット定義の割り当てプールで使用するために、この例で指定した割り当てプール外に相応の範囲を残しておきます。
  5. 仮想 IP を含むコンポーザブルネットワークを追加し、一部の API サービスをこのネットワークにマッピングする場合は、CloudName{network.name} 定義を使用して API エンドポイントの DNS 名を設定します。

    CloudName{{network.name}}
    Copy to Clipboard Toggle word wrap

    以下に例を示します。

    parameter_defaults:
      ...
      CloudNameOcProvisioning: baremetal-vip.example.com
    Copy to Clipboard Toggle word wrap
  6. 必要なサンプルネットワーク VIP 定義テンプレートを /usr/share/openstack-tripleo-heat-templates/network-data-samples から環境ファイルディレクトリーにコピーします。次の例では、vip-data-default-network-isolation.yamlvip_data.yaml という名前のローカル環境ファイルにコピーします。

    $ cp /usr/share/openstack-tripleo-heat-templates/network-data-samples/vip-data-default-network-isolation.yaml  /home/stack/templates/vip_data.yaml
    Copy to Clipboard Toggle word wrap
  7. vip_data.yaml 設定ファイルを編集します。仮想 IP データは仮想 IP アドレス定義のリストであり、それぞれに IP アドレスが割り当てられているネットワークの名前が含まれています。

    - network: storage_mgmt
      dns_name: overcloud
    - network: internal_api
      dns_name: overcloud
    - network: storage
      dns_name: overcloud
    - network: external
      dns_name: overcloud
      ip_address: <vip_address>
    - network: ctlplane
      dns_name: overcloud
    - network: storage_nfs
      dns_name: overcloud
      ip_address: <vip_address>
    Copy to Clipboard Toggle word wrap
    • <vip_address> は、必要な仮想 IP アドレスに置き換えます。

    VIP 定義ファイルでネットワーク VIP 属性を設定するために使用できるプロパティーの詳細は、ネットワーク VIP 属性のプロパティー を参照してください。

  8. サンプルネットワーク設定テンプレートをコピーします。Jinja2 テンプレートは、NIC 設定テンプレートを定義するために使用されます。/usr/share/ansible/roles/tripleo_network_config/templates/ ディレクトリーにある例を参照してください。例の 1 つが要件に一致する場合は、それを使用してください。例が要件に合わない場合は、サンプル設定ファイルをコピーし、必要に応じて変更します。

    $ cp /usr/share/ansible/roles/tripleo_network_config/templates/single_nic_vlans/single_nic_vlans.j2 /home/stack/templates/
    Copy to Clipboard Toggle word wrap
  9. single_nic_vlans.j2 設定ファイルを編集します。

    ---
    {% set mtu_list = [ctlplane_mtu] %}
    {% for network in role_networks %}
    {{ mtu_list.append(lookup('vars', networks_lower[network] ~ '_mtu')) }}
    {%- endfor %}
    {% set min_viable_mtu = mtu_list | max %}
    network_config:
    - type: ovs_bridge
      name: {{ neutron_physical_bridge_name }}
      mtu: {{ min_viable_mtu }}
      use_dhcp: false
      dns_servers: {{ ctlplane_dns_nameservers }}
      domain: {{ dns_search_domains }}
      addresses:
      - ip_netmask: {{ ctlplane_ip }}/{{ ctlplane_subnet_cidr }}
      routes: {{ ctlplane_host_routes }}
      members:
      - type: interface
        name: nic1
        mtu: {{ min_viable_mtu }}
        # force the MAC address of the bridge to this interface
        primary: true
    {% for network in role_networks %}
      - type: vlan
        mtu: {{ lookup('vars', networks_lower[network] ~ '_mtu') }}
        vlan_id: {{ lookup('vars', networks_lower[network] ~ '_vlan_id') }}
        addresses:
        - ip_netmask:
            {{ lookup('vars', networks_lower[network] ~ '_ip') }}/{{ lookup('vars', networks_lower[network] ~ '_cidr') }}
        routes: {{ lookup('vars', networks_lower[network] ~ '_host_routes') }}
    {% endfor %}
    Copy to Clipboard Toggle word wrap
  10. overcloud-baremetal-deploy.yaml 設定ファイルで network_config テンプレートを設定します。

    - name: CephStorage
      count: 3
      defaults:
        networks:
        - network: storage
        - network: storage_mgmt
        - network: storage_backup
        network_config:
          template: /home/stack/templates/single_nic_vlans.j2
    Copy to Clipboard Toggle word wrap

    Shared File Systems サービス (manila) で CephFS-NFS バックエンドを使用するために StorageNFS ネットワークをプロビジョニングする場合は、network_config セクションではなく、Controller または ControllerStorageNfs セクションを編集します。これは、StorageNFS ネットワークとその仮想 IP がコントローラーノードに接続されているためです。

    - name: ControllerStorageNfs
      count: 3
      hostname_format: controller-%index%
      instances:
      - hostname: controller-0
        name: controller-0
      - hostname: controller-1
        name: controller-1
      - hostname: controller-2
        name: controller-2
      defaults:
        profile: control
        network_config:
          template: /home/stack/templates/single_nic_vlans.j2
        networks:
        - network: ctlplane
          vif: true
        - network: external
        - network: internal_api
        - network: storage
        - network: storage_mgmt
        - network: tenant
        - network: storage_nfs
    Copy to Clipboard Toggle word wrap
  11. オーバークラウドネットワークをプロビジョニングします。このアクションにより、オーバークラウドのデプロイ時に環境ファイルで使用される出力ファイルが生成されます。

    (undercloud)$ openstack overcloud network provision \
    --output <deployment_file> /home/stack/templates/<networks_definition_file>.yaml
    Copy to Clipboard Toggle word wrap
    • <networks_definition_file> を、network_data.yaml などのネットワーク定義ファイルの名前、または network_data_ganesha.yaml などの StorageNFS ネットワークファイルの名前に置き換えます。
    • <deployment_file> は、デプロイメントコマンドに追加するために生成する heat 環境ファイルの名前に置き換えます (例 :/home/stack/templates/overcloud-networks-deployed.yaml)
  12. ネットワーク VIP をプロビジョニングし、vip-deployed-environment.yaml ファイルを生成します。オーバークラウドをデプロイするときに、このファイルを使用します。

    (overcloud)$ openstack overcloud network vip provision  --stack <stack> --output <deployment_file> /home/stack/templates/vip_data.yaml
    Copy to Clipboard Toggle word wrap
    • <stack> は、ネットワーク VIP がプロビジョニングされるスタックの名前に置き換えます。指定しない場合、デフォルトは overcloud です。
    • <deployment_file> は、デプロイメントコマンドに含めるために生成する heat 環境ファイルの名前に置き換えます (例 :/home/stack/templates/overcloud-vip-deployed.yaml)

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

コンポーザブルネットワークをご自分の環境で定義したオーバークラウドロールに割り当てることができます。たとえば、Ceph Storage ノードにカスタム StorageBackup ネットワークを含めたり、Shared File Systems サービス (manila) で CephFS-NFS を使用するためのカスタム StorageNFS ネットワークを含めたりすることができます。director にデフォルトで含まれている ControllerStorageNfs ロールを使用する場合、StorageNFS ネットワークはすでに追加されています。

手順

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

    $ cp /usr/share/openstack-tripleo-heat-templates/roles_data.yaml /home/stack/templates/roles_data.yaml
    Copy to Clipboard Toggle word wrap
  2. カスタムの roles_data.yaml ファイルを編集します。
  3. ネットワークを追加するロールの networks リストにネットワーク名を追加します。

    • この例では、StorageBackup ネットワークを Ceph Storage ロールに追加します。

      - name: CephStorage
        description: |
          Ceph OSD Storage node role
        networks:
          Storage
            subnet: storage_subnet
          StorageMgmt
            subnet: storage_mgmt_subnet
          StorageBackup
            subnet: storage_backup_subnet
      Copy to Clipboard Toggle word wrap
    • この例では、StorageNFS ネットワークをコントローラーノードに追加します。

      - name: Controller
        description: |
          Controller role that has all the controller services loaded, handles
          Database, Messaging and Network functions, and additionally runs a ganesha
          service as a CephFS to NFS gateway.  The gateway serves NFS exports via a
          VIP on a new isolated StorageNFS network.
        # ganesha service should always be deployed in HA configuration.
        CountDefault: 3
        tags:
          - primary
          - controller
        networks:
          External:
            subnet: external_subnet
          InternalApi:
            subnet: internal_api_subnet
          Storage:
            subnet: storage_subnet
          StorageMgmt:
            subnet: storage_mgmt_subnet
          Tenant:
            subnet: tenant_subnet
          StorageNFS:
            subnet: storage_nfs_subnet
      Copy to Clipboard Toggle word wrap
  4. カスタムネットワークを対応するロールに追加したら、ファイルを保存します。

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

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

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

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

parameter_defaults:
  ServiceNetMap:
    SwiftStorageNetwork: storage_backup
    CephClusterNetwork: storage_backup
Copy to Clipboard Toggle word wrap

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

director はカスタムの ServiceNetMap パラメーターの定義を ServiceNetMapDefaults から取得したデフォルト値の事前定義済みリストにマージして、デフォルト値を上書きします。director はカスタマイズされた設定を含む完全なリストを ServiceNetMap に返し、そのリストは多様なサービスのネットワーク割り当ての設定に使用されます。たとえば、GaneshaNetwork は、CephFS-NFS の NFS ゲートウェイのデフォルトサービスネットワークです。このネットワークはデフォルトで storage_nfs になりますが、外部ネットワークまたは ctlplane ネットワークにフォールバックします。デフォルトの分離された StorageNFS ネットワークの代わりに別のネットワークを使用している場合は、ServiceNetMap パラメーター定義を使用してデフォルトのネットワークを更新する必要があります。

以下に例を示します。

parameter_defaults:
  ServiceNetMap:
    GaneshaNetwork: <manila_nfs_network>
Copy to Clipboard Toggle word wrap
  • <manila_nfs_network> を、カスタムネットワークの名前に置き換えます。

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

注記

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

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

デフォルトの NIC テンプレートの 1 つを使用して、カスタムのコンポーザブルネットワークを有効にします。この例では、Single NIC with VLANs テンプレート (custom_single_nic_vlans) を使用します。

手順

  1. stackrc アンダークラウド認証情報ファイルを入手します。

    $ source ~/stackrc
    Copy to Clipboard Toggle word wrap
  2. オーバークラウドネットワークをプロビジョニングします。

    $ openstack overcloud network provision \
      --output overcloud-networks-deployed.yaml \
      custom_network_data.yaml
    Copy to Clipboard Toggle word wrap
  3. ネットワーク VIP をプロビジョニングします。

    $ openstack overcloud network vip provision \
        --stack overcloud \
        --output overcloud-networks-vips-deployed.yaml \
         custom_vip_data.yaml
    Copy to Clipboard Toggle word wrap
  4. オーバークラウドノードをプロビジョニングします。

    $ openstack overcloud node provision \
        --stack overcloud \
        --output overcloud-baremetal-deployed.yaml \
        overcloud-baremetal-deploy.yaml
    Copy to Clipboard Toggle word wrap
  5. 以下の例のように、設定ファイルとテンプレートを必要な順序で指定して、openstack overcloud deploy コマンドを作成します。

    $ openstack overcloud deploy --templates \
      --networks-file network_data_v2.yaml \
      -e overcloud-networks-deployed.yaml \
      -e overcloud-networks-vips-deployed.yaml \
      -e overcloud-baremetal-deployed.yaml
      -e custom-net-single-nic-with-vlans.yaml
    Copy to Clipboard Toggle word wrap

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

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

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

  • InternalApi
  • External
  • Storage
  • StorageMgmt
  • Tenant

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

手順

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

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

    - name: InternalApi
      name_lower: MyCustomInternalApi
      service_net_map_replace: internal_api
    Copy to Clipboard Toggle word wrap

8.2.3. 追加のオーバークラウドネットワーク設定

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

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

ホストのデフォルトルートは、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
Copy to Clipboard Toggle word wrap
注記

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

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

    - type: vlan
      device: bond1
      vlan_id: 9
      addresses:
      - ip_netmask: 172.17.0.100/16
      routes:
      - ip_netmask: 10.1.2.0/24
        next_hop: 172.17.0.1
Copy to Clipboard Toggle word wrap

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

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

たとえば、デフォルトのルートが 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. /home/stack/templates/custom-nics ディレクトリーからのカスタム NIC テンプレートに interface エントリーを作成し、インターフェイスのルートを定義し、デプロイメントに関連するルールを定義します。

      network_config:
      - type: interface
        name: em1
        use_dhcp: false
        addresses:
          - ip_netmask: {{ external_ip }}/{{ external_cidr}}
        routes:
          - default: true
            next_hop: {{ external_gateway_ip }}
          - ip_netmask: {{ external_ip }}/{{ external_cidr}}
            next_hop: {{ external_gateway_ip }}
            table: 2
            route_options: metric 100
        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"
    Copy to Clipboard Toggle word wrap
  2. ご自分のデプロイメントに該当するその他の環境ファイルと共に、カスタム NIC 設定およびネットワーク環境ファイルをデプロイメントコマンドに追加します。

    $ openstack overcloud deploy --templates \
    -e /home/stack/templates/<custom-nic-template>
    -e <OTHER_ENVIRONMENT_FILES>
    Copy to Clipboard Toggle word wrap

検証

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

    $ cat /etc/iproute2/rt_tables
    $ ip route
    $ ip rule
    Copy to Clipboard Toggle word wrap

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

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

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

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

jinja2 テンプレートまたは network_data.yaml ファイルで mtu の値を変更できます。network_data.yaml ファイルに値を設定すると、デプロイ中にレンダリングされます。

警告

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

---
{% set mtu_list = [ctlplane_mtu] %}
{% for network in role_networks %}
{{ mtu_list.append(lookup('vars', networks_lower[network] ~ '_mtu')) }}
{%- endfor %}
{% set min_viable_mtu = mtu_list | max %}
network_config:
- type: ovs_bridge
  name: bridge_name
  mtu: {{ min_viable_mtu }}
  use_dhcp: false
  dns_servers: {{ ctlplane_dns_nameservers }}
  domain: {{ dns_search_domains }}
  addresses:
  - ip_netmask: {{ ctlplane_ip }}/{{ ctlplane_subnet_cidr }}
  routes: {{ [ctlplane_host_routes] | flatten | unique }}
  members:
  - type: interface
    name: nic1
    mtu: {{ min_viable_mtu }}
    primary: true
  - type: vlan
    mtu: 9000  
1

    vlan_id: {{ storage_vlan_id }}
    addresses:
    - ip_netmask: {{ storage_ip }}/{{ storage_cidr }}
    routes: {{ [storage_host_routes] | flatten | unique }}
  - type: vlan
    mtu: {{ storage_mgmt_mtu }} 
2

    vlan_id: {{ storage_mgmt_vlan_id }}
    addresses:
    - ip_netmask: {{ storage_mgmt_ip }}/{{ storage_mgmt_cidr }}
    routes: {{ [storage_mgmt_host_routes] | flatten | unique }}
  - type: vlan
    mtu: {{ internal_api_mtu }}
    vlan_id: {{ internal_api_vlan_id }}
    addresses:
    - ip_netmask: {{ internal_api_ip }}/{{ internal_api_cidr }}
    routes: {{ [internal_api_host_routes] | flatten | unique }}
  - type: vlan
    mtu: {{ tenant_mtu }}
    vlan_id: {{ tenant_vlan_id }}
    addresses:
    - ip_netmask: {{ tenant_ip }}/{{ tenant_cidr }}
    routes: {{ [tenant_host_routes] | flatten | unique }}
  - type: vlan
    mtu: {{ external_mtu }}
    vlan_id: {{ external_vlan_id }}
    addresses:
    - ip_netmask: {{ external_ip }}/{{ external_cidr }}
    routes: {{ [external_host_routes, [{'default': True, 'next_hop': external_gateway_ip}]] | flatten | unique }}
Copy to Clipboard Toggle word wrap
1
jinja2 テンプレートで直接更新される mtu 値。
2
mtu 値は、デプロイ中に network_data.yaml ファイルから取得されます。

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

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

次の例では、External ネットワークがネイティブ VLAN 上にあるボンディングインターフェイスを設定します。

network_config:
- type: ovs_bridge
  name: br-ex
  addresses:
  - ip_netmask: {{ external_ip }}/{{ external_cidr }}
  routes: {{ external_host_routes }}
  members:
  - type: ovs_bond
    name: bond1
    ovs_options: {{ bond_interface_ovs_options }}
    members:
    - type: interface
      name: nic3
      primary: true
    - type: interface
      name: nic4
Copy to Clipboard Toggle word wrap
注記

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

8.2.3.5. netfilter が追跡する接続の最大数を増やす

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

前提条件

  • RHOSP アンダークラウドのインストールが成功しました。

手順

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

    $ source ~/stackrc
    Copy to Clipboard Toggle word wrap
  3. カスタム YAML 環境ファイルを作成します。

    $ vi /home/stack/templates/custom-environment.yaml
    Copy to Clipboard Toggle word wrap

  4. 環境ファイルには、キーワード parameter_defaults および ExtraSysctlSettings が含まれている必要があります。netfilter が追跡できる接続の最大数の新しい値を変数 net.nf_conntrack_max に入力します。

    この例では、RHOSP デプロイメント内のすべてのホストにわたって conntrack 制限を設定できます。

    parameter_defaults:
      ExtraSysctlSettings:
        net.nf_conntrack_max:
          value: 500000
    Copy to Clipboard Toggle word wrap

    <role>Parameter パラメーターを使用して、特定のロールの conntrack 制限を設定します。

    parameter_defaults:
      <role>Parameters:
        ExtraSysctlSettings:
          net.nf_conntrack_max:
            value: <simultaneous_connections>
    Copy to Clipboard Toggle word wrap
    • <role> をロールの名前に置き換えます。

      たとえば、ControllerParameters を使用して Controller ロールの conntrack 制限を設定するか、ComputeParameters を使用して Compute ロールの conntrack 制限を設定します。

    • <simultaneous_connections> を、許可する同時接続数に置き換えます。

      この例では、RHOSP デプロイメントの Controller ロールのみに conntrack 制限を設定できます。

      parameter_defaults:
        ControllerParameters:
          ExtraSysctlSettings:
            net.nf_conntrack_max:
              value: 500000
      Copy to Clipboard Toggle word wrap
      注記

      net.nf_conntrack_max のデフォルト値は 500000 接続です。最大値は 4294967295 です。

  5. コア heat テンプレート、環境ファイル、およびこの新しいカスタム環境ファイルを指定して、deployment コマンドを実行します。

    重要

    後で実行される環境ファイルで定義されているパラメーターとリソースが優先されることになるため、環境ファイルの順序は重要となります。

    $ openstack overcloud deploy --templates \
    -e /home/stack/templates/custom-environment.yaml
    Copy to Clipboard Toggle word wrap

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

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

8.2.4.1. オーバークラウドノードのネットワークインターフェイスボンディング

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

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

Expand
表8.7 サポート対象のインターフェイスボンディングの種別
ボンディング種別種別の値許可されるブリッジ種別許可されるメンバー

OVS カーネルボンディング

ovs_bond

ovs_bridge

interface

OVS-DPDK ボンディング

ovs_dpdk_bond

ovs_user_bridge

ovs_dpdk_port

Linux カーネルボンディング

linux_bond

ovs_bridge または linux_bridge

interface

重要

ovs_bridgeovs_user_bridge を同じノード上で組み合わせないでください。

8.2.4.2. Open vSwitch (OVS) ボンディングの作成

ネットワークインターフェイステンプレートで OVS ボンディングを作成します。たとえば、OVS ユーザースペースブリッジの一部としてボンディングを作成できます。

- type: ovs_user_bridge
  name: br-dpdk0
  members:
  - type: ovs_dpdk_bond
    name: dpdkbond0
    rx_queue: {{ num_dpdk_interface_rx_queues }}
    members:
    - type: ovs_dpdk_port
      name: dpdk0
      members:
      - type: interface
        name: nic4
    - type: ovs_dpdk_port
      name: dpdk1
      members:
      - type: interface
        name: nic5
Copy to Clipboard Toggle word wrap

以下の例では、2 つの DPDK ポートからボンディングを作成します。

ovs_options パラメーターには、ボンディングオプションが含まれます。ネットワーク環境ファイルの BondInterfaceOvsOptions パラメーターを使用して、ボンディングオプションを設定することができます。

parameter_defaults:
  BondInterfaceOvsOptions: "bond_mode=active-backup"
Copy to Clipboard Toggle word wrap

8.2.4.3. Open vSwitch (OVS) 結合オプション

NIC テンプレートファイルの ovs_options heat パラメーターを使用して、さまざまな Open vSwitch (OVS) ボンディングオプションを設定することができます。active-backup、balance-tlb、balance-alb、balance-slb モードは、スイッチの特定の設定を必要としません。

bond_mode=balance-slb
送信元負荷分散 (slb) は、送信元 MAC アドレスと出力 VLAN に基づいてフローのバランスを取り、トラフィックパターンの変化に応じて定期的に再調整します。balance-slb ボンディングオプションを使用して結合を設定する場合は、リモートスイッチで必要な設定はありません。Networking サービス (neutron) は、ソース MAC と VLAN の各ペアをリンクに割り当て、その MAC と VLAN からのすべてのパケットをそのリンクを介して送信します。トラフィックパターンの変化に応じて定期的にリバランスを行う、送信元 MAC アドレスと VLAN の番号に基づいた簡単なハッシュアルゴリズム。balance-slb モードは、Linux ボンディングドライバーで使用されるモード 2 ボンドに似ていますが、モード 2 とは異なり、balance-slb はスイスコードの特定の設定を必要としません。balance-slb モードを使用すると、スイッチが LACP を使用するように設定されていない場合でも、負荷分散を提供できます。
bond_mode=active-backup
active-backup ボンドモードを使用してボンドを設定すると、Networking サービスは 1 つの NIC をスタンバイ状態に保ちます。アクティブな接続に障害が発生すると、スタンバイ 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
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 を使用する場合には、ハートビートの間隔をミリ秒単位で設定します。
bond_updelay=1000
フラッピングを防止するためにリンクがアクティブになっている必要がある間隔 (ミリ秒) を設定します。
other_config:bond-rebalance-interval=10000
ボンドメンバー間でフローがリバランスする間隔 (ミリ秒) を設定します。この値をゼロに設定すると、ボンドメンバー間のフローのリバランスが無効になります。

8.2.4.5. Linux ボンディングの作成

ネットワークインターフェイステンプレートで linux ボンディングを作成します。たとえば、2 つのインターフェイスをボンディングする linux ボンディングを作成することができます。

- type: linux_bond
  name: bond_api
  mtu: {{ min_viable_mtu_ctlplane }}
  use_dhcp: false
  bonding_options: {{ bond_interface_ovs_options }}
  dns_servers: {{ ctlplane_dns_nameservers }}
  domain: {{ dns_search_domains }}
  members:
  - type: interface
    name: nic2
    mtu: {{ min_viable_mtu_ctlplane }}
    primary: true
  - type: interface
    name: nic3
    mtu: {{ min_viable_mtu_ctlplane }}
Copy to Clipboard Toggle word wrap

bonding_options パラメーターは、Linux ボンディング用の特定のボンディングオプションを設定します。

mode
ボンディングモードを設定します。この例では、802.3ad モードまたは LACP モードです。Linux ボンディングモードの詳細は、Red Hat Enterprise Linux 9 ネットワークの設定と管理ガイドの ボンディングモードに応じたアップストリームの切り替え設定 を参照してください。
lacp_rate
LACP パケットの送信間隔を 1 秒または 30 秒に定義します。
updelay
インターフェイスをトラフィックに使用する前にそのインターフェイスがアクティブである必要のある最低限の時間を定義します。この最小設定は、ポートフラッピングによる停止を軽減するのに役立ちます。
miimon
ドライバーの MIIMON 機能を使用してポートの状態を監視する間隔 (ミリ秒単位)

以下の追加の例をガイドとして使用し、独自の Linux ボンディングを設定します。

  • 1 つの VLAN を持つ active-backup モードに設定された Linux ボンディング

    ....
    
    - type: linux_bond
      name: bond_api
      mtu: {{ min_viable_mtu_ctlplane }}
      use_dhcp: false
      bonding_options: "mode=active-backup"
      dns_servers: {{ ctlplane_dns_nameservers }}
      domain: {{ dns_search_domains }}
      members:
      - type: interface
        name: nic2
        mtu: {{ min_viable_mtu_ctlplane }}
        primary: true
      - type: interface
        name: nic3
        mtu: {{ min_viable_mtu_ctlplane }}
      - type: vlan
        mtu: {{ internal_api_mtu }}
        vlan_id: {{ internal_api_vlan_id }}
        addresses:
        - ip_netmask:
            {{ internal_api_ip }}/{{ internal_api_cidr }}
          routes:
            {{ internal_api_host_routes }}
    Copy to Clipboard Toggle word wrap
  • OVS ブリッジ上の Linux ボンディング。1 つの VLAN を持つ 802.3ad LACP モードに設定されたボンディング

    - type: linux_bond
      name: bond_tenant
      mtu: {{ min_viable_mtu_ctlplane }}
      bonding_options: "mode=802.3ad updelay=1000 miimon=100"
      use_dhcp: false
      dns_servers: {{ ctlplane_dns_nameserver }}
      domain: {{ dns_search_domains }}
      members:
        - type: interface
          name: p1p1
          mtu: {{ min_viable_mtu_ctlplane }}
        - type: interface
          name: p1p2
          mtu: {{ min_viable_mtu_ctlplane }}
        - type: vlan
          mtu: {{ tenant_mtu }}
          vlan_id: {{ tenant_vlan_id }}
          addresses:
            - ip_netmask:
               {{ tenant_ip }}/{{ tenant_cidr }}
          routes:
            {{ tenant_host_routes }}
    Copy to Clipboard Toggle word wrap
    重要

    min_viable_mtu_ctlplane を使用する前に、設定する必要があります。/usr/share/ansible/roles/tripleo_network_config/templates/2_linux_bonds_vlans.j2 をテンプレートディレクトリーにコピーし、必要に応じて変更します。詳細は、コンポーザブルネットワーク を参照し、ネットワーク設定テンプレートに関連する手順を参照してください。

8.2.5. ネットワーク設定ファイルのフォーマットの更新

Red Hat OpenStack Platform (RHOSP) 17.0 では、ネットワーク設定の yaml ファイルの形式が変更されました。ネットワーク設定ファイル network_data.yaml の構造が変更され、NIC テンプレートファイルの形式が yaml ファイル形式から Jinja2 ansible 形式の j2 に変更されました。

次の変換ツールを使用して、現在の展開の既存のネットワーク設定ファイルを RHOSP 17+ 形式に変換できます。

  • convert_v1_net_data.py
  • convert_heat_nic_config_to_ansible_j2.py

既存の NIC テンプレートファイルを手動で変換することもできます。

変換する必要があるファイルは次のとおりです。

  • network_data.yaml
  • コントローラー NIC テンプレート
  • コンピュート NIC テンプレート
  • その他のカスタムネットワークファイル

8.2.5.1. ネットワーク設定ファイルのフォーマットの更新

Red Hat OpenStack Platform (RHOSP) 17.0 では、ネットワーク設定 yaml ファイルの形式が変更されました。convert_v1_net_data.py 変換ツールを使用して、現在のデプロイメントの既存のネットワーク設定ファイルを RHOSP 17+ 形式に変換できます。

手順

  1. 変換ツールをダウンロードします。

    • /usr/share/openstack-tripleo-heat-templates/tools/convert_v1_net_data.py
  2. RHOSP 16+ ネットワーク設定ファイルを RHOSP 17+ 形式に変換します。

    $ python3 convert_v1_net_data.py <network_config>.yaml
    Copy to Clipboard Toggle word wrap
    • <network_config> は、変換する既存の設定ファイルの名前 (network_data.yaml など) に置き換えます。

8.2.5.2. NIC テンプレートの Jinja2 Ansible 形式への自動変換

Red Hat OpenStack Platform (RHOSP) 17.0 では、NIC テンプレートのファイル形式が yaml ファイル形式から Jinja2 Ansible 形式の j2 に変更されました。

convert_heat_nic_config_to_ansible_j2.py 変換ツールを使用して、現在のデプロイの既存の NIC テンプレートファイルを Jinja2 形式に変換できます。

既存の NIC テンプレートファイルを手動で変換することもできます。詳細は、NIC テンプレートの Jinja2 Ansible 形式への手動変換 を参照してください。

変換する必要があるファイルは次のとおりです。

  • コントローラー NIC テンプレート
  • コンピュート NIC テンプレート
  • その他のカスタムネットワークファイル

手順

  1. アンダークラウドに stack ユーザーとしてログインします。
  2. stackrc ファイルを取得します。

    [stack@director ~]$ source ~/stackrc
    Copy to Clipboard Toggle word wrap
  3. 変換ツールをアンダークラウドの現在のディレクトリーにコピーします。

    $ cp /usr/share/openstack-tripleo-heat-templates/tools/convert_heat_nic_config_to_ansible_j2.py .
    Copy to Clipboard Toggle word wrap
  4. コンピュートとコントローラーの NIC テンプレートファイル、およびその他のカスタムネットワークファイルを Jinja2 Ansible 形式に変換します。

    $ python3 convert_heat_nic_config_to_ansible_j2.py \
     [--stack <overcloud> | --standalone] --networks_file <network_config.yaml> \
     <network_template>.yaml
    Copy to Clipboard Toggle word wrap
    • <overcloud> は、オーバークラウドスタックの名前または UUID に置き換えてください。--stack が指定されていない場合、スタックはデフォルトで overcloud になります。

      注記

      --stack オプションは、アンダークラウドノードでオーケストレーションサービス (heat) を実行する必要があるため、RHOSP 16 デプロイメントでのみ使用できます。RHOSP 17 以降、RHOSP デプロイメントは、コンテナー内でオーケストレーションサービスを実行する一時的な Heat を使用します。オーケストレーションサービスが利用できない場合、またはスタックがない場合は、--stack の代わりに --standalone オプションを使用します。

    • <network_config.yaml> は、ネットワークデプロイを記述する設定ファイルの名前 (network_data.yaml など) に置き換えます。
    • <network_template> は、変換するネットワーク設定ファイルの名前に置き換えます。

    すべてのカスタムネットワーク設定ファイルを変換するまで、このコマンドを繰り返します。convert_heat_nic_config_to_ansible_j2.py スクリプトは、変換用に渡す yaml ごとに .j2 ファイルを生成します。

  5. 生成された各 .j2 ファイルを検査して、設定が環境に対して正しく、また完全であることを確認します。次に、手動で、変換できなかった設定を強調表示するツールが生成したコメントに、手動で対応します。NIC 設定を Jinja2 形式に手動で変換する方法は、Heat パラメーターから Ansible 変数へのマッピング を参照してください。
  6. 生成された .j2 ファイルを指すように、network-environment.yaml ファイルの *NetworkConfigTemplate パラメーターを設定します。

    parameter_defaults:
      ControllerNetworkConfigTemplate: '/home/stack/templates/custom-nics/controller.j2'
      ComputeNetworkConfigTemplate: '/home/stack/templates/custom-nics/compute.j2'
    Copy to Clipboard Toggle word wrap
  7. 古いネットワーク設定ファイルの network-environment.yaml ファイルから resource_registry マッピングを削除します。

    resource_registry:
      OS::TripleO::Compute::Net::SoftwareConfig: /home/stack/templates/nic-configs/compute.yaml
      OS::TripleO::Controller::Net::SoftwareConfig: /home/stack/templates/nic-configs/controller.yaml
    Copy to Clipboard Toggle word wrap

8.2.5.3. NIC テンプレートの Jinja2 Ansible 形式への手動変換

Red Hat OpenStack Platform (RHOSP) 17.0 では、NIC テンプレートのファイル形式が yaml ファイル形式から Jinja2 Ansible 形式の j2 に変更されました。

既存の NIC テンプレートファイルを手動で変換できます。

convert_heat_nic_config_to_ansible_j2.py 変換ツールを使用して、現在のデプロイの既存の NIC テンプレートファイルを Jinja2 形式に変換することもできます。詳細は、NIC テンプレートの Jinja2 ansible 形式への自動変換 を参照してください。

変換する必要があるファイルは次のとおりです。

  • コントローラー NIC テンプレート
  • コンピュート NIC テンプレート
  • その他のカスタムネットワークファイル

手順

  1. Jinja2 テンプレートを作成します。アンダークラウドノードの /usr/share/ansible/roles/tripleo_network_config/templates/ ディレクトリーからサンプルテンプレートをコピーして、新しいテンプレートを作成できます。
  2. Heat 固有の関数は、Jinja2 フィルターに置き換えます。たとえば、次のフィルターを使用して min_viable_mtu を計算します。

    {% set mtu_list = [ctlplane_mtu] %}
    {% for network in role_networks %}
    {{ mtu_list.append(lookup('vars', networks_lower[network] ~ '_mtu')) }}
    {%- endfor %}
    {% set min_viable_mtu = mtu_list | max %}
    Copy to Clipboard Toggle word wrap
  3. Ansible 変数を使用して、デプロイメントのネットワークプロパティーを設定します。個々のネットワークを手動で設定するか、role_networks を反復して各ネットワークをプログラムで設定できます。

    • 各ネットワークを手動で設定するには、各 get_param 関数を同等の Ansible 変数に置き換えます。たとえば、現在のデプロイで get_param: InternalApiNetworkVlanID を使用して vlan_id を設定している場合は、次の設定をテンプレートに追加します。

      vlan_id: {{ internal_api_vlan_id }}
      Copy to Clipboard Toggle word wrap
      Expand
      表8.9 heat パラメーターから Ansible vars へのネットワークプロパティーマッピングの例
      yaml ファイル形式Jinja2 ansible 形式、j2
      - type: vlan
        device: nic2
        vlan_id:
          get_param: InternalApiNetworkVlanID
        addresses:
        - ip_netmask:
            get_param: InternalApiIpSubnet
      Copy to Clipboard Toggle word wrap
      - type: vlan
        device: nic2
        vlan_id: {{ internal_api_vlan_id }}
        addresses:
        - ip_netmask: {{ internal_api_ip }}/{{ internal_api_cidr }}
      Copy to Clipboard Toggle word wrap
    • 各ネットワークをプログラムで設定するには、role_networks を使用してロール名で使用可能なネットワークを取得するテンプレートに、Jinja2 for-loop 構造を追加します。

      {% for network in role_networks %}
        - type: vlan
          mtu: {{ lookup('vars', networks_lower[network] ~ '_mtu') }}
          vlan_id: {{ lookup('vars', networks_lower[network] ~ '_vlan_id') }}
          addresses:
          - ip_netmask: {{ lookup('vars', networks_lower[network] ~ '_ip') }}/{{ lookup('vars', networks_lower[network] ~ '_cidr') }}
          routes: {{ lookup('vars', networks_lower[network] ~ '_host_routes') }}
      {%- endfor %}
      Copy to Clipboard Toggle word wrap

    heat パラメーターから同等の Ansible vars へのマッピングをすべて記載したリストについては、Heat パラメーターから Ansible 変数へのマッピング を参照してください。

  4. 生成された .j2 ファイルを指すように、network-environment.yaml ファイルの *NetworkConfigTemplate パラメーターを設定します。

    parameter_defaults:
      ControllerNetworkConfigTemplate: '/home/stack/templates/custom-nics/controller.j2'
      ComputeNetworkConfigTemplate: '/home/stack/templates/custom-nics/compute.j2'
    Copy to Clipboard Toggle word wrap
  5. 古いネットワーク設定ファイルの network-environment.yaml ファイルから resource_registry マッピングを削除します。

    resource_registry:
      OS::TripleO::Compute::Net::SoftwareConfig: /home/stack/templates/nic-configs/compute.yaml
      OS::TripleO::Controller::Net::SoftwareConfig: /home/stack/templates/nic-configs/controller.yaml
    Copy to Clipboard Toggle word wrap

8.2.5.4. Heat パラメーターから Ansible 変数へのマッピング

Red Hat OpenStack Platform (RHOSP) 17.x では、NIC テンプレートのファイル形式が yaml ファイル形式から Jinja2 ansible 形式 j2 に変更されました。

既存の NIC テンプレートファイルを手動で Jinja2 ansible 形式に変換するには、heat パラメーターを Ansible 変数にマッピングして、デプロイメントで事前にプロビジョニングされたノードのネットワークプロパティーを設定します。--network-config オプションの引数を指定せずに openstack overcloud node provision を実行すると、heat パラメーターを Ansible 変数にマップすることもできます。

たとえば、現在のデプロイで get_param: InternalApiNetworkVlanID を使用して vlan_id を設定している場合は、新しい Jinja2 テンプレートで次の設定に置き換えます。

vlan_id: {{ internal_api_vlan_id }}
Copy to Clipboard Toggle word wrap
注記

--network-config オプションの引数を指定し、openstack overcloud node provision を実行してノードをプロビジョニングする場合は、overcloud-baremetal-deploy.yaml のパラメーターを使用して、デプロイ用のネットワークプロパティーを設定する必要があります。詳細は、定義ファイルマッピングをプロビジョニングする heat パラメーター を参照してください。

次の表は、heat パラメーターから同等の Ansible vars へのマッピングで利用できるものを一覧にしています。

Expand
表8.10 heat パラメーターから Ansible vars へのマッピング
Heat パラメーターAnsible vars

BondInterfaceOvsOptions

{{ bond_interface_ovs_options }}

ControlPlaneIp

{{ ctlplane_ip }}

ControlPlaneDefaultRoute

{{ ctlplane_gateway_ip }}

ControlPlaneMtu

{{ ctlplane_mtu }}

ControlPlaneStaticRoutes

{{ ctlplane_host_routes }}

ControlPlaneSubnetCidr

{{ ctlplane_subnet_cidr }}

DnsSearchDomains

{{ dns_search_domains }}

DnsServers

{{ ctlplane_dns_nameservers }}

注記

この Ansible 変数には、DEFAULT/undercloud_nameservers および %SUBNET_SECTION%/dns_nameserversundercloud.conf で設定された IP アドレスが入力されます。%SUBNET_SECTION%/dns_nameservers の設定は、DEFAULT/undercloud_nameservers の設定をオーバーライド。これにより、アンダークラウドおよびオーバークラウドに異なる DNS サーバーを使用し、異なるプロビジョニングサブネットのノードに異なる DNS サーバーを使用することができます。

NumDpdkInterfaceRxQueues

{{ num_dpdk_interface_rx_queues }}

表に記載されていない Heat パラメーターの設定

表に記載されていない heat パラメーターを設定するには、パラメーターを {{role.name}}ExtraGroupVars として設定する必要があります。このパラメーターを {{role.name}}ExtraGroupVars パラメーターとして設定しないと、新しいテンプレートで使用できません。たとえば、StorageSupernet パラメーターを設定するには、次の設定をネットワーク設定ファイルに追加します。

parameter_defaults:
  ControllerExtraGroupVars:
    storage_supernet: 172.16.0.0/16
Copy to Clipboard Toggle word wrap

その後、{{ storage_supernet }} を Jinja2 テンプレートに追加できます。

警告

ノードのプロビジョニングで --network-config オプションが使用されている場合には、このプロセスは機能しません。カスタム変数を必要とするユーザーは、--network-config オプションを使用しないでください。代わりに、Heat スタックの作成後に、ノードのネットワーク設定を config-download ansible 実行に適用します。

Ansible 変数構文を変換することによる各ネットワークのプログラム設定

Jinja2 の for ループ構造を使用して、role_networks を反復処理すし、利用可能なネットワークをロール名で取得する場合には、各ネットワークロールの小文字の名前を取得して、各プロパティーの先頭に追加する必要があります。次の構造を使用して、上記の表の Ansible vars を必要な構文に変換します。

{{ lookup(‘vars’, networks_lower[network] ~ ‘_<property>’) }}

  • <property> は、設定するプロパティー (ipvlan_id、または mtu など) に置き換えます。

たとえば、各 NetworkVlanID の値を動的に入力するには、{{ <network_name>_vlan_id }} を次の設定に置き換えます。

{{ lookup(‘vars’, networks_lower[network] ~ ‘_vlan_id’) }}`
Copy to Clipboard Toggle word wrap

8.2.5.5. 定義ファイルマッピングをプロビジョニングする heat パラメーター

openstack overcloud node provision コマンドに --network-config オプションの引数を指定して実行し、ノードをプロビジョニングする場合、ノード定義ファイル overcloud-baremetal-deploy.yaml のパラメーターを使用して、デプロイメントのネットワークプロパティーを設定する必要があります。

デプロイメントで事前にプロビジョニングされたノードを使用する場合は、heat パラメーターを Ansible 変数にマッピングして、ネットワーク属性を設定します。--network-config オプションの引数を指定せずに openstack overcloud node provision を実行すると、heat パラメーターを Ansible 変数にマップすることもできます。Ansible 変数を使用したネットワークプロパティーの設定に関する詳細は、Heat パラメーターから Ansible 変数へのマッピング を参照してください。

以下の表には、heat パラメーターからノード定義ファイル overcloud-baremetal-deploy.yaml に相当する network_config プロパティーへの利用可能なマッピングをまとめています。

Expand
表8.11 heat パラメーターからノード定義ファイル overcloud-baremetal-deploy.yaml へのマッピング
heat パラメーターnetwork_config プロパティー

BondInterfaceOvsOptions

bond_interface_ovs_options

DnsSearchDomains

dns_search_domains

NetConfigDataLookup

net_config_data_lookup

NeutronPhysicalBridge

physical_bridge_name

NeutronPublicInterface

public_interface_name

NumDpdkInterfaceRxQueues

num_dpdk_interface_rx_queues

{{role.name}}NetworkConfigUpdate

network_config_update

以下の表では、heat パラメーターからネットワーク定義ファイル network_data.yaml に相当するプロパティーへの利用可能なマッピングをまとめています。

Expand
表8.12 heat パラメーターからネットワーク定義ファイル network_data.yamlへのマッピング
heat パラメーターIPv4 network_data.yaml プロパティーIPv6 network_data.yaml プロパティー

<network_name>IpSubnet

- name: <network_name>
  subnets:
    subnet01:
      ip_subnet: 172.16.1.0/24
Copy to Clipboard Toggle word wrap
- name: <network_name>
  subnets:
    subnet01:
      ipv6_subnet: 2001:db8:a::/64
Copy to Clipboard Toggle word wrap

<network_name>NetworkVlanID

- name: <network_name>
  subnets:
    subnet01:
      ...
      vlan: <vlan_id>
Copy to Clipboard Toggle word wrap
- name: <network_name>
  subnets:
    subnet01:
      ...
      vlan: <vlan_id>
Copy to Clipboard Toggle word wrap

<network_name>Mtu

- name: <network_name>
  mtu:
Copy to Clipboard Toggle word wrap
- name: <network_name>
  mtu:
Copy to Clipboard Toggle word wrap

<network_name>InterfaceDefaultRoute

- name: <network_name>
  subnets:
    subnet01:
      ip_subnet: 172.16.16.0/24
      gateway_ip: 172.16.16.1
Copy to Clipboard Toggle word wrap
- name: <network_name>
  subnets:
    subnet01:
      ipv6_subnet: 2001:db8:a::/64
      gateway_ipv6: 2001:db8:a::1
Copy to Clipboard Toggle word wrap

<network_name>InterfaceRoutes

- name: <network_name>
  subnets:
    subnet01:
      ...
      routes:
        - destination: 172.18.0.0/24
          nexthop: 172.18.1.254
Copy to Clipboard Toggle word wrap
- name: <network_name>
  subnets:
    subnet01:
      ...
      routes_ipv6:
        - destination: 2001:db8:b::/64
          nexthop: 2001:db8:a::1
Copy to Clipboard Toggle word wrap

8.2.5.6. ネットワークデータスキーマの変更

ネットワークデータスキーマは、Red Hat OpenStack Platform (RHOSP) 17 で更新されました。RHOSP 16 以前で使用されていたネットワークデータスキーマと、RHOSP 17 以降で使用されていたネットワークデータスキーマの主な違いは次のとおりです。

  • ベースサブネットは、サブネット マップに移動されました。これにより、スパインリーフネットワーキングなど、ルーティングされないデプロイメントとルーティングされるデプロイメントの設定が調整されます。
  • 無効なネットワークを無視するために、enabled オプションが使用されなくなりました。代わりに、設定ファイルから無効なネットワークを削除する必要があります。
  • compat_name オプションは、このオプションを使用していた heat リソースが削除されたため、不要になりました。
  • ip_subnetgateway_ipallocation_poolsroutesipv6_subnetgateway_ipv6ipv6_allocation_pools、および routes_ipv6 のパラメーターは、ネットワークレベルでは無効になりました。これらのパラメーターは、サブネットレベルで引き続き使用されます。
  • metalsmith で Ironic ポートを作成するために使用される新しいパラメーター physical_network が導入されました。
  • 新しいパラメーター network_type および segmentation_id は、ネットワークタイプを vlan に設定するために使用される {{network.name}}NetValueSpecs の後継となります。
  • 次のパラメーターは、RHOSP 17 で非推奨になりました。

    • {{network.name}}NetCidr
    • {{network.name}}SubnetName
    • {{network.name}}Network
    • {{network.name}}AllocationPools
    • {{network.name}}Routes
    • {{network.name}}SubnetCidr_{{subnet}}
    • {{network.name}}AllocationPools_{{subnet}}
    • {{network.name}}Routes_{{subnet}}
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。 最新の更新を見る.

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

Theme

© 2025 Red Hat