スライド定義からソフトウェア定義ネットワーキングへ。 パート1

私たちはそれぞれ、Software Defined Networking（SDN）の概念について聞いています。 ただし、継続的な開発と多くの重要な変更にもかかわらず、この概念は、実際にはスライド定義レベルのまま、つまりベンダーおよびインテグレーターのプレゼンテーションでの投機的な構成の形で、商用製品の形で具体化されていません。 これに照らして、近年のSDNのトピックに関する過度に活発な議論が、市場で完全に機能するソリューションの欠如と相まって、拒絶ではないにしても、正確に、ITコミュニティ側のこのテクノロジーの重要な態度につながったのは驚くことではありません。 この記事では、この懐疑論を払拭し、SDNの古典的な基準を満たし、同時に完全な「箱入り」ソリューションであるネットワークファクトリについてお話したいと思います。



この記事は、ソリューションのアーキテクチャ、その機能、およびテストの個人的な印象について説明することを目的としています。 素材を準備する過程で、データセンターを構築するためにSDNがどれほどシンプルで便利なのかを示したかったので、意識的にテクノロジーに没頭することを避け、このソリューションがもたらす可能性にさらに焦点を当てます。 大量の資料があるため、一般的な説明とアーキテクチャ、機能、統合機能の3つの部分に分けました。

参加する代わりに

分散した企業ネットワークやキャンパスネットワークを構築するための確立されたテクノロジーとは異なり、データセンターネットワークを編成するアプローチは常に進化しています。 これは、アプリケーションおよび関連システムからの要件の大幅な増加に一部起因しています。 そのため、アプリケーションが機能するには、より多くの帯域幅が必要になり、遅延予測可能性の要件とさまざまなトラフィック伝送パラメーターが厳しくなり、適用されるメカニズムとトポロジーのレビューにつながります。 隣接するシステム（特に、仮想化およびオーケストレーションシステム）は、ネットワークで発生するプロセスに影響を与えることができる、より広範な統合および自動化機能を必要とします。



Software Defined Networkingの概念は、ネットワークの管理と制御の単一ポイントを使用して、統合と自動化に関する問題のほとんどを解決するように設計されています。 同じ原則は、ベンダーへのユーザーの依存度を大幅に減らすのに役立つはずです-これまで、ネットワーク化された世界では、サードパーティ企業によって製造された標準要素に基づいて機器が作成されているという事実にもかかわらず、メーカーは通常、機器のソフトウェアの唯一のサプライヤーです。



次に、特殊なマイクロチップ（ASIC）およびハードウェアメーカーの市場の発展により、独自のソフトウェアを持たないスイッチ（いわゆるBMスイッチ ）が市場に登場しました。このため、基本機能を提供するオペレーティングシステムは他社によって開発されています。 このようなスイッチのコストは、対応するブランドのスイッチよりもはるかに低く、クライアントはオペレーティングシステムを選択できます。 しかし、残念ながら、そのようなSDN製品の圧倒的多数は、利用可能な部品（スイッチ、コントローラー、ソフトウェア）からソリューションを独立して組み立てることを提供する一種のデザイナーです。 おそらく、このようなキットの使用は、技術スペシャリストの重要なスタッフを抱える企業には受け入れられますが、ほとんどの組織にとって、このアプローチは不便です。



一方、当社は最近、Big Switch NetworksからBig Cloud Fabric（BCF）データセンターネットワークを構築するソリューションをテストすることに成功しました。 Big Cloud Fabricは、古典的なSDNソリューションです。ネットワークファクトリのハードウェアインフラストラクチャとしてBMスイッチを使用し、別のコントローラーで実行される集中コントロールプレーンを使用します。 コントローラーには、トポロジの計算、ルーティング情報の処理、接続されたホストの調査、およびすべてのシステム機能の構成と管理の機能があります。 コントローラの結果はスイッチ間で同期され、ASICハードウェアテーブルに直接入力されます。 また、BCFは、ユーザーがコンポーネントを統合するための長くて難しいプロセスをとる必要のない完全な「ボックス化」ソリューションです。





このような非典型的なアプローチに基づいてソリューションがどのように機能するか、またユーザーにどのような機会を提供できるかを詳しく見てみましょう。

Big Cloud Fabricアーキテクチャ

Big Cloud Fabricとは何ですか？ 定義を簡単に定式化しようとする場合、以下が最も適切です：BCFは、単一の制御下でBMスイッチを使用でき、管理、分析、および統合のための単一の対話インターフェースを持つデータセンターデータネットワークです。



BCFは、トポロジSpineとLeafに基づいて構築されたイーサネットスイッチのネットワークに基づいており、現在データセンターネットワークの構築で最も人気があります。 さらに、任意の2つのリーフスイッチをMC-LAGペア （BCF用語のリーフグループ）に組み合わせることができます。





ただし、他のソリューションとは異なり、BCFでは、ネットワークオペレーティングシステムのインストールをサポートするさまざまなメーカーのスイッチを使用できます。 技術的な観点から見ると、これらのスイッチは通常のブランドモデルと変わりません。 CPU、メモリ、市販のASICなど、同じハードウェアコンポーネントを使用します。 ただし、BMスイッチのメーカーは、オペレーティングシステムの代わりに、互換性のあるネットワークオペレーティングシステムのダウンロードとインストールを提供する小さなシステムユーティリティであるONIEブートローダーをインストールします。 このアプローチは、使用するソフトウェアに関係なくハードウェアプラットフォームを選択できるため、ネットワークの構築に大きな柔軟性を提供します。





工場は、ASIC Broadcom Trident II / II +およびTomahawkで構築されたすべてのスイッチをサポートできます。これは、現在生産されているデータセンタースイッチの大部分を占めています（クラシックおよびベアメタル/ホワイトボックスの両方）。 サポートされるモデルの公式リストには、さまざまなDellネットワークおよびAccton / Edge-Coreスイッチが含まれています。 これは、Big Cloud Fabricが相互に独立して動作するスイッチのセットではなく、集中管理と制御を備えた単一の工場であるという事実によるものです。 そのため、すべてのコンポーネントのテスト済みの互換性がネットワーク全体の稼働時間にとって非常に重要です。 ただし、Big Switch Networksは、サポートされているスイッチのリストを定期的に補充しています。



スイッチ自体は、それらを管理できるオペレーティングシステムがなければ役に立ちません。 BCFの場合、すべての制御、制御、およびサードパーティシステムとの統合は、特別なデバイス（ファクトリーコントローラー）に転送されます。 そのタスクには、すべての管理および制御機能が含まれます-工場へのアクセスインターフェイスの提供、接続されたホストに関する情報の収集、トポロジの計算、スイッチ間のハードウェアテーブルのプログラミング情報の同期など。 軽量のSwitch Light OSオペレーティングシステムがスイッチにインストールされます。これは、コントローラーからの指示を受け取り、スイッチのASICで直接プログラムし、「生の」統計データを収集して分析のためにコントローラーに送信するように設計されています。 同時に、ネットワーク管理者はスイッチにOSを手動でインストールする必要はありません-BCFはゼロタッチプロビジョニングメカニズムをサポートします。これにより、スイッチは制御ネットワークに接続した後、コントローラーによって自動的に決定され、OSと構成テンプレートがインストールされます。 スイッチとコントローラー間の情報は、高度に変更されたOpenFlowプロトコルを介して送信されます。





モジュラースイッチとの明らかな類似性を引き出す場合、スイッチはラインカード（リーフ）とスイッチングモジュール（スパイン）であり、コントローラーは地理的に分散した大規模なスイッチのスーパーバイザーです。 フォールトトレランスを確保するために、工場は少なくとも2つのノードのクラスターで管理され、コントローラーとスイッチ間の相互作用ネットワークは、帯域外の独立したインフラストラクチャとして実装されます。



Big Cloud Fabricには、完全に物理的な工場（P Fabric）とハイブリッド（P + V Fabric）の2つのバージョンがあります。 後者のオプションでは、KVM仮想環境のOpen vSwitchソフトウェアスイッチにSwitch Light VXソフトウェアエージェント（本質的に同じSwitch Light OS）をインストールできます。 Switch Light VXはユーザー環境で動作し、ハイパーバイザーのコアには影響しません。 彼のタスクには、トラフィック転送ポリシーをファクトリコントローラーと同期し、それらをOpen vSwitchに実装することが含まれます。 実際、BMスイッチでは、Swith Light OSはASICの「筋肉」に依存し、仮想環境ではCPUとOpen vSwitchに依存しています。 したがって、仮想環境にエージェントが存在するため、トラフィック転送が最適化されるだけでなく（仮想マシン間の切り替えとルーティングは、外部デバイスに転送せずに物理ホスト上で実行されます）、仮想環境でポリシーを適用して分析を収集することもできます。



現在、P + V Fabricの実装はOpenStack / KVMアーキテクチャでのみ可能です。 他のハイパーバイザーについては、P Fabricが利用可能です。 ただし、VMware vCenter / vSphere（以下で説明）との統合機能は、これらの不便を完全に補います。





Big Cloud Fabricのブロック図（クリック可能な画像）



他のメーカーの類似製品とは対照的に、コントローラーは工場のスイッチを完全に制御し、トポロジー計算、ルーティングプロトコルの近接性と外部デバイスの関係を実行し、ハードウェアテーブルの状態を同期する要素であることに再度注意してください。 これは、構成データのみを収集し、それらに基づいてスイッチを構成する管理システムではありません。 これは、定期的に（または要求に応じて）デバイスに問い合わせて、標準プロトコルを使用して提供できる情報のみを収集する監視システムではありません。 これは実際のコントロールプレーンファクトリです。コントローラは、自分で作成したネットワークの全体像を把握しています。 スイッチ上のOSを介して、彼はASICに直接アクセスできるため、BCFの反応速度は速く、分析は競合製品よりも桁違いに詳細です。



工場のインフラストラクチャにおけるコントローラーのこのような重要な役割に関連して、合理的な疑問が生じます。すべてのクラスター要素が故障し、工場にコントロールプレーンがない場合、どうなりますか？ 結局のところ、悪いことは何も起こりません。 コントローラーなし（ヘッドレスモード）のままにすると、工場は通常モードでの作業を継続し、既に調査済みのホストのトラフィックや、ある種の障害（たとえば、1つのラック内のリンク障害（MC-LAGペア））を正しく処理します。 もちろん、このモードは新しい設定に制限を課し、新しく接続されたホストを調査し、ファクトリトポロジを変更します。 それらは処理されません。 一部にはこれは欠陥のように思えるかもしれませんが、モジュラースイッチのすべてのスーパーバイザに障害が発生するとどうなるか想像してみましょう。 おそらく彼はただ止まるでしょう。