Nikhef en SURF testen 400Gbit/s-lijnen in de randstad

Nikhef en SURF testen een 400Gbit/s-glasvezelverbinding tussen Amsterdam, Utrecht, Delft en Leiden. Het gaat om een pilot om straks de verbinding tussen Amsterdam en CERN bij Genève te upgraden.

De test verloopt over het glasvezelnetwerk van SURF en de 400Gbit/s-verbinding wordt gerealiseerd over een afstand van 250 kilometer. De dataverbinding die Nikhef met CERN in Zwitserland heeft is 1800 kilometer lang. Nu biedt die verbinding nog een maximale doorvoersnelheid van 100Gbit/s.

Nikhef is het Nationaal instituut voor subatomaire fysica, gevestigd op het Science Park in Amsterdam. Het is een van de dertien zogenoemde tier-1-locaties wereldwijd die grote hoeveelheden data van de Large Hadron Collider ontvangt om te analyseren. Door de high luminosity-upgrade van die deeltjesversneller, komt er tegen 2027 veel meer data op de tier-1-locaties af. Nikhef is bezig zich daarop voor te bereiden met snellere opslag en dataverbindingen met meer bandbreedte. Tot 2015 was Nikhef met een 10Gbit/s-lijn met CERN verbonden, sindsdien is dat een 100Gbit/s-verbinding en straks dus een 400Gbit/s-lijn.

SURF heeft voor de test ondersteuning voor Flex Grid aan zijn netwerk toegevoegd en door deze flexibele inzet van grid spacing kan meer data door een enkel kanaal. Op locaties in Amsterdam, Utrecht, Delft en Leiden is daarnaast apparatuur geplaatst die maakt dat er zo min mogelijk signaalverlies en ruis op de verbinding ontstaat. De uiteindelijke verbinding met CERN gaat met dezelfde apparatuur, en ramanversterking moet helpen de hoge doorvoersnelheden in stand te houden.

Volgens it-architect Tristan Suerink van Nikhef is de test al in augustus in gang gezet en verloopt deze voorspoedig: "We draaien al een maand met honderd procent belasting, zonder problemen." Nog dit jaar moet de 400Gbit/s-verbinding met CERN tot stand komen. Dat zou dan de eerste internationale 400Gbit/s-verbinding ter wereld zijn.

Reacties (41)

[furian88]

Waar ik meer nieuwsgierig naar ben is hoe ze deze data gaan opslaan...

[jswinkels]

Onder het artikel staat een link naar een eerder artikel over die opslag. https://tweakers.net/revi...oor-met-rappe-opslag.html

[CAPSLOCK2000]

Waar ik meer nieuwsgierig naar ben is hoe ze deze data gaan opslaan...

Niet.
Dit soort data wordt onmiddelijk gecombineerd met andere binnenkomende data en verwerkt en direct daarna gefiltered. Pas daarna worden de resultaten opgeslagen.

[Aial0n]

Sterker nog, dit is al gefilterde data. De ruwe sensordata gaat eerst door een filter van slechts een paar logic gates die al zeer veel data weggooien. De verkleinde stream wordt dan iets beter gefilterd met wat complexere logic gates, die data wordt dan real-time gefilterd door 'gewone' computers en dan pas is de data stream klein genoeg dat hij opgeslagen kan worden op storage clusters.

[locke960]

De ruwe data aan de sensors van de LHC: 600 miljoen metingen per seconde, met 1 Megabyte per meting.
Dat is dus 600 Petabyte per seconde. Die hardware die jij noemt gooit daar direct ~99,98% van weg, maar dan hou je nog steeds 100 Gigabyte per seconde over, wat dan door computers verder gereduceerd wordt.

CERN heeft er een artikel met filmpje over op hun site staan.

[Anoniem: 1322]

Geweldige video. De apparatuur nodig voor dit experiment moet echt extreem zijn.

[Pmf1971]

Dat valt allemaal nog wel mee. De ruwe sensordata is ongeveer 300 GB/sec, en een filter (Computer cluster) reduceert dat naar ruwweg 300 MB/seconde. Dit kan makkelijk lokaal tussentijds opgeslagen worden, voordat het gedistribueerd wordt naar andere locaties. De LHC staat ook niet altijd aan. Bron Wikipedia.

[Reactie gewijzigd door Pmf1971 op 23 juli 2024 00:29]

[Coffee]

Waarom niet gewoon 140 NVMe SSD's in RAID 0!?

Maar zonder grappen. Is er dan niet een kans dat er door die simpele gates data wordt weggegooid die achteraf toch nodig blijkt?

[Anoniem: 1322]

Uiteraard, maar ik begrijp het goed. Je eigen hersenen werken op dezelfde wijze. Je ontvangt op ieder moment enorme hoeveelheden input (zicht, geur, tast, etc) en je hersenen filteren alle onzin eruit en de nuttige data beland in je korte termijn geheugen. Later worden de belangrijkste zaken opgeslagen in het lange termijn geheugen en de rest wordt gedumpt.

Wat betreft de test data die je mist: Je zult dus gewoon je test opnieuw moeten doen en een aparte ‘gate’ schrijven die over een groot bereik kijkt. Bijvoorbeeld naar pieken over een breed spectrum.

[psycho202]

omdat die NVMe disks wel snel zijn, maar de kostprijs voor de hoeveelheid data die ze binnenkrijgen gewoon niet te betalen is voor hen.
Daarnaast is die RAID-0 wel mooi voor snelheid, maar hier wensen ze toch wel wat betrouwbaarheid. Je kan nu eenmaal niet snel een 2 jaar durend project herstarten omdat er in 1 servertje toevallig 1 disk kapot gegaan is.

[Coffee]

Dat was een grapje natuurlijk

[lasermen]

Waarom hebben ze dan zoveel opslag staan volgens dit artikel https://tweakers.net/revi...oor-met-rappe-opslag.html?
Als ze alles toch al weg zouden gooien, dan heb je toch ook geen 400 Gbit/s nodig?

[arjankoole]

Waarom hebben ze dan zoveel opslag staan volgens dit artikel https://tweakers.net/revi...oor-met-rappe-opslag.html?
Als ze alles toch al weg zouden gooien, dan heb je toch ook geen 400 Gbit/s nodig?

Omdat er nog altijd enorm veel data overblijft. Ondanks dat er ongelofelijk veel weggegooid wordt in 1 seconde, blijft het overblijfsel genoeg om pittige storage nodig te hebben. Zeker omdat ze er maanden over doen om die data door te ploegen, om te verifiëren bijvoorbeeld dat ze Higgs Bosson hebben gedetecteerd. Tussen het experiment waarin het gebeurde en het voltooien van de data analyse die dat bevestigde, zaten een paar maanden.

Die bandbreedte behoefte sluit daar op aan. Het kan mogelijk zijn (ik weet het niet zeker) dat die sensor data (deels) naar deelnemers als nikhef wordt gestuurd. (Broadcast). Daardoor kunnen wetenschappers realtime op andere locaties meekijken bij CERN als er een experiment draait.

Ook is het mogelijk dat ze simpelweg aan het doorontwikkelen zijn voor als er een grote behoefte is. (Die gaat zeker komen, want ze zijn al lang bezig met ontwikkelen van de opvolger voor LhC, en die collider wordt nog vele malen groter.

[VisionMaster]

Broadcast? De data gaat heel specifiek en gecurreerd van A naar B. Registratie, accountability, security, quota, scheduling... nogal wat uitdagingen als je het netjes wilt doen op deze schaal.

[Hatsjoe]

Dat is tegenwoordig niet zo'n groot punt meer. Netwerk is nu vaak je bottleneck, en niet je storage. Als we uitgaan van een gemiddelde schrijfsnelheid van 250MB/s per SSD heb je theoretisch maar 200 SSDs in RAID0 nodig (uiteraard wordt dit niet zo gedaan, dat weet ik ook wel ).

Zoals al door anderen aangegeven gebruiken ze waarschijnlijk Ceph (of soortgelijke) storage clusters hiervoor. Het is niet meer ongewoon om meer dan 1PB aan storage per 40U rack te hebben. Met 400Gbit/s duurt het iets minder dan 6 uur om die 1PB vol te stampen. Maar uiteraard is de storage niet beperkt tot dat ene rack, er zullen vele storage racks zijn.

[TD-er]

Om een beetje gevoel te krijgen van Petabytes aan opslag.
Een paar jaar geleden (toen 10 TB hdd's het grootste was wat te krijgen was), kon je ruwweg 1 PByte kwijt in 8U aan rackspace. Dit is inclusief erasure encoding redundantie. (zeg maar beetje vergelijkbaar met de extra schijf van Raid-5, maar dan verdeeld over het hele array en over elke schijf)

Kortom, als je 1U extra rekent per 4U aan hdd's voor de rekenkracht voor de erasure encoding, dan kun je dus ruwweg 4 PByte kwijt per 40U rack.
Dit even aangenomen dat je voldoende koel-capaciteit en vermogen hebt per rack.

Met 2 PB aan dergelijke systemen had je genoeg snelheid om tegelijkertijd 40 Gbps te kunnen lezen en schrijven.
Oftewel als je alles in dergelijke systemen op zou willen slaan, heb je minimaal 20 Pbyte aan opslag nodig om 400 Gbps continue te kunnen lezen en schrijven, met puur en alleen mechanische drives en het ook nog een beetje economisch te houden. (5 racks dus)
Inmiddels zijn de hdd's alweer wat groter en mogelijk dat je de bandbreedte met de huidige 100G kaarten en voldoende (en snellere) PCI-e lanes ook wat efficienter kunt verwerken.
Dus misschien dat het met de huidige systemen met de helft aan opslag-ruimte en een kwart van de rackspace al mogelijk is om 400 Gbps continue te kunnen lezen en schrijven op mechanische drives.

[lasermen]

Waarom kan NIKHEF dan vorig jaar met 2,2PB aan schijf opslag in 24HE, al iets van 300Gbit/s aan bandbreedte aan?
Dan heb je toch geen 5 kasten en 20PB nodig lijkt mij?
Volgens mij ga je dan ergens mis met je berekening of NIKHEF doet iets erg slims?

[TD-er]

Ik ga sowieso ervanuit dat NIKHEF iets erg slims doet

Zoals ik al schreef, was dat de situatie van 2 a 3 jaar geleden.
Toen heb ik gewerkt aan een opslagsysteem voor astronomische data.
Daarin zaten 4 Dell 4U kastjes met elk 5 lades van 12 schijven.
Die waren per 2 verbonden met elk een aparte 1U server en elk voorzien van dual 40 Gbps netwerk.
Dat vult dus ongeveer 18U aan rackspace. (let wel, 10TB hdd's, geen SSDs)
Met enkel schrijven, kon je ruwweg 7 GByte/sec halen voor een set van 2 van die Dell kastjes (de helft van het systeem dus) en dan is de andere helft vrij beschikbaar voor lezen.
Echter dan moet je er vanuit kunnen gaan dat je de load zo perfect kunt verdelen dat je lezen en schrijven verdeelt over fysieke units.
Oftewel heel optimistisch gezegd, compleet niet van toepassing op realistische situaties, zou je dus kunnen zeggen dat je met 18U aan rackspace daarmee dus 14 GByte/sec kunt opslaan.
Extrapoleer dat naar 24U en je zit op 21 GByte/sec. (168 Gbps)

Probleem is alleen dat je er weinig aan hebt om het alleen maar op te slaan. Je wilt de data ook kunnen lezen en er iets mee doen.
Er zijn maar weinig situaties waarbij je precies een dataset hebt die precies te mappen is naar een veelvoud aan opslag-units zodat je op 1 unit alleen maar hoeft te schrijven en een volgende kan als enige gaan lezen.
Kortom, in de praktijk moet je er vanuit gaan dat je zowel aan het lezen als aan het schrijven bent.
Dat maakt de boel al een stuk complexer en kost aanzienlijk meer dan een factor 2 in snelheid. (we hebben het hier over datasets die niet even in de cache van de server passen, ookal heb je daar 256GB RAM in zitten, of nog meer)
Dan is er nog het probleem dat je simpelweg (toen dus) niet 2x 40 Gbps over de PCIe bus gepompt kreeg, omdat er maar 64 Gbps beschikbaar was aan PCIe lanes. (naast dat de snelheid van/naar de schijven ook maar beperkt was tot 4x 12 Gbps per 4U kastje)
En dan heb je nog het probleem dat de ene PCIe lane niet zomaar de data door kan geven aan de ander als beiden niet verbonden zijn met dezelfde NUMA eenheid op de CPU.
Kortom, als je sustained (zeg een "burst" van 24h of meer) data tegelijk wilt lezen en schrijven, dan mag je heel blij zijn als je met die set van ruwweg 2 PByte 40 Gbps als gegarandeerde minimale (schrijf) transfer rate haalt.
Dus van de theoretische 4x 40 Gbps netwerk bandbreedte blijft er eigenlijk maar 40 Gbps over in de praktijk aan gegarandeerde minimale schrijf-snelheid.

Nu ruim 2 jaar verder, hebben we heel wat leukere componenten om uit te kiezen.
PCI-e bus is per lane alweer wat sneller en er zijn gelukkig ook zat chipsets die wat meer lanes te bieden hebben.
Ook zijn er inmiddels zat 100 Gbps netwerk-adapters die ook netjes 100 Gbps kunnen halen van/naar de CPU en sommigen zelfs met meerdere poortjes per kaart.
Dan ben je 'slechts' beperkt tot de verbindingssnelheid van/naar de storage laag.
Met de wat diepere racks van tegenwoordig kun je zelfs de "PC" spullen om van fibre channel naar netwerk te gaan gewoon in dat 4U rack kastje kwijt (en/of wat meer schijven) en dan kun je in 24U dus 6 van die units kwijt.
Als je dan 2 units per 100Gbps netwerk aansluit, zou je maar zo een theoretische bandbreedte van 300 Gbps kunnen halen.
Echter ik moet nog zien dat dat sustained lezen en schrijven is.
Ik zou het al een hele prestatie vinden als ze 100 Gbps gegarandeerde schrijf-snelheid kunnen halen terwijl er tegelijk ook gelezen moet worden.

Maar zoals gezegd, ik denk dat NIKHEF ongetwijfeld iets heel erg slims gedaan heeft

[x280]

Ze zullen vast iets van een datacentrum gebruiken. Dus verbinding van datacentrum A naar datacentrum B.

[xippie]

Het meeste word realtime verwerkt en alleen de uitzonderingen worden opgeslagen en nader uitgewerkt.

[wica]

CERN heeft een behoorlijk groot ceph cluster, waar je best wel snel wat data kan opslaan.

[deadlock2k]

https://eos-web.web.cern.ch/eos-web/

[Keypunchie]

Mooi, want de kennis vergaard door dit soort pilots en onderzoeksinstituten wordt doorgaans gepubliceerd en zorgt ervoor dat het voor andere partijen mogelijk is om de geleerde lessen in te zetten voor het verbeteren van de eigen netwerken.

Alhoewel aan de andere kant het grootste probleem van de verglazing van Nederland de wet van de remmende voorsprong en het ontbreken van investeringsgelden is. Het is niet alsof voor het aanleggen van FttH er nog grote onderzoeksprojecten nodig zijn. Dat is gewoon uitvoeringswerk.

[TD-er]

Wat dat betreft ben ik wel benieuwd of deze upgrade van 100 naar 400 Gbps enkel een kwestie was van het vervangen van de optics, of dat er wellicht ook ander glas nodig is om 400 Gbps te kunnen halen?
Oftewel kan elke single mode fiber deze snelheden aan over grote afstanden, of vereist 400 Gbps eigenlijk al meer punten onderweg waar het signaal weer versterkt moet worden?

En maakt het wat dat betreft nog uit of er graded index single mode fiber voor dit soort snelheden en afstanden?
Dat laatste is natuurlijk wel een dingetje voor grootschalige deployment van fiber.
Het laatste stukje multi mode fiber kan best nog wel heel wat upgrade stappen mee, maar als je nu de 'backbone' kabels gaat leggen als provider, dan wil je dat graafwerk niet over een paar jaar (of decennia) nog eens moeten doen.

[DJSmiley]

Single mode kan nog wel ff mee. Grootste uitdaging zit in de dispersion over langere afstanden. Hogere snelheid = sneller bitjes achter elkaar = meer last en het komt kritischer.

Met 1 vezel kun je momenteel zonder problemen 4Tbit doorvoer genereren. (40 DWDM kanalen, 100Gbit per kanaal). Met 400Gbit optics en 40 kanalen kun je tot 16 Tbit door 1 vezeltje jagen

Ga je 75Ghz brede DWDM channels gebruiken, dan kun je 64 x 400Gbit kwijt in een vezeltje.
Alleen is 75Ghz niet echt gangbaar. In de praktijk wordt een 100Ghz grid het meest gebruikt (=44 kanalen). Daarnaast is 50Ghz nog een optie, dan kun je 88 kanalen kwijt, maar dat is een stuk minder gangbaar.
Er zijn al wel praktijktesten gedaan met 400G / 75Ghz (google maar eens op 400ZR )

Quote:
The ability to squeeze multiple channels of 400ZR transmission onto a 75-GHz grid enables per-fiber capacity to stretch to 25.6 Tbps s (400 Gbps/channel x 64 channels)

Betaalbaarheid is een ander verhaal

De uitdaging zit echter in de afstanden. Dan gaan dingen als dispersie behoorlijk opspelen. Tot een km of 100 is het allemaal 'relatief' te doen, maar praktijkervaring is er nog maar weinig. Meestal zie je 100 of 200Gbit linkjes. Ook de versterkers (edfa's) komt erg kritisch, SNR is erg belangrijk en met teveel repeaters blijft daar ook weinig van over.
Met nieuwere technieken als coherent kun je langere afstanden overbruggen, maar dat is weer wat beperkter in snelheid.

Regeneratie (Optisch - elektrisch - optisch, dus een switch ipv een versterker) kan, maar dat voegt latency toe en je hebt een set per wavelength nodig. Een efda is veel praktischer.
Echter loop je bij hogere snelheden en veel kanalen weer aan tegen dingen als laser clipping. Een versterker heeft een bepaalde versterking (bij een EDFA), maar dat vermogen moet gedeeld worden over alle kanalen. Het totale uitgangsvermogen is dus gerelateerd aan het aantal gebruikte kanalen.

[Reactie gewijzigd door DJSmiley op 23 juli 2024 00:29]

[Exhar]

Het SURFnet netwerk is (voor dit stuk) volledig gebaseerd op coherent technologie - waarbij dispersie niet zo zeer een probleem meer is. De uitdaging op dit soort afstanden is meer de optische waardes (OSNR) zo te krijgen dat de bandbreedte gehaald kan worden. Om een 400Gbps wave werkend te krijgen, heb je minder marge dan wanneer je 2x200Gbps waves (op 2 verschillende channels) gebruikt om 400Gbps bandbreedte te halen.

Daarom wordt er op dit trace ook gebruik gemaakt van RAMAN's ipv. EDFA's voor de versterking: waar een EDFA door 'spontaneous emission' (extra) noise genereert, heeft een RAMAN hier minder/geen last van.

Daarnaast wordt er hier gebruik gemaakt van een transponderkaart, zodat het probleem met optics in de client apparatuur er niet is: richting de client kan er gewoon gebruik gemaakt worden van gangbare (nouja..) 400GbE optics.

[Keypunchie]

Wat ik uit het artikel haal, is dat ze vooral Flex Grid ipv. Fixed Grid gaan gebruiken. Wat als ik het goed begrijp betekent dat je 'bredere' kanalen kunt hebben, waardoor je minder frequentieruimte in je signalling als buffer hoeft te gebruiken. (Het medium-artikel uit de nieuwspost was heel begrijpelijk: https://medium.com/@swapn...ssion-domain-6edd84f7f983 )

[jeffreytigch]

Een leuke podcast van de Technoloog over dit onderwerp, waar dit ook aan bod kwam volgens mij: https://www.bnr.nl/podcas...tatransport-en-verwerking

[rene_fb]

De dataverbinding die Nikhef met CERN in Zwitserland heeft is 1800 kilometer lang. Nu biedt die verbinding nog een maximale doorvoersnelheid van 100Gbit/s.

Hoe moet ik mij dit voorstellen? Heeft het Nikhef een eigen dedicated glasvezel van Amsterdam naar Zwitserland liggen?

[MauricevL]

Ik moet bekennen dat ik het antwoord niet weet maar ik het heerlijk vind dat dit een vraag is; dat je verbaasd kan zijn dat iemand al die moeite zou doen voor een kabel, want: de straat bij mij ligt ook al maanden open om een paar leidingen te verleggen /s.
Maar vergeet niet dat CERN gewoon een wereld wonder is; een van de knapste projecten in de historie van de mensheid. Een dedicated kabel graven van Genève naar Amsterdam daar zullen ze wel niet zo'n moeite mee hebben.

[ETH0.1]

Ze hebben het over een private network ( https://twiki.cern.ch/twiki/bin/view/LHCOPN/LHCopnAUP ) niet een Virtual Private Network. Zie het (outdated) network diagram voor nederland hier: https://twiki.cern.ch/twiki/bin/view/LHCOPN/SaraArchitecture

Fiber trekken is trouwens niet zo lastig als je denkt, veel fiber ligt langs spoorrails, daar kun je relatief snel meters maken

[Exhar]

SURFnet heeft een eigen darkfiber tussen Amsterdam en Geneve (Cern) liggen ja

[svangroning]

Ze huren waarschijnlijk stukken glasvezel en hebben onderweg 22 knooppunten zo te lezen. Op die knooppunten kan je dan optisch versterken.

De snelheid van 300Gbps die ze vorig jaar samen met ECI haalden was 300Gbps. Dat was volgens het artikel zonder versterking onderweg, wat ik wel erg verbazingwekkend vind gezien de lengte van het traject.

[Exhar]

Die glasvezel wordt inderdaad gehuurd met inderdaad 22 hops (mix van ILA/versterker sites en daadwerkelijke drop-sites waar routers en versterkers staan. Die routers zijn niet voor EOE, maar hebben hun eigen wave hebben).

Op dit hele trace heeft altijd versterking gezeten; de demping is simpelweg te groot om 't zonder te doen.

[BezurK]

Ik blijf die snelheden fascinerend vinden. Dat vond ik vroeger al toen 100mbit gemeengoed werd. Honderd miljoen bits per seconde! Ik vond het waanzinnig. Nu hebben we het over 400 miljard! Per seconde. Ongekend.

[Belgar]

Het bijzondere is de afstand, niet de snelheid. voor "in-house" kun je 1Tb optics al kopen (niet goedkoop, wel mogelijk). Echter zijn daar dus geen versterkers en standaarden voor. point-to-point only op dit moment

[arjankoole]

Ik denk het niet, simpelweg omdat ze raw sensor data van atlas totaal niet interessant vinden.

[lasermen]

ik ga er ook vanuit dat de AIVD deze verbinding niet interessant zal vinden om te tappen.
Maar het gaat mij er meer om of ze de techniek in huis hebben om zulke snelle verbindingen bij te houden? #dtv

[arjankoole]

Ik denk niet dat ze op zo’n schaal kunnen tappen op dit moment. Als je kijkt dat er over de amsix op piek moment 8+ Tb vliegt... dat is geen doen om allemaal te tappen.

Plus dat merendeel nutteloos encrypted data is. Ik verwacht (maar dit is allemaal giswerk van mijn kant) dat ze gerichter te werken gaan, omdat ze al die prut ook nog eens moeten decrypten.

[VisionMaster]

Een olifant eet je in kleine stukjes.