ここ最近、OpenDaylightという言葉が話題に上ることはほとんどありませんでした。結局のところ、長年ネットワークソリューションを使用・管理しているスタッフは、OpenDaylight関連のニュースを目にすることはほとんどなく、それゆえOpenDaylightについてよく知らないのです。
しかし、この状況は今後1年半から1年半の間に激変し、その頃には OpenDaylight の話題を避けることはほとんど不可能になるでしょう。この記事では、OpenDaylight の本当の意味、重要性、そしてそこから広がるより広い概念について見ていきます。
Software-Definedネットワーキングの台頭により、OpenDaylightはこのトレンドにおける最も重要な技術プロジェクトとなりました。その目的は単純で、ネットワーク・インフラストラクチャの閉ざされた扉をオープンソース・フレームワークのセットで開くことで、業界がより広範な開発努力を組織化するよう促すとともに、その成果をどのベンダーの製品にも適用できるようにして、開発者が十分な収益を得られるようにすることです。
OpenDaylightアーキテクチャ
従来、ネットワークはサーバやアプリケーションの下層に位置していました。仮想化プラットフォームが急速に複雑化・高度化するにつれて、内部ネットワーク機能が新たなレイヤーで見られるようになりました。
この新機能は、異なる仮想マシン環境間のデータトラフィックの要素を同じ物理デバイスに保存するなど、多くの利便性をもたらします。さらに最近では、レイヤ3ネットワークの上にレイヤ2ネットワークをエミュレートするなど、新しい技術によってより微妙な運用効果を実現することも可能になっています。
後者の実装には現在、独創的なコードを使用する必要がありますが、具体的な結果はすでに基礎となるネットワーク層と同等です。しかし、上位レイヤーとネットワーク・レイヤーの間に相関関係があるとしたらどうでしょう？
亀とうさぎ、早く調理してゆっくり調理？
しかし、SDN もまたこの本質的な困難に直面しています - それは同時に OpenDaylight 開発の道において致命的な障害となっています。簡単に言えば、ハードウェアは速く、ソフトウェアは遅い。
1996年、某社はF1200ワイヤー・スピード・ルーターを開発したばかりでした。当時はまだ、ほとんどすべてのレイヤ3ルーティングを専用ソフトウェアで実装する必要があり、比較的低速でした。一方、F1200はASIC（＝特定用途向け集積回路）を利用することで、同じ機能を実現しながら速度を1桁向上させました。
しかし現在では、ネットワーク機能はハードウェアから取り除かれ、ソフトウェアに戻されます。それだけでなく、標準化されたPCプロセッサーは、仮想化スタックの仮想マシンを使って切り分けられるでしょう。これはスピードの観点からは後退しているのでは？
CloudFounders社のCTOであるKurt Glazemakers氏は、「全体的に、ソフトウェアは専用ハードウェアのスピードにはかないませんが、分散させる方法によって、ソリューションのコストを劇的に削減することができます。
実際、ネットワーク環境でACL（アクセス・コントロール・リスト）を処理する大規模なハードウェア・ソリューションは、ネットワーク内の複数のVMセットで完了するようにACLタスクを分割して配信する後者の機能により、分散ソフトウェア・ソリューションよりも実行効率がはるかに低くなる可能性が高い」と指摘しています。
「さらに、CPU の性能は、2 年ごとにほぼ倍増しながら、年間 20～25 パーセントで一貫して向上しています。対照的に、VMシステムごとに必要とされるネットワーク処理性能は、このような高い成長率には程遠いものです。"
ジュニパーのEMEA（欧州・中東・アフリカ地域）サービスプロバイダー・マーケティング責任者であるデイビッド・ノグエル・バウ氏は、すべてのタスクをソフトウェアに任せるだけでは不可能であることを認めています。制御レイヤーをフォワーディングレイヤーから分離することで、ユーザーは制御レイヤーの特定の部分を集中管理できるようになり、ネットワーク運用が劇的に簡素化され、新サービスの展開が格段に速くなり、仮想マシンとネットワーク間の連携がよりスムーズになります」。
しかし、優れたパケット転送速度を提供するためには、ワイヤ・スピードのルーティング・ハードウェアが必要です。ネットワーク・デバイスは、仕事を成し遂げる筋肉として機能し、制御レイヤーの集中管理は、脳のコマンド機能を拡張することに相当します」。
ExtraHopのCEOであるJesse Rothstein氏は、ネットワーク機器からネットワーク機能を削除することにはいくつかの疑問があることを認めています。レイヤ2/3のスイッチングとルーティング機能をソフトウェアに移行することは、今日のサーバクラスのハードウェアでは完全に実現可能ですが、最も重要な問題は、運用コストはどうなるのかということです。高速パケット処理は、汎用プロセッサにとって深刻なリソースの浪費であり、CPU自体も共有リソースです。"割り込みやビジーウェイト状態の処理に多くの時間を消費し、同時に他のタスクを実行することが不可能になります。
ネットワークのボトルネックを回避するには？
Rothstein 氏は、「通常、遅いリンクは、定期的に使用される場合にのみ、そのパフォーマンス性能に深刻な影響を及ぼし、新しく出現したプロジェクトだけの場合、OpenFlow コントローラーが潜在的なボトルネックになる可能性が高い」と指摘しています。ネットワーク・トラフィックに存在時間の短いデータ・ストリームが大量に含まれたり、単一のデータ・ストリームがすべてコントローラの介入を必要としたりすると、パフォーマンスが露呈します。"
しかし、OpenFlowコントローラが時折介入する必要があるだけであれば、パフォーマンスへの影響は最小限に抑えられます。実際、このような設計は、ホスト・プロセッサを搭載した最新のイーサネット・スイッチではごく一般的です。"
ブロケードの EMEA シニア・プロダクト・マネージャーであるニック・ウィリアムズ氏も同様の見解を示し、トランスポートの既存のデータストリームに抽象化ソフトウェアを導入すると、実際の動作が遅くなると指摘しました。ネットワーク・レイヤのフォワーディング・テーブルをどの程度までプログラムでリアルタイムに変更するつもりですか？また、このような変更がトランスポートのトラフィックに影響を与える頻度はどれくらいですか？" という質問が出されました。
非リアルタイムでデータフローリストに変更が加えられた場合、自動化／プログラム化されたメカニズムであっても、変更後の処理の転送速度は元のハードウェア処理と同レベルに留まると考えているとのこと。
OpenFlowの登場
全体として、先に述べたベンダーの何社かは、優れた柔軟性により、ソフトウェア定義のメカニズムが速度に与えるマイナスの影響を大幅に相殺できると述べています。
Rothstein は特に OpenFlow について言及しました。OpenDaylight プロジェクトが SDN のための一般的なフレームワークであることを意図しているのに対して、OpenFlow はサポートされている特殊なプロトコルです。
2011年初頭に設立されて以来、OpenFlowは、占有ライセンス契約を通じて、Software-Defined分野における支配的なプレーヤーとしての地位を確立し、Brocade、Juniper、Cisco、Extreme、IBM、Hewlett-Packardなど、多くの大手テクノロジー・ベンダーの支持を得ています。
Rothstein 氏は、「OpenFlow プロトコルは、本質的にイーサネットのフォワーディングテーブルにアクセスするための API (Application Programming Interface) であり、データレイヤーから制御レイヤーを切り離す役割を果たします。これはデータレイヤーから制御レイヤーを切り離す役割を果たします。
つまり、手動で設定を調整したり、閉じたネットワークレイヤの制限を受けることなく、あらかじめ決められた方法で動作するように動的にLANを再構成する仮想レイヤの機能は、SDNの最も重要な特徴です。
OpenDaylightコア・サブスタンス
OpenDaylight フレームワークがどのように機能するのかを正確に理解してもらうために、まず最初に、現在市場にある同様の有名な製品を要約して比較します。
あなたは、Microsoftのソフトウェアアーキテクチャに精通している場合は、.NET Frameworkは馴染みのないものではありません。マイクロソフトのアーキテクチャは、関連するメカニズムに相対する基礎となるオペレーティングシステムも多数あります。アプリケーションの正常な動作を保証するために、開発者は基礎となるシステムに関連する必要もあります。SDN の役割は開発者が複雑なコードを書かずに目標を達成できるようにすることです。
OpenDaylightフレームワークも同じように動作します。上位のアプリケーションはフレームワークにコールを送信し、フレームワークは複雑なインターフェイスを使用して基盤となるネットワークデバイスと連携します。同時に、フレームワークは相関メカニズムを提供し、アプリケーションが監視、管理、侵入防止などのインフラ関連機能を使用できるようにします。
OpenDaylightはネットワークエンジニアを救えるか？
リコンフィギュレーションなしでも、新しい一連のテクノロジーを使って上から下へ直接やり取りができるようになったことで、OpenDaylight と SDN は最終的にネットワークエンジニアを仕事としてなくし、サーバ管理者に引き継がせるということでしょうか？
Glazemakers氏は、この変化の範囲はネットワークエンジニアだけでなく、業界全体に及ぶと見ています。同氏は、「ストレージ、ネットワーク、コンピュートという従来の概念的な区分は、ソフトウェアがより多くのコア機能を引き継ぐようになるにつれ、徐々に崩壊していくだろう」と予測しています。
一方、ノグエル・バウ氏は、ネットワーク・エンジニアの役割は今後も存在し続けるが、より協力的な形になると考えています。ネットワーク管理者とサーバ管理者は既にクラウド部門で緊密に連携しています。しかし、組織が SDN の世界で従業員の役割と責任を明確に定義し続ける必要があるなら、サーバプロフェッショナルとネットワークプロフェッショナルの肩書きは残るでしょう。ジュニパーの SDN ソリューションは、ユーザがこの 2 つの間で定義することを可能にします。
OpenDaylight開発の展望
OpenDaylightは最終的に成熟し、広く利用可能なフレームワークに成長するのでしょうか？それとも、Betamax、100VG-AnyLAN、ATMネットワークなどの他の傑作の包囲網の下で死んでしまうのでしょうか？OpenDaylightが開拓した領域で、市場はどのように進化するのでしょうか？
Glazemakers は SDN がマクロな観点から成長し続けると信じています。私は SDN がプライベートクラウドソリューション、仮想化技術、ネットワークサービスプロバイダーからの新しい先進的な提供によって強力に牽引されると思いますが、その最も広い成長範囲は企業ネットワーキングの領域に留まります。" と彼は断言します。
Noguer Bau はクラウドコンピューティングが Software-Defined Networking の主戦場になると考えています。メディアコンバージェンスへの明らかなトレンドにもかかわらず、SDN はまだ好調です。次の 12 ヶ月で、より多くのコントローラソリューションが市場に出回るでしょう。これらのいくつかはまだ実験段階ですが、他のいくつかはクラウドコンピューティング環境における現実の問題を解決する能力を持っています。"
ウィリアムズは、Software-Definedのコンセプトがまだ確立されていないことに同意しています。
それは黎明期です。技術者はユースケースの仕組みとそれらがどのように展開されるかを理解するために努力する必要があり、SDN の助けを借りて、全てのメーカは OpenFlow の全ての機能をサポートするために同じ努力をすることになるでしょう。
Rothstein 氏は、SDN の概念はまだ拡大中であり、現在展示されているものはそのほんの一部に過ぎないと考えています。SDN の定義はまだ進化していると思います。数年間、SDN はしばしば OpenFlow だけに関連していました。今日、SDN はよりスマートで、よりダイナミックなネットワークアーキテクチャと見なされています。より多くのベンダーが関わるようになるにつれ、その定義は更に拡大し、その成長の見込みを定量的に評価することが難しくなるでしょう。"
活気あふれるOpenDaylight
要するに、SDN の有用性はとても顕著で、このようなメカニズムが失敗し、最終的に重要な足場を得ることは想像しにくい。コンセプトはまだいくらか萌芽的ではありますが、OpenFlow の傑出した貢献のおかげで、それは既に思考の域を脱し、実世界の展開に向かい始めています。
SDN の標準はここ数年で確立され、多くのベンダーがそれに基づいて優れた技術サポートソリューションを提供しています。もちろん、最後になりましたが、このようなコンセプトはベンダーがそれを買ってくれる場合にのみ真に成功します。結局のところ、もしネットワーク製品メーカーがシステムを手放さなければ、SDN は単にネットワークレイヤーとインターフェースすることはできません。
OpenDaylight は SDN 関連の開発において強力なプレイヤーとしての地位を確立しました。その最初のリリースは今年の12月9日に予定されており、多くの機能コンポーネントを伴う予定です。この相対的なリードタイムにより、OpenDaylight はタイムリーにこの開発の波に追いつくことができます。
多くの技術者がこの便利な新しいソリューションを試すチャンスに飛びついています。もちろん、これに疑問を抱く技術者が出てくることは避けられないかもしれません。
