第10章 コンポーザブルネットワークの使用
コンポーザブルネットワークでは、事前定義済みのネットワークセグメント (Internal、Storage、Storage Management、Tenant、External、Control Plane) によって制限されなくなり、その代わりに、独自のネットワークを作成して任意のロール (デフォルトまたはカスタム) に割り当てることができます。たとえば、NFS トラフィック専用のネットワークがある場合には、複数の異なるロールに提供できます。
director は、デプロイメントおよび更新段階中のカスタムネットワークの作成をサポートしています。このような追加のネットワークは、Ironic ベアメタルノード、システム管理に使用したり、異なるロール用に別のネットワークを作成するのに使用したりすることができます。また、これは、トラフィックが複数のネットワーク間でルーティングされる、分離型のデプロイメント用に複数のネットワークセットを作成するのに使用することもできます。
デプロイされるネットワークの一覧は、単一のデータファイル (network_data.yaml) で管理します。それにより、ロールの定義プロセスは、ネットワーク分離を使用して、必要なロールにネットワークを割り当てます (詳しくは「9章ネットワークの分離」を参照)。
10.1. コンポーザブルネットワークの定義
コンポーザブルネットワークを作成するには、/usr/share/openstack-tripleo-heat-templates/network_data.yaml の Heat テンプレートのローカルコピーを編集します。以下に例を示します。
- name: StorageBackup
vip: true
name_lower: storage_backup
ip_subnet: '172.21.1.0/24'
allocation_pools: [{'start': '171.21.1.4', 'end': '172.21.1.250'}]
gateway_ip: '172.21.1.1'
ipv6_subnet: 'fd00:fd00:fd00:7000::/64'
ipv6_allocation_pools: [{'start': 'fd00:fd00:fd00:7000::10', 'end': 'fd00:fd00:fd00:7000:ffff:ffff:ffff:fffe'}]
gateway_ipv6: 'fd00:fd00:fd00:7000::1'-
name は、唯一の必須の値です。ただし、
name_lowerを使用して名前を正規化し、読みやすくすることができます。たとえば、InternalApiをinternal_apiに変更します。 - vip:true は仮想 IP アドレス (VIP) を新規ネットワーク上に作成します。その新規ネットワークのデフォルト値は、残りのパラメーターによって設定されます。
- ip_subnet と allocation_pools はデフォルトの IPv4 サブネットと、ネットワークの IP 範囲を設定します。
- ipv6_subnet および ipv6_allocation_pools は、ネットワークのデフォルトの IPv6 サブネットを設定します。
これらのデフォルト値は、環境ファイル (通常は network-environment.yaml という名前) を使用して上書きすることができます。使用している director のコア Heat テンプレートのルート (/usr/share/openstack-tripleo-heat-templates/ のローカルコピー) から以下のコマンドを実行すると、サンプルの network-environment.yaml ファイルを作成できます。
[stack@undercloud ~/templates] $ ./tools/process-templates.py
10.1.1. コンポーザブルネットワーク用のネットワークインターフェース設定の定義
コンポーザブルネットワークを使用する場合には、各ロール (ネットワークが使用しないロールを含む) に使用する NIC 定義テンプレートにネットワーク IP アドレスのパラメーターの定義を追加する必要があります。この NIC 設定の例は、/usr/share/openstack-tripleo-heat-templates/network/config のディレクトリーを参照してください。たとえば、StorageBackup ネットワークが Ceph ノードにのみ追加される場合には、全ロールの NIC 設定テンプレートのリソース定義に以下の定義を追加する必要があります。
StorageBackupIpSubnet:
default: ''
description: IP address/subnet on the external network
type: string必要な場合には、VLAN ID とゲートウェイ IP のリソース定義も作成することができます。
StorageBackupNetworkVlanID: # Override this via parameter_defaults in network_environment.yaml
default: 60
description: Vlan ID for the management network traffic.
type: number
StorageBackupDefaultRoute: # Override this via parameter_defaults in network_environment.yaml
description: The default route of the storage backup network.
type: string
カスタムネットワーク用の IpSubnet パラメーターは、各ロールのパラメーター定義に含まれています。ただし、この例では、Ceph ロールは、StorageBackup ネットワークを使用する唯一のロールなので、Ceph ロールの NIC 設定テンプレートのみがそのテンプレートの network_config セクションの StorageBackup パラメーターを使用することになります。
$network_config:
network_config:
- type: interface
name: nic1
use_dhcp: false
addresses:
- ip_netmask:
Get_param: StorageBackupIpSubnet10.1.2. サービスに対するコンポーザブルネットワークの割り当て
カスタムのネットワーク定義で vip: true が指定されている場合には、ServiceNetMap パラメーターを使用してサービスをネットワークに割り当てることができます。サービスに選択されたカスタムネットワークは、サービスをホストするロール上に存在する必要があります。network_environment.yaml (または異なる環境ファイル) の /usr/share/openstack-tripleo-heat-templates/network/service_net_map.j2.yaml で定義されている ServiceNetMap を上書きすることによって、デフォルトのネットワークを上書きすることができます。
parameter_defaults: ServiceNetMap: NeutronTenantNetwork: tenant CeilometerApiNetwork: internal_api AodhApiNetwork: internal_api GnocchiApiNetwork: internal_api MongoDbNetwork: internal_api CinderApiNetwork: internal_api CinderIscsiNetwork: storage GlanceApiNetwork: storage GlanceRegistryNetwork: internal_api KeystoneAdminApiNetwork: ctlplane # Admin connection for Undercloud KeystonePublicApiNetwork: internal_api NeutronApiNetwork: internal_api HeatApiNetwork: internal_api NovaApiNetwork: internal_api NovaMetadataNetwork: internal_api NovaVncProxyNetwork: internal_api SwiftMgmtNetwork: storage_backup # Changed from storage_mgmt SwiftProxyNetwork: storage SaharaApiNetwork: internal_api HorizonNetwork: internal_api MemcachedNetwork: internal_api RabbitMqNetwork: internal_api RedisNetwork: internal_api MysqlNetwork: internal_api CephClusterNetwork: storage_backup # Changed from storage_mgmt CephPublicNetwork: storage ControllerHostnameResolveNetwork: internal_api ComputeHostnameResolveNetwork: internal_api BlockStorageHostnameResolveNetwork: internal_api ObjectStorageHostnameResolveNetwork: internal_api CephStorageHostnameResolveNetwork: storage
10.1.3. ルーティングネットワークの定義
コンポーザブルネットワークを使用してルーティングネットワークをデプロイする場合には、ネットワーク設定で使用するルートとルーターゲートウェイを定義します。ネットワークルートを作成して、ネットワークルートとスーパーネットルートを作成して、サブネット間でトラフィックをルーティングする際に使用するインターフェースを定義します。たとえば、Compute と Controller ロールの間でトラフィックがルーティングされるデプロイメントの場合には、分離ネットワークのセット用にスーパーネットを定義することができます。たとえば、172.17.0.0/16 は、172.17 で始まる全ネットワークが含まれるスーパーネットで、コントローラー上で使用される Internal API ネットワークには 172.17.1.0/24 を使用できます。また、コンピュートノード上で使用される Internal API ネットワークには 172.17.2.0/24 を使用できます。ロールで使用されるネットワーク固有のルーターゲートウェイを介する 172.17.0.0/16 スーパーネットへのルートを両方のノードで定義します。
network-environment.yaml で利用可能なパラメーター
InternalApiSupernet:
default: '172.17.0.0/16'
description: Supernet that contains Internal API subnets for all roles.
type: string
InternalApiGateway:
default: '172.17.1.1'
description: Router gateway on Internal API network
type: string
InternalApi2Gateway:
default: '172.17.2.1'
description: Router gateway on Internal API 2 network
Type: stringこれらのパラメーターは、ロールの NIC 設定テンプレートで使用できます。
コントローラーは、controller.yaml の InternalApi ネットワークのパラメーターを使用します。
- type: interface
name: nic3
use_dhcp: false
addresses:
- ip_netmask:
get_param: InternalApiIpSubnet
- routes:
ip_netmask:
get_param: InternalApiSupernet
next_hop:
Get_param: InternalApiGateway
compute ロールは、compute.yaml の InternalApi2 ネットワークのパラメーターを使用します。
- type: interface
name: nic3
use_dhcp: false
addresses:
- ip_netmask:
get_param: InternalApi2IpSubnet
- routes:
ip_netmask:
get_param: InternalApiSupernet
next_hop:
Get_param: InternalApi2Gateway特定のネットワークルートが分離ネットワークに適用されない場合には、ローカル以外のネットワークへのトラフィックはすべてデフォルトのゲートウェイを使用します。これにより、異なる種別のトラフィックが混在し、送信トラフィックがすべて同じインターフェース上に配置されるので、通常はセキュリティーとパフォーマンスの両観点から望ましくありません。また、ルーティングが非対称なので (受信用とは別のインターフェースでトラフィックが送信される)、サービスが到達不可能となる可能性があります。クライアントとサーバーの両方でスーパーネットへのルートを使用すると、トラフィックは両サイドで正しいインターフェースを使用するように送られます。

Where did the comment section go?
Red Hat's documentation publication system recently went through an upgrade to enable speedier, more mobile-friendly content. We decided to re-evaluate our commenting platform to ensure that it meets your expectations and serves as an optimal feedback mechanism. During this redesign, we invite your input on providing feedback on Red Hat documentation via the discussion platform.