Arista リーフ スパイン アーキテクチャ – ブログ シリーズ パート XNUMX

従来の 3 層データセンター ネットワーク

約 20 年前、ネットワークの可用性が向上し、アプリケーションの数が増加したため、より多くのサーバーが必要でした。 そのため、データセンターに多数のアクセス ポートをプロビジョニングする必要がありました。 当時はクラウド コンピューティングは存在せず、プライベート データ センターが標準でした。 各企業はインフラストラクチャに投資する必要があり、データセンター内の VLAN アドレッシング スペースが 4094 の VLAN に制限されていたため、マルチテナンシーもサービス プロバイダー ネットワークに限定されていました。

データセンター内のサーバーの数が多いため、アクセス スイッチにはサーバーに接続するためのより多くのポートが必要でした。 これらはアクセス層を形成しました。 これらは、通常はデータセンター列の最後にある分散/集約レイヤーに集約される必要がありました。 ディストリビューション スイッチは通常、多数のアクセス スイッチを集約するための多数のダウンストリーム ポートを備えたモジュラー スイッチでした。

次の設計上の考慮事項は、これらすべてのディストリビューション スイッチを、高レベルの冗長性を備えた高帯域幅、低遅延のトランスポート コアに接続することでした。 コア層の機能は、ルーティングのオーバーヘッドを最小限に抑えたデータ転送のみです。

スイッチング機能はアクセス層とディストリビューション層に限定されており、ディストリビューション層は VLAN 間ゲートウェイとして機能します。 コア層はスイッチングには関与せず、ルーティングのみに重点を置きました。 ネットワークの残りの部分は通常、コアまたは専用のディストリビューション スイッチ ペアに接続されます。 すべてのレイヤーで冗長性を確保するために複数のアップリンクが接続され、高速フェイルオーバーのために同一構成の冗長デバイス ペアが HA で構成されました。 これはクロスリンクを使用して実現されました。 VSS は、そのような一般的な構成の XNUMX つでした。

従来の 3 層データセンターの問題点

3 層データ センターは、サーバー仮想化が初期段階にあった当時、主に南北トラフィック フロー用に設計されました。 仮想化がより一般的になるにつれて、アプリケーションは、データ センター全体、場合によっては複数のデータ センター全体に広がる複数の物理サーバーにまたがって焼き付けられました。 これにより、1 層アーキテクチャのホップ数に関する問題が明らかになりました。 トラフィック フローは次のようになります。Server1 -> Access1 -> Dist2 -> Core (複数のホップが可能) -> Dist2 -> Access2 -> Server4。 送信元と宛先のアクセス スイッチ間に最小 XNUMX ホップ。

2 番目の最も重要な要因の XNUMX つは、スパニング ツリーです。 非常に多くの STP ドメインを管理することには問題があり、利用可能なすべてのアップリンクがネットワークで使用されていませんでした。 新しいアプリケーションのプロビジョニングには俊敏性が必要でした。ネットワーク チームは、厳格なレイヤー XNUMX 設計で作業している間、アプリケーションの動的な性質に対処できませんでした。

最後に、重要なワークロードの DR および HA シナリオでは、VM モビリティの必要性がますます高まっていました。 宛先データセンターの L3 および L2 設計では VM の再アドレス指定が必要になるため、これを 3 層モデルで実装するのは困難でした。 これによりアプリケーションが破損し、ユーザーおよび管理者レベルでの再構成が必要になりました。

さらに、ネットワーク OEM による SOC 機能の開発により、ほぼ線形のルーティング ルックアップが可能になりました。 ルーティングをコア層とディストリビューション層のみに制限する必要は実際にはなく、アクセス層まで拡張してスパニングツリーの問題を軽減することができました。

CLOS ノンブロッキング ファブリックの概要

3 層データセンターに関する上記の問題により、OEM は以下の原則を使用してよりシンプルなアーキテクチャを考案しました。

• 3 段階のファブリック – イングレス、クロスバー、イーグレス
• 等コストマルチパス化
• ファブリックにはスイッチのみが含まれています。
• すべてのスイッチは、レイヤ 2 とレイヤ 3 の両方の機能を備えたマルチレイヤ スイッチです。
• 新しい Spine スイッチの追加によりサブスクリプション率を向上できる
• 新しいリーフ スイッチを追加することでアクセス ポートの数を増やすことができます

Leaf and Spine ネットワークは CLOS アーキテクチャの実装です。

スイッチの役割を理解する – 「リーフ」と「スパイン」

CLOS ファブリックには、理解する必要がある新しいスイッチの役割があります。 リーフ スイッチはアクセス スイッチの別名です。 CLOS ファブリックの入力スイッチと出力スイッチは両方ともリーフ スイッチです。

さらに、「スパイン」ロールがあります。これは、3 ステージ CLOS ファブリックのクロスバー機能の別名です。 すべての「リーフ」スイッチはこの層に接続するため、ファブリックのスパインと呼ばれ、その名前が付けられています。

各リーフはネットワーク内のすべてのスパインに接続し、ECMP を使用して転送に利用可能なすべてのパスを利用する必要があります。 「スパイン」スイッチは相互に接続する必要はなく、リーフ スイッチ間の接続にのみ使用されます。

外部ネットワークをスパイン スイッチに接続することは可能ですが、ファブリックの境界を形成して外部ネットワークに接続する「ボーダーリーフ」スイッチと呼ばれる専用のスイッチを用意することをお勧めします。

Advaリーフスパイン アーキテクチャの使用方法:

advaリーフ スパイン アーキテクチャを使用する場合のステージは次のとおりです。

• ノンブロッキング – スパニングツリーでポートがブロックされない
• 宛先アクセス スイッチへの利用可能なパスをすべて利用します。
• 利用可能なパスの数 = ネットワーク内のスパイン スイッチの数。
• ほとんどの場合、1:1 のサブスクリプション比率を達成できます
• 送信元から宛先まではネットワーク上で常に 2 ホップです
• 決定的な東西交通経路
• スパニングツリーは必要ありません – 再コンバージェンス中の学習と転送の遅延はありません
• 完全なレイヤー3データセンターが可能

Rahi は、企業が多数のベンダーから市場で入手可能な最新のリーフスパイン ソリューションを特定して展​​開するのに役立ちます。 Rahi は、高度にスケーラブルな展開の豊富な経験を持っています データセンター ネットワーク Day 1 の構成と Day 2 のサポートについては、世界中の経験豊富なプロフェッショナル サービス チームとマネージド サービス チームが対応します。

もっと詳しく知りたい場合は読んでください パート2