VMがOpen vSwitchのパケット滞留時間に与える影響の評価

全文

(1)Vol.2018-DPS-174 No.12 Vol.2018-CSEC-80 No.12 2018/3/5. 情報処理学会研究報告 IPSJ SIG Technical Report. VM が Open vSwitch のパケット滞留時間に与える影響の評価吉川かなえ1,a). 金子晋丈2,b). 概要：近年，データセンタは仮想化技術を用いて物理マシン上に多くの仮想マシン (VM) を同居させることにより，物理的故障や電源供給面でのコスト削減を目指している．しかし，同一物理マシン上で複数の. VM と仮想スイッチが動作する場合，計算資源の共有により互いのプロセスが影響を及ぼし合う可能性がある．そこで，VM が仮想スイッチに与える影響をパケット滞留時間から評価した．パケット滞留時間の計測では，GPS 信号から生成した 1PPS, 1MHz の信号を用いて 100 ナノ秒精度のタイムスタンプを打刻した．計測の結果，CPU が高負荷状態においてパケット滞留時間に大きな変動は無いが，VM 起動時にパケット滞留時間が約 2 倍に増加すること，VM がスタンバイ状態では VM の台数によらずパケット滞留時間にばらつきが生じることが明らかとなった．キーワード：仮想マシン，Open vSwitch, パケット滞留時間. Performance evaluation of the time delay on Open vSwitch for a server with high load state Kanae Yoshikawa1,a). 1. はじめに. Kunitake Kaneko2,b). られる単位時間あたりの計算資源量が減少し１つのパケット処理にかかる時間が実時間として長くなることが予想さ. 近年, 多くの企業が自社の IT 基盤をオンプレミスから. れる．仮想スイッチにおいてパケット処理時間が長くなる. クラウドへ移行している．一方，クラウドを実現するデー. と，通信遅延時間の増大やばらつきが大きくなり低遅延や. タセンタは効率的な運用をめざし，仮想化技術の導入を進. 安定したネットワーク性能を求めるアプリケーションに影. めてきた．仮想化技術には，同一の物理マシンに複数の仮. 響を与える. 仮想スイッチの性能を明らかにする研究には. 想マシンを動作させる計算資源の仮想化とネットワーク機. パケットペイロード長と処理遅延時間の関係を明らかにす. 器をソフトウェア化する仮想化がある．一般にこれらの仮. る研究 [2] があるが，VM 動作環境における性能をサブマ. 想化技術は同一の物理マシン上に同居して動作するため，. イクロ秒の精度で検証しているものはない.. 互いの処理性能に影響を与えることになる．特に仮想マシ. 本稿では，同一物理マシン上で動作する VM が仮想スイッ. ンが仮想スイッチに与える影響に着目すると，例えば，仮. チに与える影響を VM の状態ごとに評価した．具体的に. 想マシン群の負荷が高い場合には仮想スイッチに割り当て. は，VM の状態として起動時，スタンバイ，終了時，高負. 1. 荷時を取り上げ，それぞれについてパケット滞留時間を測. 2. a) b). 慶應義塾大学理工学研究科 Graduate School of Science and Technology, Keio University, Yokohama, Kanagawa 223-8522, Japan 慶應義塾大学理工学部 Faculty of Science and Technology, Keio University, Yokohama, Kanagawa 223-8522, Japan [email protected] [email protected]. ⓒ 2018 Information Processing Society of Japan. 定した．以下，2 章は関連研究を述べ，3 章で計測手法，4 章で計測結果を述べる．. 1.

(2) 情報処理学会研究報告. Vol.2018-DPS-174 No.12 Vol.2018-CSEC-80 No.12 2018/3/5. IPSJ SIG Technical Report. 5/#.

(3) . 2. 関連研究. .//#0(.1234 . 2.1 ペイロード長に着目した OpenFlow スイッチの性能評価. 間のみを計測するため, 予め書き込んだフローテーブルに該. 当するルールで異なるペイロードの 200 万パケットをトラフィックジェネレータから送信. ペイロードはショートパ. ケット (64 byte) から Ethernet 最大フレームサイズ (1514. byte) までの値で変化させる．計測には 2 種類のハード. ウェア実装スイッチと 1 種類のソフトウェア実装スイッチ. !"#&. . !"#. $%&'()$*&+(,(-.. !"#' !"#$ . コントローラでの処理を除いたスイッチにおける処理時. ()*+,-./#012#. !"#%. ()*+,-./#012#. .157*)'(8 9:( #;/<(. $%&'()$*&+(,(-6. . 図 1. 計測環境. Fig. 1 Measurement environment. （Open vSwitch）を用いてパケット通過時間を計測. ハー. ドウェア実装のスイッチでは，どちらもペイロード長が長. くなるにつれて右肩上がりでスイッチ通過時間が増大し，ペイロード長最大時のパケット通過時間はおよそ 16.5 マ. イクロ秒となった．ソフトウェア実装のスイッチの場合，ペイロード長が約 200 byte までの間はスイッチ通過時間が減少したが, その後ペイロード長が約 1100 byte まではス. イッチ通過時間が横ばいとなり，それ以降では，ペイロー. ド長の増加に伴い通過時間が増加した．該当ルールが同じ. 異なるペイロード長でパケット通過時間を比較した場合，ハードウェア実装とソフトウェア実装ではおよそ 2 オーダーの差が生じることが明らかとなった．[2]. 2.2 DPDK を用いたソフトウェアスイッチのボトルネック対策. ソフトウェアスイッチのパフォーマンスは, カーネル空. 間でのキャッシュヒットやユーザ空間でのフローテーブルのルックアップなど様々な要素が関係する [9]．仮想スイッ. チの性能低下を防ぐ方法としてホスト OS のカーネルが行. うネットワーク制御をユーザー空間に移す DPDK がある.. Open vSwitch はバージョン 2.2 以降 DPDK データパス. への対応が可能となり DPDK データパスを使用すること. で低遅延かつ高性能なデータパスが実現された．しかし，特定の CPU コアを DPDK データプレーン処理に占有す. る必要があるため，同一物理マシン上に多くの VM を同居させコスト削減を目指す場合のデメリットとなり得る．[8]. 3. 計測手法本計測の基本的な考え方は以下の 2 点である．VM の処. 理時間を除く仮想スイッチでのパケット滞留時間を計測するために，VM を通過せず仮想スイッチのみを通過するパ. ケットを測定する．また，計測によるパケット滞留時間の影響を防ぐため，VM と仮想マシンが動作する物理マシン外で計測を行う. 図 1 に計測環境の構成図を示す.. 送信マシンは，計測対象マシンと計測器へ光ファイバス. プリッタで信号を分岐し送信．計測対象マシンは，スイッ. ⓒ 2018 Information Processing Society of Japan. チで処理された信号を受信マシンと計測器へ光ファイバスプリッタで分岐し送信．送信マシンから計測対象マシンへの信号を時刻：T1 , 計測対象マシンから受信マシンへの信. 号を時刻：T2 とすると，パケット滞留時間 t は，計測器の NIC 間の時刻差分であるから計測器で取得した 2 つの. タイムスタンプより t = T2 - T1 と表すことができる. 1PPS,10MHz 信号発生器はクロックとして OCXO を搭. 載し，GPS 信号を受信して 1PPS(pulse per sec) と 10MHz. の信号を発生する．NM10G は外部入力された 1PPS と. 10MHz の信号を基準クロックとして用い，NTP から時刻情報を入手することで 100 ナノ秒精度のタイムスタンプ. を実現する．NM10G のトランシーバには 10GBaseLR の. SFP+を用いた．トランシーバに接続するシングルモード. 光ファイバはそれぞれ送信マシンと計測対象マシン，及び. 計測対象マシンと受信マシンの間の光ファイバを光ファイバスプリッタを用いて分岐している．. トラフィックの送信には，送信マシンで動作するトラ. フィックジェネレータを自作した．トラフィックジェネレータが生成するフローは宛先 MAC アドレス，宛先 IP. アドレスを受信マシンの MAC IP アドレスとし送信元は. 架空の値を設定した．また，IP ペイロードは 100byte で. あり送信間隔は 1 秒とした．. 計測対象マシンで動作する Open vSwitch[3] は， Open. vSwitch 2.5.2(カーネルモジュール有り, Open Flow 1.3 を指定), DB Schema 7.12.1 である．Open vSwitch と同一の計測対象マシンで動作する VM は VirtualBox[6] と仮. 想化環境管理構築ツールである Vagrant[7] を併用した.. VirtualBox のバージョンは 5.0.40 r 115130, Vagrant の. バージョンは 1.8.1 である．送信マシン，受信マシン，計測. 対象マシンのスペックはいずれも，CPU;Intel(R) Xeon(R). CPU E5-2643 v2 @ 3.50GHz, メモリ; 32,910,260 kB,OS; Ubuntu 16.04.3LTS (Linux Kernel 4.4.0-97-generic) であ. り，CPU は (E5-2643 v2)*2, 各 6 コア，2 スレッド/コアの計 24 スレッドである．. 2.

(4) 情報処理学会研究報告. Vol.2018-DPS-174 No.12 Vol.2018-CSEC-80 No.12 2018/3/5. 1300. IPSJ SIG Technical Report. ! ! !!. !! !! !. !! ! !. !. !. !. !. !. !!! !! ! ! !! ! !. !. !! !! ! !!! ! !! ! !!!!! ! !!!! !!! !!! ! !!!! !!! !!!!!! ! !! ! !! !!!! ! !! !! !! !!! !!!!! !!!! ! ! !!! !!! !!!! !! ! !! !! !! !!!!! !!! ! !! !! !! !! !!! !! ! ! ! !! !! ! ! ! !! !!!! !!! !! ! !!!!! !!!!!!!! !! !!!!!!! ! !! !! !! ! !!!! !! !!! ! ! !!! ! !! !!!!! !!! ! !! !!!! !! ! ! !! ! ! ! ! !!! ! !! !! !! !!!!! !!!!! !!!! !!!!!!!!!! !!!!! ! ! !!! !! !!!!!! !! !!!! ! !! !!!!! !!! !! !!!!! !!!!!! !!! !!! !!!!!! !!! !! ! !! !!!!! !! ! !!!!! !!!! ! !! ! !! !! !! ! ! ! !! !!!!!!!! ! !! !!! !!! !!!! !!!! ! !!!!!!!! !!!! ! !!! ! !!!!!!!!!!!! ! !. 0. 900. 50000. ! !! !. !. !!!! !!. !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!. !!! !!!!! !! !. !. 200000. !!!. Delay [ns]. !!!!! ! !!! !!!!!!!! ! !!!!!!! !! !!!!!! !! !!! !! !!!! ! ! !!!. 100000. 1100 1000. Delay [ns]. 1200. 300000. !. 0. 100. 200. 300. 400. 500. 600. 700. 0. 100. 200. 300. 400. 500. 600. 700. Sec. Sec. 図 2 OpenFlow 対応ハードウェアスイッチ (IBM G8264). 図 3. Fig. 2 Hardware switch (IBM G8264). Open vSwitch. Fig. 3 Open vSwitch. 4.2 VM の立ち上げプロセス. VM を順に起動し，openssl speed[5]（OpenSSL が対応. 4. パケット滞留時間の評価本章では各計測内容の詳細と計測結果について述べる．. 計測内容は VM の状態に基づき，1）Open vSwitch の基本性能評価，2）VM 立ち上げプロセス，3）全ての CPU コ. アが使用率 100%の場合，4）VM 終了プロセス，5）Open. vSwitch と同一物理マシン上で複数の VM がスタンバイ状態の場合の 5 つに分類した．. するアルゴリズムの処理速度を計測するベンチマーク）を用いて VM 1 つにつき CPU のスレッド 1 つが使用率. 100%になるよう負荷をかけ，CPU 負荷が上昇する状況に. おける VM 起動プロセスのパケット滞留時間を計測した．既に 15 台の VM が起動し 15 スレッドが使用率 100%に. なっている状態から，16 台目から 24 台目の VM を順に起. 動した結果を図 4, 表 1 に示す．図 4 の青い丸が起動時，. 図 4 黄色い三角が openssl speed 開始時を指す．結果より，. VM 起動時に大きくパケット滞留時間が増加することがわ. 4.1 Open vSwitch の基本性能評価. かる．図 4 中央の 21 台目の起動から 22 台目の起動前の. したソフトウェアスイッチの１つであるため，基本性能. (ns) であるのに対し，最小パケット滞留時間が 12,200 (ns)，. Open vSwitch は OpenFlow プロトコル [1],[11] に対応. 評価として OpenFlow に対応したハードウェアスイッ. チを用いてパケット滞留時間を比較した．使用したハードウェアスイッチは IBM Networking Operating System. みの結果に着目すると，パケット滞留時間の平均が 20,782 最大パケット滞留時間が 40,200 (ns) であった．. また， CPU 負荷の上昇に伴うパケット滞留時間の増加. はないことが明らかとなった．図 4 の緑の丸で示すパケッ. RackSwitch G8264,[4] (以降,IBM G8264) Software Ver-. トは，CPU 最大使用率（全スレッドが 100%) だが，時間. version 1.3 に設定した．このとき，Open vSwitch が動作. の結果より， Open vSwitch のパフォーマンスに及ぼす影. sion 7.11.11,Boot kernel version 7.11.11 であり，OpenFlow する物理マシン上で VM は起動しておらず，マシンに負. 経過に伴うパケット滞留時間の増加も見られなかった．こ響は CPU 以外の物理資源がボトルネックとなっているこ. 荷がかかるプロセスは実行されていない.. とがわかる．. Open vSwitch で 7 通りのフローを各 100 パケットずつ. 読み出す disk I/O からのメモリアクセスの影響を調べる. OpenFlow 対応のハードウェアスイッチ（IBM G8264）. そこで，VM 立ち上げプロセスにおける OS イメージを. 送信した結果を図 2，図 3 に示す. IBM G8264 では平. ため，パケット滞留時間と disk I/O を同時計測した結果を. のに対し，Open vSwitch では 7 種類の各フロー初回パ. 連動してパケット滞留時間の増加が明らかとなった．. 均パケット滞留時間は 1,103 (ns), 分散は 1650 であった. ケットを除く平均パケット滞留時間は 45,631 (ns), 分散は. 図 5 に示す．図 5 より，disk I/O のアクセス数の増加と. 403,582,060 であった．ソフトウェアスイッチよりもハー. 4.3 全ての CPU コアが使用率 100% の場合. 短く，分散値はハードウェアスイッチの方が非常に小さく. CPU コアの使用率が 100%である場合と，VM がスレッド. ドウェアスイッチの方がパケット滞留時間がおよそ 40 倍. 処理時間が安定していることがわかる． ⓒ 2018 Information Processing Society of Japan. VM と Open vSwitch が動作するホスト OS 側で全ての. 数と同等数起動し，VM 上で全スレッドの使用率が 100%. 3.

(5) 情報処理学会研究報告. Vol.2018-DPS-174 No.12 Vol.2018-CSEC-80 No.12 2018/3/5. IPSJ SIG Technical Report. 25000. 立ち上げプロセスにおけるパケット滞留時間. 19,460 (ns). 136,389,994. 17 台目-18 台目起動前. 21,269 (ns). 214,808,475. 18 台目-19 台目起動前. 18,367 (ns). 118,818,228. 19 台目-20 台目起動前. 20,809 (ns). 192,778,349. 20 台目-21 台目起動前. 22,079 (ns). 448,967,043. 21 台目-22 台目起動前. 20,782 (ns). 136,534,982. 22 台目-23 台目起動前. 22,565 (ns). 325,550,538. 23 台目-24 台目起動前. 19,952 (ns). 97,115,465. 24 台目-計測終了. 19,925 (ns). 186,658,652. 15000. 16 台目-17 台目起動前. Delay [ns]. 293,990,014. ! ! ! ! ! ! ! ! ! !! ! ! ! ! !! ! ! !! !! ! ! ! !!! ! !! ! ! ! ! !!! ! ! ! ! ! ! ! ! ! !!! ! !!! ! !! !! !! !!! ! !!!! !!! !! !!! ! ! ! ! ! !!! ! ! ! ! ! ! ! ! ! ! ! !!! ! !! ! ! !!! ! !! ! ! ! ! ! ! ! ! ! ! ! ! ! !! !!! ! ! ! ! ! ! ! !! ! ! !! ! !! ! ! ! ! ! ! !!! ! ! ! !!! ! ! ! !! !! !!! !! ! ! ! ! ! ! ! !! !! !!! !! !!! ! ! ! ! !! ! ! !! ! ! ! ! ! !!!! ! !!!! ! ! ! ! !!! ! ! ! !!! ! !! ! !!! !!!. 5000. 分散. 21,455 (ns). !"#$%&'%()**+. 0. 平均全体. ,-./012**+3%4(). 20000. Table 1 The time delay in VM startup state.. 10000. 表 1. 0. 20. 40. 60. 80. 100. 120. Sec. 図 6 CPU 使用率 100% 150000. ! !. 100000. ! ! !. ! !. ! !!. 表 2 VM 終了時パケット滞留時間. !. !. !. !"#$%&&' &()*(. !. 50000. Delay [ns]. Fig. 6 CPU usage 100%. !. !. !. !. ! ! !. !. Table 2 Time delay in shutdown VMs.. !. !. 分散. 50,844 (ns). 120,488,024. VM 2. 52,886 (ns). 259,287,822. VM 3. 38,995(ns). 268,191,475. VM 4. 39,600(ns). 253,826,451. 0. ! ! ! ! ! !! ! ! ! ! !! ! !! !! !! !!!! ! !!! !! ! !!! ! !!! ! !! !!! !! !! !! !! ! ! !! ! ! ! ! ! ! ! !!!!! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !!! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !!!! !!! ! ! !! ! ! !! ! ! !! !! ! !! ! !! !! !! ! ! ! ! ! ! ! ! ! !!! ! !! !! ! ! !! ! ! !! ! ! !! !! ! !!! ! ! ! ! ! ! ! !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !!!! ! ! ! ! ! ! ! ! !! !!! ! !! ! ! ! ! ! ! ! ! ! !! ! ! ! ! ! ! ! ! ! ! ! ! !! ! ! !! ! ! ! ! ! ! ! !!! ! ! ! ! ! !!! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !! ! ! !! !! !!! ! ! !! ! !!!! ! ! !!!! ! !!! ! !! ! ! ! ! ! ! ! ! !! !!! !! ! ! ! !! !! ! ! ! !. 平均. VM 1. 0. 100. 200. 300. 400. 500. 600. 700. 100%にした場合の結果を図 6 に示す．パケット滞留時間. 16 台目から 24 台目の VM を起動し負荷をかけた場合. した場合（図 6, 青）で 12,147 (ns)，24 台の VM で CPU の. Sec. 図 4. 平均は，ホスト OS 上で全 24 スレッドを使用率 100% に. 全スレッドを使用率 100%にした場合（図 6, 赤）で 14,694. Fig. 4 Add VMs the to the maximum CPU usage. (ns) であった．平均時間で比較すると，VM 上で負荷をか. けた場合の方がおよそ 2.5 μ s パケット滞留時間が長い．. Sec 200. 300. 400. 2500. ! !. !. !. ! !. 2000. !. !. 120000. 1500. !. !. !. ! !. ! !. ! ! !. !. !. !. 1000. !. !. !. ! !. !. !. 500. !. &#!$ %&. 0. !. 0. "#!$ %&. 100. "$$ 200. 300. &$$ 400. 500. ($$. Sec1*3. 図 5. パケット滞留時間と disk I/O アクセス数. 荷が小さいため，VM 上で負荷をかけた場合よりもパケッ. Delay [ns]. 80000. (#!$ %&. ! ! ! ! ! ! ! ! ! ! !! ! !! !!!!! !! ! ! !! !!!!!!!!!!!! ! !!! !!!!!! ! ! !! ! ! !! ! ! !! ! ! ! !! !! ! ! ! ! ! !! !! ! ! !! ! ! ! !! !!! ! ! ! ! ! ! ! !! !!! !! !! ! !!!!!!! ! ! !!! ! !! ! ! ! ! !! ! !! !! !! ! !!! ! !! ! !!! ! !! !! !! !! ! ! ! ! !!! ! ! !!!!! ! ! ! !! ! ! !!! ! ! ! !!! ! ! !! ! ! ! ! ! ! ! ! !!!!! !!! ! ! ! ! ! ! ! ! ! ! ! ! !! ! ! ! ! !!!!!! !! ! ! ! ! !! !! ! ! ! ! ! ! ! ! ! ! ! !!! ! !!! ! ! !! ! !! ! !! !!!!! !! !! ! ! !! !!!! !!! !! !! !!! !! ! ! ! !! ! ! ! ! ! !!!! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !! !! ! ! !!! ! ! ! !!! ! ! ! ! ! ! ! ! ! !!! !! ! !! ! !! !! !! !! ! !! ! ! ! ! ! !! ! ! !! !! ! ! ! ! !! !! !! !! ! !! !! ! !! ! ! !!! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !. てもホスト OS 側で負荷をかけたほうがメモリに対する負. !$ #!$ %&. '#!$ %&. ! !. ゲスト OS で 2 度発生するため同様の負荷のかけ方であっ. !"#!$%&. 60000. 4567*8.9:.;<=.>[email protected]*.?0A*8C,+ Delay [ns]. ! ! ! ! ! ! ! ! ! ! ! ! ! ! !! !!! !! !! ! ! !! ! ! ! !! ! ! ! ! ! !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !! ! ! ! ! ! ! ! ! ! ! !! ! !! ! ! ! ! ! ! ! ! ! ! ! ! ! !! ! ! ! ! ! ! ! ! !! ! ! ! ! ! ! ! ! ! !! ! ! ! ! ! ! ! ! !! !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !! ! ! ! ! ! ! ! ! ! ! ! !! !! !! !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !! ! ! ! ! ! ! ! ! !! ! ! !! !! ! ! !!!! ! ! ! ! ! ! ! ! ! ! ! !! ! ! ! ! ! ! ! ! ! ! !! ! ! ! !!!! ! ! ! ! !!! !! ! ! !! ! ! ! ! !! ! ! ! !! !! ! ! ! ! ! ! ! !! !! !! !! ! ! !! ! ! ! !!! !! ! !! !! !! !! ! ! ! ! ! ! ! ! ! ! ! !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !! ! ! ! ! ! ! !! ! !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !! ! !! ! ! ! !! ! ! ! ! ! ! ! !! ! ! ! ! ! !! ! ! ! ! ! ! ! ! ! !! ! ! !! ! ! ! ! ! ! ! ! ! ! !! ! !. !. !. )*+,-./012. 500 3000. 100. ! !. !. !. 100000. 20000500 400001000 60000150080000 2000 100000 2500 120000 3000. 0. !. ! ! !. 40000. !. !. 20000. !. 0$. VM 上で負荷をかける場合，メモリコピーがホスト OS と. !. ト滞留時間が短くなったと考えられる．. 4.4 VM の終了プロセス. 複数台 VM を起動した状態で，スタンバイ状態から順. に 1 台ずつ VM をシャットダウンする場合のパケット滞. 留時間を計測した．スタンバイ状態では，VM 上で CPU. に負荷をかけるプロセスは実行されていないものとする．. VM 上で CPU 負荷がかかっておらずスタンバイ状態の. Fig. 5 Time delay and the number of disk I/O access. 4 台の VM を順にシャットダウンした場合の結果を図 7，. になるよう負荷をかけた場合のパケット滞留時間を比較. 目と 2 台目に対し，3 台目と 4 台目のほうがやや小さい．. した．. ホスト OS 上で CPU 全 24 スレッドを使用率 100% に. した場合と，24 台の VM で CPU の各スレッドを使用率 ⓒ 2018 Information Processing Society of Japan. 表 2 に示す．パケット滞留時間平均はシャットダウン 1 台. また， VM 起動時と比較するとパケット滞留時間は起動. 後の定常状態よりも大きいがシャットダウンの動作に連動するパケット滞留時間の変動は見られなかった．. 4.

(6) 情報処理学会研究報告. Vol.2018-DPS-174 No.12 Vol.2018-CSEC-80 No.12 2018/3/5. 250000. !"#$%&'( !"#$%&'( !"#$%&'( !. !. !"#$%&'(. 200000. !. 20. 40. 60. 80. 100. !. ! !! !. 50000. ! !. !. !. !. !. ! ! ! !. 120. 0. 図 8. VM 終了時. 40. 60. 100. 120. 577,110,929. 64,623 (ns). 814,575,955. 33,422 (ns). 426,666,796. 250000 200000. 1,677,518,731. 42,549 (ns). 52,440 (ns). 80. VM 5 台スタンバイ状態. 647,258,400. 150000. 59,272 (ns). Delay [ns]. VM 24 台（3 回目）. 分散. ! !. 100000. VM 24 台（2 回目）. 平均. ! ! ! ! ! ! !. 4.5 Open vSwitch と同一物理マシン上で複数の複数の VM が起動したスタンバイ状態において, VM. 0. 台数ごとにパケット滞留時間を比較する. スタンバイ状態. VM が 5 台の場合のパケット滞留時間の結果を図 8，15 台. 250000. の場合を図 9，VM が 24 台スタンバイ状態の場合について. 3 回計測した結果を図 10 に示す．また，図 8 図 9 と図 10. スタンバイ台数を変えずに VM が 24 台の場合を計 3 回計. ! !. 同一物理マシン上で VM がスタンバイ状態の場合，Open. vSwitch のパケット滞留時間にばらつきが生じることが明. 100. 120. #. 200000. !. !. ! !. !. !. !. ! ! ! ! !! !! ! ! !! ! ! ! !! ! ! ! ! ! ! !! ! ! ! ! ! ! ! ! !! ! !!! !!! ! ! ! !!! ! !! !!! ! ! !! ! !!! ! ! !!!!! ! ! !!! !!! !! ! !! ! ! !!! !!!! !! !!!!! !! !!!!!!!!! ! !!!!!! !! !! ! !! !! ! !!!! ! !! ! !! !!!!!! !!!! ! ! ! !!! !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !! !! ! ! ! ! !!! ! ! ! ! ! !!!!!!! !!!!!!! ! ! !!!!!!!!!!! ! ! !! ! !!! ! ! ! ! ! ! !! !!!!!!!!!!! ! ! ! ! ! ! ! ! ! ! ! ! !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !!!! !!! !!!! ! !!!! ! ! !!! ! ! !! !! ! !! !! !! ! ! ! ! !. 0. 20. 測した結果より，パケット滞留時間平均，分散のいずれも大幅に変動し，ばらつきが生じた．よって，台数によらず. 80. ". !. 150000. Delay [ns]. 100000 50000. は大きいことから，VM のスタンバイ台数の増加に伴うパ. 60. 0. VM 5 台と 15 台の場合の結果のみを比較すると，15 台. ケット滞留時間の増減はみられなかった．さらに，VM の. 40. !. の結果について表 3 にまとめた．. 台（1 回目）の方がパケット滞留時間平均は長く，分散値. 20. Fig. 9 15 VMs standby. VM 上で CPU 負荷がかかっておらずスタンバイ状態の. 台と 24 台（1 回目）の場合を比較すると，台数の多い 24. !!. 図 9 VM 15 台スタンバイ状態. いないものとする. からパフォーマンスが安定しているように見えるが，15. !. ! !. Sec. では,VM 上で CPU に負荷をかけるプロセスは実行されて. のほうがパケット滞留時間平均は短く，分散は小さいこと. !! ! !. 0. VM がスタンバイ状態の場合. ! !!. !. !. ! ! ! !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !!! !!! ! ! ! ! ! !!!! ! !!! ! !! !!!! !! !!! ! !! ! ! ! ! ! ! ! !!!!!!!! ! ! !!! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !! ! !! ! ! !. 50000. VM 24 台（1 回目）. !. Fig. 8 5 VMs standby. Table 3 Time delay in standby VMs.. VM 15 台. !. !. Sec. VM がスタンバイ状態のパケット滞留時間. VM 5 台. !. !!. ! ! ! ! ! ! !! ! ! ! ! ! ! ! !!!!! ! ! ! ! ! ! ! ! ! ! ! ! !!!! !!!!! !!!!!!!!! !!! ! !!! ! !! !! ! !!!! !!! ! ! ! ! ! !!! ! !. 20. Fig. 7 Shutdown VMs 表 3. !!. !. !. !. ! ! ! !!. Sec. 図 7. !. !. !!. ! !. !. !. !. !. 0. 50000. ! !! ! ! ! ! !! ! ! ! ! !! ! ! ! ! ! !! ! ! !!!! ! ! ! ! !!!!! !! ! !! !! ! ! !! ! ! ! ! !! ! !! ! ! ! ! ! !!! ! !! ! ! !! !!!!! !! !! !!! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !! ! ! ! !!! 0. !. 150000. Delay [ns]. 150000. !. 100000. 200000. !. 100000. Delay [ns]. 250000. IPSJ SIG Technical Report. 40. 60. 80. 100. 120. Sec. 図 10. 24 VMs standby. Fig. 10 24 VMs standby. らかになった．. ⓒ 2018 Information Processing Society of Japan. 5.

(7) 情報処理学会研究報告. Vol.2018-DPS-174 No.12 Vol.2018-CSEC-80 No.12 2018/3/5. IPSJ SIG Technical Report 200000. 5. 評価のまとめ. から CPU に負荷をかけた場合，VM 24 台がスタンバイ状 Delay [ns]. 態の場合を図 11 にまとめた．. 同一物理マシン上で複数の VM と Open vSwitch が. 50000. 動作する場合，VM の CPU 使用率上昇によって Open. vSwitch が受ける影響は非常に小さいことがわかった． Open vSwitch は 2 種類のカーネルキャッシュをもちユー. 0. ザ空間のフローテーブルへのアクセスを最小限にとどめるよう実装されている [9], [10]．本計測で用いた 7 種類のフ. きを生じた VM がスタンバイ状態の場合については原因を明らかにすることはできなかったが，「ホスト OS のス. ケジューリング」と「CPU アンダークロック」の 2 つの. 原因が推測できる．CPU のアンダークロックは，CPU の. 消費電力を節約するためにクロック周波数を下げることを指す．Open vSwitch 動作マシンの設定では CPU 動的ク. ロック変更が有効化されており最小動的クロック数は 1.2. GHz，最大動的クロック数は 3.8 GHz であった．CPU が. 低負荷状態（図 11 紫）よりも高負荷状態（図 11 赤）の方がおよそ 30 μ s もパケット滞留時間が短いことから，仮. にアンダークロックが原因であれば大きく Open vSwitch. のパフォーマンスを低下させていると言える．. !. !. !. !. !. !. ! !!. !!. ! !. !. ! !. ! !. !. ! ! ! ! ! !! !! ! ! ! ! ! ! ! ! ! ! ! ! ! !! !! ! !!!! !!!!!! !!!!! !! !! ! ! !! ! ! !!! !! ! !!!!! !! !!! ! !! !!!! ! !!!! ! ! ! ! ! ! ! ! ! !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !!! ! !! ! !!!! ! !!!!!!!! ! !!!!! !!! !!!!! !!!!!!!!!!! !!! !! !!! ! !!!!!!!! ! !! ! !! !!! !! !! !!!!!!!!!!!!! !!! !! !!! ! !!!!!!!! !! ! ! !! ! !! ! !! ! !! ! !! !! !!!!!!!!!!!!! !!!!!! !! ! !!!!! !! !!!!! !!!!!!! !!!! ! !! ! !!!!!!!!!!!!!!! !! !! !!!!!!! !!! !!!! !! !!!!!!!!!!!!! ! !!! !!!!!! ! !!!!! !! !! ! !! !! ! !!!! ! !!!! !!! !! ! ! !! ! ! !!! !!! ! !!! !! !!! ! !! ! ! !!! !!!!!! ! ! !!!!!!! !! !! !!! !! !!! ! !! ! !!!!! !! ! !!! !!!! !!!! ! !!! !! !!!! !!!! ! !! !!!!!! !! ! !!! ! !! ! ! ! ! ! !! ! !! ! ! ! !!!!!!!!!!!! ! !! ! !!!!! !!! !!! !!! ! ! !! !!!!!! !!!!!!! ! ! !!! ! !!!!!!! !! ! !!! !!!! !!!!!! !! ! ! !!! !!! ! !!! !!!!! ! !!!! !!! ! ! !!! !! ! !! ! ! ! !! ! ! ! ! ! !! !! ! !! !!! !! !! !!! ! ! !! ! !! !!! ! !!!!!!!!! !!!!! !!!!! ! ! ! !! !!!! ! ! !!! ! ! !! ! ! !! !!! ! !! !!!!!!! ! ! !!!!!! !!! !! ! ! ! ! ! !!!! ! ! !! !! !! ! ! ! ! ! ! ! ! ! ! ! !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !! ! ! ! ! !! ! ! ! ! ! ! ! ! ! ! ! !! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !!! ! ! ! ! ! !!!!! !!!!! !!!! ! ! ! ! !! !!!!!!! !!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 100. 200. 図 11. けなかったと考えられる [8]．パケット滞留時間は VM 起. 増加したと考えられる．また，パケット滞留時間のばらつ. !! !. 300. 400. 500. 600. 700. Sec. シュで処理されたため CPU の負荷が上昇しても影響を受. るメモリバスを多く利用するため，パケット滞留時間が. ()*+,,-. !. 0. ローはフローテーブルへのアクセスなしにカーネルキャッ. イメージを読み出す disc I/O が Open vSwitch と共有す. '#. ! 100000. 装 OpenFlow スイッチの比較，VM を順に起動し VM 上. 動時大幅な増加が見られたが，これは VM 起動時に OS. ./0 0&. 150000. ハードウェア実装 OpenFlow スイッチとソフトウェア実. !"#$$%& '#12. 各結果のまとめ. Fig. 11 summary of each result. Open vSwitch，入手先 http://openvswitch.org. VirtualBox，入手先 https://www.virtualbox.org. Vagrant，入手先 https://www.vagrantup.com. ameh Gobriel, Charlie Tai, Flow Classification Optimizations in DPDK，入手先 https://dpdksummit.com/Archive/pdf/2016USA/Day01Session07-SamehGobriel-DPDKUSASummit2016.pdf. [9] Ben Pfaff, Justin Pettit, Teemu Koponen, Ethan Jackson, Andy Zhou, Jarno Rajahalme, Jesse Gross, Alex Wang, Joe Stringer, Pravin Shelar, Keith Amidon, Martin Casado, The Design and Implementation of Open vSwitch, 2015 . [10] Ben Pfaff, The Power of Compound 入手先 Caches in the OVS Pipeline, http://openvswitch.org/support/ovscon2016/7/0950pfaff.pdf. [11] McKeown, Nick and Anderson, Tom and Balakrishnan, Hari and Parulkar, Guru and Peterson, Larry and Rexford, Jennifer and Shenker, Scott and Turner, Jonathan, OpenFlow: Enabling Innovation in Campus Networks, SIGCOMM Comput. Commun. Rev., April 2008 [5] [6] [7] [8]. 6. おわりに今後の展望として，低負荷状態時におけるパケット滞留. 時間の増加原因と VM スタンバイ状態におけるパケット滞留時間のばらつきの原因を明らかにする必要がある．参考文献 [1]. [2]. [3] [4]. OpenFlow Switch Specification Version1.3，入手先 https://www.opennetworking.org/images/stories/downloads/sdnresources/ onf-specifications/openflow/openflow-specv1.3.0.pdf. Michael Jarschel, Simon Oechsner, Daniel Schlosser, Rastin Pries, Sebastian Goll, Phuoc Tran-Gia, Modeling and Performance Evaluation of an OpenFlow Architecture, In 23rd International Teletraffic Congress, 2011 . Open vSwitch，入手先 http://openvswitch.org. IBM Networking Operating System RackSwitch G8264，入手先 https://www3.lenovo.com/jp/ja/data- center/networking/ ethernet-rackswitch/RackSwitchG8264/p/WMD00000026.. ⓒ 2018 Information Processing Society of Japan. 6.

(8)