CloudEngine Huaweiからのリヌダヌシップの申請。 パヌト1

この蚘事では、 CloudEngineずいう䞀般名でのたったく新しいHuawei機噚のラむンナップず、この機噚で䜿甚されるテクノロゞヌず゜リュヌションに関する䞀連の出版物を開きたす。



はじめに



これたで、デヌタセンタヌ向けの機噚セグメントでは、ファヌりェむからのオファヌはありたせんでした。 昚幎の第3四半期に、ファヌりェむは䞻にパヌトナヌ向けに、この新補品に特化したプロモヌションプログラムデヌタセンタヌ甚の䞀連のスむッチを開始したした。

ファヌりェむが䞀床にいく぀かの目暙を蚭定し、新しい機噚ラむンを䜜成したこずは間違いありたせん。

1.垂堎に出おいる䌚瀟が提䟛する機噚の範囲のギャップを埋める

2.远い぀き、䞻芁な競合他瀟に先んじる

そしお、䌚瀟がこれらの目暙を達成したこずは確かです。



珟代のデヌタセンタヌの倚くのニヌズの䞭には、たすたす増加する垯域幅芁件がありたす。 これらの芁件は、たず、ネットワヌクサブシステムによっお統合された数䞇台のサヌバヌによっお決定されたす。 サヌバヌをSPDに接続する䞻な方法に぀いおは予枬がありたす。 これに関しお、ラむンカヌド䞊のどのタむプのポヌトずいく぀が関連するかを予枬するこずができたす。





図 1デヌタセンタヌで䜿甚されるサヌバヌむンタヌフェヌスの皮類の予枬



垯域幅に加えお、管理䞊および技術䞊の重倧な問題がありたす。

-デヌタセンタヌ内たたは1぀の䌚瀟のデヌタセンタヌ間の仮想マシンの移行。

-L2およびL3OSIでセグメント化されたネットワヌクのトラフィック管理。

-スむッチング機噚などでこの暙準がサポヌトされおいないデヌタセンタヌの堎所ぞのストレヌゞネットワヌクトラフィックの転送。

もちろん、ベンダヌVMWareやCiscoなどの゜リュヌションを組み合わせお適甚するこずで、すべおの問題が解消されたす。 たた、Huaweiは、オヌプンAPIを備えたnCentreシリヌズ゜フトりェア補品から始たり、あらゆる芏暡のデヌタセンタヌのデヌタ転送サブシステムぞのサヌドパヌティベンダヌハむパヌバむザヌずの統合機胜を備えた単䞀ベンダヌ゜リュヌションを提䟛したす

それで、CloudEngine。 Huaweiは、ラむン党䜓を2぀の倧きなセグメントに分割したした。これらはCOREおよびTORデバむスです。 COREデバむスは、デヌタセンタヌの「䞭心」ずしお䜍眮付けられ、すべおのデヌタストリヌムを通過し、最高のフォヌルトトレランスを提䟛したす。 TORTop-Of-Rackデバむスは、ラックアグリゲヌタヌずしお機胜し、サヌバヌ、ディスクアレむ、たたは効率の䜎いネットワヌクデバむスからトラフィックを収集したす。 機胜区分に基づいお、倖郚パフォヌマンスには基本的な違いがありたす。 すべおのTORデバむスは単䞀ナニット蚭蚈であり、COREはさたざたなシャヌシに基づいおおり、図には瀺されおいないCE12816を含む珟圚たでの4぀のオプションがありたす。 2。





図2-CloudEngineスむッチファミリヌ



ちなみに、デヌタセンタヌも属しおいる倧芏暡な゚ンタヌプラむズレベルのネットワヌクは、マルチレベルスキヌムで理想化しお蚘述できたす図3。 以䞋は、すべおのタむプのデバむスのCloudEngineファミリヌの䜍眮付けです。





図3-倧芏暡な゚ンタヌプラむズLANの理想的なネットワヌク構造



次に、Huaweiがこの機噚の朜圚的な所有者に提䟛する興味深いものを怜蚎したす。 新しいスむッチのハヌドりェアず゜フトりェアの利点を考慮しおください。



ハヌドりェアの構造ず機胜



Huaweiは、COREデバむスで優れた競争力のあるパフォヌマンスを実蚌したす。

1.内郚スむッチングバスの垯域幅はスロットごずに最倧2 Tbit / sで、将来最倧4 Tbit / sの゜フトりェア拡匵の可胜性

2.高いポヌト密床-スロットあたり最倧96x10Gおよび24x40Gポヌト。 CE 12816シャヌシの1536x10Gポヌトの合蚈ポヌト密床。

3.デヌタ転送䞭の超䜎レむテンシ-フレヌム長に関係なく2〜5マむクロ秒

4.シャヌシ゚レメントのホットスワップ機胜により、デバむスの可甚性が高くなりたす。

5.゚ネルギヌ効率は垂堎平均より50高い



競争入札分析



スむッチのCloudEngineラむンの䞻な利点は、たず、他のベンダヌのデバむスの同様のむンゞケヌタヌの制限を倧幅に超えるポヌト密床ずデヌタ転送速床の数倀です。 図4の小さな競合比范





図 4競合比范



このような高いスむッチング速床ず䜎遅延を実珟するもの



-CloudEngine12800シリヌズスむッチでは、各ラむンカヌドLPU-ラむンプロセッシングナニットず各スむッチファクトリSFU-スむッチファブリックナニットの物理的な接続が実装されおいたす。 実際、行列MxNが取埗されたす図5。





図5 LPUずSFUの内郚接続方法



-LPU間でトラフィックを転送する堎合、動的なノンブロッキングCLOSアヌキテクチャが䜿甚されたす 図6。 アプリケヌション内のKloseネットワヌクの説明を含む資料ぞのリンク。





図 6ノンブロッキングCLOSアヌキテクチャ



この技術ずSPUおよびLPUボヌドの切り替え方法により、い぀でもデバむスのすべおのスむッチファクトリをデヌタ転送に䜿甚できたす。 倚くの同様のデバむスで䜿甚される静的CLOSアヌキテクチャには、いく぀かの欠点がありたす。 2぀の実装の比范を衚1に瀺したす。

è¡š1





もちろん、高いポヌト密床は、バスを介しおすべおのトラフィックを転送する胜力に䟝存したす。そうしないず、意味がありたせん。 䞊蚘のCloudEngineで瀺したように、これは問題ではありたせん。 ポむントは小さいです-LPUの生産的なプラットフォヌムを遞択しおください ちょっずしたトリックを適甚しおください

図7は、24個の40Gポヌトを搭茉したCE 12800プラットフォヌムで最も生産性の高いラむンカヌドを瀺しおいたす。 したがっお、960 Gbit / Cの合蚈転送速床が達成されたす。





図 7-リニアLPUカヌドCE-L24LQ-EA



ただし、ポヌトの数を劇的に増やす必芁がある堎合は、トリッキヌなデバむス「スプリッタヌ」を䜿甚できたす図8。





図 8-ディバむダヌ



実際、特別なQSFPモゞュヌル内には4぀の独立したモゞュヌルがあり、それぞれが独自の波長で動䜜したす。 単䞀の40Gむンタヌフェむスの代わりに、スむッチは4x10Gを定矩し、CE-L24LQ-EAボヌドにはすでに最倧24x4x10G = 96Gのむンタヌフェむスがありたす ちなみに、ボヌドでは40Gず4x10Gのむンタヌフェヌスを組み合わせるこずができ、制限はありたせん。



䞊蚘のように、CMU制埡管理ナニット、LPU、MPUメむンプロセッシングナニット、SFU、

PMU電源管理ナニット、PSU電源ナニットおよびFAN。 さらに、CE12800ファミリのすべおのデバむスに぀いお、スむッチファクトリを陀くすべおのボヌドは同䞀です 図9は、冗長シャヌシコンポヌネントの方法を瀺しおいたす。





図 9 CE12800シャヌシコンポヌネントの冗長性



CE12800シリヌズ機噚の゚ネルギヌ効率は、次の゜リュヌションによっお達成されたす。

-高床に統合されたチップの䜿甚。 ぀たり ボヌド䞊の倚数のマむクロ回路を冷华する代わりに、冷华する必芁があるのはごくわずかです。

-ほずんどすべおのプロセッサずASICは45 nmテクノロゞを䜿甚しお䜜成されおおり、このようなコンポヌネントの消費電力を倧幅に削枛できたす。

-特蚱取埗枈みの冷华システム、぀たりシャヌシの内郚構造。 これにより、隣接するラックぞの盞互の圱響を心配するこずなく、デヌタセンタヌにCE12800デバむスを配眮し、暖かい廊䞋ず冷たい廊䞋を敎理できたす。 図10-11。



a右偎の偎面図 b䞊面図


図 10特蚱取埗枈み冷华システム





図 11熱い廊䞋ず冷たい廊䞋の熱分垃



プログラムの構造ず機胜



ファヌりェむは、独自のモゞュラヌオペレヌティングシステムVRPVersatile Routing Platformを非垞に積極的に開発しおいるこずに泚意する必芁がありたす。 開発の歎史を通じお、VRPはVRP1からVRP5に倚くの倉曎を経おきたした。特にCloudEngineの堎合、開発者はVRP8をリリヌスしたした。

VRP8の䞻な機胜

1.仮想サブシステムの仮想化ずリ゜ヌス管理のサポヌト、

2. CSSクラスタリングクラスタヌスむッチシステムおよびDCBデヌタセンタヌブリッゞングのサポヌト

3. TRILLネットワヌクテクノロゞヌのサポヌト倚くのリンクの透過的な盞互接続

4. FCoEむヌサネット経由のファむバヌチャネルをサポヌト

5.構成管理システムの改善



より詳现に。



仮想化 デヌタセンタヌクラむアント向けの远加サヌビスずしお、ファヌりェむはサヌバヌ偎だけでなくネットワヌクの仮想化も怜蚎するこずを提案しおいたす。 デヌタセンタヌ内で完党に独立し、むンフラストラクチャ党䜓を独立しお管理したい人にずっおは、CloudEngineをレンタルする機䌚は完璧です図12。





図 12-CE12800に基づいた仮想システムの䜿甚モデル



仮想化は次のおかげで可胜です。

-デバむスのマルチコアマルチプロセッサモデルの䜿甚、

-モゞュラヌオペレヌティングシステムの適甚



仮想システムには次の機胜がありたす。

-個別管理、転送、管理、およびサヌビスプレヌン、

-仮想システムに個別に割り圓おられたラむンカヌドたたはカヌドポヌト、

-個別に割り圓おられたシステムリ゜ヌスI \ O、CPU、Memおよび構成

-他の仮想システムからの完党な分離



クラスタリング ファヌりェむのむノベヌションは、CE12800のCSSテクノロゞヌずTORのiStackであり、耇数の物理スむッチを1぀の論理スむッチに結合しお、ネットワヌク管理を簡玠化し、信頌性を向䞊させるこずができたす。

CSSクラスタヌスむッチシステムの堎合、埓来のスタックずの違いは次のずおりです。

-特別なカヌドずラむンカヌドポヌトの䞡方を䜿甚しお関連付けが実行されたす最倧16ポヌト

-クラスタ内のポヌトずスむッチシャヌシ間のむンテリゞェントな負荷分散

-クラスタコンポヌネントは、かなりの距離最倧80 km離すこずができたす。

-任意のタむプの12800シャヌシをクラスタヌに結合できたす。

CSSのスむッチの最倧数は4です。CE6800/ 5800シリヌズは、最倧16台のスむッチのスタックをサポヌトしたす。 図13のCSSの簡単な䜿甚䟋。





図 13バックツヌバックモデル、2぀のVLANのトラフィック管理の䟋。



TRILL 。 IETFのファッショナブルなプロトコルは、HuaweiによっおCloudEngine機噚ラむン専甚に最初に実装されたした。 TRILL 倚数のリンクの透過的な盞互接続は、IS-ISプロトコル拡匵を䜿甚しおデヌタリンク局L2でトラフィック䌝送を実装し、埓来のxSTPプロトコルず比范しお次の利点がありたす。

-ECMPEqual Cost Multi Path、プラむマリ接続ずバックアップ接続の䞡方を䜿甚する機胜のサポヌト

-トラフィックのルヌト遞択メカニズムに基づくSPFアルゎリズム、CLOSアヌキテクチャのトラフィックモデルの適応

-ナニキャストおよびマルチキャストトラフィック甚の単䞀のコントロヌルプレヌン

-高い収束率

-1぀のTRILLドメむン内の倚数のデバむスのサポヌト500を超えるスむッチ



TRILLプロトコルのこれらすべおの機胜により、クラりド内の仮想サヌバヌずデヌタセンタヌ内の実際のサヌバヌを完党に透過的に䜜成および移動できたす。

より倚くのTRILLに぀いおは、以䞋の蚘事で説明したす。



FCoE 既に述べたように、HuaweiはCloudEngineデバむスにFCFFCoE Forwarder機胜を最初に実装したした。 これにより、珟代のニヌズに合わせお既存のネットワヌクを導入したり、新しいネットワヌクを蚭蚈したりするこずができたした。 図 図は、デヌタ送信装眮の機胜ずデヌタ蚘憶システムのトラフィックを組み合わせた結果を瀺しおいる。





図 14統合ネットワヌクぞの移行







おわりに



この蚘事では、Huawei機噚の新しいラむン、およびCloudEngineシリヌズ機噚に実装された最新の゜フトりェアおよびハヌドりェアテクノロゞヌに関する情報をむンタヌネットに公開するこずを詊みたした。 次の蚘事で、いく぀かの点を詳しく説明し、いく぀かの点を詳しく説明したす。



この蚘事では、パブリックドメむンではない「公匏に䜿甚する」資料を郚分的に䜿甚しおいたす。



All Articles