前回の記事では OpenStack における OVN プラグインのリファレンスアーキテクチャについて解説しました。本記事では、OpenStack Neutron で OVN と OVS を使用する場合の主な違いを比較します。
アーキテクチャ面
公式FAQから翻訳したこの表を見ると、OVN と OVS のアーキテクチャ面の違いが明確にわかります。
| 項目 | ml2/ovs | ml2/ネットワーキング-ovn |
|---|---|---|
| agent/server 間の通信 | RabbitMQ メッセージ + RPC | NorthBound データベースと SouthBound データベース間の OVSDB プロトコル |
| L3HA API | デプロイ時にルーターの ha フィールドを設定することで、L3HA の有効化または無効化が可能 | 複数のネットワークノードが存在する場合、HA 機能を自動的に有効化 |
| DVR API | 管理者（admin）のみが変更可能なルーターの distributed 設定 | distributed 設定は存在せず、デフォルトで distributed となる |
| DVR データプレーン | コンピュートノード上の名前空間（namespaces）、veth、IP ルーティング、IP ルール、および iptables を使用 | コンピュートノードの OpenFlow ルールを使用 |
| E/W トラフィック | DVR が無効な状態では、ネットワークノードを経由する | あらゆる状況で分散型となり、コンピュートノード間で直接転送される |
| メタデータサービス | メタデータサービスは、ネットワークノード上の qrouter または DHCP ネームスペースを介して提供されます。 | メタデータは、各コンピュートノード上の ovnmeta-xxxxx-xxxx-namespace によって提供されます。 |
| DHCP サービス | dnsmasq の qdhcp-xxxxx-xxx ネームスペースを介して提供されます。 | DHCP は ovn-controller および OpenFlow によって提供され、各コンピュートノードに分散されています。 |
| トランクポート | トランクポートは、br-trunk-xxx ブリッジおよびパッチポートを作成することで提供されます。 | トランクポートは br-int 内で OpenFlow ルールを介して作成され、接続されるポートは直接 br-int に接続されます。 |
OVN は設計段階で HA 機能が十分に考慮されており、アーキテクチャ全体に組み込まれていることがわかります。そのため、デプロイ時に別途高可用性構成を検討する必要はありません。
パフォーマンス
以下の OpenStack Summit Boston でのセッションから、OVS と比較した OVN のパフォーマンスを少し見てみましょう。
Nova VM の作成速度を見ると、OVN は OVS と比較して 70% 以上の向上が見られます。
| ML2/OVS (秒) | OVN (秒) | 改善率 | |
|---|---|---|---|
| 平均 | 80.7 | 23.4 | 70.9% |
| 95% | 163.2 | 35.3 | 78.4% |
| 最大 | 211.9 | 48.7 | 78.4% |
| 最小 | 18.7 | 3.8 | 79.8% |
コントロールプレーンのパフォーマンス向上が非常に高いことがわかります。こちらのこちらの記事には、より詳細なテスト結果があります。
データプレーンに関しても、関連するテストが行われていますが、それほど大きな差はありません。最大の利点は、分散アーキテクチャによってもたらされる高可用性にあります。
まとめ
本記事では、アーキテクチャ面と実際のパフォーマンス面から OVN と OVS の違いを比較しました。これにより、OVN の利点や、なぜ RedHat のような OpenStack の大手ベンダーが現在 OpenStack Neutron のプラグインとして OVN を推奨しているのかをご理解いただけたかと思います。これまでの Neutron に関する一連の紹介を通じて、OpenStack ネットワークへの理解が深まったことでしょう。次回は、OpenStack の中で目立たないながらも非常に重要なコアコンポーネントである Glance を紹介する予定です。
著作権表示：特に断りのない限り、本ブログのすべての記事はCC BY-NC-SA 4.0ライセンスの下で提供されています。
