クラウドネイティブのデータセンターネットワークを構築するにはどうすればよいでしょうか?

[[429690]]

私たちの仕事は、たくさんの情報を読まなければなりませんが、この業界には細分化された分野がたくさんあります。私たちの時間は限られており、現代人は読書に割ける時間がさらに少なくなっています。一つの疑問は、深く読むべきか、それとも広く読むべきかということです。

私は最近、Shopify[1]の元開発チーム責任者であるサイモン・エスキルセン氏のインタビューを読みました。サイモン・エスキルセンは高校生でしたが、Shopify の創業年に入社し、会社とともに技術マネージャーに成長しました。彼は学位を持っていないが、多読を通じてコン​​ピューターと経営の知識を学んだという。サイモン・エスキルセン氏はインタビューの中で、T 型人間、つまり 1 つの分野に深く精通しながらも、複数の分野に幅広い知識を持つ人間になることを目指していると述べています。

以前の記事では、分散コンピューティング、ストレージ、調整などのトピックについて説明しましたが、ネットワークの側面については説明していませんでした。 「SRE: Demystifying Google Operations」の中で、私に深い印象を残した一文があります。「UNIX システムの内部詳細と 1～3 層のネットワーク知識は、Google が最も重視する 2 つの追加技術力です。」

私のネットワークに関する知識は比較的乏しく、最近たまたま仕事でネットワーク アーキテクチャ関連の知識を設計していたので、10 月に中断して、最新のデータ センター ネットワーク アーキテクチャに関する知識を読み始めました。読者の皆さんも私と一緒に考えてみてください。新しいデータセンター ネットワーク アーキテクチャを設計するように依頼されたら、どうしますか?

この答えは、O'REILLY の新しい本「Cloud Native Data Center Networking」にあります。私はもともと原書を読みましたが、本に出てくる英語のインターネット用語の一部が理解できませんでした。最近中国語版が出版されたので、読んでメモを取ってみました。

新しいネットワークアーキテクチャが必要な理由

アプリケーション層が変更されなければ、それについて議論する必要はありません。クラウド ネイティブ データ センター ネットワークについて言えば、このアーキテクチャは最新のクラウド ネイティブ アプリケーション向けに設計されています。では、最新のクラウドネイティブ アプリケーションの特徴は何でしょうか?

この本では、「アプリケーション ネットワーク」アーキテクチャの進化は、次の図に示すように 4 つの段階を経てきたと述べられています。

1. モノリシックアプリケーション

• メインフレーム上で実行
• ネットワークトラフィックは小さく、プロトコルはプライベートです

2. クライアントサーバー（C/S）アーキテクチャ

• ワークステーションとPCの台頭
• LAN が登場し始め、ネットワーク トラフィックが増加し、イーサネット、トークン リング、FDDI が最大 100Mbps の速度で最も人気のある接続になりました。結局、イーサネットとTCP/IPが勝利した

3. Webアプリケーション

• コンピューティング能力が向上し続けると、CPU のパフォーマンスが過剰になり、アプリケーションが仮想マシンで実行されるようになり、Windows が主流になり、Linux は十分に成熟していませんでした。
• ギガビットイーサネットがエンタープライズネットワーク相互接続の標準となる

4. マイクロサービス

• Google の分散システムは、南北トラフィック (クライアントとサーバー間) から東西トラフィック (サーバー間) への歴史的な変化をもたらしました。 Linuxが成熟し、クラウドが台頭し、マイクロサービスとコンテナの時代が始まる
• 10Gネットワ​​ークが主流となり、ネットワーク速度は向上し続けている

分散アプリケーションの大きな変化によってネットワークが不意を突かれたことがわかります。従来のネットワークはなぜ「ペースを維持」できないのでしょうか?

上の図は従来のネットワークを示しています。このタイプのネットワーク設計は、「アクセス集約コア」アーキテクチャと呼ばれます。コンピュータはアクセス スイッチに接続され、その上にはコア ネットワークに接続された 1 組の分散集約スイッチがあり、アクセス層を外部ネットワークに接続します。

アクセス集約コア ネットワークは、次の 3 つの理由からブリッジング テクノロジに大きく依存しています。

• データ転送チップの出現、このハードウェア技術は当初ブリッジングのみをサポートしていた
• IPプロトコル以外のプロトコルを備えたエンタープライズ固有のネットワークソフトウェアスタック
• スイッチ ネットワークにおけるゼロ コンフィギュレーションの利点は、ルーティング ネットワークはブリッジ ネットワークよりもコンフィギュレーションが難しく、人為的なコンフィギュレーション エラーがネットワーク障害の第一または第二の原因となることです。

ルーティングとブリッジングの違い: ブリッジングは、OSI ネットワーク モデルの第 2 層であるリンク層で機能します。スイッチまたはブリッジは MAC アドレスに基づいてデータを交換し、リンク層はデータ フレームを交換します。ルーティングは、OSI の第 3 層であるネットワーク層で機能します。ルータは IP アドレスに基づいてターゲット アドレスを見つけ、ネットワーク層はデータ パケットを交換します。

従来のネットワークは成功していますが、ブリッジ ネットワークには依然として次の制限があります。

1. ブロードキャスト ストームとスパニング ツリー プロトコル (STP) の影響
2. 洪水は負担をもたらす
3. IP 層の冗長設計では、集約スイッチの可用性を高めるために 2 つのスイッチが同じ IP アドレスを使用する必要がありますが、同時にこれをサポートするルータは 1 つだけです。この目的のために、これをサポートするために FHRP プロトコルが発明されました。

転送ネットワークでは、各パケットは送信元アドレスと宛先アドレスの 2 つの MAC アドレスを伝送します。ブリッジは、自身の MAC アドレス テーブルで宛先 MAC アドレスを検索します。認識できない場合は、パケットを受信したインターフェイスを除く他のすべてのインターフェイスにパケットを送信します。ブリッジが自身の MAC アドレス テーブルで転送するデータ パケットの宛先 MAC アドレスを見つけられない場合に、データ パケットをすべてのポートに送信する動作をフラッディングと呼びます。

アクセス集約コア モデルは、南北トラフィックが中心となるクライアント サーバー アプリケーション アーキテクチャに非常に適しています。最近では、サーバー間アーキテクチャが増え、アプリケーションの規模も大幅に拡大しています。アクセス集約コア モデルには次の問題があります。

1. スケーラビリティがない

• 洪水は避けられない
• VLAN の最大数は 4096 です。
• ARP 負荷: 集約スイッチは多数の ARP に応答する必要があり、CPU 使用率が過度に高くなります。
• スイッチと STP の制限。理論的には、集約スイッチを追加すると東西帯域幅を増やすことができますが、STP は 2 つ以上の集約スイッチをサポートしていません。

2. 複雑さ。ブリッジングネットワークでは、STP、FHRP、リンク障害検出、ベンダー固有のプロトコル（VTPなど）など、多くのプロトコルのサポートが必要です。

3. 障害ドメイン 粗粒度の障害が発生しやすい。例えば、1つのリンクに障害が発生すると、帯域幅が半分になる。

4. 予測不可能性。コンポーネントが多すぎるとネットワークが予測不可能になり、障害箇所の特定が難しくなる可能性がある。

敏捷性の欠如。クラウド コンピューティングの分野では、テナントはリソースを継続的に使用または破壊しており、VLAN では、ネットワーク内の各ノードが適切に動作するために VLAN 情報を使用して正しく構成されている必要があります。 VLAN の追加または削除は、時間と労力を要するプロセスです。

ブリッジング技術の支持者は諦めず、これらの問題に対する多くの解決策を提案してきましたが、現代のエンタープライズ データ センターで使用されているものはほとんどありません。

クラウドネイティブ データセンター インフラストラクチャは、非常にスケーラブルなネットワーク アーキテクチャを構築することを目指しており、Clos はそのアーキテクチャです。

クロストポロジー

Clos トポロジは、下の図に示すように、発明者である Charles Clos にちなんで名付けられました。このトポロジは、リーフ スパイン トポロジ (またはスパイン リーフ アーキテクチャ) とも呼ばれます。

上の写真では:

• 背骨スイッチ。目的はただ 1 つ、異なるリーフ スイッチを接続することです。コンピューティング ノードはスパイン スイッチに接続されることはありません。
• リーフスイッチ。サーバーはリーフ スイッチを介してネットワークに接続されます。リーフ スイッチは互いに直接接続されるのではなく、スパイン スイッチを介して互いに接続されます。

Clos トポロジでは、任意の 2 つのサーバー間に 3 つ以上のパスが存在するため、東西トラフィックをサポートする大容量ネットワークが実現します。従来のネットワークと比較して、Clos アーキテクチャは優れた水平スケーラビリティも備えています。

• リーフスイッチとサーバーを追加してシステム容量を拡張する
• スパインスイッチを追加して帯域幅を拡張する

「アクセス集約コア」は、垂直拡張のために、より強力な集約スイッチにのみ置き換えることができます。

Clos アーキテクチャの詳細

1. Clos アーキテクチャには次の機能もあります。

2. リーフとスパインでは、同様の小型スイッチを使用してネットワークを構築できます。

基本的な相互接続モードとしてのルーティング

Clos は STP を使用せず、単一ラック内での直接ブリッジングのみをサポートします。ラック間のブリッジングでは、より最新のネットワーク仮想化ソリューション (VXLAN など) が使用されます。

3. クローズ収束比

1:1 の収束比を持つネットワークは非ブロッキング ネットワークとも呼ばれ、アップリンク帯域幅がダウンリンク帯域幅と等しくなります。スパインスイッチとリーフスイッチの両方がnポートスイッチである場合、1:1の収束比でClosトポロジに接続できるサーバーの最大数はn^2/2です。

4. リンクレート

スイッチ リンクがサーバー リンクよりも高いレートを使用する場合、同じコンバージェンス比をサポートするために使用できるスパイン スイッチの数が少なくなります。

5. 実用的な制限

冷蔵、キャビネット、放熱、サーバーの配置などの制限により、上記の理論をそのままデータセンターに実装することはできません。通常、1 つのキャビネットには 20 台または 40 台のサーバーを収容できます。その結果、スパイン ポートの数は多くなり、リーフ ポートの数は少なくなります。機器メーカーは通常、異なるスパイン スイッチとリーフ スイッチを提供します。

6. 細分化された障害ドメイン

• スパイン スイッチが 2 つ以上ある場合、1 つのリンク障害によって災害が発生することはありません。
• リーフからスパインへのリンクに障害が発生した場合でも、残りのリンクは引き続き全帯域幅を使用でき、障害の範囲は最小限に抑えられます。
• 体系的な制御プレーン障害はネットワーク全体に影響を及ぼす可能性がありますが、「アクセス集約コア」ネットワークでは体系的な障害（ブロードキャスト ストームなど）は発生しません。

Closアーキテクチャの拡張

数万台または数十万台のサーバーをサポートする大規模なデータセンターを構築する場合は、次の図に示すように、3 層の Clos トポロジを拡張する必要があります。拡張方法は 2 つあります。

• 上図(b)に対応する仮想シャーシモデル(Facebook)
• ポッドモデル（マイクロソフト、アマゾン）、上図（c）に対応

拡張された 3 層 Clos トポロジの最上位スイッチは、「スーパー スパイン スイッチ」と呼ばれます。

2 つのモデルの長所と短所の比較:

• アプリケーションとネットワーク モデルのマッチングを検討します。
  • 仮想シャーシ モデルには 5 つのホップがあり、単一のアプリケーションを実行するのに適しているため、Facebook はこのモデルを使用します。
  • ポッド モデルでは、同じポッドへのホップが平均 3 回、他のポッドへのホップが平均 5 回であるため、クラウド サービスの提供に適しています。したがって、Microsoft と Amazon はこのモデルを採用しています。
• データ センターの拡張を考慮すると、両方のモデルとも、特定の容量に対して同じ数のスイッチが必要ですが、次のようになります。
• 仮想シャーシ モデル内のレイヤー 2 スイッチの数はコンバージェンス比を満たす必要があり、十分なリーフ スイッチが提供される必要があります。
• ポッド モデル トラフィックがすべてポッド内にある場合は、最初に少数のスーパー スパイン スイッチを展開できます。

Clos トポロジの影響とベストプラクティス

Clos トポロジには次のような効果があります。

• 失敗とトラブルシューティングを再考します。スイッチは固定されており、単一であり、故障の種類は単純であり、故障したスイッチは直接交換できる。
• 配線。 Clos トポロジでは、多数のケーブルを管理する必要があります。ケーブル検証テクノロジー（PTM または Ansible）を使用してケーブルを検証できます。
• 固定式スイッチにより在庫管理が簡素化されます
• スイッチの数が多いため、ネットワークを手動で構成することは不可能であり、ネットワークの自動化が不可欠です。

Clos トポロジのベストプラクティス:

• スパインとリーフのリンクは単一のままにし、帯域幅を増やすために複数のリンクを使用せず、スパインまたはリーフを追加して帯域幅を増やします (例: 複数のリンクは BGP エラーを引き起こす可能性があります)。

• スパイン スイッチはリーフ ノードを接続するためにのみ使用され、余分な作業によってスパイン スイッチは意図したトラフィック シェアよりも多くのトラフィックを受信することになります (シンプルにすることは、デメリットではなくメリットです)。
• スパイン ノードとリーフ ノードに同じボックス スイッチを使用します。より多くのポートを持つフレーム スイッチをスパイン ノードとして使用しないでください。理由は、1. 3層Closへの拡張が難しいため。 2. 資産管理が複雑になる3. 失敗の原因はより複雑です。

この本には、LinkedIn と Dropbox が一貫性のないスイッチを使用したことを後悔していると書かれています。

この記事はWeChatの公開アカウント「Duo Ketang」から転載したものです。下のQRコードからフォローできます。この記事を転載する場合は、Duoketangの公式アカウントまでご連絡ください。