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

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

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

（本記事は「OpenFlowに関するよくありそうな質問と、専門家からの答え（前編）」の続きです。

コントローラが単一障害点になる可能性は？

─── OpenFlowのスケーラビリティには問題ないとして、もう1つOpenFlowの集中管理に関して、「OpenFlowコントローラが落ちてしまうとネットワーク全体に問題が及んでしまうのではないか」という質問もありました。

樋口　残念ながらOpenFlowコントローラが故障などで停止すると、全体に影響が及びます。しかし、コントローラの故障がすぐにシステム全体の停止につながるわけではありません。それにコントローラの二重化などは可能なので、一般的なシステムで必要となる信頼性は確保できると思います。

Openflowコントローラが1つしかなく、それが落ちたとします。そのときでも、先ほど説明したとおり、スイッチは既知のパケットを受信する限りコントローラに問い合わせをせずにパケットを転送可能です。つまり、既知のパケットを受信し続ける限りはコントローラが停止していてもシステムは動作を継続できます。

とはいえ、実際には未知のパケットを受信する確率もそれなりに高いと思いますので、やはりコントローラの長時間の故障は許されないと考えた方がよいでしょう。

─── とすると、従来のシステムと比較してOpenFlowを利用したシステムの信頼性は高いといえるのでしょうか？

樋口　従来のシステムにも高い信頼性を要求する金融系システムからコストパフォーマンスを重視する一般的なWebシステムまでさまざまなシステムが存在します。ここでは、ロードバランサ、ファイアウォールを利用するWebシステムを例に考えてみます。仮想化によりサーバ集約されている前提です。私としては以下のように考えています。

従来のシステムの特徴

• コアルータを導入している場合、コアルータの故障により全てのシステムに影響が及ぶ
• 各機器を矛盾なく設定する必要がある。設定項目も多数。人に起因するトラブルは発生しやすい
• 枯れた技術であり実績も豊富

OpenFlowを採用したシステム

• コントローラの障害により全てのシステムに影響が及ぶ。
• 設定は一元管理される。矛盾なく多数の機器に設定可能。設定ミスは生じにくい。
• 新技術であり、実績がない。枯れた実装も存在しない。

OpenFlowコントローラは、ロードバランサやファイアウォールと同様SPoF（Single Point of Failure：単一障害点）ですが、ロードバランサやファイアウォールの停止が1つのシステム停止を引き起こすのに対し、OpenFlowコントローラの停止は複数システムの停止を引き起こします。ロードバランサやファイアウォールと比較して高い信頼性が求められていることは否定できません。

しかし前述したように、OpenFlowでも一般的な製品であればコントローラの二重化は可能になるでしょう。よって一般的なシステムで必要な信頼性は確保できると考えています。

OpenFlowは新しい技術であるため、枯れていないのは仕方ないと思っています。このあたりの課題は時間が解決するので、それほど私は心配はしていません。

トラブル対応のノウハウ蓄積はこれからだが、集中管理の利点もある

─── 「トラブったときの原因の切り分けや解析が大変になりそう」という声もありました。

樋口　OpenFlowを採用したシステムのトラブルシューティングでは、サーバ、OpenFlowスイッチ、OpenFlowコントローラ、スイッチとコントローラ間のネットワークなどの、どこに問題があるかを切り分ける必要があります。OpenFlowが実際の商用サービスで利用されている例は少ないため、ノウハウの蓄積はほとんどありません。そのような意味では、トラブル対応は大変でしょう。

しかし、OpenFlowならではの将来性もあります。OpenFlowはネットワークを一元管理するため現在の設定や動作が「見える化」されます。各ネットワーク機器にログインして一つ一つ設定を確認する必要はありません。

OpenFlowコントローラで各OpenFlowスイッチに格納されている制御ルールを収集し、矛盾が存在しないかチェックする機能を実装することもできます。

─── 集中管理は利点でもある、ということですか。

樋口　集中管理と同時に、OpenFlowによる標準化は利点だと思います。従来のネットワーク機器はベンダーごとに設定方法が異なりました。設定が正しいかを確認するには各製品に熟知した要員を確保する必要があります。しかし、OpenFlowでは標準化されているOpenFlowの仕様を理解していれば、どのベンダーのスイッチであれ正しく設定されているか（正しく制御ルールが書かれているか）を確認できます。

OpenFlowコントローラに機能追加を行い、定型的なトラブル切り分け作業を自動化することも可能になるでしょう。これまで以上に迅速なトラブル対応ができるようになります。

─── なるほど、コントローラにインテリジェンスを持たせることもできるわけですね。

樋口　OpenFlowは新しい技術であるため、まだ成熟しきっていない点もあります。OpenFlowの機能をフルに利用する場合、OpenFlowスイッチに各ベンダーごとに異なる方法で設定を行う必要があります。このあたりは今後改善されていくでしょう。

また、マルチスレッドにより高度に高性能化されたコントローラの不具合修正は簡単ではない、といった問題もあります。プログラムによりネットワークを制御できるようになるため、今後はネットワーク管理者にもプログラム開発スキルが必要になるかもしれません。少なくともOpenFlowコントローラをサーバ上で自前で動かす場合はサーバ管理スキルが必要になるのではないでしょうか。私は仮想化とともに、管理者に求められるスキルも変わると考えています。

─── ありがとうございました。