長い間、ネットワークに関連するすべての大規模プロジェクトは、それがWebプロジェクトであろうと大企業のDCであろうと、1つの同じ構造でした。 信頼性とパフォーマンスの要件が異なるため、ツリーのサイズと「ブランチ」の密度のみが異なる特徴的なツリーのようなアーキテクチャでした。 しかし、デジタルの世界は静止しているのではなく、急速に成長と発展を遂げており、量と速度の増加だけでなく、構造の変化もしています。 あらゆる種類のビッグデータ、クラウド、分散コンピューティングにより、大量のデータをネットワークを介して多数のエンドノード間で、できれば最小限の遅延で送信することが必要になりました。
これらすべてが、アクセスレベル、トラフィックの集約、カーネルで構成される従来のツリーのようなアーキテクチャが公然と滑って失敗するという事実につながりました。 交換する必要があります。 何のために？
始めるために、いわゆる「伝統的な」エンタープライズプロジェクトのネットワーク構造を特徴付けてみましょう。
- 数百から数千のノード。
- 静的ルーティング;
- サーバー仮想化のないVLAN構造。
- 垂直指向（南北）アーキテクチャ
- 1Gは10Gアップリンクと相互接続します。
また、クラウド、ビッグデータ、分散コンピューティングなどの最新の大規模プロジェクトなどのWeb 2.0プロジェクトで動作する最新のデータセンターのネットワークと同じ特性があります。
- 数千から数百万のノード。
- 動的ルーティング;
- 仮想サーバーを使用したクラウド構造。
- 主に水平（西東）アーキテクチャ。
- ネットワークの迅速な（数週間ではなく数時間）展開とラックの追加。
- 基本的に、40Gアップリンクを使用した10G接続。
新しい世界のニーズ
組織の変更が必要な大きな違いがあります。
最新のネットワークインフラストラクチャのさまざまな要件をまとめると、次のようになります。
- パフォーマンスの優れたスケーラビリティ。
- すべてのレベルでの耐障害性。
- コストを削減するための高い互換性。
- 予測可能なレイテンシ;
- 機器の高可用性;
- サービスの利便性。
従来のネットワークインフラストラクチャ
従来のスキームでカテゴリ的に満足していないものは何ですか？
- 集約レベルで障害が発生した場合の生産性の急激な低下。
- 集約レベルに起因するスケーラビリティの欠如：
- MAC / ARP
- VLAN
- 水平方向のトラフィック交換ポイントの輻輳。
- 信頼性の向上に伴う構造の複雑さの急激な増加。
- 多くの独自プロトコルオプション（MLAG、vPC、STP、UDLD、ブリッジ保証、LACP、FHRP、VRRP、HSRP、GLBP、VTP、MVRP ...）
解決策？ 規模について話し始めるとすぐに、サービスのコストが機器のコストを超え始めると（そう、会計士やマーケティング担当者に愛され、CAPEXとOPEXの残りの人には愛されない）、Closネットワークの形式で知られているソリューションが登場し、 Leaf-Spineアーキテクチャとも呼ばれます。
葉背
不注意な人への重要な注意：スパインのレベルは、集約のレベルとまったく同じではありません。 このレベルでは、スイッチ間に水平方向の接続はなく、想定されていません。さらに、このレベルを通過するすべてのトラフィックが収集され、コア、たとえばインターネットに向かうとは想定されていません。
このアーキテクチャ自体は半世紀にわたって知られており、電話ネットワークでの使用に成功していますが、データセンターネットワークでの積極的な実装にはすべての前提条件があります。 一方で、機器は非常に効率的かつ安価になり、同時に非常に低いレイテンシー（数百ナノ秒-これはフィクションではありませんが、非常に現実的です）を提供します。 一方で、集中化されたアーキテクチャが最適ではなくなると、タスク自体がそうなりました。
Leaf-Spineは、検討中の構造に適用すると何を提供しますか？
- 継続的なIPファクトリーでECMP（_ 2014年3月以来、IEEE 802.1Qbp_標準として一意に識別され認識されている）に依存する機能。
- 均質性に起因する機器故障の排除の促進。
- 予測可能なレイテンシ;
- スケーラビリティを備えています。
- 制御の自動化の容易さ;
- 機器障害時のネットワーク帯域幅の低下が少ない。
- EOR（End of Row）の代わりにTOR（Top of Rack）。 TORとEORの詳細については、この古い記事ですが、関連する記事で読むことができます）
ボーナスが欲しいですか？ お願い：
- 回線はデフォルトでループから保護されており、これにはSTPは必要ありません。
- ポートが応答しない場合、ルーティングプロトコルはドロップアウトしたと見なし、STPとは異なり、ルートへの参加の可能性を考慮しません。
そのようなネットワークはどの程度まで拡張できますか？ 48個の10Gポートと6個の40Gアップリンク（ラックごとに40台のサーバーを配置する場合はオーバープロビジョニング比1.6）を備えた一般的で安価なスイッチの2レベルネットワークにより、最大1920台のサーバーを接続できます。 第3レベルに入ると、この数値は18万に増加します。 これで十分でない場合は、レベルをさらに上げることができます。
はるかに小さいサイズのネットワークでこのアーキテクチャを使用することは可能ですか？ もちろん、プロジェクトにL2ルーティング専用の特定の要件がない場合はどうでしょうか。 BMSスイッチの従来のソリューションとLeaf-Spineのコストを計算します。 そして、後者が明らかにあなたのために勝っているなら-これは正しいと思う正当な理由ですか？ :)
もちろん、これに加えて、もう1つの条件が満たされる必要があります。これは、ネットワークの概念を変更する必要性について話し合ったときに重要でした。データボリュームの一部。 これは、そのようなネットワークに外部接続を持たせてはならないという意味ではありませんが、それらへのトラフィックはノード間のフローに見合ったものであり、主要なコンポーネントではないはずです。
これに必要なものをすべて提供する準備ができています。
Eos 420
Eos 520
たとえば、非常に費用対効果の高いスイッチは、
Trident IIマトリックスにプリインストールされたOS（ベアメタルスイッチ）、10 Gポートの価格が100ドル未満：リーフレベルではETegro Eos 420 （48 10G + 6 40G）、スパインレベルではEos 520 （32 40G）。
さて、必要に応じて、ネットワークオペレーティングシステムのCumulus Linuxを提供します。これについては、少し前に書きました 。
ベアメタルスイッチ
ネットワーク機器のBMSバージョンを推奨しているのはなぜですか？ はい、単に私たちの意見では、必要な機能のセットを備えたOSを選択することで、同時に現代のプロジェクトに必要な柔軟性を提供できるだけであり、時には非常に高価だが絶対に不要なベンダー固有の機能を支払うことを拒否するため、所有コストが低いためです。 あるメーカーからサーバーを購入し、別のメーカーのOSをその上に置き、サードパーティのソフトウェアでそれを補うことができるという事実の利便性に誰もが異議を唱えることはまずありません。 私たちの意見では、このオープンシステムのイデオロギーをネットワーク機器の世界に持ち込む時が来ました。
このようなスイッチを「タッチ」して、オープンネットワークOSで可能なことを確認したい場合は、テストを整理する機会があります。