論文紹介 ー "NetVM: High Performance and Flexible Networking Using Virtualization on Commodity Platforms"
本記事は、システム系論文紹介 Advent Calendar 2014 12/11 のための記事です
本エントリでは、NSDI'14 にて発表のあった "NetVM" について紹介します。
- タイトル: "NetVM: High Performance and Flexible Networking Using Virtualization on Commodity Platforms"
- 著者: Jinho Hwang et al.
- 出典: 11th USENIX Symposium on Networked Systems Design and Implementation (NSDI'14)
この論文では表題にも登場する"Commodity Platforms"いわゆる普通の(?) x86マシンを使った、高度かつ高速なネットワークサービスを実現するための基盤として、"NetVM" というプラットフォームを提案&実装しています。これまでお高い専用のハードウェアでなければ実用に足る性能が出せなかったファイヤーウォールやルーティング、ロードバランサといったネットワークに必要な諸機能。これらをソフトウェアだけで実現し、いわゆるNFV 的なものの基盤として使える様にするといったことを目的としています。特にこの論文では、ハードウェアアプライアンスに負けない性能(==ワイヤーレート)を目指しつつ、ソフトウェアとしての展開の容易さや機能実現に対する柔軟性といったネットワークサービスインフラにおける利便性を実現することを主眼としています。
ここではNetVMを支える技術、として論文中よりNetVMにおける「こだわり」ポイントをいくつか紹介します。
NetVMにおける一つの特徴として、仮想化環境によるネットワークサービスの実現を特に意識している点が上げられます。 いわゆるハコモノを用いる一般的なネットワークでは用途に応じて様々なハコを組み合わせてネットワークを構成します。 これにはたとえばスイッチやルータ、ファイヤーウォールなどといったコンポーネントに設定を投入し、間を LANケーブルで敷設するイメージでしょうか。 ブロードバンドルータなど一つのハコにまとめている場合もありますが、より大規模かつ高速な処理を要求される場合は 専用のアプライアンスを持ってくることが一般的でしょう。
NetVMでは、これらの物理的なハコとしての形を取っ払ってKVM上の仮想マシンを新たな仮想的なハコとしてそこに機能を押し込めています。 これによりソフトウェアの柔軟性(デプロイや変更の自動化、大規模化 etc)といった利点をネットワークの構成に導入しています。
それぞれのVMはハコモノとして、これまで行ってきたのと同じようにパケットの入力とそれに基づく出力の決定(宛先の変更やパケットの書き換えなど)を行います。 もちろん仮想マシンに押し込めたところで物理配線が消える訳ではないのでそれらは依然として存在しますが、このハコモノの間を埋めるLANケーブル (とスイッチング)の役割の一部をNetVMではハイパバイザでも提供します。NetVMではこのホストで動く部分をNetVM Core, NetVM Managerと呼称しています。 ネットワークコンポーネント間の結線にあたるこの部分もソフトウェアとして抱き込むことで、ハコモノを仮想化したのと同様の利点をネットワーキングにも導入しています。
一つのハコモノを一つのVMに押し込めて動かすことはセキュリティ面でも利点があります。 NFV的な、一つの物理ハードウェア上に複数のネットワーク、複数のお客さん環境が載っている場合は それぞれの間がまぜこぜにならないことが肝要です。 KVMが既にVMという区分で提供しているアイソレーションの仕組みに乗っかることでNetVMでは 各ネットワークコンポーネントのセキュリティを担保しています。
加えて必要なのは、それぞれのネットワーク間を間違って繋がないことです。 ここはホストOSつまりNetVM CoreやNetVM Managerの領分になりますが、このためにVMのグルーピングができるようになっています。 これにより、あるVM群は特定のユーザのもの、また別のVM群はそっちのユーザのものといった形で内部的に分離する事が可能です。
なおあくまで内部的な区分けにつき、外に出たフレームは対象とはなりません。このため実際にNFVっぽいことの基盤として使うにはその部分でVLANかますなりトンネリングするなりでネットワーク的に区分けすることが必要だったり？また、一つの物理的なハードウェア上での組み合わせを主眼にしているためか外に出ないといけないような場合の想定があまりなされていない感じもあります。
ハードウェアなアプライアンス箱に性能で勝つ、というのを第一目標においているためかチューニングやテクニックの記述に論文のそこそこの部分を割いているためその一部をここでは解説します。
いわゆる「ポーリングモード」+ 「ユーザランドにおけるパケット処理」+「バッチ処理」による高速化は、Intel DPDKのリリースやnetmap、あとちょっとマニアックなところだとrump(はどうなんだろう...?)などの登場によりもはや当たり前のテクニックとなってきました。特に"なんらかのアプリケーション"に特化した通信を行いたい場合は、これまで先人がせっせと築き上げてきたOSのレイヤやらコンテキストスイッチングによるオーバヘッドをぶち抜けるため非常に高速にパケットを処理することが可能です。
これらの仕組みはDPDKでもnetmapでも、基本的には直接ハードウェア(NIC)を触ってる人のみへの恩恵です。一方、NetVMではベースにDPDKを用いることでこれらの技術を利用しつつ、ネットワークサービスのコンポーネントたるVMの中のアプリケーションに対しても同様の利点を提供しています。
DPDKやnetmapは基本的に、NICとネットワークアプリケーションとで送受信リングとパケットバッファを共有することでコピーコストの削減を行っています。 NetVMでもDPDKを利用しているため、ホストOSとNICとの間でこれはすでになされていますがこの構造をさらに拡張し、VMにたいしても 同様の処理ができるように巨大な共有メモリ領域を用意し、ダミーのvirtual PCIデバイス経由でVMに対してこれを晒しています。 これによりNIC-ホストOS-VMの三者間でのZero Copyを実現しています。 このZero CopyはVM-VM間でも有効であり、ホストOS(NetVM Core)を通してのコンポーネント間のパケットのやりとりにあたっても 同様の恩恵を得ることができます。これは、ホスト-VM間のRx/Txリングがそれぞれ独立である一方で"同じネットワーク"間では パケットバッファが共有されているためです。なお先に述べたネットワーク間のアイソレーション機能(グルーピング)は このパケットバッファの共有範囲を分けることでも実現されています。
バッファ共有によるZero Copyの拡張に加えて、マルチコアシステムを前提として以下の工夫がなされています。
- Lockless なシステムデザイン
- NUMA-awareなデザイン
netmapでも同様だったかと思いますが(マルチコアの場合はどうだったっけ...)、共有のパケットバッファの操作にあたりNetVMではロックを用いません。 あるキュー(Rx/Tx)は同時にホスト内またはゲストから操作しないように構成されます(できないのではなくやらない)。 ある一つのキューに対してロックが必要なケースは以下の場合です。
- ホストOS側でそれぞれのコアが同じキューを触ることがある場合
- ゲストOSとホストOSが同じキューを触ることがある場合
これらを避けるために、NetVMではコア間で触るキューを分けるようになっています。 まずNetVMのホストOS側ではコアごとにNICおよびVMとのキューを分けるようになっています。 これにより1の、同じキューを別々のコア(上で動作するスレッド)が触ることがないようにしています。 次に、ゲストOS(VM)側のスレッドとホストOS側のスレッドが同じキューを操作するシチュエーション(2)ですが、 これも1と同様にあるゲストOS(VM)上のスレッドが動くCPUを限定することで対処しています。 このゲスト上のスレッドも、同様に自分のCPUに割り当てられたキューしか触れないようにすることで実質的に いわゆるキューを挟んだconsumer-producerにおいてRX側では「ホストOSのスレッドとしてキューにpush」と 「VM上のスレッドとしてキューからpop」が一つのCPUで完結することになります(これらは1つのCPU上では同時に実行されないためロックもいらない)。 このあたりの実装にはKVMのvCPU周りの管理機構をいじくって実現したとのこと。
NetVMではNUMAなマルチコアシステムにおけるメモリの距離とキャッシュの扱いについても考慮が入っています。 基本的なデザインとして、NetVMでは自分のコアに距離的に近いメモリ領域以外は触らないように構成されています (遠いメモリにアクセスするとキャッシュは汚れるは遠いわで良くないよというお話はここでは割愛)。 これは上記の「キューごとのコア」という構造をベースに作られます。 まずNetVMではそれぞれのコアごとに触るメモリ領域を分けます (総メモリ量/コア数 == 1つのコアが触るメモリ領域)。 そしてその各々のメモリ領域に「キューごとのコア」が作られ、ゲスト(VM)と共有されます。 先に述べたように、Locklessデザインの制約によりあるキューはそれぞれ対応するCPUからしかアクセスされないため、 あるCPU(とその上で動くホスト/ゲスト上のスレッド)は常に自分から近いメモリ領域のみを触る様になります。 これは全てのホスト-ゲスト間のみならず、ゲスト-ゲスト間でのパケットのやりとりでも有効であり、最終的に NICにパケットを引き渡すまでlocalityを維持したまま通信ができるようになります。
ここではNSDI'14より"NetVM"の紹介をしました。こういったNFV的なプラットフォームはネットワークベンダやキャリアなど各社それぞれ様々な構想を出しており、それらの一例として作り方まで踏み込んだものとして面白い論文ですが、なによりもチューニングに結構命かけているあたりがこのNetVMの面白いところです。
最後に、今回読もうと思ってた論文の候補たちを並べておきます。
- Unikernels: Library Operating Systems for the Cloud (ATC'13)
- HACK: Hierarchical ACKs for Efficient Wireless Medium Utilization (ATC'14)
- Hyper-Switch: A Scalable Software Virtual Switching Architecture (ATC'13)
- Rekindling Network Protocol Innovation with User-Level Stacks (SIGCOMM Computer Communication Review)
Unikernelsは@suma90h さんが既にシステム系論文輪読会でお読みになってた のでパス。HACKは、無線LAN系 & 今年のATCでのBest Paperということもあって気になっているのですが別枠で読むことに。3や4は、NetVMと同じく"えすでーえぬ"とか"えぬえふぶい"といった類いに属しそうなのと、先日のIIJ-II セミナーで"ClickOS and the Art of Network Function Virtualization"のお話があったので関連文献として上げてみました。
NetVM の記事, 大変興味深く拝読しました. 一つ質問というか, ご意見を伺いたいのですが, 自分は NetVM について, なぜ複数の VMs に分けてしまわなければいけないのか?, についてが少し弱い印象を受けたのですが, どう思われますでしょうか? というのも, 1 user あたり１つ VM を割り当てて, その中で multi process で NetVM の機能を用いるのではだめなのかな, と思ったためです.
利点は, section 2.3 の,
かなあと思っていますが VM を複数上げるほど強くは感じないかなあとごく個人的には感じました. が, 自分が勝手にそう感じただけな気もするので, 他の方はどう思われるのかぜひ聞いてみたいです.