Juniper ontwerpt nieuwe netwerkarchitectuur

De fabrikant van netwerkapparatuur Juniper heeft een nieuwe netwerkarchitectuur gepresenteerd. Volgens het bedrijf kan 'QFabric' de prestaties van datacenters fors verbeteren, maar hoe de technologie precies werkt, is nog niet duidelijk.

Juniper claimt dat de QFabric-architectuur de latency binnen datacenters kan terugbrengen naar maximaal 5 microseconden, door toepassing van een nieuwe manier van routeren. Ook de jitter wordt teruggebracht, evenals het stroomverbruik, het aantal benodigde netwerkapparaten en de vereiste ruimte in het datacenter.

De huidige inrichting van datacenters is volgens Juniper vaak te gecompliceerd; packets zouden een vaak onlogische weg langs te veel nodes afleggen om een bepaald eindpunt te bereiken. De QFabric-architectuur maakt het mogelijk om data met slechts één hop naar een ander punt in het datacenter te sturen, belooft Juniper. Volgens het bedrijf doet een QFabric-installatie in feite dienst als een soort gigantische switch.

Het is nog onbekend hoe de techniek precies werkt, maar duidelijk is wel dat een QFabric-netwerk op drie componenten leunt. De 'QF/Node' lijkt de rol van switch op zich te nemen, terwijl het 'QF/Interconnect'-chassis wordt gebruikt om gegevens direct van de ene naar de andere node te sturen. Tot slot kan een 'QF/Director' worden gebruikt om het netwerk te beheren.

Volgens Juniper maakt QFabric het onder andere mogelijk om datacenters eenvoudiger op te schalen. Het is echter ook nog onduidelijk in hoeverre bestaande datacenters moeten worden aangepast om als 'QFabric' te kunnen werken. Het is weer wel bekend dat QFabric bestaande netwerkprotocollen als fibrechannel en ethernet kan gebruiken.

De eerste QFabric-hardware is al aangekondigd; het gaat om een 'QF/Node' die ook als traditionele switch dienst kan doen. De QFX3500 biedt een maximale switch-capaciteit van 960 miljoen pakketten per seconde en een maximale doorvoersnelheid van 1,28Tbps. De eerste interconnect- en director-hardware komt in het derde kwartaal uit, verwacht Juniper.

De technologie is vooral bedoeld voor grote datacenters die snel moeten kunnen worden uitgebreid. Op papier maakt QFabric iets mogelijk dat als 'unified networking' wordt omschreven. Dat is het principe dat een netwerk als één geheel functioneert, in plaats van als een verzameling kleinere netwerken die aan elkaar zijn geknoopt. Overigens biedt ook Cisco al 'unified networking'-producten aan.

Helaas!
De video die je probeert te bekijken is niet langer beschikbaar op Tweakers.net.

Reacties (54)

[localhost]

Met andere woorden: Wat Cisco "Nexus" noemt, heet bij Juniper "QFabric" ?

[Bl@ckbird]

De Cisco Nexus 5000 ondersteund FCoE en gaat FabricPath / TRILL ondersteunen.
De Cisco Nexus 7000 ondersteund FCoE en FabricPath (en in de toekomst TRILL als de standaard er is.)

Voor de Nexus 7000 heb je hier -F type lijnkaarten voor nodig.
Bij Juniper stond QFabric eerder bekent als project Stratus.

[Reactie gewijzigd door Bl@ckbird op 22 juli 2024 18:23]

[ijdod]

Nee, Juniper heet met Qfabric dat gemaakt wat Cisco met Nexus had moeten doen. Revolutie ipv evolutie. In elk geval op papier .

[Kickasz]

Revolutie, het lijkt meer op achteruitgang als je het mij vraagt. Dit is toch simpel gezegd niet meer dan een fully connected mesh topology

[seba]

Volgens mij is dat in het filmpje simpeler voorgesteld dan het is.
Want als je een fully connected mesh hebt, heb je geen switches en dus geen qfabric nodig.
Volgens mij bedoelen ze dat het gelijkaardig presteert aan een fully connected mesh. Mss met bepaalde aanpassingen in hun eerste voorstelling (fat tree van de gewone tree maken ofzo).

[florholvoet]

Als het een fysiek volledig verbonden gaas topologie had geweest, dan was het inderdaad eerder een achteruitgang te noemen vanwege de grote hoeveelheid bekabeling.

Met QFabric claimt Juniper deze topologie echter te hebben verwezenlijkt in efficiënte fysieke topologie, de fysieke netwerkstructuur die we vandaag allemaal gewoon zijn. En dat is wel degelijk op z'n minst een evolutie t.o.v. de standaard vandaag.

[Belboer]

Commercieel staan deze apparaten tegenover elkaar. QFabric is de Juniper versie van L2 routing, zoals FabricPatch dat bij Cisco is. Wel zorgt Juniper er voor dat alle switches die aan een QFabric deelnemen als een enkele grote switch te beheren zijn. Zover ik weet is dat bij de Nexus niet zo.

[arjankoole]

Zover ik weet is dat bij de Nexus niet zo

Dat zou raar zijn, cisco 37xx switches deden dat ook al. Waarom zou hun grotere/betere/uitgebreidere/nieuwere broer dat niet hebben dan?

[peak]

Wat ik uit de tekst en filmpje niet echt duidelijk begrijp is het volgende:
Ze zeggen, all Devices are connected with the other Devices...

Juist.. Moet ik dat zien als alle Servers hebben een fysieke netwerkverbinding naar 1 Switch?
Het lijkt mij vrij onlogisch als een Server x fysieke netwerkverbindingen heeft naar alle servers toe...

Ik zou weleens een plaatje willen zien hoe het er fysiek uit komt te zien, aangezien er in het filmpje wordt gezegd dat elke server maar 1 hop is....

Agree?

[Stokkie01]

Logisch gezien wordt het 1 switch, echter in de praktijk zullen het meerder fysieke switches zijn.
Het voordeel: Qua management heb je maar 1 device te managen.
En je hoeft niet meer met Spanning Tree te gaan werken, daarom wordt het ook vele malen sneller. Daarnaast heb je wel zeker minder devices nodig omdat je de aggregatie laag gaat weg halen uit je datacenter.

Tenminste, dat is wat ik er van begrijp...

Edit: hier wellicht nog wat meer uitleg...
http://www.flickr.com/photos/junipernetworks/5470442318/

[Reactie gewijzigd door Stokkie01 op 22 juli 2024 18:23]

[mxcreep]

Spanning tree is gelukkig zowieso niet in elk (redundant) netwerk ontwerp nodig... persoonlijk vind ik het een behoorlijk lapmiddel...

[Netrunner]

Inderdaad,

ik zie ook geen logische topology van het fysieke verhaal ervan.

[OruBLMsFrl]

Iets als cut-through routing in plaats van store-and-forward gaat daar al aardig heen. Als je cut-through routing niet op switch maar op router niveau zou kunnen realiseren, door op de routers volledige informatie over de topologie te hebben, dan zou dit mogelijk wel naar de microseconden schaal te brengen zijn die genoemd wordt. Een normale router doet store-and-forward, wat de vertraging beduidend hoger maakt. Lijkt me vooral voor supercomputer clusters interessant, aangezien daarbij latency enorm belangrijk is. Meestal is 1ms (of zelfs meer) latency prima acceptabel voor diverse internet en enterprise business toepassingen binnen een serverruimte of datacenter. Iets dat meer dan honderden transacties per seconde doet heb je niet zo snel, dat blijven toch vooral gespecialiseerde toepassingen.

[Verwijderd]

Cut-through routing is onzin. Hoeveel winst boek je ? Zo goed als niks.

Stel een 4k byte packet.
Stel een 1Gbps link.

32000 bits in een packet.
1000000000 bits worden verzonden in een seconde.
1000000 bits worden verzonden in een milliseconde.
1000 bits worden verzonden in een microseconde.

Er zitten dus 32 microseconden tussen het verzenden van het eerste bit en het laatste bit van een packetje. Dat is de *maximale* winst die je kunt boeken in het beste geval. Zodra je 10GB ethernet gebruikt, valt de winst terug naar 3 microseconden maximaal. Als je 1500 byte packets neemt, dan valt het terug naar 1 microseconde (of 10 microseconde voor 1Gbps ethernet).

Verwaarloosbaar in het grote geheel.

In 1995-1996 waren er twee vernieuwende switch fabrikanten. Kalpana en Crescendo. Kalpana deed cut-through switching. Crescendo niet. Beide bedrijven zijn opgekocht door Cisco. De Crescendo switches werden de Catalyst switches. Toendertijd was alle ethernet nog 10 Mbps, er was niet eens 100 Mbps. En toen al was het duidelijk dat cut-through switching onzin is. Marketing speak. Net zoals het fimpje van Juniper meer marketing-speak is dan echt iets technisch uitlegt.

De normale vertraging in een router of een switch komt door (tijdelijke) congestion op de output poort. Als je uitgaande poort toch al bezig is met het verzenden van een ander pakketje, dan heeft cut-through geen zin. Dan moet je zowiezo je pakketje toch bufferen.

Ik zie een Ster-topologie.
Ik zie een Single-point of failure.

Misschien dat zo'n QFabric design makkelijker te managen is. Dat zou een groot voordeel zijn.

Ik zou eens beginnen met het redesignen van dat netwerk dat je voor je servers hebt hangen. Zijn er al switches die bridging doen met IS-IS (ipv Spanning Tree) ? Ik weet dat de RFCs er zijn. Zijn er al viable implementaties ?
Edit: er zijn nog geen RFCs dus. Alleen een draft.
https://datatracker.ietf.org/doc/draft-ietf-isis-ieee-aq/

[Reactie gewijzigd door Verwijderd op 22 juli 2024 18:23]

[Zunflappie]

Tel het aantal servers in je datacenter.
Elke server heeft evenveel poorten als er aantal servers zijn.
En directe kabel ertussen.

100 servers = 100 netwerkpoorten per server = 99x98x97x96....x3x2x1 kabels.

Hopen dat de koperprijs niet te hoog wordt...

[Vliedel]

Met 1 hop staat er toch? Dus dan zou je 100 kabels hebben.

*edit* filmpje geeft jou gelijk

[Reactie gewijzigd door Vliedel op 22 juli 2024 18:23]

[ijdod]

Een hop qua ontwerp lagen, helaas, niet een hop qua devices. Qua devices zal het 1 of 3 zijn, volgens deze techniek. Het is een hub/spoke mode. De QF/Interconnect is de spin in het web, waar elke QF/Node op samenkomt. Servers zitten op een QF/Node aangesloten.

[TheMazzter]

Gelukkig is het 'maar' 99+98+97+...+3+2+1 = 99*(99+1)/2 = 4950 en niet 99x98x97x...x3x2x1 = 99! = 93326215443944152681699238856266700
49071596826438162146859296389521759
99932299156089414639761565182862536
97920827223758251185210916864000000
0000000000000000

[Reactie gewijzigd door TheMazzter op 22 juli 2024 18:23]

[iMars]

precies! en niet 100 servers = 100 netwerkpoorten per server maar n-1 netwerkpoorten per server, dus 99.

1 server = geen netwerkpoort
2 servers = 1 per server
3 servers = 2 per server
5 servers = 4 per server
100 servers = 99 per server (vandaar ook 99+98+97+...+3+2+1)

[Predator]

It smells like fabricpath

Of de open standaard: Transparent Interconnection of Lots of Links (TRILL)

[Reactie gewijzigd door Predator op 22 juli 2024 18:23]

[ijdod]

Niet echt, hoewel het achterliggende idee vergelijkbaar is (het kortsluiten van de tree). TRILL is vziw niet hetzelfde, anders dan dat het ook een mesh is. Dit lijkt technisch meer op de meshing zoals HP die op een aantal Procurve dozen ondersteunde.

[Reactie gewijzigd door ijdod op 22 juli 2024 18:23]

[Predator]

Ik zeg toch niet dit dat dit de Juniper implementatie van het TRILL principe is ?

Dit ruikt toch gewoon naar een strategische zeg richting het Cisco fabricpath verhaal ?
Verder is het natuurlijk hetzelfde doel. Het wegfilteren van de L2 fysieke boomstructuur van access naar core. Fabricpath maakt er een L2 'routed' omgeving van (gesteund op IS-IS). Hier lijkt men meer de switch intelligentie te centraliseren zoals Cisco ook met de NX 5K en 2K modules doet.
Enfin, daar lijkt het op, want dit is VAAG.

[jimbo123]

En dan gaat je QFabric ding stuk en heb je een single point of failure.
Oh nee, dan zetten we gewoon 2 van die dingen in.
Ja, maar we zouden het toch minder complex maken? fewer devices?

[StnCldKllr]

Brocade heeft dit al met zijn VCS Ethernet Fabrics
TRILL icm FSPF

[Kabouterplop01]

elke server verbinden met elke server hoeft niet veel draadjes te kosten, je kunt dat ook met een trunk doen. Heb je echter wel een mega high end netwerkkaart voor nodig en een dedicated cpu core die al je interrupts moet afhandelen, trouwens ik heb nog geen moederbordje gezien met zoveel slots. moet je wel een dure raiser kopen zeker?
Overigens zoals gryz het stelt moeten al je machines ingesteld staan om jumboframes te ondersteunen. lijkt me wel even wennen voor beheer

[Sjohnnie83]

Misschien wordt een techniek als Serial RapidIO gebruikt? Dit is een Interconnect technology nu vooral gebruikt in embedded systemen. Het lijkt erg op PCIe, maar is in plaats van P2P een Fabric. De nieuwste versie (2.x) is niet lang geleden gereleased en ondersteunt links met 32x lanes en 5Gbps per lane..... Bedrijven zoals IDT maken hier switches voor die een ongelofelijke throughput hebben, al is de hier genoemde 1.28Tbps wel erg hoog, maar misschien is dat de maximum cumulatieve bandbreedte die beschikbaar is.
SRIO heeft een speciale transmissie modus die Cut-through wordt genoemd. Normale Ethernet switches gebruiken "store and forward". met cut-through worden de bits (symbolen) verzonden terwijl ze binnenkomen.

Mja, het is speculatie, maar ik zou SRIO kiezen voor zo'n toepassing (wij gebruiken het in DSP farms).

[haarbal]

wat is de latency in een datacenter nu dan? En boeit het echt of het 5 microseconden is of een milliseconde. Als de bandbreedte maar redelijk is toch?

[webfreakz.nl]

Latency is minstens zo belangrijk voor VoIP, Video streaming en ook VMWare High Availability oplossingen.

[hendrickbert]

een filmpje dat er heel gelikt uitziet maar helemaal niks vertelt, directie-porno.

[mph_rbi]

Juniper kennende moet ik hiervoor helaas m'n huis en inboedel verkopen voor een 10Gig lijnkaart

[D.oomah]

Je kunt ook een tweede hypotheek nemen

[mxcreep]

Die heeft ie al voor de vorige Juniper setup