Case Study: Performance Analysis of a Virtualized XRootD Frontend in Large-Scale WAN Transfers

Dit artikel presenteert een gedetailleerde prestatieanalyse van de virtualisatie-architectuur van de T2_BR_SPRACE XRootD-frontend, die onder zware productiebelasting een aggregaat doorvoer van 51,3 Gb/s haalde, met pieken van 41,5 Gb/s naar Fermilab.

De kern

De Super-Highway voor Wetenschappelijke Data: Hoe SPRACE 51 Gigabit per Seconde Haalde

Stel je voor dat je een gigantische bibliotheek hebt, vol met de zwaarste boeken die de mensheid ooit heeft geschreven: de data van deeltjesversnellers zoals de LHC. Deze boeken moeten razendsnel naar andere bibliotheken over de hele wereld worden gestuurd, vaak naar de Verenigde Staten of Zwitserland.

Dit verhaal gaat over een team in Brazilië (SPRACE) dat een slimme manier heeft bedacht om deze data over de "internet-snelweg" te sturen, zonder dat het vastloopt in een file.

1. Het Probleem: Een File op de Snelweg

Normaal gesproken is het alsof je een vrachtwagen met boeken probeert te laden via een smalle poort. De computer (de backend) kan de boeken heel snel ophalen, maar de poort naar buiten (het internet) is vaak te smal of de bestuurder van de vrachtwagen (het besturingssysteem) is te voorzichtig en rijdt te langzaam.

Het team wilde de 100 Gb/s snelweg (een super-snel internetverbinding) volledig volproppen met data. Maar standaardsoftware is vaak te traag voor zo'n snelheid.

2. De Oplossing: Een Slimme Logistieke Hub

In plaats van één grote vrachtwagen te gebruiken, bouwden ze een park van 8 virtuele vrachtwagens (Virtual Machines of VM's).

• De Achterkant (De Bibliotheek): Ze hadden een enorme data-opslag (dCache) met 12 schijven die data razendsnel konden uitlezen. Dit was als een magazijn met 12 super-snelle pakketbanden.
• De Voorkant (De Vrachtwagens): De 8 virtuele machines fungeerden als de vrachtwagens die de data oppakken en de snelweg oprijden.
• De Slimme Bestuurders (BBR): Het geheim van hun succes was niet alleen de vrachtwagens, maar de bestuurders. Ze gebruikten een slim algoritme genaamd BBR.
  • De Analogie: Stel je voor dat een normale bestuurder (standaard software) voorzichtig rijdt en wacht tot hij zeker weet dat de weg vrij is, waardoor hij veel tijd verliest. De BBR-bestuurder is echter een Formule 1-coureur. Hij voelt de weg, weet precies hoe snel hij kan rijden zonder te crashen, en houdt de motor altijd op het maximale toerental. Hij past zijn snelheid continu aan op basis van de verkeersdrukte, in plaats van te wachten.

3. De Technische "Tweaks": De Vrachtwagens Verbeteren

Om deze Formule 1-couleurs echt te laten presteren, moesten ze de vrachtwagens zelf aanpassen:

• Grotere Koffers: Ze vergrootten de "koffers" (geheugenbuffers) in de vrachtwagens. Normaal zijn deze klein, maar voor zo'n snelheid hadden ze enorme koffers nodig om duizenden boeken tegelijk vast te houden zonder te vertragen.
• Directe Toegang: Sommige vrachtwagens kregen een speciale sleutel (SR-IOV) om direct de motor van de vrachtwagen aan te sturen, zonder dat er een tussenpersoon (de hypervisor) tussen zat. Dit maakte ze nog sneller.

4. Het Resultaat: Een Recordbrekende Rit

Op een ochtend in oktober 2025 zette het team alles op scherp.

• Het Magazijn: De achterkant kon theoretisch 77 Gb/s aan data leveren.
• De Prestatie: De 8 vrachtwagens samen haalden een topsnelheid van 51,3 Gb/s.
• De Enkele Rit: Een enkele vrachtwagen die naar Fermilab (in de VS) reed, haalde zelfs 41,5 Gb/s.

Dit is alsof je een vrachtwagen laat rijden met de snelheid van een straalvliegtuig, terwijl hij volgeladen is. En het beste? De vrachtwagen viel niet uit. De "Formule 1-coureur" (BBR) hield de controle, zelfs toen het drukst was.

5. Wat ging er mis? (En wat niet)

Niet alles was perfect. Van alle 5.696 ritjes die ze maakten, faalden er ongeveer 22%.

• De Oorzaak: Het was niet de snelheid of de vrachtwagens die faalden. Het probleem zat bij de ontvangers in de VS. Een specifieke bestemming (een computer in Fermilab) was gewoon stuk of niet bereikbaar.
• De Overwinning: De route naar de belangrijkste bestemmingen (zoals CERN in Zwitserland en Fermilab) liep bijna perfect. De 41,5 Gb/s rit naar Fermilab was 100% succesvol.

Conclusie: Waarom is dit belangrijk?

Dit verhaal laat zien dat je niet altijd duurdere hardware nodig hebt om sneller te zijn. Soms moet je gewoon de bestuurders (de software-instellingen) slimmer maken.

Door de "Formule 1-coureur" (BBR) te gebruiken en de vrachtwagens (de servers) goed voor te bereiden, konden ze een enorme hoeveelheid wetenschappelijke data over de hele wereld sturen. Ze haalden meer dan de helft van de maximale snelheid van hun 100 Gb/s snelweg, wat een enorme prestatie is voor een virtueel systeem.

Kortom: Ze bewezen dat je met de juiste instellingen en een slimme aanpak, zelfs met bestaande middelen, de snelste data-transporteurs ter wereld kunt worden.

Technische samenvatting

Hier is een gedetailleerde technische samenvatting van het artikel "Performance Analysis of a Virtualized XRootD Frontend in Large-Scale WAN Transfers", geschreven in het Nederlands.

Technische Samenvatting: Prestatieanalyse van een Gevirtualiseerde XRootD Frontend

Probleemstelling
Distributed computing voor experimenten in de Hoge Energie-fysica (zoals CMS bij de LHC) vereist de efficiënte overdracht van petabytes aan data via het Worldwide Computing Grid (WLCG). Een veelvoorkomende uitdaging voor rekencentra (Tiers) is het aggregeren van heterogene opslagendpunten om hoge-capaciteit WAN-verbindingen (Wide Area Network) volledig te benutten. Traditionele configuraties met standaard besturingssysteeminstellingen (vaak gericht op het CUBIC-congestie-algoritme en beperkte TCP-buffergroottes) blijken ontoereikend om hoge-latentie, hoog-bandbreedte WAN-links (zoals 100 Gb/s) te verzadigen. Het doel was om de prestaties van een complexe, gevirtualiseerde architectuur onder zware productielast te documenteren en te analyseren.

Methodologie en Architectuur
De studie analyseert de opslagarchitectuur van het T2_BR_SPRACE-voorzieningspunt, een decoupled systeem dat bestaat uit:

• Backend: 12 dCache-opslagpools die data leveren via het pNFS-protocol (parallel NFS 4.1) om bottlenecks van NFS-gateways te elimineren.
• Frontend: Een cluster van 8 XRootD-servers die draaien als Virtuele Machines (VM's). Deze VM's hebben toegang tot 10 Gb/s en 40 Gb/s netwerkkaarten (NIC's), waarbij de 40 Gb/s-hosts SR-IOV (Single Root I/O Virtualization) gebruiken voor directe hardwaretoegang (PCI passthrough).
• Netwerkconfiguratie: Het systeem gebruikt de CERN File Transfer Service (FTS) voor orchestration en een lokale XRootD-redirector voor verkeer.

Kernconfiguraties en Optimalisaties
Om de 100 Gb/s WAN-link te benutten, werden specifieke kernel-niveau optimalisaties toegepast die afwijken van de standaard OS-instellingen:

1. Congestiebesturing: Inschakelen van Google's BBR (Bottleneck Bandwidth and Round-trip propagation time) algoritme in plaats van CUBIC.
2. TCP-buffervergroting: De maximale geheugentoewijzing voor buffers (net.core.rmem_max en net.core.wmem_max) werd verhoogd tot een plafond van 2048 MiB.
3. Window Scaling: Activering van RFC 1323-optimalisaties (tcp_window_scaling en tcp_timestamps) om de 64 KB limiet te doorbreken.
4. Aangepaste Advertentie: De parameter tcp_adv_win_scale werd ingesteld op 1, waardoor 50% van de buffer (max. 1024 MiB) als advertentie-venster wordt gebruikt. Dit creëert een veiligheidsmarge voor de applicatie om data uit de socket te lezen terwijl de kernel dynamisch grote buffers toewijst.
5. Verbindingslimieten: Verhoging van limieten voor wachtende verbindingen (somaxconn) en netwerkapparatuur-backlog (netdev_max_backlog) tot 65.536.

Belangrijkste Resultaten
Tijdens een piekperiode op 17 oktober 2025 werden de volgende prestaties gemeten:

• Totale Aggregate Throughput: Het systeem bereikte een piek van 51,3 Gb/s aan uitgaand verkeer van het XRootD-cluster naar de WAN.
• Enkele Dataflow (SPRACE → FNAL): Een specifieke datastroom naar Fermilab (FNAL) piekte op 41,5 Gb/s. Deze meting werd onafhankelijk geverifieerd door monitoringstools van CERN.
• Betrouwbaarheid: Tijdens de piekbelasting van 41,5 Gb/s op de link naar FNAL werden geen fouten geregistreerd. De algehele succesratio voor alle transfers was 78%, waarbij mislukkingen voornamelijk werden toegeschreven aan problemen bij specifieke bestemmingen (zoals cmstnvm1.fnal.gov) en niet aan de bronarchitectuur.
• Backend Capaciteit: De theoretische I/O-capaciteit van de backend (dCache) werd gemeten op 77,36 Gb/s, wat aantoont dat de schijf I/O niet de beperkende factor was.

Bottleneck Analyse
De analyse concludeert dat de bottleneck niet in de disk I/O lag (die 77 Gb/s aankan), maar in de aggregatiecapaciteit van de frontend VM-cluster. De limiet van 51,3 Gb/s wordt veroorzaakt door de gezamenlijke saturatie van de VM-ressourcen (CPU-contentie, RAM-beperkingen voor TCP-buffers, of NIC-limieten) terwijl 530 gelijktijdige BBR-streams worden beheerd.

Significantie en Bijdrage
Dit artikel levert een waardevolle case study voor de High Energy Physics-community door:

1. Validatie van Virtualisatie: Het bewijst dat een heterogene cluster van gevirtualiseerde XRootD-servers (met SR-IOV) in staat is om een dCache/pNFS-backend te aggregeren en een aanzienlijk deel (51%) van een 100 Gb/s WAN-link te verzadigen.
2. Configuratiebewijs: Het demonstreert dat standaard OS-instellingen ontoereikend zijn voor moderne hoge-snelheidsnetwerken en dat een specifieke combinatie van BBR, enorme TCP-buffers en window scaling essentieel is voor succes.
3. Stabiliteit onder Last: Het documenteert dat deze geoptimaliseerde configuratie stabiel blijft onder extreme last, met name geïllustreerd door de foutloze prestaties van 41,5 Gb/s op een enkele link.

De studie bevestigt dat de toegepaste netwerkconfiguratie een kritiek component is om de architectuur in staat te stellen de benodigde bandbreedte voor wereldwijde dataoverdrachten te leveren.