メインコンテンツまでスキップ

3. VXLAN Problem Statement (VXLAN問題記述)

本セクションでは、VXLANが対処することを意図している領域についてさらに詳しく説明します。データセンター内のネットワークインフラストラクチャとそれに関連する問題に焦点を当てています。

3.1. Limitations Imposed by Spanning Tree and VLAN Ranges (スパニングツリーとVLAN範囲による制限)​

現在のレイヤ2ネットワークは、重複パスによるネットワーク内のループを回避するために、IEEE 802.1D スパニングツリープロトコル (Spanning Tree Protocol, STP) [802.1D] を使用しています。STPは、フレームの複製とループを回避するためにリンクの使用をブロックします。一部のデータセンターオペレーターは、STPを使用すると実際に使用できるよりも多くのポート数とリンク数に対して料金を支払っていることになるため、これを一般的にレイヤ2ネットワークの問題と見なしています。さらに、マルチパスによる回復力はSTPモデルでは利用できません。TRILL [RFC6325] やSPB [802.1aq] などの新しいイニシアチブは、マルチパスを支援し、STPの問題の一部を克服するために提案されています。ラック内のサーバーを同じレイヤ3ネットワーク上に構成し、ラック内およびラック間の両方でレイヤ3でスイッチングを行うことによっても、STP制限を回避できます。ただし、これはVM間通信のレイヤ2モデルと互換性がありません。

レイヤ2データセンターネットワークの重要な特性は、ブロードキャスト分離を提供するために仮想LAN (VLAN) を使用することです。イーサネットデータフレームでは12ビットのVLAN IDが使用され、より大きなレイヤ2ネットワークを複数のブロードキャストドメインに分割します。これは、4094未満のVLANを必要とする多くのデータセンターでうまく機能してきました。仮想化の採用が増加するにつれて、この上限は圧力を受けています。さらに、STPのため、いくつかのデータセンターでは使用できるVLANの数を制限しています。また、セクション3.2で説明されているように、マルチテナント環境の要件により、より大きなVLAN制限の必要性が加速しています。

3.2. Multi-tenant Environments (マルチテナント環境)​

クラウドコンピューティングには、マルチテナント環境のためのオンデマンド弾性リソースプロビジョニングが含まれます。クラウドコンピューティングの最も一般的な例は、クラウドサービスプロバイダーが同じ物理インフラストラクチャ上で複数の顧客/テナントにこれらの弾性サービスを提供するパブリッククラウドです。

テナントによるネットワークトラフィックの分離は、レイヤ2またはレイヤ3ネットワークを介して行うことができます。レイヤ2ネットワークの場合、VLANはトラフィックを分離するためによく使用されます。たとえば、テナントは独自のVLANによって識別できます。クラウドプロバイダーがサービスを提供する可能性のあるテナントの数が多いため、4094というVLAN制限は不十分であることがよくあります。さらに、テナントごとに複数のVLANが必要になることが多く、これが問題を悪化させています。

関連するユースケースは、クロスポッド拡張です。ポッドは通常、関連するネットワークおよびストレージ接続を持つ1つ以上のサーバーラックで構成されます。テナントはポッドから始まる可能性があり、拡張により他のポッド上のサーバー/VMが必要になる場合があります。特に、他のポッド上のテナントがすべてのリソースを完全に利用していない場合です。このユースケースでは、個々のサーバー/VMを接続する「拡張された」レイヤ2環境が必要です。

レイヤ3ネットワークも、マルチテナンシーの包括的なソリューションではありません。2つのテナントがネットワーク内で同じレイヤ3アドレスセットを使用する可能性があり、これによりクラウドプロバイダーは他の形式で分離を提供する必要があります。さらに、すべてのテナントにIPの使用を要求すると、VM間通信のために直接レイヤ2または非IPレイヤ3プロトコルに依存している顧客が除外されます。

3.3. Inadequate Table Sizes at ToR Switch (ToRスイッチでの不十分なテーブルサイズ)​

今日の仮想化環境は、サーバーに接続するトップオブラック (Top-of-Rack, ToR) スイッチのMACアドレステーブルに追加の要求を課します。サーバーリンクごとに1つのMACアドレスだけでなく、ToRは個々のVMのMACアドレス (サーバーごとに数百に及ぶ可能性がある) を学習する必要があります。これは、VMから物理ネットワークの残りの部分への/からのトラフィックがサーバーとスイッチ間のリンクを通過するために必要です。典型的なToRスイッチは、サーバー向けポートの数に応じて24または48台のサーバーに接続できます。データセンターは複数のラックで構成される可能性があるため、各ToRスイッチは、さまざまな物理サーバー全体で通信するVMのアドレステーブルを維持する必要があります。これにより、非仮想化環境と比較して、テーブル容量に対するはるかに大きな需要が生じます。

テーブルがオーバーフローすると、スイッチはアイドルエントリがエージアウトするまで新しいアドレスの学習を停止する可能性があり、その後の未知の宛先フレームの大量のフラッディングにつながります。

に最終更新