第9章 コンポーザブルネットワークの使用
コンポーザブルネットワークでは、事前定義済みのネットワークセグメント (Internal、Storage、Storage Management、Tenant、External、Control Plane) によって制限されなくなり、その代わりに、独自のネットワークを作成して任意のロール (デフォルトまたはカスタム) に割り当てることができます。たとえば、NFS トラフィック専用のネットワークがある場合には、複数の異なるロールに提供できます。
director は、デプロイメントおよび更新段階中のカスタムネットワークの作成をサポートしています。このような追加のネットワークは、Ironic ベアメタルノード、システム管理に使用したり、異なるロール用に別のネットワークを作成するのに使用したりすることができます。また、これは、トラフィックが複数のネットワーク間でルーティングされる、分離型のデプロイメント用に複数のネットワークセットを作成するのに使用することもできます。
デプロイされるネットワークの一覧は、単一のデータファイル (network_data.yaml) で管理します。それにより、ロールの定義プロセスは、ネットワーク分離を使用して、必要なロールにネットワークを割り当てます (詳しくは「8章ネットワークの分離」を参照)。
9.1. コンポーザブルネットワークの定義 リンクのコピーリンクがクリップボードにコピーされました!
コンポーザブルネットワークを作成するには、/usr/share/openstack-tripleo-heat-templates/network_data.yaml の Heat テンプレートのローカルコピーを編集します。以下に例を示します。
-
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
[stack@undercloud ~/templates] $ ./tools/process-templates.py
9.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
StorageBackupIpSubnet:
default: ''
description: IP address/subnet on the external network
type: string
必要な場合には、VLAN ID とゲートウェイ IP のリソース定義も作成することができます。
カスタムネットワーク用の IpSubnet パラメーターは、各ロールのパラメーター定義に含まれています。ただし、この例では、Ceph ロールは、StorageBackup ネットワークを使用する唯一のロールなので、Ceph ロールの NIC 設定テンプレートのみがそのテンプレートの network_config セクションの StorageBackup パラメーターを使用することになります。
9.1.2. サービスに対するコンポーザブルネットワークの割り当て リンクのコピーリンクがクリップボードにコピーされました!
カスタムのネットワーク定義で vip: true が指定されている場合には、ServiceNetMap パラメーターを使用してサービスをネットワークに割り当てることができます。サービスに選択されたカスタムネットワークは、サービスをホストするロール上に存在する必要があります。network_environment.yaml (または異なる環境ファイル) の /usr/share/openstack-tripleo-heat-templates/network/service_net_map.j2.yaml で定義されている ServiceNetMap を上書きすることによって、デフォルトのネットワークを上書きすることができます。
9.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 で利用可能なパラメーター
これらのパラメーターは、ロールの NIC 設定テンプレートで使用できます。
コントローラーは、controller.yaml の InternalApi ネットワークのパラメーターを使用します。
compute ロールは、compute.yaml の InternalApi2 ネットワークのパラメーターを使用します。
特定のネットワークルートが分離ネットワークに適用されない場合には、ローカル以外のネットワークへのトラフィックはすべてデフォルトのゲートウェイを使用します。これにより、異なる種別のトラフィックが混在し、送信トラフィックがすべて同じインターフェース上に配置されるので、通常はセキュリティーとパフォーマンスの両観点から望ましくありません。また、ルーティングが非対称なので (受信用とは別のインターフェースでトラフィックが送信される)、サービスが到達不可能となる可能性があります。クライアントとサーバーの両方でスーパーネットへのルートを使用すると、トラフィックは両サイドで正しいインターフェースを使用するように送られます。
9.2. ルーティング対応のリーフ/スパイン型のネットワーク リンクのコピーリンクがクリップボードにコピーされました!
コンポーザブルネットワークにより、OpenStack Networking デプロイメントを一般的なルーティング対応のリーフ/スパイン型データセンタートポロジーに適応させることができます。図9.1「ルーティング対応のリーフ/スパイントポロジーの例」に示したとおり、ルーティング対応のリーフ/スパインの実用では、リーフは通常データセンターラック内の Compute または Storage のコンポーザブルロールとして表されます。leaf 0 ラックには、アンダークラウドノードが 1 つと、コントローラーおよびコンピュートノードがあります。コンポーザブルネットワークは、コンポーザブルロールに割り当てられたノードに提示されます。この図では、StorageLeaf ネットワークは Ceph storage ノードとコンピュートノードに提供されています。 NetworkLeaf は、コンポーズする任意のネットワークの例を示しています。
図9.1 ルーティング対応のリーフ/スパイントポロジーの例
9.3. ルーティング対応のリーフ/スパインを使用したハードウェアプロビジョニング リンクのコピーリンクがクリップボードにコピーされました!
本項では、ハードウェアプロビジョニングのユースケースを記載し、コンポーザブルネットワークを使用したルーティング対応のリーフ/スパインの機能を実証するための評価環境のデプロイ方法について説明します。デプロイされる環境には、ルーティングが可能な複数のネットワークセットが設定されます。
ルーティング対応のリーフ/スパイン型ネットワークでプロビジョニングネットワークを使用するには、スイッチファブリックで設定した VXLAN トンネルと、各 ToR スイッチにトランキングされた拡張 VLAN の 2 つのオプションがあります。
今後のリリースでは、DHCP リレーを使用して、DHCPOFFER ブロードキャストがルーティング対応のレイヤー 3 ドメイン間を横断するようにできるようになる見込みです。
9.3.1. VLAN プロビジョニングネットワークの例 リンクのコピーリンクがクリップボードにコピーされました!
この例では、新規オーバークラウドノードはプロビジョニングネットワークを介してデプロイされます。 プロビジョニングネットワークは、コンポーズできず、また複数使用することはできません。代わりに、VLAN トンネルを使用してレイヤー 3 トポロジー全体にまたがります (図9.2「VLAN プロビジョニングネットワークトポロジー」を参照)。これにより、DHCPOFFER ブロードキャストを任意のリーフに送信できます。このトンネルは、Top-of-Rack (ToR) リーフスイッチ間の VLAN をトランキングすることによって確立されます。下図では、StorageLeaf ネットワークは Ceph Storage ノードとコンピュートノードに提供されます。NetworkLeaf はコンポーズする任意のネットワークの例を示しています。
図9.2 VLAN プロビジョニングネットワークトポロジー
9.3.2. VXLAN プロビジョニングネットワークの例 リンクのコピーリンクがクリップボードにコピーされました!
この例では、新規オーバークラウドノードはプロビジョニングネットワークを介してデプロイされます。 プロビジョニングネットワークは、コンポーズできず、また複数使用することはできません。代わりに、VXLAN トンネルを使用してレイヤー 3 トポロジー全体にまたがります (図9.3「VXLAN プロビジョニングネットワークトポロジー」を参照)。これにより、DHCPOFFER ブロードキャストを任意のリーフに送信できます。このトンネルは、Top-of-Rack (ToR) リーフスイッチ上で設定された VXLAN エンドポイントを使用して確立されます。
図9.3 VXLAN プロビジョニングネットワークトポロジー
9.3.3. プロビジョニング用ネットワークトポロジー リンクのコピーリンクがクリップボードにコピーされました!
ルーティング対応のリーフ/スパイン型ベアメタル環境にはレイヤー 3 対応のスイッチが 1 つまたは複数あります。このスイッチは、複数のレイヤー 2 ブロードキャストドメイン内の分離された VLAN 間でトラフィックをルーティングします。
この設計意図は、機能に応じてトラフィックを分離することです。たとえば、コントローラーノードが Internal API ネットワーク上で API をホストする場合、コンピュートノードが API にアクセスする際に独自のバージョンの Internal API ネットワークを使用する必要があります。このルーティングが機能するには、Internal API ネットワークを宛先とするトラフィックが必要なインターフェースを使用するように強制するルートが必要です。これは、supernet ルートを使用して設定することができます。たとえば、172.18.0.0/24 をコントローラーノード用の Internal API ネットワークに使用する場合には、2 番目の Internal API ネットワークに172.18.1.0/24、3 番目には 172.18.2.0/24、というように使用できます。その結果、各レイヤー 2 ドメイン内の各ロール向けに、ローカルの Internal API ネットワーク上のゲートウェイ IP を使用する、より大きな 172.18.0.0/16 スーパーネットをポイントするルートができます。
以下のネットワークは、director を使用してデプロイされた環境に使用することができます。
| ネットワーク | アタッチされるロール | インターフェース | ブリッジ | サブネット |
|---|---|---|---|---|
|
Provisioning |
すべて |
UC: nic2 およびその他: nic1 |
UC: br-ctlplane | |
|
External |
Controller |
nic7、OC: nic6 |
br-ex |
192.168.24.0/24 |
|
Storage |
Controller |
nic3、OC: nic2 |
172.16.0.0/24 | |
|
Storage Mgmt |
Controller |
nic4、OC: nic3 |
172.17.0.0/24 | |
|
Internal API |
Controller |
nic5、OC: nic4 |
172.18.0.0/24 | |
|
Tenant |
Controller |
nic6、OC: nic5 |
172.19.0.0/24 | |
|
Storage1 |
Compute1、Ceph1 |
nic8、OC: nic7 |
172.16.1.0/24 | |
|
Storage Mgmt1 |
Ceph1 |
nic9、OC: nic8 |
172.17.1.0/24 | |
|
Internal API1 |
Compute1 |
nic10, OC: nic9 |
172.18.1.0/24 | |
|
Tenant1 |
Compute1 |
nic11、OC: nic10 |
172.19.1.0/24 | |
|
Storage2 |
Compute2、Ceph2 |
nic12、OC: nic11 |
172.16.2.0/24 | |
|
Storage Mgmt2 |
Ceph2 |
nic13、OC: nic12 |
172.17.2.0/24 | |
|
Internal API2 |
Compute2 |
nic14、OC: nic13 |
172.18.2.0/24 | |
|
Tenant2 |
Compute2 |
nic15、OC:nic14 |
172.19.2.0/24 |
アンダークラウドは、外部/インターネット接続用のアップリンクにも接続されている必要があります。通常はアンダークラウドはアップリンクネットワークに接続されている唯一のノードです。これは、OpenStack デプロイメントとは別のインフラストラクチャー VLAN である可能性が高くなります。
9.3.4. トポロジー図 リンクのコピーリンクがクリップボードにコピーされました!
図9.4 コンポーザブルネットワークトポロジー
この図では、172.18.1.0 に戻るルートは、仮想 IP アドレス (VIP) がリッスンしているインターフェースと一致します。その結果、パケットはドロップされず、API 接続は想定通りに機能します。
9.3.5. カスタムロールへの IP アドレス割り当て リンクのコピーリンクがクリップボードにコピーされました!
ロールには、分離ネットワークごとにルートが必要です。各ロールには独自の NIC 設定があり、カスタムネットワークをサポートするには TCP/IP の設定をカスタマイズする必要があります。ゲートウェイのアドレスとルートをロールの NIC 設定にパラメーター化またはハードコード化することも可能です。
たとえば、既存の NIC 設定を基本テンプレートとして使用して、ネットワーク固有のパラメーターを全 NIC 設定に追加することができます。
デプロイメントで使用する各ロールの各カスタムネットワークに対してこの操作を実行してください。
9.3.6. ロール用のルートの割り当て リンクのコピーリンクがクリップボードにコピーされました!
各分離ネットワークにスーパーネットルートを 1 つ適用すべきです。スーパーネットルートには 172.18.0.0/16 よりも大きい推奨値を使用して、同じルートを各インターフェースに適用しますが、ローカルゲートウェイを使用します。
network-environment.yaml:Copy to Clipboard Copied! Toggle word wrap Toggle overflow
各ロールには、同じ機能によって使用される別のサブネットをポイントする各分離ネットワーク上のルートが必要です。Compute1 ノードが InternalApi VIP 上のコントローラーにコンタクトする場合には、トラフィックは InternalApi1 ゲートウェイを介した InternalApi1 インターフェースをターゲットにする必要があります。その結果、コントローラーから InternalApi1 ネットワークに戻るトラフィックは、InternalApi ネットワークゲートウェイを経由するはずです。
コントローラーの設定
Copy to Clipboard Copied! Toggle word wrap Toggle overflow Compute1 の設定
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
スーパーネットルートは、各ロール上の全分離ネットワークに適用して、デフォルトのゲートウェイ経由でトラフィックが送信されるのを防ぎます。これは、デフォルトではコントローラー以外のロールの場合は Control Plane ネットワークで、コントローラー上の場合には External ネットワークです。
Red Hat Enterprise Linux は受信トラフィックに対して厳格な逆方向パスフィルターをデフォルトで実装するので、これらのルートを分離ネットワーク上で設定する必要があります。API が Internal API インターフェース上でリッスンしている場合には、要求はその API で受信し、戻るパスのルートが Internal API インターフェース上にある場合にのみ要求を受理します。サーバーが Internal API ネットワークをリッスンしているが、クライアントに戻るパスが Control Plane 経由の場合には、逆方向パスフィルターによりそのサーバーは要求を破棄します。
たとえば、下図には、コントロールプレーンを経由してトラフィックのルーティングを試みて、成功しない例を示しています。ルーターからコントローラーノードに戻るルートは、VIP がリッスンしているインターフェースとは一致しないので、パケットは破棄されます。192.168.24.0/24 は直接コントローラーに接続され、Control Plane に対してローカルであると見なされます。
図9.5 コントロールプレーン経由のトラフィックルーティング
比較のために、Internal API ネットワーク経由のルーティングを以下に示します。
図9.6 Internal API 経由のトラフィックルーティング
以下の ExtraConfig 設定は、上記で説明した問題に対処します。InternalApi1 の値は、最終的には internal_api1 の値によって表され、大文字と小文字が区別される点に注意してください。
-
CephAnsibleExtraConfig:public_networkの設定には、全ストレージネットワークのリーフが一覧表示されます。cluster_networkエントリーには、Storage Management ネットワーク (1 リーフにつき 1 つ) が一覧表示されます。
9.3.7. NIC のカスタム定義 リンクのコピーリンクがクリップボードにコピーされました!
以下のカスタム定義は、ノード用の nic-config テンプレートに適用されています。以下の例は、デプロイメントに適した定義に変更してください。
network_data.yamlの値を確認します。これは、以下の例と似たような値であるはずです。Copy to Clipboard Copied! Toggle word wrap Toggle overflow 注記ネットワークサブネットと
allocation_poolsの値に対して実行される検証は現在ありません。これらの値が一致するように定義して、既存のネットワークと競合が発生しないことを確認してください。/home/stack/roles_data.yamlの値を確認します。これらは、以下の例と似たような値であるはずです。Copy to Clipboard Copied! Toggle word wrap Toggle overflow コンピュートノード用の
nic-configテンプレートを確認します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow openstack overcloud deployコマンドを実行して変更を適用します。以下に例を示します。Copy to Clipboard Copied! Toggle word wrap Toggle overflow