SmartNIC's in hosting: netwerkversnelling op de juiste manier beoordelen

SmartNIC's op de juiste manier inpassen in hosting

De term SmartNIC is geen uniform gestandaardiseerde productnaam. Voor de planning op het gebied van hosting is daarom niet het label doorslaggevend, maar de aantoonbare functie in het datapad: welke pakketten, regels en tunnels kan de kaart verwerken, welke taken blijven bij de host en welke software stuurt de functies aan? Een hoge poortsnelheid geeft geen antwoord op deze vragen.

Een klassieke netwerkkaart biedt vooral de Ethernet-verbinding en ondersteunt gangbare basis-offloads, zoals checksums of segmentatie. Een SmartNIC breidt dit kader uit met gespecialiseerde of programmeerbare datapadfuncties. Hieronder kunnen flowregels, virtuele switchingfuncties, SR-IOV, tunnelverwerking of cryptografische subtaken vallen. Of deze functies bruikbaar zijn, wordt echter bepaald door het model, de firmware, de stuurprogramma’s en de platformintegratie samen.

A DPU is doorgaans uitgebreider opgezet: naast de netwerk-ASIC beschikt deze over eigen rekenkracht en kan hij een afzonderlijk infrastructuur-gegevenspad beheren. NVIDIA beschrijft voor BlueField een DPU-modus, waarin het geïntegreerde Arm-systeem de NIC-bronnen en het datapad beheert, en een NIC-modus, waarin de kaart zich ten opzichte van de externe host gedraagt als een adapter. Hierdoor ontstaat, afhankelijk van de bedrijfsmodus, ook een eigen beheer- en vertrouwensdomein.

Deze indeling heeft praktische gevolgen voor de aanschaf en het gebruik. Een kaart met een eigen rekenlogica is niet automatisch de betere keuze als er alleen eenvoudige basis-offloads nodig zijn. Omgekeerd kan een uitbestede infrastructuur voor client-isolatie of beveiligingsfuncties zinvol zijn, maar vereist dan wel firmwareonderhoud, toegangsconcepten, monitoring en herstelprocessen voor extra componenten.

Zelfs een 100-GbE-poort of een snellere poort zorgt niet voor een versnelling van firewallregels, overlays of versleuteling. Bepalend zijn de pakketgrootte, het aantal parallelle flows, de omvang van de regels en de vraag of de benodigde acties daadwerkelijk in hardware kunnen worden geïmplementeerd. Pas wanneer aantoonbaar blijkt dat de server-CPU een beperkende factor is in het netwerkdatapad, leidt een lijst met functies tot een mogelijke capaciteitswinst.

Hoe hardware-offload het gegevenspad verandert

Zonder verdere offload komt een pakket eerst bij de fysieke NIC terecht en wordt vervolgens door de host verwerkt. Afhankelijk van de architectuur doorloopt het de kernel-netwerkstack, firewall, bridge of virtuele switch, routing en eventueel de inkapseling voor een overlay. Pas daarna bereikt het een VM, een container of een andere fysieke poort. Elke stap kan CPU-tijd en wachtrijen veroorzaken.

Dit traject is vooral van belang bij veel kleine pakketten, talrijke kortstondige verbindingen of omvangrijke klantbeleidsregels. Niet alleen de hoeveelheid overgedragen gegevens belast de host, maar ook de herhaalde verwerking van afzonderlijke pakketten en stromen. Daarom is netwerkversnelling geen algemene eigenschap van een server, maar een gerichte ontlasting van een concreet geïdentificeerd gegevenspad.

Op Hardware-offload kunnen besturingscomponenten toegestane doorstuur- en filterregels doorgeven aan een hardware-datapad. Het Linux-switchdev-model beschrijft hiervoor de verplaatsing van het doorstuurpad van de kernel naar een switch-apparaat. Welke regels daadwerkelijk worden overgenomen, hangt af van de specifieke kaart, het bijbehorende stuurprogramma en de bovenliggende netwerkintegratie.

In de OVS-documentatie van de ontwikkelingsbranch 4.0.90 wordt een apart hoofdstuk over Flow Hardware Offload uitdrukkelijk als experimenteel omschreven. Voor precies deze OVS-met-DPDK-configuratie maakt de documentatie onderscheid tussen volledige offload van matches en acties en gedeeltelijke offload, waarbij alleen matches worden uitbesteed. Deze beschrijving is geen stabiel, algemeen geldend bewijs van compatibiliteit voor andere OVS-versies, NIC's of platforms.

In de praktijk moet elke offload-verklaring daarom het concrete gegevenspad specificeren: de gebruikte softwareversie, stuurprogramma’s, firmware, match-velden en acties. Een geactiveerde schakelaar bewijst noch dat relevante flows worden uitbesteed, noch dat aan de beveiligings- en netwerksemantiek ongewijzigd wordt voldaan. Bij VLAN-filtering eist switchdev bijvoorbeeld dat de hardware zich aan de bridge-VLAN-regels houdt en niet-toegestane VLAN-ID’s afwijst. Offload is daarmee de technische implementatie van bestaande regels, geen omweg om ze te omzeilen.

Wanneer is het zinvol om SmartNIC's te gebruiken bij hosting?

SmartNIC’s zijn vooral zinvol op virtualisatieplatforms met veel VM’s en terugkerende doorstuurbeslissingen. SR-IOV kan een virtuele functie aan een VM toewijzen; in een switchdev-architectuur geven representor-interfaces fysieke of virtuele functies weer in het besturingssysteem. Regels voor het verkeer tussen deze poorten kunnen daardoor in hardware worden geïmplementeerd. Het nut hangt echter af van de benodigde VM-functies.

Overlay-netwerken met ondersteuning voor meerdere clients en Microsegmentatie vormen een ander uitgangspunt. Wanneer veel klantnetwerken herhaaldelijk gebruikmaken van VLAN- of overlay-toewijzingen, toegangsbeheersregels en soortgelijke flowbeslissingen, kan een geschikt hardware-gegevenspad de host-CPU’s ontlasten. Voorwaarde blijft dat het aantal regels, matchvelden en acties beschikbaar zijn in de gekozen kaart inclusief driver en dat de semantiek van de beleidsregels volledig behouden blijft.

Voor OpenShift Container Platform 4.22 documenteert Red Hat hardware-offload voor bare-metal-knooppunten met een compatibele SmartNIC en een actieve SR-IOV Network Operator. Hier worden alleen pod-naar-pod-communicatie en pod-naar-ClusterIP-service met reguliere pods ondersteund; DPDK-toepassingen zijn niet compatibel met deze functie. Het voordeel is bovendien beperkt tot communicatiesegmenten waarbij de betrokken knooppunten compatibele SmartNIC's gebruiken.

Bij versleutelde host- of locatienetwerken kan IPsec-offload deelopdrachten of het gehele proces van inkapseling, ontkapseling, versleuteling en bescherming tegen replay-aanvallen overnemen. NVIDIA beschrijft hiervoor verschillende soorten offload, waaronder crypto- en volledige offload. Dit betekent echter niet dat deze voor alle situaties geschikt zijn: ondersteuning en prestatiegrenzen zijn afhankelijk van het model, de firmware en de cryptografische methode.

Een eenvoudige webhostingserver is bewust gekozen als tegenvoorbeeld. Als deze voornamelijk enkele, grotere HTTP-antwoorden levert en geen CPU-belasting in het pakketpad vertoont, kan meer gespecialiseerde serverhardware zorgen alleen maar voor extra operationele lasten. Eerst moet worden vastgesteld of de applicatie, de database, de opslag of het netwerk de oorzaak van de bottleneck is. SmartNIC’s zijn geen geschikte vervanging voor deze diagnose.

Toepassingen technisch vergelijken

Of een SmartNIC zinvol is, hangt niet af van de nominale poortsnelheid, maar van het concrete datapad. Het is vooral zinvol wanneer veel terugkerende regels, hoge flow-aantallen of overlay- en beveiligingsfuncties voortdurend host-CPU-tijd in beslag nemen. Het voordeel blijft trajectafhankelijk: Een versneld gedeelte helpt alleen de verbindingen die daadwerkelijk via compatibele hardware en ondersteunde regels lopen.

Bij VM-platforms is SR-IOV Een typische aanpak: virtuele functies worden aan een VM toegewezen, terwijl Representor-interfaces in het besturingssysteem de poorten van dergelijke functies weergeven. Hierdoor kunnen doorstuurregels tussen virtuele en fysieke poorten in een switchdev-georiënteerde architectuur in hardware worden geïmplementeerd. Dit is echter geen vervanging voor een controle of de gewenste scheiding tussen clients en het bedrijfsmodel behouden blijven.

Kubernetes is het tegenovergestelde van een algemene belofte van versnelling. Voor de gedocumenteerde OpenShift 4.22-integratie gelden bepaalde ondersteunde verkeerspaden, compatibele SmartNIC-knooppunten en vereisten voor workloads. Als een knooppunt dat offload ondersteunt communiceert met een regulier knooppunt, verwerkt dat reguliere knooppunt zijn deel in de kernel en beperkt daarmee het totale pad. Bij een uitrol moet daarom in eerste instantie rekening worden gehouden met een afgebakende knooppuntenpool en reële communicatiepaden.

Bij versleutelde host- of locatienetwerken moeten deze termen bijzonder nauwkeurig worden gebruikt. Gedocumenteerde IPsec-varianten variëren, afhankelijk van het platform, van crypto-offload tot volledige offload voor encapsulatie, decapsulatie, versleuteling en replay-bescherming. Hieruit volgt geen algemene doorvoergarantie: het model, de firmware, de gebruikte algoritmen en productgebonden beperkingen bepalen welke verwerking daadwerkelijk wordt uitbesteed.

Controleer de compatibiliteit vóór de uitrol

Een aanschaf begint met een objectieve inventarisatie, niet met het inschakelen van offload-opties. Leg het exacte kaartmodel vast, inclusief PCI-ID, firmwareversie, stuurprogramma's en kernel. Daarnaast moeten de eSwitch-modus en de versie en configuratie van Open vSwitch, OVN, de hypervisor of het Kubernetes-platform bekend zijn, omdat de mogelijkheden van de kaart op zich nog geen volledige software-integratie garanderen.

De benodigde regel-semantiek moet vooraf beschikbaar zijn in de vorm van een beschrijving van het gegevenspad: bijvoorbeeld VLAN-toewijzing, IPv4 of IPv6, TCP of UDP, tunneltype, headerwijziging, doorsturen of verwijderen. Uit de experimentele OVS 4.0.90-documentatie blijkt voor de DPDK-configuratie dat ontbrekende hardwareacties kunnen leiden tot gedeeltelijke offload. Hieruit volgt voor elke andere versie of elk ander platform slechts een verzoek om controle, geen garantie met betrekking tot de functionaliteit ervan.

Platformmatrices zijn versiegebonden compatibiliteitsverklaringen, geen algemene uitspraken over een NIC-familie. OpenShift 4.22 noemt voor zijn hardware-offload-integratie specifieke NIC’s, waaronder BlueField-2 in de ConnectX-6-NIC-modus. Hieruit kan noch de ondersteuning van andere firmware, noch van een andere DPU-modus of een afwijkende distributie worden afgeleid. Documenteer daarom elke combinatie van hardware, firmware, stuurprogramma en platformversie afzonderlijk.

Voor Linux-switchdev is het bovendien van cruciaal belang dat de hardware de semantiek van het softwarenetwerk in stand houdt. Bij VLAN-filtering moet een switch die taken afkoppelt bijvoorbeeld de VLAN-regels van de bridge in acht nemen en niet-toegestane VLAN-ID's afwijzen. Deze eis laat zien waarom functielijsten en beveiligingsbeleid gezamenlijk moeten worden gecontroleerd: versnelling mag geen afwijkende netwerksegmentatie veroorzaken.

SmartNIC afwegen tegen CPU en software

Een SmartNIC is slechts één van de vele opties wanneer de netwerkverwerking beperkt is. Het loont de moeite om eerst na te gaan of meer CPU-capaciteit, een geschikt aantal wachtrijen, RSS, IRQ-verdeling of kernel-tuning het knelpunt al kunnen verhelpen. Voor meer informatie over SoftIRQ's, wachtrijen en interruptverdeling verwijzen we naar het artikel over CPU- en netwerkdoorvoer bij hosting aanvullende basisprincipes. Zonder bewijs van een netwerkbottleneck blijft extra speciale hardware een veronderstelling.

DPDK en AF_XDP kunnen softwarepaden op host-CPU’s verkorten, maar vereisen elk een eigen architectuur- en CPU-planning. De opmerking over permanente polling kan niet zonder meer op beide benaderingen worden toegepast: In de OVS-DPDK-documentatie voor de beschreven configuratie pollt een thread continu DPDK-apparaten en neemt daarbij een CPU-kern volledig in beslag. NUMA-toewijzing, kernisolatie en de specifieke OVS- en DPDK-versie blijven daarom onderdeel van het ontwerp.

Ook een klassieke server-NIC kan voldoende offloads bieden voor checksums, segmentatie of afzonderlijke tunnelkenmerken. Deze keuze is geschikt wanneer er geen uitgebreide virtuele switchregels, scheiding tussen tenants of beveiligde gegevenspaden in hardware nodig zijn. SmartNIC's zijn vooral zinvol wanneer de vereiste functies verder gaan dan dergelijke basisfuncties en op de lange termijn terugkerend zijn.

Het concept van capaciteit is eenvoudig, maar belangrijk: als CPU-kernen op een host volledig worden benut door pakketverwerking en een representatief deel van deze pakketten volledig kan worden afgevoerd, ontstaat er mogelijk CPU-speling. Deze speling geldt echter alleen als bruikbare capaciteit als er geen applicatie, geheugen, opslag of software-fallback is die het volgende knelpunt vormt. Het is geen directe afleiding van de linkrate of de prijs van de kaart.

Vergelijk daarom alternatieven op basis van hetzelfde belastingsprofiel: pakketgroottes, verbindingssnelheid, aantal regels, tunnels, versleuteling en verwachte piekbelasting. Bekijk daarbij de CPU-aandelen van het datapad los van het applicatiewerk en controleer welke flows daadwerkelijk in de hardware worden verwerkt. Een CPU-bottleneck Een firewall, overlay of virtuele doorsturing vormt een gegronde aanleiding voor een beoordeling; een algemeen hoge systeembelasting is dat niet.

Offload tijdens het gebruik zichtbaar maken

Na de implementatie is het niet voldoende om een offload-optie als actief te beschouwen. Een betrouwbaar bewijs van de werking koppelt de Flow-status met tellers van de kaart, drop- en foutpercentages, CPU-belasting en een belastingsprofiel dat lijkt op het latere verkeer. Pas samen laten deze gegevens zien of relevante flows daadwerkelijk in de hardware worden verwerkt of dat de host nog steeds het grootste deel van het datapad voor zijn rekening neemt.

Voor de vergelijking moeten beheerders voor en na een wijziging rekening houden met dezelfde pakketgroottes, protocollen, het aantal verbindingen en richtlijnen. Een zuivere gigabit-doorvoer kan gemakkelijk een knelpunt bij kleine pakketten of veel parallelle flows verhullen. Even belangrijk zijn latentie, CPU-tijd per betrokken host, Softirq-belasting, queue-drops en de verdeling van het verkeer over knooppunten en poorten.

De volgende opdrachten brengen geen wijzigingen aan in de configuratie. De eerste query houdt zowel rekening met PCI-apparaten die als Ethernet-controller worden weergegeven, als met apparaten die als netwerkcontroller worden weergegeven. ethtool -k toont aangeboden of op de Netdev geactiveerde offload-functies, maar levert geen volledig bewijs voor eSwitch-, SmartNIC- of flow-offload. Ook de overige uitvoer bestaat uit inventaris- en configuratiegegevens, en vormt geen bewijs voor een specifieke, volledig uitbestede regel.

lspci -nn | grep -Ei 'Ethernet controller|Network controller'
ethtool -k <interface>
ethtool -i <interface>
devlink dev show
ovs-vsctl get Open_vSwitch . other_config

Bij Open vSwitch moet met name onderscheid worden gemaakt tussen geconfigureerde hardwareversnelling en het waargenomen resultaat. De ontwikkelingsdocumentatie van OVS 4.0.90 bestempelt de hardware-offload van de flow als experimenteel en beschrijft volledige of gedeeltelijke offload alleen voor deze OVS-met-DPDK-configuratie. Voor productiegebruik moeten daarom flow-informatie en hardwaretellers samen met de host-softwaretellers worden geëvalueerd.

Monitoring vereist bovendien een tijdsreferentie. Een korte test kan regels bevestigen, terwijl een profiel dat dicht bij de productie ligt later tabellencapaciteiten, zeldzame logboekpaden of herconfiguraties kan activeren. Het is daarom zinvol om normale waarden en afwijkingen per kaartmodel, firmware, stuurprogramma en platformversie vast te leggen. Zo kan na updates worden nagegaan of de Datapad of dat alleen de waargenomen belasting is veranderd.

In de OpenShift 4.22-integratie moet het overzicht bovendien het volledige communicatiepad omvatten. De gedocumenteerde ondersteuning voor hardware-offload geldt alleen voor bepaalde workloads en communicatietypen. Als een compatibele node communiceert met een node zonder geschikte SmartNIC, verwerkt deze node zijn deel in de kernel; meetpunten op slechts één host kunnen dan het end-to-end-traject onvolledig weergeven.

Typische foutpatronen en terugvaltrajecten

De meest voorkomende fout is onvolledige offload. Een flow kan aan de hand van eenvoudige kenmerken in de hardware worden herkend, maar moet voor een niet-ondersteunde actie gedeeltelijk of volledig terugkeren naar het softwarepad. De experimentele OVS 4.0.90-documentatie beschrijft deze gedeeltelijke offload voor de DPDK-configuratie. Dit is geen algemene uitspraak over elke OVS-installatie, maar maakt wel duidelijk wat bij elke concrete integratie moet worden gecontroleerd.

De diagnose begint langs het daadwerkelijke pad: ingangspoort, virtuele functie of representor, switch-regel, tunnel- of beleidsverwerking en doel-workload. Als de tellers vóór en achter een fase niet op plausibele wijze met elkaar overeenkomen, is dat een aanleiding om matches, acties en fallback te controleren. Een geactiveerde functie vervangt deze toewijzing niet, omdat de mogelijkheden van de kaart niet elke gewenste regelcombinatie omvatten.

Heterogene clusters maken de vergelijking moeilijker. Voor OpenShift 4.22 vindt hardware-offload alleen plaats als de betrokken pods en services zijn toegewezen aan knooppunten met een compatibele SmartNIC. Als een dergelijk pad een regulier knooppunt tegenkomt, vindt de verwerking daarvan plaats in de kernel en wordt de totale communicatie beperkt. Een enkel versneld knooppunt neemt daarom geen volledig versneld clusterpad in beslag.

Ook een onjuiste pod- of netwerkconfiguratie kan het verwachte effect verhinderen. Red Hat wijst er voor de OpenShift 4.22-functie uitdrukkelijk op dat geactiveerde hardware-offload zonder dienovereenkomstig geconfigureerde pods de pod-doorvoer kan verslechteren. Beheerders moeten een afwijking daarom niet verhelpen door nog meer opties in te schakelen, maar eerst de koppeling van de workload, de netwerkmodus en de daadwerkelijk bereikte doorvoersnelheden controleren.

Regelcapaciteit en firmware-afwijkingen vallen onder dezelfde foutklasse: bij veel clients, kortstondige verbindingen of dynamische beleidsregels kan de relevante flowhoeveelheid anders toenemen dan verwacht. Een versieggebonden stuurprogramma of afwijkende firmware kan bovendien functies op een andere manier aanbieden dan de geplande platformcombinatie. Daarom moeten inventarisgegevens en tellers altijd samen met de concrete regelverzameling worden gearchiveerd.

A gecontroleerd terugvaltraject zorgt ervoor dat de werking diagnosticeerbaar blijft. Dit houdt in dat de softwareverwerking als beoogd alternatief behouden blijft en dat wijzigingen stapsgewijs worden doorgevoerd, met een vergelijkingsvenster en duidelijke afbrekingscriteria. De software-fallback is daarbij niet automatisch een defect, maar kan de verwachte afhandeling zijn van acties die het gekozen hardwarepad niet volledig ondersteunt.

Realistische beslissingen nemen over inkoop en exploitatie

Een aankoopbeslissing begint bij de werklast, niet bij de poortsnelheid of de productnaam. Gespecialiseerde hardware is zinvol wanneer terugkerende pakketverwerking aantoonbaar CPU-tijd in beslag neemt: bijvoorbeeld bij talrijke virtuele netwerken, stabiele beleidsregels, overlay-verkeer of een gedefinieerd versleutelingspad. Ontbreekt dit bewijs, dan kunnen CPU- en wachtrij-tuning of een klassieke NIC met passende basis-offloads de eenvoudigere oplossing zijn.

Vervolgens moet de Compatibiliteitsverklaring voor de specifieke combinatie: kaartmodel en bedrijfsmodus, firmware, stuurprogramma’s, kernel, virtuele switch of CNI, evenals de benodigde match- en actiefuncties. Programmeerbare infrastructuurversnellers kunnen bijvoorbeeld flow-offload bieden voor status- of sessiegerelateerde functies; hieruit volgt echter niet dat elke SmartNIC of elk platform dezelfde functie biedt.

De verwachte ontlasting van de CPU is pas als capaciteit beschikbaar wanneer de pakketverwerking het knelpunt was en de vrijgekomen kernen zinvol kunnen worden ingezet. Als ze bijvoorbeeld worden ingezet voor databases, webworkers of als reserve, is dat een architecturale keuze en geen automatische prestatieverbetering. De overige serverconfiguratie blijft daarom van cruciaal belang; CPU, werkgeheugen en opslag moeten net zo goed bij de toepassing passen als het netwerk. Meer context voor de algehele afweging biedt het artikel over prestatiegerichte serverhardware bij webhosting.

Bij IPsec is de controle bijzonder gedetailleerd: gedocumenteerde offload-varianten variëren van crypto-offload tot volledige uitbesteding van encapsulatie, decapsulatie, versleuteling en replay-bescherming. Welke variant bruikbaar is, hangt af van het model, de generatie, de firmware en de cryptoconfiguratie. Productspecifieke opmerkingen kunnen bovendien beperkingen voor bepaalde generaties of bandbreedtes bevatten; deze moeten vóór de uitrol worden meegenomen in de goedkeuringscontrole.

Een DPU breidt de beslissing uit met een eigen beheer- en vertrouwensdomein. In de BlueField-DPU-modus beheert het geïntegreerde Arm-systeem de NIC-bronnen en het datapad, in plaats van dat de kaart uitsluitend als hostadapter fungeert. Dit maakt het mogelijk om infrastructuurtaken van de host te scheiden, maar vereist wel een robuust concept voor toegangsrechten, images, updates, monitoring en herstel.

Economisch gezien telt daarom niet alleen de prijs van de kaart. Daartegenover staan de bespaarde of vermeden host-CPU-capaciteit, de verwachte levensduur van het platform en de extra kosten voor kwalificatie, reserveonderdelen, firmware-onderhoud en incidentherstel. Een SmartNIC is zinvol als deze afweging is gebaseerd op een reproduceerbaar gegevenspad en een levenscyclus die permanent beheersbaar is – niet omdat gespecialiseerde hardware in principe sneller lijkt.