OpenFlowに関するよくありそうな質問と、専門家からの答え（前編）

先日の記事「OpenFlowの本質は「プログラマブルであること」」を公開したところ、多くの方にツイッターやブックマークでコメントをいただきました。その中にはOpenFlowに関する疑問、質問も含まれていました。

この記事ではその中からOpenFlowでよくありそうな質問を3つ、「OpenFlowのスケーラビリティ」「コントローラが単一障害点になる可能性」「トラブル時の切り分け」をピックアップして、OpenFlowについての講演なども行っている、NTTデータ 技術開発本部 ITアーキテクチャソリューションセンタ シニアエキスパートの樋口晋也氏に聞いたことをまとめたものです。

集中管理型のOpenFlow、どれくらいスケールするのか？

─── 「OpenFlowはどれくらいスケールするのか？」というコメントがTwitterでありました。

OpenFlowは「OpenFlowコントローラ」が多数の「OpenFlowスイッチ」を集中管理する方式ですから、たしかにスケーラビリティは気になります。例えば、コントローラは何台くらいのスイッチを制御を制御できるものなのでしょうか？

樋口　まずは管理するべきスイッチの数について話をしましょう。

仮想化を利用する場合、一般的にはサーバ1台につき1つの仮想スイッチソフトウェア（OpenFlow利用時はOpenFlow対応の仮想スイッチ）がインストールされます。サーバが100台存在すれば、管理するべきスイッチ数も100になります。一般に考えられている以上に管理するべきスイッチ数が多い、というのが現実ではないでしょうか。

─── 管理するべきスイッチ数は非常に多いと。

樋口　さて本題に移りますが、OpenFlowコントローラ1台で管理可能なスイッチ数の上限は何台なのか？ 実はこれにはっきりお答えすることは難しいです。

OpenFlowコントローラは通常、IAサーバ上のソフトウェアとして動作させるケースが多いと思われますが、制御可能なスイッチ数はサーバスペックにより変化するため、一概には言えません。サーバ性能とスイッチ数の関係については、残念ながらNTTデータでも具体的な性能測定を開始したばかりで具体的な数値を答えることはできませんが、オープンソースのコントローラを用いた場合の性能が公開されているので、後ほど紹介しましょう。

コントローラがボトルネックになることはほとんどない

樋口　とはいえ、OpenFlowにはコントローラへの負荷集中を防ぐ仕組みが組み込まれているので、コントローラがボトルネックになることはほとんどないと考えています。

OpenFlowスイッチは未知のパケットを受信した時のみコントローラにパケットの制御方法を問い合わせます。もう少し正確に言うと受信したパケットから抽出した12種類の情報がスイッチ内に書き込まれた制御ルール（フローエントリ）にマッチしない場合にのみコントローラに問い合わせを行います。

問い合わせを受けたOpenFlowコントローラはパケット制御方法を決定し、制御ルールをスイッチに書き込みます。パケットはその制御ルールに従い転送されます（制御ルールを書き込まないでパケットを転送する方法も存在するのですが割愛します）。

一度スイッチに制御ルールが書き込まれると制御ルールに対応するパケットを受信している限りスイッチはコントローラへ問い合わせることなしにパケットを転送できるようになるため、コントローラへ負荷はかかりません。

コントローラの処理も十分に高く、分散処理も可能

─── 制御ルールが十分にスイッチに書き込まれていれば、コントローラへの問い合わせは滅多に発生しないため、コントローラの性能がある程度あればボトルネックにならない、ということですね。

樋口　はい。しかし、そのような理由だけでは納得されない方もいらっしゃると思います。

例えば、事業の継続性にかかわるようなインフラを管理されている方は「スイッチに全く制御ルールが書き込まれていない状態で、バースト的に負荷が発生し、さらにネットワークに流れるパケットがそれぞれ異なるためスイッチからコントローラに大量の問い合わせが発生する」といった最悪のケースを想像をされるのではないでしょうか。

もちろん負荷の限度はありますが、そのような状況に陥ってもOpenFlowコントローラは問題なく動作する可能性が高いです。

「Beacon」と呼ばれるJavaで実装されたオープンソースのOpenFlowコントローラは、Core i7/3.3GHzCPU、9GBメモリのサーバを用い、4スレッドで動作させると1秒間に600万フローを処理可能だというデータがあります（参考：Controller Performance Comparisons）。

もちろん、コントローラに実装する機能の複雑度により処理性能は変化しますが、この結果は一般的な企業が有する規模のシステムであればコントローラの性能が問題になることはほぼないことを示していると考えます。

樋口　OpenFlowでコントローラに負荷を集中させない方法はまだあります。

例えば1000台のOpenFlowスイッチを500台ずつに分け、それぞれを別のOpenFlowコントローラで管理すれば簡単にコントローラへの負荷を分散できます。

─── 分散も簡単にできると。コントローラがボトルネックになる可能性は高くないのですね。

樋口　はい。むしろコントローラ以外の部分が気になっています。例えば、1台のOpenFlowスイッチに書き込める制御ルール数の上限値を超えてしまうと、OpenFlowのネットワークをスケールさせることが難しくなります。

この問題の解決方法はいくつか考えられますが、多少複雑になるのでここでは割愛します（解決方法の一例をソフトウェアデザイン誌の7月号に書いてあるので興味のある方は読んでいただけると幸いです）。

（「コントローラが単一障害点になる可能性」「トラブル時の切り分け」は後編に続きます。）