SmartNIC:er inom webbhotell: Att korrekt utvärdera nätverksacceleration

Att placera SmartNIC:er på rätt sätt inom webbhotellbranschen

Begreppet SmartNIC är inte ett enhetligt standardiserat produktnamn. Vid planeringen av värdtjänster är det därför inte etiketten som är avgörande, utan den påvisbara funktionen i datavägen: Vilka paket, regler och tunnlar kan kortet hantera, vilka uppgifter åligger värden och vilken programvara styr funktionerna? En hög porthastighet ger inget svar på dessa frågor.

Ett klassiskt nätverkskort tillhandahåller främst Ethernet-anslutningen och stöder vanliga grundläggande avlastningsfunktioner, till exempel kontrollsummor eller segmentering. Ett SmartNIC utökar denna ram med specialiserade eller programmerbara datavägsfunktioner. Detta kan omfatta flödesregler, virtuella switchfunktioner, SR-IOV, tunnelhantering eller kryptografiska deluppgifter. Om dessa funktioner kan användas avgörs dock gemensamt av modell, firmware, drivrutiner och plattformsintegration.

En DPU är i regel mer avancerat utformat: Förutom nätverks-ASIC:en har den egna beräkningsresurser och kan driva en separat infrastrukturdataväg. NVIDIA beskriver för BlueField ett DPU-läge, där det integrerade Arm-systemet styr NIC-resurser och dataväg, samt ett NIC-läge, där kortet fungerar som en adapter gentemot den externa värden. Detta skapar, beroende på driftsläge, även en egen förvaltnings- och förtroendezon.

Klassificeringen har praktiska konsekvenser för inköp och drift. Ett kort med egen beräkningslogik är inte automatiskt det bästa valet om endast enkla grundläggande avlastningar behövs. Omvänt kan en utlagd infrastrukturväg vara lämplig för kundseparering eller säkerhetsfunktioner, men kräver då firmwareunderhåll, åtkomstkoncept, övervakning och återställningsprocesser för ytterligare komponenter.

Inte ens en 100-GbE-port eller en snabbare port medför någon prestandaförbättring för brandväggsregler, överlagringar eller kryptering. Avgörande faktorer är paketstorlek, antalet parallella flöden, regelomfånget och frågan om de nödvändiga åtgärderna faktiskt kan implementeras i hårdvaran. Först när det kan påvisas att server-CPU:n utgör en begränsning i nätverkets dataväg blir en funktionslista en möjlig kapacitetsvinst.

Hur hårdvaruavlastning förändrar datavägen

Utan ytterligare avlastning når ett paket först det fysiska nätverkskortet och bearbetas därefter av värddatorn. Beroende på arkitekturen passerar det genom kärnans nätverksstack, brandvägg, brygga eller virtuell switch, routning och, i förekommande fall, kapsling för ett överlägg. Först därefter når det en virtuell maskin, en container eller en annan fysisk port. Varje steg kan orsaka CPU-tid och köer.

Denna väg blir särskilt relevant vid många små paket, ett stort antal kortvariga anslutningar eller omfattande klientpolicyer. Det är inte bara den överförda datamängden som belastar värddatorn, utan även den upprepade bearbetningen av enskilda paket och flöden. Därför är nätverksacceleration inte en allmän egenskap hos en server, utan en målinriktad avlastning av en konkret identifierad dataväg.

På Hårdvaruavlastning kan styrkomponenter överföra tillåtna vidarebefordrings- och filterregler till en hårdvarubaserad dataväg. Linux-switchdev-modellen beskriver i detta sammanhang flyttningen av vidarebefordringsdatavägen från kärnan till en switch. Vilka regler som faktiskt överförs beror på det specifika nätverkskortet, dess drivrutin och den överliggande nätverksintegrationen.

I OVS-dokumentationen för utvecklingsgrenen 4.0.90 beskrivs ett separat avsnitt om Flow Hardware Offload uttryckligen som experimentellt. Just för denna OVS-konfiguration med DPDK skiljer dokumentationen mellan fullständig avlastning av matchningar och åtgärder samt partiell avlastning, där endast matchningar avlastas. Denna beskrivning utgör inte ett stabilt, allmänt giltigt kompatibilitetsintyg för andra OVS-versioner, nätverkskort eller plattformar.

I praktiken måste därför varje offload-angivelse specificera den konkreta datavägen: vilken programvaruversion som används, drivrutiner, firmware, matchningsfält och åtgärder. En aktiverad knapp bevisar varken att relevanta flöden har avlastats eller att säkerhets- och nätverkssemantiken uppfylls oförändrat. Vid VLAN-filtrering kräver exempelvis switchdev att hårdvaran följer Bridge-VLAN-reglerna och avvisar otillåtna VLAN-ID:n. Offload är alltså den tekniska implementeringen av befintliga regler, inte en genväg för att kringgå dem.

I vilka sammanhang är SmartNIC:er lämpliga inom webbhotellbranschen?

SmartNIC:er är framför allt lämpliga på virtualiseringsplattformar med många virtuella maskiner (VM) och återkommande vidarebefordringsbeslut. SR-IOV kan tilldela en virtuell maskin en virtuell funktion; i en switchdev-arkitektur avbildar representatorgränssnitt fysiska eller virtuella funktioner i operativsystemet. Regler för trafiken mellan dessa portar kan därmed implementeras i hårdvaran. Nyttan beror dock på vilka VM-funktioner som krävs.

Klientkompatibla överlagringsnätverk och Mikrosegmentering är ytterligare en utgångspunkt. Om många kundnätverk upprepade gånger tillämpar VLAN- eller overlay-tilldelningar, åtkomstkontrollregler och liknande flödesbeslut kan en lämplig hårdvarudataväg avlasta värd-CPU:erna. En förutsättning är fortfarande att antalet regler, matchningsfält och åtgärder finns tillgängliga i det valda kortet och dess drivrutin, samt att policy-semantiken bevaras fullständigt.

För OpenShift Container Platform 4.22 dokumenterar Red Hat hårdvaruavlastning för bare-metal-noder med kompatibla SmartNIC-kort och en aktiv SR-IOV Network Operator. Där stöds endast pod-till-pod-kommunikation samt pod-till-ClusterIP-tjänst med vanliga podar; DPDK-applikationer är inte kompatibla med denna funktion. Fördelen begränsas dessutom till kommunikationssegment där de deltagande noderna använder kompatibla SmartNIC-kort.

I krypterade värd- eller lokala nätverk kan IPsec-offload ta hand om deluppgifter eller hela processen med inkapsling, avkapsling, kryptering och skydd mot återuppspelning. NVIDIA dokumenterar olika typer av avlastning för detta ändamål, däribland kryptoavlastning och fullständig avlastning. Detta innebär dock inte att de är universellt lämpliga: stöd och prestandagränser beror på modell, firmware och krypteringsmetod.

En enkel webbhotellserver är medvetet valt som ett motexempel. Om den huvudsakligen levererar ett fåtal större HTTP-svar och inte visar någon CPU-belastning i paketvägen, kan mer specialiserad serverhårdvara skapar bara ytterligare driftskostnader. Först bör man klargöra om det är applikationen, databasen, lagringsutrymmet eller nätverket som är orsaken till flaskhalsen. SmartNIC:ar är inte ett lönsamt alternativ som ersättning för denna diagnostik.

Jämföra användningsfall ur teknisk synvinkel

Det är inte den nominella porthastigheten som avgör om en SmartNIC är lämplig, utan den faktiska datavägen. Den är särskilt lämplig när många återkommande regler, höga flödesvärden eller överlagrings- och säkerhetsfunktioner kontinuerligt tar upp tid på värd-CPU:n. Fördelen kvarstår vägberoende: En snabbare sektion hjälper endast de anslutningar som faktiskt körs via kompatibel hårdvara och regler som stöds.

När det gäller VM-plattformar är SR-IOV Ett typiskt tillvägagångssätt: Virtuella funktioner tilldelas en virtuell maskin (VM), medan Representor-gränssnitt i operativsystemet avbildar portarna för dessa funktioner. På så sätt kan vidarebefordringsregler mellan virtuella och fysiska portar i en switchdev-orienterad arkitektur implementeras i hårdvaran. Detta ersätter dock inte en kontroll av om den önskade klientseparationen och driftsmodellen bibehålls.

Kubernetes är motsatsen till ett generellt löfte om ökad hastighet. För den dokumenterade OpenShift 4.22-integrationen gäller vissa stödda trafikvägar, kompatibla SmartNIC-noder och krav på arbetsbelastning. Om en nod med avlastningsfunktion kommunicerar med en vanlig nod, bearbetar den vanliga noden sin del i kärnan och begränsar därmed den totala vägen. En utrullning bör därför inledningsvis beakta en avgränsad nodpool och faktiska kommunikationsvägar.

När det gäller krypterade värd- eller lokala nätverk måste begreppen användas med särskild precision. Dokumenterade IPsec-varianter sträcker sig, beroende på plattform, från krypteringsavlastning till fullständig avlastning för inkapsling, avkapsling, kryptering och skydd mot återuppspelning. Detta innebär dock ingen allmän garanti för genomströmning: modell, firmware, använda algoritmer och produktrelaterade begränsningar avgör vilken bearbetning som faktiskt avlastas.

Kontrollera kompatibiliteten före lanseringen

En anskaffning inleds med en objektiv inventering, inte med att aktivera avlastningsalternativ. Registrera den exakta kortmodellen inklusive PCI-ID, firmwareversion, drivrutiner och kärna. Dessutom måste eSwitch-läget samt version och konfiguration av Open vSwitch, OVN, hypervisor eller Kubernetes-plattformen vara kända, eftersom kortets kapacitet i sig inte garanterar fullständig programvaruintegration.

Den nödvändiga regelsemantiken bör finnas tillgänglig i förväg i form av en beskrivning av datavägen: till exempel VLAN-tilldelning, IPv4 eller IPv6, TCP eller UDP, tunneltyp, ändring av rubrik, vidarebefordran eller bortkastning. Den experimentella dokumentationen för OVS 4.0.90 visar för sin DPDK-konfiguration att avsaknande hårdvaruåtgärder kan leda till partiell avlastning. Av detta följer att varje annan version eller plattform endast utgör ett testuppdrag, utan någon garanti för dess funktionsomfång.

Plattformmatriser är versionsspecifika kompatibilitetsintyg, inga allmänna uttalanden om en NIC-familj. OpenShift 4.22 anger specifika NIC:er för sin hårdvaruavlastningsintegration, däribland BlueField-2 i ConnectX-6-NIC-läge. Därifrån kan man varken dra slutsatsen att annan firmware, ett annat DPU-läge eller en avvikande distribution stöds. Dokumentera därför varje kombination av hårdvara, firmware, drivrutin och plattformsversion separat.

För Linux-switchdev är det dessutom avgörande att hårdvaran respekterar det virtuella nätverkets semantik. Vid VLAN-filtrering måste en switch som avlastar trafiken till exempel följa bryggans VLAN-regler och avvisa otillåtna VLAN-ID:n. Detta krav visar varför funktionslistor och säkerhetspolicyer måste granskas tillsammans: avlastningen får inte skapa en avvikande nätverkssegmentering.

Jämföra SmartNIC med CPU och programvara

En SmartNIC är bara ett av flera alternativ när nätverksbearbetningen är begränsad. Först bör man undersöka om mer CPU-kapacitet, ett lämpligt antal köer, RSS, IRQ-fördelning eller kärnoptimering redan kan lösa flaskhalsen. För en översikt över SoftIRQ:er, köer och interruptfördelning hänvisar vi till artikeln om CPU- och nätverksgenomströmning inom webbhotell Ytterligare grundläggande principer. Utan bevis på en nätverksflaskhals förblir ytterligare specialhårdvara en antagande.

DPDK och AF_XDP kan förkorta mjukvaruvägarna på värd-CPU:er, men kräver var för sig en egen arkitektur- och CPU-planering. Uttalandet om kontinuerlig avfrågning kan inte generellt tillämpas på båda metoderna: I OVS-DPDK-dokumentationen för den beskrivna konfigurationen pollar en tråd DPDK-enheter kontinuerligt och upptar därvid en CPU-kärna fullständigt. NUMA-tilldelning, kärnisolering och den specifika OVS- och DPDK-versionen förblir därför en del av utformningen.

Även ett klassiskt server-NIC kan tillhandahålla tillräcklig avlastning för kontrollsummor, segmentering eller enskilda tunnelfunktioner. Detta val är lämpligt om det inte krävs omfattande virtuella switchregler, kundseparering eller säkerhetsdatavägar i hårdvaran. SmartNIC:er blir framför allt ett rimligt alternativ när de efterfrågade funktionerna går utöver sådana grundläggande funktioner och är återkommande på lång sikt.

Kapacitetsbegreppet är enkelt men viktigt: Om CPU-kärnor på en värd utnyttjas till fullo genom paketbearbetning och en representativ del av dessa paket kan avlastas helt, kan det uppstå ledig CPU-kapacitet. Detta utrymme räknas dock endast som användbar kapacitet om inte applikationen, minnet, lagringsutrymmet eller en programvarufallback utgör nästa flaskhals. Det är inte en direkt följd av länkhastigheten eller kortpriset.

Jämför därför alternativen utifrån samma belastningsprofil: paketstorlekar, överföringshastighet, antal regler, tunnlar, kryptering och förväntad toppbelastning. Separera vid detta tillfälle CPU-andelen i datavägen från applikationsarbetet och kontrollera vilka flöden som verkligen körs i hårdvaran. En CPU-flaskhals Brandvägg, overlay eller virtuell vidarebefordran utgör en tillräcklig anledning till utvärdering; en generellt hög systembelastning gör det däremot inte.

Synliggöra avlastning under drift

Efter införandet räcker det inte att bara se en avlastningsfunktion som aktiv. Ett tillförlitligt driftsbevis kopplar samman Flödesstatus med kortets räknare, drop- och felfrekvenser, CPU-utnyttjande samt en belastningsprofil som liknar den framtida trafiken. Det är först när dessa data sammanställs som det framgår om relevanta flöden faktiskt bearbetas i hårdvaran eller om värddatorn fortfarande står för den avgörande delen av datavägen.

För att kunna göra en jämförelse bör operatörerna beakta samma paketstorlekar, protokoll, antal anslutningar och riktlinjer både före och efter en förändring. Ren gigabit-genomströmning kan lätt dölja en flaskhals vid små paket eller många parallella flöden. Lika viktigt är latens, CPU-tid per involverad värd, Softirq-belastning, köbortfall och fördelningen av trafiken på noder och portar.

Följande kommandon ändrar inte någon konfiguration. Den första frågan tar hänsyn till både PCI-enheter som visas som Ethernet-kontroller och sådana som visas som nätverkskontroller. ethtool -k visar tillgängliga eller på Netdev aktiverade avlastningsfunktioner, men ger ingen fullständig bekräftelse på varken eSwitch-, SmartNIC- eller flödesavlastning. Även de övriga utdatauppgifterna är inventerings- och konfigurationsdata, inte bevis på att en viss regel är helt avlastad.

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

När det gäller Open vSwitch är det särskilt viktigt att skilja mellan konfigurerad hårdvaruacceleration och det observerade resultatet. Utvecklingsdokumentationen för OVS 4.0.90 betecknar dess flödesavlastning till hårdvara som experimentell och beskriver fullständig eller partiell avlastning endast för denna OVS-konfiguration med DPDK. För produktionsdrift måste därför flödesinformation och hårdvaruräknare utvärderas tillsammans med värdprogramvarans räknare.

Övervakning kräver dessutom en tidsreferens. Ett kort test kan bekräfta regler, medan en profil som ligger nära produktionsmiljön senare kan utlösa tabellkapaciteter, sällsynta loggvägar eller omkonfigurationer. Det är därför lämpligt att dokumentera normalvärden och avvikelser per kortmodell, firmware, drivrutin och plattformsversion. På så sätt går det att efter uppdateringar spåra om Data sökväg eller om det endast är den observerade belastningen som har förändrats.

I OpenShift 4.22-integrationen måste översikten dessutom täcka hela kommunikationsvägen. Det dokumenterade stödet för hårdvaruavlastning gäller endast för vissa arbetsbelastningar och kommunikationstyper. Om en kompatibel nod kommunicerar med en nod utan lämpligt SmartNIC, bearbetar den senare sin del i kärnan; mätpunkter på endast en värd kan då ge en ofullständig bild av end-to-end-vägen.

Typiska felmönster och återfallsvägar

Det vanligaste felet är ofullständig avlastning. Ett flöde kan identifieras i hårdvaran utifrån enkla egenskaper, men måste för en åtgärd som inte stöds återgå helt eller delvis till mjukvaruvägen. Den experimentella dokumentationen för OVS 4.0.90 beskriver denna partiella avlastning för sin DPDK-konfiguration. Detta är inte ett generellt uttalande om varje OVS-installation, men belyser den nödvändiga kontrollpunkten vid varje konkret integration.

Diagnosen inleds längs den faktiska vägen: ingångsport, virtuell funktion eller representor, switch-regel, tunnel- respektive policybearbetning och mål-workload. Om räknarna före och efter ett steg inte stämmer överens på ett rimligt sätt är det anledning att kontrollera matchningar, åtgärder och fallback. En aktiverad funktion ersätter inte denna tilldelning, eftersom kortets kapacitet inte omfattar alla önskade regelkombinationer.

Heterogena kluster försvårar jämförelsen. I OpenShift 4.22 sker hårdvaruavlastning endast om de berörda podarna och tjänsterna är tilldelade noder med kompatibla SmartNIC-kort. Om en sådan väg stöter på en vanlig nod sker bearbetningen i kärnan, vilket begränsar den totala kommunikationen. En enskild accelererad nod upptar därför inte en helt accelererad klusterväg.

Även en felaktig pod- eller nätverkskonfiguration kan förhindra den förväntade effekten. Red Hat påpekar uttryckligen för OpenShift 4.22-funktionen att aktiverad hårdvaruavlastning utan korrekt konfigurerade podar kan försämra podarnas genomströmning. Operatörer bör därför inte försöka åtgärda avvikelser genom att aktivera ytterligare alternativ, utan först kontrollera arbetsbelastningsanslutningen, nätverksläget och de faktiska flödena.

Regleringskapacitet och avvikelser i firmware hör till samma felklass: Vid många klienter, kortvariga anslutningar eller dynamiska policyer kan den relevanta flödesmängden öka på ett annat sätt än förväntat. En versionsbunden drivrutin eller avvikande firmware kan dessutom erbjuda funktioner på ett annat sätt än den planerade plattformskombinationen. Därför måste inventeringsdata och räknare alltid arkiveras tillsammans med den konkreta regeluppsättningen.

En kontrollerad återfallsväg gör det möjligt att diagnostisera driften. Det innebär att mjukvarubearbetningen bibehålls som ett avsett alternativ och att ändringar införs stegvis, med jämförelsefönster och tydliga avbrottskriterier. Programvarufallbacken är i detta sammanhang inte automatiskt en defekt, utan kan vara den förväntade hanteringen av åtgärder som den valda hårdvaruvägen inte stöder fullt ut.

Fatta realistiska beslut om inköp och drift

Ett inköpsbeslut utgår från arbetsbelastningen, inte från porthastighet eller produktbeteckning. Specialiserad hårdvara är ett rimligt val där återkommande paketbehandling bevisligen tar upp CPU-tid: till exempel ett stort antal virtuella nätverk, stabila policyuppsättningar, overlay-trafik eller en definierad krypteringsväg. Om detta inte kan påvisas kan CPU- och köoptimering eller ett klassiskt nätverkskort med lämpliga grundläggande avlastningsfunktioner vara den enklare lösningen.

Därefter måste Kompatibilitetsintyg för den specifika kombinationen: kortmodell och driftsläge, firmware, drivrutiner, kärna, virtuell switch eller CNI samt de nödvändiga matchnings- och åtgärdsfunktionerna. Programmerbara infrastrukturacceleratorer kan till exempel tillhandahålla flödesavlastning för tillstånds- eller sessionsrelaterade funktioner; detta innebär dock inte att varje SmartNIC eller varje plattform tillhandahåller samma funktion.

Den förväntade avlastningen av processorn blir först tillgänglig som kapacitet när paketbearbetningen utgjorde den faktiska flaskhalsen och de frigjorda kärnorna kan utnyttjas på ett meningsfullt sätt. Om de till exempel planeras in för databaser, webbarbetare eller som reserver är det ett arkitekturval, inte en automatisk prestandaförbättring. Den övriga serverutrustningen förblir därför avgörande; CPU, arbetsminne och lagringsutrymme måste passa applikationen lika väl som nätverket. Mer information om den övergripande avvägningen finns i artikeln om prestandakritisk serverhårdvara inom webbhotell.

När det gäller IPsec är kontrollen särskilt konkret: Dokumenterade varianter av avlastning sträcker sig från kryptoavlastning till fullständig avlastning av kapsling, avkapsling, kryptering och skydd mot återuppspelning. Vilken variant som kan användas beror på modell, generation, firmware och kryptokonfiguration. Produktrelaterade anvisningar kan dessutom innehålla begränsningar för vissa generationer eller bandbredder; dessa ska beaktas i godkännandekontrollen före driftsättningen.

En DPU utökar beslutet med ett eget administrations- och förtroendeområde. I BlueField-DPU-läget styr det integrerade Arm-systemet NIC-resurser och datavägen, istället för att kortet enbart fungerar som en värdadapter. Detta kan separera infrastrukturuppgifter från värden, men kräver en robust strategi för åtkomsträttigheter, avbildningar, uppdateringar, övervakning och återställning.

Ur ekonomisk synvinkel är det därför inte bara kortpriset som räknas. Mot detta står den besparade eller undvikna kapaciteten hos värd-CPU:n, plattformens förväntade livslängd samt ytterligare kostnader för kvalificering, reservdelar, firmwareunderhåll och återställning efter incidenter. En SmartNIC är ett klokt val om denna beräkning bygger på en reproducerbar dataväg och en livscykel som går att kontrollera på lång sikt – inte för att specialiserad hårdvara i princip verkar vara snabbare.