第1章 はじめに

本ガイドは、Red Hat OpenStack Platform 環境に向けたスパイン/リーフ型ネットワークのトポロジーの構築方法についての情報を提供します。これには、完全なエンドツーエンドのシナリオと、お使いの環境でより広範囲なネットワークトポロジーを複製するのに役立つサンプルファイルが含まれます。

1.1. スパイン/リーフ型ネットワーク

Red Hat OpenStack Platform のコンポーザブルネットワークアーキテクチャーにより、ネットワークを、一般的なルーティング対応のスパイン/リーフ型データセンタートポロジーに適合させることができます。ルーティング対応のスパイン/リーフの実際の適用では、リーフはコンピュートまたはストレージのコンポーザブルロールに相当し、図1.1「ルーティング対応のリーフ/スパイントポロジーの例」に示したように、通常はデータセンターのラック内にあります。Leaf 0 ラックにはアンダークラウドノード、コントローラー、コンピュートノードがあります。コンポーザブルネットワークはコンポーザブルロールに割り当てられたノードに提示されます。以下の図では、

  • StorageLeaf ネットワークは、Ceph Storage とコンピュートノードに提示されます。
  • NetworkLeaf は、構成する任意のネットワークの例を示します。

図1.1 ルーティング対応のリーフ/スパイントポロジーの例

OpenStack Spine Leaf 466050 0218 routed

1.2. ネットワークトポロジー

ルーティング対応のリーフ/スパイン型ベアメタル環境にはレイヤー 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 supernet をポイントするルートができます。

このシナリオでは、以下のネットワークを使用します。

表1.1 Leaf 0 ネットワーク

ネットワークアタッチされているロールインターフェースブリッジサブネット

プロビジョニング / コントロールプレーン

すべて

nic1

br-ctlplane (アンダークラウド)

192.168.10.0/24

Storage

Controller

nic2

 

172.16.0.0/24

Storage Mgmt

Controller

nic3

 

172.17.0.0/24

Internal API

Controller

nic4

 

172.18.0.0/24

Tenant

Controller

nic5

 

172.19.0.0/24

External

Controller

nic6

br-ex

10.1.1.0/24

表1.2 Leaf 1 Networks

ネットワークアタッチされているロールインターフェースブリッジサブネット

プロビジョニング / コントロールプレーン

すべて

nic1

br-ctlplane (アンダークラウド)

192.168.11.0/24

Storage1

Compute1、Ceph1

nic2

 

172.16.1.0/24

Storage Mgmt1

Ceph1

nic3

 

172.17.1.0/24

Internal API1

Compute1

nic4

 

172.18.1.0/24

Tenant1

Compute1

nic5

 

172.19.1.0/24

表1.3 Leaf 2 Networks

ネットワークアタッチされているロールインターフェースブリッジサブネット

プロビジョニング / コントロールプレーン

すべて

nic1

br-ctlplane (アンダークラウド)

192.168.12.0/24

Storage2

Compute2、Ceph2

nic2

 

172.16.2.0/24

Storage Mgmt2

Ceph2

nic3

 

172.17.2.0/24

Internal API2

Compute2

nic4

 

172.18.2.0/24

Tenant2

Compute2

nic5

 

172.19.2.0/24

表1.4 Supernet Routes

ネットワークサブネット

Storage

172.16.0.0/16

Storage Mgmt

172.17.0.0/16

Internal API

172.18.0.0/16

Tenant

172.19.0.0/16

OpenStack Spine Leaf 466050 0218 API network

1.3. スパイン/リーフ型ネットワークの要件

レイヤー 3 ルーティング対応アーキテクチャーを使用したネットワーク上でオーバークラウドをデプロイするには、以下の要件を満たす必要があります。

レイヤー 3 ルーティング
異なるレイヤー 2 セグメント間のトラフィックを有効にするには、ネットワークインフラストラクチャーでルーティングを設定する必要があります。これは、静的または動的に設定することができます。
DHCP リレー
アンダークラウドにローカルでない各レイヤー 2 セグメントには、dhcp-relay を指定する必要があります。DHCP 要求は、アンダークラウドが接続されているプロビジョニングネットワークのセグメントでアンダークラウドに対して送信する必要があります。
注記

アンダークラウドは 2 つの DHCP サーバーを使用します。1 つは、ベアメタルノードのイントロスペクション用で、もう 1 つはオーバークラウドノードのデプロイ用です。dhcp-relay の設定時に要件を理解するには、DHCP リレーの設定を必ず読んでください。

1.4. スパイン/リーフの制限事項

  • コントローラーロールなどの一部のロールは、仮想 IP アドレスとクラスタリングを使用します。この機能の背後にあるメカニズムには、ノード間のレイヤー 2 ネットワーク接続が必要です。それらのノードはすべて同じリーフ内に配置されます。
  • Networker ノードにも同様の制限が適用されます。ネットワークサービスは、Virtual Router Redundancy Protocol (VRRP) を使用するネットワーク内にデフォルトの高可用性パスを実装します。VRRP は仮想ルーターの IP アドレスを使用するので、マスターとバックアップノードを同じ L2 ネットワークセグメントに接続する必要があります。
  • テナントまたはプロバイダーネットワークをVLAN セグメンテーションと共に使用する場合には、すべての Networkerノードおよびコンピュートノード間で特定の VLAN を共有する必要があります。
注記

ネットワークサービスは、複数の Networker ノードセットで設定することが可能です。各セットはそれらのネットワークのルートを共有し、VRRP が Networker ノードの各セット内の高可用性のデフォルトパスを提供します。このような構成では、ネットワークを共有する全 Networker ノードが同じ L2 ネットワークセグメント上にある必要があります。