第25章 レイヤー 2 ゲートウェイの使用
25.1. 概要
本章では、Red Hat OpenStack Platform を OpenDaylight と共に使用して、SDN オーバーレイソリューションを作成する方法について説明します。このソリューションにより、デプロイメントはベアメタルワークロード、レガシー VLAN ドメイン、SR-IOV 対応ワークロード、仮想化ワークロードの間でシームレスに接続することができます。
OpenDaylight は、本リリースでは テクノロジープレビュー として提供しているため、Red Hat では全面的にはサポートしていません。これは、テスト目的のみでご利用いただく機能で、実稼働環境にデプロイすべきではありません。テクノロジープレビューについての詳しい情報は「テクノロジプレビュー機能のサポート範囲」を参照してください。
この接続は、物理 ToR (top-of-rack) スイッチ (コア スイッチではなく、アクセス スイッチとしても知られる) 上に VXLAN ゲートウェイをデプロイすることによって提供されます。ToR スイッチは、VXLAN カプセル化と HWVTEP スキーマをサポートしている必要があります。ネットワークの切り替えは、neutron のマルチセグメントネットワークと L2GW サービスプラグインを使用して実行されます。Southbound の設定は、OVSDB プロトコルと hardware_vtep
スキーマを実装する HWVTEP プラグインを使用して実装されます。
マルチセグメントのネットワークとは、複数のセグメント ID をトランキングするように設定されたネットワークです。このネットワークは、1 つは VLAN、もう 1 は VXLAN の複数のセグメントがあると見なされます。これにより、カプセル化された VXLAN トラフィックはコンピュートノードと ToR スイッチの間で切り替えられます。
本ガイドでは、一連の L2GW ユースケースについて説明し、コンピュートノードで SR-IOV 設定は必須となっています。
25.1.1. ネットワークトポロジー
以下の図は、SDN オーバーレイにおける SR-IOV 接続を示しています。
25.1.2. 要件
- director ベースのデプロイには、OpenDaylight ロールを有効にする必要があります。https://access.redhat.com/documentation/ja-jp/red_hat_openstack_platform/12/html/red_hat_opendaylight_installation_and_configuration_guide/ を参照してください。
- ユースケース 1 から 6 では、コンピュートノードで SR-IOV を有効化する必要があります。director ベースのデプロイメントの場合は、https://access.redhat.com/documentation/ja-jp/red_hat_openstack_platform/12/html-single/network_functions_virtualization_planning_and_configuration_guide/#assembly_sriov_parameters を参照してください。
25.2. ユースケース 1: 1 台の SR-IOV コンピュートノード上に 2 つのインスタンスがある場合
このユースケースは、SR-IOV を有効化した同じコンピュートノード上に 2 つのインスタンスがあります。このシナリオでは、VXLAN トンネルが ToR からコントローラーノードに通ります。
- nova がインスタンスを起動する時には、その仮想マシンの DHCP リクエストは SR-IOV NIC を出て、ToR 上の eth2 で入ります。
-
ToR スイッチ (
hardware_vtep
スキーマで OVSDB を実行) は、DHCP パケットを VXLAN トンネル内にカプセル化します。 - DHCP パケットは、TOR とコントローラーノード間で VXLAN トンネルを介して送信されます。
- DHCP パケットはコントローラーノード上の VXLAN トンネルを出て、VXLAN ヘッダーが削除された後に、ネイティブの DHCP パケットが処理されて、コントローラーノードから DHCP 応答が送信されます。
- VXLAN ヘッダーが DHCP 応答に追加され、VXLAN トンネルを介してコントローラーノードから ToR スイッチに送られます。
- ToR では、VXLAN ヘッダーが削除され、VLAN タグが DHCP パケットに追加されます。
- DHCP パケット (VLAN タグ付き) は ToR を介して送信され、コンピュートノード 2 で受信されます。ここで、DHCP 応答が受信され、インスタンスによって処理されます。
これで各インスタンスに IP アドレスが割り当てられ、コンピュートノード上の VM1
と VM2
の間の IP パケットは Intel 82599ES NIC によりローカルでスイッチされます。この例で使用している NIC は、ローカルスイッチングをサポートしている Intel 82599ES なので、VM1 と VM2 の間の IP パケットは NIC から外に送信されません。ローカルスイッチングをサポートしていないベンダーの NIC の場合は、VM1 から VM2 へのパケットは ToR によってスイッチされます。
ノード 1:
- Red Hat Enterprise Linux 7
- OpenStack コントローラーノード
- OpenStack コンピュートノード
- OpenDaylight ロール
ノード 2:
- Red Hat Enterprise Linux 7
- OpenStack コンピュートノード
-
SR-IOV が NIC
em1
で有効化 -
ネットワークタグ:
2901
25.3. ユースケース 2: 別のコンピュートノード (複数) 上にインスタンスがある場合
このユースケースは ユースケース 1 と似ており、DHCP は同じように機能します。異なるのは、VM1
(コンピュートノード 1 上) と VM2
(コンピュートノード 2 上) の間の IP 転送が ToR スイッチによって実行される点です。これは、赤の破線で示しています。
25.4. ユースケース 3: ハードウェア VEB 上のインスタンスにソフトウェア VEB 上のインスタンスが接続する場合
このユースケースでは、ソフトウェア VEB (Virtual Ethernet Bridge) とハードウェア VEB にアタッチされたインスタンス間で接続を確立しましす。
ノード 1:
- Red Hat Enterprise Linux 7
- OpenStack コントローラーノード
- OpenStack コンピュートノード
- OpenDaylight ロール
ノード 2:
- Red Hat Enterprise Linux 7
- OpenStack コンピュートノード
-
SR-IOV が NIC
em1
で有効化 -
ネットワークタグ:
2900
25.5. ユースケース 4: SR-IOV Physical Function (PF) に接続されたインスタンスの場合
このユースケースでは、VM2
(コンピュートノード 2 上) の受信および送信トラフィックは、ToR スイッチを介して、VM2
にアタッチされた SR-IOV PF をトラバースします。
25.6. ユースケース 5: ToR スイッチが 2 つある場合
このユースケースでは、3 台のコンピュートノードが 2 つの異なる ToR スイッチに接続されています。multinet
という名前の単一の neutron ネットワークが 3 台のノードをすべて結んでおり、インスタンスは同じ論理レイヤー 2 ネットワーク上で相互に接続することができます。
25.7. ユースケース 6 : 同じインターフェースを共有する異なる複数のネットワークに接続されたインスタンスの場合
このユースケースでは、VM1
および VM2
は別々のコンピュートノード上にあり、同じ neutron ネットワークを共有しています。VM3
と VM4
も別々のノード上にあり、同じ neutron ネットワークを共有しています。両方の neutron ネットワークのトラフィックは各ノード上の同じ物理 NIC を通過します。
VM1 と VM2:
-
接続されている neutron ネットワーク:
multinet
-
VXLAN VNI:
1500
-
VLAN タグ:
2901
-
接続されている neutron ネットワーク:
VM3 と VM4:
-
接続されている neutron ネットワーク:
multinet1
-
VXLAN VNI:
1501
-
VLAN タグ:
2902
-
接続されている neutron ネットワーク:
25.8. SDN トポロジーの構築
L2GW VXLAN トンネルのスイッチの設定および準備のための設定手順は、各 ToR ベンダースイッチ固有である可能性が高いので、以下に記載するステップの設定コマンドは、スイッチベンダーのマニュアルを参照して確認してください。
各 ToR スイッチには以下が必要となります:
- OVSDB の有効化と設定
- データネットワーク上の ODL コントローラーへの IP 接続。これは、VXLAN トンネルのトランスポートに必要です。
- 管理ネットワーク上の ODL コントローラーへの IP 接続。これは、OVSDB の制御メッセージに必要です。
25.9. OpenDaylight の設定
- director ベースのデプロイには、OpenDaylight ロールを有効にする必要があります。https://access.redhat.com/documentation/ja-jp/red_hat_openstack_platform/12/html/red_hat_opendaylight_installation_and_configuration_guide/ を参照してください。
OpenDaylight (ODL) のデプロイが完了したら、必要なトランスポートゾーンを作成する必要があります。
25.9.1. トランスポートゾーンの設定
本項では OpenDaylight 用のトランスポートゾーンを作成します。以下の例で使用している IP アドレスは、お使いのデプロイメントに適した IP アドレスに変更する必要があります。
トランスポートゾーンを作成します。以下に例を示します。
URL: http://${ODL-IP}:8181/restconf/config/itm:transport-zones/ JSON: { "transport-zone": [ { "zone-name": "TZA", "subnets": [ { "prefix": "192.168.254.0/24", "vlan-id": 0, "vteps": [ { "dpn-id": 95311090836804, "portname": "eth1", "ip-address": "192.168.254.31" } ], "gateway-ip": "0.0.0.0" } ], "tunnel-type": "odl-interface:tunnel-type-vxlan" } ] }
VXLAN トンネルネットワーク (VTEP)の一部となるコントローラーノードとコンピュートノードをトランスポートゾーンに追加します。そのためには、デバイスの
dpnid
が必要です。これは、以下のように取得することができます。$ curl -s -u admin:admin -X GET http://10.8.125.240:8181/restconf/operational/odl-interface-meta:bridge-ref-info/ { "bridge-ref-info": { "bridge-ref-entry": [ { "bridge-reference": "/network-topology:network-topology/network-topology:topology[network-topology:topology-id='ovsdb:1']/network-topology:node[network-topology:node-id='ovsdb://uuid/2647ac59-281f-4968-beb1-7a7d64990f19/bridge/br-int']", "dpid": 181136841129213 } ] } }
sudo ovs-vsctl show
を実行してovsdb
UUID を取得します。これは、上記のcurl
コマンドでデバイスのdpnid
を特定するのに必要です。$ sudo ovs-vsctl show 2647ac59-281f-4968-beb1-7a7d64990f19 Manager "tcp:10.8.125.240:6640" is_connected: true Bridge br-int
bridge-ref curl コマンドを使用して取得した
dpn-id
を指定して、デバイスをトランスポートゾーンに追加します。これには、Postman を使用することができます。もう 1 つの方法として、代わりにcurl
を使用することができます。この例では、IP アドレスが 192.168.254.31 のリモート VTEP を追加します。リモート VTEP のトンネルインターフェースはeth1
で、リモート VTEP のdpn-id
は以下に示したとおりです。OpenDaylight が VLAN ベースのネットワーク上でリッスンしている場合には、その vlan-id を指定する必要があります。$ curl -X POST -H "Authorization: Basic YWRtaW46YWRtaW4=" -H "Content-Type: application/json" -H "Cache-Control: no-cache" -H "Postman-Token: ae2ebaee-8813-79df-7114-0bc786287793" -d '{ "transport-zone": [ { "zone-name": "zone1", "subnets": [ { "prefix": "192.168.254.0/24", "vlan-id": 0, "vteps": [ { "dpn-id": 181136841129213, "portname": "eth1", "ip-address": "192.168.254.31" } ], "gateway-ip": "0.0.0.0" } ], "tunnel-type": "odl-interface:tunnel-type-vxlan" } ] } ' "http://10.8.125.240:8181/restconf/config/itm:transport-zones/"
その結果、出力される一覧の各 VTEP には、以下のような属性が表示されます。
-
ip-address
: リモートの VTEP IP アドレス -
portname
: トンネルインターフェースのポート名 -
dpn-id
: 上記のステップで取得した値
-
この例の
curl
コマンドは、zone1
という名前のトランスポートゾーンを作成します。curl -X POST -H "Authorization: Basic YWRtaW46YWRtaW4=" -H "Content-Type: application/json" -H "Cache-Control: no-cache" -H "Postman-Token: ae2ebaee-8813-79df-7114-0bc786287793" -d '{ "transport-zone": [ { "zone-name": "zone1", "subnets": [ { "prefix": "192.0.2.0/24", "vlan-id": 0, "vteps": [ { "dpn-id": 92455225558023, "portname": "eth3", "ip-address": "192.0.2.6" } ], "gateway-ip": "0.0.0.0" } ], "tunnel-type": "odl-interface:tunnel-type-vxlan" } ] } ' "http://10.8.125.240:8181/restconf/config/itm:transport-zones/"
- ToR スイッチが OpenDaylight ノードを VTEP マネージャーとして使用するように設定します。設定コマンドと構文については、ToR スイッチベンダーのマニュアルを参照してください。
25.10. OpenStack ネットワークの作成
2 つのネットワークセグメントで構成される
multinet
という名前のネットワークを作成します。1 番目のセグメントは VLAN タイプで、仮想マシンにアタッチされる SRIOV Virtual Function の VLAN タグの設定に使用されます。2 番目のセグメントは VXLAN タイプで、ToR スイッチから ODL コントローラーノードおよびコンピュートノードへの VXLAN トンネルに使用されます。$ neutron net-create multinet --segments type=dict list=true provider:physical_network='',provider:segmentation_id=1500,provider:network_type=vxlan provider:physical_network=physnet_sriov,provider:segmentation_id=2201,provider:network_type=vlan
multinet
ネットワーク用のサブネットを作成します。$ neutron subnet-create multinet --allocation-pool start=10.100.5.2,end=10.100.5.254 --name mn-subnet --dns-nameserver 8.8.8.8 10.100.5.0/24
適切な SR-IOV ドライバー (例: Intel
ixgbe
ドライバー) を含む Red Hat Enterprise Linux 7 イメージを作成します。完了したら、イメージを glance にインポートします。$ glance image-create --name rhel7 --disk-format qcow2 --container-format bare --visibility public --file /opt/images/rhel7.qcow2
L2 ゲートウェイを作成します。以下のコマンドは、
gw1
という名前の L2GW を作成し、アクセスポートはeth2
とeth3
です。注記ポート更新の API には、現在いくつかの制約があるため、このコマンドに全ゲートウェイポートを含めることを考慮してください。
$ neutron l2-gateway-create gw1 --tenant_id $(openstack project list | grep '\sadmin' | awk '{print $2}') --device name=hwvtep,interface_names="eth1;eth2"
- name: ToR スイッチの設定に一致する必要があります。これは、hardware_vtep スキーマの Physical_Switch テーブル内で name として定義されています。ToR スイッチベンダーのマニュアルを参照してください。
L2 ゲートウェイの接続を作成します。これにより、ToR スイッチと、トランスポートゾーンで定義されている VTEP との間のトンネルが確立します。
$ neutron l2-gateway-connection-create gw1 multinet --default-segmentation-id 2201 $ neutron l2-gateway-connection-create gw1 multinet1 --default-segmentation-id 2203
以下に示す L2GW 作成の代替方法に注意してください。この例は、VLAN タグをサポートしない SR-IOV PF を設定する場合に役立ちます。この例では、
eth1
にはタグがなく、eth2
には2201
タグが付いています。$ neutron l2-gateway-create gw1 --tenant_id $(openstack project list | grep '\sadmin' | awk '{print $2}') --device name=hwvtep,interface_names="eth1|0;eth2|2201" $ neutron l2-gateway-connection-create gw1 multinet
コンピュートノード上に SR-IOV VF ポートを作成します。
$ port1_id=$(neutron port-create multinet --name sriov_port1 --binding:vnic_type direct --device-owner nova-compute | grep "\ id\ " | awk '{ print $4 }') $ port2_id=$(neutron port-create multinet --name sriov_port2 --binding:vnic_type direct --device-owner nova-compute | grep "\ id\ " | awk '{ print $4 }') $ port3_id=$(neutron port-create multinet --name sriov_port3 --binding:vnic_type direct --device-owner nova-compute | grep "\ id\ " | awk '{ print $4 }')
コンピュートノード上に
direct-physical
SR-IOV PF ポートを作成します。$ port2_id=$(neutron port-create multinet --name sriov_port2 --binding:vnic_type direct-physical --device-owner nova-compute | grep "\ id\ " | awk '{ print $4 }')
コンピュートノード上にインスタンスを作成します。これらは、前のステップで作成した SR-IOV ポートに接続されます。
注記イメージ内のゲスト OS が Network Manager を使用している場合には、DHCP は、SR-IOV VF インターフェースでのみ機能します。Red Hat Enterprise Linux の場合は、イメージに対して virt-customize を使用して、ifcfg-eth0 をシステムが使用するインターフェースの名前 (例: ens4) に変更する必要があります。
$ nova boot --poll --flavor m1.small --image rhel7 --nic port-id=$port1_id --key-name admin_key sriov-vm1 $ nova boot --poll --flavor m1.small --image rhel7 --nic port-id=$port3_id --key-name admin_key sriov-vm3 $ nova boot --poll --flavor m1.small --image rhel7 --nic port-id=$port2_id --key-name admin_key sriov-vm2 $ nova boot --poll --flavor m1.small --image rhel7 --nic net-id=$(neutron net-list | grep -w multinet | awk '{print $2}') --key-name admin_key vmvx01
注記本項では、SR-IOV インターフェースを使用してインスタンスを相互接続する方法について説明しますが、L2GW neutron ドライバーを引き続き使用して基本的な接続を確立できる点に注意してください。これには、VXLAN ベースのプロジェクトネットワークの L2 ブロードキャストドメインを、外部の VLAN ベースのプロバイダーネットワークに拡張する必要があります。このユースケースでは、複数のプロバイダーネットワークを作成する必要はなく、標準の VXLAN ネットワークを使用します。これにより、外部のアプライアンスを使用して通常のインスタンスを接続することができます。
25.11. レビュー
上記のステップに従って作業を完了すると、インスタンスの 1 つに SSH 接続してから、他のコンピュートノード上でホストされているインスタンスに ping できるようになるはずです。その結果 ICMP トラフィックは OVS と ToR スイッチを、カプセル化されたレイヤー 2 トンネルとしてトラバースするようになります。