大規模SDNクラウドコンピューティングデータセンターネットワークのアーキテクチャ設計

この論文ではまず、大規模な SDN データセンター ネットワーキングで発生する問題を分析します。一方、アンダーレイ基盤ネットワークの規模は、機器の実際の転送能力とポート密度によって制限され、単一のスパインリーフ ファブリック アーキテクチャでは大規模ネットワークのニーズを満たすことができません。一方、SDN テクノロジーの実装ソリューションに関しては、Openstack と SDN コントローラーには管理および制御機能の制限があります。

[[259421]]

この記事では、マルチポッド大規模データセンターのアンダーレイ ネットワーキングとルーティング計画の技術的な詳細と、クロスポッド相互接続のための SDN テクノロジ実装ソリューションについて説明します。この記事では、ネットワーク サービス トラフィック モデルの実装と組み合わせて、大規模 SDN データ センターのネットワーク アーキテクチャについて説明します。

1. 大規模SDNデータセンターネットワークにおける解決すべき課題の分析

大規模な SDN データ センター ネットワーキングでは、ホスティングとオーケストレーション用のリソース プールとして数万台のサーバーを使用する必要があります。アンダーレイ ネットワーキングと SDN ソリューションの実装を考慮すると、対処する必要がある主な問題が 3 つあります。

（１）データセンターのアンダーレイネットワーク層。データセンター スイッチの処理能力と転送能力はチップの継続的なアップグレードにより大幅に向上しましたが、データセンター スイッチの現在のポート能力に基づき、各コンピュータ ルームの実際のキャビネット数とコンピュータ ルーム間の配線の難しさを考慮すると、単一のスパイン リーフ 2 層アーキテクチャ ネットワークでは、数万台のサーバーの搬送ニーズを満たすことはできません。

たとえば、データ センター ネットワークでは、業界の現在の主流メーカーの成熟した 16 スロット コア スイッチ デバイスがスパインとして選択されます。 100G ボード カードのポート密度は 20/ボード、40G ボード カードのポート密度は 30/ボードです。 48 個の 10G ポートと 6 個の 40G ポートで構成されたアクセス スイッチがリーフとして選択されます。 LeafとSpineは完全に相互接続されており、Spineコアの数は6で完全に構成されており、各コアスイッチには外部ファイアウォール、プライベートネットワーク、専用線ルーティングデバイスなどに接続するための100Gボードが2つ装備されています。帯域幅収束比が1：1を満たす条件下では、単一のSpine-Leafアーキテクチャは最大5,760台のサーバーをサポートできると計算されており、数万台のサーバーの搬送要件を満たすことはできません。

（２）SDNコントローラの管理規模及び範囲SDN コントローラが VSW またはハードウェア スイッチを管理する場合、TCP の長い接続が有効になり、CPU メモリ リソースが占有されます。管理対象デバイスの数が多すぎると、SDN コントローラーのリソースが大幅に消費され、コントローラーのパフォーマンスが低下します。これは、SDN コントローラの管理規模を制限する主な要因です。 SDN コントローラの管理範囲は、主にコントローラと管理対象デバイス間のネットワーク遅延によって制限されます。したがって、SDN コントローラーは、長距離のリモート管理ではなく、ローカルに展開することをお勧めします。現在、主流の機器メーカーは、3 台のマシンの SDN コントローラ クラスターで 2,000 台の VSW または 1,000 台のハードウェア SDN スイッチを管理できます。

（３）クラウドオペレーティングシステムOpenstackの管理機能Openstack は集中型のメッセージ処理メカニズムです。すべての対話型操作は命令レベルで分割されます。ただし、命令の同時処理能力は低く、主に単一プロセスキュー方式で実行されます。たとえば、リソース プールで 100 台の仮想マシンが同時に動作するシナリオでは、命令を分割して対話型操作を実行すると、同時命令処理能力が低いため、多数の分割命令が実行のためにキューに入れられる必要があります。このとき、Openstack システムのインタラクティブな操作応答効率と適時性が低下し、ユーザーの実際の認識に影響を与えます。

セル テクノロジーにより、Openstack プラットフォームのメッセージ処理効率が大幅に向上します。 Nova は複数の Nova 処理ノードに拡張できます。各ノードには独立したデータベースがあり、データベースの同期を使用して複数の nova ノードの共同作業と分散作業を実現します。ただし、Openstack システムのパフォーマンスは、企業の実際の研究開発能力と密接に関係しています。現在、オープンソースの Openstack をベースに開発された主流のメーカー製品は、仮想化ホスト 500 台 (VM 5,000 台) またはベアメタル サーバー 3,000 台の管理容量を備えています。

2. 大規模SDNデータセンター向けマルチポッドネットワークアーキテクチャ

単一の Spine-Leaf 構造の Underaly ネットワーク アクセス容量、Openstack プラットフォームの管理機能、および SDN コントローラーの制御範囲と規模の制限により、大規模な SDN データ センターでネットワークを構築する場合、展開のために複数の個別の Spine-Leaf モジュールに分解する必要があります。モジュールは、SDN-DCI テクノロジーの助けを借りて統合アプリケーション層を通じて連携し、データセンター リソース プール全体の統合管理とオーケストレーションを実現します。個々のスパインリーフ モジュールはそれぞれ独立したファブリックであり、POD (Point of Delivery) とも呼ばれます。

POD 内のネットワークは標準の SDN データセンター アーキテクチャを採用しており、各 POD には独自の Openstack クラウド オペレーティング システムと SDN コントローラーが備わっています。主流メーカーの Openstack クラウド オペレーティング システム製品のパフォーマンス指標によると、POD 内のベア メタル サーバー シナリオでサポートされるサーバーの数は 3,000 台に制限され、仮想化サーバー シナリオでサポートされるサーバー ホストの数は 500 台に制限されています。同時に、主流メーカーの SDN コントローラーのパフォーマンスに基づいて、POD 内のハードウェア スイッチの数は 1,000 台以下に、VSW の数は 2,000 台以下に制限されています。

複数のポッドを備えた大規模な SDN データ センター ネットワーキングでは、ポッド内のアンダーレイ ネットワーキングは標準のスパイン リーフ アーキテクチャです。 POD 内の SDN-GW は、Spine と一緒にインストールすることも、Spine と並行して展開することもできます。ファイアウォールと負荷分散デバイスは、SDN-GW と並行して導入できます。

現在、SDN-GW は、SDN コントローラの統合管理を容易にするために、主に 2 つのスタックに導入されています。したがって、POD 規模が大きく、2 つ以上のスパインが必要な場合は、SDN-GW とスパインを一緒に設定することは推奨されません。 SDN-GW は、サイドマウントデバイスとして別途導入する必要があります。

POD 間のトラフィック相互接続を実現するために、POD 間で東西トラフィックを伝送する東西トラフィック集約コア スイッチ Core-Spine が設定されます。 POD 内部から外部ネットワークへの相互アクセスを実現するために、南北トラフィックを伝送する南北トラフィック集約コア スイッチ Out-Spine が設定されます。東西トラフィック集約コアスイッチと南北トラフィック集約コアスイッチの数は、実際の POD 規模、POD 数、ネットワーク収束率の要件に基づいて柔軟に計算できます。 POD 内のスパインと POD 間の集約コア スイッチは、通常、コンピュータ ルーム間で相互接続されます。リンクの使用率を向上させるには、相互接続に 100G 光モジュールを使用する必要があります。

ポッド間の東西トラフィックが大きくなることが計画されている場合は、ポッド内のスパインを東西集約スイッチに直接接続することをお勧めします。現時点でのトラフィック モデルでは、ポッド間トラフィックは POD 内のスパインから SDN-GW に送られます。 SDN-GW は元の VXLAN カプセル化を解凍し、ポッド間トラフィックを相互接続されたさまざまな VNI にインポートしてから、それをスパインに送り返します。スパインはそれを東西集約スイッチに送信します。このトラフィック モデルでは、同じサービス トラフィックが POD 内のスパインを 2 回通過します。したがって、トラフィック計画が SDN-GW スイッチ デバイスの許容範囲内に完全に含まれている場合は、SDN-GW を東西集約スイッチに接続することをお勧めします。これにより、POD 内のスパイン上の往復の侵入トラフィックを削減できます。

図1. 大規模SDNデータセンターのマルチポッドネットワークアーキテクチャ

POD 内の SDN データセンター転送制御テクノロジ実装ソリューションは、Openflow+Netconf または EVPN+Netconf になります。仮想マシンのシナリオでは、VTEP としてより大きく柔軟なテーブル エントリを持つ VSW を使用し、Openflow+Netconf ソリューションを採用することをお勧めします。ベアメタル サーバーのシナリオでは、ハードウェア SDN アクセス スイッチが VTEP として使用されます。 EVPN + Netconf ソリューションまたは Openflow + Netconf ソリューションは、特定のネットワーク デバイスの機能に応じて柔軟に選択できます。

Openflow+Netconf と EVPN+Netconf が一緒に導入されるシナリオでは、2 つの制御テクノロジ ソリューションを SDN コントローラ上で変換して接続する必要があります。 SDN コントローラと SDN-GW は EVPN ネイバーを確立し、EVPN コントロール プレーン情報を Openflow に変換して VSW に送信し、VSW の関連 Openflow 情報を EVPN コントロール情報に変換してハードウェア SDN スイッチに送信します。これは、VXLAN トンネルの確立と、VSW とハードウェア SDN スイッチ間のデータ転送を制御します。

POD を相互接続するためのソリューションは、SDN-DCI の関連技術を最大限に活用し、EVPN + VXLAN 技術を採用します。 POD 内の SDN-GW は DCI-GW としても機能し、異なる POD の SDN-GW との EVPN ネイバーを確立して、統合コラボレーション レイヤーの制御下でクロス POD トラフィックの相互運用性を実現します。

共有分散ブロック ストレージ、分散ファイル ストレージ、分散オブジェクト ストレージを個別に計画して、ストレージ ポッドを形成できます。ストレージ POD にアクセスするトラフィックは、VXLAN カプセル化を介して SDN-GW によって解凍され、Underaly ネットワーク ルーティングを介して転送され、ストレージ POD に到達します。ストレージ アクセス トラフィックを他のビジネス トラフィックから分離するには、POD に別の VRF を設定します。ストレージ POD が外部ネットワークにアクセスする必要がある場合は、ストレージ アグリゲーション スイッチを North-South アグリゲーション スイッチに接続する予定です。 FC SAN ストレージは各 POD に直接導入することをお勧めします。

図2. ストレージPODネットワーク計画図

3. 大規模SDNデータセンターのアンダーレイネットワークとルーティングの計画

複数のポッドを備えた大規模データセンターのアンダーレイ ネットワーキングでは、ネットワーク内に多数のネットワーク デバイスが存在します。各ポッドに 500 台のネットワーク デバイスがある場合、10 ポッドのネットワークには 5,000 台を超えるネットワーク デバイスが存在することになります。したがって、大規模データセンター ネットワークの高性能転送には、アンダーレイ層でのルーティング構成をどのように計画するかが非常に重要です。

一般的なデータ センターのシナリオでは、IGP ルーティングは主に OSPF ルーティングに基づいています。 OSPF ルーティング技術は成熟しており、ネットワーク構築および運用担当者はそれを使用する豊富な経験を持っています。大規模データセンター ネットワークの IGP ルーティング プロトコルとして OSPF を使用します。各 POD を異なるエリアに分割し、東西集約スイッチをバックボーン エリア エリア 0 として使用して、伝播エリアと LSA の数を削減する必要があります。各 POD 内の SDN-GW は OSPF 地域境界ネットワーク デバイスとして機能し、異なるインターフェイスは異なる領域に分割されます。上部に接続された東西集約スイッチのインターフェースはエリア0に分割され、下部に接続されたPOD内のスパインインターフェースはPODごとに別々のエリアに分割されます。南北集約スイッチは通常、レイヤー 2 透過伝送モードで動作し、レイヤー 3 終端は外部ネットワーク ファイアウォールにあります。したがって、南北集約スイッチはルーティング プロトコルを実行する必要はありません。

図3. 大規模データセンターネットワークのOSPFルーティング計画

OSPF と比較して、ISIS は大規模ネットワークに対するサポート機能と収束パフォーマンスに優れた ISPF (Incremental SPF) をサポートしています。 ISIS は柔軟な TLV エンコーディングをサポートしており、プロトコルのスケーラビリティが向上しています。 ISIS は、収束速度が速く、構造が明確で、大規模ネットワークに適しているため、メトロポリタン エリア ネットワーク シナリオや IP プライベート ネットワーク シナリオで IGP ルーティング プロトコルとして広く使用されています。データ センターがますます大規模になり、デバイスの数が増えるにつれて、データ センター シナリオでも ISIS がますます使用されるようになっています。 ISIS エリアの境界はリンクにあり、各ネットワーク デバイスは 1 つの ISIS エリアにのみ属することができます。大規模データセンターのシナリオでは、伝播エリアと LSP の数を削減するために、ISIS が階層的に計画されます。バックボーン エリアには、ポッド間の東西集約スイッチと各ポッド内の SDN-GW が含まれます。 POD 間の東西集約スイッチは ISIS レベル 2 を実行し、POD 内の SDN-GW は ISIS レベル 1-2 を実行します。各 POD の Spine ノードと Leaf ノードは ISIS レベル 1 を実行します。

図4. 大規模データセンターネットワークのISISルーティング計画

RFC7938 では、EBGP ルーティング プロトコルを大規模データ センターに適用することが提案されており、現在、データ センターの基盤となるルーティング プロトコルとして EBGP を使用する例は少数です。 OSPF や ISIS などのリンク ステート プロトコルとは異なり、BGP は距離ベクトル ルーティング プロトコルであるため、スケーラビリティが優れています。中小規模のデータセンターでネットワークを構築する場合、BGP を使用する場合と、ISIS や OSPF などのリンク ステート プロトコルを使用する場合のパフォーマンスにほとんど違いはありません。ただし、超大規模データセンターのネットワークでは、BGP を適用した方がパフォーマンスは向上します。 OSPF や ISIS などのリンク ステート プロトコルでは、ネットワーク内で多数の LSA を送信する必要があります。ルーティング情報生成プロセスでは、まず LSA 情報の同期を完了し、次にルーティング情報を計算して生成します。ネットワーク内の一部のノードが変更されたり、ネットワークがカットオーバーされてアップグレードされたりすると、大量の LSA が送信されます。距離ベクトル ルーティング プロトコル BGP にはこのような問題はありません。 BGP ノードはルートを直接アナウンスするため、ネットワーク拡張やカットオーバー アップグレード中のネットワークの安定性が向上します。

現在、IETF には OSPF および ISIS ルーティング プロトコルの LSA 最適化に関する対応するドラフトがあり、LSA 伝播の数と範囲を削減して、超大規模データ センター ネットワークにおける OSPF および ISIS のパフォーマンスを向上させることを目的としています。しかし、非常に効果的かつ実用的な解決策はありません。 EBGP は現在データ センター アプリケーションで広く使用されていませんが、距離ベクトル ルーティング プロトコル BGP は、将来、ハイパースケール データ センターの基盤となるルーティング プロトコルの選択肢として広く使用されるようになると思われます。

EBGP ルートの計画と構成は、OSPF や ISIS の場合よりも複雑です。 POD 内の複数の Spine デバイスは同じ AS 番号を持つように計画されており、複数の East-West アグリゲーション スイッチは同じ AS 番号を持つように計画されており、スタックされた Leaf デバイスの各グループには個別の AS 番号を持つように計画されています。各 POD の Leaf は同じ POD の Spine とのみ EBGP ネイバーを確立し、Leaf ノード間には EBGP ネイバーは確立されませんが、Spine 上で大量の Leaf ネイバー情報を設定する必要があります。複雑な計画と構成は、データセンターでの EBGP の適用を制限する要因の 1 つです。

基盤ルーティングプロトコルとして EBGP を使用する大規模データセンターでは、POD 内の転送制御ソリューションとして EVPN+Netconf を使用する場合、POD 内の EVPN は IBGP に基づいて確立する必要があります。したがって、ネットワーク デバイスには、異なる AS 番号を持つ 2 つの BGP プロセス (EBGP+IBGP) を設定する必要があります。現在、主流メーカーのネットワーク機器は、異なる AS 番号を持つ BGP デュアル プロセスをサポートしています。

通常の BGP メッセージの AS 番号は 16 ビット長で、範囲は 0 ～ 65535 です。プライベート AS 番号の範囲は 64512 ～ 65534 です。したがって、データセンターのネットワーク計画に使用できるプライベート AS 番号の数は 1023 です。スタックされたリーフ ノードのグループごとに 1 つの AS 番号という原則によれば、マルチポッドの大規模データセンター ネットワーキングの AS 番号割り当て要件を満たすことができないのは明らかです。 RFC6793 では、BGP AS 番号を 32 ビットに拡張することが推奨されています。拡張後、AS 番号の数は大規模データセンター ネットワーキングのニーズを満たすことができ、現在、業界の主流の機器は 32 ビットの AS 番号の長さをサポートする機能を備えています。

図5. 大規模データセンターネットワークのEBGPルーティング計画

SDN データセンターの管理ネットワークでは、機器の従来の帯域外管理機能を満たすだけでなく、Openstack クラウド管理プラットフォームと SDN コントローラーも導入する必要があります。したがって、従来のデータセンターの管理ネットワークよりも重要です。データセンターの規模が大きくなると、管理ネットワークの規模も必然的に大きくなります。そのため、大規模データセンターの管理ネットワークも POD に展開する必要があります。 POD 内の管理ネットワークのコア スイッチは、ネットワーク セグメントごとにゲートウェイで構成され、管理ネットワークのアクセス スイッチは、レイヤー 2 VLAN 透過伝送モードで動作します。管理ネットワーク内の POD 間に管理集約スイッチが設定されます。 POD 内の管理ネットワーク コアと POD 間の集約スイッチは 3 層で相互接続されており、ISIS または OSPF ルーティング プロトコルを実行できます。 POD 内の管理ネットワークのブロードキャスト ドメインを削減し、管理ネットワークをより安定させるために、管理ネットワーク セグメントのゲートウェイを管理アクセス スイッチ上に構成して、3 層からエッジ管理ネットワークを計画することもできます。ただし、そうすることの欠点は、より詳細な管理アドレス計画が必要になることです。管理アドレス計画が詳細すぎると、アドレス リソースがある程度無駄になります。したがって、3 層からエッジ管理までのネットワーク計画は一般的ではありません。

4. 大規模SDNデータセンターにおけるPOD間の相互接続

大規模な SDN データ センターでは、大規模なデータ センター用の統合リソース プールを構築するために、さまざまな POD 内のリソースを統一的に管理およびスケジュールする必要があります。大規模な SDN データセンターでは、SDN-DCI テクノロジーを使用して POD 間の相互接続を実現します。

SDN-DCI テクノロジーは、EVPN + VXLAN を介してクロス POD 相互接続チャネルを確立します。管理プレーンは EVPN プロトコルを採用し、データ プレーンは VXLAN トンネル伝送を採用します。 POD 内の SDN-GW は DCI-GW としても機能し、フル メッシュ EBGP プロトコルは各 POD の SDN-GW 間で実行されるように設定されます。 EBGP プロトコルに基づいて、各 POD の SDN-GW 間に EVPN ネイバー関係が確立され、EVPN を介して相互接続されたコントロール プレーンが確立され、テナントの VPC (仮想プライベート クラウド) 内で MAC、ARP、および IP ネットワーク セグメント ルーティング情報が伝送されます。

大規模データセンターでは、統合クラウド管理プラットフォームを導入して各 POD 内の SDN コントローラーを調整し、POD 間のネットワーク サービス トラフィックの相互運用性を実現します。実際のネットワーク展開では、POD は異なるメーカーのデバイスである可能性が高いため、クラウド管理プラットフォームは異なるメーカーの SDN コントローラーに接続する必要があります。このためには、SDN コントローラからクラウド管理プラットフォームへの標準のノースバウンド API オープン インターフェイスを定義する必要があります。さまざまなメーカーの SDN コントローラは、この標準インターフェイスに基づいてクラウド管理プラットフォームから指示を受信し、POD 内の転送デバイスを制御して指示の実行を完了します。

図6. クロスPOD相互通信EVPN+VXLANテクノロジーソリューションの概略図

大規模データセンターにおけるポッド間のビジネス相互接続のニーズを分析することで、次のトラフィック モデルを導き出すことができます。同じビジネス ドメイン内の同じテナントは、イントラネット ファイアウォールを通過せずにポッド間で相互接続できます。同じビジネス ドメイン内の異なるテナントは、イントラネット ファイアウォールを通過せずに Pod 間で相互接続できます。異なるビジネス ドメイン内の同じテナントは、イントラネット ファイアウォールを通過せずに Pod 間で相互接続できます。異なるビジネス ドメインの異なるテナントは、イントラネット ファイアウォールを通過せずに Pod 間で相互接続できます。

上記のネットワーク トラフィック モデルを要約して分析すると、ファイアウォールを介した POD 間の相互通信とファイアウォールを通過せずに POD 間の相互通信という 2 つの相互通信トラフィック モデルに簡略化できます。クラウド管理プラットフォームのクロスポッド相互通信サービス インターフェース命令テンプレートに、ファイアウォールを通過するかどうかを決定するファイアウォール ステータス有効化スイッチを追加します。さらに、トラフィック モデルの対称性を考慮すると、壁を通過するシナリオでは、両側の POD の両方が壁を通過する必要があります。

ポッド間のトラフィックはファイアウォールを通過できません。テナント トラフィックは、ローカル アクセス VTEP によってローカル VXLAN トンネルにカプセル化され、その後、ポッド内の SDN-GW によってローカル VXLAN に展開されます。相互接続された VXLAN に再カプセル化され、反対側の Pod の SDN-GW に送信されます。トラフィックがピア POD 内の SDN-GW に到達すると、相互接続された VXLAN カプセル化からアンパックされ、対応するテナントのローカル VXLAN トンネルにカプセル化されます。異なるサービスのクロスポッド相互通信トラフィックは分離する必要があります。サービス相互通信トラフィックのグループごとに個別の VNI と VRF を計画し、VNI と VRF をバインドする必要があります。

図 7. ポッド間のトラフィック モデル (ファイアウォールは除く)

クロス POD ファイアウォール トラフィック モデルでは、テナント トラフィックは POD 内の SDN-GW に到達し、ローカル VXLAN カプセル化を解凍してから、VLAN レイヤー 2 を介してファイアウォールに転送します。ファイアウォールが処理した後、トラフィックは SDN-GW に送り返され、相互接続された VXLAN に再カプセル化されて、反対側の POD 内の SDN-GW に送信されます。トラフィックが反対側の POD の SDN-GW に到達すると、相互接続された VXLAN カプセル化が解凍され、VLAN レイヤー 2 を介して POD のファイアウォールに転送されます。ファイアウォールが処理した後、トラフィックは SDN-GW に送り返され、SDN-GW はトラフィックを対応するテナントのローカル VXLAN トンネルにカプセル化します。

図 8. ポッド間のトラフィック モデル (ファイアウォールは除く)

異なるサービスのクロスポッド相互通信トラフィックは分離する必要があります。サービス相互通信トラフィックのグループごとに個別の VNI と VRF を計画し、VNI と VRF をバインドする必要があります。負荷分散デバイスで処理する必要がある一部のビジネス トラフィックについては、クラウド管理プラットフォームでトラフィックを均一に調整して、対応する負荷分散を通過させることができます。

5. 大規模SDNデータセンターにおける南北トラフィックの簡単な説明

大規模 SDN データ センターでは、マルチ POD ネットワーキングを導入した後、North-South アグリゲーション スイッチを追加することで North-South トラフィックを処理します。北と南の集約スイッチは、それぞれインターネット ファイアウォール、IP プライベート ネットワーク、専用回線ルーターに接続されます。南北コンバージェンス スイッチは、南北インターネット サービス トラフィックを処理するためにレイヤー 2 透過伝送モードで動作し、レイヤー 3 トラフィックはそれぞれ SDN-GW と外部ネットワーク ファイアウォールで終了します。 IP プライベート ネットワークと専用回線の内外の North-South トラフィックの処理では、具体的な状況に応じて、レイヤー 2 透過伝送モードまたはレイヤー 3 モードで動作できます。レイヤー 3 モードで作業するには、さまざまなビジネス トラフィックを分離するために VRF を構成する必要があります。