> [!abstract] 概要(Abstract の日本語訳) > マルチテナントデータセンターは、非常に困難なネットワーキング環境である。テナントは、自社のエンタープライズネットワークからサービスプロバイダのデータセンターへ、変更を加えていないワークロードを移行し、かつ自宅のネットワークと同じネットワーク設定を維持したいと望む。サービスプロバイダは、オペレータの介入なしにこれらのニーズを満たしつつ、自らの運用上の柔軟性と効率性を保持しなければならない。従来のネットワーキング手法は、このテナントとプロバイダの要求を満たすことに失敗してきた。この要求に応えるため、我々はマルチテナントデータセンター向けのネットワーク仮想化ソリューションの設計と実装を提示する。 ## 論文情報 - タイトル: Network Virtualization in Multi-tenant Datacenters - 著者: Teemu Koponen, Keith Amidon, Peter Balland, Martín Casado, Anupam Chanda, Bryan Fulton, Igor Ganichev, Jesse Gross, Natasha Gude, Paul Ingram, Ethan Jackson, Andrew Lambeth, Romain Lenglet, Shih-Hao Li, Amar Padmanabhan, Justin Pettit, Ben Pfaff, Rajiv Ramanathan(以上 VMware, Inc.)、Scott Shenker(International Computer Science Institute および University of California, Berkeley)、Alan Shieh, Jeremy Stribling, Pankaj Thakkar, Dan Wendlandt, Alexander Yip, Ronghua Zhang(以上 VMware, Inc.) - 媒体: 11th USENIX Symposium on Networked Systems Design and Implementation(NSDI '14)、Operational Systems Track。2014年4月2日〜4日、Seattle, WA, USA。ISBN 978-1-931971-09-6 - 発表年: 2014 - コード URL: 記載なし(NVP は VMware/Nicira の商用プラットフォームであり公開実装は無い。データプレーンの一部である [[Open vSwitch (OVS)]] のみオープンソース) ## 概要 本論文は、[[VMware]](買収前は [[Nicira]])が数年にわたって本番環境に展開してきたネットワーク仮想化プラットフォーム NVP(Network Virtualization Platform)の設計と実装を報告する。NVP はネットワークハイパーバイザーとして、サービスプロバイダの物理転送インフラとテナントのコントロールプレーンの間に介在し、各ホストの [[Open vSwitch (OVS)|Open vSwitch]] にテナント固有の論理データパスを実装することで、既存の物理ネットワーク設定を一切変更せずにテナントごとの仮想ネットワークを提供する。宣言的言語 nlog による増分状態計算と、論理/物理の二層構造を持つコントローラクラスタによって、数千ホストパーバイザー・数万論理ポート規模のマルチテナントデータセンター(MTD)向けのスケーラビリティと可用性を実現している。 ## 問題設定 マルチテナントデータセンター(MTD)は、サーバ仮想化によって計算資源のプロビジョニングが分単位に短縮された一方、ネットワークプロビジョニングには依然として数か月を要するという非対称性を抱えている(顧客環境からのアナリストレポート [7, 29] でも共通して指摘される)。この非対称性の根本原因は、計算は仮想化されているのにネットワークは仮想化されていない点にある。VLAN・VRF・NAT・MPLS のような個別の仮想化プリミティブは存在するが、これらはボックス単位で設定され、グローバルに一括して呼び出せる統一的な抽象化を欠く。 さらにテナント側には2つの課題がある。(1) トポロジ: サービスディスカバリを使うフラット L2、大規模分析ワークロードの L3、多層構成の Web サービスなど、ワークロードごとに異なる物理トポロジと L4-L7 サービスが必要になり、単一の物理トポロジで組織内の全ワークロードの要求を満たすのが難しい。(2) アドレス空間: 仮想化されたワークロードは今日、物理ネットワークと同じアドレス空間で動作する(脚注: VMware VDS や Cisco Nexus 1000V を使っていてもこの制約は残る)ため、VM を任意の場所へ移動できない、テナント独自の IPAM を許可できない、アドレッシング方式(例: IPv4→IPv6)を変更できない、という3つの問題が生じる。 NVP の目標は、これら物理ネットワークと同様のトポロジ・アドレッシングの自由度を、同一の物理ネットワークの上に仮想的に重ねる(オーバーレイする)ことである。 ## 提案手法 ### アーキテクチャ: ネットワークハイパーバイザー NVP はネットワークハイパーバイザーとして、プロバイダの物理転送インフラとテナントのコントロールプレーンの間に介在するソフトウェア層である(Figure 1)。これは、コントロール抽象化(テナントが論理データパスを物理スイッチ・ルータと同様に設定できる)とパケット抽象化(テナントのエンドポイントが送受信するパケットが、テナントの本来のネットワークにいたときと同じスイッチング・ルーティング・フィルタリングを受ける)という2つの抽象化を提供する。 **Figure 1: ネットワークハイパーバイザーの位置づけ** ![[_attachments/nsdi14-paper-koponen/fig01-network-hypervisor.png]] (Figure 1. ネットワークハイパーバイザーはサービスプロバイダの物理転送インフラの上に位置し、テナントのコントロールプレーン(CP)には制御抽象化を、VM にはパケット抽象化を提供する。VM から送信されたパケットは L2→L3→L2 という論理パイプラインを通過してから物理インフラに転送される。) 各論理データパスは、現代のフォワーディング ASIC に似たパケットフォワーディングパイプラインインタフェースとして定義される。ルックアップテーブルの列(ステージ)からなり、各ステージでパケットヘッダやメタデータに対するマッチと、ヘッダの書き換え・ドロップ・メタデータの更新・次ステージへの再投入といったアクションを実行できる。ソフトウェア仮想スイッチ上に実装されているため、ASIC 実装と異なりテーブル数やマッチ対象フィールドに人為的な制約を課さずに済む。 ### 仮想化アーキテクチャ 論理データパスは各ホストのソフトウェア仮想スイッチにほぼ完全に実装され、ホスト間トンネルの集合を利用する(物理ネットワークからは通常の IP トラフィックにしか見えない)。論理データパスの処理は、送信元 VM が存在するホストの仮想スイッチでほぼすべて完結し、フォワーディング決定に達した後にトンネルを介して受信側ホストへ転送される(Figure 2)。 **Figure 2: 送信元ホストにおける論理フォワーディングの実装** ![[_attachments/nsdi14-paper-koponen/fig02-virtual-switch-forwarding.png]] (Figure 2. 送信元ホストの仮想スイッチが論理フォワーディングを実装する。パケットは論理データパスとそのテーブル群を通過した後、受信側ホストの仮想スイッチへトンネルされ、宛先 VM へ配送される。) 論理ブロードキャスト/マルチキャストのためには、サービスノード(パケット複製を担う x86 ベースの仮想スイッチホスト)を用いたマルチキャストオーバーレイを構築する。また、テナントが自らの論理ネットワークを既存の物理ネットワークと相互接続したい場合には、ゲートウェイアプライアンスを介する。ホスト・サービスノード・ゲートウェイを総称してトランスポートノードと呼ぶ(Figure 3)。 **Figure 3: NVP のトランスポートノード配置** ![[_attachments/nsdi14-paper-koponen/fig03-transport-nodes-arrangement.png]] (Figure 3. NVP のコントローラは全トランスポートノード(ホストパーバイザー・ゲートウェイ・サービスノード)のフォワーディング状態を管理する。トランスポートノードは IP トンネルによってフルメッシュで接続される。ゲートウェイは論理ネットワークと非仮想化ワークロードを接続し、サービスノードは論理マルチキャスト/ブロードキャストの複製を担う。) ### エッジにおける仮想化の実装 NVP は全トランスポートノードで [[Open vSwitch (OVS)|Open vSwitch(OVS)]] を用いてパケットを転送する。OVS は[[OpenFlow]]を用いたフローテーブルの検査・変更プロトコルと、[[Open vSwitch (OVS)|OVSDB]](オーバーレイトンネルの作成・管理、ホストにいる VM の発見)の2プロトコルでリモート制御される。 論理データパスは、通常のフローテーブルパイプラインと同じ制御プレーン抽象化を NVP 内部で提供しつつ、次の2点で拡張されている。(1) マッチ: 各論理フローエントリを OVS に書き込む前に、論理テーブル識別子に対するメタデータマッチを強制的に付加し、他の論理データパスからの分離とパイプライン上の正しい位置への配置を保証する。(2) アクション: 論理アクション列を書き換え、次の論理フローテーブルの識別子をパケットメタデータに書き込んで OVS フローテーブルへ再投入させる。これによりパイプラインが構成され、かつ制御プレーンが別の論理データパスへ直接フォワードするフローエントリを作れなくなる。 複数の論理データパスが L3 ルータで相互接続される場合、パケットは論理トポロジ全体を「Map」ステップを挟みながら順に通過する(Figure 4)。 **Figure 4: 複数論理データパスを跨ぐパケット処理** ![[_attachments/nsdi14-paper-koponen/fig04-logical-datapath-processing.png]] (Figure 4. 2つの論理スイッチが論理ルータで相互接続された構成を、パケットが通過する処理ステップ。物理フローはトンネルヘッダまたは送信元 VM の識別情報を最初の論理データパスへマップすることでロジカルトラバーサルの準備を行い、各論理データパスの後に論理フォワーディング決定を次の論理ホップへマップする。最後の論理決定はトンネルヘッダへマップされる。) 論理 L2 宛先はエッジにのみ存在するという最適化により、送信側ホストの OVS フローテーブルは自ホストの VM が接続する論理データパスと論理トポロジの L3 ルータのフローだけを持てばよく、最後の論理 L2 ホップは受信側ホストで実行される。 ### フォワーディング性能とハードウェアオフロード OVS はソフトウェアでパケットをフローテーブル全体に対して分類するが、カーネルモジュールとユーザ空間プログラムからなり、各フローの最初のパケットだけがユーザ空間でワイルドカードを含む全体マッチを受け、以降の同一フローのパケットはカーネル内の完全一致フロー(exact-match)で高速転送される。 NVP のカプセル化は、標準的な NIC のハードウェアオフロード機構(TSO/LRO/GSO)を無効化してしまう問題があった(NIC がカプセル化されたパケットの中身を見られないため)。これを解決するため、NVP は STT(Stateless Transport Tunneling)というカプセル化方式を採用する。STT は物理 IP ヘッダの後に標準的だが偽の TCP ヘッダを置き、その後にコンテキスト情報付きのカプセル化ヘッダと元の論理パケット(Ethernet ヘッダから)を続ける。NIC はこの偽 TCP ヘッダ以降を TCP ペイロードとみなすため、TSO を含む標準オフロード機構をそのまま利用できる。 ### 高速フェイルオーバー サービスノードの障害はロードバランシング(ECMP ライクなフローハッシュ)とトンネル監視(BFD)によって吸収され、コントローラクラスタを介さずにホストパーバイザーがバンドルから外す。ゲートウェイクラスタは、同一物理ネットワークをブリッジする複数ゲートウェイ間でループが生じないよう、CFM パケットのブロードキャストによる軽量なリーダー選出(非リーダーはトンネルを無効化)を行う。 ### フォワーディング状態計算: 宣言的言語 nlog コントローラの入出力は複雑であり、合計123種類の入力型から81種類の出力型を生成する。入力状態の総量は MTD の規模に比例し、VM のマイグレーションやテナントの参加・離脱・再設定に応じて頻繁に変化する。当初は手書きの状態機械でこれをインクリメンタルに計算していたが、扱うべきイベント型の数とその任意の入れ替わりのため実用的でなくなった。 そこで NVP はドメイン固有の宣言的言語 nlog を実装した。nlog の宣言は Datalog クエリであり、複数テーブルの JOIN によって head テーブルへ不変のタプルを生成する。JOIN 対象テーブルの変化があると、その JOIN が増分的に再評価され head テーブルへタプルが追加・削除される。nlog は再帰宣言・否定をサポートしない。NVP 全体では約1200 declaration・900テーブル(全種別合計)が使われている。 **Figure 5: nlog を用いたフォワーディング状態計算への入出力** ![[_attachments/nsdi14-paper-koponen/fig05-controller-inputs-outputs.png]] (Figure 5. コントローラへの入力は、ホストパーバイザー/ゲートウェイからの位置情報(1)、API を介したプロビジョニング設定(2)であり、出力は各トランスポートノードへ配布されるフォワーディング状態(3)である。) nlog の宣言の具体例として、トンネル確立のための3段階の Datalog 宣言が示される(送信元→宛先論理ポート間のトンネル決定、OVS DB へのトンネルエントリ作成、トンネルへパケットを出力する OpenFlow フローエントリの作成)。この計算モデルは完全にプロアクティブ(コントローラは必要なフォワーディング状態を事前にすべて計算・配布し、パケットを一切処理しない)であり、(1) スイッチへの継続的なパケットパンティングを避けて計算資源を効率的に使え、(2) コントローラへの接続が一時的に失われてもトランスポートノードのデータプレーンが動作し続けるという2つの理由から選ばれている。 上記のコード例は Datalog ベースの nlog 宣言であり、次のように読める(§4.3, Figure 6 相当): ``` # 1. 送信元ホストパーバイザーから、リモートの宛先論理ポートへのトンネルを決定 tunnel(dst_lport_id, src_hv_id, encap, dst_ip) :- log_port(src_lport_id, log_datapath_id), log_port(dst_lport_id, log_datapath_id), log_datapath_encap(log_datapath_id, encap), log_port_presence(src_lport_id, src_hv_id), log_port_presence(dst_lport_id, dst_hv_id), hypervisor_locator(dst_hv_id, dst_ip), not_equal(src_hv_id, dst_hv_id); # 2. OVS db 経由でトンネルを確立。割り当てられたポート番号は # 入力テーブル ovsdb_tport に入る(1列目は無視) ovsdb_tunnel(src_hv_id, encap, dst_ip) :- tunnel(_, src_hv_id, encap, dst_ip); # 3. トンネルへトラフィックを送るフローエントリを構築。 # このステージへ再投入する前に reg1 に論理ポートに対応する # 'stage id' がロードされる ovs_flow(src_hv_id, of_expr, of_actions) :- tunnel(dst_lport_id, src_hv_id, encap, dst_ip), lport_stage_id(dst_lport_id, processing_stage_id), flow_expr_match_reg1(processing_stage_id, of_expr), ovsdb_tport(src_hv_id, encap, dst_ip, port_no), flow_output_action(port_no, of_actions); ``` (Figure 6. トンネル確立の3ステップ: 1) トンネルの決定、2) OVS db エントリの作成、3) トンネルへパケットを出力する OF フローの作成。VM のマイグレーションで `log_port_presence` 入力テーブルが更新されると、2番目・3番目の宣言が再評価され、対応する OVS 設定データベースの変更と OpenFlow エントリの追加・削除が生じる。) nlog は言語拡張として、整数列の合計や OpenFlow マッチ式/アクションの構築のような列変換を行う「関数テーブル」、およびより複雑な変換を C++ で実装する仕組み(ヒステリシスの実装などに利用)を提供する。増分更新モデルは変更後の速い収束を可能にするが、データプレーンのタイムスケールでの障害対応には向かないため、NVP はトンネルのバックアップパスなどデータプレーン障害復旧に必要な状態をあらかじめ計算しておく。 ### コントローラクラスタ フォワーディング状態計算は容易に並列化でき、NVP はこれを疎結合な二層構造のコントローラクラスタに分割する(Figure 7)。上位層の論理コントローラは、論理データパスの識別子をシャーディングキーとして各論理データパスの計算を担当し、フローとトンネルを「universal flows」という OpenFlow に似た中間表現(トランスポート固有の詳細を抽象識別子に置き換えたもの)として計算し、RPC で下位層の物理コントローラへ配布する。物理コントローラはホストパーバイザー・ゲートウェイ・サービスノードとの通信を担い、universal flows をノード固有・位置固有の状態(IPアドレス、物理インタフェースのポート番号)へ変換して物理フローとして配布する。 **Figure 7: NVP コントローラの二層構造** ![[_attachments/nsdi14-paper-koponen/fig07-controller-two-layers.png]] (Figure 7. NVP のコントローラは論理コントローラ層と物理コントローラ層の二層構造を取る。API から入力された論理データパス設定は universal flows として物理コントローラ層へ伝わり、物理フロー(OpenFlow・OVS 設定)としてトランスポートノードへ配布される。位置情報と物理状態は逆方向にフィードバックされる。) この分離により、論理コントローラ層は単一の理想的なトランスポートノード(O(N) 本のトンネル)の「イメージ」を1つ計算すればよく、全トランスポートノード間のトンネルメッシュの O(N^2) の複雑さを考慮する必要がない。各物理コントローラがそのイメージを担当トランスポートノードごとに具体化する。 NVP は [[Onix]] コントローラプラットフォーム上に構築されており、Onix が提供する分散サービス(レプリケーテッドトランザクショナルデータベースによる設定状態の永続化)に加えて、[[Onix|Zookeeper]] を用いたシャーディングコーディネータによるリーダー選出(マスタ/スタンバイの割り当てと障害時の昇格)と、ラベル割り当てサービス(トンネルの論理宛先ポートを一意に識別するラベルの、コントローラ障害をまたいだグローバルな一意性保証)という2つの分散サービスを追加実装している。 ### サービスプロバイダ向け API NVP は HTTP ベースの REST API を公開し、トランスポートノードなどの物理ネットワーク要素、論理スイッチ・ポート・ルータなどの論理ネットワーク要素をオブジェクトとして表現する。クラウド管理システムはこの API を通じてテナントワークロードをプロビジョニングでき、コマンドラインや GUI によるヒューマンフレンドリーなインタフェースへもマッピングできる。単一の API リクエストが複数トランスポートノード・複数コントローラの情報を要求することもあり、NVP はオンデマンドまたはプロアクティブ(継続収集)のいずれかで応答する。 ## 新規性 既存のネットワーク仮想化プリミティブ(VLAN・VRF・NAT・MPLS)はボックス単位の設定にとどまり、グローバルな抽象化を欠いていた。関連研究の SDN([3, 4, 13, 14, 23, 27])は OpenFlow によるフォワーディングモデルとコントローラによる集中制御プレーンという形で NVP の基盤になっているが、NVP はこれに大幅な拡張を加えている。ネットワークフォワーディングプレーンの仮想化という概念自体は [6](Casado らの先行研究)が最初に述べたが、NVP はこれをさらに発展させ、エッジベースの実装の詳細な設計を提示する点で新規性を持つ。 FlowVisor [36] のようなスライシング機構は隔離を提供するが、テナントが本来のネットワークで得ていたパケット抽象化・制御抽象化までは提供しない。VM によるルータ仮想化 [38] は MTD に対してスケーラブルではない。 計算モデルの面では、宣言的言語による分散(ルーティング)アルゴリズムの記述という先行研究([24, 25]、Datalog ベース)が最も近いが、それらは分散アルゴリズムの簡潔で直感的なモデリングに焦点を当てるのに対し、NVP(nlog)は単一ノード内での計算構造化による効率的な増分計算に焦点を当てる。Frenetic [10, 11] や Pyretic [28] はリアクティブな関数型プログラミングによってパケットフォワーディング決定の実装を単純化することを主張するが、リアクティブなパケット処理に焦点を当てており、NVP のようなプロアクティブな計算は対象としていない。Pyretic は NVP([6]と同様)と同じく抽象トポロジの価値を認め、モジュラーな制御ロジックの合成に利用している点で類似する。 ## 実験設定 - 環境: テスト用コントロールクラスタは3ノード。各コントローラはベアメタル Intel Xeon 2.4GHz サーバ(12コア、96GBメモリ、400GB HDD)。物理ネットワークは専用のスイッチドネットワーク。 - シミュレーション規模: 3,000台の仮想化ホストパーバイザー(各21 vNIC、合計63,000論理ポート)、7,000の論理データパス(平均9ポート、2〜64ポートの幅、49,188論理ポートにポートACL・1,553論理スイッチにジェネリックACL設定)。各シミュレートホストパーバイザーは、各仮想インタフェースを TUN デバイスでシミュレートする OVS インスタンスを持つ Linux VM で、XenServer 5.6 物理ハイパーバイザー上で Xen ブリッジ経由で物理ネットワークに接続。 - テストシナリオ: (1) コールドスタート(全サーバクラッシュ・揮発性メモリ喪失からの復旧をシミュレート)、(2) リストア(コントロールクラスタのみクラッシュしデータプレーンは健全)、(3) フェイルオーバー(クラスタ内の単一コントローラ障害)、(4) ステディステート(既存63,000ポートに10論理ポートを追加・削除)。 - 評価指標: 論理エンドポイント間の ping 成功率(期待通りに成功/失敗するか)、nlog テーブルサイズ(フロー数)、nlog スレッドの稼働率(負荷)、コントローラのメモリ使用量。 - トランスポートノード性能の測定環境: Intel Xeon 2.0GHz サーバ2台(8コア、32GBメモリ、Intel 10Gb NIC、Ubuntu 12.04、KVM)、Netperf の TCP_STREAM テストでスループットを測定。 ## 実験結果 ### コントローラクラスタ(コールドスタート) コールドスタートテストでは、ping の正答率が17%からスタートし(フォワーディング未確立の状態で成功が期待される割合)、約1時間かけてフル接続性に到達する(Figure 8)。これはコントローラクラスタが全状態を計算しトランスポートノードへ送信し終えるまで接続性が確立しない、NVP にとって最悪ケースのシナリオである。この長いコールドスタート時間は破局的な障害時にのみ関係する一方、事前計算されたフローによってステディステートでのデータプレーン性能は大きく向上する(ホストパーバイザーの電源が入ったままなら、コントローラがコールドスタートを経ている間もデータプレーンは機能し続ける)。 単一コントローラは、コールドスタート中に約20分で約180万フローを計算し、全nlogテーブル合計で約3700万タプルが関与する(Figure 9)。1つの最終フローを生成するのに平均20個の中間タプルが必要であり、フロー計算に関わる要因の複雑さを示す。収束後の測定コントローラのメモリ使用量は約27GB(Figure 10)。テストクラスタは3コントローラ構成のため、180万フローはシステム全体のフローの2/3(1/3のシャードでマスタ、1/3でスタンバイ)に相当する。nlog は平均で毎分約190万タプル、ピークで毎分最大1000万タプルを生成する。 **Figure 8: コールドスタート時の接続性正答率** ![[_attachments/nsdi14-paper-koponen/fig08-coldstart-connectivity.png]] (Figure 8. コールドスタートテストにおける、全ペア中で正しく接続できたものの割合の時間推移。開始時点は期待される失敗が17%あるため17%からスタートし、約2000秒でほぼ100%に達する。) **Figure 9: コールドスタート中の物理フロー数とnlogタプル数** ![[_attachments/nsdi14-paper-koponen/fig09-flows-tuples-coldstart.png]] (Figure 9. 1コントローラにおける、コールドスタート後の物理フロー総数(実線・左軸)とnlogタプル総数(破線・右軸)の推移。両者とも約1300秒で頭打ちになる。) **Figure 10: コールドスタート後のコントローラのメモリ使用量** ![[_attachments/nsdi14-paper-koponen/fig10-memory-coldstart.png]] (Figure 10. コールドスタート後にコントローラが使用するメモリ量の推移。約1300秒で約27GBに収束する。) **Figure 11: コールドスタート中のnlog負荷** ![[_attachments/nsdi14-paper-koponen/fig11-nlog-load-coldstart.png]] (Figure 11. コールドスタートテスト中のnlogスレッドの稼働率(busy率)。約20分間ほぼ100%稼働し続けており、この間はnlogの計算能力がボトルネックであることを示す。約1300秒付近の落ち込みは、データベース読み込み・スイッチ接続の完了によるものと考えられる。) コールドスタート中の接続性正答率が線形でない理由は2つある。第1に NVP は論理データパスを1つずつでなく全データパスについて並行して計算するため(nlog の任意の評価順序に起因する実装上の特性)。第2に、1回の ping が成功するには経路上の全トランスポートノードで正しいフローが設定されている必要があるため(ARP request/response を含む)。 リストア・フェイルオーバーのテストでは接続性正答率のグラフは省略されているが、両テストを通じて接続性正答率は100%を維持したと報告されている。コントローラの追加・削除時も同様に接続性は良好に維持される。 ステディステートテストでは、既存63,000論理ポートに10論理ポートを追加すると、数秒間0.5%未満の負荷上昇にとどまり、削除でも同様の負荷だった。これは実際のデプロイメントの典型的な状態(緩やかな速度で構成が変化し続ける)を表す。 ### トランスポートノード **トンネル性能**: 非トンネル・STT・GRE の3方式で2台のホストパーバイザーを接続した場合のスループットと CPU オーバーヘッドを比較した(Table 1)。 **Table 1: 非トンネル・STT・GRE のトンネル性能比較** ![[_attachments/nsdi14-paper-koponen/table1-tunnel-encap-performance.png]] | | No encap | STT | GRE | |---|---|---|---| | TX CPU load | 49% | 49% | 85% | | RX CPU load | 72% | 119% | 183% | | Throughput | 9.3Gbps | 9.3Gbps | 2.4Gbps | (Table 1. 非トンネル・STT・GRE それぞれのTX/RX CPU負荷とスループット。GRE はハードウェアオフロードを利用できないためスループットが低くCPU負荷も高い。STT はTSOを利用できるため非トンネル時とほぼ同等のスループットを達成する。) GRE はハードウェアオフロードを利用できないため、スループットが著しく低く(2.4Gbps)、CPU負荷も高い(TX 85%、RX 183%)。STT はNICのTSOエンジンを利用できるため、非トンネル時(9.3Gbps)とほぼ同等のスループット(9.3Gbps)を達成する。STT は受信側でより多くのCPUを消費するが(RX 119%)、これはLROによるセグメントの結合が、ワイヤ上の2つのデータグラム間に十分な時間があるとNICがOSへ結果を渡してしまう(過剰な追加レイテンシを避けるため)一方、STTはフレーム全体のセグメントが揃わないとカプセル化ヘッダを除去できず、その際にはソフトウェアで残りの結合処理を行う必要があるためである。 **トンネルスケール**: サービスノード・ゲートウェイのようにトンネル数が多いノードにおけるキープアライブメッセージ処理コストを測定した(Figure 12)。500ms間隔でハートビートを送信するテストで、単一CPUコアが最大5000トンネルまでタイムリーに応答できる。 **Figure 12: トンネル数増加に伴うキープアライブ処理コスト** ![[_attachments/nsdi14-paper-koponen/fig12-tunnel-mgmt-cpu-load.png]] (Figure 12. トンネル数の増加に対する、キープアライブメッセージ処理の単一コアCPU負荷(%)。5000トンネルまで単一コアで処理しきれることを示す。) ## 考察 論文8章「Discussion」は、NVP の成功の要因と得られた教訓を振り返る。 ### 成功の要因 - **馴染みのある抽象化を基礎にしたこと**: 論理ネットワークを現在のネットワーク構成とまったく同じに見せるという設計判断が、既存のネットワークポリシーを無改修で使えるという形で NVP と MTD 双方の採用を大きく促進した。 - **宣言的な状態計算**: 手書き状態機械からnlogへ移行したことで、イベント順序に依存しない正しさを確保しつつ開発時間を大幅に短縮した。 - **ソフトウェアスイッチングの柔軟性の活用**: ASIC 開発が IETF 標準化競争に伍するほど遅い伝統的なネットワーキングに対し、OVS は標準化の駆け引きなしに、ソフトウェアアップグレードという低い導入障壁で急速に普及した。ソフトウェアスイッチであるため、パケットマッチやアクションの人為的な制約を気にせず新機能を追加できた。 ### 学んだ教訓 - **成長**: ネットワーク仮想化により新環境の立ち上げが数分で完了するようになり、デプロイメントは数百から数千のホストパーバイザーへ急成長する傾向を見せた。論理ネットワークも単一の論理スイッチから、ACL付きの複数論理ルータで相互接続された数百VM規模へと複雑化していく。 - **スケーラビリティ**: OpenFlow の採用は物理コントローラ層でのスケーリングの大きな複雑要因となった。論理コントローラの計算量が O(N) なのに対し、OpenFlow が要求するホストパーバイザーごとのフローの個別化により物理層は O(N^2) の操作が必要になる。また、デプロイメントの成長とともにメモリ限界に近づき、コントローラフェイルオーバーなどの一時的な状態の丁寧な調整が必要になった。製品ライフサイクルの初期には顧客がハイパーバイザーへの計算オフロードに消極的だったが、CPU・メモリ資源が年々向上したことで、後継バージョンでは物理コントローラをホストパーバイザー内へ移動させ、クラスタの要件を1桁削減し、OpenFlow をホストパーバイザー内のローカルプロトコルにすることでシステム全体への影響を限定できるようになった。 - **フェイルアイソレーション**: OpenFlow の非トランザクショナルな性質により、コントローラのクラッシュや接続断の際にスイッチが不整合・不完全なフォワーディング状態のまま動作する一時的な状況が生じうる。これへの対応として、次世代のNVPでは宣言的計算と通信チャネル全体をトランザクショナルにし、変更集合をバッチとしてまとめて計算・配布し原子的に適用する方向へ進化させた。 - **フォワーディング性能**: 完全一致(exact-match)のフローキャッシュは長寿命コネクションが支配的なワークロードでは有効だが、短命コネクションが支配的な環境ではCPU負荷が許容できないほど増大した。この対策として OVS は完全一致キャッシュを megaflows(より大きなトラフィック集約に対してワイルドカードマッチするキャッシュ)に置き換えた。将来的にはさらに完全一致キャッシュを再導入し、完全一致キャッシュ・megaflows・低速パス(完全なフロー分類の系列)の3層構造にする計画である。 ## 強み / 弱点・課題 **強み**: - 数百の本番環境・数万の仮想ネットワーク/VMという実運用規模での長期展開実績に基づく設計と教訓の報告であり、学術的な提案にとどまらない実務的知見を含む。 - 宣言的言語 nlog による増分計算という、複雑な状態計算のイベント順序非依存な正しさと開発効率を両立させる具体的な仕組みを提示している。 - コントローラクラスタの二層シャーディング構造により、論理計算のO(N)特性を保ちながら物理層のノードごとの詳細化を分離するという、スケーラビリティに関する具体的な設計判断を示している。 **弱点・限界(論文が自ら述べる課題)**: - OpenFlow採用がもたらす物理コントローラ層のO(N^2)スケーリング要求は、論文自身が「大きな複雑要因になった」と認める限界である。 - OpenFlowの非トランザクショナルな性質に起因する一時的な状態不整合は、次世代でのトランザクショナル化が必要になるほどの課題として残った。 - コールドスタート時の復旧に約1時間を要する点は、破局的障害時のみとはいえ長い時間である。 - STTのようなカプセル化はミドルボックスを混乱させうる懸念があり(本文脚注)、コンプライアンスが効率より優先される環境向けに別のIPカプセル化もサポートする必要が生じている。