データセンターを拡張する方法。 ヤンデックスレポート

当社は、100 秒あたり XNUMX ペタバイトを超えるピーク二分帯域幅を備えた XNUMX 万サーバーを超えるコンピューティング クラスターの展開を可能にするデータ センター ネットワーク設計を開発しました。

Dmitry Afanasyev のレポートから、新しい設計の基本原則、トポロジのスケーリング、これによって生じる問題、それらを解決するためのオプション、「高密度接続」における最新のネットワーク デバイスのフォワーディング プレーン機能のルーティングとスケーリングの機能について学びます。多数の ECMP ルートを含むトポロジ。さらに、ディマ氏は、外部接続の構成、物理層、配線システム、および容量をさらに増やす方法について簡単に説明しました。

- みなさん、こんにちは！私の名前はドミトリー アファナシエフです。Yandex のネットワーク アーキテクトで、主にデータ センター ネットワークを設計しています。



私の話は、Yandex データセンターの更新されたネットワークについてです。これは私たちのデザインを大きく進化させたものですが、同時にいくつかの新しい要素もあります。短い時間に多くの情報を詰め込む必要があるため、これは概要のプレゼンテーションです。まず、論理トポロジを選択します。次に、コントロール プレーンの概要とデータ プレーンのスケーラビリティの問題、物理レベルで何が起こるかを選択し、デバイスのいくつかの機能を見ていきます。少し前にお話しした、MPLS を使用するデータセンターで何が起こっているかについて少し触れてみましょう。

では、負荷とサービスの観点から見ると、Yandex とは何でしょうか? Yandex は典型的なハイパースケーラーです。ユーザーに目を向けると、私たちは主にユーザーのリクエストを処理します。また、各種ストリーミングサービスやデータ転送、ストレージサービスもございますのでご利用下さい。バックエンドに近い場合は、分散オブジェクト ストレージ、データ レプリケーション、そしてもちろん永続キューなどのインフラストラクチャの負荷とサービスがそこに表示されます。ワークロードの主なタイプの 1 つは、MapReduce および同様のシステム、ストリーム処理、機械学習などです。

こうしたすべてが行われるインフラストラクチャはどのようになっているのでしょうか?繰り返しになりますが、当社は非常に典型的なハイパースケーラーですが、おそらくスペクトルのより弱いハイパースケーラー側に少し近づいています。しかし、私たちはすべての属性を持っています。可能な限り、汎用ハードウェアと水平スケーリングを使用します。当社では完全なリソース プーリングを行っています。個々のマシンやラックを操作するのではなく、計画と割り当てを処理するいくつかの追加サービスを使用して、それらを交換可能なリソースの大規模なプールに結合し、このプール全体を操作します。

したがって、次のレベルは、コンピューティング クラスター レベルのオペレーティング システムです。使用するテクノロジー スタックを完全に制御することが非常に重要です。当社はエンドポイント (ホスト)、ネットワーク、ソフトウェア スタックを制御します。

当社はロシア国内外にいくつかの大規模なデータセンターを持っています。これらは、MPLS テクノロジーを使用するバックボーンによって結合されます。当社の内部インフラストラクチャはほぼ完全に IPv6 で構築されていますが、引き続き主に IPv4 経由で送信される外部トラフィックに対応する必要があるため、IPv4 経由で送信されるリクエストを何らかの方法でフロントエンド サーバーに配信し、さらにもう少し外部の IPv4 (インターネット) に送信する必要があります。たとえば、インデックス作成の場合。

データセンター ネットワーク設計の最後の数回の反復では、マルチレイヤー Clos トポロジが使用されており、L3 のみです。先ほどＬ２を出て安堵のため息をつきました。最後に、当社のインフラストラクチャには数十万のコンピューティング (サーバー) インスタンスが含まれています。少し前の最大クラスター サイズは約 2 サーバーでした。これは主に、同じクラスタ レベルのオペレーティング システム、スケジューラ、リソース割り当てなどがどのように機能するかによるものであり、インフラストラクチャ ソフトウェア側での進歩があったため、現在、目標サイズは 10 つのコンピューティング クラスタに約 100 万台のサーバーが含まれています。私たちには、そのようなクラスター内で効率的なリソース プーリングを可能にするネットワーク ファクトリを構築できるようにするという課題があります。

データセンター ネットワークに何を求めますか?まず第一に、安価でかなり均一に分散された帯域幅がたくさんあります。ネットワークはリソースをプールできるバックボーンであるためです。新しい目標規模は、100 つのクラスター内のサーバー約 XNUMX 万台です。

もちろん、スケーラブルで安定したコントロール プレーンも必要です。これは、このような大規模なインフラストラクチャでは、単なるランダムなイベントからも多くの問題が発生するためであり、コントロール プレーンによっても同様に問題が発生することは望ましくないからです。同時に、その状態を最小限に抑えたいと考えています。状態が小さいほど、すべてがより良く安定して機能し、診断が容易になります。

もちろん、このようなインフラストラクチャを手動で管理することは不可能であり、しばらくの間不可能であったため、自動化が必要です。できる限りの運用サポートと、提供できる範囲のCI/CDサポートが必要です。

このような規模のデータセンターとクラスターでは、サービスを中断することなく段階的な展開と拡張をサポートするという課題が非常に重要になっています。 1000 台のマシン (おそらく 1 万台近くのマシン) のサイズのクラスター上にある場合でも、それらは 1 つの操作として展開できます。つまり、インフラストラクチャの拡張を計画しており、数千台のマシンが 1 つの操作として追加されます。このように、10 万台のマシンのサイズのクラスターがすぐに発生するわけではなく、時間をかけて構築されます。そして、すでに汲み上げられているもの、展開されているインフラストラクチャが常に利用可能であることが望ましいです。

そして、私たちが持っていたものの残された要件の 6 つは、マルチテナンシー、つまり仮想化またはネットワーク セグメンテーションのサポートです。シャーディングがホストに渡されるため、これをネットワーク ファブリック レベルで行う必要がなくなり、スケーリングが非常に簡単になりました。 IPvXNUMX と大規模なアドレス空間のおかげで、内部インフラストラクチャで重複したアドレスを使用する必要がなく、すべてのアドレス指定がすでに一意になっていました。また、ホストにフィルタリングとネットワーク セグメンテーションを導入したおかげで、データ センター ネットワークに仮想ネットワーク エンティティを作成する必要がなくなりました。

非常に重要なことは、私たちが必要としないものです。一部の機能をネットワークから削除できれば、作業がはるかに楽になり、一般に、利用可能な機器やソフトウェアの選択肢が広がり、診断が非常に簡単になります。

それでは、私たちに必要のないものは何でしょうか。それが起こったときは必ずしも喜んでではなく、プロセスが完了したときに大きな安堵感を持って手放すことができたものは何でしょうか?

まずはL2放棄。実際の L2 もエミュレートされた L3 も必要ありません。アプリケーションスタックを制御しているため、ほとんど使用されません。私たちのアプリケーションは水平方向にスケーラブルで、LXNUMX アドレス指定で動作し、個々のインスタンスが失われることをあまり心配せず、新しいインスタンスをロールアウトするだけです。古いアドレスでロールアウトする必要はありません。クラスター内にあるマシンの別のレベルのサービス検出と監視。このタスクをネットワークに委任することはありません。ネットワークの仕事は、ポイント A からポイント B にパケットを配信することです。

また、ネットワーク内でアドレスが移動する状況も発生していないため、これを監視する必要があります。多くの設計では、これは通常、VM モビリティをサポートするために必要です。私たちは、大手 Yandex の内部インフラストラクチャでは仮想マシンのモビリティを使用していません。また、たとえ使用したとしても、ネットワーク サポートではそのようなことは起こらないはずだと考えています。本当に必要な場合は、ホスト レベルで実行し、アンダーレイ自体 (トランスポート ネットワーク) のルーティング システムに触れたり、過度に動的変更を加えたりしないように、オーバーレイに移行できるアドレスをプッシュする必要があります。 。

私たちが使用していないもう 1 つのテクノロジーはマルチキャストです。ご希望であれば、その理由を詳しくお話します。これにより、作業がはるかに楽になります。誰かがこれに対処し、最も単純なインストールを除くすべてのマルチキャスト コントロール プレーンがどのように見えるかを正確に調べた場合、これは大きな頭痛の種となるからです。さらに、たとえば、適切に機能するオープンソース実装を見つけるのは困難です。

最後に、ネットワークがあまり変化しないように設計します。ルーティング システムにおける外部イベントのフローは小さいという事実が当てはまります。

データセンター ネットワークを開発する場合、どのような問題が発生し、どのような制限を考慮する必要があるのでしょうか?もちろん費用もかかります。スケーラビリティ、私たちが成長したいレベル。サービスを停止せずに拡張する必要がある。帯域幅、可用性。監視システムや運用チーム向けに、ネットワーク上で何が起こっているかを可視化します。自動化のサポート - 追加レイヤーの導入を含め、さまざまなタスクをさまざまなレベルで解決できるため、これも可能な限りサポートします。まあ、ベンダーに依存することは[おそらく]ありません。歴史上の時代は異なりますが、どのセクションを見るかによって、この独立は達成しやすかったり、達成しにくかったりします。ネットワーク デバイス チップの断面図を見ると、最近まで、高スループットのチップも必要な場合、ベンダーからの独立性について話すことは非常に条件付きでした。

ネットワークを構築するにはどのような論理トポロジを使用しますか?これは複数レベルのクロになります。実際、現時点では実質的な代替手段はありません。そして、Clos トポロジは、大規模な基数スイッチがあれば、現在学術的に関心のあるさまざまな高度なトポロジと比較した場合でも、非常に優れています。

マルチレベル Clos ネットワークは大まかにどのように構成されており、その中でさまざまな要素は何と呼ばれていますか?まず第一に、風が立ち、どこが北で、どこが南で、どこが東で、どこが西なのかを自分の方向に向けます。このタイプのネットワークは通常、非常に大規模な西から東へのトラフィックを扱うネットワークによって構築されます。残りの要素に関しては、上部には小さなスイッチから組み立てられた仮想スイッチがあります。これが Clos ネットワークの再帰的構築の主なアイデアです。ある種の基数を持つ要素を取得し、それらを接続して、取得したものをより大きな基数を持つスイッチとみなせるようにします。さらに必要な場合は、手順を繰り返すことができます。

たとえば、1 レベルの Clo の場合、図内で垂直なコンポーネントを明確に識別できる場合、それらは通常プレーンと呼ばれます。 XNUMX レベルのスパイン スイッチ (すべて境界スイッチや ToR スイッチではなく、トランジットのみに使用されます) を備えた Clos を構築する場合、プレーンはより複雑に見えます。XNUMX レベルのプレーンは次のようになります。 ToR またはリーフ スイッチのブロックと、それらに関連付けられた第 XNUMX レベルのスパイン スイッチをポッドと呼びます。ポッドの上部にあるスパイン XNUMX レベルのスパイン スイッチは、ポッドの上部、つまりポッドの上部です。ファクトリ全体の最上部にあるスイッチは、ファクトリの最上層、つまりファブリックのトップです。

もちろん、Clos ネットワークはかなり前から構築されているという疑問が生じますが、そのアイデア自体は一般的に古典的な電話、TDM ネットワークの時代から来ています。もしかしたら、もっと良いものが登場したり、何かもっと良くできるかもしれない？はいといいえ。理論的にはそうですが、実際には近い将来には間違いなくそうではありません。興味深いトポロジが多数あるため、その一部は運用環境でも使用されています。たとえば、Dragonfly は HPC アプリケーションで使用されます。 Xpander、FatClique、Jellyfish などの興味深いトポロジもあります。最近の SIGCOMM や NSDI などのカンファレンスのレポートを見ると、Clos よりも (何らかの) 優れた特性を持つ代替トポロジーに関する研究がかなり多く見つかります。

しかし、これらすべてのトポロジには 1 つの興味深い特性があります。これにより、私たちが汎用ハードウェア上に構築しようとしているデータセンター ネットワークへの実装が妨げられ、かなりの費用がかかります。これらの代替トポロジのすべてにおいて、残念ながら帯域幅のほとんどは最短パス経由ではアクセスできません。したがって、従来のコントロール プレーンを使用する機会は即座に失われます。

理論的には、この問題の解決策はわかっています。これらは、たとえば、k-shortest パスを使用したリンク状態の変更ですが、やはり、実稼働環境で実装され、機器で広く利用できるようなプロトコルはありません。

さらに、容量のほとんどは最短パス経由ではアクセスできないため、それらのパスをすべて選択するには、コントロール プレーン以上の変更が必要です (ちなみに、これはコントロール プレーンの状態のかなり多くの部分です)。転送プレーンを変更する必要があり、原則として、少なくとも 2 つの追加機能が必要です。これは、パケット転送に関するすべての決定を、たとえばホスト上で 1 回だけ行う機能です。実際、これはソース ルーティングであり、相互接続ネットワークに関する文献では、一括転送決定と呼ばれることもあります。そして、適応ルーティングはネットワーク要素に必要な機能であり、これは要約すると、たとえば、キュ​​ーの最小負荷に関する情報に基づいて次のホップを選択するという事実に帰着します。一例として、他のオプションも可能です。

したがって、この方向性は興味深いのですが、残念ながら、現時点ではそれを適用することはできません。

さて、Clos 論理トポロジに落ち着きました。どのようにスケールするのでしょうか?それがどのように機能し、何ができるかを見てみましょう。

Clos ネットワークには、要素の基数とネットワークのレベル数という 2 つの主なパラメータがあり、これらを変更して特定の結果を得ることができます。両方がサイズにどのように影響するかを示す概略図があります。理想的には、両方を組み合わせます。

Clos ネットワークの最終的な幅は、南基数のスパイン スイッチのすべてのレベル、ダウンしているリンクの数、分岐方法の積であることがわかります。これがネットワークのサイズを拡大する方法です。

特に ToR スイッチの容量に関しては、2 つのスケーリング オプションがあります。一般的なトポロジを維持しながら、より高速なリンクを使用するか、プレーンを追加することができます。

Clos ネットワークの拡張バージョン (右下隅) を見て、下の Clos ネットワークがあるこの図に戻ると...

...これはまったく同じトポロジですが、このスライドではよりコンパクトに折りたたまれており、工場の平面が互いに重ね合わされています。同じです。

Clos ネットワークのスケーリングを数値で表すとどのようになりますか?ここでは、取得できるネットワークの最大幅、ラック、ToR スイッチ、またはリーフ スイッチの最大数 (それらがラック内にない場合) についてのデータを提供します。スパイン レベルに使用するスイッチの基数に応じて取得できます。使用するレベルの数。

ここでは、ラックごとに 20 kW に基づいて、ラックの数、サーバーの数、およびこれらすべてが消費できるおおよその量を示します。先ほど、約 100 万サーバーのクラスター サイズを目指していると述べました。

この設計全体で、64 つ半のオプションが興味深いことがわかります。 128 層のスパインと 128 ポート スイッチを備えたオプションもありますが、これでは少し不十分です。さらに、32 レベルの 150 ポート (基数 XNUMX) スパイン スイッチ、または XNUMX レベルの基数 XNUMX のスイッチに最適なオプションもあります。そして、どのような場合でも、より多くの基数とより多くのレイヤーがある場合、非常に大規模なネットワークを構築できますが、予想される消費量に注目すると、通常はギガワット単位になります。ケーブルを敷設することは可能ですが、XNUMXつの場所でそれほど多くの電力を得ることができそうにありません。データセンターに関する統計や公開データを見てみると、推定容量が XNUMX MW を超えるデータセンターはほとんどありません。より大きなものは通常、データ センター キャンパスであり、いくつかの大規模なデータ センターが互いに非常に近接して配置されています。

もう一つ重要なパラメータがあります。左側の列を見ると、使用可能な帯域幅がそこにリストされています。 Clos ネットワークでは、ポートの大部分がスイッチ間の接続に費やされていることが簡単にわかります。使用可能な帯域幅、つまり便利なストリップは、サーバーに対して外部に提供できるものです。当然のことながら、私は条件付きポート、特に帯域について話しています。一般に、ネットワーク内のリンクはサーバーへのリンクよりも高速ですが、帯域幅の単位あたり、サーバー機器に送信できる分だけ、ネットワーク自体内にまだある程度の帯域幅が存在します。そして、作成するレベルが増えるほど、このストリップを外部に提供するための具体的なコストが高くなります。

さらに、この追加の帯域さえもまったく同じではありません。スパンは短いですが、DAC (直接接続銅線、つまり Twinax ケーブル) やマルチモード光のようなものを使用できますが、多かれ少なかれそれなりの費用がかかります。より長いスパンに移行するとすぐに、通常、これらはシングルモード光であり、この追加の帯域幅のコストは著しく増加します。

もう一度前のスライドに戻りますが、オーバーサブスクリプションなしで Clos ネットワークを作成すると、図を見てネットワークがどのように構築されているかを簡単に確認できます。各レベルのスパイン スイッチを追加して、最初のストリップ全体を繰り返します。底。プラス レベル - 同じ帯域、前のレベルと同じ数のスイッチ上のポート、および同じ数のトランシーバーが追加されます。したがって、スパイン スイッチのレベルの数を最小限に抑えることが非常に望ましいです。

この図に基づいて、基数 128 のスイッチのようなものを本当に構築したいことは明らかです。

ここでは、原則的には今言ったことと同じであり、これは後で検討するためのスライドです。

このようなスイッチとしてはどのような選択肢があるのでしょうか?このようなネットワークがついにシングルチップ スイッチ上に構築できるようになったのは、私たちにとって非常に喜ばしいニュースです。これは非常にクールで、素晴らしい機能がたくさんあります。たとえば、内部構造がほとんどありません。つまり、壊れやすくなります。さまざまな形で壊れますが、幸いなことに完全に壊れます。モジュール式デバイスには、隣接するデバイスやコントロール プレーンの観点からは機能しているように見えても、たとえばファブリックの一部が失われ、機能していない場合に、多数の障害 (非常に不快な問題) が発生します。フルキャパシティで。そして、それへのトラフィックは、それが完全に機能しているという事実に基づいてバランスがとられており、過負荷になる可能性があります。

あるいは、たとえば、モジュール式デバイスの内部には高速 SerDe もあり、内部は非常に複雑であるため、バックプレーンで問題が発生します。転送要素間の符号は同期しているか、同期していません。一般に、多数の要素で構成される生産的なモジュラーデバイスは、原則として、その内部に同じ Clos ネットワークを含みますが、診断するのは非常に困難です。多くの場合、ベンダー自身でも診断することが困難です。

また、デバイスが劣化してもトポロジから完全に外れることはないという、多数の障害シナリオがあります。私たちのネットワークは大規模であるため、同一の要素間のバランスが積極的に使用されており、ネットワークは非常に規則的です。つまり、すべてが正常に動作している 1 つのパスは他のパスと何ら変わりません。単純に一部を失う方が有益です。トポロジからデバイスを削除すると、一部のデバイスは動作しているように見えても、一部のデバイスが動作しないという状況に陥ることがなくなります。

シングルチップ デバイスの次の優れた特徴は、デバイスがより良く、より速く進化することです。また、容量も優れている傾向があります。組み立てられた大規模な構造を円周上に配置すると、同じ速度のポートのラック ユニットあたりの容量は、モジュラー デバイスのほぼ 2 倍になります。単一チップを中心に構築されたデバイスは、モジュール式のものよりも著しく安価で、消費エネルギーも少なくなります。

しかし、もちろんこれには理由があり、デメリットもあります。まず、基数はほとんどの場合、モジュール式デバイスの基数よりも小さくなります。 128 ポートを備えた XNUMX つのチップを中心に構築されたデバイスを入手できれば、数百のポートを備えたモジュール式デバイスを問題なく入手できるようになります。

これは、転送テーブルのサイズが著しく小さくなり、原則として、データ プレーンのスケーラビリティに関連するすべてのサイズが小さくなります。浅いバッファ。そして、原則として、機能はかなり制限されています。しかし、これらの制限を理解し、時間内に注意して回避したり、単純に考慮したりすれば、これはそれほど恐ろしいことではないことがわかります。最近ようやく登場した基数 128 のデバイスでは、基数が小さくても問題はなくなり、スパインを XNUMX 層組み込むことができます。しかし、私たちにとって興味深いものを XNUMX つより小さいものを構築することは依然として不可能です。 XNUMX つのレベルでは、非常に小さなクラスターが取得されます。以前の設計と要件でさえ、依然としてそれを上回っていました。

実際、突然ソリューションが瀬戸際に陥ったとしても、拡張する方法はまだあります。サーバーが接続されている最後 (または最初) の最下位レベルは ToR スイッチまたはリーフ スイッチであるため、それらに 1 つのラックを接続する必要はありません。したがって、解決策が約半分に満たない場合は、単純に基数の大きいスイッチを下位レベルに使用し、たとえば 2 つまたは 3 つのラックを 1 つのスイッチに接続することを考えることができます。これもオプションであり、コストはかかりますが、非常にうまく機能し、サイズを約 2 倍にする必要がある場合には良い解決策となります。

要約すると、8 つのファクトリー層を持つ 2 レベルのスパインを持つトポロジーを構築しています。

物理学はどうなるのでしょうか？非常に単純な計算。 1 レベルのスパインがある場合、スイッチは 2 レベルのみになり、ネットワーク内にはサーバーからリーフ スイッチ、スパイン XNUMX、スパイン XNUMX までの XNUMX つのケーブル セグメントが存在することが予想されます。使用方法は、Twinax、マルチモード、シングル モードです。ここで、どのようなストリップが利用可能か、価格はいくらか、物理的な寸法は何か、カバーできる範囲は何か、アップグレード方法を検討する必要があります。

コスト的には何でも揃えられます。 Twinax は、アクティブ オプティクスよりも大幅に安く、端からフライトごとに取得した場合、マルチモード トランシーバーよりも安く、100 ギガビット スイッチ ポートよりも若干安くなります。また、シングルモード光学系よりもコストが低いことに注意してください。これは、シングルモードが必要なフライトやデータセンターでは、さまざまな理由から CWDM を使用するのが理にかなっていますが、パラレルシングルモード (PSM) は動作するのにあまり便利ではないためです。非常に大きなパックでファイバーが得られ、これらの技術に焦点を当てると、おおよそ次のような価格階層が得られます。

もう 100 つの注意: 残念ながら、逆アセンブルされた 4 ～ 25x28 マルチモード ポートを使用することはほとんどできません。 SFP28 トランシーバーの設計上の特徴により、100 ギガビット QSFPXNUMX よりもそれほど安価ではありません。そして、このマルチモードの逆アセンブリはあまりうまく機能しません。

もう 1 つの制限は、コンピューティング クラスターのサイズとサーバーの数により、データ センターが物理的に大きくなってしまうことです。これは、少なくとも 1 つのフライトを singlemod で実行する必要があることを意味します。繰り返しますが、ポッドの物理的なサイズにより、2 スパンの Twinax (銅線ケーブル) を実行することはできません。

その結果、価格を最適化し、この設計のジオメトリを考慮すると、CWDM を使用して Twinax の 1 スパン、マルチモードの 1 スパン、およびシングルモードの 1 スパンが得られます。これには、考えられるアップグレード パスが考慮されます。

これが最近の状況であり、私たちがどこに向かっているのか、そして何が可能なのかを示しています。少なくとも、マルチモードとシングルモードの両方で 50 ギガビット SerDes に移行する方法は明らかです。さらに、現在および将来の 400G のシングルモード トランシーバーの内容に注目すると、多くの場合、電気側から 50G SerDes が到着したときでも、レーンあたり 100 Gbps がすでに光に送られることができます。したがって、50 に移行する代わりに、100 ギガビット SerDes およびレーンあたり 100 Gbps への移行が行われる可能性は十分にあります。これは、多くのベンダーの約束によれば、すぐに利用可能になることが予想されているためです。 50G SerDes の最初のコピーがほぼ来年展開されるため、100G SerDes が最速だった期間はそれほど長くはないようです。そしてその後しばらくすると、おそらく相応の金額の価値が付くでしょう。

物理学の選択についてもう 400 つニュアンスがあります。原理的には、200G SerDes を使用して 50 または 128 ギガビット ポートをすでに使用できます。しかし、これはあまり意味がないことがわかりました。なぜなら、前に述べたように、当然のことながら、スイッチにはかなり大きな基数が必要だからです。必要なのは XNUMX です。そして、チップ容量が限られており、リンク速度を上げると、自然に基数が減少し、奇跡は起こりません。

また、飛行機を使用することで総容量を増やすことができ、特別なコストはかからず、飛行機の数を追加することができます。基数を失った場合は、追加のレベルを導入する必要があります。そのため、現在の状況では、チップごとに利用可能な最大容量を考慮すると、100 ギガビット ポートを使用する方が効率的であることがわかります。より大きな基数を取得します。

次の質問は、物理学がどのように組織されるかですが、ケーブル インフラストラクチャの観点からです。かなり面白い方法で組織されていることがわかりました。リーフ スイッチと第 1 レベルのスパインの間のケーブル配線 - そこには多くのリンクはなく、すべてが比較的単純に構築されています。しかし、1 つの平面を取り上げると、内部で何が起こるかというと、第 1 レベルのすべてのスパインを第 2 レベルのすべてのスパインに接続する必要があるということです。

さらに、原則として、データセンター内でどのように見えるかについていくつかの要望があります。たとえば、ケーブルを束ねて引っ張り、1 つの高密度パッチ パネルが 1 つのパッチ パネルに完全に収まり、長さの点で動物園がなくなるようにしたいと考えていました。私たちはこの問題を解決することができました。最初に論理トポロジを見ると、プレーンが独立しており、各プレーンを独自に構築できることがわかります。しかし、そのようなバンドルを追加し、パッチ パネル全体を 1 つのパッチ パネルにドラッグしたい場合は、1 つのバンドル内で異なるプレーンを混合し、光クロスコネクトの形で中間構造を導入して、組み立てられた方法から再パックする必要があります。あるセグメント上で、それらが別のセグメント上でどのように収集されるかという点で異なります。このおかげで、すべての複雑なスイッチングがラックを超えないという優れた機能が得られます。 Clos ネットワークでは「プレーンを展開する」と呼ばれることもありますが、何かを非常に強く絡み合わせる必要がある場合、すべてが 1 つのラック内に集中されます。個々のリンクに至るまで高度に分解したり、ラック間の切り替えを行ったりすることはありません。

ケーブル インフラストラクチャの論理構成の観点から見ると、次のようになります。左側の図では、マルチカラーのブロックは、第 2 レベルのスパイン スイッチのブロック (各 XNUMX 個) と、そこからのケーブルの XNUMX つの束を示しています。これらのケーブルは、スパイン XNUMX スイッチのブロックからの束と交差しています。 。

小さな四角は交差点を示します。左上は、そのような各交差点の内訳です。これは実際には、ケーブルが完全に 512 つのラックに収まるように再梱包する 512 x 2 ポートのクロスコネクト モジュールで、スパイン 1 プレーンが 2 つだけあります。そして右側は、この写真のスキャンで、スパイン XNUMX レベルの複数のポッドと、それがクロスコネクトにどのようにパッケージ化されるか、スパイン XNUMX レベルにどのように影響するかに関して、もう少し詳細に示しています。

見た目はこんな感じです。まだ完全に組み立てられていないスパイン 2 スタンド (左側) とクロスコネクト スタンド。残念ながら、そこには見るべきものはあまりありません。この構造全体は現在、拡張中の当社の大規模データセンターの XNUMX つに展開されています。これは進行中の作業です。見た目はさらに良くなり、記入内容も改善されるでしょう。

重要な質問: 私たちは論理トポロジーを選択し、物理学を構築しました。コントロール プレーンはどうなりますか?これは運用経験からよく知られており、リンク ステート プロトコルが優れているという報告が多数あり、それらを使用するのは楽しいことですが、残念ながら、密に接続されたトポロジではうまく拡張できません。そして、これを妨げる主な要因が 1 つあります。これが、リンク ステート プロトコルでのフラッディングの仕組みです。フラッディング アルゴリズムを取り上げて、ネットワークがどのように構成されているかを見ると、各ステップで非常に大きなファンアウトがあり、コントロール プレーンにアップデートがフラッディングされるだけであることがわかります。具体的には、このようなトポロジは、リンクステート プロトコルの従来のフラッディング アルゴリズムと非常にうまく混合できません。

BGP を使用することを選択します。 BGP を正しく準備する方法は、大規模データセンターでの BGP の使用に関する RFC 7938 に説明されています。基本的な考え方は単純です。ホストごとのプレフィックスの最小数、および一般にネットワーク上のプレフィックスの最小数、可能であれば集約を使用し、パス ハンティングを抑制します。私たちは、非常に注意深く、非常に制御されたアップデートの配布、いわゆるバレーフリーを望んでいます。更新がネットワークを通過するときに、一度だけ展開されるようにしたいと考えています。それらが下から始まる場合、それらは上に上がり、展開は XNUMX 回だけです。ジグザグがあってはなりません。ジグザグは非常に悪いです。

これを行うために、基盤となる BGP メカニズムを使用できるほど単純な設計を使用します。つまり、リンク ローカルで実行される eBGP を使用し、自律システムは次のように割り当てられます。ToR 上の自律システム、1 つのポッドのスパイン XNUMX スイッチのブロック全体上の自律システム、およびトップ全体上の一般的な自律システムです。ファブリックの。 BGP の通常の動作でも、必要なアップデートを配布できることを確認するのは難しくありません。

当然のことながら、アドレス指定とアドレス集約は、ルーティングの構築方法と互換性があり、コントロール プレーンの安定性が保証されるように設計する必要があります。トランスポートにおける L3 アドレス指定は、トポロジに関連付けられています。これがなければ、集約を実現することは不可能であり、これがないと、個々のアドレスがルーティング システムに入り込むことになります。そしてもう XNUMX つは、残念なことに、アグリゲーションはマルチパスとあまりうまく組み合わせられないということです。なぜなら、マルチパスがあり、アグリゲーションがある場合、すべてがうまくいき、ネットワーク全体が健全であれば、そこに障害はありません。残念ながら、ネットワークに障害が発生し、トポロジの対称性が失われるとすぐに、ユニットが発表された時点に到達し、そこからさらに進む必要がある場所に進むことができなくなります。したがって、これ以上マルチパスが存在しない場所に集約するのが最善です。この場合、これらは ToR スイッチです。

実際、集約することは可能ですが、慎重に行ってください。ネットワーク障害が発生したときに、制御された分解を行うことができれば。しかし、これは非常に難しい作業であり、私たちはこれを実行できるかどうか、追加の自動化や、BGP を正しく起動して目的の動作を実現する有限ステート マシンを追加することが可能かどうかさえ疑問に思いました。残念ながら、特殊なケースの処理は非常に明白ではなく複雑であり、このタスクは外部添付ファイルを BGP に接続しても十分に解決されません。

この点に関しては、RIFT プロトコルの枠組みの中で非常に興味深い研究が行われており、これについては次のレポートで説明します。

もう 1 つ重要なことは、多数の代替パスがある高密度トポロジでデータ プレーンがどのように拡張されるかです。この場合、いくつかの追加データ構造が使用されます。ECMP グループは、ネクスト ホップ グループを記述します。

障害がなく正常に動作しているネットワークでは、Clos トポロジに上がるときは 1 つのグループのみを使用するだけで十分です。ローカルでないものはすべてデフォルトで記述されているため、上がることができます。上から下、そして南に進むと、すべてのパスは ECMP ではなく、単一パスのパスになります。すべて順調。問題は、古典的な Clos トポロジの特徴であり、ファブリックの上部を見ると、どの要素においても、その下の要素へのパスが 1 つしかないことです。このパスに沿って障害が発生した場合、ファクトリの先頭にあるこの特定の要素は、まさに壊れたパスの背後にあるプレフィックスに対して無効になります。しかし、残りの部分については有効であり、ECMP グループを解析して新しい状態を導入する必要があります。

最新のデバイスではデータ プレーンのスケーラビリティはどのようになりますか? LPM (最長プレフィックス マッチ) を実行すると、すべてが非常に良好で、100 プレフィックスを超えています。ネクストホップグループについて話している場合、すべてがさらに悪く、2〜4です。ネクスト ホップ (または隣接) の説明を含むテーブルについて話している場合、これは 16k から 64k の範囲になります。そして、これが問題になる可能性があります。そして、ここで興味深い余談になります。データセンターの MPLS はどうなったのでしょうか?原則として、私たちはそれをやりたかったのです。

2つのことが起こりました。ホスト上でマイクロセグメンテーションを行ったため、ネットワーク上でマイクロセグメンテーションを行う必要がなくなりました。さまざまなベンダーからのサポートはあまり良くありませんでしたが、MPLS を使用したホワイト ボックスのオープン実装ではさらに良くありませんでした。そして、MPLS、少なくとも従来の実装は、残念ながら ECMP との組み合わせが非常に不十分です。だからこそ。

IP の ECMP 転送構造は次のようになります。多数のプレフィックスが同じグループと同じネクスト ホップ ブロック (または隣接、これはデバイスごとに異なるドキュメントで異なる呼び方になる場合があります) を使用できます。重要なのは、これが送信ポートとして記述されており、正しいネクストホップに到達するために MAC アドレスを何に書き換えるべきかということです。 IP の場合、すべてが単純に見えます。同じグループ、同じネクスト ホップ ブロックに対して非常に多くのプレフィックスを使用できます。

古典的な MPLS アーキテクチャは、発信インターフェイスに応じて、ラベルを異なる値に書き換えることができることを意味します。したがって、入力ラベルごとにグループと Next Hops ブロックを保持する必要があります。そして、残念なことに、これはスケールがありません。

私たちの設計では約 4000 個の ToR スイッチが必要で、スパイン 64 からスパイン 1 に向かって移動すると、最大幅は 2 ECMP パスだったことが簡単にわかります。 ToR を持つプレフィックスが XNUMX つだけ削除されたとしても、ECMP グループの XNUMX つのテーブルにかろうじて入ることができ、ネクスト ホップ テーブルにはまったく入りません。

セグメント ルーティングのようなアーキテクチャにはグローバル ラベルが含まれるため、すべてが絶望的というわけではありません。形式的には、これらすべての Next Hops ブロックを再度折りたたむことが可能です。これを行うには、ワイルド カード タイプの操作が必要です。つまり、ラベルを取得し、特定の値を指定せずに同じラベルに書き換えます。しかし、残念ながら、これは利用可能な実装にはあまり存在しません。

そして最後に、外部トラフィックをデータセンターに取り込む必要があります。どうやってするの？以前は、トラフィックは上から Clos ネットワークに導入されていました。つまり、ファブリックの上部にあるすべてのデバイスに接続するエッジ ルーターがありました。このソリューションは、小規模から中規模のサイズで非常にうまく機能します。残念ながら、この方法でトラフィックをネットワーク全体に対称的に送信するには、ファブリックの上部のすべての要素に同時に到達する必要があり、それらの要素が 100 を超える場合は、大規模な要素も必要になることがわかります。エッジルーター上の基数。一般に、これにはコストがかかります。エッジ ルーターの機能が高く、ポートの価格も高く、デザインもあまり美しくないからです。

別のオプションは、そのようなトラフィックを下から開始することです。 Clos トポロジが、下から、つまり ToR 側から来るトラフィックが 2 回の繰り返しでファブリックのトップ全体のレベル間で均等に分散され、ネットワーク全体に負荷がかかるような方法で構築されていることを確認するのは簡単です。したがって、外部接続を提供する特別なタイプのポッド、Edge Pod を導入します。

もう 1 つの選択肢があります。これは、たとえば Facebook が行っていることです。彼らはこれをファブリック アグリゲーターまたは HGRID と呼びます。複数のデータセンターを接続するために、追加のスパイン レベルが導入されています。この設計は、インターフェイスでの追加機能やカプセル化の変更がない場合に可能です。それが追加のタッチポイントである場合、それは困難です。通常、データセンターのさまざまな部分を分離する機能と一種の膜が存在します。このような膜を大きくすることに意味はありませんが、何らかの理由でそれが本当に必要な場合は、それを取り除き、できるだけ幅を広くして宿主に移す可能性を検討するのは理にかなっています。これは、たとえば、多くのクラウド オペレーターによって行われます。これらにはオーバーレイがあり、ホストから始まります。

どのような発展の機会があるでしょうか?まず第一に、CI/CD パイプラインのサポートを改善します。私たちは、テストした方法で飛行し、テストした方法で飛行したいと考えています。インフラストラクチャが大規模であり、テスト用にそれを複製することが不可能であるため、これはあまりうまくいきません。テスト要素を削除せずに本番インフラストラクチャに導入する方法を理解する必要があります。

より優れた計測器やより優れたモニタリングが不必要になることはほとんどありません。問題は、努力と利益のバランスです。相応の努力でそれを追加できれば、非常に良いです。

ネットワーク デバイス用のオープン オペレーティング システム。 RIFT など、より優れたプロトコルとより優れたルーティング システム。より優れた輻輳制御スキームの使用と、おそらく少なくともいくつかの時点でクラスター内に RDMA サポートを導入するための研究も必要です。

さらに将来を見据えると、高度なトポロジが必要になり、場合によってはオーバーヘッドの少ないネットワークも必要になります。新鮮なものとしては、HPC Cray Slingshot のファブリック テクノロジに関する出版物が最近出版されました。これはコモディティ イーサネットをベースにしていますが、オプションではるかに短いヘッダーを使用することができます。その結果、オーバーヘッドが削減されます。

すべては可能な限りシンプルに保つ必要がありますが、それ以上にシンプルにする必要はありません。複雑さはスケーラビリティの敵です。シンプルさと規則正しい構造が私たちの味方です。どこかでスケールアウトできる場合は、スケールアウトしてください。そして一般的に、今ネットワーク テクノロジーに携わることは素晴らしいことです。興味深いことがたくさん起こっています。ありがとう。

出所： habr.com