Roadmap OcNOS 7.1 · End-to-end · Sovrapposto a DLB

Global Load Balancing: routing adattivo esteso a tutto il fabric

DLB prende la decisione giusta a un singolo hop; GLB prende la decisione giusta su tutta la fabric. Nella roadmap di OcNOS 7.1, Global Load Balancing estende il routing adattivo da una visione per porta alla qualità del percorso end-to-end, colmando il divario degli hot-spot multi-hop sulle fabric IA Clos a 3 stadi fino al limite di 16,384 GPU. GLB si sovrappone a DLB anziché sostituirlo.

OcNOS 7.1Release di destinazione di GLB
End-to-endscoring del percorso, non hop locale
16,384limite GPU, design di riferimento
Stratificato su DLBestende, non sostituisce mai
Telemetria di percorso end-to-end

Valutare l'intero percorso, non solo l'hop locale

Una sezione di Clos a 3 stadi (leaf, spine, super-spine) che trasporta l'AllReduce GPU. Ogni tier trasmette in streaming la telemetria di occupazione delle code e di utilizzo dei link verso i leaf di ingresso. GLB sceglie il percorso con il miglior punteggio end-to-end, non il miglior punteggio di egress locale, così che un uplink pulito che sfocia in un downlink congestionato non venga più scelto alla cieca.

Global Load Balancing su un fabric AI Clos a 3 stadi Fabric AI Clos a tre stadi. Due super-spine in alto, quattro spine al centro, due leaf in basso. Le frecce di telemetria scorrono verso l'alto e di nuovo verso il basso così che il leaf di ingresso veda la qualità del percorso end-to-end. Un collegamento spine-super-spine è congestionato e viene bypassato a favore di un percorso end-to-end alternativo. telemetria end-to-end Super-Spine-1TH5 · 51.2T Super-Spine-2TH5 · 51.2T Spine-1e2e ok Spine-2e2e ok Spine-3uplink congestionato Spine-4e2e ok Leaf di ingressoGLB · ranks paths Leaf di egressrack di destinazione GLB · END-TO-END PATH SCORING · MULTI-HOP CONGESTION AWARENESS · OcNOS 7.1
Dove la visione locale viene meno

DLB e GLB, per ambito della decisione di percorso

DLB assegna un punteggio a ogni next-hop ECMP usando la profondità della coda di egress locale, ottimale su un leaf-spine a 2 tier. Passate a un Clos a 3 tier e potreste scegliere uno spine con un uplink pulito, per poi finire su un super-spine il cui downlink verso il leaf di egress è congestionato. La visione locale è corretta; la visione end-to-end è errata. Su fabric da 1,024 GPU e oltre, dove il Clos a 3 stadi con super-spine diventa standard, questa è la principale fonte residua di valori anomali di latenza di coda.

Axis DLBlocale, disponibile oggi GLBglobale, roadmap OcNOS 7.1
Ambito della decisionePer hop: ogni switch classifica i propri next-hop ECMP.End-to-end: i leaf di ingresso classificano percorsi completi da leaf a leaf.
Signal usedProfondità della coda di egress locale e utilizzo del link su questo switch.Telemetria di congestione aggregata da ogni tier, fino all'ingresso.
Scelta ottimaleFabric a 2 stadi e l'hop leaf-spine nelle fabric a 3 stadi.Clos a 3 stadi con super-spine, fino al limite di 16,384 GPU.
Hot-spot rilevatoSolo congestione di egress locale.Hot-spot a valle che l'hop locale non può vedere.
RebindingAllineato ai flowlet, in ordine per RoCEv2 e TCP.Allineato ai flowlet, stessa garanzia di ordine, con input dell'intera fabric.
HardwareTH4 e TH5 oggi.Stesso hardware TH4 e TH5, nessun nuovo silicio.
RelationshipDecisione indipendente su ogni switch.Si sovrappone a DLB; non lo sostituisce.
Come GLB colma il divario

Una sola decisione, informata dall'intera fabric

GLB riutilizza il meccanismo di routing adattivo che gli operatori già eseguono e vi aggiunge una consapevolezza estesa a tutta la fabric. Si basa direttamente su DLB e RoCEv2 e resta allineato alla direzione verso cui si muove Ultra Ethernet.

Builds on

La decisione di DLB

GLB estende la DLB decisione sui flowlet anziché sostituirla. Le fabric miste funzionano correttamente: gli switch senza GLB contribuiscono semplicemente con una qualità di percorso solo locale durante un aggiornamento progressivo.

Runs over

Una fabric RoCEv2 lossless

GLB effettua il rebind ai confini dei flowlet, preservando la consegna in ordine di cui RoCEv2 RDMA ha bisogno. Il trasporto resta di livello produzione; solo l'input sul percorso diventa più intelligente.

Allineato con

la segnalazione Ultra Ethernet

Il piano di qualità del percorso è progettato per interoperare con Ultra Ethernet la segnalazione del Consortium man mano che gli ecosistemi di NIC UEC maturano, così la roadmap resta compatibile con il futuro.

Dentro OcNOS 7.1

Come si integra l'implementazione GLB pianificata

GLB è abilitato da OcNOS come sistema operativo di rete su hardware aperto basato su Broadcom. Il design mantiene silenzioso il control plane e fornisce agli operatori la telemetria necessaria per fidarsi delle decisioni della fabric.

Piano di telemetria

Pubblicazione qualità del path

Ogni spine e super-spine pubblica i delta di occupazione delle code e di utilizzo per porta verso un'adiacenza estesa a tutta la fabric. Gli aggiornamenti avvengono in tempi inferiori al millisecondo tramite la segnalazione in-band esistente, senza traffico aggiuntivo sul control plane.

Scoring del percorso

Aggregazione end-to-end

I leaf di ingresso combinano la qualità di egress locale con la telemetria a valle in un punteggio aggregato per ciascun percorso candidato. L'hop peggiore domina il punteggio, la stessa intuizione che gli operatori usano durante il troubleshooting.

Selection

Flowlet-aligned

Come DLB, GLB esegue il rebinding ai confini dei flowlet, preservando la consegna in ordine per RoCEv2 e TCP. La differenza sta in ciò che alimenta la decisione: la qualità dell'intero fabric, non quella della porta locale.

Backwards-compatible

Stratificato su DLB

GLB estende la decisione di DLB; non la sostituisce. Le fabric miste con switch dotati di GLB e switch solo DLB si comportano correttamente, quindi gli aggiornamenti brownfield da 7.0 sono sicuri.

Scalare

Fino al limite massimo di 16k GPU

I design di riferimento usano 256 switch spine e 128 switch super-spine, ciascuno un Tomahawk 5 da 64x800G, dimensionati al limite architetturale di 16,384 GPU.

Telemetria in uscita

gNMI per il team operativo

I punteggi per percorso, gli eventi di rebind e l'attribuzione dell'hop peggiore vengono trasmessi in streaming tramite gNMI e OpenConfig, così gli SRE possono correlare le decisioni della fabric con il comportamento dei job collettivi xCCL senza una scatola nera.

Roadmap e disponibilità

Cosa aspettarsi quando arriverà GLB

GLB è nella roadmap di OcNOS 7.1. È destinato allo stesso hardware e alle stesse licenze che gli operatori già utilizzano, quindi adottarlo è un aggiornamento anziché una sostituzione completa.

  • Roadmap OcNOS 7.1. GLB è destinato alla train OcNOS-DC 7.1, sullo stesso hardware TH4 e TH5 che oggi esegue DLB. Pianificazione e ambito delle funzionalità al Pagina delle release OcNOS.
  • Stesso SKU. Previsto per OcNOS-DC PLUS: nessun paywall per singola funzionalità, nessuna nuova chiave di licenza al momento dell'aggiornamento.
  • Upgrade in-place. L'aggiornamento brownfield da 7.0 a 7.1 è supportato; i fabric a versioni miste continuano a funzionare con comportamento DLB-only durante la finestra di aggiornamento.
  • UEC-aligned. Il piano di qualità del percorso è progettato per interoperare con la segnalazione dell'Ultra Ethernet Consortium quando gli ecosistemi di NIC UEC matureranno. Vedi Ultra Ethernet (UEC).
  • Revisione dell'architettura disponibile. Se state dimensionando una fabric con oltre 1,000 GPU, eseguiremo un esercizio di dimensionamento che include il piano di telemetria GLB. Ottenete un layout leaf-spine di primo passaggio con la AI fabric design suite.
La visione di IP Infusion

DLB è la base oggi, GLB alzerà il limite domani

Il routing adattivo sta già risolvendo problemi reali di latenza di coda su scala a 2 tier. GLB porta la stessa disciplina nelle fabric a 3 stadi dove risiedono i cluster più grandi, su hardware aperto che già validate.

DLB risolve il caso comune

Su leaf-spine a 2 tier e sull'hop leaf-spine, il routing adattivo locale elimina già la maggior parte delle collisioni ECMP. È disponibile su TH4 e TH5 già oggi.

GLB risolve il caso su larga scala

Da 1,024 GPU in su, gli hot-spot multi-hop diventano il principale valore anomalo. GLB assegna un punteggio ai percorsi completi così che il leaf di ingresso smetta di rincorrere un uplink pulito che sfocia in un downlink congestionato.

OcNOS è l'abilitatore

Un unico NOS, un'unica roadmap di funzionalità: DLB oggi, GLB in arrivo, allineato a RoCEv2 e UEC per tutto il percorso, su hardware aperto validato anziché su una fabric di un unico fornitore.

FAQ

Global Load Balancing, le risposte

In che cosa GLB si differenzia da DLB?
DLB valuta ciascun next-hop in base alla profondità della coda di uscita locale di un singolo switch, il che è ottimale su un leaf-spine a due livelli. GLB aggrega la telemetria di congestione di ogni livello, così i leaf di ingresso classificano i percorsi leaf-a-leaf completi e individuano gli hot-spot a valle che la vista locale non coglie sui fabric Clos a tre stadi.
Quando sarà disponibile GLB?
GLB è nella roadmap di OcNOS 7.1, destinato alla train OcNOS-DC, sullo stesso hardware Tomahawk 4 e 5 che oggi esegue DLB. È previsto per lo SKU OcNOS-DC PLUS senza nuove chiavi di licenza al momento dell'aggiornamento.
Devo sostituire il DLB per utilizzare il GLB?
No. GLB si sovrappone alla decisione DLB anziché sostituirla. Le fabric miste funzionano correttamente: gli switch non abilitati a GLB contribuiscono semplicemente con una qualità di percorso solo locale, e sono supportati gli upgrade brownfield dalla 7.0.
Quanto grande può essere una fabric supportata da GLB?
I design di riferimento usano 256 switch spine e 128 switch super-spine, ciascuno un Tomahawk 5 da 64x800G, dimensionati al limite architetturale di 16,384 GPU.

Dimensionare una fabric da diverse migliaia di GPU? Facciamo i conti insieme

Indicateci il carico di lavoro e la scala GPU, e un ingegnere di IP Infusion dimensionerà con voi il piano di telemetria GLB, oppure iniziate con un layout leaf-spine di primo passaggio nell'AI fabric design suite.