インスタンスが相互に通信する場所を提供し、DHCP を使用して IP アドレスを受け取るためにネットワークを作成します。ネットワークは、Red Hat OpenStack Platform デプロイメントまたは物理ネットワークなどの別の場所の外部ネットワークと統合することも可能です。このような統合を行うと、インスタンスは外部システムとの通信および外部から到達が可能となります。このネットワークを外部の物理ネットワークと統合するには、「物理ネットワークのブリッジ」の項を参照してください。

ネットワークの作成時には、ネットワークで複数のサブネットをホスト可能である点を認識しておくことが重要です。これは、明らかに異なるシステムを同じネットワークでホストする場合やそれらのシステムを分離する手段を希望する場合に役立ちます。たとえば、Web サーバーのトラフィックが 1 つのサブネット上のみで伝送される一方で、データベースのトラフィックは別のサブネット上を通過するように指定することができます。サブネットは相互に分離され、別のサブネットと通信する必要のあるインスタンスのトラフィックは、ルーターによって転送される必要があります。大量のトラフィックを必要とする複数のシステムを、同じサブネットに配置すると、ルーティングの必要がなく、それに伴うレイテンシーや負荷を回避することができます。

1. Dashboard で プロジェクト > ネットワーク > ネットワーク を選択します。

2. +ネットワークの作成 をクリックして、以下を指定します。

3. 次へ ボタンをクリックして サブネット タブで以下を指定します。

4. 次へ をクリックして DHCP オプションを指定します。

5. 作成 をクリックします。

作成が完了したネットワークは、ネットワーク タブに表示されます。必要に応じて、 編集 をクリックしてオプションを変更することができます。これで、インスタンスの作成時には、このサブネットを使用できるようになりました。作成後には、指定した DHCP オプションがインスタンスに適用されます。

管理者は、管理 の画面からネットワークを作成する際に高度なネットワークオプションを使用することができます。これらのオプションは、使用するネットワークタイプを定義し、テナントの指定を可能にします。

1. Dashboard で、管理 > ネットワーク > ネットワークの作成 > プロジェクト を選択します。プロジェクト から新規ネットワークをホストする先のプロジェクトを選択します。

2. プロバイダーネットワーク種別 でオプションを確認します。

ネットワークの作成 をクリックし、プロジェクトのネットワークトポロジーをチェックして、ネットワークが適切に作成されたことを確認します。

新規ネットワークからのトラフィックのルーティングを許可するには、そのサブネットを既存の仮想ルーターへのインターフェースとして追加する必要があります。

1. Dashboard で プロジェクト > ネットワーク > ルーター を選択します。

2. ルーター 一覧で仮想ルーターの名前をクリックしてから、+インターフェースの追加 をクリックします。サブネット一覧では、新規サブネットの名前を選択します。このフィールドでインターフェースの IP アドレスを任意で指定することができます。

3. インターフェースの追加 をクリックします。

ネットワーク上のインスタンスで、サブネットの外部のシステムとの通信ができるようになりました。

以前に作成したネットワークを削除する必要がある場合があります (例: ハウスキーピングやデコミッションプロセスの一環としての処理など)。ネットワークを正常に削除するには、まず使用中のインターフェースを削除または切断する必要があります。以下の手順では、プロジェクト内でネットワークを削除するステップ、そのステップで利用するインターフェースについて説明します。

1. Dashboard で プロジェクト > ネットワーク > ネットワーク を選択します。対象のネットワークのサブネットに関連付けられたルーターインターフェースをすべて削除します。インターフェースを削除するには、ネットワーク 一覧にある対象のネットワークをクリックして ID フィールドを確認し、削除するネットワークの ID 番号を特定します。そのネットワークの割り当て済みサブネットにはすべて、この値が ネットワーク ID フィールドに示されます。

2. プロジェクト > ネットワーク > ルーター を選択して、ルーター の一覧から対象の仮想ルーターの名前をクリックし、削除するサブネットに接続されているインターフェースを特定します。ゲートウェイ IP として機能していた IP アドレスで他のインターフェースと区別することができます。また、以前のステップで書き留めた ID とインターフェースのネットワーク ID が一致するかどうかを確認することによってさらに識別することができます。

3. 対象のインターフェースの インターフェースの削除 ボタンをクリックします。

プロジェクト > ネットワーク > ネットワークを選択して、対象のネットワークの名前をクリックします。対象のサブネットのサブネットの削除ボタンをクリックします。

プロジェクト > ネットワーク > ネットワーク を選択して、削除するネットワークを選択します。プロンプトが表示された際と、次の確認画面で ネットワークの削除 をクリックしてください。

Red Hat OpenStack Platform 8 以前では、ネットワーク、ルーター、ポートなど、過去にプロジェクトに割り当てられた古いリソースがプロジェクトの削除後にも残っている場合がありました。以前のリリースでは、これらの古いリソースは、正しい順番にリソースを慎重に、手動で削除する必要がありました。Red Hat OpenStack Platform 9 で、これに対応し、neutron purge コマンドを使用することで、特定のプロジェクトに以前に割り当てられた neutron リソースをすべて削除できるようになりました。

たとえば、削除前に test-project の neutron リソースを削除するには、以下を実行します。

# openstack project list
+----------------------------------+--------------+
| ID                               | Name         |
+----------------------------------+--------------+
| 02e501908c5b438dbc73536c10c9aac0 | test-project |
| 519e6344f82e4c079c8e2eabb690023b | services     |
| 80bf5732752a41128e612fe615c886c6 | demo         |
| 98a2f53c20ce4d50a40dac4a38016c69 | admin        |
+----------------------------------+--------------+

# neutron purge 02e501908c5b438dbc73536c10c9aac0
Purging resources: 100% complete.
Deleted 1 security_group, 1 router, 1 port, 1 network.

# openstack project delete 02e501908c5b438dbc73536c10c9aac0

サブネットは、インスタンスにネットワーク接続を許可する手段です。インスタンスの作成プロセスの一環として、各インスタンスはサブネットに割り当てられるため、最適なインスタンスの配置を考慮してインスタンスの接続性の要件に対応することが重要です。サブネットは既存のネットワークで作成されます。OpenStack Networking のテナントネットワークでは、複数のサブネットをホストできることを念頭に入れておいてください。これは、明らかに異なるシステムを同じネットワークでホストする場合やそれらのシステムを分離する手段を希望する場合に役立ちます。たとえば、Web サーバーのトラフィックが 1 つのサブネット上のみで伝送される一方で、データベースのトラフィックは別のサブネット上を通過するように指定することができます。サブネットは相互に分離され、別のサブネットと通信する必要のあるインスタンスのトラフィックは、ルーターによって転送される必要があります。大量のトラフィックを必要とする複数のシステムを、同じサブネットに配置すると、ルーティングの必要がなく、それに伴うレイテンシーや負荷を回避することができます。

使用しなくなったサブネットは削除することができます。ただし、インスタンスがまだそのサブネットを使用するように設定されている場合には、削除を試みても失敗し、Dashboard にエラーメッセージが表示されます。以下の手順では、ネットワーク内にある特定のサブネットを削除する方法を説明します。

Dashboard で プロジェクト > ネットワーク > ネットワーク を選択して、使用するネットワーク名をクリックします。対象のサブネットを選択して、サブネットの削除 をクリックします。

OpenStack Networking は、SDN をベースとする仮想ルーターを使用したルーティングサービスを提供します。インスタンスが外部のサブネット (物理ネットワーク内のサブネットを含む) と通信するには、ルーターは必須です。ルーターとサブネットはインターフェースを使用して接続します。各サブネットにはルーターに接続するための独自のインターフェースが必要です。ルーターのデフォルトゲートウェイは、そのルーターが受信するトラフィックのネクストホップを定義します。そのネットワークは通常、仮想ブリッジを使用して、外部の物理ネットワークにトラフィックをルーティングするように設定されます。

1. Dashboard で プロジェクト > ネットワーク > ルーター を選択し、+ルーターの作成 をクリックします。

2. 新規ルーターの説明的な名前を入力し、ルーターの作成 をクリックします。

3. ルーター 一覧に新たに追加されたルーターのエントリーの横にある ゲートウェイの設定 をクリックします。

4. 外部ネットワーク の一覧で、外部ロケーション宛のトラフィックを受信するネットワークを指定します。

5. ゲートウェイの設定 をクリックします。ルーターを追加した後に行う次のステップでは、作成済みのサブネットがこのルーターを使用してトラフィックを受信できるように設定します。これは、サブネットとルーター間のインターフェースを作成することによって行います。

インターフェースが接続されていないルーターは削除することができます。以下の手順では、最初にルーターのインターフェースを削除してからルーター自体を削除するステップを説明します。

1. Dashboard で プロジェクト > ネットワーク > ルーター を選択し、削除するルーター名をクリックします。

2. 内部インターフェース タイプのインターフェースを選択します。インターフェースの削除 をクリックします。

3. ルーター 一覧から対象のルーターを選択して ルーターの削除 をクリックします。

インターフェースにより、ルーターをサブネットと相互接続することができます。これにより、ルーターは、インスタンスを中継するサブネットの外部にある宛先にインスタンスが送信するトラフィックを転送することが可能となります。以下の手順では、ルーターのインターフェースを追加して、サブネットに接続します。以下の手順では、ネットワークトポロジー機能を使用します。この画面には、全仮想ルーターとネットワークを示した図が表示され、ネットワーク管理タスクを実行することができます。

1. Dashboard で プロジェクト > ネットワーク > ネットワークトポロジー を選択します。

2. 管理するルーターを特定して インターフェースの追加 をクリックします。

3. ルーターを接続するサブネットを指定します。オプションで IP アドレスを指定することができます。このアドレスを指定しておくと、インターフェースに対して ping を実行して成功した場合にはトラフィックのルーティングが想定通りに機能していることを確認できるので、テストやトラブルシューティングに役立ちます。

4. インターフェースの追加 をクリックします。

ネットワークトポロジー の図が自動的に更新され、ルーターとサブネットの間の新規インターフェース接続が反映されます。

ルーターがトラフィックを転送する必要がなくなった場合には、サブネットへのインターフェースを削除することができます。以下の手順では、インターフェースの削除に必要なステップを説明します。

1. Dashboard で プロジェクト > ネットワーク > ルーター を選択します。

2. 削除するインターフェースをホストしているルーターの名前をクリックします。

3. (内部インターフェース タイプの) インターフェースを選択し、インターフェースの削除 をクリックします。

本項に記載する手順に従って OpenStack Networking における IP アドレスの確保を管理することができます。

# neutron subnet-create --name SUBNET_NAME --enable_dhcp=False --allocation_pool start=IP_ADDRESS,end=IP_ADDRESS --gateway=IP_ADDRESS NETWORK_NAME CIDR

# neutron subnet-create --name public_subnet --enable_dhcp=False --allocation_pool start=192.168.100.20,end=192.168.100.100 --gateway=192.168.100.1 public 192.168.100.0/24

# nova floating-ip-associate INSTANCE_NAME IP_ADDRESS

# nova floating-ip-associate corp-vm-01 192.168.100.20

# neutron floatingip-create public
+---------------------+--------------------------------------+
| Field               | Value                                |
+---------------------+--------------------------------------+
| fixed_ip_address    |                                      |
| floating_ip_address | 192.168.100.20                       |
| floating_network_id | 7a03e6bc-234d-402b-9fb2-0af06c85a8a3 |
| id                  | 9d7e2603482d                         |
| port_id             |                                      |
| router_id           |                                      |
| status              | ACTIVE                               |
| tenant_id           | 9e67d44eab334f07bf82fa1b17d824b6     |
+---------------------+--------------------------------------+

# neutron port-list
+--------+------+-------------+--------------------------------------------------------+
| id     | name | mac_address | fixed_ips                                              |
+--------+------+-------------+--------------------------------------------------------+
| ce8320 |      | 3e:37:09:4b | {"subnet_id": "361f27", "ip_address": "192.168.100.2"} |
| d88926 |      | 3e:1d:ea:31 | {"subnet_id": "361f27", "ip_address": "192.168.100.5"} |
| 8190ab |      | 3e:a3:3d:2f | {"subnet_id": "b74dbb", "ip_address": "10.10.1.25"}|
+--------+------+-------------+--------------------------------------------------------+

# neutron floatingip-associate 9d7e2603482d 8190ab

OpenStack Networking は 1 つの L3 エージェントあたり 3 つの Floating IP プールをサポートします。このため、L3 エージェントをスケールアウトすることによって追加の Floating IP プールを作成することができます。

以下の手順では、仮想ネットワークを物理ネットワークにブリッジして仮想インスタンスとの間の接続を可能にします。例として示した物理 eth0 インターフェースは br-ex ブリッジにマップされます。この仮想ブリッジは、物理ネットワークと仮想ネットワークを中継する機能を果たします。これにより、eth0 を通過するトラフィックはすべて、設定した Open vSwitch を使用してインスタンスに到達します。物理 NIC を仮想 Open vSwitch ブリッジにマッピングします。

# vi /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=br-ex
ONBOOT=yes
Configure the virtual bridge with the IP address details that were previously allocated to eth0:
# vi /etc/sysconfig/network-scripts/ifcfg-br-ex
DEVICE=br-ex
DEVICETYPE=ovs
TYPE=OVSBridge
BOOTPROTO=static
IPADDR=192.168.120.10
NETMASK=255.255.255.0
GATEWAY=192.168.120.1
DNS1=192.168.120.1
ONBOOT=yes

インスタンスに Floating IP アドレスを割り当てて、物理ネットワークが利用できるようにすることができます。

OpenStack のデプロイメントを計画する際には、デプロイメントに使用するサブネットの数から開始します。この数をもとに、各アドレスをどのように使用していくかを割り当てる必要があります。複数のサブネットがあると、システム間のトラフィックを VLAN に分割することができます。たとえば、通常、管理または API トラフィックは、Web トラフィックにサービスを提供するシステムと同じネットワークをまた VLAN 間のトラフィックは、ルーター経由で伝送する必要があります。このルーターを利用することで、ファイアウォールを設置してさらにトラフィックの流れを統括する機会ができます。

通常、異種のネットワークトラフィックをホストする場合には、別個の VLAN をトラフィックに割り当てます。たとえば、各種ネットワークごとに別の VLAN を指定します。当然ながら、外部ネットワークは外部の物理ネットワークにのみルーティングが可能です。Red Hat OpenStack Platform 9 では、DHCP サービスは director により提供されます。

以下のシステムは割り当てられた範囲からの IP アドレスを消費します。

これらの仮想リソースは、OpenStack Networking の IP アドレスを消費します。これらはクラウドインフラストラクチャーではローカルとみなされ、外部の物理ネットワークにあるシステムから到達できなくても構いません。

以下の例では、7 つのサブネット (各サブネットのアドレス数) に対応するように複数のネットワークを割り当てています。

以下の手順では、特定のルーターに接続されたポートをすべて一覧表示し、ポートの状態 (DOWN または ACTIVE) を取得する方法を解説します。

1. r1 とうい名前のルーターにアタッチされているポートをすべて表示します。

#  neutron router-port-list r1

結果の例:

+--------------------------------------+------+-------------------+--------------------------------------------------------------------------------------+
| id                                   | name | mac_address       | fixed_ips                                                                            |
+--------------------------------------+------+-------------------+--------------------------------------------------------------------------------------+
| b58d26f0-cc03-43c1-ab23-ccdb1018252a |      | fa:16:3e:94:a7:df | {"subnet_id": "a592fdba-babd-48e0-96e8-2dd9117614d3", "ip_address": "192.168.200.1"} |
| c45e998d-98a1-4b23-bb41-5d24797a12a4 |      | fa:16:3e:ee:6a:f7 | {"subnet_id": "43f8f625-c773-4f18-a691-fd4ebfb3be54", "ip_address": "172.24.4.225"}  |
+--------------------------------------+------+-------------------+--------------------------------------------------------------------------------------+

2. ポートの ID (値は左の欄に記載) に対して以下のコマンドを実行して、各ポートの詳細を表示します。コマンドの結果にはポートの ステータス が含まれており、以下の例ではステータスが ACTIVE であることが分かります。

# neutron port-show b58d26f0-cc03-43c1-ab23-ccdb1018252a

結果の例:

+-----------------------+--------------------------------------------------------------------------------------+
| Field                 | Value                                                                                |
+-----------------------+--------------------------------------------------------------------------------------+
| admin_state_up        | True                                                                                 |
| allowed_address_pairs |                                                                                      |
| binding:host_id       | node.example.com                                                      |
| binding:profile       | {}                                                                                   |
| binding:vif_details   | {"port_filter": true, "ovs_hybrid_plug": true}                                       |
| binding:vif_type      | ovs                                                                                  |
| binding:vnic_type     | normal                                                                               |
| device_id             | 49c6ebdc-0e62-49ad-a9ca-58cea464472f                                                 |
| device_owner          | network:router_interface                                                             |
| extra_dhcp_opts       |                                                                                      |
| fixed_ips             | {"subnet_id": "a592fdba-babd-48e0-96e8-2dd9117614d3", "ip_address": "192.168.200.1"} |
| id                    | b58d26f0-cc03-43c1-ab23-ccdb1018252a                                                 |
| mac_address           | fa:16:3e:94:a7:df                                                                    |
| name                  |                                                                                      |
| network_id            | 63c24160-47ac-4140-903d-8f9a670b0ca4                                                 |
| security_groups       |                                                                                      |
| status                | ACTIVE                                                                               |
| tenant_id             | d588d1112e0f496fb6cac22f9be45d49                                                     |
+-----------------------+--------------------------------------------------------------------------------------+

ポートごとにこの手順を実行して、ステータスを取得します。

ping コマンドは、ネットワークの接続性の問題解析に役立つツールです。ping コマンドで返される結果は、ネットワークの接続性に関する基本的な指標として機能しますが、実際のアプリケーショントラフィックをブロックするファイアウォールなど、すべての接続性の問題を完全に除外するわけではありません。ping コマンドは、指定の宛先にトラフィックを送信することで機能し、次に ping 送信の試行に問題がなかったかどうかを報告します。

ping テストは、ネットワークの問題が発生しているマシンから実行すると最も有効です。そのため、マシンが完全にオフラインの場合には、VNC 管理コンソール経由でコマンドラインに接続する必要がある場合があります。

たとえば、以下の ping のテストコマンドを成功させるには、複数のネットワークインフラストラクチャー層を検証する必要があります。つまり、名前の解決、IP ルーティング、ネットワークスイッチのすべてが正常に機能していなければなりません。

$ ping www.redhat.com

PING e1890.b.akamaiedge.net (125.56.247.214) 56(84) bytes of data.
64 bytes from a125-56.247-214.deploy.akamaitechnologies.com (125.56.247.214): icmp_seq=1 ttl=54 time=13.4 ms
64 bytes from a125-56.247-214.deploy.akamaitechnologies.com (125.56.247.214): icmp_seq=2 ttl=54 time=13.5 ms
64 bytes from a125-56.247-214.deploy.akamaitechnologies.com (125.56.247.214): icmp_seq=3 ttl=54 time=13.4 ms
^C

ping コマンドの結果のサマリーが表示されたら、Ctrl-c で ping コマンドを終了することができます。パケットロスがない場合は、タイムリーかつ安定した接続であることが分かります。

--- e1890.b.akamaiedge.net ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 13.461/13.498/13.541/0.100 ms

さらに、テストする宛先によっては、ping テストの結果は非常に明確な場合があります。たとえば、以下の図では、VM1 において何らかの接続性の問題が発生しています。接続が可能な宛先を赤の番号で示しています。また、成功結果または失敗結果から導かれた結論を記載しています。

1. インターネット: 一般的な最初のステップは、www.redhat.com などのインターネットロケーションに ping テストを送信します。

2. 物理ルーター: これは、外部の宛先にトラフィックを転送するために、ネットワーク管理者が指定したルーターインターフェースです。

3. Neutron ルーター: これは、仮想マシンのトラフィックを転送するのに、Red Hat OpenStack Platform が使用する仮想 SDN (ソフトウェア定義ネットワーク) ルーターです。

4. 物理スイッチ: 物理スイッチは、同じ物理ネットワーク上にあるノード間のトラフィックを管理する役割を果たします。

5. VM2: 同じコンピュートノード上にある、同じサブネットの仮想マシンに ping 送信を試行します。

OpenStack Newtorking は、VLAN ネットワークをトランク接続して SDN スイッチに到達することができます。VLAN のタグ付けがされたプロバイダーネットワークに対するサポートがあると、仮想インスタンスを物理ネットワークにあるサーバーのサブネットと統合することができます。

VLAN プロバイダーネットワークへの接続性のトラブルシューティングを行うには、ネットワークの作成時に指定したゲートウェイ IP に ping 送信をしてみてください。たとえば、以下のコマンドでネットワークを作成した場合には、

# neutron net-create provider --provider:network_type=vlan --provider:physical_network=phy-eno1 --provider:segmentation_id=120 --router:external=True
# neutron subnet-create "provider" --allocation-pool start=192.168.120.1,end=192.168.120.253 --disable-dhcp --gateway 192.168.120.254 192.168.120.0/24

定義済みのゲートウェイの IP 192.168.120.254 に ping を送信してください。

これに失敗した場合には、関連付けられた VLAN (ネットワーク作成時に定義済み) へのネットワークフローがあることを確認してください。上記の例では、OpenStack Networking は VLAN 120 をプロバイダーネットワークにトランク接続するように設定されています。このオプションは --provider:segmentation_id=120 のパラメーターを使用して設定します。

ブリッジインターフェース (今回の場合は br-ex という名前) の VLAN フローを確認します。

# ovs-ofctl dump-flows br-ex

 NXST_FLOW reply (xid=0x4):
  cookie=0x0, duration=987.521s, table=0, n_packets=67897, n_bytes=14065247, idle_age=0, priority=1 actions=NORMAL
  cookie=0x0, duration=986.979s, table=0, n_packets=8, n_bytes=648, idle_age=977, priority=2,in_port=12 actions=drop

# neutron agent-list
+--------------------------------------+--------------------+-----------------------+-------+----------------+
| id                                   | agent_type         | host                  | alive | admin_state_up |
+--------------------------------------+--------------------+-----------------------+-------+----------------+
| a08397a8-6600-437d-9013-b2c5b3730c0c | Metadata agent     | rhelosp.example.com   | :-)   | True           |
| a5153cd2-5881-4fc8-b0ad-be0c97734e6a | L3 agent           | rhelosp.example.com   | :-)   | True           |
| b54f0be7-c555-43da-ad19-5593a075ddf0 | DHCP agent         | rhelosp.example.com   | :-)   | True           |
| d2be3cb0-4010-4458-b459-c5eb0d4d354b | Open vSwitch agent | rhelosp.example.com   | :-)   | True           |
+--------------------------------------+--------------------+-----------------------+-------+----------------+

OpenStack Networking では、テナントトラフィックはすべて、ネットワークの名前空間に含まれます。これにより、テナントは、テナント間の干渉なしにネットワークの設定が可能になります。たとえば、ネットワーク名前空間を使用することで異なるテナントが干渉することなしに 192.168.1.1/24 の同じサブネット範囲を指定することができます。

テナントネットワークのトラブルシューティングを開始するには、まず対象のネットワークがどのネットワーク名前空間に含まれているかを確認します。

1. neutron コマンドを使用して全テナントネットワークを一覧表示します。

# neutron net-list
+--------------------------------------+-------------+-------------------------------------------------------+
| id                                   | name        | subnets                                               |
+--------------------------------------+-------------+-------------------------------------------------------+
| 9cb32fe0-d7fb-432c-b116-f483c6497b08 | web-servers | 453d6769-fcde-4796-a205-66ee01680bba 192.168.212.0/24 |
| a0cc8cdd-575f-4788-a3e3-5df8c6d0dd81 | private     | c1e58160-707f-44a7-bf94-8694f29e74d3 10.0.0.0/24      |
| baadd774-87e9-4e97-a055-326bb422b29b | private     | 340c58e1-7fe7-4cf2-96a7-96a0a4ff3231 192.168.200.0/24 |
| 24ba3a36-5645-4f46-be47-f6af2a7d8af2 | public      | 35f3d2cb-6e4b-4527-a932-952a395c4bb3 172.24.4.224/28  |
+--------------------------------------+-------------+-------------------------------------------------------+

この例では、web-servers ネットワークを検証します。web-server の行の id の値をメモしてください (この例では 9cb32fe0-d7fb-432c-b116-f483c6497b08 です)。この値は、ネットワーク名前空間に追加されており、次のステップで特定がしやすくなります。

2. ip コマンドを使用してネットワーク名前空間をすべて一覧表示します。

# ip netns list
qdhcp-9cb32fe0-d7fb-432c-b116-f483c6497b08
qrouter-31680a1c-9b3e-4906-bd69-cb39ed5faa01
qrouter-62ed467e-abae-4ab4-87f4-13a9937fbd6b
qdhcp-a0cc8cdd-575f-4788-a3e3-5df8c6d0dd81
qrouter-e9281608-52a6-4576-86a6-92955df46f56

この結果では、web-server のネットワーク ID と一致する名前空間が存在します。この例では、qdhcp-9cb32fe0-d7fb-432c-b116-f483c6497b08 と表示されています。

3. この名前空間内でコマンドを実行して web-servers ネットワークの設定を検証します。これには、トラブルシューティングのコマンドの先頭に ip netns exec (名前空間) を追加します。例を以下に示します。

a) web-servers ネットワークのルーティングテーブルを表示する場合:

# ip netns exec qrouter-62ed467e-abae-4ab4-87f4-13a9937fbd6b route -n

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.24.4.225    0.0.0.0         UG    0      0        0 qg-8d128f89-87
172.24.4.224    0.0.0.0         255.255.255.240 U     0      0        0 qg-8d128f89-87
192.168.200.0   0.0.0.0         255.255.255.0   U     0      0        0 qr-8efd6357-96

b) web-servers ネットワークのルーティングテーブルを表示する場合:

# ip netns exec qrouter-62ed467e-abae-4ab4-87f4-13a9937fbd6b route -n

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.24.4.225    0.0.0.0         UG    0      0        0 qg-8d128f89-87
172.24.4.224    0.0.0.0         255.255.255.240 U     0      0        0 qg-8d128f89-87
192.168.200.0   0.0.0.0         255.255.255.0   U     0      0        0 qr-8efd6357-96

# ip netns exec qrouter-62ed467e-abae-4ab4-87f4-13a9937fbd6b tcpdump -qnntpi any icmp

# ip netns exec qrouter-62ed467e-abae-4ab4-87f4-13a9937fbd6b  ping www.redhat.com

tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
IP (tos 0xc0, ttl 64, id 55447, offset 0, flags [none], proto ICMP (1), length 88)
    172.24.4.228 > 172.24.4.228: ICMP host 192.168.200.20 unreachable, length 68
	IP (tos 0x0, ttl 64, id 22976, offset 0, flags [DF], proto UDP (17), length 60)
    172.24.4.228.40278 > 192.168.200.21: [bad udp cksum 0xfa7b -> 0xe235!] UDP, length 32

以下の手順では、外部ネットワークの直接インスタンスを接続可能なフラットプロバイダーネットワークを作成します。複数の物理ネットワーク (physnet1、physnet2) およびそれぞれ別の物理インターフェース (eth0 -> physnet1 および eth1 -> physnet2) があり、各コンピュートノードとネットワークノードをこれらの外部ネットワークに接続する必要がある場合に実行します。

type_drivers = vxlan,flat
flat_networks =*

2. フラットな外部ネットワークを作成して、設定済みの physical_network に関連付けます。共有ネットワークとしてこのネットワークを作成することで、他のユーザーが直接インスタンスを接続できるようにします。

neutron net-create public01 --provider:network_type flat --provider:physical_network physnet1 --router:external=True --shared

3. neutron subnet-create または OpenStack Dashboard を使用して、外部ネットワーク内にサブネットを作成します。

4. neutron-server サービスを再起動して、この変更を適用します。

# systemctl restart neutron-server.service

1. Open vSwitch ブリッジとポートを作成します。この手順では外部ネットワークのブリッジ (br-ex) を作成して、対応のポート (eth1) を追加します。

i. /etc/sysconfig/network-scripts/ifcfg-eth1 を編集します。

DEVICE=eth1
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=br-ex
ONBOOT=yes
NM_CONTROLLED=no
BOOTPROTO=none

ii. /etc/sysconfig/network-scripts/ifcfg-br-ex を編集します。

DEVICE=br-ex
TYPE=OVSBridge
DEVICETYPE=ovs
ONBOOT=yes
NM_CONTROLLED=no
BOOTPROTO=none

2. network サービスを再起動してこれらの変更を適用します。

# systemctl restart network.service

3. /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini で物理ネットワークを設定して、ブリッジを物理ネットワークにマッピングします。

bridge_mappings = physnet1:br-ex

4. ネットワークノードとコンピュートノード上で neutron-openvswitch-agent サービスを再起動して、変更を適用します。

systemctl restart neutron-openvswitch-agent

# Name of bridge used for external network traffic. This should be set to
# empty value for the linux bridge
external_network_bridge =

2. neutron-l3-agent を再起動して変更を適用します。

systemctl restart neutron-l3-agent.service

1. 新規インスタンスを作成します。

2. Dashboard の ネットワーク タブから、新たに作成した外部ネットワークに新規インスタンスを直接追加します。

qbr269d4d73-e7		8000.061943266ebb	no		qvb269d4d73-e7
							tap269d4d73-e7

  Bridge br-int
        fail_mode: secure
            Interface "qvof63599ba-8f"
        Port "qvo269d4d73-e7"
            tag: 5
            Interface "qvo269d4d73-e7"

    Bridge br-int
        fail_mode: secure
       Port int-br-ex
            Interface int-br-ex
                type: patch
                options: {peer=phy-br-ex}

    Bridge br-ex
        Port phy-br-ex
            Interface phy-br-ex
                type: patch
                options: {peer=int-br-ex}
        Port br-ex
            Interface br-ex
                type: internal

# ovs-ofctl show br-ex
OFPT_FEATURES_REPLY (xid=0x2): dpid:00003440b5c90dc6
n_tables:254, n_buffers:256
capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
actions: OUTPUT SET_VLAN_VID SET_VLAN_PCP STRIP_VLAN SET_DL_SRC SET_DL_DST SET_NW_SRC SET_NW_DST SET_NW_TOS SET_TP_SRC SET_TP_DST ENQUEUE

 2(phy-br-ex): addr:ba:b5:7b:ae:5c:a2
     config:     0
     state:      0
     speed: 0 Mbps now, 0 Mbps max

# ovs-ofctl dump-flows br-ex
NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=4703.491s, table=0, n_packets=3620, n_bytes=333744, idle_age=0, priority=1 actions=NORMAL
 cookie=0x0, duration=3890.038s, table=0, n_packets=13, n_bytes=1714, idle_age=3764, priority=4,in_port=2,dl_vlan=5 actions=strip_vlan,NORMAL
 cookie=0x0, duration=4702.644s, table=0, n_packets=10650, n_bytes=447632, idle_age=0, priority=2,in_port=2 actions=drop

ovs-ofctl show br-int
OFPT_FEATURES_REPLY (xid=0x2): dpid:00004e67212f644d
n_tables:254, n_buffers:256
capabilities: FLOW_STATS TABLE_STATS PORT_STATS QUEUE_STATS ARP_MATCH_IP
actions: OUTPUT SET_VLAN_VID SET_VLAN_PCP STRIP_VLAN SET_DL_SRC SET_DL_DST SET_NW_SRC SET_NW_DST SET_NW_TOS SET_TP_SRC SET_TP_DST ENQUEUE
 15(int-br-ex): addr:12:4e:44:a9:50:f4
     config:     0
     state:      0
     speed: 0 Mbps now, 0 Mbps max

# ovs-ofctl dump-flows br-int
NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=5351.536s, table=0, n_packets=12118, n_bytes=510456, idle_age=0, priority=1 actions=NORMAL
 cookie=0x0, duration=4537.553s, table=0, n_packets=3489, n_bytes=321696, idle_age=0, priority=3,in_port=15,vlan_tci=0x0000 actions=mod_vlan_vid:5,NORMAL
 cookie=0x0, duration=5350.365s, table=0, n_packets=628, n_bytes=57892, idle_age=4538, priority=2,in_port=15 actions=drop
 cookie=0x0, duration=5351.432s, table=23, n_packets=0, n_bytes=0, idle_age=5351, priority=0 actions=drop

# grep bridge_mapping /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini
bridge_mappings = physnet1:br-ex

# neutron net-show provider-flat
...
| provider:physical_network | physnet1
...

# neutron net-show provider-flat
...
| provider:network_type     | flat                                 |
| router:external           | True                                 |
...

    Bridge br-ex
        Port phy-br-ex
            Interface phy-br-ex
                type: patch
                options: {peer=int-br-ex}
        Port "eth1"
            Interface "eth1"

# ip a
5: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master ovs-system state UP qlen 1000

以下の手順では、外部ネットワークに直接インスタンスを接続可能な VLAN プロバイダーネットワークを作成します。複数のプロバイダーネットワークに (単一の NIC 上で) VLAN タグが付けられたインターフェースを複数接続するには、この手順を実行します。以下の例では、VLAN 範囲が 171-172 の physnet1 と呼ばれる物理ネットワークを使用します。ネットワークノードとコンピュートノードは、eth1 という名前の物理インターフェースを使用して物理ネットワークに接続します。これらのインターフェースの接続先のスイッチポートは、必要な VLAN 範囲をトランク接続するように設定する必要があります。
以下の手順では、サンプルの VLAN ID と上記で指定した名前を使用して VLAN プロバイダーネットワークを設定します。

[ml2]
type_drivers = vxlan,flat,vlan

2. network_vlan_ranges の設定を行い、使用する物理ネットワークおよび VLAN 範囲を反映します。以下に例を示します。

[ml2_type_vlan]
network_vlan_ranges=physnet1:171:172

3. neutron-server サービスを再起動して変更を適用します。

systemctl restart neutron-server

4. 外部ネットワークを vlan 種別として作成して、設定済みの physical_network に関連付けます。--shared ネットワークとして作成して、他のユーザーが直接インスタンスに接続できるようにします。以下の例では、VLAN 171 と VLAN 172 の 2 つのネットワークを作成します。

neutron net-create provider-vlan171 \
			--provider:network_type vlan \
			--router:external true \
			--provider:physical_network physnet1 \
			--provider:segmentation_id 171 --shared

neutron net-create provider-vlan172 \
			--provider:network_type vlan \
			--router:external true \
			--provider:physical_network physnet1 \
			--provider:segmentation_id 172 --shared

5. 複数のサブネットマスクを作成して、外部ネットワークを使用するように設定します。これは、neutron subnet-create または Dashboard のいずれかを使用して設定できます。ネットワーク管理者から取得した外部サブネットの詳細が正しく各 VLAN に関連付けられていることを確認します。以下の例では、VLAN 171 はサブネット 10.65.217.0/24、VLAN 172 は 10.65.218.0/24 を使用します。

neutron subnet-create \
			--name subnet-provider-171 provider-171 10.65.217.0/24 \
			--enable-dhcp \
			--gateway 10.65.217.254 \

neutron subnet-create \
			--name subnet-provider-172 provider-172 10.65.218.0/24 \
			--enable-dhcp \
			--gateway 10.65.218.254 \

1. 外部ネットワークブリッジ (br-ex) を作成して、ポート (eth1) に関連付けます。

/etc/sysconfig/network-scripts/ifcfg-eth1

DEVICE=eth1
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=br-ex
ONBOOT=yes
NM_CONTROLLED=no
BOOTPROTO=none

/etc/sysconfig/network-scripts/ifcfg-br-ex:

DEVICE=br-ex
TYPE=OVSBridge
DEVICETYPE=ovs
ONBOOT=yes
NM_CONTROLLED=no
BOOTPROTO=none

2. ノードを再起動するか、network サービスを再起動して、ネットワークの変更を有効にします。以下に例を示します。

# systemctl restart network

3. /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini で物理ネットワークを設定して、物理ネットワークに合わせてブリッジをマッピングします。

bridge_mappings = physnet1:br-ex

4. ネットワークノードとコンピュートノードで neutron-openvswitch-agent サービスを再起動して、変更を有効にします。

systemctl restart neutron-openvswitch-agent

# Name of bridge used for external network traffic. This should be set to
# empty value for the linux bridge
external_network_bridge =

2. neutron-l3-agent を再起動して、変更を有効にします。

systemctl restart neutron-l3-agent

3. 新規インスタンスを作成して、Dashboard の ネットワーク タブを使用して新規作成した外部ネットワークに直接、新しいインスタンスを追加します。

# brctl show
bridge name	bridge id		STP enabled	interfaces
qbr84878b78-63		8000.e6b3df9451e0	no		qvb84878b78-63
							tap84878b78-63

qbr86257b61-5d		8000.3a3c888eeae6	no		qvb86257b61-5d
							tap86257b61-5d

                options: {peer=phy-br-ex}
        Port "qvo86257b61-5d"
            tag: 3

            Interface "qvo86257b61-5d"
        Port "qvo84878b78-63"
            tag: 2
            Interface "qvo84878b78-63"

    Bridge br-int
        fail_mode: secure
       Port int-br-ex
            Interface int-br-ex
                type: patch
                options: {peer=phy-br-ex}

    Bridge br-ex
        Port phy-br-ex
            Interface phy-br-ex
                type: patch
                options: {peer=int-br-ex}
        Port br-ex
            Interface br-ex
                type: internal

# ovs-ofctl show br-ex
 4(phy-br-ex): addr:32:e7:a1:6b:90:3e
     config:     0
     state:      0
     speed: 0 Mbps now, 0 Mbps max

# ovs-ofctl dump-flows br-ex
NXST_FLOW reply (xid=0x4):
NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=6527.527s, table=0, n_packets=29211, n_bytes=2725576, idle_age=0, priority=1 actions=NORMAL
 cookie=0x0, duration=2939.172s, table=0, n_packets=117, n_bytes=8296, idle_age=58, priority=4,in_port=4,dl_vlan=3 actions=mod_vlan_vid:172,NORMAL
 cookie=0x0, duration=6111.389s, table=0, n_packets=145, n_bytes=9368, idle_age=98, priority=4,in_port=4,dl_vlan=2 actions=mod_vlan_vid:171,NORMAL
 cookie=0x0, duration=6526.675s, table=0, n_packets=82, n_bytes=6700, idle_age=2462, priority=2,in_port=4 actions=drop

# ovs-ofctl show br-int
 18(int-br-ex): addr:fe:b7:cb:03:c5:c1
     config:     0
     state:      0
     speed: 0 Mbps now, 0 Mbps max

# ovs-ofctl dump-flows br-int
NXST_FLOW reply (xid=0x4):
 cookie=0x0, duration=6770.572s, table=0, n_packets=1239, n_bytes=127795, idle_age=106, priority=1 actions=NORMAL
 cookie=0x0, duration=3181.679s, table=0, n_packets=2605, n_bytes=246456, idle_age=0, priority=3,in_port=18,dl_vlan=172 actions=mod_vlan_vid:3,NORMAL
 cookie=0x0, duration=6353.898s, table=0, n_packets=5077, n_bytes=482582, idle_age=0, priority=3,in_port=18,dl_vlan=171 actions=mod_vlan_vid:2,NORMAL
 cookie=0x0, duration=6769.391s, table=0, n_packets=22301, n_bytes=2013101, idle_age=0, priority=2,in_port=18 actions=drop
 cookie=0x0, duration=6770.463s, table=23, n_packets=0, n_bytes=0, idle_age=6770, priority=0 actions=drop

# grep bridge_mapping /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini
bridge_mappings = physnet1:br-ex

# neutron net-show provider-vlan171
...
| provider:physical_network | physnet1
...

# neutron net-show provider-vlan171
...
| provider:network_type     | vlan                                 |
| provider:physical_network | physnet1                             |
| provider:segmentation_id  | 171                                  |
...

    Bridge br-ex
        Port phy-br-ex
            Interface phy-br-ex
                type: patch
                options: {peer=int-br-ex}
        Port "eth1"
            Interface "eth1"

# ip a
5: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master ovs-system state UP qlen 1000

この方法で接続されたインスタンスは、プロバイダーの外部ネットワークに直接アタッチされ、OpenStack Networking (neutron) ルーターではなく、外部ルーターがデフォルトゲートウェイとして設定されます。これは、neutron ルーターはインスタンスから nova-metadata サーバーへのメタデータ要求をプロキシー化するために使用することができないため、cloud-init の実行中にエラーが発生する可能性があることを意味しますが、この問題は dhcp エージェントがメタデータ要求をプロキシー化するように設定することによって解決することができます。この機能は、/etc/neutron/dhcp_agent.ini で有効にすることができます。以下に例を示します。

enable_isolated_metadata = True

同時にプライベートネットワークに追加された場合でも、同じネットワークを利用して、Floating IP アドレスをインスタンスに割り当てることができる点に注意してください。このネットワークから Floating IP として割り当てられたアドレスは、ネットワークノードの qrouter-xxx の名前空間にバインドされ、関連付けられたプライベート IP アドレスに DNAT-SNAT を実行します。反対に、直接外部ネットワークにアクセスできるように割り当てられた IP アドレスはインスタンス内に直接バインドされ、インスタンスが外部ネットワークと直接通信できるようになります。

OpenStack ノード内の物理ネットワークアダプターは、異なる種別のネットワークトラフィックを伝送することが想定される場合があります。これには、インスタンストラフィック、ストレージデータ、認証要求が含まれます。NIC が伝送するトラフィックの種別によって、物理スイッチ上でのポートの設定方法が異なります。

最初のステップでは、コンピュートノード上の物理 NIC で伝送するトラフィックの種別を決定する必要があります。次に、NIC が物理スイッチポートに接続されると、そのスイッチポートはトラックトラフィックまたは一般のトラフィックを許可するように特別に設定する必要があります。

たとえば、以下の図は、eth0 と eth1 の 2 つの NIC を搭載したコンピュートノードを示しています。各 NIC は、物理スイッチ上のギガビットイーサネットポートに接続され、eth0 がインスタンストラフィックを伝送し、eth1 が OpenStack サービスの接続性を提供します。

Red Hat OpenStack Platform 9 (Mitaka) では、OpenStack Networking は、インスタンスに安全に適用することができる許容最大 MTU サイズの計算が可能です。MTU の値は、単一のネットワークパケットで転送できる最大データ量を指定します。この数は、アプリケーションに最も適したサイズによって変わります。たとえば、NFS 共有で必要な MTU サイズは VoIP アプリケーションで必要なサイズとは異なる場合があります。

MTU 設定を正しく機能させるにはエンドツーエンドで一貫して設定する必要があります。つまり、MTU 設定は、仮想マシン自体、仮想ネットワークのインフラストラクチャー、物理ネットワーク、宛先のサーバー自体など、パケットがパススルーするすべてのポイントで同じサイズに指定する必要があります。

たとえば、以下の図の赤の点は、インスタンスと物理サーバーの間のトラフィックに合わせて MTU 値を調節する必要があるポイントを示しています。ネットワークトラフィックを処理するインターフェースの MTU 値はすべて、特定の MTU サイズのパケットに対応するように変更する必要があります。トラフィックが 192.168.200.15 から物理サーバー 10.20.15.25 に伝送されることが想定され、その過程に断片化が発生するのを防ぐには、この変更が必要です。

MTU 値に一貫性がないと、ネットワークに複数の問題が発生します。最も一般的な問題は、ネットワークのパフォーマンスが低下することです。このような問題は、各ネットワークポイントを特定してから、正しい MTU 値が設定されていることを検証する必要があるため、トラブルシューティングが困難です。

advertise_mtu = True

            -
              type: ovs_bridge
              name: br-isolated
              use_dhcp: false
              mtu: 9000    # <--- Set MTU
              members:
                -
                  type: ovs_bond
                  name: bond1
                  mtu: 9000    # <--- Set MTU
                  ovs_options: {get_param: BondInterfaceOvsOptions}
                  members:
                    -
                      type: interface
                      name: ens15f0
                      mtu: 9000    # <--- Set MTU
                      primary: true
                    -
                      type: interface
                      name: enp131s0f0
                      mtu: 9000    # <--- Set MTU
                -
                  type: vlan
                  device: bond1
                  vlan_id: {get_param: InternalApiNetworkVlanID}
                  mtu: 9000    # <--- Set MTU
                  addresses:
                  -
                    ip_netmask: {get_param: InternalApiIpSubnet}
                -
                  type: vlan
                  device: bond1
                  mtu: 9000    # <--- Set MTU
                  vlan_id: {get_param: TenantNetworkVlanID}
                  addresses:
                  -
                    ip_netmask: {get_param: TenantIpSubnet}

# neutron net-show <network>

QoS ポリシーは、個々のポートに適用されるか、特定のテナントネットワークに適用され全ポートに継承されます。

QoS ポリシーは、動的に適用、変更、削除することができます。以下の例では、帯域幅を制限するルールを手動で作成して、1 つのポートに適用します。

以下の値により、規制のアルゴリズムを適宜に設定することができます。

Red Hat OpenStack Platform 9 では、QoS ポリシーにロールベースアクセス制御 (RBAC) を追加され、QoS ポリシーを特定のプロジェクトに適用できるようになりました。

たとえば、優先順位が低いネットワークトラフィックを許可する QoS ポリシーを作成して、特定のプロジェクトにのみ適用することができます。以下のコマンドでは、以前に作成した bw-limiter ポリシーが demo テナントに割り当てられます。

# neutron rbac-create 'bw-limiter' --type qos-policy --target-tenant 80bf5732752a41128e612fe615c886c6 --action access_as_shared

ブリッジマッピングにより、プロバイダーネットワークのトラフィックは、物理ネットワークに到達することが可能となります。トラフィックは、ルーターの qg-xxx インターフェースからプロバイダーネットワークの外部に送出されて、br-int に達します。次に br-int と br-ex の間の veth ペアにより、トラフィックはプロバイダーネットワークのブリッジを通過して物理ネットワークまで到達することが可能となります。

int-br-ex <-> phy-br-ex

bridge_mappings = physnet1:br-ex,physnet2:br-ex2

network_vlan_ranges = physnet1,physnet2

マッピングを削除した後には、patch port のクリーンアップを実行する必要があります。この操作により、ブリッジ設定から誤ったエントリーが確実に消去されます。このタスクを実行するには 2 つのオプションを利用できます。

各オプションの例を以下に示します。

bridge_mappings = physnet1:br-ex,physnet2:br-ex2

bridge_mappings = physnet1:br-ex

# ovs-vsctl del-port br-ex2 phy-br-ex2
# ovs-vsctl del-port br-int int-br-ex2

# service neutron-openvswitch-agent restart

# ovs-vsctl add-port br-ex eth1

# /usr/bin/neutron-ovs-cleanup
--config-file /usr/share/neutron/neutron-dist.conf
--config-file /etc/neutron/neutron.conf
--config-file /etc/neutron/plugins/openvswitch/ovs_neutron_plugin.ini
--log-file /var/log/neutron/ovs-cleanup.log --ovs_all_ports

# systemctl restart neutron-openvswitch-agent
# systemctl restart neutron-l3-agent.service
# systemctl restart neutron-dhcp-agent.service

# systemctl restart neutron-openvswitch-agent

以下の手順では、RBAC ポリシーを使用してテナントに共有ネットワークへのアクセスを許可する方法の実例を紹介します。

これにより、 auditors プロジェクトでインスタンスを web-servers ネットワークに接続できるようになります。

--action access_as_external パラメーターを使用して、RBAC で制御可能な外部ネットワーク (ゲートウェイインターフェースがアタッチされているネットワーク) にアクセスします。

たとえば、以下の手順では web-servers ネットワークの RBAC を作成して、engineering テナント (c717f263785d4679b16a122516247deb) へのアクセスを許可します。

1. --action access_as_external を使用して新しい RBAC ポリシーを作成します。

# neutron rbac-create 6e437ff0-d20f-4483-b627-c3749399bdca --type network --target-tenant c717f263785d4679b16a122516247deb --action access_as_external
 Created a new rbac_policy:
+---------------+--------------------------------------+
| Field         | Value                                |
+---------------+--------------------------------------+
| action        | access_as_external                   |
| id            | ddef112a-c092-4ac1-8914-c714a3d3ba08 |
| object_id     | 6e437ff0-d20f-4483-b627-c3749399bdca |
| object_type   | network                              |
| target_tenant | c717f263785d4679b16a122516247deb     |
| tenant_id     | c717f263785d4679b16a122516247deb     |
+---------------+--------------------------------------+

2. 上記のコマンドを実行した結果、Engineering テナントのユーザーは、ネットワークの表示やそのネットワークへのインスタンスの接続が可能になります。

$ neutron net-list
+--------------------------------------+-------------+------------------------------------------------------+
| id                                   | name        | subnets                                              |
+--------------------------------------+-------------+------------------------------------------------------+
| 6e437ff0-d20f-4483-b627-c3749399bdca | web-servers | fa273245-1eff-4830-b40c-57eaeac9b904 192.168.10.0/24 |
+--------------------------------------+-------------+------------------------------------------------------+

1. ネットワークノードで、neutron.conf ファイルの router_distributed を有効にします。この設定により、今後作成されるルーターはすべてデフォルトで分散されるようになります。

router_distributed = True

policy.json ファイルを編集して、デフォルトの動作をオーバーライドすることができます。

neutron router-create --distributed=True/False <name>

2. レイヤー 3 エージェントの設定

コンピュートノードの l3_agent.ini ファイルで DVR を有効にします。

agent_mode = dvr

ネットワークノードで、分散ルーターに dvr_snat を設定します。

agent_mode = dvr_snat

3. レイヤー 2 エージェントの設定

ネットワークノードとコンピュートノードで、DVR と、L2 エージェントへの L2 ポピュレーションを有効にします。たとえば、Open vSwitch する場合には、ovs_neutron_plugin.ini ファイルを以下のように編集します。

enable_distributed_routing = True
l2_population = True

4. ML2 で、L2 ポピュレーションメカニズムドライバーを有効にします。

コントローラーで、ml2_conf.ini を編集します。

[ml2]
mechanism_drivers = openvswitch, l2population	#Other values may be listed here as well

コンピュートノードで、ml2_conf.ini を編集します。

[agent]
l2_population = True

5. サービスを再起動して、変更を有効にします。

コントローラーで、以下のサービスを再起動します。

# systemctl restart neutron-server.service
# systemctl restart neutron-l3-agent.service
# systemctl restart neutron-openvswitch-agent.service

コンピュートノードで、以下のサービスを再起動します。

# systemctl restart neutron-l3-agent.service
# systemctl restart neutron-metadata-agent

OpenStack Networking (neutron) サービスは、大きく 2 つのカテゴリーに分類することができます。

1. Neutron API server: このサービスは、エンドユーザーとサービスが OpenStack Networking と対話できるように、主に API を提供する OpenStack Networking API サーバーを実行します。またこのサービスは、基盤のデータベースと対話して、テナントネットワーク、ルーター、ロードバランサーの詳細などを保存する役割も果たします。

2. Neutron エージェント: OpenStack Networking のさまざまな機能を提供するサービスです。

以下の手順では、OpenStack Networking が Open vSwitch (OVS) または Linux Bridge のいずれかのプラグインとともに LBaaS を使用するように設定します。BigSwitch、Floodlight、NEC、NSX、Ryu などの OVS ベースのプラグイン向けに LBaaS を有効化する場合には Open vSwitch LBaaS ドライバーが必要です。

neutron-server サービスを実行するノードで以下のステップを実行します。

コントローラーノード (API サーバー) の場合:

1. /etc/neutron/neutron_lbaas.conf ファイルの service_provider パラメーターを使用して、HAProxy プラグインを有効にします。

service_provider = LOADBALANCER:Haproxy:neutron_lbaas.services.loadbalancer.drivers.haproxy.plugin_driver.HaproxyOnHostPluginDriver:default

2. /etc/neutron/neutron.conf ファイルで service_plugin を設定して、LBaaS プラグインを有効化します。

service_plugins = lbaas

3. _neutron-server サービスを再起動して、新規設定を適用します。

# systemctl restart neutron-server.service

OPENSTACK_NEUTRON_NETWORK = {'enable_lb': True,

# systemctl restart httpd.service

1. /etc/neutron/lbaas_agent.ini ファイルで HAProxy ロードバランサーを有効化します。

device_driver = neutron.services.loadbalancer.drivers.haproxy.namespace_driver.HaproxyNSDriver

2. /etc/neutron/lbaas_agent.ini で user_group オプションを設定します。

# The user group
# user_group = nogroup
user_group = haproxy

3. /etc/neutron/lbaas_agent.ini ファイルで必要なドライバーを選択します。

interface_driver = neutron.agent.linux.interface.OVSInterfaceDriver

interface_driver = neutron.agent.linux.interface.BridgeInterfaceDriver

4. neutron-lbaas-agent サービスを再起動して、新規設定を適用します。

# systemctl restart neutron-lbaas-agent.service

IPv6 サブネットは、neutron subnet-create コマンドを使用して作成します。また、オプションとして、アドレスモードとルーター広告モードを指定することができます。これらのオプションの設定可能な組み合わせは以下のとおりです。

# keystone tenant-list
+----------------------------------+----------+---------+
|                id                |   name   | enabled |
+----------------------------------+----------+---------+
| 25837c567ed5458fbb441d39862e1399 |    QA    |   True  |
| f59f631a77264a8eb0defc898cb836af |  admin   |   True  |
| 4e2e1951e70643b5af7ed52f3ff36539 |   demo   |   True  |
| 8561dff8310e4cd8be4b6fd03dc8acf5 | services |   True  |
+----------------------------------+----------+---------+

# neutron net-list
+--------------------------------------+------------------+-------------------------------------------------------------+
| id                                   | name             | subnets                                                     |
+--------------------------------------+------------------+-------------------------------------------------------------+
| 8357062a-0dc2-4146-8a7f-d2575165e363 | private          | c17f74c4-db41-4538-af40-48670069af70 10.0.0.0/24            |
| 31d61f7d-287e-4ada-ac29-ed7017a54542 | public           | 303ced03-6019-4e79-a21c-1942a460b920 172.24.4.224/28        |
| 6aff6826-4278-4a35-b74d-b0ca0cbba340 | database-servers |                                                             |
+--------------------------------------+------------------+-------------------------------------------------------------+

# neutron subnet-create --ip-version 6 --ipv6_address_mode=dhcpv6-stateful --tenant-id 25837c567ed5458fbb441d39862e1399 database-servers fdf8:f53b:82e4::53/125

Created a new subnet:
+-------------------+--------------------------------------------------------------+
| Field             | Value                                                        |
+-------------------+--------------------------------------------------------------+
| allocation_pools  | {"start": "fdf8:f53b:82e4::52", "end": "fdf8:f53b:82e4::56"} |
| cidr              | fdf8:f53b:82e4::53/125                                       |
| dns_nameservers   |                                                              |
| enable_dhcp       | True                                                         |
| gateway_ip        | fdf8:f53b:82e4::51                                           |
| host_routes       |                                                              |
| id                | cdfc3398-997b-46eb-9db1-ebbd88f7de05                         |
| ip_version        | 6                                                            |
| ipv6_address_mode | dhcpv6-stateful                                              |
| ipv6_ra_mode      |                                                              |
| name              |                                                              |
| network_id        | 6aff6826-4278-4a35-b74d-b0ca0cbba340                         |
| tenant_id         | 25837c567ed5458fbb441d39862e1399                             |
+-------------------+--------------------------------------------------------------+

# neutron net-list
+--------------------------------------+------------------+-------------------------------------------------------------+
| id                                   | name             | subnets                                                     |
+--------------------------------------+------------------+-------------------------------------------------------------+
| 6aff6826-4278-4a35-b74d-b0ca0cbba340 | database-servers | cdfc3398-997b-46eb-9db1-ebbd88f7de05 fdf8:f53b:82e4::50/125 |
| 8357062a-0dc2-4146-8a7f-d2575165e363 | private          | c17f74c4-db41-4538-af40-48670069af70 10.0.0.0/24            |
| 31d61f7d-287e-4ada-ac29-ed7017a54542 | public           | 303ced03-6019-4e79-a21c-1942a460b920 172.24.4.224/28        |
+--------------------------------------+------------------+-------------------------------------------------------------+

# nova list
+--------------------------------------+------------+--------+------------+-------------+-------------------------------------+
| ID                                   | Name       | Status | Task State | Power State | Networks                            |
+--------------------------------------+------------+--------+------------+-------------+-------------------------------------+
| fad04b7a-75b5-4f96-aed9-b40654b56e03 | corp-vm-01 | ACTIVE | -          | Running     | database-servers=fdf8:f53b:82e4::52 |
+--------------------------------------+------------+--------+------------+-------------+-------------------------------------+

L3 ネットワークで利用可能なクォータオプション: quota_floatingip (テナント 1 つにつき許容される Floating IP の数)、quota_network (テナント 1 つにつき許容されるネットワークの数)、quota_port (テナント 1 つにつき許容されるポートの数)、quota_router (テナント 1 つにつき許容されるルーターの数)、quota_subnet (テナント 1 つにつき許容されるサブネットの数)、quota_vip (テナント 1 つにつき許容される仮想 IP の数)

ファイアウォールを統括するクォータオプション: quota_firewall (テナント 1 つにつき許容されるファイアウォール数)、quota_firewall_policy (テナント 1 つにつき許容されるファイアウォールのポリシー数)、quota_firewall_rule (テナント 1 つにつき許容されるファイアウォールのルール数)

セキュリティーグループの許容数を管理するクォータオプション: quota_security_group (テナント 1 つにつき許容されるセキュリティーグループ数)、quota_security_group_rule (テナント 1 つにつき許容されるセキュリティーグループルール数)

管理者が検討するクォータオプション: default_quota (テナント 1 つにつき許容されるデフォルトのリソース数)、quota_health_monitor (テナント 1 つにつき許容されるヘルスモニターの数。ヘルスモニターはリソースを消費しませんが、OpenStack Networking のバックエンドではメンバーをリソースのコンシューマーとして処理するため、クォータオプションの利用が可能)、quota_member (テナント 1 つにつき許容されるメンバーの数。メンバーはリソースを消費しませんが、OpenStack Networking のバックエンドがメンバーをリソースのコンシューマーとして処理するため、クォータオプションの利用が可能)、quota_pool (テナント 1 つにつき許容されるプール数)

1. FWaaS パッケージをインストールします。

# yum install openstack-neutron-fwaas python-neutron-fwaas

2. neutron.conf ファイルで FWaaS プラグインを有効化します。

service_plugins = neutron.services.firewall.fwaas_plugin.FirewallPlugin

3. fwaas_driver.ini ファイルで FWaaS を設定します。

[fwaas]
driver = neutron.services.firewall.drivers.linux.iptables_fwaas.IptablesFwaasDriver
enabled = True

[service_providers]
service_provider = LOADBALANCER:Haproxy:neutron_lbaas.services.loadbalancer.drivers.haproxy.plugin_driver.HaproxyOnHostPluginDriver:default

4. FWaaS 管理オプションは、OpenStack Dashboard で利用できます。通常、コントローラーノードに設置されている local_settings.py ファイルで、これらのオプションを有効化します。

/usr/share/openstack-dashboard/openstack_dashboard/local/local_settings.py
'enable_firewall' = True

5. neutron-server を再起動して変更を適用します。

# systemctl restart neutron-server

まず、ファイアウォールルールを作成して、これらのルールを含めるポリシーを作成します。次に、ファイアウォールを作成して、ポリシーを適用します。

1. ファイアウォールルールを作成します。

$ neutron firewall-rule-create --protocol <tcp|udp|icmp|any> --destination-port <port-range> --action <allow|deny>

CLI では、プロトコルの値が必要です。ルールがプロトコルに依存しない場合は、any の値を使用することができます。

2. ファイアウォールポリシーを作成します。

$ neutron firewall-policy-create --firewall-rules "<firewall-rule IDs or names separated by space>" myfirewallpolicy

上記で指定したルールの順番は重要です。ルールなしで、ファイアウォールポリシーを作成して、update 操作 (複数のルールの追加時) または insert-rule 操作 (単一ルールの追加時) のいずれかを使用してから、後でルールを追加することができます。

注記: FWaaS は常に、各ポリシーの最も低い優先度において、「default deny all」ルールを追加します。そのため、デフォルトでは、ルールを持たないファイアウォールポリシーは全トラフィックをブロックします。

$ neutron firewall-create <firewall-policy-uuid>

ファイアウォールは、OpenStack Networking のルーターが作成され、インターフェースが接続されるまで、PENDING_CREATE の状態に留まります。

固有の allowed-address-pairs でポートを作成します。

# neutron port-create net1 --allowed-address-pairs type=dict list=true mac_address=<mac_address>,ip_address=<ip_cidr>

# neutron port-update <port-uuid> --allowed-address-pairs type=dict list=true mac_address=<mac_address>,ip_address=<ip_cidr>

高可用性機能が有効化されていない OpenStack Networking デプロイメントは、物理ノードの障害からの影響を受けやすくなります。

一般的なデプロイメントでは、テナントによって、物理 L3 エージェントノードで実行するようにスケジューリングされる仮想ルーターが作成されます。これにより、L3 エージェントノードがなくなると、依存していた仮想マシンが外部ネットワークとの接続が切断されてしまいます。また、Floating IP アドレスも利用できなくなります。

この active/passive の高可用性設定は、業界標準の VRRP (RFC 3768 で定義) を使用してテナントルーターと Floating IP アドレスを保護します。ノードの 1 つを active、残りを standby ロールとして機能するように指定することで、仮想ルーターは複数の OpenStack Networking ノードの間で無作為にスケジュールされます。

以下の図では、アクティブなルーター 1 とルーター 2 が別個の物理 L3 エージェントノード上で稼働しています。レイヤー 3 高可用性には、対応するノードの仮想ルーターのバックアップがスケジュールされており、物理ノードに障害が発生した場合にサービスを再開する準備が整っています。

L3 エージェントノードに障害が発生した場合には、レイヤー 3 高可用性により、影響を受けた仮想ルーターおよび Floating IP アドレスが、機能しているノードに対して再スケジュールされます。

フェイルオーバーのイベント時には、Floating IP 経由のインスタンスの TCP セッションは影響を受けず、中断することなく新しい L3 ノードにマイグレーションされます。SNAT トラフィックのみがフェイルオーバーイベントからの影響を受けます。

active/active HA モードの場合には、L3 エージェント自体はさらに保護されます。

レイヤー 3 高可用性設定はバックエンドで行われており、テナントには表示されません。通常通り、仮想ルーターを継続して作成/管理することができますが、レイヤー 3 の高可用性の実装を設計する場合に認識しておく必要のある制限事項があります。

ルーターの作成時に、管理者が --ha=True/False を設定できるように、Neutron API が更新されました。これは、neutron.conf の l3_ha の設定 (デフォルト) を上書きします。必要な設定手順については、次の項を参照してください。

以下の手順では、OpenStack Networking と L3 エージェントノード上でレイヤー 3 高可用性を有効化します。

1. neutron.conf でレイヤー 3 高可用性を設定します。この際、L3 HA を有効化して、各仮想ルーターを保護する L3 エージェントノード数を定義します。

l3_ha = True
max_l3_agents_per_router = 2
min_l3_agents_per_router = 2

これらの設定については、以下で説明します。

# neutron router-create --ha=<True | False> routerName

2. neutron-server サービスを再起動して変更を適用します。

# systemctl restart neutron-server.service

仮想ルーターの名前空間内で ip address のコマンドを実行すると、プレフィックスとして ha- が指定された HA デバイスが結果内に返されます。

# ip netns exec qrouter-b30064f9-414e-4c98-ab42-646197c74020 ip address
<snip>
2794: ha-45249562-ec: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 12:34:56:78:2b:5d brd ff:ff:ff:ff:ff:ff
inet 169.254.0.2/24 brd 169.254.0.255 scope global ha-54b92d86-4f

レイヤー 3 高可用性が有効化され、個別のノードで障害が発生した場合に、仮想ルーターと Floating IP アドレスが保護されます。

本章には、物理 NIC が仮想インスタンスへパススルーできるように、SR-IOV を設定する手順が含まれています。以下の手順では、単一のコントローラーノード、単一の OpenStack Networking (neutron) ノード、複数の Compute (nova) ノードを使用するデプロイメントを前提としています。

注記: SR-IOV ポートを使用する仮想マシンのインスタンスと、通常のポート (例: Open vSwitch ブリッジに接続されたポート) を使用する仮想マシンのインスタンスの間では、ネットワーク上での相互通信が可能です。これは、L2 設定 (フラット、VLAN) が適切に行われていることを前提とします。現在制約があるため、SR-IOV ポートを使用するインスタンスと、同じコンピュートノード上に設定されている通常の vSwitch ポートを使用するインスタンスが、ネットワークアダプター上で同じ PF を共有している場合には、それらのインスタンス間では相互通信はできません。

サポート対象ハードウェアを使用する全コンピュートノードで以下の手順を実行します。

注記: サポート対象のドライバーについての詳しい情報は、この記事 を参照してください。

以下の手順では、Intel 82576 ネットワークデバイスへシステムがパススルーできるように設定します。また、Virtual Function も作成され、インスタンスがこの Virtual Function を使用して、デバイスに SR-IOV アクセスすることができます。

1. Intel VT-d または AMD IOMMU がお使いのシステムの BIOS で有効になっていることを確認してください。マシンの BIOS 設定メニューまたはメーカーから提供されているその他の手法を参照してください。

2. Intel VT-d または AMD IOMMU がオペレーティングシステムで有効になっているかどうかを確認します。

3. lspci コマンドを実行して、ネットワークデバイスがシステムで認識されていることを確認します。

[root@compute ~]# lspci | grep 82576

以下のように、ネットワークデバイスが結果に含まれています。

03:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
03:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)

4. 以下のステップを実行して、コンピュートノードで VF を有効化します。

4a. カーネルモジュールを削除します。このコマンドで、次のステップでの設定が可能になります。

[root@compute ~]# modprobe -r igb

注記: SRIOV をサポートする NIC が使用するモジュールは、他の NIC の igb ではなく (例: ixgbe または mlx4_core)、ステップ 4 で使用する必要があります。ethtool コマンドを実行して、ドライバーを確認します。この例では、em1 が使用予定の PF (Physical Function) です。

[root@compute ~]# ethtool -i em1 | grep ^driver

4b. max_vfs を 7 (サポートされている最大数以下の値) に設定して、モジュールを開始します。

[root@compute ~]# modprobe igb max_vfs=7

4c. VF を永続化します。

[root@compute ~]# echo "options igb max_vfs=7" >>/etc/modprobe.d/igb.conf

注記: Red Hat Enterprise Linux 7 の場合は、上記の変更を永続化させるために、ステップ 4 の完了後に 「Red Hat Enterprise Linux で、initial ramdisk イメージをリビルドする方法」の記事に記載の手順を実行します。

注記: ステップ 4c. および 4d. の設定の永続化について: modprobe コマンドにより、同じカーネルモジュールを使用するすべての NIC 上で VF が有効化され、システムの再起動後も変更が永続化されるようになります。特定の NIC のみの VF を有効化することも可能ですが、問題が発生する可能性があります。たとえば、以下のコマンドで、enp4s0f1 インターフェースの VF が有効になります。

# echo 7 > /sys/class/net/enp4s0f1/device/sriov_numvfs

しかし、この設定では再起動すると設定が保持されません。考えられる回避策として、rc.local に以下を追加してください。ただし、以下の注記にあるように、この回避策にも制約があります。

# chmod +x /etc/rc.d/rc.local
# echo "echo 7 > /sys/class/net/enp4s0f1/device/sriov_numvfs" >> /etc/rc.local

注記: systemd が導入されて以来、Red Hat Enterprise Linux ではサービスは順番ではなく並列して起動されます。これは、rc.local が起動プロセスの予想される時点で実行されなくなったことを意味します。そのため、予期せぬ動作が発生する可能性があり、この設定は推奨していません。

4d. intel_iommu=pt と igb.max_vfs=7 のパラメーターをカーネルコマンドラインに追記して、Intel VT-d をアクティブ化します。常にこの方法を使用してカーネルを起動する場合には、現在の設定を変更するか、これらのパラメーターを使用したカスタムメニューエントリーを作成することができます。その場合いは、システムはデフォルトでそれらのパラメーターを使用してブートしますが、必要な場合にはそれらのパラメーターを使用せずにもカーネルを起動することも可能です。

• 現在のカーネルコマンドラインパラメーターを変更するには、以下のコマンドを実行します。

[root@compute ~]# grubby --update-kernel=ALL --args="intel_iommu=pt igb.max_vfs=7"

grubby の使用に関する詳しい情報は、『システム管理者ガイド』の「grubby ツールを使用した GRUB 2 メニューの永続的な変更」の項を参照してください。

注記: Dell Power Edge R630 ノードを使用している場合には、intel_iommu=pt の代わりに intel_iommu=on を使用する必要があります。これは、grubby で有効にすることができます。

# grubby --update-kernel=ALL --args="intel_iommu=on"

• カスタムのメニューエントリーを作成します。

i. grub でデフォルトエントリーを見つけます。

[root@compute ~]# grub2-editenv list
saved_entry=Red Hat Enterprise Linux Server (3.10.0-123.9.2.el7.x86_64) 7.0 (Maipo)

ii. a. saved_entry の値で始まる、任意の menuentry を /boot/grub2/grub.cfg から /etc/grub.d/40_custom にコピーします。このエントリーは「menuentry」で開始し、「}」を含む行で終了します。b. menuentry の後ろのタイトルを変更します。c. linux16 で始まる行の最後に、intel_iommu=pt igb.max_vfs=7 を追加します。

例:

menuentry 'Red Hat Enterprise Linux Server, with Linux 3.10.0-123.el7.x86_64 - SRIOV' --class red --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.10.0-123.el7.x86_64-advanced-4718717c-73ad-4f5f-800f-f415adfccd01' {
    load_video
    set gfxpayload=keep
    insmod gzio
    insmod part_msdos
    insmod ext2
    set root='hd0,msdos2'
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos2 --hint-efi=hd0,msdos2 --hint-baremetal=ahci0,msdos2 --hint='hd0,msdos2'  5edd1db4-1ebc-465c-8212-552a9c97456e
    else
      search --no-floppy --fs-uuid --set=root 5edd1db4-1ebc-465c-8212-552a9c97456e
    fi
    linux16 /vmlinuz-3.10.0-123.el7.x86_64 root=UUID=4718717c-73ad-4f5f-800f-f415adfccd01 ro vconsole.font=latarcyrheb-sun16 biosdevname=0 crashkernel=auto  vconsole.keymap=us nofb console=ttyS0,115200 LANG=en_US.UTF-8 intel_iommu=pt igb.max_vfs=7
    initrd16 /initramfs-3.10.0-123.el7.x86_64.img
}

iii. grub.cfg を更新して設定ファイルの変更を適用します。

[root@compute ~]# grub2-mkconfig -o /boot/grub2/grub.cfg

iv. デフォルトのエントリーを変更します。

[root@compute ~]# grub2-set-default 'Red Hat Enterprise Linux Server, with Linux 3.10.0-123.el7.x86_64 - SRIOV'

v. dist.conf 設定ファイルを作成します。

注記: このステップを実行する前に、allow_unsafe_interrupts の影響について説明している項 (allow_unsafe_interrupts 設定のレビュー) を確認してください。

[root@compute ~]# echo "options vfio_iommu_type1 allow_unsafe_interrupts=1" > /etc/modprobe.d/dist.conf

5. サーバーを再起動して、新しいカーネルパラメーターを適用します。

[root@compute ~]# systemctl reboot

6. コンピュートノードの SR-IOV カーネルモジュールを確認します。lsmod を実行して、カーネルモジュールが読み込まれていることを確認します。

[root@compute ~]#  lsmod |grep igb

フィルタリングされた結果には、必要なモジュールが含まれます。

igb    87592  0
dca    6708    1 igb

7. PCI ベンダー ID を確認します。ネットワークアダプターの PCI ベンダー ID (vendor_id:product_id 形式) をメモします。この内容は、-nn フラグを使用して、lspci コマンドの出力から抽出します。例を以下に示します。

[root@compute ~]# lspci  -nn | grep -i 82576
05:00.0 Ethernet controller [0200]: Intel Corporation 82576 Gigabit Network Connection [8086:10c9] (rev 01)
05:00.1 Ethernet controller [0200]: Intel Corporation 82576 Gigabit Network Connection [8086:10c9] (rev 01)
05:10.0 Ethernet controller [0200]: Intel Corporation 82576 Virtual Function [8086:10ca] (rev 01)

注記:このパラメーターは、ネットワークアダプターのハードウェアにより異なる場合があります。

8. 新しい VF を確認します。lspci を使用して、新規作成された VF を一覧表示します。

[root@compute ~]# lspci | grep 82576

以下のように、結果には、デバイスと VF が含まれて表示されます。

0b:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
0b:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection(rev 01)
0b:10.0 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
0b:10.1 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
0b:10.2 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
0b:10.3 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
0b:10.4 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
0b:10.5 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
0b:10.6 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
0b:10.7 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
0b:11.0 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
0b:11.1 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
0b:11.2 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
0b:11.3 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
0b:11.4 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)
0b:11.5 Ethernet controller: Intel Corporation 82576 Virtual Function (rev 01)

OpenStack Networking (neutron) は ML2 メカニズムのドライバーを使用して SR-IOV をサポートします。ネットワークノードで以下の手順を実行して、SR-IOV ドライバーを設定します。

1. sriovnicswitch in the /etc/neutron/plugins/ml2/openvswitch_agent.ini を有効化します。たとえば、この設定により、Open vSwitch に加え、SR-IOV メカニズムドライバーが有効化されます。

注記: sriovnicswitch は、DHCP エージェント の現在のインターフェースドライバーをサポートしません。そのため、sriovnicswitch の使用時には、openvswitch (または、VLAN サポートのある他のメカニズムのドライバー) が必要です。

[ml2]
tenant_network_types = vlan
type_drivers = vlan
mechanism_drivers = openvswitch, sriovnicswitch
[ml2_type_vlan]
network_vlan_ranges = physnet1:15:20

注記: メカニズムドライバー sriovnicswitch は現在 flat と vlan ドライバーのみをサポートしています。

2. (オプション) VF のリンク状態と管理状態を管理する必要がある場合には、/etc/neutron/plugins/ml2/sriov_agent.ini ファイルでこのオプションを有効にします。

[root@network ~]# openstack-config --set /etc/neutron/plugins/ml2/sriov_agent.ini ml2_sriov agent_required True

3. (オプション) サポートされた vendor_id/product_id のペアは 15b3:1004, 8086:10ca です。これと異なる場合には、お使いの NIC ベンダーの製品 ID を指定してください。以下に例を示します。

[ml2_sriov]
supported_pci_vendor_devs = 15b3:1004,8086:10ca

4. neutron-server.service が ml2_conf_sriov.ini ファイルを使用するように設定します。以下に例を示します。

[root@network ~]# vi /usr/lib/systemd/system/neutron-server.service

[Service]
Type=notify
User=neutron
ExecStart=/usr/bin/neutron-server --config-file /usr/share/neutron/neutron-dist.conf --config-file /etc/neutron/neutron.conf --config-file /etc/neutron/plugins/ml2/openvswitch_agent.ini --config-file /etc/neutron/plugins/ml2/sriov_agent.ini  --log-file /var/log/neutron/server.log

5. neutron-server サービスを再起動して、設定を適用します。

[root@network ~]# systemctl restart neutron-server.service

1. SR-IOV デバイスを適切にスケジュールできるように、コンピュートスケジューラーは PciPassthroughFilter フィルターで FilterScheduler を使用する必要があります。コントローラーノードの nova.conf ファイルでこの設定を適用します。以下に例を示します。

scheduler_available_filters=nova.scheduler.filters.all_filters
scheduler_default_filters=RetryFilter,AvailabilityZoneFilter,RamFilter,ComputeFilter,ComputeCapabilitiesFilter,ImagePropertiesFilter,CoreFilter, PciPassthroughFilter

2. コンピュートスケジューラーを再起動して、変更を適用します。

[root@compute ~]# systemctl restart openstack-nova-scheduler.service

全コンピュートノード上で、利用可能な VF と各物理ネットワークを関連付けます。

1. nova.conf ファイルでエントリーを定義します。この例では、enp5s0f1 と一致する VF ネットワークを追加して、physical_network を physnet1 (前の手順で network_vlan_ranges に設定したネットワークラベル) としてタグ付けします。

pci_passthrough_whitelist={"devname": "enp5s0f1", "physical_network":"physnet1"}

この例では、ベンダー ID 8086 と一致する PF ネットワークを追加し、physical_network を physnet1 としてタグ付けします: _~ pci_passthrough_whitelist = \{"vendor_id": "8086","product_id": "10ac", "physical_network":"physnet1"} _~

PCI パススルーのホワイトリストエントリーは、以下の構文を使用します。

["device_id": "<id>",] ["product_id": "<id>",]
["address": "[[[[<domain>]:]<bus>]:][<slot>][.[<function>]]" |
"devname": "Ethernet Interface Name",]
"physical_network":"Network label string"

1 ホストに複数のホワイトリストエントリーを設定することができます。device_id、product_id と address または devname のフィールドは、libvirt のクエリー結果として返された PCI デバイスと照合されます。

2. nova-compute サービスを再起動して変更を適用します。

[root@compute ~]# systemctl restart openstack-nova-compute

オプションの OpenStack Networking の SR-IOV エージェントにより、admin_state ポートの管理が有効になります。このエージェントを使用してネットワークアダプターを統合することで、管理者は VF の管理状態の up/down を切り替えることができるようになります。

また、OpenStack Networking (neutron) サーバー上で、agent_required=True を設定した場合には、各コンピュートノード上で OpenStack Networking の SR-IOV エージェントを実行する必要があります。

注記: 現在、すべての NIC ベンダーが、このエージェントを使用したポートの状態管理をサポートしているわけではありません。

1. 以下のステップを完了するには sriov-nic-agent パッケージをインストールします。

[root@compute ~]# yum install openstack-neutron-sriov-nic-agent

2. /etc/neutron/plugins/ml2/openvswitch_agent.ini ファイルで NoopFirewallDriver を有効にします。

[root@compute ~]# openstack-config --set /etc/neutron/plugins/ml2/openvswitch_agent.ini securitygroup firewall_driver neutron.agent.firewall.NoopFirewallDriver

3. /etc/neutron/plugins/ml2/sriov_agent.ini ファイルにマッピングを追加します。以下の例では、physnet1 が物理ネットワークで、enp4s0f1 が Physical Function (PF) です。exclude_devices を空白にして、関連付けられたすべての VF を、エージェントが管理できるようにします。

[sriov_nic]
physical_device_mappings = physnet1:enp4s0f1
exclude_devices =

4. (オプション) VF を除外します。エージェントの設定から特定の VF を除外するには、sriov_nic セクションに除外する VF を記載します。以下に例を示します。

exclude_devices = eth1:0000:07:00.2; 0000:07:00.3, eth2:0000:05:00.1; 0000:05:00.2

5. neutron-sriov-nic-agent.service が ml2_conf_sriov.ini ファイルを使用するように設定します。以下に例を示します。

[root@compute ~]# vi /usr/lib/systemd/system/neutron-sriov-nic-agent.service

[Service]
Type=simple
User=neutron
ExecStart=/usr/bin/neutron-sriov-nic-agent --config-file /usr/share/neutron/neutron-dist.conf --config-file /etc/neutron/neutron.conf --log-file /var/log/neutron/sriov-nic-agent.log --config-file /etc/neutron/plugins/ml2/sriov_agent.ini

6. OpenStack Networking の SR-IOV エージェントを起動します。

[root@compute ~]# systemctl enable neutron-sriov-nic-agent.service
[root@compute ~]# systemctl start neutron-sriov-nic-agent.service

この例では、SR-IOV ポートは web ネットワークに追加されます。

1. 利用可能なネットワークの一覧を取得します。

[root@network ~]# neutron net-list
+--------------------------------------+---------+------------------------------------------------------+
| id                                   | name    | subnets                                              |
+--------------------------------------+---------+------------------------------------------------------+
| 3c97eb09-957d-4ed7-b80e-6f052082b0f9 | corp    | 78328449-796b-49cc-96a8-1daba7a910be 172.24.4.224/28 |
| 721d555e-c2e8-4988-a66f-f7cbe493afdb | web     | 140e936e-0081-4412-a5ef-d05bacf3d1d7 10.0.0.0/24     |
+--------------------------------------+---------+------------------------------------------------------+

この結果出力には、OpenStack Networking で作成されたネットワークが一覧表示され、サブネットの詳細も含まれます。

2. web ネットワーク内にポートを作成します。

[root@network ~]# neutron port-create web --name sr-iov --binding:vnic-type direct
Created a new port:
+-----------------------+---------------------------------------------------------------------------------+
| Field                 | Value                                                                           |
+-----------------------+---------------------------------------------------------------------------------+
| admin_state_up        | True                                                                            |
| allowed_address_pairs |                                                                                 |
| binding:host_id       |                                                                                 |
| binding:profile       | {}                                                                              |
| binding:vif_details   | {}                                                                              |
| binding:vif_type      | unbound                                                                         |
| binding:vnic_type     | normal                                                                          |
| device_id             |                                                                                 |
| device_owner          |                                                                                 |
| fixed_ips             | {"subnet_id": "140e936e-0081-4412-a5ef-d05bacf3d1d7", "ip_address": "10.0.0.2"} |
| id                    | a2122b4d-c9a9-4a40-9b67-ca514ea10a1b                                            |
| mac_address           | fa:16:3e:b1:53:b3                                                               |
| name                  | sr-iov                                                                          |
| network_id            | 721d555e-c2e8-4988-a66f-f7cbe493afdb                                            |
| security_groups       | 3f06b19d-ec28-427b-8ec7-db2699c63e3d                                            |
| status                | DOWN                                                                            |
| tenant_id             | 7981849293f24ed48ed19f3f30e69690                                                |
+-----------------------+---------------------------------------------------------------------------------+

3. 新規ポートを使用してインスタンスを作成します。webserver01 という名前の新規インスタンスを作成し、以前の出力の id フィールドにあるポート ID で、このインスタンスが新規ポートを使用するように設定します。

注記: glance image-list コマンドを使用して、利用可能なイメージの一覧とその UUID を取得することができます。

[root@compute ~]# nova boot --flavor m1.tiny --image 59a66200-45d2-4b21-982b-d06bc26ff2d0  --nic port-id=a2122b4d-c9a9-4a40-9b67-ca514ea10a1b  webserver01

新規インスタンス webserver01 が作成され、このインスタンスが SR-IOV ポートを使用するように設定されました。

割り込み再マッピングのプラットフォームサポートは、割り当てデバイスを持つゲストをホストから完全に分離するために必要です。このサポートがない場合、ホストは悪意のあるゲストからのインジェクション攻撃に対して脆弱になる可能性があります。ゲストが信頼される環境では、管理者は引き続き allow_unsafe_interrupts オプションを使用する PCI デバイスの割り当てを選択することができます。ホストで allow_unsafe_interrupts を有効化する必要があるかどうかを確認します。ホストの IOMMU が割り込み再マッピングをサポートする場合には、この機能を有効にする必要はありません。

1. dmesg を使用して、ホストが IOMMU の割り込み再マッピングをサポートするかどうかを確認します。

[root@compute ~]# dmesg |grep ecap

ecap (0xf020ff → …​1111) のビット 3 が 1 の場合には、IOMMU が割り込み再マッピングをサポートしていることが分かります。

2. IRQ 再マッピングが有効化されているかどうかを確認します。

[root@compute ~]# dmesg |grep "Enabled IRQ"
[    0.033413] Enabled IRQ remapping in x2apic mode

注記: 「IRQ 再マッピング」は grub.conf に intremap=off を追加することで、手動で無効化できます。

3. ホストの IOMMU が割り込み再マッピングをサポートしない場合には、kvm モジュールで allow_unsafe_assigned_interrupts=1 を有効にする必要があります。