先日の記事「OpenFlowの本質は「プログラマブルであること」」を公開したところ、多くの方にツイッターやブックマークでコメントをいただきました。その中にはOpenFlowに関する疑問、質問も含まれていました。シニアエキスパートの樋口晋也氏に聞いたことをまとめたものです。(本記事は「OpenFlowに関するよくありそうな質問と、専門家からの答え(前編)」の続きです。OpenFlowのスケーラビリティには問題ないとして、もう1つOpenFlowの集中管理に関して、「OpenFlowコントローラが落ちてしまうとネットワーク全体に問題が及んでしまうのではないか」という質問もありました。残念ながらOpenFlowコントローラが故障などで停止すると、全体に影響が及びます。コントローラの故障がすぐにシステム全体の停止につながるわけではありません。それにコントローラの二重化などは可能なので、一般的なシステムで必要となる信頼性は確保できると思います。Openflowコントローラが1つしかなく、それが落ちたとします。そのときでも、先ほど説明したとおり、スイッチは既知のパケットを受信する限りコントローラに問い合わせをせずにパケットを転送可能です。既知のパケットを受信し続ける限りはコントローラが停止していてもシステムは動作を継続できます。いえ、実際には未知のパケットを受信する確率もそれなりに高いと思いますので、やはりコントローラの長時間の故障は許されないと考えた方がよいでしょう。従来のシステムにも高い信頼性を要求する金融系システムからコストパフォーマンスを重視する一般的なWebシステムまでさまざまなシステムが存在します。ここでは、ロードバランサ、ファイアウォールを利用するWebシステムを例に考えてみます。仮想化によりサーバ集約されている前提です。私としては以下のように考えています。従来のシステムの特徴コアルータを導入している場合、コアルータの故障により全てのシステムに影響が及ぶ各機器を矛盾なく設定する必要がある。人に起因するトラブルは発生しやすい枯れた技術であり実績も豊富OpenFlowを採用したシステムコントローラの障害により全てのシステムに影響が及ぶ。設定は一元管理される。矛盾なく多数の機器に設定可能。設定ミスは生じにくい。新技術であり、実績がない。枯れた実装も存在しない。Failure:単一障害点)ですが、ロードバランサやファイアウォールの停止が1つのシステム停止を引き起こすのに対し、OpenFlowコントローラの停止は複数システムの停止を引き起こします。ロードバランサやファイアウォールと比較して高い信頼性が求められていることは否定できません。前述したように、OpenFlowでも一般的な製品であればコントローラの二重化は可能になるでしょう。よって一般的なシステムで必要な信頼性は確保できると考えています。OpenFlowは新しい技術であるため、枯れていないのは仕方ないと思っています。このあたりの課題は時間が解決するので、それほど私は心配はしていません。「トラブったときの原因の切り分けや解析が大変になりそう」という声もありました。OpenFlowを採用したシステムのトラブルシューティングでは、サーバ、OpenFlowスイッチ、OpenFlowコントローラ、スイッチとコントローラ間のネットワークなどの、どこに問題があるかを切り分ける必要があります。OpenFlowが実際の商用サービスで利用されている例は少ないため、ノウハウの蓄積はほとんどありません。そのような意味では、トラブル対応は大変でしょう。OpenFlowならではの将来性もあります。OpenFlowはネットワークを一元管理するため現在の設定や動作が「見える化」されます。各ネットワーク機器にログインして一つ一つ設定を確認する必要はありません。OpenFlowコントローラで各OpenFlowスイッチに格納されている制御ルールを収集し、矛盾が存在しないかチェックする機能を実装することもできます。集中管理は利点でもある、ということですか。集中管理と同時に、OpenFlowによる標準化は利点だと思います。従来のネットワーク機器はベンダーごとに設定方法が異なりました。設定が正しいかを確認するには各製品に熟知した要員を確保する必要があります。OpenFlowでは標準化されているOpenFlowの仕様を理解していれば、どのベンダーのスイッチであれ正しく設定されているか(正しく制御ルールが書かれているか)を確認できます。OpenFlowコントローラに機能追加を行い、定型的なトラブル切り分け作業を自動化することも可能になるでしょう。これまで以上に迅速なトラブル対応ができるようになります。コントローラにインテリジェンスを持たせることもできるわけですね。OpenFlowは新しい技術であるため、まだ成熟しきっていない点もあります。OpenFlowの機能をフルに利用する場合、OpenFlowスイッチに各ベンダーごとに異なる方法で設定を行う必要があります。このあたりは今後改善されていくでしょう。マルチスレッドにより高度に高性能化されたコントローラの不具合修正は簡単ではない、といった問題もあります。プログラムによりネットワークを制御できるようになるため、今後はネットワーク管理者にもプログラム開発スキルが必要になるかもしれません。少なくともOpenFlowコントローラをサーバ上で自前で動かす場合はサーバ管理スキルが必要になるのではないでしょうか。私は仮想化とともに、管理者に求められるスキルも変わると考えています。ありがとうございました。ネットワークPublickey広告.NET帳票ツール。デザイナはExcel。クラウド/サーバー環境対応。.NET5/6/8に対応。デザイナはExcelのため、エンドユーザーも編集可能。ノーコードでCSVファイルから帳票を出力する、CSVReportも新収録。Niino(jniino)IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。Linux」、CNCFのインキュベーションプロジェクトに採択WebAssemblyランタイム「Wasmer」がiOSをサポート、iOS上でWebAssemblyを実行。Copilotが複数ファイルにわたるコード変更や生成に対応。CopilotがAppleのXcodeに対応。Xcode」パブリックプレビューOrbがデジタル通貨決済システムの基盤にNewSQLのTiDBを採用。ETLをなくし、トランザクション処理とデータ分析を統合可能に[PR]日本人プログラマ向け、プログラミングに適した「フォント」まとめ。2024年版GitHubで最も使われている言語、PythonがJavaScriptを抜いて1位に。生成AI関連プロジェクト急増で。Sonnetが選択可能に。