Menu Close

第7章 物理ネットワークへのインスタンスの接続

本章では、プロバイダーネットワークを使用して外部ネットワークに直接インスタンスを接続する方法を説明します。

OpenStack Networking トポロジーの概要

OpenStack Networking (neutron) には、複数のノード種別に分散される 2 種類のサービスがあります。

  • Neutron サーバー: このサービスは、エンドユーザーとサービスが OpenStack Networking と対話するための API を提供する OpenStack Networking API サーバーを実行します。このサーバーは、下層のデータベースと統合して、テナントネットワーク、ルーター、ロードバランサーの詳細などを保管します。
  • Neutron エージェント: これらは、OpenStack Networking のネットワーク機能を実行するサービスです。

    • neutron-dhcp-agent: テナントプライベートネットワークの DHCP IP アドレスを管理します。
    • neutron-l3-agent: テナントプライベートネットワーク、外部ネットワークなどの間のレイヤー 3 ルーティングを実行します。
    • neutron-lbaas-agent: テナントにより作成された LBaaS ルーターをプロビジョニングします。
  • コンピュートノード: このノードは、仮想マシン (別称: インスタンス) を実行するハイパーバイザーをホストします。コンピュートノードは、インスタンスに外部への接続を提供するために、ネットワークに有線で直接接続する必要があります。このノードは通常、neutron-openvswitch-agent などの L2 エージェントが実行される場所です。

サービスの配置:

OpenStack Networking サービスは、同じ物理サーバーまたは別の専用サーバー (役割によって名付けられる) で実行することができます。

  • コントローラーノード: API サービスを実行するサーバー
  • ネットワークノード: OpenStack Networking エージェントを実行するサーバー
  • コンピュートノード: インスタンスをホストするハイパーバイザー

本章の以下の手順では、環境に上記の 3 種類のノード種別がデプロイされていることが前提です。お使いのデプロイメントで、同じ物理ノードがコントローラーノードとネットワークノードの両方の役割を果たしている場合には、そのサーバーで両ノードのセクションの手順を実行する必要があります。これは、3 つの全ノードにおいてコントローラーノードおよびネットワークノードサービスが HA で実行されている高可用性 (HA) 環境にも適用されます。そのため、コントローラーノードとネットワークノードに該当するセクションの手順を全 3 ノードで実行する必要があります。

7.1. フラットプロバイダーネットワークの使用

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

注記

単一の NIC 上の VLAN タグ付けされた複数のインターフェースを複数のプロバイダーネットワークに接続する場合には、「VLAN プロバイダーネットワークの使用」を参照してください。

コントローラーノードの設定

1. /etc/neutron/plugin.ini (/etc/neutron/plugins/ml2/ml2_conf.ini へのシンボリックリンク) を編集し、既存の値リストに flat を追加し、flat_networks* に設定します。

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 の設定に関する詳しい情報は、「11章ブリッジマッピングの設定」を参照してください。

bridge_mappings = physnet1:br-ex

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

 # systemctl restart neutron-openvswitch-agent

ネットワークノードの設定

1. /etc/neutron/l3_agent.iniexternal_network_bridge = に空の値を設定します。これにより、外部プロバイダーネットワークが使用できるようになります。

# 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
注記

複数のフラットプロバイダーネットワークが存在する場合には、それぞれに異なる物理インターフェースとブリッジを使用して外部ネットワークに接続すべきです。ifcfg-* スクリプトを適切に設定し、bridge_mappings にコンマ区切りリストでネットワーク別のマッピングを指定してください。bridge_mappings の設定に関する詳しい情報は、「11章ブリッジマッピングの設定」を参照してください。

外部ネットワークへのインスタンスの接続

このネットワークが作成されると、インスタンスを接続して、接続性をテストすることができます。

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

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

パケットフローについて

フラットネットワークが設定され、本項ではインスタンスに対するトラフィックの流れについて詳しく説明します。

7.1.1. 送信トラフィックのフロー

インスタンスから送信され、直接外部ネットワークに到達するトラフィックのパケットフロー: br-ex を設定し、物理インターフェースを追加してインスタンスをコンピュートノードに作成すると、作成されるインターフェースとブリッジは以下の図のようになります (iptables_hybrid ファイアウォールドライバーを使用する場合)。

flat provider out

1. インスタンスの eth0 インターフェースからのパケットは最初に linux ブリッジ qbr-xx に到達します。

2. ブリッジ qbr-xx は、veth ペア qvb-xx <-> qvo-xxx を使用して br-int に接続されます。これは、セキュリティーグループによって定義されている受信/送信のファイアウォールルールの適用にブリッジが使用されるためです。

3. インターフェース qvb-xxqbr-xx linux ブリッジに、qvoxxbr-int Open vSwitch (OVS) ブリッジに接続されます。

qbr-xx Linux ブリッジの設定例を以下に示します。

 # brctl show
qbr269d4d73-e7		8000.061943266ebb	no		qvb269d4d73-e7
							tap269d4d73-e7

br-int 上の qvo-xx の設定:

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

注記

ポート qvo-xx は、フラットなプロバイダーネットワークに関連付けられた内部 VLAN タグでタグ付けされます。この例では VLAN タグは 5 です。パケットが qvo-xx に到達すると、VLAN タグがパケットのヘッダーに追加されます。

次にこのパケットは、パッチピア int-br-ex <-> phy-br-ex を使用して br-ex OVS ブリッジに移動します。

br-int でのパッチピアの設定例を以下に示します。

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

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

このパケットが br-exphy-br-ex に到達すると、br-ex 内の OVS フローにより VLAN タグ (5) が取り除かれ、物理インターフェースに転送されます。

以下の出力例では、phy-br-ex のポート番号は 2 となっています。

 # 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

以下の出力例では、VLAN タグが 5 (dl_vlan=5) の phy-br-ex (in_port=2) に到達するパケットを示しています。さらに、VLAN タグは削除され、パケットが転送されます (actions=strip_vlan,NORMAL)。

# 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

このパケットは、次に物理インターフェースに転送されます。物理インターフェースが別の VLAN タグ付きインターフェースの場合、そのインターフェースはパケットにタグを追加します。

7.1.2. 受信トラフィックのフロー

本項では、外部ネットワークからインスタンスのインターフェースに到達するまでの受信トラフィックのフローを説明します。

flat provider in

1. 受信トラフィックは、まず物理ノードの eth1 に到達します。

2. 次にパケットは br-ex ブリッジに渡されます。

3. パッチピア phy-br-ex <--> int-br-ex を使用して、このパケットは br-int に移動します。

以下の例では、int-br-ex がポート番号 15 を使用します。15(int-br-ex) が含まれるエントリーに注目してください。

 # 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

br-int のトラフィックフローの確認

1. パケットが int-br-ex に到達すると、br-int ブリッジ内の OVS フロールールにより、内部 VLAN タグ 5 を追加するようにパケットが変更されます。actions=mod_vlan_vid:5 のエントリーを参照してください。

 # 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

2. 2 番目のルールは、VLAN タグのない (vlan_tci=0x0000) int-br-ex (in_port=15) に到達するパケットを管理します。これにより、VLAN タグ 5 はパケット (actions=mod_vlan_vid:5,NORMAL) に追加され、qvoxxx に転送されます。

3. qvoxxx は、VLAN タグを削除した後に、パケットを受け入れて qvbxx に転送します。

4. 最終的にパケットはインスタンスに到達します。

注記

VLAN tag 5 は、フラットプロバイダーネットワークを使用するテスト用コンピュートノードで使用したサンプルの VLAN です。この値は neutron-openvswitch-agent により自動的に割り当てられました。お使いのフラットプロバイダーネットワークの値とは異なる可能性があり、2 種のコンピュートノード上にある同じネットワークにおいても異なる可能性があります。

7.1.3. トラブルシューティング

前項「パケットフローについて」で提供される出力で、問題が発生した場合にフラットプロバイダーネットワークをトラブルシューティングするのに順分なデバッグ情報が得られます。以下の手順は、さらにトラブルシューティングプロセスの手助けとなります。

1. bridge_mappings を確認します。

使用する物理ネットワーク名 (例: physnet1) が bridge_mapping 設定の内容と一致していることを確認します。以下に例を示します。

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

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

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

ネットワークが external として作成され、flat の種別が使用されていることを確認します。

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

3. パッチピアを確認します。

ovs-vsctl show を実行し、int-br-ex <--> phy-br-ex を使用して br-int および br-ex が接続されていることを確認します。

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

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

この接続は、neutron-openvswitch-agent サービスが再起動される際に作成されます。ただし、/etc/neutron/plugins/ml2/openvswitch_agent.inibridge_mapping が正しく設定されている場合に限ります。サービスを再起動した後でもこれが作成されない場合には、bridge_mapping の設定を再確認してください。

注記

bridge_mappings の設定に関する詳しい情報は、「11章ブリッジマッピングの設定」を参照してください。

4. ネットワークフローを確認します。

ovs-ofctl dump-flows br-exovs-ofctl dump-flows br-int を実行して、フローにより送信パケットの内部 VLAN ID が削除されたかどうかを確認します。まず、このフローは、特定のコンピュートノード上のこのネットワークにインスタンスを作成すると追加されます。

  • インスタンスの起動後にこのフローが作成されなかった場合には、ネットワークが flat として作成されていて、external であることと、physical_network の名前が正しいことを確認します。また、bridge_mapping の設定を確認してください。
  • 最後に ifcfg-br-exifcfg-ethx の設定をチェックします。ethXbr-ex 内のポートとして追加されており、いずれも ip a の出力で UP フラグが表示されることを確認します。

たとえば、以下の出力では eth1br-ex のポートであることが分かります。

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

以下の例では eth1 は OVS ポートとして設定されており、カーネルはこのインターフェースからのパケットをすべて転送して OVS ブリッジ br-ex に送信することを認識していることが分かります。これは、master ovs-system のエントリーで確認することができます。

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