私はネットワークアーキテクトであり、気になります

データセンターで4x25に分類された100G



ネットワークアーキテクトの* aaSプロジェクトに関する仕事の基礎は、進化する建物をどのように構築するかです。 5階建ての建物のようで、4階建てになった後、さらに21か所が必要になり、地下トンネルで接続された家を取り付けることが必要になりました。 まだ中に居住者がいます、そして、彼らは下水道、給水とポーチを遮ることができません。



ええ、はい。 また、ネットワーク標準に​​は現在の問題があります（実際の要件から10年遅れています）。 ほとんどの場合、これは明らかな、一見、ソリューションを適用する代わりに、トリッキーな自転車を発明することを意味します。 もちろん、自転車はどこにでもあります。



相互接続されたクラウドプラットフォームとその隣にあるサービスがあります。 クラウドサーバーはネットワークにとどまります。 ネットワーク自体を提供するデバイスは、同じネットワークに固定されています。 クラウドクライアント機器が同じネットワークに接続している場合があります。 さらに、たとえば、インターネット上のチャンネルなど、多くのことが行き詰まっています。 つまり、ネットワークが存在する必要があり、誰かがそれを担当する必要があります。 プロジェクトはかなり大きく、あらゆる種類の複雑な関係（OpenStackパーツとVMwareパーツ、または他の* aaSがあります）があるため、単純に構成するだけでは不十分です。 このすべてを処理し、責任を負う何らかのエンティティが必要です。 もちろん、これは搾取です-私たちには素晴らしい仲間がいます。 しかし、彼らの主な仕事は悪用することです。



私の仕事は、数年後に何が起こるか、そして他のアーキテクトや製品の専門家が、パズルのすべての部分が正常に接続するようなネットワークを構築したいことを知ることです。 また、ベンダー、請負業者、顧客とも会います。すべての情報を考慮に入れて、すべての人の意見を聞き、リソースに関してどのように改善するかについての考えを頭の中に集めます。



一般的なシステムアーキテクトではなく、ネットワークアーキテクトが必要なのはなぜですか？ 彼はシステムアーキテクトになることができるため、ネットワークテクノロジーに特化しています。 これは、詳細を強調する単なる名前です。 ネットワークアーキテクトは、ビジネスタスクをテクノロジーに、お金をプロセスに変換します。 彼は彼の決定について「アップ」を詳細に報告し、ビジネスがそれを好めば-すべては良いです。 次に、ドキュメントを作成し、システムを動作させます。



ネットワークアーキテクトの特別な点は何ですか？ 私の意見では、彼はすべきです：

• 企業とデータセンターの両方、およびそれらの間で地理的に分散された複雑なネットワークの長年の経験を持っています。 年数を決定することは困難です。2年に1人は、他の人と同じくらい見たり、感じたりすることができ、10年ではできません。
• 主要なネットワークプロトコルを理解します。 キー-建築家のアプリケーションの場所に依存します。
• システムがアプリケーションとどのように機能し、ネットワークがその仕事で果たす役割、一方が他方にどのように影響し、反対方向に影響するかを理解します。
• さまざまなレベルの従業員とやり取りできる：マネージャーから他のアーキテクト、翻訳者としてしばしば語られるテクニカルサポートまで、しばしば対立するタスク間の「橋」ハードウェア/ソフトウェア/サービス）。 書くこと、話すこと、話すことができる必要があります。これは人々を悩ませたり、力を入れたりするべきではありません。 プロトコルを知るだけでは十分ではありません。プロトコルを説明できる必要があります。

仕事はどのように見えますか？

歴史的に作成されたネットワークアーキテクチャがありました。 私たちが正しいと思ったように、当時の現実によると、クラウドを構築すると、これが基礎になりました。 時間が経つにつれて、インフラストラクチャが成長し、変化しました-そしてしばらくして、社内顧客として私たちを喜ばせることがなくなりました。 そうでなければ、数年後にネットワークを確認し始め、どのようにして何がボトルネックになるかを見始めました。 簡単に言えば、ある時点で、ネットワークのいくつかの品質を変更する必要があることが明らかになりました。 そして、価値を維持しながら、できれば。



専門家の委員会が来ました。 システムアーキテクトは彼らの紹介と希望を与え、オプションとニュアンスを受け取り、共同で制限と開発について議論しました。 そして、解決策を計算するために滞在しました。 そして彼に同行します。



インフラストラクチャの開発中に新しい技術が登場したため、私はそれらに感謝し、蓄積された経験に感謝し、さまざまなオーバーヘッドは不要であり、何をどのように変更すべきかを提案しました。 システムアーキテクトは、パフォーマンス、速度、およびスケーラビリティの観点からビジョンを捨てました。これを考慮しました。 オペレーションはウィッシュリストとウィッシュリストを追加しました-これを考慮しました。



システム設計者が設定した要件の1つは、25 Gb / sのイーサネットポートを有効にする機能でした。 以前は、すべてがN * 10 Gbで行われ、40 Gb / sのインターフェイスは、10 Gb / sで4組、100 Gb / s-10 Gb / sで10個でした。 これで、100個の4x25を取得できるため、操作が簡単になり、SCSの要件が少なくなります。 はい、プロトコルで何かを掘りたいと思いました。 ターゲットは次のとおりです。

詳細

25Gイーサネット-10GbEリンクと比べて、ネットワークおよびサーバー機器の価格に大きな違いはありません。 ポートに関しては、価格はほぼ同じですが、速度の向上は非常に快適です。 そして、顧客は今後数年間で間違いなくそれを必要とします。 同時に、100 GBスイッチ間のジョイントに切り替えました。 ストリップを備えたデータセンター内のネットワークでは、データセンター間よりもはるかに簡単です。光学系とトランシーバーは安価です。





DACケーブル10および25 Gb / s-区別しないようです



ターゲットアーキテクチャは、トポロジCLOS（リーフ＆スパイン）に基づいて構築されます。 古いスパニングツリースイッチマージテクノロジーを次に示します。



そして、ここに新しいものがあります：



ご覧のとおり、各スイッチは独立しています。 コントロールプレーン（コントロール）とデータプレーン（データ転送）があります。 制御レベルは、スイッチOSとルーティングおよびシグナリングプロトコルによって決定されます。 データ転送層の特徴は、ポートからポートへ送信されるデータをスイッチが処理することです。



従来、ポート容量を増やし、主にLAG（リンクアグリゲーショングループ-異なるスイッチ間の2つ以上の物理的なフェールセーフリンク）を収集するために、単一のシャーシシャーシ内のスタンドアロンスイッチまたはスイッチ（インターフェイスカード）を使用するか、個別のスイッチを組み合わせました仮想シャーシに。 仮想シャーシではすべてが便利です。単一のコントロールプレーンは単一の制御下で異なるスイッチを組み合わせ、エンジニアは個々のスイッチを1つのシャーシ内のインターフェイスカードと見なします。 しかし、シャーシには欠点もあります。コントロールプレーンをしっかりと結ぶと、仮想シャーシ内のすべてのスイッチが故障する可能性があります。 これは、この世界に仮想シャーシを配置する場所がないことを意味するものではありませんが、タスクとプロセスにとっては、それらの利便性と信頼性が劣っています。



脊椎レベルは、あるノードから別のノードへの転送のみであり、クライアント接続はありません。



スパニングツリーは古くから実績のあるプロトコルであり、その主な目的はリングトポロジのループを回避することです。 ループはどこから来たのですか？ 上の写真を見てください。 ループはリンクの冗長性の結果です。 リングにつながる可能性のあるリンクはブロックされます-事故の場合とツリーの再構築後にのみ使用されます。 STPタイマーをツイストできます。ツリーの再構築時間を短縮する追加のメカニズムを使用できますが、ロックされたリンクは残ります。 ツリーの再構築に関する問題は、再構築時間の損失でもあります。100Mbit / sと100 Gb / sが同時に存在する場合、最小の再構築時間でさえ、より多くの信号（データ）が失われます。 VLAN単位のスパニングツリーまたはMSTPリージョンを使用しても、タスクの問題は解決しません。VLANのロードは非常に異なります-リンクですべてまたは自動的にそれらを配布することは困難です。



セグメント化にVLANを使用すること自体もスケーリングの問題になります。単一のドメインでは4000を超えることはできません。お客様は、ハイブリッドシステムを構築することがよくあります。 顧客とクラウドインフラストラクチャの結合-95％のケースでVLANを使用。 カップル。 その後、さらに2つ追加します。 そしてもう1つのシステムをクラウドに広げます...そしてもう1つ...入口でVLANが交差することは問題ではありません。いつでも「リマップ」できます（リマップ-顧客とのジャンクションでタグを変更します）。 ただし、VLANの数と、STPを使用したリンクによるVLANのダウンロードには問題があります。



そして、特定の代替手段はありません。 多くのポートを備えた大きなシャーシが必要なので、誰でも十分です。 ペア（予備用）！ しかし、1つのデータセンターの異なる部屋に物理的に均等に分散されたさまざまなセグメントがあり（これは、アーキテクチャと「歴史」の両方のさまざまな理由で発生しました）、すべてのホストをこのカップルに物理的に接続することは難しく、操作するのはさらに困難です。 また、このカップルが落ちた場合、最悪のシナリオではデータセンター全体が失われます。すべてのホストが互いに失われます。 また、セグメントごとに遅延とバッファリングに異なるパラメータが必要であり、1つのシャーシ内で達成するのはより困難です。 VLANを使用したバックアップが必要な場合、MLAGを使用せずに別のスイッチへのホストリンクを予約することはできません。 したがって、VLANでのトラフィックのトンネリングは、タスクには不十分です。



SPBとしても知られるIEEE 802.1aqとその「キラー」-TRILL-オープンスタンダードを考えてみてください。 しかし、ベンダーはこれらのプロトコルのネットワーク機器を実際にサポートしていません-彼らはそれらが好きではありません。 サプライヤーをすぐに2〜3に制限します。 数年後、既存のプラットフォームでのサポートを失うか、新しいプラットフォームで同じベンダーを取得することさえできません。 Cisco FabricPath-少なくともほぼTRILL、ただし完全なベンダーロック。



スマートで強力、それ自体が何か-SDN！ Big Switch、Plexxi、またはOpenFlowベースのソリューションは非常に美しく、紛れもない利点があります。 しかし、彼らには完全なベンダーロックがあり、サービスプロバイダーとしては受け入れられません。 このプロジェクトのためにそれらを放棄しました。



そこで、EVPNとVXLANを使用してIPでLeaf＆Spineにアクセスしました。



ここで、気を散らし、Leaf＆Spineを構築するための2つのオプションがあると言う必要があります。オーバーレイを使用してL2ファクトリーまたはL3ファクトリーをL2を工場に「転送」します（また、オーバーレイが必要です。 IP）。 冗長ファクトリノードでL2ファクトリを構築する場合、VLANを使用する必要があります。VLANの数は4Kに制限されていますが、ファクトリ内で異なるVLANドメインを使用することはできません。 それらの一意性を確保する必要があります。 アクティブ-アクティブトポロジでは、すべてのノードでマルチシャーシリンクアグリゲーションが利用されている（MC-LAG）を使用する必要もあります。 L3ファクトリーは、オーバーレイの柔軟性を高め、VLANの数と一意性に依存しません。 オーバーレイとして、ネットワーク機器のASIC（およびもちろん、スイッチソフトウェア）でサポートされているものを使用できます。現在はMPLSおよびVXLAN（RFC 7348）です。 VXLANは「シグナリング」する必要があります。これには、静的構成、マルチキャスト、MP-BGP EVPN（マルチプロトコルボーダーゲートウェイプロトコルイーサネット仮想プライベートネットワーク）またはコントローラーを使用できます。 EVPNは、オープンで業界標準であるため、よりスケーラブルで安価なオプションとして選択されました-理論的には、ハードウェアとソフトウェア間のクロスベンダーの相互作用を実現できます（たとえば、「シンプル」または「基本」BGPで発生）。 プロトコルは（SPBやTRILLとは異なり）ルートに新しいシグナリングを導入せず、データプレーンに制限を課しません（別のカプセル化の要件はありません-たとえば、Genveとは異なり、VXLANまたはMPLSが適しています）。 このプロトコルは、マルチキャストなどの追加機能や設定も必要としません。 EVPNアドレスファミリには、レイヤー2（MAC）とレイヤー3（IP）の両方の情報が含まれており、MAC / ARP学習のローカライズとともに、EVPN分散によるネットワークのフラッディングを最小限に抑えることができるARP抑制メカニズムもあります：各ネットワークデバイスは、「近隣」から受信したデータに基づいてトポロジを構築します。 もちろん、これは重要なポイントです。誰かにとって、制御とソリューションの集中化はプラスになります（たとえば、SDNのようなコントローラーの存在）。 EVPNを使用すると、マルチホーミングLAGを実現できます。エンドホストは、同じスイッチに接続されていると「考え」ます。 EVPNがもう5年間生きていないことを考えると、彼の将来がどれほど強いかは不明です。 一般に、プロトコルを変更せずにベンダーを変更できます。 私たちにとって重要なのは、規格の一部が釘付けにされていないことです。すでにドラフトモードで5年目です。 一部のベンダーは、記録された標準を独自の方法で実装しました。それぞれが独自の量とシナリオで実装されていました。 新しいテクノロジーの完全な機能セットを一か所に持っているベンダーはありません。 たとえば、異なる方向の異なる種類のルートのセット。 長年の運用と大規模なインストールベースにより、コードはまだなめられていません。

いつか動物園は終わります

上記のすべてのソリューションを見ると、原則として、これらはすべて、いつかわかりやすい1つの標準によって決定されることがわかります。 問題は、多くのベンダーが存在し、誰もが自分のベンダーを望んでいることであり、ネットワーク自体はゆっくりと発展しています。 ある日、私たちの建築家は単純なスクリプトに置き換えられるかもしれませんが、これはまだ非常に遠いです。



したがって、ハードウェアとソフトウェアの文書化されていない機能を詳しく調べたい場合は、説明書に記載されていないことについて多くを学び、ベンダーの無料テスターに​​なり、ネットワークアーキテクトにアクセスしてください。 「どのような馬鹿を設定したのか？」ではなかったので、ビジネス、アーキテクト、製品の専門家、運用者とのチームゲームが必要です。 たとえば、一般に論理的には設計プロセスで必要とされない操作について話さない場合、ナットを手で回した場合にのみ表示される多くの機能がわからない場合があります。 一般的に、チームゲーム。 一般に、ネットワークアーキテクトとは、アーキテクト、翻訳者、そして船を再建する人です。 唯一の違いは、これが彼の船であり、皆さんと一緒に作業すれば、宇宙的にクールになるということです。

このテキストは、Technoserv CloudのネットワークアーキテクトであるOleg Alekseenkoによって作成されました。