完璧なネットワークを見つける：OpenFlowとすべてすべて

こんにちは読者の皆様、



この投稿では、クラウドインフラストラクチャに最適なネットワークソリューションの検索と、OpenFlowを使用することにした理由について説明します。

はじめに

クラウドの概念は、リソースの品質保証と相互分離という2つの抽象化と密接に関連しています。 これらの概念がクラウドソリューションのネットワークデバイスにどのように適用されるかを検討してください。 リソースの分離は 、次のことを意味します。

• なりすまし防止、
• プライベートネットワークセグメントの割り当て、
• パブリックセグメントをフィルタリングして、外部の影響を最小限に抑えます。

リソースの保証品質は 、一般的な意味でのQoSです。つまり、クラウドネットワーク内で必要な帯域幅と必要な応答を提供します。 次に、クラウドインフラストラクチャにおける上記の概念の実装の詳細な分析です。

トラフィック分離

• OpenVSwitchのiptables / ebtablesまたは静的ルールを使用したスプーフィング防止：最も安価なソリューションですが、実際には不便です-Linuxブリッジルールがlibvirtのnwfilterメカニズムを使用して作成され、仮想マシンの起動時に自動的に強化される場合、ovsの場合、開始時間を追跡してovsをチェックする必要がありますまたは、スイッチ内の対応するルールを更新します。 アドレスの追加または削除、または仮想マシンの移行は、どちらの場合も重要なタスクに変わり、オーケストレーションのロジックに移行します。 サービスを公開して使用するために、nwfilter [ 1 ]を使用しましたが、ソリューション全体の柔軟性が不十分なため、OpenFlow 1.0への切り替えを余儀なくされました。 また、ホストネットワークスタック（macvtap / vf）を回避するテクノロジーのネットリンクを使用して、発信トラフィックをフィルタリングするかなりエキゾチックな方法に言及する価値があります。これは、高い商業需要にもかかわらず、一度はカーネルに受け入れられませんでした。
  
  
• 仮想マシンインターフェイスからトラフィックトンネリングメカニズムのいずれかを使用して仮想マシンポートをポートレベルで移植する場合、ラックレベルスイッチ（ToRスイッチ）のルールを使用したスプーフィング防止（下図を参照）。 このようなソリューションの利点として、スイッチのロジックの焦点==コンピューティングノードのソフトウェアスイッチを「拡散」する必要がないことに注目できます。 1つのコンピューティングノードのマシン間のトラフィックルートは常にスイッチを通過するため、必ずしも便利ではない場合があります。
  
  
  
  

  ToRフィルタリング©networkheresy

  
  
  
• OpenFlowネットワークのフィールドをチェックするときのスプーフィング防止-物理および仮想のすべてのスイッチが、トラフィックフィールドのリダイレクトと変換に加えて、計算ノードのソフトウェアスイッチのレベルでクリアするコントローラーのグループに接続されている場合。 通常のスイッチ内でのデータグラムの送信から始まる絶対的にすべてのロジックがコントローラーに転送されるため、これは可能なオプションの中で最も複雑で柔軟です。 不完全または一貫性のないルールは、接続性の故障または分離の故障のいずれかにつながる可能性があります。そのため、NICE [ 2 ]のようなフレームワークを使用して、反応性（スイッチからの要求に応じて動的に設定）の割合が高いシステムをテストする必要があります
  
  
• ネットワークセグメントの選択は、大規模な同種構造で実践されるソリューションですが、仮想マシンのグループには、物理​​マシン（および物理スイッチのポート）または任意のタイプのカプセル化タグ（vlan / vxlan / gre）へのバインディングが割り当てられます。 フィルタリングの境界はL2セグメントのジャンクションにあります。つまり、サブネットまたはサブネットのセットがセグメントに割り当てられ、それらを置き換えることが不可能かどうかは、たとえばNovaハイブリッドドライバーを使用しないOpenStack Neutronのルーティングによって決定されます[ 3 ]。 このアプローチは、理論上の深い関心を引くものではありませんが、仮想化前の時代から受け継がれた幅広い実用的な普及率を持っています。
  
  

交通管理

ネットワークリンクを最大限に活用するようにルートを最適化する（言い換えると、相互作用するエンドポイントのすべてのペアの重み、つまりQoS優先度を考慮して、最小カット合計[ 4 ]の最大値を見つける）は、分散ネットワークで最も難しいタスクと見なされます。 この問題を解決するために設計されたIGPは一般に十分な柔軟性がありません。トラフィックは事前に割り当てられたQoSラベルに基づいてのみソートでき、動的な分析とトラフィックの再分配について考える必要はありません。 OpenFlowの場合、個々のトラフィック要素を分析する手段はプロトコルの不可欠な部分であるため、この問題を解決するのは非常に簡単です-個々のフロー[ 5、6 ]の正しく機能する分類子を構築するだけで十分です。 この場合のOpenFlowのもう1つの明確な利点は、転送戦略の集中計算で、IGP標準のいずれにも含まれていない多くの追加パラメーターを考慮することができることです。



異種コンテンツを含む小さなデータセンターのネットワークの設計（マシングループをラックに物理的にリンクせずに複数の小売ユーザーを同時に維持）は、既存のメカニズムの1つを使用して分散L2-over-L3ネットワーク（オーバーレイネットワーク）[ 7 ]を構築するタスクにつながります従来の方法では、1つのブロードキャストセグメントに数万台の仮想ホストを技術的に配置することは不可能です。 示された技術により、転送ロジックを「アンロード」できます。これは、機器がユーザーネットワークのプライベート（およびパブリック）セグメントの個別のアドレスではなく、ホストグループに対応するラベルで動作するためです。 低コストと比較的簡単な実装の背後に、少なくともネットワーク機器のメーカーと究極の非決定性へのリンクがあります-詳細を無視すると、すべてのオーバーレイプロトコルは別のラベル内でトレーニングされたスイッチを提供し、オーバーレイセグメント内のトラフィックを最適化する際に「アンティ」により困難を引き起こす可能性があります第3レベルのルーティングプロトコルとオーバーレイメカニズム。 OpenFlowを選択すると、すべてのトラフィック管理が1つのレベルの意思決定-ネットワークコントローラーに削減されます。 もちろん、オーバーレイまたはそれらに代わる独自のメカニズムは、スイッチアグリゲーター（以下の図のスパイン）のルールの量を減らす上で同じ役割を果たし、ToRスイッチ（リーフ）のトラフィック方向の最適化は、任意のメトリックセットに基づいて発生します。単純なバランシングから（例えば、ECMPで）。

2レベルのスパインリーフ

Openflow

最初の工業的に利用可能なバージョン1.0のOpenFlow標準は、1年以上前に鉄製スイッチの一部として利用可能になりましたが、このバージョンには、大量採用を妨げるいくつかのアーキテクチャ上の制限があり、最も問題のあるものは、処理のための複数のシーケンシャルテーブルの欠如、つまり1つのルールが対応していたことです追加の偶然の一致を考慮せずに、相互作用するエンドポイントの正確に1つのペア[ 8 ]。 OpenFlow 1.0をプロアクティブに（つまり、必要なすべてのルールを事前に作成して）使用すると、下の図に示すように、相互作用するホストの数からルールの数が2次的に増加します。

1.0と1.3の比較©Broadcom Corp

状況から抜け出すための部分的な方法は、学習スイッチメカニズムを使用することです。つまり、スイッチ転送テーブルに既に配置されているルールと一致しない場合、および特定のTTLがスイッチから削除された後にルールが要求されるたびに、OpenFlowスイッチリアクティブ操作が使用されます。 削除戦略は、「ハード」-ルール設定後の指定期間後の削除、または「ソフト」-特定のストリームの「内部」で一定期間アクティビティがない場合にのみ削除することができます。 OFの使用を開始した時点では、オープンソフトウェアコントローラーはいずれも新しいバージョンをサポートしていませんでしたが、前述の制御アプローチの柔軟性の追求は1.0標準に焦点を合わせていました。 学習スイッチモデルは、かなりの量のワークロードで正当化されます。スイッチレベルで毎秒数百および数千の一意の要求を生成するカウンターなどのアプリケーションのみが乗り越えられない障害になります。また、迅速なスプーフィング攻撃の対象となります-一意のIP / MAC識別子を持つパケットを生成するクライアント、少なくとも、計算ノードレベルのスイッチを動作不能にすることができます。PACKET_IN（コントローラーのストリームを処理するためのメッセージ）を制限する前に気をつけなければ、セグメント全体 NTネットワーク。



ネットワークのすべての要素（OpenVSwitchに基づく）が標準1.3を使用するのに十分な更新を受け取った後、すぐに切り替えてコントローラーをアンロードし、転送パフォーマンス（平均ppsによる再計算）を1.5から2桁向上させました圧倒的な量のトラフィックに対してプロアクティブなフローに切り替えることを考慮してください。 分散トラフィック分析の必要性（従来のファイアウォールを備えた専用の分類ノードを介してボリューム全体をポンピングすることなく）は、リアクティブフローの余地を残します。

プレゼントについて

手頃な価格のToRホワイトボックスネットワーク機器のメーカーによる最新のOpenFlow標準のサポート[ 9 ]は、現在、Pica8スイッチのWindriver（Intel）、Cumulus（Dell）およびDebianに基づくソリューションに限定されています。独自の互換性のない拡張機能/メカニズム。 歴史的な理由から、Pica8をToRスイッチとして使用しますが、GPLディストリビューションを有料サブスクリプションに移行したメーカーのポリシーにより、潜在的な相互作用の領域が非常に制限されます。 現在、オープンなIntel ONSまたはDellプラットフォーム（ Trident IIに基づく）は、非常に手頃な価格（4 * 40G + 48 * 10Gで<10,000ドル）で、1〜6 Tbの1つの産業ラックの規模で数万台の仮想マシンのトラフィックを管理できます。 OpenFlow（1.3+）を使用したメモリ。



振り返ってみると、このような開発の追加の利点-ソフトウェア定義のサブネットの問題への没入と独自のエコシステムの拡大に注目します。 トラフィック管理にOpenFlowを使用し、データ可用性を高めるためにCephソフトウェアストレージを使用することで、 ソフトウェア定義のデータセンターの実装として自分自身を宣言することができますが、理想への道はまだまだたくさんあります。



ご清聴ありがとうございました！

参照資料

[1]。 libvirt-nwfilter

[2]。 いいね

[3]。 Openstack Neutron

[4]。 最大流量/最小カット

[5]。 B4-OpenFlow上のGoogle WANネットワーク

[6]。 QoS指向のTEアルゴリズムの1つの詳細分析

[7]。 オーバーレイネットワークに関する良い記事

[8]。 OF：1.0対1.3のテーブルマッチ

[9]。 ホワイトボックススイッチが適している理由