ホントにネットワークは仮想化されるのか！？①

ビジネス推進本部 第1応用技術部
コアネットワークチーム
平河内 竜樹

サーバ仮想化の活用が進むに相まって、ネットワーク機器で提供されていた機能をサーバに収容する構成にも高い関心が寄せられています。ニーズに合わせて各社から仮想マシン上で稼働する仮想アプライアンスがリリースされており、ルータ分野ではBrocade Communications Systems社のBrocade vRouter（旧称：Vyatta vRouter）やCisco Systems社のCSR 1000Vなどが該当の製品として挙げられます。本稿では検証結果などを通じて仮想ルータ製品の現状を探っていきます。

ルータ機能の仮想化に纏わる分野と今回のターゲット

ルータの仮想化と聞けば、以前から存在するVRFの様なルータのインスタンス分割機能を思い浮かべる方も多いのではないでしょうか？ またレイヤ3の機能をサーバ上に持たせることによって、サブネットの内外を問わず、仮想マシン間通信の最短ホップ保証を一機能とするSDN製品も導入が進む時期になったとして引き続き注目度の高い分野となっています。本稿ではそういった「ルータ製品のインスタンス分割機能」や「コントローラからの指令に基づいて実行されるレイヤ3転送モジュール」ではなく、仮想アプライアンスという言葉から連想される様な『ルータのOSをx86マシン上で稼働させる形態』を取り上げたいと思います（図１）。

補足といたしまして、サーバ上で実行されるルータOSの稼働環境は対象によって異なっています。これは対応するハイパーバイザの種類やバージョンが異なるというだけでなく、ベアメタル環境をサポートする製品もあれば、ソフトウェアとしてコンテナ上の稼働を想定しているものもあります（図2）。本稿では便宜的に区別を付けず仮想ルータと呼びますが、必ずしも仮想化環境で利用されるとは限らず、「ソフトウェア実装」のネットワーク機能がどのように配置されるかによって複数のパターンが存在する格好です。各形態には得手不得手があり、例えば性能を最大化したい場合はより仮想化オーバーヘッドの少ない構成が向いていますし、仮想化による柔軟性を必要とする場合はハイパーバイザを介する構成が選ばれることになります。

インストールやメンテナンスにおける仮想ルータの特徴

仮想ルータ製品のインストール手順は稼働環境によって異なりますが、いずれのパターンにおいても、コンソールアクセスまで辿り着けば以降はその製品のUIで操作することが可能になります。専用機器として製品を提供しているメーカーがその仮想化版をリリースするケースでは、ベースとなるソフトウェアは共有されることが大半で、操作性も同様です。これは、オペレーションにおけるノウハウの踏襲が容易とも言えます。以下はCisco System社が提供するCSR1000Vと、OSバージョンを共有するASR1006の管理アクセスを比較したものです（図3）。

Telnet/SSH経由のCLIアクセスやSNMPなど、従来のネットワーク管理手法をそのまま流用できることが伺えます。なお、昨今のデータセンター向け製品は仮想化環境に向いた管理方法も提供されていることが多く、CSR1000Vでは必要な情報を起動前にセットすることによってCLIを介さずに利用を開始することも可能です。管理方法の一つであるREST APIに関してはこちらの記事でも紹介しております。

一方、仮想ルータを利用するまでのインストールに関しては、サーバやハイパーバイザのナレッジが多少なりとも要求されます。また、リソース利用状況のモニタや問題発生時の原因究明などの際には、ハイパーバイザのレイヤで情報を拾う必要性に迫られることも度々あり、ネットワークを中心に業務を行っていたエンジニアが仮想ルータを扱う際にはより広範な技術習得が要求されるという側面があります。これは、同様の機能を有する専用機器と比較して管理点や確認対象が増加するだけでなく、トラブルシューティングの難易度にも影響を及ぼします。

性能面の特徴

例えば、UNIX系OSを用いてx86マシンをルータ用途に使用することは、旧来から可能であり、個人ユースだけでなくIXのルートサーバなどでも活用されてきました。一方パケット転送処理に対しては専用のハードウェアが開発・利用されてきた経緯があり、お客様と会話する中でもx86マシン上で稼働させて期待する転送性能が得られるのか？という点を気にされる方は多くいらっしゃいました。
それでは仮想マシン上にルータOSをインストールして使用する形態を想定した場合、どの程度のPPS(packet per second)が得られるのでしょうか？ ルータは経路計算に向いた機器ですが、何かしらのネットワークサービスを挿入するために配置することも多く、この場合、単純なIPv4転送の性能データをそのまま当てはめることはできません。今回は少し古いデータになりますが、Cisco Systems社のCSR 1000Vを対象に、転送負荷の傾向を示すいくつかの数字とIPsecを有効にした際の転送性能測定結果を紹介したいと思います。

図4はCSR1000および同社のルータ製品であるASR1001に対し、共通のOSバージョンを用いて、IPsecを有効にした際のノンドロップレートを測定した結果です。CSR1000Vの値は1コアのみ利用時のものですが、それでも差は10倍以上にもなることが伺えます。

図5は何もサービス処理を加えない状態で各パケット長に対し一定のPPSを印加した際のCPU使用率を測定した結果となります。単純なIPv4転送の処理負荷はパケット長の影響はほとんど受けず、綺麗な線形ではないものの相関関係にあることが伺えます。また図6は、ルータの性能測定ではポピュラーなRFC2544のテストアプリケーションを利用し、ノンドロップレートを測定した結果です。性能限界を迎えた際のCPU使用率は概ね高騰しており、パケット損失はCPU負荷の高まりに伴って発生していると言い換えられます。つまり、専用機器と同じく、（仮想マシンに割り当てられた）CPUリソースの枯渇が仮想ルータの転送処理における典型的なボトルネックであると言えます。

また、性能測定試験全体の傾向として、印加するトラフィックの条件によってはCPUに相応の余力が残されているにも関わらずパケットの損失が観測される・ノンドロップレートの測定を複数回行った際に各回で結果に目立った差が見受けられるなどの現象も確認され、専用機器と比較して高負荷状態の転送は若干不安定である印象を受けました。全てのソフトウェア実装がこの通りであるとは限りませんが、このような傾向が確認された場合、高負荷時における若干のパケット損失は許容される環境でない限り負荷に余裕の持った配置を行うことが望ましいと言えます。関連して今後実装の最適化によって解決される課題かもしれませんが、「リソースは必ずしもビジーではないもののパケット損失が発生する」リスクは専用機器と比較して相対的に高まると考えられます。僅かな欠損が稀に発生する程度であれば実質的に問題にならない環境も多いかもしれませんが、欠損にセンシティブな通信も存在するため、ネットワークにおける仮想化移行の難易度は、その上で稼働するアプリケーションや保証すべき品質にも依存することになります。

加えて補足いたしますと、仮想ルータは専用機器と比較して転送性能に影響するメトリックが数多くあります。まず、割り当てられるCPUの処理能力によって性能はガラッと変わるということが挙げられます。図7は異なるCPUが搭載されたサーバに対しそれぞれ同一の仮想ハードウェア条件でCPU使用率を測定した結果です。処理能力の異なるサーバ上で同一のCPU使用率を示すPPSに着目すると、実に5倍もの開きが発生していることが伺えます。
また、ソフトウェアの影響も大きく、ルータのOSバージョンを変更すると性能が若干前後するという現象は専用機器においても往々にして確認されますが、仮想化環境ではその言葉で片付けられないほどの差が生じる試験結果が確認されています。現状は概ね上昇傾向にあることから最適化が進められているという見方もできますし、専用機器と比較して転送性能がソフトウェア品質の影響を受けやすいと言うこともできるかもしれません。

CPUベースで転送処理を行う機器では、処理内容に応じてCPU負荷が異なってくるためパターンを考慮した性能測定が必要になっていましたが、それでも専用機器であればいくつかの前提を定めてしまえば汎用的に利用できるデータを採取することは十分に可能でした。ところが、仮想ルータを配置する環境では性能に関係する要素が多く存在する上に影響を受ける度合いも無視できるほど小さくないため、想定する環境でどの程度の転送性能を得られるかは「やってみるしかない」のが現状です。転送処理の実行主体はCPUであることから遠い将来にはCPU性能を測定するベンチマーキングの結果を基におおよそのスループットを導出できる様になる可能性はあるかもしれませんが、前述の経緯より現在は環境に合わせた測定が都度必要であり、そのデータを再利用する際は前提条件に基づいた参考値として扱うべきです。

また、仮想化環境でルータOSが複数個配置されサーバ全体で処理すべきPPSが増大した場合などでは、物理インタフェースから仮想マシンまで・もしくは仮想マシン間のパケット交換を制御する、ハイパーバイザのレイヤで発生する処理がボトルネックとなってパケット損失が発生する様な現象も確認されています（図8）。先般ルータOSのバージョンによって転送性能が変動することをお伝えしましたが、仮想化環境ではハイパーバイザの種類やバージョンなども性能に影響する要素となります。仮に仮想マシンが利用できるCPUリソースに余力が残されていたとしても、ハイパーバイザによって行われるデータの交換処理が妨げられる可能性があるとすれば、その条件下でロスレスのパケット転送を継続することは難しくなります。

尚、関連分野の技術動向として、これらのボトルネックを押し上げるべく、ハードウェアリソースをより効率良く利用するための取り組みが盛んに行われています。その内容はモノによって様々で、SR-IOVの様なネットワークI/O最適化技術を適用しているものもあれば、Intel DPDKを用いて従来は各所のカーネルが担っていたパケット処理を専用に一から再定義することによって抜本的な性能改善を図るアプローチもあります。特に後者では高性能をアピールする試験結果が注目される一方、ハイパーバイザとの連携や利用環境に沿った高性能仮想スイッチの実装、サービス処理における多様性との両立等においてまだ解が定まっていない状況であり、継続して発展が期待される分野です。少なくとも「既存環境に合わせてこの製品を導入すれば高性能な仮想ルータ環境に無理なく移行できる」状況には至っていないと言えます。

価格面について

ネットワーク機能のソフトウェア化や仮想化環境移行を期待する背景として、導入コストの削減があると考えられます。これは、ネットワーク機器が専用のハードウェアで提供されてきた経緯から、「ハードウェアに一般的なサーバを使えば安くなりそう」というイメージが湧くからかもしれません。
しかしながら、実際に価格を積み上げて計算してみると、ライセンス費用がネックとなって思いの外コスト削減に繋がらない・むしろ高くついてしまうケースが確認されます。勿論、価格は製品や用途によって異なるため一概には言えませんし、もしネットワーク機能を無償で入手可能なソフトウェアに移行するのであればこの部分に対する費用は発生しません。利用するサーバリソースが既に用意されているケースなどではハードウェアの調達も不要となります。ただ、これまでのサービスレベルや導入・運用ノウハウを維持しようとした場合、必要とされるパーツを揃えるとなかなかコスト削減が実現できないことも事実です。
また導入コストに直接勘定されないケースもあるかもしれませんが、取り扱いにはネットワーク分野とサーバ分野双方のナレッジが要求されるため、もしギャップを埋める必要がある場合その習得にも時間や費用を要します。また、想定する環境で必要とする性能や品質を確保できるか確認するためには、今は慎重な検証が不可欠です。
これらの経緯より、結果としてコスト削減が実現できるケースは比較的限定されてしまうことが、現在における価格面の傾向として挙げられます。

まとめ

主に専用機器からの単純な移行という視点で整理を行うと、仮想ルータ製品には、現状として以下の特徴が挙げられます。

• 【操作感】製品のUIにアクセスできれば以降は専用機器と同様に操作することができます。
• 【システムとしての複雑さ】取り扱いにはサーバやハイパーバイザのナレッジも必要となります。また、状態把握やトラブルシューティングの労力にも影響します。
• 【性能および品質】特に仮想化環境では、専用機器と同等の転送性能を確保することが難しく、また多くの要素に左右されます。リソース枯渇前にパケットの損失が発生する可能性も相対的に上昇する傾向にあります。
• 【導入費用】コスト削減が実現できないケースも多くあります。
  次回はこのような特性を踏まえた上で、利活用のポイントについて掘り下げていきたいと思います。

関連記事

• Cisco’s Cloud Services Router (CSR 1000V): Extending the Enterprise Network to the Cloud (2015 San Diego) 【要ユーザ登録】
• DPDK Summit – 08 Sept 2014 – VMware and Intel – Using DPDK In A Virtual World
• DPDK Summit – 08 Sept 2014 – 6WIND – High Perf Networking Leveraging the DPDK and the Growing Community

執筆者プロフィール

平河内 竜樹
ネットワンシステムズ株式会社 ビジネス推進本部 第1応用技術部 コアネットワークチーム
所属
エンタープライズ・パブリック・サービスプロバイダのネットワーク提案・導入を支援する業務に、10年以上にわたり従事

• CCIE RS
• CCIE SP