SmartNIC'er i hosting: Sådan vurderer man netværksacceleration korrekt

Sådan placeres SmartNIC'er korrekt i hosting-løsninger

Begrebet SmartNIC er ikke et ensartet standardiseret produktnavn. Ved planlægningen af hosting er det derfor ikke betegnelsen, der er afgørende, men den påviselige funktion i datavejen: Hvilke pakker, regler og tunneler kan kortet håndtere, hvilke opgaver forbliver hos værten, og hvilken software styrer funktionerne? En høj porthastighed giver ikke svar på disse spørgsmål.

Et klassisk netværkskort leverer først og fremmest Ethernet-forbindelsen og understøtter almindelige grundlæggende offload-funktioner, såsom kontrolsummer eller segmentering. Et SmartNIC udvider denne ramme med specialiserede eller programmerbare datavejsfunktioner. Dette kan omfatte flow-regler, virtuelle switching-funktioner, SR-IOV, tunnelbehandling eller kryptografiske delopgaver. Om disse funktioner kan benyttes, afhænger dog af en kombination af model, firmware, drivere og platformintegration.

En DPU er som regel mere omfattende opbygget: Ud over netværks-ASIC’en har den egne beregningsressourcer og kan drive en separat infrastruktur-datavej. NVIDIA beskriver for BlueField en DPU-tilstand, hvor det integrerede Arm-system styrer NIC-ressourcer og datavejen, samt en NIC-tilstand, hvor kortet fungerer som en adapter over for den eksterne vært. Dette skaber dermed, afhængigt af driftstilstanden, også et eget administrations- og tillidsområde.

Denne klassificering har praktiske konsekvenser for indkøb og drift. Et kort med egen beregningslogik er ikke automatisk det bedste valg, hvis der kun er behov for enkle, grundlæggende offloads. Omvendt kan en udlagret infrastrukturvej være fornuftig med henblik på klientadskillelse eller sikkerhedsfunktioner, men kræver i så fald firmwarevedligeholdelse, adgangskoncepter, overvågning og gendannelsesprocesser for yderligere komponenter.

Selv en 100-GbE-port eller en hurtigere port medfører ingen hastighedsforøgelse for firewall-regler, overlays eller kryptering. Det afgørende er pakkestørrelse, antallet af parallelle flows, regelomfanget og spørgsmålet om, hvorvidt de nødvendige handlinger rent faktisk kan implementeres i hardware. Først når det kan påvises, at server-CPU’en udgør en begrænsning i netværksdatavejen, bliver en liste over funktioner til en mulig kapacitetsgevinst.

Hvordan hardware-offload ændrer datavejen

Uden yderligere offload når en pakke først frem til det fysiske netværkskort og behandles derefter af værten. Afhængigt af arkitekturen passerer den gennem kernelens netværksstack, firewall, bridge eller virtuel switch, routing og eventuelt indkapsling til et overlay. Først derefter når den en VM, en container eller en anden fysisk port. Hvert trin kan medføre CPU-tid og køer.

Denne fremgangsmåde bliver især relevant, når der er tale om mange små pakker, et stort antal kortvarige forbindelser eller omfattende klientpolitikker. Det er ikke kun den overførte datamængde, der belaster værten, men også den gentagne behandling af enkelte pakker og datastrømme. Derfor er netværksacceleration ikke en generel egenskab ved en server, men en målrettet aflastning af en konkret identificeret datavej.

På Hardware-aflastning kan styringskomponenter overføre tilladte videresendelses- og filterregler til en hardwaredatavej. Linux-switchdev-modellen beskriver i denne sammenhæng flytningen af videresendelsesdatastien fra kernen til en switch. Hvilke regler der rent faktisk overtages, afhænger af det konkrete kort, dets driver og den overliggende netværksintegration.

OVS-dokumentationen i udviklingsgrenen 4.0.90 beskriver udtrykkeligt et særskilt afsnit om Flow Hardware Offload som eksperimentelt. Netop for denne OVS-med-DPDK-konfiguration skelner den mellem fuldstændig offload af matches og handlinger samt delvis offload, hvor kun matches udlades. Denne beskrivelse udgør ikke et stabilt, generelt gyldigt kompatibilitetsbevis for andre OVS-versioner, NIC'er eller platforme.

I praksis skal enhver offload-angivelse derfor specificere den konkrete datavej: den anvendte softwareversion, drivere, firmware, match-felter og handlinger. En aktiveret kontakt beviser hverken, at relevante datastrømme er udlagt, eller at sikkerheds- og netværkssemantikken fortsat opfyldes uændret. Ved VLAN-filtrering kræver switchdev for eksempel, at hardwaren overholder Bridge-VLAN-reglerne og afviser ikke-godkendte VLAN-ID'er. Offload er dermed den tekniske implementering af eksisterende regler, ikke en omvej uden om dem.

Hvor SmartNIC’er er en fordel inden for hosting

SmartNIC’er er især velegnede på virtualiseringsplatforme med mange VM’er og gentagne videresendelsesbeslutninger. SR-IOV kan tildele en VM en virtuel funktion; i en switchdev-arkitektur afspejler representor-grænseflader fysiske eller virtuelle funktioner i operativsystemet. Regler for trafikken mellem disse porte kan dermed implementeres i hardwaren. Fordelen afhænger dog af de nødvendige VM-funktioner.

Overlay-netværk med klientunderstøttelse og Mikrosegmentering er et yderligere udgangspunkt. Hvis mange kundenetværk gentagne gange anvender VLAN- eller overlay-tildelinger, adgangskontrolregler og lignende flow-beslutninger, kan en passende hardwaredatavej aflaste værts-CPU’erne. Forudsætningen er dog stadig, at antallet af regler, matchfelter og handlinger er tilgængelige i det valgte kort samt i driveren, og at politikens semantik bevares fuldt ud.

For OpenShift Container Platform 4.22 dokumenterer Red Hat hardware-offload for bare-metal-noder med kompatibelt SmartNIC og aktiv SR-IOV Network Operator. Her understøttes kun pod-til-pod-kommunikation samt pod-til-ClusterIP-tjeneste med almindelige pods; DPDK-applikationer er ikke kompatible med denne funktion. Fordelen er desuden begrænset til kommunikationsstrækninger, hvor de involverede noder anvender kompatible SmartNIC'er.

I krypterede værts- eller lokalnetværk kan IPsec-offload overtage delopgaver eller hele processen med indkapsling, udpakning, kryptering og beskyttelse mod replay-angreb. NVIDIA dokumenterer forskellige former for offload i denne sammenhæng, herunder Crypto- og Full-Offload. Dette betyder dog ikke, at de er universelt anvendelige: Understøttelse og ydeevnebegrænsninger afhænger af model, firmware og kryptografisk metode.

En simpel webhostingserver er bevidst valgt som et modeksempel. Hvis den hovedsageligt leverer få, større HTTP-svar og ikke viser nogen CPU-belastning i pakkestien, kan mere specialiseret serverhardware skaber blot yderligere driftsomkostninger. Først bør det afklares, om årsagen til flaskehalsen ligger i applikationen, databasen, lageret eller netværket. SmartNIC’er er ikke en god erstatning for denne diagnose.

Teknisk sammenligning af anvendelsestilfælde

Det er ikke den nominelle porthastighed, der afgør, om et SmartNIC er en god idé, men derimod den konkrete datavej. Det er især en fornuftig løsning, når mange tilbagevendende regler, høje flow-tal eller overlay- og sikkerhedsfunktioner konstant belaster værts-CPU’en. Fordelen er stadig stiafhængig: Et afsnit med højere hastighed hjælper kun de forbindelser, der rent faktisk kører via kompatibel hardware og understøttede regler.

Når det gælder VM-platforme, er SR-IOV En typisk tilgang: Virtuelle funktioner tildeles en VM, mens Representor-grænseflader i operativsystemet afspejler porte for sådanne funktioner. På den måde kan videresendelsesregler mellem virtuelle og fysiske porte i en switchdev-orienteret arkitektur implementeres i hardware. Dette erstatter dog ikke en kontrol af, om den ønskede klientadskillelse og driftsmodellen opretholdes.

Kubernetes er det modsatte af et generelt løfte om hurtigere hastigheder. For den dokumenterede OpenShift 4.22-integration gælder der bestemte understøttede trafikveje, kompatible SmartNIC-noder og krav til arbejdsbelastningen. Hvis en node med offload-funktion kommunikerer med en almindelig node, behandler denne almindelige node sin del i kernen og begrænser dermed den samlede vej. En udrulning bør derfor i første omgang tage højde for en afgrænset node-pool og reelle kommunikationsveje.

I forbindelse med krypterede værts- eller lokalnetværk skal disse begreber anvendes særdeles præcist. Dokumenterede IPsec-varianter spænder, afhængigt af platformen, fra »Crypto-Offload« til »Full Offload« for indkapsling, udpakning, kryptering og beskyttelse mod gentagelse. Dette medfører ingen generel garanti for gennemstrømning: Model, firmware, anvendte algoritmer og produktrelaterede begrænsninger bestemmer, hvilken behandling der faktisk udlægges.

Kontroller kompatibiliteten inden udrulningen

En anskaffelse begynder med en objektiv statusopgørelse, ikke med aktivering af offload-indstillinger. Registrer det nøjagtige kortmodel inklusive PCI-ID, firmwareversion, drivere og kerne. Derudover skal eSwitch-tilstand samt version og konfiguration af Open vSwitch, OVN, hypervisor eller Kubernetes-platformen være kendt, da kortets egenskaber alene ikke er tilstrækkeligt bevis for fuldstændig softwareintegration.

Den nødvendige reguleringssemantik bør foreligge på forhånd som en beskrivelse af datastien: f.eks. VLAN-tildeling, IPv4 eller IPv6, TCP eller UDP, tunneltype, ændring af header, videresendelse eller drop. Den eksperimentelle OVS 4.0.90-dokumentation viser for sin DPDK-konfiguration, at manglende hardwarehandlinger kan føre til delvis offload. Heraf følger, at der for enhver anden version eller platform kun er tale om en opfordring til at undersøge sagen, ikke en garanti for dens funktionsomfang.

Platformmatricer er versionsafhængige kompatibilitetsattester, ingen generelle udsagn om en NIC-familie. OpenShift 4.22 angiver konkrete NIC’er til sin hardware-offload-integration, herunder BlueField-2 i ConnectX-6-NIC-tilstand. Heraf kan man hverken udlede understøttelse af en anden firmware, en anden DPU-tilstand eller en afvigende distribution. Dokumenter derfor hver kombination af hardware, firmware, driver og platformversion separat.

For Linux-switchdev er det desuden afgørende, at hardwaren overholder softwarenetværkets semantik. Ved VLAN-filtrering skal en switch, der udfører offload, for eksempel overholde broens VLAN-regler og afvise ikke-godkendte VLAN-ID'er. Dette krav viser, hvorfor funktionslister og sikkerhedspolitik skal kontrolleres i fællesskab: Acceleration må ikke skabe en afvigende netværkssegmentering.

Afveje SmartNIC mod CPU og software

En SmartNIC er blot én af flere muligheder, når netværksbehandlingen er begrænset. Først er det værd at undersøge, om mere CPU-kapacitet, et passende antal køer, RSS, IRQ-fordeling eller kernel-tuning allerede kan løse flaskehalsen. For en oversigt over SoftIRQ'er, køer og interrupt-fordeling henvises til artiklen om CPU- og netværksgennemstrømning i hosting Yderligere grundlæggende principper. Uden dokumentation for en netværksflaskehals forbliver yderligere specialhardware en antagelse.

DPDK og AF_XDP kan forkorte softwarevejene på værts-CPU’er, men kræver hver især en egen arkitektur- og CPU-planlægning. Udsagnet om kontinuerlig polling kan ikke generelt overføres til begge tilgange: I OVS-DPDK-dokumentationen for den beskrevne konfiguration poller en tråd løbende DPDK-enheder og optager derved en CPU-kerne fuldstændigt. NUMA-tildeling, kerneisolering og den konkrete OVS- og DPDK-version er derfor stadig en del af udformningen.

Selv et klassisk server-NIC kan levere tilstrækkelig aflastning til kontrolsummer, segmentering eller enkelte tunnelfunktioner. Dette valg er passende, hvis der ikke er behov for omfattende virtuelle switch-regler, klientadskillelse eller sikkerhedsdataveje i hardware. SmartNIC'er bliver især en fornuftig løsning, når de krævede funktioner går ud over sådanne grundlæggende funktioner og er tilbagevendende på lang sigt.

Kapacitetsbegrebet er enkelt, men vigtigt: Hvis CPU-kerner på en host udnyttes fuldt ud til pakkebehandling, og en repræsentativ del af disse pakker kan aflastes fuldstændigt, kan der muligvis opstå CPU-reserver. Denne ledige kapacitet tæller dog kun som brugbar kapacitet, hvis ikke applikationen, hukommelsen, lagringsmediet eller en software-fallback udgør den næste flaskehals. Den er ikke en direkte afledning af linkhastighed eller kortpris.

Sammenlign derfor alternativerne ud fra den samme belastningsprofil: pakkestørrelser, forbindelseshastighed, antal regler, tunneler, kryptering og forventet spidsbelastning. Her skal du skelne mellem CPU-andele i datavejen og applikationsarbejdet og undersøge, hvilke flows der rent faktisk kører i hardware. En CPU-flaskehals Brug af firewall, overlay eller virtuel videresendelse er en vægtig grund til vurdering; en generelt høj systembelastning er det ikke.

Gøre offload synlig under drift

Efter implementeringen er det ikke nok blot at se en offload-indstilling som aktiv. Et pålideligt driftsbevis forbinder Flow-status med kortets tællere, drop- og fejlprocenter, CPU-udnyttelse samt en belastningsprofil, der ligner den senere trafik. Først samlet set viser disse data, om relevante flows rent faktisk behandles i hardwaren, eller om værten fortsat bærer den afgørende del af datavejen.

For at kunne foretage en sammenligning bør operatører tage højde for de samme pakkestørrelser, protokoller, antal forbindelser og retningslinjer både før og efter en ændring. Ren gigabit-gennemstrømning kan let skjule en flaskehals ved små pakker eller mange parallelle flows. Lige så vigtige er latenstid, CPU-tid pr. involveret vært, Softirq-belastning, kø-tab og fordelingen af trafikken på noder og porte.

Følgende kommandoer ændrer ikke nogen konfiguration. Den første forespørgsel tager højde for både PCI-enheder, der vises som Ethernet-controllere, og dem, der vises som netværkscontrollere. ethtool -k viser de tilbudte eller på Netdev aktiverede offload-funktioner, men dokumenterer hverken eSwitch-, SmartNIC- eller flow-offload fuldt ud. Også de øvrige udskrifter er inventar- og konfigurationsdata og udgør ikke bevis for, at en bestemt regel er fuldt ud udlagt.

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

I forbindelse med Open vSwitch skal der især skelnes mellem konfigureret hardwareacceleration og det observerede resultat. OVS 4.0.90-udviklingsdokumentationen betegner dens flow-hardware-offload som eksperimentel og beskriver fuldstændig eller delvis offload kun for denne OVS-med-DPDK-konfiguration. I produktionsdrift skal flowoplysninger og hardwaretællere derfor evalueres sammen med værtssoftwaretællerne.

Overvågning kræver desuden en tidsreference. En kort test kan bekræfte regler, mens en profil, der ligger tæt på produktionsforholdene, senere kan udløse tabelkapaciteter, sjældne logstier eller rekonfigurationer. Det er derfor fornuftigt at registrere normalværdier og afvigelser for hver kortmodel, firmware, driver og platformversion. På den måde kan man efter opdateringer spore, om Datasti eller blot har ændret den observerede belastning.

I OpenShift 4.22-integrationen skal visningen desuden dække hele kommunikationsvejen. Den dokumenterede understøttelse af hardware-offload gælder kun for bestemte arbejdsbelastninger og kommunikationstyper. Hvis en kompatibel node kommunikerer med en node uden et passende SmartNIC, behandler denne sin del i kernen; målepunkter på kun én vært kan derfor give et ufuldstændigt billede af end-to-end-stien.

Typiske fejlmønstre og tilbagefaldsforløb

Den mest almindelige fejl er ufuldstændig overførsel. En strøm kan genkendes i hardwaren på baggrund af enkle kendetegn, men skal dog helt eller delvist vende tilbage til softwareforløbet, hvis der er tale om en handling, der ikke understøttes. Den eksperimentelle OVS 4.0.90-dokumentation beskriver denne delvise offload for sin DPDK-konfiguration. Dette er ikke en generel udtalelse om enhver OVS-installation, men illustrerer det nødvendige kontrolpunkt ved enhver konkret integration.

Diagnosen starter langs den faktiske rute: indgangsport, virtuel funktion eller repræsentor, switch-regel, tunnel- eller policy-behandling og målarbejdsbelastning. Hvis tællerne før og efter et trin ikke stemmer overens på en plausibel måde, er det en anledning til at kontrollere match, handlinger og fallback. En aktiveret funktion erstatter ikke denne tilknytning, da kortets kapacitet ikke omfatter alle ønskede regelkombinationer.

Heterogene klynger gør sammenligningen vanskeligere. I OpenShift 4.22 finder hardware-offload kun sted, hvis de involverede pods og tjenester er tildelt noder med kompatible SmartNIC’er. Hvis en sådan sti støder på en almindelig node, foregår behandlingen heraf i kernen, hvilket begrænser den samlede kommunikation. En enkelt accelereret node optager derfor ikke en fuldt accelereret klyngesti.

Også en forkert pod- eller netværkskonfiguration kan forhindre den forventede effekt. Red Hat gør udtrykkeligt opmærksom på, at aktiveret hardware-offload uden tilsvarende konfigurerede pods kan forringe pod-gennemstrømningen i forbindelse med OpenShift 4.22-funktionen. Operatører bør derfor ikke forsøge at afhjælpe en afvigelse ved at aktivere yderligere indstillinger, men i stedet først kontrollere arbejdsbelastningstilkoblingen, netværksmodus og de faktisk opnåede flows.

Reguleringskapacitet og firmwareafvigelser hører til samme fejlklasse: Ved mange klienter, kortvarige forbindelser eller dynamiske politikker kan den relevante flowmængde vokse anderledes end forventet. En versionsafhængig driver eller afvigende firmware kan desuden tilbyde funktioner på en anden måde end den planlagte platformskombination. Derfor skal inventardata og tællere altid arkiveres sammen med den konkrete regelbestand.

En kontrolleret tilbageførselsvej sikrer, at driften kan diagnosticeres. Det betyder, at softwarebehandlingen bevares som det tilsigtede alternativ, og at ændringer implementeres trinvist med sammenligningsvinduer og klare afbrydelseskriterier. Software-fallback er i denne sammenhæng ikke nødvendigvis en fejl, men kan være den forventede håndtering af handlinger, som den valgte hardwarevej ikke understøtter fuldt ud.

Træffe realistiske beslutninger om indkøb og drift

En indkøbsbeslutning tager udgangspunkt i arbejdsbyrden, ikke i portens hastighed eller produktbetegnelsen. Specialiseret hardware er en fornuftig løsning, når det kan påvises, at gentagen pakkebehandling optager CPU-tid: for eksempel ved mange virtuelle netværk, faste sæt af politikker, overlay-trafik eller en defineret krypteringsvej. Mangler dette bevis, kan CPU- og kø-tuning eller et klassisk netværkskort med passende basis-offloads være den enklere løsning.

Dernæst skal Kompatibilitetsbevis for den konkrete kombination: kortmodel og driftsmodus, firmware, driver, kerne, virtuel switch eller CNI samt de nødvendige match- og action-funktioner. Programmerbare infrastrukturacceleratorer kan f.eks. tilbyde flow-offload til tilstands- eller sessionsrelaterede funktioner; det betyder dog ikke, at alle SmartNIC'er eller alle platforme tilbyder den samme funktion.

Den forventede aflastning af CPU’en er først tilgængelig som kapacitet, hvis pakkebehandlingen var den faktiske flaskehals, og de frigjorte kerner kan udnyttes fornuftigt. Hvis de f.eks. planlægges til databaser, web-workere eller som reserver, er det et arkitektonisk valg og ikke en automatisk ydeevneforbedring. Det øvrige serverudstyr er derfor stadig afgørende; CPU, arbejdshukommelse og lagerplads skal passe til applikationen lige så godt som netværket. Artiklen om giver mere kontekst til den samlede vurdering præstationsrelevant serverhardware inden for webhosting.

Ved IPsec er kontrollen særligt konkret: De dokumenterede offload-varianter spænder fra krypto-offload til fuldstændig udlicitering af indkapsling, udpakning, kryptering og replay-beskyttelse. Hvilken variant der kan anvendes, afhænger af model, generation, firmware og kryptokonfiguration. Produktrelaterede bemærkninger kan desuden indeholde begrænsninger for bestemte generationer eller båndbredder; disse skal indgå i godkendelseskontrollen inden implementeringen.

En DPU udvider beslutningen med sit eget administrations- og tillidsområde. I BlueField-DPU-tilstand styrer det integrerede Arm-system NIC-ressourcer og datavejen, i stedet for at kortet blot fungerer som en host-adapter. Dette kan adskille infrastrukturopgaver fra værten, men kræver et robust koncept for adgangsrettigheder, images, opdateringer, overvågning og gendannelse.

Økonomisk set er det derfor ikke kun kortprisen, der tæller. På den anden side skal man tage højde for den host-CPU-kapacitet, der spares eller undgås, platformens forventede levetid samt ekstra omkostninger til kvalificering, reservedele, firmwarevedligeholdelse og genopretning efter hændelser. Et SmartNIC er en fornuftig løsning, hvis denne beregning bygger på en reproducerbar datavej og en livscyklus, der kan styres på lang sigt – ikke fordi specialiseret hardware generelt forekommer hurtigere.