第13章 分散仮想ルーター (DVR) の設定

13.1. 分散仮想ルーター (DVR) について

Red Hat OpenStack Platform をデプロイする場合、集中ルーティングモデルまたは DVR のどちらかを選択することができます。

それぞれのモデルには短所と長所があります。本項を使用して、集中ルーティングと DVR のどちらがよりニーズに適しているかを慎重に検討してください。

新たなデフォルトの RHOSP デプロイメントでは、DVR および Modular Layer 2 プラグインと Open Virtual Network メカニズムドライバーの組み合わせ (ML2/OVN) が使用されます。

ML2/OVS のデプロイメントでは、DVR はデフォルトで無効になっています。

13.1.1. レイヤー 3 ルーティングの概要

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

13.1.2. フローのルーティング

Red Hat OpenStack Platform (RHOSP) のルーティングサービスは主に、3 つのフローに分類できます。

  • East-West ルーティング: 同じプロジェクト内の異なるネットワーク間のトラフィックのルーティング。このトラフィックは OpenStack デプロイメント外には出ません。この定義は、IPv4 と IPv6 のサブネット両方に適用されます。
  • Floating IP を使用した North-South ルーティング: Floating IP のアドレス指定は 1 対 1 の NAT で、変更およびインスタンス間の移動が可能です。Floating IP は、Floating IP と neutron ポートの間での 1 対 1 の関連付けとしてモデル化されていますが、Floating IP は NAT の変換を実行する neutron ルーターとの関連付けで実装されています。Floating IP 自体は、ルーターに外部接続を提供するアップリンクネットワークから取得されます。したがって、インスタンスと (インターネット上のエンドポイントなど) 外部のリソースとの間の通信が可能です。Floating IP は IPv4 の概念で、IPv6 には適用されません。プロジェクトが使用する IPv6 のアドレス指定は、プロジェクト全体で重複のないグローバルユニキャストアドレス (GUA) を使用することが前提であるため、NAT なしにルーティングが可能です。
  • Floating IP なしの North-South ルーティング (別名: SNAT): Networking サービスは、Floating IP が割り当てられていないインスタンスに、デフォルトのポートアドレス変換 (PAT) サービスを提供します。このサービスを使用すると、インスタンスはルーター経由で外部のエンドポイントと通信ができますが、外部のエンドポイントからはインスタンスへは通信ができません。たとえば、インスタンスはインターネット上の Web サイトにアクセスすることができますが、外部の Web ブラウザーはこのインスタンス内でホストされている Web サイトにアクセスすることができません。SNAT は、IPv4 トラフィックにのみ適用されます。さらに、GUA 接頭辞が割り当てられた Networking サービスのネットワークでは、外部にアクセスするために Networking サービスルーターの外部ゲートウェイポート上に NAT は必要ありません。

13.1.3. 集中ルーティング

Networking サービス (neutron) は当初、集中ルーティングモデルで設計されました。このモデルでは、neutron L3 エージェントで管理されるプロジェクトの仮想ルーターはすべて専用のノードまたはデプロイ、導入ノードのクラスター (ネットワークノードまたはコントローラーノード) にデプロイされます。したがって、ルーティングの機能が必要となる度に (East/West、Floating IP または SNAT)、トラフィックはトポロジー内の専用のノードを経由します。そのため、複数の課題が発生し、トラフィックフローは最適な状態ではありませんでした。以下に例を示します。

  • コントローラーノード経由で伝送されるインスタンス間のトラフィック: L3 を使用して 2 つのインスタンス間で通信する必要がある場合に、トラフィックはコントローラーノードを経由する必要があります。同じコンピュートノードでインスタンスがそれぞれスケジューリングされている場合でも、トラフィックはコンピュートノードを離れてからコントローラーを通過して、コンピュートノードに戻ってくる必要があります。このことが、パフォーマンスに悪影響を与えます。
  • コントローラーノード経由でパケットを送受信するインスタンス (Floating IP を使用): 外部ネットワークのゲートウェイインターフェイスはコントローラーノードでのみ利用できるので、トラフィックはインスタンスから開始される場合でも、外部ネットワークにあるインスタンスを宛先とする場合でも、トラフィックはコントローラーノードを経由する必要があります。その結果、大規模な環境では、コントローラーノードにかかるトラフィックの負荷が高くなります。そのため、パフォーマンスやスケーラビリティーに影響を及ぼします。また、外部ネットワークのゲートウェイインターフェイスで十分な帯域幅を確保できるように慎重に計画する必要があります。SNAT トラフィックにも同じ要件が適用されます。

L3 エージェントのスケーリングを改善するには、Networking サービスで複数のノードに仮想ルーターを分散する L3 HA の機能を使用することができます。コントローラーノードが失われた場合には、HA ルーターは別のノードのスタンバイにフェイルオーバーして、HA ルーターのフェイルオーバーが完了するまではパケットが失われます。