*

OpenFlow スイッチとしてのOpen vSwitch の性能

公開日: 最終更新日:2014/07/23  |  By  |  Open vSwitch, OpenFlow, ryu, SDN

by Hiroki Ide 2013/8/26

Open vSwitch のカーネルモジュールがLinux 3.3 からkernel のメインラインにマージされ
標準的に使用されるようになってきました。

既存のLinux Bridge を置き換えるように使われており
特にLinuxをホストとしたKVMなどの仮想化を考える上では無視できない存在となっていると思います。

今回は前回の構成のままで、Open vSwitch のパフォーマンスを見てみたいと思います
(Server A から Server B へ負荷掛け)。

 ※マシンのスペック
   CPU : Intel Xeon L5640 12-thread
   NIC  : Broadcom NetXtreme II BCM5709

Open vSwitchには主要なコンポーネントとして、以下が存在します。

ユーザー空間で動作
 ・ovs-vswitchd
 ・ovsdb-server

カーネル空間で動作
 ・datapath

 ※設定次第で、ユーザー空間で動作させる事も可能です

パフォーマンス検証をするにあたって、大きく3つの観点に分けてみました。

1.OpenFlow コントローラー、OpenFlow スイッチ間

 受信したパケットがスイッチのフローテーブルにマッチしない場合など
 コントローラーへの問い合わせが発生するケースでのコントローラー、スイッチの負荷確認と
 なります。

 まずは、ネットワーク内でトラフィックが発生しないという状況下で、以下の要因によって
 負荷が変わるかどうかを確認します。

 ・コントローラーに接続するスイッチの台数
 ・コントローラーとの接続形式(プレーンテキスト/TLS)

 以下が結果となります。

接続形式
スイッチ台数
CPU(ovs-vswitchd)
遅延
プレーンテキスト
1
0%
1.9ms(グラフ
プレーンテキスト
998
53%
75ms(グラフ
TLS
1
0%
2.2ms(グラフ
TLS
998
55%
80ms(グラフ

 通信がない状況でも多数のスイッチを接続するとovs-vswitchd の負荷が増大する事が分かりました
 (このケースでは、1つのovs-vswitchd が多数のスイッチを管理している状況となっています)。
 負荷だけでなく遅延も増加しており、パケットロスが発生する事も確認できました。

 また、コントローラーとの接続をTLSで行うと遅延が増加する事を確認できました
 (通信がない状況ではCPU負荷については、目立った変化は見られませんでした)。

 次に、全てのパケット処理について、コントローラーに問い合わせるようにスイッチを設定しておき
 トラフィックを発生させて、負荷状況を確認します。

 今回の検証全体での確認項目は、マシンのインターフェースが1G である事や
 最初にネックとなるのは処理パケット数であろう事から、PPS(Packet Per Second)を中心としました。

 コントローラー側で使うアプリケーションは
 ポート1から受信したらポート2に、ポート2から受信したら
 ポート1にパケットを送信しろというメッセージ(Packet-Out)を投げる という
 最も単純な(負荷が少ない)ものとなっています。

 以下が結果となります。

 ■プレーンテキスト接続

 ■TLS接続

 コントローラー(ryu-manager)のCPU負荷がプレーンテキスト接続だと、2000pps
 TLS接続だと、1750pps くらいでCPU使用率が92%に達しています。
 トラフィックが発生して、コントローラーへの問い合わせが頻繁になると、TLS接続の方が
 CPU負荷が上昇する事が確認できました
 (TLS接続時のovs-vswitchd の負荷の伸びは更に大きくなっています)。

 ※rcu_sched は、常にCPU 1% 程を使用しており、これはフローテーブルの更新処理で
   RCU を使用している為だと思われます

 2000pps 程度で、CPU 1スレッドをかなり占有してしまうので
 やはり、よく言われるようにコントローラーへの問い合わせは極力抑えるべきだと分かります。
 コントローラーが複数スイッチを束ねている状況であれば、尚更、気を付けなくてはならないと
 思います。

2.カーネル側(datapath)でのパケットフォワード

 どのような状況でも最終的にはdatapath の部分でパケットフォワードされますが
 余計なlookup を排して、純粋なカーネルモジュール(openvswitch.ko)での
 処理性能を確認します。

 負荷掛けは、長時間の実施でもパケットロスが起こらないレベルでパケットの送信レートを
 抑えています。
 実際にはもう少し良い値も出たと思いますので、今回の結果は参考レベルとなります。

 また、負荷掛け用の通信はランダムでIPアドレスやポートを変えるような事はしていなく
 常に同一のIPアドレス、ポートを使用しております。

 以下が結果の一部、抜粋となります。

テストパターン
フレームサイズ
64byte
128byte
512byte
1280byte
1518byte
Non OF スイッチ
143Kpps
73Mbps
143Kpps
146Mbps
123Kpps
505Mbps
96Kpps
984Mbps
81Kpps
986Mbps
1フローエントリ
(マッチ項目1個)
同上
同上
同上
同上
同上
1フローエントリ
(マッチ項目15個)
同上
同上
同上
同上
同上
1フローエントリ
(TTL減算処理)
同上
同上
同上
同上
同上
1フローエントリ
(Set-Field処理)
同上
同上
同上
同上
同上
1フローエントリ
(Set-Queue処理)
同上
同上
同上
同上
同上
61000フローエントリ
(マッチ項目1個)
同上
同上
同上
同上
同上
61000フローエントリ
(マッチ項目15個)
同上
同上
同上
同上
同上
61000フローエントリ
(64テーブル使用)
同上
同上
同上
同上
同上

 各テストパターンの説明は割愛させて頂きますが
 結論として143Kpps くらいはパケットを捌けそうです
 (フレームサイズ 1280、1518byte は、1Gの帯域ネックで、実質 PPSのテストになっていません)。

 この値をどう見るかは、使用を想定するシステムによるかと思いますが
 理論値には遠く及ばないもののホストOS内に配置されるスイッチとしては、それなりには
 使えるのではないでしょうか。
 さらに、SDNな世界では必要なパケットだけ届くように調整される傾向にある
 という事もあります。
 また、CPU使用率に関しては、全く負荷が掛かりませんでした。

 結果の中身について言及しますと、何てことはなく
 フローテーブルの状態に関係なくすべて同じ結果となっております。

 これはOpen vSwitch の構造を理解していれば、当たり前のことで
 最初に受信したパケットはカーネル空間からユーザー空間へと渡され
 (情報のやり取りはNetlink を利用)
 パケットの解析を行った後に、フローテーブルに該当するフローエントリが無いかを
 検索しにいき、その後に然るべきアクションを実行します。

 この内容をカーネル空間でもフローテーブルとしてキャッシュしており、次回以降
 このテーブルを参照する限りにおいてはカーネル空間での高速な処理(Fast Path)となります。

 ここでの負荷掛け用通信は、常に同一IPアドレス、ポートで行っており
 フローキャッシュが利用されているので、カーネル空間での処理能力を確認出来た事になります。

 また、この状態においては、ユーザー空間でのフローテーブルの登録状況は
 パフォーマンスに(ほぼ)影響を与えない事も確認できました。

3.ユーザー空間でのパケット処理

 観点1と観点2を見て、これでOpen vSwitch が使えそうだと考えるのは早計で
 ユーザー空間でのフローテーブルの検索処理等の一連の動作の負荷確認をする必要があります。

 ここでは、負荷掛けの通信を1種類でなくランダムなものとし、通常では有り得ませんが
 カーネル空間でのフローのキャッシュを行わないようにして、テストを行います。

 以下が結果となります。

 処理がユーザー空間で行われるようになると、ovs-vswitchd に負荷が掛かり
 PPS も急に低い値となる事が確認できました。
 15Kpps くらいからはCPU使用率の伸びも鈍化しましたが、パケットのロスはありませんでした。

まとめ

 Open vSwitchの処理の流れとしては

 最初に受信したパケットをカーネル空間のフローキャッシュで検索を行い
 マッチすれば、そのままパケットフォワーディング(143Kpps)を行う

 マッチしなければ(テーブルミス)、ユーザー空間に処理が移り
 ユーザー空間のフローテーブルとのマッチングを行う(15-27Kpps)

 そこでもマッチしなければ(テーブルミス)、コントローラーへの問い合わせを行う(2-3Kpps)
 という3段階があります。

 ここでのPPS計測は、ピンポイントで各コンポーネントに負荷がかかるようにした場合ですし
 コントローラーのアプリケーションも最も単純なものを使用していますので
 実際にこの通りとなる訳ではありませんが、特長や限界値を把握できたと思います。

 ハードウェアスイッチのメリットはパケット処理能力の高さで
 デメリットはフローテーブルを高価で容量の限られるTCAMに載せている事です。

 逆に、Open vSwitchはパケット処理能力は劣りますが
 フローテーブルを豊富なメモリ上に載せられ、かつ その使用量を監視しており
 足らなくなりそうであれば、メモリの動的割り当てが起こるようになっています。

 テストの中では61000エントリを登録していましたが、試しに660000エントリ程、追加しても
 問題ありませんでした(メモリの動的割り当てが発生)。

 Open vSwitchのパフォーマンスのポイントは、今回の結果からも分かるように
 極力、カーネル空間で完結させる事です。

 その為にはフローキャッシュにエントリを載せる事が重要になります。
 詳細は割愛させて頂きますが、カーネル空間のフローキャッシュは完全一致のエントリの集合であり
 DDoSなどで、すぐにテーブルが溢れてしまう可能性がありますが
 短期的なフロー(DoSアタックなど)を検知して、キャッシュしない仕組みがある事や
 そもそも、テーブル容量を動的に変更できる事 など対応が可能となっております。

 ※キャッシュ回収が始まるトリガーの閾値も変更する必要があります

 このような工夫があれば、大量のフローによるパフォーマンスの低下に関しては
 ある程度の安心は得られると思います。

 パケットフォワーディング能力の改善に関しては、今回触れませんでしたが
 これについては、Intel DPDKやNetmap(今回はNICが未対応) などのアプローチが
 有効だと考えており、機会があれば検証してみたいと思います。

関連記事

no image

RDOを使用したOpenStack+MidoNet環境のインストール

ビットアイル総合研究所 田波です。 今回は以前紹介したRDOを使用して、OpenStack+M

記事を読む

25E6-25A7-258B-25E6-2588-2590-25E5-259B-25B3

OpenFlow にてNW機能構築

by Hiroki Ide 2013/7/18 仮想化全盛の今日において、足枷となっていたネッ

記事を読む

dpdk

OpenStack OVS VXLAN ネットワークの高速化

少し前の話になりますが、3月2日に開催された 日本仮想化技術株式会社様の OpenStack最新情報

記事を読む

no image

ビットアイル総合研究所は、クラウド技術に関する調査&研究を通して、社会と会社に寄与していくことを目的に、ビットアイル・エクイニクスの企業内研究所として2011年8月に設立されました。

openstack-figure1-2x
COHO DataStream のCinder連携

OpenStack Cinder のストレージバックエンドとしてはCe

blog-ocata
Jujuで Ocataを含む様々なバージョンのOpenStack をデプロイする方法

祝OpenStack Ocata リリース!! ということで、早速デプ

newton
Juju Manual Cloud で OpenStack 環境構築

本当にご無沙汰しております。 この投稿はOpenStack Adve

top
HACK! THE Juju/MAAS

6/8~6/10まで幕張メッセで開催されたInterop 2016。皆

dpdk
OpenStack OVS VXLAN ネットワークの高速化

少し前の話になりますが、3月2日に開催された 日本仮想化技術株式会社様

→もっと見る

PAGE TOP ↑