ソフトウェアで計画されたネットワークは昔からありますが、SDNはそれらとどう違うのですか？
分散ルーティングアルゴリズムや管理プロトコルのようなソフトウェアが長い間フォワーディングパスを決定し、ネットワークデバイスのパラメータを設定してきたのは事実です。にもかかわらず、これらのツールは各ベンダーのネットワーキングのエコシステムと特許から隔離されてきました。SDN にはこれを変えることができるいくつかの重要なアイデアがあります: 集中制御、プログラミングインターフェース、オーケストレーション/オートメーションツールとの統合です。
なぜ SDN は現在使われている従来のネットワークより優れているのですか？
SDN があなたのネットワークをどの程度強化するかは、あなたが解決しようとしている問題に大きく依存します。適切な場所に適切な SDN ソリューションをデプロイすることで、運用プロセスをよりスムーズにしたり、ヒューマンエラーを減らしたり、企業独自のメトリクスが必要とする型にはまらない方法でトラフィックを転送したりすることができます。要するに、より多くの効率性と柔軟性を提供することができるのです。
一般的な使用例とは？
今日、企業における SDN の2つの一般的な使用例があります。一つ目はネットワークデータの収集とネットワークの可視化です。このユースケースでは、興味のあるネットワークトラフィックはソフトウェアポリシーによって定義された通りにコレクタにコピーされます。SDN コントローラはネットワークインフラ全体に仮想 NIC を挿入し、どこからでも解析エンジンの場所にトラフィックのコピーを送ることができます。
2つ目のケースは、革新的なフォワーディングです。ここでは、トラフィックは設計されたネットワーク経路を経由して転送されます。この設計されたネットワークパスは、OSPF、BGP、MPLSなどの従来の転送メカニズムとは異なります。一般的なアプリケーションは、遅延やジッターの影響を受けやすいトラフィックの処理に特化したものです。セキュリティを向上させるために、選択したトラフィックに監視装置を通過させたり、コストに基づいて経路を選択することもできます。また、コストに基づいて経路を選択することもできます。期間やリンクの利用率に基づいて、企業にとってより安価な経路でトラフィックをルーティングできます。
なぜオープンネットワーキング財団は、IETFやIEEEと違ってクローズドな運営をしているのですか？
ONF は OpenFlow プロトコルの迅速な開発を促進するために設立されました。これはベンダーに依存しないプロトコルであり、SDN コントローラが様々なフローマッチング条件と手段を使用するネットワークスイッチのフォワーディングテーブルを準備するために使用されます。そのスピードは特定の結果に既得権を持つ少数のメンバーによってコントロールされるでしょう。もしそれが IETF や IEEE のようなオープンな方法で運営されるなら、開発プロセスは全てのメンバーをカバーするために遅くなるに違いありません。
ONFのアジェンダを特定のノードで公開し、より大きなネットワーキング・コミュニティがOpenFlow仕様の議論を見学できるようにしようという議論がありました。
OpenFlowはネットワークを通じてトラフィックを転送する新しい方法になり得るでしょうか？
OpenFlowの将来は現在のところ不透明です。必要な処理をサーバベースの x86 コンピューティングパワーに依存することで、OF は仮想レイヤネットワークのエッジで動作するソフトスイッチで有用であることが証明されています。それにもかかわらず、OF が従来のネットワーク・ハードウェア・スイッチに導入される場合、OF の利点は、スイッチ・チップの性能と、ユースケースにおける大規模な OpenFlow 操作を処理するチップの能力に依存します。
レガシーフォワーディングが最終的に OpenFlow に取って代わられるもう一つの根拠は、OF は Cisco、Juniper、Broadcom のような ASIC（特定用途向け集積回路）設計会社のチップで利用可能なハードウェア機能の全範囲を複製する必要がないということです。これらのベンダーは、フォワーディングのオーダーやポリシーを満たすための補助的なものとして OF をサポートするかもしれませんが、それにもかかわらず、自社のハードウェアの性能をフルに活用できるとして、自社の API を大々的に宣伝するでしょう。
ストリームエントリの数に制限があり、コントローラへの転送に待ち時間が発生するため、OFのスケーラビリティに疑問を呈する声もあります。これは本当ですか？
OF付きネットワーク・スイッチの最大ストリーム・エントリーが10K未満であることは事実です。この上限は、ユースケースとネットワーク全体の設計に依存します。ベンダーは、OFが（コアではなく）ネットワークのエッジで使用される場合、数千のストリームエントリが上限に達する可能性は低く、簡素化されたコアが成功する可能性があると指摘しています。
OpenFlowスイッチのフローエントリがフローにマッチしない場合、フローをコントローラに迂回させる必要があります。これには数十ミリ秒から数百ミリ秒の遅延が発生します。さらに、OpenFlow スイッチの CPU はフォワーディング・アウトの処理だけは非常に高速ですが、通常、フォワーディング・アウトのオペレーションは、1 秒あたり最大 1000 に制限されています。これは、テラバイトレベルのワイヤスピードで L2 や L3 トラフィックを転送することに慣れているネットワーク設計者にとっては遅く感じるかもしれませんが、ベンダーは、典型的な展開では、コントローラがエンドポイントを知っているため、フローテーブルをフローエントリで事前に埋めることができると指摘しています。これにより、イグレスの必要性を最小限に抑えることができます。
SDNコントローラは単一障害点ではないのですか？
SDN のコンセプトの一つは集中コントローラがネットワーク全体のトポロジーを知っていて、それ故に分散制御レイヤではできない複数の方法でネットワークを置き換えることができるということです。ベンダはコントローラのミッションクリティカルな役割を認識しており、しばしばアグリゲーションツールのように動作する分散アプリケーションとして、あるいは仮想レイヤの高い信頼性を利用できる仮想マシンとして使用しています。さらに、コントローラに障害が発生した場合、ネットワークも一緒に障害が発生するような状況にはなりません。ベンダーは多くのアーキテクチャを設計するでしょうが、コントローラが存在しなくてもネットワークはトラフィックを転送し続けると考えるのが妥当です。
既存のネットワークと一緒にSDNを導入することはできますか？
はい。スケールアウト環境のデプロイメントで一般的なトポロジーは "SDN サイロ" です。このサイロでは SDN ドメインのトラフィックはゲートウェイデバイスを通ってレガシーネットワークに流れます。もう一つのトポロジーはハイブリッドスイッチングで、2つのドメイン間にポートを割り当てることでOpenFlowとレガシーネットワークスイッチングの両方の機会を扱うことができます。異なるベンダーは異なるハイブリッド機能を提供します。
マルチとは何ですか？どうしてこんなに種類があるの？
オーバーレイは、仮想ネットワークコンテナを作成するために使用されます。VXLAN（仮想拡張ローカル・エリア・ネットワーク）、汎用ルーティング・カプセル化を使用したネットワーク仮想化、ステートレス・トランスポート・トンネルなどの技術がほぼ同時に登場しています。異なるベンダーが異なるテクノロジーを支配しています。
一言で言えば、Cisco は VXLAN を推し、Microsoft は NVGRE を推し、Nicira（現在は VMware に買収された）は STT をサポートしています。これらのオーバーレイは、それぞれ似たような特徴がありますが、細部では互いに似ているようで異なっています。時間の経過とともに、VXLAN は一部の業界大手の支持を得ましたが、NVGRE と NVGRE は決定的に見捨てられたわけではなく、どちらも現在も支持者がいます。さらに、IETFのNVO3ワーキンググループは、既存のものに似たカプセル化タイプを持つ他のオーバーレイに取り組んでいます。
なぜこれほど多くの種類のコントローラーがあるのですか？
SDN テクノロジーをマーケティングし販売する初期のベンダーは、グループに対する全体的なソリューションの一部としてコントローラを含めなければなりませんでした。SDN コントローラの標準はまだありません。そのため、各ベンダーはそれぞれのターゲット市場のニーズを満たすコントローラを発表しています。
業界に受け入れられる SDN コントローラの標準を作るのは悪いことですか？
オープンソース SDN にコードを提供する業界内のベンダのコンソーシアムである OpenDaylight プロジェクトの設立によって、業界は同じように考えているようです。SDN コントローラの標準がどのようにベンダの製品に浸透し、SDN の消費者にとってどのような意味を持つかは時間が解決してくれるでしょう。
ネットワーク・エンジニアはプログラマーでなければならないのですか？
スクリプティングとプログラミングに精通したネットワークエンジニアは SDN テクノロジーを活用できるようになるでしょう。そうする必要があるのでしょうか？それはまだわかりません。私が見るシナリオはベンダーが豊富なネットワーク機能を持つソフトウェアを企業に提供することです。一部のエンジニアはネットワークを設定するためにこれらのソフトウェアインターフェイスを使い、彼らの期待に応えるネットワーク機能に満足するでしょう。別のエンジニアのサブセットは、ベンダーが提供するソフトウェアを使用し、ビジネスで必要とされる独自のネットワーク・アプリケーションを作成するために使用する言語に習熟します。このようなネットワーク・エンジニアは、徐々にプログラミング・スキルを習得するにつれて、ネットワーク・インフラストラクチャをより効率的に監視・維持する能力を維持するようになります。
SDN テクノロジーを評価する際に考慮すべき点は何ですか？
理解すべき最も重要なことの一つは、全ての SDN ソリューションが同じ問題を解決するわけではないということです。さらに、エンドユーザは異なる SDN テクノロジーに異なる期待を持っています。あるソリューションは使いやすいソリューションを提供することでネットワークと運用の複雑さをフィルタリングすることを意図していますが、他のソリューションはユーザが独自のアプリケーションを作成できるように、より多くのツールを備えたツールキットを提供しています。従って、解決しようとしている問題がどのレベルの技術なのかを把握することが重要です。ベンダーにニーズを詳しく伝えれば伝えるほど、ベンダーのソリューションがどのようにニーズを満たすかが明確になります。
SDN が newリスクをもたらすと言うのは難しいですが、プログラム可能なインターフェースを通して公開されるネットワークデバイスには管理リスクがあることが示されています。つまり、SNMP はプログラマブル API にほぼ類似していますが、詳細なリスク軽減戦略を持っています。この意味で、SDN は新しいリスクを導入しません。確かに SDN はリスクを導入しますが、IT は既にアクセス制御、信頼、暗号化、ディープパケットインスペクション等でリスクを軽減しています。
SDN の擁護者は集中制御のセキュリティ上の利点はネットワークの設定に必要な人の数を減らすことだと指摘しています。ヒューマンエラーは IT インフラにとって最大のセキュリティリスクであり、SDN は実際にセキュリティ資産になり得ます。
