Red Hat Training
A Red Hat training course is available for Red Hat OpenStack Platform
第2章 OpenStack Networking の概念
OpenStack Networking には、ルーティング、DHCP、メタデータなどのコアサービスを管理するシステムサービスがあります。これらのサービスが 1 つにまとまって、物理サーバーに割り当てられる概念的なロールであるコントローラーノードの概念に含まれます。物理サーバーは通常、ネットワークノード のロールが割り当てられ、インスタンス間のネットワークトラフィックのレイヤー 3 ルーティングを管理するタスクに特化して稼働します。OpenStack Networking では、このロールを実行する複数の物理ホストを指定することができ、ハードウェア障害が発生した場合に向けたサービスの冗長化が可能です。詳しい情報は、「レイヤー 3 の高可用性」の章を参照してください。
Red Hat OpenStack Platform 11 では、コンポーザブルロールのサポートが追加され、ネットワークサービスをカスタムロール別に分類することができます。ただし、本ガイドでは、内容をわかりやすくするために、デプロイメントにはデフォルトのコントローラーノードを使用することを前提とします。
2.1. OpenStack Networking (neutron) のインストール
2.1.1. サポートされるインストール
OpenStack Networking コンポーネントは、Red Hat OpenStack Platform director デプロイメントの一部としてインストールされます。詳しくは、『director のインストールと使用方法』ガイドを参照してください。
2.2. OpenStack Networking の図
以下の図は、専用の OpenStack Networking ノードが L3 ルーティングと DHCP の機能を果たし、FWaaS や LBaaS の高度なサービスを実行する OpenStack Networking のデプロイメントの例です。2 つのコンピュートノードは Open vSwitch (openvswitch-agent) を実行し、それぞれにテナントトラフィックと管理用の接続向けに物理ネットワークカードが 2 つ搭載されています。また、OpenStack Networking ノードには、プロバイダートラフィック専用の 3 枚目のネットワークカードがあります。
2.3. セキュリティーグループ
セキュリティーグループおよびルールを使用して、任意の neutron ポートに送信 (および任意の neustron ポートから受信) されるネットワークトラフィックの種別と方向をフィルタリングします。これにより、セキュリティーにもう 1 つレイヤーが追加されて、コンピュートインスタンスに存在するファイアウォールルールが補完されます。セキュリティーグループとは、1 つ以上のセキュリティールールを含むコンテナーオブジェクトのことで、1 つのセキュリティーグループで複数のコンピュートインスタンスへのトラフィックを管理することができます。Floating IP アドレス、OpenStack Networking LBaaS の仮想 IP、およびインスタンスのために作成されたポートは、セキュリティーグループに割り当てられます。セキュリティーグループが指定されなかった場合には、ポートは default のセキュリティーグループに割り当てられます。デフォルトでは、このグループは全受信トラフィックをドロップし、全送信トラフィックを許可します。追加のセキュリティールールを default セキュリティーグループに追加して動作を変更したり、必要に応じて新規セキュリティーグループを作成したりすることができます。
2.4. Open vSwitch
Open vSwitch は、レガシーの Linux ソフトウェアブリッジと同様の、ソフトウェア定義ネットワーク (SDN: Software-Defined Networking) の仮想スイッチです。OVS は業界標準の NetFlow、OpenFlow、および sFlow をサポートする仮想ネットワークへのスイッチングサービスを提供します。Open vSwitch は、STP、LACP、802.1Q VLAN タグ付け などのレイヤー 2 (L2) 機能を使用することで物理スイッチとの統合も可能です。VXLAN と GRE を使用したトンネリングは、Open vSwitch のバージョン 1.11.0-1.el6 以降でサポートされています。
LACP は OVS ベースのボンディングでは使用しないでください。この構成は問題があるため、サポートされていません。この機能の代わりとして、bond_mode=balance-slb
を使用することを検討してください。また、LACP は Linux ボンディングで使用することも可能です。この要件に関する技術的な詳細は、BZ#1267291 を参照してください。
1 つのブリッジには単一のインターフェースまたは単一のボンディングのみをメンバーにすると、Open vSwitch でネットワークループが発生するリスクを緩和することができます。複数のボンディングまたはインターフェースが必要な場合には、複数のブリッジを設定することが可能です。
2.5. Modular Layer 2 (ML2)
ML2 とは、OpenStack Havana リリースで導入された OpenStack Networking コアプラグインです。以前のモノリシックなプラグインのモデルに置き換わる、ML2 のモジュラー型設計により、複数のネットワーク技術を組み合わせた操作を同時に実行できます。モノリシックな Open vSwitch および Linux Bridge プラグインは、非推奨となり、削除されました。これらの機能は、代わりに ML2 メカニズムドライバーとして再実装されています。
ML2 はデフォルトの OpenStack Networking プラグインで、Open vSwitch がデフォルトのメカニズムドライバーとして設定されています。
2.5.1. ML2 が導入された理由
以前は、OpenStack Networking のデプロイでは、実装時に選択したプラグインしか使用することができませんでした。たとえば、Open vSwitch プラグインを実行するデプロイは、Open vSwitch のみを単独にしか使えず、linuxbridge などの別のプラグインを同時に実行することは不可能でした。複数の異なる要件を伴う環境では、これは制限事項となっていました。
2.5.2. ML2 ネットワーク種別
ML2 ネットワーク種別では、複数のネットワークセグメントタイプを同時に操作することができます。また、これらのネットワークセグメントは、ML2 のマルチセグメントネットワークサポートを利用して相互接続することが可能です。ポートは接続性のあるセグメントに自動的にバインドされ、特定のセグメントにバインドする必要はありません。メカニズムドライバーにより、ML2 は、次のネットワークセグメントタイプをサポートします 。
- flat
- GRE
- local
- VLAN
- VXLAN
ml2_conf.ini ファイルの ML2 セクションでは、さまざまな タイプの ドライバーが有効化されます。
[ml2] type_drivers = local,flat,vlan,gre,vxlan
2.5.3. ML2 メカニズムドライバー
共通のコードベースを使用するメカニズムとしてプラグインが再実装されています。このアプローチにより、コードの再利用が可能になる上、コードのメンテナンスとテストにおける複雑性が大幅に軽減されます。
サポートされるメカニズムドライバーの一覧は、『リリースノート』を参照してください。
ml2_conf.ini ファイルの ML2 セクションでさまざまなメカニズムドライバーが有効化されます。
[ml2] mechanism_drivers = openvswitch,linuxbridge,l2population
デプロイメントで Red Hat OpenStack Platform director を使用している場合には、これらの設定は director によって管理されるので、手動で変更すべきではありません。
Red Hat OpenStack Platform 11 では、Neutron の Linux Bridge ML2 ドライバーおよびエージェントは非推奨となり、Red Hat OpenStack Platform 12 では削除される予定です。OpenStack Platform director によってデフォルトでデプロイされるのは、Open vSwitch (OVS) のプラグインです。一般的な用途の場合には、Red Hat はこのプラグインを推奨しています。
2.6. L2 Population
L2 Population ドライバーはブロードキャスト、マルチキャスト、およびユニキャストのトラフィックを有効化して、大型のオーバーレイネットワークをスケールアウトします。デフォルトでは、Open vSwitch GRE および VXLAN がブロードキャストを各エージェントに複製します。これには、送信先のネットワークをホストしていないエージェントも含まれます。この設計には、多大なネットワークとプロセスのオーバーヘッドを受容する必要があります。L2 Population ドライバーにより導入される代替の設計は、ARP 解決および MAC 学習トラフィックのための部分的なメッシュを実装し、特定のネットワークをホストするノード間に、そのネットワーク用のトンネルも作成します。このトラフィックは、対象設定済みのユニキャストとしてカプセル化されることによって、必要なエージェントにのみ送信されます。
1. L2 population ドライバーを有効化するには、メカニズムドライバーのリストに追加します。また、少なくとも 1 つのトンネリングドライバーが有効化されている必要もあります (GRE と VXLAN のいずれか一方または両方)。ml2_conf.ini ファイルに適切な設定オプションを追加します。
[ml2] type_drivers = local,flat,vlan,gre,vxlan mechanism_drivers = openvswitch,linuxbridge,l2population
Red Hat OpenStack Platform 11 では、Neutron の Linux Bridge ML2 ドライバーおよびエージェントは非推奨となり、Red Hat OpenStack Platform 12 では削除される予定です。OpenStack Platform director によってデフォルトでデプロイされるのは、Open vSwitch (OVS) のプラグインです。一般的な用途の場合には、Red Hat はこのプラグインを推奨しています。
2. openvswitch_agent.ini ファイルで L2 Population を有効化します。これは、L2 エージェントを実行する各ノードで有効化する必要があります。
[agent] l2_population = True
ARP 応答フローをインストールするには、arp_responder
フラグを設定する必要があります。以下に例を示します。
[agent] l2_population = True arp_responder = True
2.7. OpenStack Networking サービス
Red Hat OpenStack Platform にはデフォルトで、ML2 および Open vSwitch のプラグインと統合してデプロイメントのネットワーク機能を提供するコンポーネントが含まれています。
2.7.1. L3 エージェント
L3 エージェントは openstack-neutron パッケージに含まれています。ネットワーク名前空間は、各プロジェクトに独自の分離されたレイヤー 3 ルーターを提供するのに使用されます。レイヤー 3 ルーターは、トラフィックを誘導し、レイヤー 2 ネットワーク向けのゲートウェイサービスを提供します。L3 エージェントはこれらのルーターの管理を支援します。L3 エージェントをホストするノードでは、外部ネットワークに接続されたネットワークインターフェースに手動で IP アドレスを設定することはできません。代わりに、OpenStack Networking で利用可能な外部ネットワークの IP アドレスの範囲内で指定する必要があります。これらの IP アドレスは、内部ネットワークと外部ネットワークの間を接続するルーターに割り当てられます。選択した範囲は、デプロイメント内の各ルーターに一意の IP アドレスと、必要な各 Floating IP を指定するのに十分な大きさである必要があります。
2.7.2. DHCP エージェント
OpenStack Networking DHCP エージェントは、各プロジェクトのサブネットが DHCP サーバーとして機能するために作成されるネットワークの名前空間を管理します。各名前空間は、ネットワーク上で実行される仮想マシンへの IP アドレス確保が可能な dnsmasq プロセスを実行します。サブネットの作成時にこのエージェントが有効化されて稼働している場合には、そのサブネットにはデフォルトで DHCP が有効化されます。
2.7.3. Open vSwitch エージェント
Open vSwitch (OVS) neutron プラグインは、独自のエージェントを使用します。このエージェントは、各ノードで稼働し、OVS ブリッジを管理します。ML2 プラグインは専用のエージェントと統合して L2 ネットワークを管理します。デフォルトでは、Red Hat OpenStack Platform は ovs-agent
を使用します。このエージェントは、OVS ブリッジを使用してオーバーレイネットワークを構築します。
2.8. テナントとプロバイダーネットワーク
以下の図には、テナントとプロバイダーネットワークの種別の概要と、それらが OpenStack Networking トポロジー全体でどのように対話するかを図解しています。
2.8.1. テナントネットワーク
テナントネットワークは、プロジェクト内の接続性のためにユーザーが作成します。これらは、デフォルトで完全に分離され、他のプロジェクトとは共有されません。OpenStack Networking はさまざまな種別のテナントネットワークをサポートしています。
- フラット: 全インスタンスが同じネットワークに存在し、そのネットワークは、ホストと共有することも可能です。VLAN タグ付けやその他のネットワーク分離は行われません。
- VLAN: OpenStack Networking では、物理ネットワークにある VLAN に対応する VLAN ID (802.1Q タグ付け)を使用してユーザーが複数のプロバイダーネットワークまたはテナントネットワークを作成することができます。これにより、インスタンスは環境全体で相互に通信を行うことが可能になります。また、専用のサーバー、ファイアウォール、ロードバランサー、および同じレイヤー 2 上にあるその他のネットワークインフラストラクチャーと通信することもできます。
- VXLAN および GRE のトンネル: VXLAN および GRE は、ネットワークオーバーレイを使用して、インスタンス間のプライベートの通信をサポートします。OpenStack Networking ルーターは、トラフィックが GRE または VXLAN テナントネットワークの外部に通過できるようにするために必要です。また、ルーターは、直接接続されたテナントネットワークを外部ネットワーク (インターネットを含む) に接続するのにも必要とされ、Floating IP アドレスを使用して外部ネットワークから直接インスタンスに接続する機能を提供します。
テナントネットワークの QoS ポリシーを設定することが可能です。詳しくは、「10章Quality-of-Service (QoS) の設定」を参照してください。
2.8.2. プロバイダーネットワーク
プロバイダーネットワークは OpenStack の管理者によって作成され、データセンター内の既存の物理ネットワークに直接マップします。このカテゴリーの中で有用なネットワークタイプには、フラット (タグなし) と VLAN (802.1Q タグ付き) があります。ネットワーク作成プロセスの一環としてプロバイダーネットワークがテナント間で共有されるように許可することができます。
2.8.2.1. フラットプロバイダーネットワーク
フラットプロバイダーネットワークを使用してインスタンスを直接外部ネットワークに接続することができます。これは、複数の物理ネットワーク (例: physnet1 および physnet2)、さらにそれぞれ別の物理インターフェース (eth0 → physnet1 および eth1 → physnet2) があり、各コンピュートおよびネットワークノードをこれらの外部ネットワークに接続する予定にしている場合に便利です。単一のインターフェース上に VLAN タグ付けされたインターフェースを複数使用する場合には、「VLAN プロバイダーネットワークの使用」の項を参照してください。
2.8.2.2. コントローラーノードの設定
1. /etc/neutron/plugin.ini (/etc/neutron/plugins/ml2/ml2_conf.ini へのシンボリックリンク) を編集して、既存の値リストに flat
を追加し、flat_networks
を *
に設定します。以下に例を示します。
type_drivers = vxlan,flat flat_networks =*
2. フラットネットワークとして外部ネットワークを作成して、設定済みの physical_network に関連付けます。このネットワークを共有ネットワークとして設定すると (--shared
を使用)、他のユーザーはそのネットワークに直接接続されたインスタンスを作成することができます。
neutron net-create public01 --provider:network_type flat --provider:physical_network physnet1 --router:external=True --shared
3. neutron subnet-create
またはダッシュボードを使用してサブネットを作成します。以下に例を示します。
# 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
2.8.2.3. ネットワークノードとコンピュートノードの設定
ネットワークノードとコンピュートノードで以下の手順を実行すると、ノードは外部ネットワークに接続され、インスタンスが外部ネットワークと直接通信できるようになります。
1. 外部ネットワークのブリッジ (br-ex) を作成して、関連付けたポート(eth1) を追加します。
/etc/sysconfig/network-scripts/ifcfg-br-ex に外部ネットワークのブリッジを作成します。
DEVICE=br-ex TYPE=OVSBridge DEVICETYPE=ovs ONBOOT=yes NM_CONTROLLED=no BOOTPROTO=none
/etc/sysconfig/network-scripts/ifcfg-eth1 で eth1
が br-ex
に接続するように設定します。
DEVICE=eth1 TYPE=OVSPort DEVICETYPE=ovs OVS_BRIDGE=br-ex ONBOOT=yes NM_CONTROLLED=no BOOTPROTO=none
ノードを再起動するか、ネットワークサービスを再起動して、変更を適用します。
2. /etc/neutron/plugins/ml2/openvswitch_agent.ini で物理ネットワークを設定して、ブリッジをその物理ネットワークにマッピングします。
bridge_mappings = physnet1:br-ex
ブリッジマッピングについての詳しい情報は、「11章ブリッジマッピングの設定」を参照してください。
3. ネットワークノードとコンピュートノードの両方で neutron-openvswitch-agent サービスを再起動して、変更を適用します。
systemctl restart neutron-openvswitch-agent
2.8.2.4. ネットワークノードの設定
1. /etc/neutron/l3_agent.ini で external_network_bridge =
に空の値を設定します。
以前のバージョンでは、OpenStack Networking は、外部のネットワークとの接続に単一のブリッジのみを使用する場合に external_network_bridge
を使用していました。今回のリリースでは、この値に空白の文字列を設定することができるようになり、複数の外部ネットワークブリッジを使用できます。この設定により、OpenStack Networking は br-int
に接続する各ブリッジからパッチを作成します。
# 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
複数のプロバイダーネットワークが存在する場合には、ネットワークごとに異なる物理インターフェースとブリッジを使用して外部ネットワークに接続すべきです。ifcfg-* スクリプトを適切に設定し、bridge_mappings
オプションでコンマ区切りリストでネットワーク別のマッピングを指定する必要があります。詳しくは、「11章ブリッジマッピングの設定」を参照してください。
2.9. レイヤー 2 およびレイヤー 3 ネットワーク
仮想ネットワークを設計する場合には、トラフィックの大半がどこに発生するかを予測する必要があります。ネットワークトラフィックは、異なるネットワーク間よりも同じ論理ネットワーク内のほうが早く移動します。これは、(異なるサブネットを使用した) 論理ネットワーク間のトラフィックではルーターを経由する必要があり、追加でレイテンシーが発生するためです。
以下の図で、別の VLAN 上にあるインスタンス間を流れるネットワークトラフィックを見てみましょう。
パフォーマンスが高いハードウェアルーターでも、この設定にレイテンシーが加えられます。
2.9.1. 可能な範囲でのスイッチの使用
スイッチは、ネットワークの下層 (レイヤー 2) で行われるため、レイヤー 3 で行われるルーティングよりもはるかに早く機能することが可能です。頻繁に通信のあるシステム間では、ホップ数をできる限り少なくすることを推奨します。たとえば、この図ではスイッチ付きのネットワークで 2 つの物理ノードをつなげ、ナビゲーションにルーターを使用せずに 2 つのインスタンスが直接通信できるようにしている点が描写されています。これらのインスタンスで同じサブネットが共有されており、同じ論理ネットワークに存在することが分かります。
別のノードにあるインスタンスが同じ論理ネットワークにあるかのように通信できるようにするためには、VXLAN または GRE などのカプセル化されたトンネルを使用する必要があります。トンネルヘッダーに必要な追加のビットに対応するためにエンドツーエンドでの MTU サイズの調節を検討することを推奨します。そうしなかった場合には、断片化が原因でネットワークのパフォーマンスが悪影響を受ける可能性があります。詳しい情報は、「MTU の設定」を参照してください。
VXLAN オフロード機能を搭載したサポート対象のハードウェアを使用すると、VXLAN トンネリングのパフォーマンスをさらに向上させることができます。完全な一覧は https://access.redhat.com/articles/1390483 の記事を参照してください。