8.2. オーバークラウドネットワークのカスタマイズ
オーバークラウドの物理ネットワークの設定をカスタマイズできます。たとえば、Jinja2 ansible 形式 (j2) の NIC テンプレートファイルを使用して、ネットワークインターフェイスコントローラー (NIC) の設定ファイルを作成できます。
8.2.1. カスタムネットワークインターフェイステンプレートの定義 リンクのコピーリンクがクリップボードにコピーされました!
カスタムネットワークインターフェイステンプレートのセットを作成して、オーバークラウド環境の各ノードの NIC レイアウトを定義できます。オーバークラウドのコアテンプレートコレクションには、さまざまなユースケース向けのデフォルトの NIC レイアウトのセットが含まれています。拡張子が .j2.yaml の Jinja2 形式のファイルを使用して、カスタム NIC テンプレートを作成できます。director は、デプロイメント中に Jinja2 ファイルを YAML 形式に変換します。
その後、ノード定義ファイル overcloud-baremetal-deploy.yaml の network_config プロパティーをカスタム NIC テンプレートに設定して、特定のノードのネットワークをプロビジョニングできます。詳細は、オーバークラウド用のベアメタルノードのプロビジョニング を参照してください。
8.2.1.1. カスタム NIC テンプレートの作成 リンクのコピーリンクがクリップボードにコピーされました!
オーバークラウド環境の各ノードの NIC レイアウトをカスタマイズするための NIC テンプレートを作成します。
手順
必要なサンプルネットワーク設定テンプレートを
/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>
$ cp /usr/share/ansible/roles/tripleo_network_config/templates/<sample_NIC_template> /home/stack/templates/<NIC_template>Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
<sample_NIC_template>は、コピーするサンプル NIC テンプレートの名前 (single_nic_vlans/single_nic_vlans.j2など) に置き換えます。 -
<NIC_template>は、カスタム NIC テンプレートファイルの名前 (例:single_nic_vlans.j2)に置き換えます。
-
- オーバークラウドのネットワーク環境の要件に合わせて、カスタム NIC テンプレートのネットワーク設定を更新します。NIC テンプレートの設定に使用できるプロパティーについては、ネットワークインターフェイス設定オプション を参照してください。NIC テンプレートの例は、カスタムネットワークインターフェイスの例 を参照してください。
既存の環境ファイルを作成または更新して、カスタム 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'
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 Copied! Toggle word wrap Toggle overflow オーバークラウドがデフォルトの内部負荷分散を使用する場合は、以下の設定を環境ファイルに追加して、Redis および OVNDB に予測可能な仮想 IP を割り当てます。
parameter_defaults: RedisVirtualFixedIPs: [{'ip_address':'<vip_address>'}] OVNDBsVirtualFixedIPs: [{'ip_address':'<vip_address>'}]parameter_defaults: RedisVirtualFixedIPs: [{'ip_address':'<vip_address>'}] OVNDBsVirtualFixedIPs: [{'ip_address':'<vip_address>'}]Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
<vip_address>は、割り当てプール範囲外の IP アドレスに置き換えます。
-
8.2.1.2. ネットワークインターフェイスの設定オプション リンクのコピーリンクがクリップボードにコピーされました!
次の表では、ネットワークインターフェイスの設定に使用できるオプションを説明しています。
interface
単一のネットワークインターフェイスを定義します。ネットワークインターフェイスの name には、実際のインターフェイス名 (eth0、eth1、enp0s25) または一連の番号付きインターフェイス (nic1、nic2、nic3) が使用されます。eth0 や eno2 などの名前付きインターフェイスではなく、nic1 や nic2 などの番号付きインターフェイスを使用する場合、ロール内のホストのネットワークインターフェイスがまったく同じである必要はありません。たとえば、あるホストに em1 と em2 のインターフェイスが指定されており、別のホストには eno1 と eno2 が指定されていても、両ホストの NIC は nic1 および nic2 として参照することができます。
番号付きのインターフェイスの順序は、名前付きのネットワークインターフェイスのタイプの順序と同じです。
-
eth0、eth1などのethX。これらは、通常オンボードのインターフェイスです。 -
eno0、eno1などのenoX。これらは、通常オンボードのインターフェイスです。 -
enp3s0、enp3s1、ens3などの英数字順のenXインターフェイス。これらは、通常アドオンのインターフェイスです。
番号による NIC スキームには、アクティブなインターフェイスだけが含まれます (たとえば、インターフェイスにスイッチに接続されたケーブルがあるかどうかが考慮されます)。4 つのインターフェイスを持つホストと、6 つのインターフェイスを持つホストがある場合は、nic1 から nic4 を使用して各ホストで 4 本のケーブルだけを結線します。
- type: interface
name: nic2
- type: interface
name: nic2
| オプション | デフォルト | 説明 |
|---|---|---|
|
|
インターフェイスの名前。ネットワークインターフェイスの | |
|
| False | DHCP を使用して IP アドレスを取得します。 |
|
| False | DHCP を使用して v6 の IP アドレスを取得します。 |
|
| インターフェイスに割り当てられる IP アドレスのリスト | |
|
| インターフェイスに割り当てられるルートのリスト。詳細は、routes を参照してください。 | |
|
| 1500 | 接続の最大伝送単位 (MTU: Maximum Transmission Unit) |
|
| False | プライマリーインターフェイスとしてインターフェイスを定義します。 |
|
| False | システム名の代わりにデバイスのエイリアス設定を記述します。 |
|
| None | DHCP クライアントに渡す引数 |
|
| None | インターフェイスに使用する DNS サーバーのリスト |
|
|
特定の NIC で VXLAN を使用する際にスループットを向上させるには、このオプションを |
vlan
VLAN を定義します。parameters セクションから渡された VLAN ID およびサブネットを使用します。
以下に例を示します。
| オプション | デフォルト | 説明 |
|---|---|---|
| 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 で、複数の インターフェイス を結合するボンディングを定義します。これにより、冗長性や帯域幅が向上します。
以下に例を示します。
| オプション | デフォルト | 説明 |
|---|---|---|
| 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 サービスにより提供されるデフォルトのルートを使用します。 |
| persist_mapping | False | システム名の代わりにデバイスのエイリアス設定を記述します。 |
| dhclient_args | なし | DHCP クライアントに渡す引数 |
| dns_servers | なし | ボンディングに使用する DNS サーバーのリスト |
ovs_bridge
Open vSwitch で、複数の interface、ovs_bond、vlan オブジェクトを接続するブリッジを定義します。
ネットワークインターフェイス種別 ovs_bridge には、パラメーター name を使用します。
複数のブリッジがある場合は、デフォルト名の bridge_name を受け入れるのではなく、個別のブリッジ名を使用する必要があります。個別の名前を使用しないと、コンバージフェーズ時に 2 つのネットワークボンディングが同じブリッジに配置されます。
外部の tripleo ネットワークに OVS ブリッジを定義している場合は、bridge_name および interface_name の値を維持します。デプロイメントフレームワークが、これらの値を自動的にそれぞれ外部ブリッジ名および外部インターフェイス名に置き換えるためです。
以下に例を示します。
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 が必要となります。
| オプション | デフォルト | 説明 |
|---|---|---|
| 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 サービスにより提供されるデフォルトのルートを使用します。 |
| persist_mapping | False | システム名の代わりにデバイスのエイリアス設定を記述します。 |
| dhclient_args | なし | DHCP クライアントに渡す引数 |
| dns_servers | なし | ブリッジに使用する DNS サーバーのリスト |
linux_bond
複数の インターフェイス を結合する Linux ボンディングを定義します。これにより、冗長性や帯域幅が向上します。bonding_options パラメーターには、カーネルベースのボンディングオプションを指定するようにしてください。
以下に例を示します。
| オプション | デフォルト | 説明 |
|---|---|---|
| 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 サービスにより提供されるデフォルトのルートを使用します。 |
| persist_mapping | False | システム名の代わりにデバイスのエイリアス設定を記述します。 |
| dhclient_args | なし | DHCP クライアントに渡す引数 |
| dns_servers | なし | ボンディングに使用する DNS サーバーのリスト |
linux_bridge
複数の interface、linux_bond、vlan オブジェクトを接続する Linux ブリッジを定義します。外部のブリッジは、パラメーターに 2 つの特殊な値も使用します。
-
bridge_name: 外部ブリッジ名に置き換えます。 -
interface_name: 外部インターフェイスに置き換えます。
以下に例を示します。
| オプション | デフォルト | 説明 |
|---|---|---|
| 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 サービスにより提供されるデフォルトのルートを使用します。 |
| persist_mapping | False | システム名の代わりにデバイスのエイリアス設定を記述します。 |
| dhclient_args | なし | DHCP クライアントに渡す引数 |
| dns_servers | なし | ブリッジに使用する DNS サーバーのリスト |
routes
ネットワークインターフェイス、VLAN、ブリッジ、またはボンディングに適用するルートのリストを定義します。
以下に例を示します。
- type: linux_bridge
name: bridge_name
...
routes: {{ [ctlplane_host_routes] | flatten | unique }}
- type: linux_bridge
name: bridge_name
...
routes: {{ [ctlplane_host_routes] | flatten | unique }}
| オプション | デフォルト | 説明 |
|---|---|---|
| ip_netmask | なし | 接続先ネットワークの IP およびネットマスク |
| default | False |
このルートをデフォルトルートに設定します。 |
| next_hop | なし | 接続先ネットワークに到達するのに使用するルーターの IP アドレス |
8.2.1.3. カスタムネットワークインターフェイスの例 リンクのコピーリンクがクリップボードにコピーされました!
次の例は、ネットワークインターフェイステンプレートをカスタマイズする方法を示しています。
制御グループと OVS ブリッジを分離する例
以下に示すコントローラーノードの NIC テンプレートの例では、OVS ブリッジとは別に制御グループを設定します。このテンプレートは、5 つのネットワークインターフェイスを使用し、タグ付けされた複数の VLAN デバイスを、番号によるインターフェイスに割り当てます。テンプレートは、nic4 および nic5 に OVS ブリッジを作成します。
複数の NIC の例
次の例では、2 番目の NIC を使用して、DHCP アドレスを持つインフラストラクチャーネットワークに接続し、ボンド用に別の NIC を使用します。
8.2.1.4. 事前にプロビジョニングされたノードの NIC マッピングのカスタマイズ リンクのコピーリンクがクリップボードにコピーされました!
事前にプロビジョニングされたノードを使用している場合は、次のいずれかの方法を使用して、特定のノードの os-net-config マッピングを指定できます。
-
環境ファイルで
NetConfigDataLookupheat パラメーターを設定し、--network-configを指定せずにopenstack overcloud node provisionコマンドを実行します。 -
ノード定義ファイル
overcloud-baremetal-deploy.yamlでnet_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.yaml で NetConfigDataLookup パラメーターを設定する
- 1
- 指定の MAC アドレスに
node1をマップし、このノードの MAC アドレスのエイリアスとしてnic1を割り当てます。 - 2
node3をシステム UUID "A8C85861-1B16-4803-8689-AFC62984F8F6" を持つノードにマップし、このノード上のem3インターフェイスのエイリアスとしてnic1を割り当てます。- 3
dmiStringパラメーターは有効な文字列キーワードに設定する必要があります。有効な文字列キーワードのリストは、DMIDECODE(8) のマニュアルページを参照してください。- 4
nodegroup1内のすべてのノードを製品名 "PowerEdge R630" のノードにマップし、これらのノード上の名前付きインターフェイスのエイリアスとしてnic1、nic2、およびnic3を割り当てます。
通常、os-net-config はすでに接続済みの UP 状態のインターフェイスしか登録しません。ただし、カスタムマッピングファイルを使用してインターフェイスをハードコーディングすると、DOWN 状態のインターフェイスであっても登録されます。
例 2: overcloud-baremetal-deploy.yaml で net_config_data_lookup プロパティーを設定する (特定のノード)
例 3: overcloud-baremetal-deploy.yaml で net_config_data_lookup プロパティーを設定する (ロールの全ノード)
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. コンポーザブルネットワークの追加 リンクのコピーリンクがクリップボードにコピーされました!
コンポーザブルネットワークを使用して、さまざまなサービス用のネットワークを追加します。たとえば、ストレージバックアップトラフィック専用のネットワークがある場合には、ネットワークを複数のロールに提供できます。
手順
利用可能なサンプルネットワーク設定ファイルをリストします。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow 必要なサンプルネットワーク設定ファイルを
/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
$ cp /usr/share/openstack-tripleo-heat-templates/network-data-samples/default-network-isolation.yaml /home/stack/templates/network_data.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow network_data.yaml設定ファイルを編集して、新しいネットワークのセクションを追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 環境のその他のネットワーク VIP 属性を設定します。ネットワーク属性の設定に使用できるプロパティーの詳細は、ネットワーク定義ファイルの設定オプション を参照してください。
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.yamlVLAN ID やサブネット範囲などのネットワーク設定をカスタマイズします。IPv4 または IPv6 が不要な場合は、対応するサブネットを除外できます。
以下に例を示します。
Copy to Clipboard Copied! Toggle word wrap Toggle overflow - このネットワークは、オーバークラウドデプロイメントと、オーバークラウドのデプロイ後にセットアップされる Networking サービス (neutron) プロバイダーネットワークにより共有され、Compute サービス (nova) 仮想マシンのようなコンシューマーが共有をマウントするために使用されます。
- オーバークラウド Networking サービス StorageNFS プロバイダーネットワークのサブネット定義の割り当てプールで使用するために、この例で指定した割り当てプール外に相応の範囲を残しておきます。
-
仮想 IP を含むコンポーザブルネットワークを追加し、一部の API サービスをこのネットワークにマッピングする場合は、
CloudName{network.name}定義を使用して API エンドポイントの DNS 名を設定します。CloudName{{network.name}}CloudName{{network.name}}Copy to Clipboard Copied! Toggle word wrap Toggle overflow 以下に例を示します。
parameter_defaults: ... CloudNameOcProvisioning: baremetal-vip.example.com
parameter_defaults: ... CloudNameOcProvisioning: baremetal-vip.example.comCopy to Clipboard Copied! Toggle word wrap Toggle overflow 必要なサンプルネットワーク VIP 定義テンプレートを
/usr/share/openstack-tripleo-heat-templates/network-data-samplesから環境ファイルディレクトリーにコピーします。次の例では、vip-data-default-network-isolation.yamlをvip_data.yamlという名前のローカル環境ファイルにコピーします。cp /usr/share/openstack-tripleo-heat-templates/network-data-samples/vip-data-default-network-isolation.yaml /home/stack/templates/vip_data.yaml
$ cp /usr/share/openstack-tripleo-heat-templates/network-data-samples/vip-data-default-network-isolation.yaml /home/stack/templates/vip_data.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow vip_data.yaml設定ファイルを編集します。仮想 IP データは仮想 IP アドレス定義のリストであり、それぞれに IP アドレスが割り当てられているネットワークの名前が含まれています。Copy to Clipboard Copied! Toggle word wrap Toggle overflow -
<vip_address>は、必要な仮想 IP アドレスに置き換えます。
VIP 定義ファイルでネットワーク VIP 属性を設定するために使用できるプロパティーの詳細は、ネットワーク VIP 属性のプロパティー を参照してください。
-
サンプルネットワーク設定テンプレートをコピーします。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/
$ cp /usr/share/ansible/roles/tripleo_network_config/templates/single_nic_vlans/single_nic_vlans.j2 /home/stack/templates/Copy to Clipboard Copied! Toggle word wrap Toggle overflow single_nic_vlans.j2設定ファイルを編集します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow overcloud-baremetal-deploy.yaml設定ファイルでnetwork_configテンプレートを設定します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow Shared File Systems サービス (manila) で CephFS-NFS バックエンドを使用するために StorageNFS ネットワークをプロビジョニングする場合は、
network_configセクションではなく、ControllerまたはControllerStorageNfsセクションを編集します。これは、StorageNFS ネットワークとその仮想 IP がコントローラーノードに接続されているためです。Copy to Clipboard Copied! Toggle word wrap Toggle overflow オーバークラウドネットワークをプロビジョニングします。このアクションにより、オーバークラウドのデプロイ時に環境ファイルで使用される出力ファイルが生成されます。
openstack overcloud network provision \ --output <deployment_file> /home/stack/templates/<networks_definition_file>.yaml
(undercloud)$ openstack overcloud network provision \ --output <deployment_file> /home/stack/templates/<networks_definition_file>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
<networks_definition_file>を、network_data.yamlなどのネットワーク定義ファイルの名前、またはnetwork_data_ganesha.yamlなどの StorageNFS ネットワークファイルの名前に置き換えます。 -
<deployment_file>は、デプロイメントコマンドに追加するために生成する heat 環境ファイルの名前に置き換えます (例:/home/stack/templates/overcloud-networks-deployed.yaml)。
-
ネットワーク VIP をプロビジョニングし、
vip-deployed-environment.yamlファイルを生成します。オーバークラウドをデプロイするときに、このファイルを使用します。openstack overcloud network vip provision --stack <stack> --output <deployment_file> /home/stack/templates/vip_data.yaml
(overcloud)$ openstack overcloud network vip provision --stack <stack> --output <deployment_file> /home/stack/templates/vip_data.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
<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 ネットワークはすでに追加されています。
手順
カスタム
roles_data.yamlファイルがまだない場合には、デフォルトをご自分のホームディレクトリーにコピーします。cp /usr/share/openstack-tripleo-heat-templates/roles_data.yaml /home/stack/templates/roles_data.yaml
$ cp /usr/share/openstack-tripleo-heat-templates/roles_data.yaml /home/stack/templates/roles_data.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
カスタムの
roles_data.yamlファイルを編集します。 ネットワークを追加するロールの
networksリストにネットワーク名を追加します。この例では、
StorageBackupネットワークを Ceph Storage ロールに追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow この例では、
StorageNFSネットワークをコントローラーノードに追加します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
- カスタムネットワークを対応するロールに追加したら、ファイルを保存します。
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
parameter_defaults:
ServiceNetMap:
SwiftStorageNetwork: storage_backup
CephClusterNetwork: storage_backup
これらのパラメーターを 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>
parameter_defaults:
ServiceNetMap:
GaneshaNetwork: <manila_nfs_network>
-
<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) を使用します。
手順
stackrcアンダークラウド認証情報ファイルを入手します。source ~/stackrc
$ source ~/stackrcCopy to Clipboard Copied! Toggle word wrap Toggle overflow オーバークラウドネットワークをプロビジョニングします。
openstack overcloud network provision \ --output overcloud-networks-deployed.yaml \ custom_network_data.yaml
$ openstack overcloud network provision \ --output overcloud-networks-deployed.yaml \ custom_network_data.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow ネットワーク VIP をプロビジョニングします。
openstack overcloud network vip provision \ --stack overcloud \ --output overcloud-networks-vips-deployed.yaml \ custom_vip_data.yaml$ openstack overcloud network vip provision \ --stack overcloud \ --output overcloud-networks-vips-deployed.yaml \ custom_vip_data.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow オーバークラウドノードをプロビジョニングします。
openstack overcloud node provision \ --stack overcloud \ --output overcloud-baremetal-deployed.yaml \ overcloud-baremetal-deploy.yaml$ openstack overcloud node provision \ --stack overcloud \ --output overcloud-baremetal-deployed.yaml \ overcloud-baremetal-deploy.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 以下の例のように、設定ファイルとテンプレートを必要な順序で指定して、
openstack overcloud deployコマンドを作成します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow
上記の例に示すコマンドにより、追加のカスタムネットワークを含め、コンポーザブルネットワークがオーバークラウドのノード全体にデプロイされます。
8.2.2.5. デフォルトネットワークの名前変更 リンクのコピーリンクがクリップボードにコピーされました!
network_data.yaml ファイルを使用して、デフォルトネットワークのユーザー表示名を変更することができます。
- InternalApi
- External
- Storage
- StorageMgmt
- Tenant
これらの名前を変更するのに、name フィールドを変更しないでください。代わりに、name_lower フィールドをネットワークの新しい名前に変更し、新しい名前で ServiceNetMap を更新します。
手順
network_data.yamlファイルで、名前を変更する各ネットワークのname_lowerパラメーターに新しい名前を入力します。- name: InternalApi name_lower: MyCustomInternalApi
- name: InternalApi name_lower: MyCustomInternalApiCopy to Clipboard Copied! Toggle word wrap Toggle overflow service_net_map_replaceパラメーターに、name_lowerパラメーターのデフォルト値を追加します。- name: InternalApi name_lower: MyCustomInternalApi service_net_map_replace: internal_api
- name: InternalApi name_lower: MyCustomInternalApi service_net_map_replace: internal_apiCopy to Clipboard Copied! Toggle word wrap Toggle overflow
8.2.3. 追加のオーバークラウドネットワーク設定 リンクのコピーリンクがクリップボードにコピーされました!
この章では、「カスタムネットワークインターフェイステンプレートの定義」で説明した概念および手順に続いて、オーバークラウドネットワークの要素を設定する際に役立つその他の情報を提供します。
8.2.3.1. ルートおよびデフォルトルートの設定 リンクのコピーリンクがクリップボードにコピーされました!
ホストのデフォルトルートは、2 つの方法のどちらかで設定することができます。インターフェイスが DHCP を使用しており、DHCP サーバーがゲートウェイアドレスを提供している場合には、システムはそのゲートウェイのデフォルトルートを使用します。それ以外の場合には、固定 IP が指定されたインターフェイスにデフォルトのルートを設定することができます。
Linux カーネルは複数のデフォルトゲートウェイをサポートしますが、最も低いメトリックのゲートウェイだけを使用します。複数の DHCP インターフェイスがある場合には、どのデフォルトゲートウェイが使用されるかが推測できなくなります。このような場合には、デフォルトルートを使用しないインターフェイスに defroute: false を設定することを推奨します。
たとえば、DHCP インターフェイス (nic3) をデフォルトのルートに指定する場合があります。そのためには、以下の YAML スニペットを使用して別の DHCP インターフェイス (nic2) 上のデフォルトルートを無効にします。
defroute パラメーターは、DHCP で取得したルートにのみ適用されます。
固定 IP が指定されたインターフェイスに静的なルートを設定するには、サブネットへのルートを指定します。たとえば、Internal API ネットワーク上のゲートウェイ 172.17.0.1 を経由するサブネット 10.1.2.0/24 にルートを設定します。
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}のルーティングテーブル固有のルート
前提条件
- アンダークラウドが正常にインストールされている。詳細は、director を使用した Red Hat OpenStack Platform のインストールと管理ガイド の アンダークラウドへの director のインストール を参照してください。
手順
/home/stack/templates/custom-nicsディレクトリーからのカスタム NIC テンプレートにinterfaceエントリーを作成し、インターフェイスのルートを定義し、デプロイメントに関連するルールを定義します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow ご自分のデプロイメントに該当するその他の環境ファイルと共に、カスタム NIC 設定およびネットワーク環境ファイルをデプロイメントコマンドに追加します。
openstack overcloud deploy --templates \ -e /home/stack/templates/<custom-nic-template>
$ openstack overcloud deploy --templates \ -e /home/stack/templates/<custom-nic-template> -e <OTHER_ENVIRONMENT_FILES>Copy to Clipboard Copied! Toggle word wrap Toggle overflow
検証
コントローラーノードで以下のコマンドを入力して、ルーティング設定が正しく機能していることを確認します。
cat /etc/iproute2/rt_tables $ ip route $ ip rule
$ cat /etc/iproute2/rt_tables $ ip route $ ip ruleCopy to Clipboard Copied! Toggle word wrap Toggle overflow
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 を変更しないでください。
8.2.3.4. トランキングされたインターフェイスでのネイティブ VLAN の設定 リンクのコピーリンクがクリップボードにコピーされました!
トランキングされたインターフェイスまたはボンディングに、ネイティブ VLAN を使用したネットワークがある場合には、IP アドレスはブリッジに直接割り当てられ、VLAN インターフェイスはありません。
次の例では、External ネットワークがネイティブ VLAN 上にあるボンディングインターフェイスを設定します。
アドレスまたはルートのステートメントをブリッジに移動する場合は、対応する 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 アンダークラウドのインストールが成功しました。
手順
-
アンダークラウドホストに
stackユーザーとしてログインします。 source コマンドでアンダークラウドの認証情報ファイルを読み込みます。
source ~/stackrc
$ source ~/stackrcCopy to Clipboard Copied! Toggle word wrap Toggle overflow カスタム YAML 環境ファイルを作成します。
例
vi /home/stack/templates/custom-environment.yaml
$ vi /home/stack/templates/custom-environment.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow 環境ファイルには、キーワード
parameter_defaultsおよびExtraSysctlSettingsが含まれている必要があります。netfilter が追跡できる接続の最大数の新しい値を変数net.nf_conntrack_maxに入力します。例
この例では、RHOSP デプロイメント内のすべてのホストにわたって conntrack 制限を設定できます。
parameter_defaults: ExtraSysctlSettings: net.nf_conntrack_max: value: 500000parameter_defaults: ExtraSysctlSettings: net.nf_conntrack_max: value: 500000Copy to Clipboard Copied! Toggle word wrap Toggle overflow <role>Parameterパラメーターを使用して、特定のロールの conntrack 制限を設定します。parameter_defaults: <role>Parameters: ExtraSysctlSettings: net.nf_conntrack_max: value: <simultaneous_connections>parameter_defaults: <role>Parameters: ExtraSysctlSettings: net.nf_conntrack_max: value: <simultaneous_connections>Copy to Clipboard Copied! Toggle word wrap Toggle overflow <role>をロールの名前に置き換えます。たとえば、
ControllerParametersを使用して Controller ロールの conntrack 制限を設定するか、ComputeParametersを使用して Compute ロールの conntrack 制限を設定します。<simultaneous_connections>を、許可する同時接続数に置き換えます。例
この例では、RHOSP デプロイメントの Controller ロールのみに conntrack 制限を設定できます。
parameter_defaults: ControllerParameters: ExtraSysctlSettings: net.nf_conntrack_max: value: 500000parameter_defaults: ControllerParameters: ExtraSysctlSettings: net.nf_conntrack_max: value: 500000Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記net.nf_conntrack_maxのデフォルト値は500000接続です。最大値は4294967295です。
コア heat テンプレート、環境ファイル、およびこの新しいカスタム環境ファイルを指定して、deployment コマンドを実行します。
重要後で実行される環境ファイルで定義されているパラメーターとリソースが優先されることになるため、環境ファイルの順序は重要となります。
例
openstack overcloud deploy --templates \ -e /home/stack/templates/custom-environment.yaml
$ openstack overcloud deploy --templates \ -e /home/stack/templates/custom-environment.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
8.2.4. ネットワークインターフェイスボンディング リンクのコピーリンクがクリップボードにコピーされました!
カスタムネットワーク設定では、さまざまなボンディングオプションを使用することができます。
8.2.4.1. オーバークラウドノードのネットワークインターフェイスボンディング リンクのコピーリンクがクリップボードにコピーされました!
複数の物理 NIC をバンドルして、単一の論理チャネルを形成することができます。この設定はボンディングとも呼ばれます。ボンディングを設定して、高可用性システム用の冗長性またはスループットの向上を実現することができます。
Red Hat OpenStack Platform では、Open vSwitch (OVS) カーネルボンディング、OVS-DPDK ボンディング、および Linux カーネルボンディングがサポートされます。
| ボンディング種別 | 種別の値 | 許可されるブリッジ種別 | 許可されるメンバー |
|---|---|---|---|
| OVS カーネルボンディング |
|
|
|
| OVS-DPDK ボンディング |
|
|
|
| Linux カーネルボンディング |
|
|
|
ovs_bridge と ovs_user_bridge を同じノード上で組み合わせないでください。
8.2.4.2. Open vSwitch (OVS) ボンディングの作成 リンクのコピーリンクがクリップボードにコピーされました!
ネットワークインターフェイステンプレートで OVS ボンディングを作成します。たとえば、OVS ユーザースペースブリッジの一部としてボンディングを作成できます。
以下の例では、2 つの DPDK ポートからボンディングを作成します。
ovs_options パラメーターには、ボンディングオプションが含まれます。ネットワーク環境ファイルの BondInterfaceOvsOptions パラメーターを使用して、ボンディングオプションを設定することができます。
parameter_defaults: BondInterfaceOvsOptions: "bond_mode=active-backup"
parameter_defaults:
BondInterfaceOvsOptions: "bond_mode=active-backup"
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.4. Open vSwitch (OVS) ボンディングモードでの Link Aggregation Control Protocol (LACP) の使用 リンクのコピーリンクがクリップボードにコピーされました!
ボンディングを、オプションの Link Aggregation Control Protocol (LACP) と共に使用することができます。LACP は動的ボンディングを作成するネゴシエーションプロトコルで、これにより負荷分散機能および耐障害性を持たせることができます。
以下の表を使用して、LACP オプションと組み合わせた OVS カーネルおよび OVS-DPDK ボンディングインターフェイスのサポート互換性を説明します。
Control ネットワークおよび Storage ネットワークの場合、Red Hat では VLAN を使用する Linux ボンディングを LACP と組み合わせて使用することを推奨します。OVS ボンディングを使用すると、更新、ホットフィックス等の理由により OVS または neutron エージェントが再起動すると、コントロールプレーンの中断が生じる可能性があるためです。Linux ボンディング/LACP/VLAN の設定であれば、OVS の中断を懸念することなく NIC を管理できます。
| 目的 | OVS ボンディングモード | 互換性のある LACP オプション | 備考 |
| 高可用性 (active-passive) |
|
| |
| スループットの向上 (active-active) |
|
|
|
|
|
|
|
8.2.4.5. Linux ボンディングの作成 リンクのコピーリンクがクリップボードにコピーされました!
ネットワークインターフェイステンプレートで linux ボンディングを作成します。たとえば、2 つのインターフェイスをボンディングする linux ボンディングを作成することができます。
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 ボンディングCopy to Clipboard Copied! Toggle word wrap Toggle overflow OVS ブリッジ上の Linux ボンディング。1 つの VLAN を持つ
802.3adLACP モードに設定されたボンディングCopy to Clipboard Copied! Toggle word wrap Toggle overflow 重要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+ 形式に変換できます。
手順
変換ツールをダウンロードします。
-
/usr/share/openstack-tripleo-heat-templates/tools/convert_v1_net_data.py
-
RHOSP 16+ ネットワーク設定ファイルを RHOSP 17+ 形式に変換します。
python3 convert_v1_net_data.py <network_config>.yaml
$ python3 convert_v1_net_data.py <network_config>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow -
<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 テンプレート
- その他のカスタムネットワークファイル
手順
-
アンダークラウドに
stackユーザーとしてログインします。 stackrcファイルを取得します。source ~/stackrc
[stack@director ~]$ source ~/stackrcCopy to Clipboard Copied! Toggle word wrap Toggle overflow 変換ツールをアンダークラウドの現在のディレクトリーにコピーします。
cp /usr/share/openstack-tripleo-heat-templates/tools/convert_heat_nic_config_to_ansible_j2.py .
$ cp /usr/share/openstack-tripleo-heat-templates/tools/convert_heat_nic_config_to_ansible_j2.py .Copy to Clipboard Copied! Toggle word wrap Toggle overflow コンピュートとコントローラーの NIC テンプレートファイル、およびその他のカスタムネットワークファイルを Jinja2 Ansible 形式に変換します。
python3 convert_heat_nic_config_to_ansible_j2.py \ [--stack <overcloud> | --standalone] --networks_file <network_config.yaml> \ <network_template>.yaml
$ python3 convert_heat_nic_config_to_ansible_j2.py \ [--stack <overcloud> | --standalone] --networks_file <network_config.yaml> \ <network_template>.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow <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ファイルを生成します。-
生成された各
.j2ファイルを検査して、設定が環境に対して正しく、また完全であることを確認します。次に、手動で、変換できなかった設定を強調表示するツールが生成したコメントに、手動で対応します。NIC 設定を Jinja2 形式に手動で変換する方法は、Heat パラメーターから Ansible 変数へのマッピング を参照してください。 生成された
.j2ファイルを指すように、network-environment.yamlファイルの*NetworkConfigTemplateパラメーターを設定します。parameter_defaults: ControllerNetworkConfigTemplate: '/home/stack/templates/custom-nics/controller.j2' ComputeNetworkConfigTemplate: '/home/stack/templates/custom-nics/compute.j2'
parameter_defaults: ControllerNetworkConfigTemplate: '/home/stack/templates/custom-nics/controller.j2' ComputeNetworkConfigTemplate: '/home/stack/templates/custom-nics/compute.j2'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 古いネットワーク設定ファイルの
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
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.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
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 テンプレート
- その他のカスタムネットワークファイル
手順
-
Jinja2 テンプレートを作成します。アンダークラウドノードの
/usr/share/ansible/roles/tripleo_network_config/templates/ディレクトリーからサンプルテンプレートをコピーして、新しいテンプレートを作成できます。 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 %}{% 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 Copied! Toggle word wrap Toggle overflow Ansible 変数を使用して、デプロイメントのネットワークプロパティーを設定します。個々のネットワークを手動で設定するか、
role_networksを反復して各ネットワークをプログラムで設定できます。各ネットワークを手動で設定するには、各
get_param関数を同等の Ansible 変数に置き換えます。たとえば、現在のデプロイでget_param: InternalApiNetworkVlanIDを使用してvlan_idを設定している場合は、次の設定をテンプレートに追加します。vlan_id: {{ internal_api_vlan_id }}vlan_id: {{ internal_api_vlan_id }}Copy to Clipboard Copied! Toggle word wrap Toggle overflow Expand 表8.9 heat パラメーターから Ansible vars へのネットワークプロパティーマッピングの例 yamlファイル形式Jinja2 ansible 形式、 j2Copy to Clipboard Copied! Toggle word wrap Toggle overflow - type: vlan device: nic2 vlan_id: {{ internal_api_vlan_id }} addresses: - ip_netmask: {{ internal_api_ip }}/{{ internal_api_cidr }}- type: vlan device: nic2 vlan_id: {{ internal_api_vlan_id }} addresses: - ip_netmask: {{ internal_api_ip }}/{{ internal_api_cidr }}Copy to Clipboard Copied! Toggle word wrap Toggle overflow 各ネットワークをプログラムで設定するには、
role_networksを使用してロール名で使用可能なネットワークを取得するテンプレートに、Jinja2 for-loop 構造を追加します。例
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
heat パラメーターから同等の Ansible
varsへのマッピングをすべて記載したリストについては、Heat パラメーターから Ansible 変数へのマッピング を参照してください。生成された
.j2ファイルを指すように、network-environment.yamlファイルの*NetworkConfigTemplateパラメーターを設定します。parameter_defaults: ControllerNetworkConfigTemplate: '/home/stack/templates/custom-nics/controller.j2' ComputeNetworkConfigTemplate: '/home/stack/templates/custom-nics/compute.j2'
parameter_defaults: ControllerNetworkConfigTemplate: '/home/stack/templates/custom-nics/controller.j2' ComputeNetworkConfigTemplate: '/home/stack/templates/custom-nics/compute.j2'Copy to Clipboard Copied! Toggle word wrap Toggle overflow 古いネットワーク設定ファイルの
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
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.yamlCopy to Clipboard Copied! Toggle word wrap Toggle overflow
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 }}
vlan_id: {{ internal_api_vlan_id }}
--network-config オプションの引数を指定し、openstack overcloud node provision を実行してノードをプロビジョニングする場合は、overcloud-baremetal-deploy.yaml のパラメーターを使用して、デプロイ用のネットワークプロパティーを設定する必要があります。詳細は、定義ファイルマッピングをプロビジョニングする heat パラメーター を参照してください。
次の表は、heat パラメーターから同等の Ansible vars へのマッピングで利用できるものを一覧にしています。
| Heat パラメーター | Ansible vars |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
注記
この Ansible 変数には、 |
|
|
|
表に記載されていない Heat パラメーターの設定
表に記載されていない heat パラメーターを設定するには、パラメーターを {{role.name}}ExtraGroupVars として設定する必要があります。このパラメーターを {{role.name}}ExtraGroupVars パラメーターとして設定しないと、新しいテンプレートで使用できません。たとえば、StorageSupernet パラメーターを設定するには、次の設定をネットワーク設定ファイルに追加します。
parameter_defaults:
ControllerExtraGroupVars:
storage_supernet: 172.16.0.0/16
parameter_defaults:
ControllerExtraGroupVars:
storage_supernet: 172.16.0.0/16
その後、{{ 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>は、設定するプロパティー (ip、vlan_id、またはmtuなど) に置き換えます。
たとえば、各 NetworkVlanID の値を動的に入力するには、{{ <network_name>_vlan_id }} を次の設定に置き換えます。
{{ lookup(‘vars’, networks_lower[network] ~ ‘_vlan_id’) }}`
{{ lookup(‘vars’, networks_lower[network] ~ ‘_vlan_id’) }}`
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 プロパティーへの利用可能なマッピングをまとめています。
| heat パラメーター | network_config プロパティー |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
以下の表では、heat パラメーターからネットワーク定義ファイル network_data.yaml に相当するプロパティーへの利用可能なマッピングをまとめています。
| heat パラメーター | IPv4 network_data.yaml プロパティー | IPv6 network_data.yaml プロパティー |
|---|---|---|
|
|
- name: <network_name>
subnets:
subnet01:
ip_subnet: 172.16.1.0/24
|
- name: <network_name>
subnets:
subnet01:
ipv6_subnet: 2001:db8:a::/64
|
|
|
- name: <network_name>
subnets:
subnet01:
...
vlan: <vlan_id>
|
- name: <network_name>
subnets:
subnet01:
...
vlan: <vlan_id>
|
|
|
- name: <network_name> mtu:
|
- name: <network_name> mtu:
|
|
|
- name: <network_name>
subnets:
subnet01:
ip_subnet: 172.16.16.0/24
gateway_ip: 172.16.16.1
|
- name: <network_name>
subnets:
subnet01:
ipv6_subnet: 2001:db8:a::/64
gateway_ipv6: 2001:db8:a::1
|
|
|
|
|
8.2.5.6. ネットワークデータスキーマの変更 リンクのコピーリンクがクリップボードにコピーされました!
ネットワークデータスキーマは、Red Hat OpenStack Platform (RHOSP) 17 で更新されました。RHOSP 16 以前で使用されていたネットワークデータスキーマと、RHOSP 17 以降で使用されていたネットワークデータスキーマの主な違いは次のとおりです。
-
ベースサブネットは、
サブネットマップに移動されました。これにより、スパインリーフネットワーキングなど、ルーティングされないデプロイメントとルーティングされるデプロイメントの設定が調整されます。 -
無効なネットワークを無視するために、
enabledオプションが使用されなくなりました。代わりに、設定ファイルから無効なネットワークを削除する必要があります。 -
compat_nameオプションは、このオプションを使用していた heat リソースが削除されたため、不要になりました。 -
ip_subnet、gateway_ip、allocation_pools、routes、ipv6_subnet、gateway_ipv6、ipv6_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}}
-