インスタンスが相互に通信し DHCP を使用して IP アドレスを受け取ることができるように、ネットワークを作成します。ネットワークを Red Hat OpenStack Platform デプロイメント内の外部ネットワークと統合することや、他の物理ネットワークと統合することも可能です。このような統合を行うと、インスタンスは外部のシステムと通信できるようになります。外部ネットワーク接続に関する詳しい情報は、「物理ネットワークのブリッジ」を参照してください。

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

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. 対象のインターフェースの インターフェースの削除 ボタンをクリックします。

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

4. プロジェクト > ネットワーク > ネットワーク を選択し、削除するネットワークを選択します。

5. ネットワークの削除 をクリックします。

以前のリリースでは、過去にプロジェクトに割り当てられた古いリソースがプロジェクトの削除後にも残っている場合がありました。これには、ネットワーク、ルーター、ポートなどが含まれます。以前のリリースでは、これらの古いリソースは、正しい順序で慎重に手動で削除する必要がありました。Red Hat OpenStack Platform 10 はこの問題に対処し、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 のテナントネットワークでは、複数のサブネットをホストできることを念頭に置いておいてください。これは、まったく異なるシステムを同じネットワークでホストし、それらのシステムを分離する場合に役立ちます。たとえば、1 つのサブネットでは Web サーバーのトラフィックだけが伝送されるようにする一方で、別のサブネットはデータベースのトラフィックが通過するように指定することができます。サブネットは相互に分離され、別のサブネットと通信する必要のあるインスタンスのトラフィックは、ルーターによって転送する必要があります。大量のトラフィックを必要とする複数のシステムを、同じサブネットに配置すると、ルーティングの必要がなく、ルーティングに伴うレイテンシーや負荷を回避することができます。

使用しなくなったサブネットは削除することができます。ただし、インスタンスがまだそのサブネットを使用するように設定されている場合には、削除を試みても失敗し、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 エージェントにつき 1 つの Floating IP プールをサポートします。したがって、L3 エージェントをスケールアウトすることによって追加の Floating IP プールを作成することができます。

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

# vi /etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
TYPE=OVSPort
DEVICETYPE=ovs
OVS_BRIDGE=br-ex
ONBOOT=yes

eth0 に以前確保されていた IP アドレスの情報を使用して仮想ブリッジを設定します。

# 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 を指定します。この中で、外部ネットワークだけは外部の物理ネットワークにルーティングが可能でなければなりません。本リリースでは、DHCP サービスは director により提供されます。

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

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

以下の例には、複数のサブネットに対応する、さまざまなネットワークを示しています。各サブネットには IP アドレスの範囲が 1 つ割り当てられます。

以下の手順では、特定のルーターに接続されたポートをすべて一覧表示し、ポートの状態 (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
# 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 (namespace) を追加します。以下に例を示します。

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 を使用して、この外部ネットワーク内にサブネットを作成します。以下に例を示します。

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 public01 192.168.100.0/24

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/ml2/openvswitch_agent.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/ml2/openvswitch_agent.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/ml2/openvswitch_agent.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/ml2/openvswitch_agent.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 サービスの接続性を提供します。

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 つのポートに適用します。

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

Differentiated Services Code Point (DSCP) では、IP ヘッダーに関連の値を埋め込むことで、ネットワーク上に QoS を実装することができます。OpenStack Networking (neutron) QoS ポリシーは、DSCP マーキングを使用して、neutron ポートとネットワーク上で送信トラフィックを管理することができます。現在、DSCP は Open vSwitch (OVS) を使用する VLAN とフラットプロバイダーネットワークのみに利用できます。今後、VXLAN もサポートされる予定です。

この実装では、最初にポリシーが作成され、DSCP ルールが定義されてポリシーに適用されます。これらのルールは、--dscp-mark パラメーターを使用して、DSCP マークに 10 進数の値を指定します。以下に例を示します。

1. 新規 QoS ポリシーを作成します。

neutron qos-policy-create qos-web-servers --tenant-id 98a2f53c20ce4d50a40dac4a38016c69

2. DSCP マーク 18 を使用して、DSCP ルールを作成してそれを qos-web-servers ポリシーに適用します。

neutron qos-dscp-marking-rule-create qos-web-servers --dscp-mark 18
Created a new dscp_marking_rule:
+-----------+--------------------------------------+
| Field     | Value                                |
+-----------+--------------------------------------+
| dscp_mark | 18                                   |
| id        | d7f976ec-7fab-4e60-af70-f59bf88198e6 |
+-----------+--------------------------------------+

3. QoS ポリシー qos-web-servers の DSCP ルールを表示します。

neutron qos-dscp-marking-rule-list qos-web-servers
+-----------+--------------------------------------+
| dscp_mark | id                                   |
+-----------+--------------------------------------+
|        18 | d7f976ec-7fab-4e60-af70-f59bf88198e6 |
+-----------+--------------------------------------+

4. qos-web-servers ポリシーに割り当てられた DSCP ルールの詳細を表示します。

neutron qos-dscp-marking-rule-show d7f976ec-7fab-4e60-af70-f59bf88198e6 qos-web-servers
+-----------+--------------------------------------+
| Field     | Value                                |
+-----------+--------------------------------------+
| dscp_mark | 18                                   |
| id        | d7f976ec-7fab-4e60-af70-f59bf88198e6 |
+-----------+--------------------------------------+

5. ルールに割り当てられた DSCP 値を変更します。

neutron qos-dscp-marking-rule-update d7f976ec-7fab-4e60-af70-f59bf88198e6 qos-web-servers --dscp-mark 22
Updated dscp_marking_rule: d7f976ec-7fab-4e60-af70-f59bf88198e6

6. DSCP ルールを削除します。

neutron qos-dscp-marking-rule-delete d7f976ec-7fab-4e60-af70-f59bf88198e6 qos-web-servers
Deleted dscp_marking_rule(s): d7f976ec-7fab-4e60-af70-f59bf88198e6

Red Hat OpenStack Platform 10 では、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 の間のパッチポートにより、トラフィックはプロバイダーネットワークのブリッジを通過して物理ネットワークまで到達することができます。

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

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

network_vlan_ranges = physnet1:10:20,physnet2:21:25

マッピングを削除した後には、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 /etc/neutron/plugins/ml2/openvswitch_agent.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

neutron がサブポートに割り当てた MAC アドレスを使用するには、インスタンスのオペレーティングシステムを設定する必要があります。サブポート作成のステップで、固有の MAC アドレスを使用するようにサブポートも設定してください。

1. ネットワークトランクの設定を確認します。

$ openstack network trunk list
+--------------------------------------+--------------+--------------------------------------+-------------+
| ID                                   | Name         | Parent Port                          | Description |
+--------------------------------------+--------------+--------------------------------------+-------------+
| 0e4263e2-5761-4cf6-ab6d-b22884a0fa88 | parent-trunk | 20b6fdf8-0d43-475a-a0f1-ec8f757a4a39 |             |
+--------------------------------------+--------------+--------------------------------------+-------------+


$ openstack network trunk show parent-trunk
+-----------------+------------------------------------------------------------------------------------------------+
| Field           | Value                                                                                          |
+-----------------+------------------------------------------------------------------------------------------------+
| admin_state_up  | UP                                                                                             |
| created_at      | 2016-10-20T02:05:17Z                                                                           |
| description     |                                                                                                |
| id              | 0e4263e2-5761-4cf6-ab6d-b22884a0fa88                                                           |
| name            | parent-trunk                                                                                   |
| port_id         | 20b6fdf8-0d43-475a-a0f1-ec8f757a4a39                                                           |
| revision_number | 2                                                                                              |
| status          | DOWN                                                                                           |
| sub_ports       | port_id='479d742e-dd00-4c24-8dd6-b7297fab3ee9', segmentation_id='55', segmentation_type='vlan' |
| tenant_id       | 745d33000ac74d30a77539f8920555e7                                                               |
| updated_at      | 2016-10-20T02:10:06Z                                                                           |
+-----------------+------------------------------------------------------------------------------------------------+

2. 親ポート id を仮想 NIC として使用するインスタンスを作成します。

nova boot --image cirros --flavor m1.tiny testInstance --security-groups default --key-name sshaccess --nic port-id=20b6fdf8-0d43-475a-a0f1-ec8f757a4a39


+--------------------------------------+-----------------------------------------------+
| Property                             | Value                                         |
+--------------------------------------+-----------------------------------------------+
| OS-DCF:diskConfig                    | MANUAL                                        |
| OS-EXT-AZ:availability_zone          |                                               |
| OS-EXT-SRV-ATTR:host                 | -                                             |
| OS-EXT-SRV-ATTR:hostname             | testinstance                                  |
| OS-EXT-SRV-ATTR:hypervisor_hostname  | -                                             |
| OS-EXT-SRV-ATTR:instance_name        |                                               |
| OS-EXT-SRV-ATTR:kernel_id            |                                               |
| OS-EXT-SRV-ATTR:launch_index         | 0                                             |
| OS-EXT-SRV-ATTR:ramdisk_id           |                                               |
| OS-EXT-SRV-ATTR:reservation_id       | r-juqco0el                                    |
| OS-EXT-SRV-ATTR:root_device_name     | -                                             |
| OS-EXT-SRV-ATTR:user_data            | -                                             |
| OS-EXT-STS:power_state               | 0                                             |
| OS-EXT-STS:task_state                | scheduling                                    |
| OS-EXT-STS:vm_state                  | building                                      |
| OS-SRV-USG:launched_at               | -                                             |
| OS-SRV-USG:terminated_at             | -                                             |
| accessIPv4                           |                                               |
| accessIPv6                           |                                               |
| adminPass                            | uMyL8PnZRBwQ                                  |
| config_drive                         |                                               |
| created                              | 2016-10-20T03:02:51Z                          |
| description                          | -                                             |
| flavor                               | m1.tiny (1)                                   |
| hostId                               |                                               |
| host_status                          |                                               |
| id                                   | 88b7aede-1305-4d91-a180-67e7eac8b70d          |
| image                                | cirros (568372f7-15df-4e61-a05f-10954f79a3c4) |
| key_name                             | sshaccess                                     |
| locked                               | False                                         |
| metadata                             | {}                                            |
| name                                 | testInstance                                  |
| os-extended-volumes:volumes_attached | []                                            |
| progress                             | 0                                             |
| security_groups                      | default                                       |
| status                               | BUILD                                         |
| tags                                 | []                                            |
| tenant_id                            | 745d33000ac74d30a77539f8920555e7              |
| updated                              | 2016-10-20T03:02:51Z                          |
| user_id                              | 8c4aea738d774967b4ef388eb41fef5e              |
+--------------------------------------+-----------------------------------------------+

以下の手順では、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 |
+--------------------------------------+-------------+------------------------------------------------------+

OpenStack Networking (neutron) は、プロジェクトネットワークにルーティングサービスを提供します。ルーターがない場合には、プロジェクトネットワーク内のインスタンスは、共有 L2 ブロードキャストドメインでのみ相互通信が可能となります。ルーターを作成して、テナントネットワークに割り当てると、そのネットワークのインスタンスが他のプロジェクトネットワークやアップストリームと通信することができます (外部ゲートウェイがルーターに定義されている場合)。

分散仮想ルーティング (DVR) では、別のルーティング設計も提供されており、Red Hat OpenStack Platform 10 で完全にサポートされるようになりました。これは、コントローラーノードの障害のあるドメインを分離して、L3 エージェントをデプロイしてネットワークトラフィックを最適化し、全コンピュートノードにルーターをスケジューリングすることが目的です。DVR の使用時には以下が可能です。

neutron-ovs-dvr.yaml の環境ファイルは、必須の DVR 固有のパラメーターを設定します。任意のデプロイメント構成の DVR を設定するには、他にも考慮する事項があります。要件は以下のとおりです。

(a) 外部ネットワークトラフィック用の物理ネットワークに接続されたインターフェースは、コンピュートノードとコントローラーノードの両方で設定すること。

(b) コンピュートノードおよびコントローラーノードでブリッジを作成して、外部ネットワークトラフィック用のインターフェースを設定すること。

(c) Neutron がこのブリッジを使用できるように設定すること。

ホストのネットワーク設定 (a および b) は Heat テンプレートが制御しており、これらのテンプレートにより、os-net-config プロセスで使用できるように、Heat が管理するノードに設定が渡されます。これは基本的には、ホストのネットワークのプロビジョニングを自動化しています。プロビジョニングしたネットワーク環境と一致するように、Neutron も設定する必要があります (c)。デフォルトの設定は、実稼動環境で機能するように想定されていません。たとえば、通常のデフォルト設定を使用する概念実証用の環境は、以下のようになります。

1. environments/neutron-ovs-dvr.yaml の OS::TripleO::Compute::Net::SoftwareConfig の値が使用中の OS::TripleO::Controller::Net::SoftwareConfig の値と同じであることを確認します。これは通常、environments/net-multiple-nics.yaml など、オーバークラウドのデプロイ時に使用するネットワーク環境ファイルに含まれます。これにより、コンピュートノードの L3 エージェントに適した外部のネットワークブリッジが作成されます。

2. OS::TripleO::Compute::Ports::ExternalPort: ../network/ports/external.yaml など、OS::TripleO::Compute::Ports::ExternalPort を適切な値に変更して、外部ネットワークにあるコンピュートノードの neutron ポートを設定します。

3. オーバークラウドのデプロイ時に環境ファイルとして environments/neutron-ovs-dvr.yaml を追加します。以下に例を示します。

$ openstack overcloud deploy --templates -e /usr/share/openstack-tripleo-heat-templates/environments/neutron-ovs-dvr.yaml

4. L3 HA が無効になっていることを確認します。

実稼動環境 (または、ネットワークの分離、専用の NIC など、特別にカスタマイズする必要があるテスト環境) の場合には、環境の例は指針として利用してください。L2 エージェント (例: OVS) が使用するブリッジマッピングタイプのパラメーターや、他のエージェント (例: L3 エージェント) の外部向けのブリッジへの参照には、細心の注意を払う必要があります。

本項では、L3 HA 集中ルーティングを使用する Red Hat OpenStack Platform 9 デプロイメントの分散ルーティングへのアップグレードパスについて説明します。

1. デプロイメントを Red Hat OpenStack Platform 9 から 10 にアップグレードし、正常に機能していることを確認します。

2. 「DVR のデプロイ」に記載の手順に従って、director のスタック更新を実行して DVR を設定します。

3. 既存のルーターでルーティングがまだ機能していることを確認します。

4. L3 HA ルーターを直接 分散型 に移行することはできません。代わりに、各ルーターで L3 HA オプションを無効にしてから分散型のオプションを有効にします。

4a. ルーターの admin 状態を無効にします。

$ neutron router-update --admin-state-up=False

4b. ルーターを レガシー タイプに変換します。

$ neutron router-update --ha=False

4c. ルーターが DVR を使用するように設定します。

$ neutron router-update --distributed=True

4d. ルーターを admin 状態に切り替えます。

$ neutron router-update --admin-state-up=True

4e. ルーティングがまだ機能していて、分散型になったことを確認します。

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

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

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

以下の図には、HTTPS トラフィックからプールメンバーへのフローを示しています。

本手順では、OpenStack Networking (neutron) が Open vSwitch (OVS) プラグインで LBaas を使用するように設定します。

コントローラーノード (API サーバー) で、以下の操作を行います。

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

# openstack project list
+----------------------------------+----------+
| ID                               | Name     |
+----------------------------------+----------+
| 25837c567ed5458fbb441d39862e1399 |    QA    |
| f59f631a77264a8eb0defc898cb836af |  admin   |
| 4e2e1951e70643b5af7ed52f3ff36539 |   demo   |
| 8561dff8310e4cd8be4b6fd03dc8acf5 | services |
+----------------------------------+----------+

# 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 操作 (1 つのルールを追加する場合) のいずれかを使用して、後でルールを追加することができます。

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

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

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

ポートを作成して、1 つのアドレスペアを許可します。

# 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 高可用性を有効化します。

l3_ha = True
max_l3_agents_per_router = 2
min_l3_agents_per_router = 2

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

# systemctl restart neutron-server.service

# 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

SR-IOV により、Virtual Function の概念がサポートされるようになりました。これは、ハードウェア上の PCI デバイスとして提供されるものの、Physical Function が提供する 仮想インターフェース です。

本章では、SR-IOV を設定して 物理 NIC を仮想インスタンスに渡す手順について説明します。以下の手順では、コントローラーノード、OpenStack Networking (neutron) ノード、および複数の Compute (nova) ノードを使用するデプロイメントを前提としています。

サポート対象のハードウェアを持つすべてのコンピュートノードで、以下の手順を実施します。

注記: サポートされるドライバーの詳細は、この アーティクル を参照してください。

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

1. システムの BIOS で Intel VT-d または AMD IOMMU が有効になるようにします。マシンの 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. 以降のステップを実施して、コンピュートノード上で Virtual Function をアクティブ化します。

4a. カーネルモジュールを削除します。これにより、カーネルモジュールを次のステップで設定できるようになります。

[root@compute ~]# modprobe -r igb

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

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

4b. max_vfs を 7 に設定して (またはサポートされる最大値まで) モジュールを起動します。

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

4c. Virtual Function を永続化します。

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

注記: Red Hat Enterprise Linux 7 では、上記の変更を永続化するには、ステップ 4 の完了後に 初期 ramdisk イメージを再ビルドします。

注記: ステップ 4c および 4d の設定の永続化について: modprobe コマンドにより同じカーネルモジュールを使用するすべての NIC で Virtual Function が有効になり、システムをリブートしても変更が維持されます。特定の 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. 新しい Virtual Function を確認します。lspci を使用して、新たに作成された VF を一覧表示します。

[root@compute ~]# lspci | grep 82576

結果に、デバイスおよび Virtual Function が含まれるようになりました。

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 ドライバーを設定するには、ネットワークノードで以下の手順を実施します。以下の手順では、メカニズムドライバーを追加し、vlan が有効にしたドライバーに含まれる状態にし、続いて VLAN 範囲を定義します。

1. /etc/neutron/plugins/ml2/ml2_conf.ini ファイルで sriovnicswitch を有効にします。たとえば、この設定により、Open vSwitch と共に SR-IOV メカニズムドライバーが有効になります。

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

注記: メカニズムドライバー sriovnicswitch は、現在 flat ドライバーおよび vlan ドライバーのみをサポートしています。ただし、sriovnicswitch を有効しても、テナントネットワークが flat および vlan だけに制限される訳ではありません。VXLAN および GRE などは、引き続き SR-IOV ポートを使用しないインスタンスに使用することができます。

2. (オプション) サポートされる vendor_id/product_id の組み合わせは 15b3:1004, 8086:10ca です。実際の NIC ベンダーの製品 ID がこれとは異なる場合、その ID を指定します。さらに、PF パススルーを使用している場合は、この一覧を変更しなければならない場合があります。以下に例を示します。

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

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

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

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

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

2. Compute のスケジューラーを再起動して変更を適用します。

[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"

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

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

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

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 になります。exclude_devices を空白のままにして、エージェントが関連付けられたすべての VF を管理できるようにします。

[sriov_nic]
physical_device_mappings = physnet1:enp4s0f1
exclude_devices =

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

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

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

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

SR-IOV 機能の概要

SR-IOV により、Physical Function (PF) および Virtual Function (VF) を使用して、インスタンスが直接 NIC にアクセスすることができます。PF は VF を使用して、複数のインスタンスが同じ PCI カードに直接アクセスできるようにします。その結果、PCI カードは、複数のインスタンスが使用できるように論理的に VF に分割されていると考えることができます。このことから、SR-IOV は、PCI デバイスへの独占的アクセスを 1 つのインスタンスだけに付与する PCI パススルーとは異なります。

Virtual Functions の制限次項

設定例

以下の例では、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

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

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

Physical Functions (PF) をインスタンスに公開するように Compute を設定することができます。インスタンスに物理ポートに対する完全な制御を付与することで、このユースケースは NFV アプリケーションに役立ちます。これにより、インスタンスは Virtual Functions (VF) では利用できない一部機能を使用することができます。これらのインスタンスは、特定のカードが VF に適用する制限の一部を回避することや、ポートの全帯域幅を独占して使用することができます。

インスタンスに割り当てられている子 VF がない場合に、Compute では未使用の PF をインスタンスに割り当てることができます。PF が割り当てられると、その VF はいずれも使用できなくなります。インスタンスがシャットダウンされ、PF が未使用の状態になると、VF は再び使用できるようになります。逆に、子 VF のいずれかがすでに割り当てられている場合、Compute は PF が割り当てられないようにします。

pci_passthrough_whitelist={"product_id":"10ed", "vendor_id":"8086", "physical_network":"physnet1",'device_type': 'type-PF}

$ neutron port-create Network1 --name pf-port --binding:vnic_type direct-physical