SmartNIC nell'hosting: valutare correttamente l'accelerazione di rete

Come inquadrare correttamente gli SmartNIC nel settore dell'hosting

Il termine SmartNIC non è un nome di prodotto standardizzato in modo uniforme. Per la progettazione nell’ambito dell’hosting, quindi, non è l’etichetta a essere determinante, bensì la funzione dimostrabile nel percorso dei dati: quali pacchetti, regole e tunnel è in grado di elaborare la scheda, quali compiti rimangono a carico dell’host e quale software controlla le funzioni? Un’elevata velocità di porta non risponde a queste domande.

Una scheda di rete classica fornisce principalmente la connessione Ethernet e supporta le operazioni di offload di base più diffuse, come i checksum o la segmentazione. Una SmartNIC amplia questo quadro con funzioni specializzate o programmabili relative al percorso dei dati. Tra queste possono figurare regole di flusso, funzioni di commutazione virtuale, SR-IOV, elaborazione dei tunnel o operazioni crittografiche. La disponibilità di tali funzioni dipende tuttavia dal modello, dal firmware, dai driver e dall’integrazione con la piattaforma.

A DPU ha solitamente un’architettura più articolata: oltre all’ASIC di rete, dispone di risorse di calcolo proprie ed è in grado di gestire un percorso dati infrastrutturale separato. NVIDIA descrive per BlueField una modalità DPU, in cui il sistema ARM integrato controlla le risorse della scheda di rete (NIC) e il percorso dati, nonché una modalità NIC, in cui la scheda si comporta come un adattatore nei confronti dell’host esterno. A seconda della modalità operativa, si crea così anche un proprio ambito di gestione e di fiducia.

Questa classificazione ha conseguenze pratiche per l’approvvigionamento e la gestione. Una scheda con una propria logica di calcolo non è automaticamente la scelta migliore se sono necessari solo semplici offload di base. Al contrario, un percorso infrastrutturale esternalizzato può essere utile per la separazione dei clienti o per le funzioni di sicurezza, ma richiede allora la manutenzione del firmware, strategie di accesso, monitoraggio e processi di ripristino per componenti aggiuntivi.

Anche una porta da 100 GbE o più veloce non garantisce un’accelerazione delle regole del firewall, degli overlay o della crittografia. Fattori determinanti sono la dimensione dei pacchetti, il numero di flussi paralleli, l’estensione delle regole e la possibilità che le azioni richieste siano effettivamente implementabili a livello hardware. Solo quando è dimostrabile che la CPU del server costituisce un collo di bottiglia nel percorso dei dati di rete, un elenco di funzionalità si traduce in un potenziale aumento della capacità.

Come l'offload hardware modifica il percorso dei dati

Senza un ulteriore offload, un pacchetto raggiunge inizialmente la scheda di rete fisica (NIC) e viene poi elaborato dall’host. A seconda dell’architettura, il pacchetto attraversa lo stack di rete del kernel, il firewall, il bridge o lo switch virtuale, il routing e, se necessario, l’incapsulamento per un overlay. Solo successivamente raggiunge una VM, un container o un’altra porta fisica. Ogni fase può comportare un consumo di tempo CPU e la formazione di code.

Questo percorso assume particolare rilevanza in presenza di molti pacchetti di piccole dimensioni, numerose connessioni di breve durata o politiche client-server di ampia portata. A gravare sull’host non è solo la quantità di dati trasmessi, ma anche l’elaborazione ripetuta dei singoli pacchetti e flussi. Pertanto, è accelerazione della rete non una caratteristica generale di un server, bensì un alleggerimento mirato di un percorso di dati specificamente identificato.

All'indirizzo Offload hardware I componenti di controllo possono trasferire le regole di inoltro e di filtraggio consentite in un percorso dati hardware. Il modello Linux switchdev descrive a tal fine lo spostamento del percorso di inoltro dei dati dal kernel a un dispositivo switch. Quali regole vengano effettivamente applicate dipende dalla scheda specifica, dal suo driver e dall’integrazione di rete a livello superiore.

La documentazione OVS nel ramo di sviluppo 4.0.90 descrive espressamente come sperimentale una sezione dedicata all’offload hardware dei flussi. Proprio per questa configurazione OVS con DPDK, la documentazione distingue tra l'offload completo di match e azioni e l'offload parziale, in cui vengono trasferiti solo i match. Questa descrizione non costituisce una prova di compatibilità stabile e universalmente valida per altre versioni di OVS, schede di rete (NIC) o piattaforme.

Nella pratica, quindi, ogni dichiarazione relativa all’offload deve specificare il percorso concreto dei dati: versione del software utilizzata, driver, firmware, campi di corrispondenza e azioni. Un interruttore attivato non dimostra né che i flussi rilevanti siano stati trasferiti, né che i requisiti di sicurezza e la semantica di rete siano soddisfatti senza modifiche. Nel caso del filtraggio VLAN, ad esempio, switchdev richiede che l’hardware rispetti le regole delle VLAN bridge e scarti gli ID VLAN non autorizzati. L’offload rappresenta quindi l’attuazione tecnica delle regole esistenti, non una scappatoia per aggirarle.

In quali casi è opportuno utilizzare le SmartNIC nell'hosting

Le SmartNIC risultano particolarmente utili soprattutto su piattaforme di virtualizzazione con numerose macchine virtuali (VM) e decisioni di inoltro ricorrenti. SR-IOV può assegnare una funzione virtuale a una VM; in un’architettura switchdev, le interfacce Representor mappano le funzioni fisiche o virtuali nel sistema operativo. In questo modo, le regole relative al traffico tra queste porte possono essere implementate a livello hardware. Il vantaggio dipende tuttavia dalle funzioni richieste dalla VM.

Reti overlay multi-cliente e Microsegmentazione rappresentano un ulteriore punto di partenza. Se molte reti dei clienti applicano ripetutamente assegnazioni VLAN o overlay, regole di controllo degli accessi e decisioni simili relative ai flussi, un percorso dati hardware adeguato può alleggerire il carico sulle CPU degli host. Rimane comunque necessario che il numero di regole, i campi di corrispondenza e le azioni siano disponibili nella scheda selezionata, compreso il driver, e che la semantica delle policy venga mantenuta integralmente.

Per OpenShift Container Platform 4.22, Red Hat documenta l’offload hardware per i nodi bare-metal dotati di SmartNIC compatibile e con SR-IOV Network Operator attivo. Sono supportate solo la comunicazione da pod a pod e quella da pod a servizio ClusterIP con pod regolari; le applicazioni DPDK non sono compatibili con questa funzionalità. Inoltre, il vantaggio è limitato alle sessioni di comunicazione in cui i nodi coinvolti utilizzano SmartNIC compatibili.

Nel caso di reti host o locali crittografate, l’offload IPsec può occuparsi di alcune attività o dell’intero processo di incapsulamento, decapsulamento, crittografia e protezione contro il replay. NVIDIA documenta a tal fine diversi tipi di offload, tra cui il crypto-offload e il full-offload. Ciò non implica tuttavia un’idoneità universale: il supporto e i limiti prestazionali dipendono dal modello, dal firmware e dall’algoritmo crittografico utilizzato.

Un semplice server di web hosting è volutamente un controesempio. Se fornisce prevalentemente poche risposte HTTP di grandi dimensioni e non mostra alcun carico della CPU nel percorso dei pacchetti, è possibile utilizzare soluzioni più specializzate hardware del server non fanno altro che aumentare i costi operativi. Innanzitutto occorre chiarire se la causa del collo di bottiglia sia l'applicazione, il database, la memoria o la rete. Le SmartNIC non sono una valida alternativa a questa diagnosi.

Confronto tecnico dei casi d'uso

A determinare se una SmartNIC sia utile non è la velocità nominale della porta, bensì il percorso concreto dei dati. La sua adozione risulta particolarmente indicata quando numerose regole ricorrenti, un numero elevato di flussi o funzioni di overlay e di sicurezza occupano costantemente il tempo di elaborazione della CPU dell’host. Il vantaggio rimane dipendente dal percorso: Una sezione accelerata è utile solo per le connessioni che utilizzano effettivamente hardware compatibile e regole supportate.

Nel caso delle piattaforme VM, SR-IOV Un approccio tipico: le funzioni virtuali vengono assegnate a una VM, mentre le interfacce Representor nel sistema operativo mappano le porte di tali funzioni. Ciò consente di implementare a livello hardware le regole di inoltro tra porte virtuali e fisiche in un’architettura orientata a switchdev. Ciò non sostituisce tuttavia la verifica che la separazione dei mandanti desiderata e il modello operativo rimangano inalterati.

Kubernetes rappresenta l’opposto di una promessa generica di accelerazione. Per l’integrazione documentata con OpenShift 4.22 valgono determinati percorsi di traffico supportati, nodi SmartNIC compatibili e requisiti relativi ai carichi di lavoro. Se un nodo con funzionalità di offload comunica con un nodo standard, quest’ultimo elabora la propria parte nel kernel, limitando così il percorso complessivo. Un’implementazione dovrebbe quindi prendere in considerazione inizialmente un pool di nodi circoscritto e percorsi di comunicazione reali.

Nel caso di reti host o locali crittografate, è necessario utilizzare questi termini con particolare precisione. A seconda della piattaforma, le varianti IPsec documentate vanno dal “crypto-offload” al “full offload” per l’incapsulamento, il decapsulamento, la crittografia e la protezione contro il replay. Ciò non comporta alcuna garanzia generale di throughput: il modello, il firmware, gli algoritmi utilizzati e i limiti specifici del prodotto determinano quali operazioni di elaborazione vengono effettivamente esternalizzate.

Verificare la compatibilità prima del lancio

Un processo di approvvigionamento inizia con un'analisi accurata della situazione attuale, non con l'attivazione delle opzioni di offload. Registrare il modello esatto della scheda, compresi l’ID PCI, la versione del firmware, i driver e il kernel. Inoltre, è necessario conoscere la modalità eSwitch, nonché la versione e la configurazione di Open vSwitch, OVN, dell’hypervisor o della piattaforma Kubernetes, poiché la sola compatibilità della scheda non garantisce un’integrazione software completa.

La semantica di regolazione richiesta dovrebbe essere disponibile in anticipo sotto forma di descrizione del percorso dei dati: ad esempio, assegnazione VLAN, IPv4 o IPv6, TCP o UDP, tipo di tunnel, modifica dell’intestazione, inoltro o drop. La documentazione sperimentale di OVS 4.0.90 mostra, per la sua configurazione DPDK, che l’assenza di azioni hardware può comportare un offload parziale. Ne consegue che, per qualsiasi altra versione o piattaforma, si tratta solo di una richiesta di verifica, non di una garanzia sulle funzionalità offerte.

Le matrici a piattaforma sono Verifiche di compatibilità relative alle versioni, nessuna affermazione generica su una famiglia di schede di rete. OpenShift 4.22 indica schede di rete specifiche per la sua integrazione dell’offload hardware, tra cui BlueField-2 in modalità ConnectX-6. Da ciò non è possibile dedurre né il supporto di un altro firmware, né di un’altra modalità DPU, né di una distribuzione diversa. Documentare quindi separatamente ogni combinazione di hardware, firmware, driver e versione della piattaforma.

Per Linux-switchdev è inoltre fondamentale che l’hardware rispetti la semantica della rete software. Nel caso del filtraggio VLAN, ad esempio, uno switch che esegue l'offload deve rispettare le regole VLAN del bridge e scartare gli ID VLAN non autorizzati. Questo requisito dimostra perché gli elenchi delle funzioni e le politiche di sicurezza devono essere verificati congiuntamente: l'accelerazione non deve generare una segmentazione di rete divergente.

Valutare i pro e i contro di SmartNIC rispetto alla CPU e al software

Una SmartNIC è solo una delle diverse opzioni disponibili quando l'elaborazione di rete è limitata. Innanzitutto, vale la pena verificare se una maggiore capacità della CPU, un numero adeguato di code, l'RSS, la distribuzione degli IRQ o l'ottimizzazione del kernel siano già in grado di risolvere il collo di bottiglia. Per una classificazione di SoftIRQ, code e distribuzione degli interrupt, si rimanda all’articolo su Prestazioni della CPU e della rete nell'hosting ulteriori nozioni di base. In assenza di prove che dimostrino l’esistenza di un collo di bottiglia nella rete, l’hardware speciale aggiuntivo rimane un’ipotesi.

DPDK e AF_XDP possono ridurre i percorsi software sulle CPU host, ma richiedono entrambi una progettazione specifica dell’architettura e della CPU. L’affermazione relativa al polling continuo non può essere applicata in modo generalizzato a entrambi gli approcci: nella documentazione OVS-DPDK relativa alla configurazione descritta, un thread esegue il polling continuo dei dispositivi DPDK, occupando interamente un core della CPU. L’assegnazione NUMA, l’isolamento dei core e le versioni specifiche di OVS e DPDK rimangono quindi parte integrante della progettazione.

Anche una scheda di rete classica per server può fornire un offload sufficiente per i checksum, la segmentazione o singole funzionalità di tunneling. Questa scelta è adeguata quando non sono necessarie regole di switch virtuali complesse, la separazione dei tenant o percorsi di sicurezza dei dati implementati a livello hardware. Le SmartNIC diventano particolarmente interessanti quando le funzioni richieste vanno oltre tali caratteristiche di base e sono ricorrenti nel lungo periodo.

Il concetto di capacità è semplice ma importante: se su un host i core della CPU sono occupati dall’elaborazione dei pacchetti e se una parte rappresentativa di questi pacchetti può essere completamente scaricata, è possibile che si crei un margine di CPU. Tuttavia, questo margine viene considerato capacità utilizzabile solo se né l’applicazione, né la memoria, né lo storage, né un fallback software costituiscono il collo di bottiglia successivo. Non è una derivazione diretta dalla velocità di collegamento o dal prezzo della scheda.

Confronta quindi le alternative sulla base dello stesso profilo di carico: dimensioni dei pacchetti, velocità di connessione, numero di regole, tunnel, crittografia e picchi di carico previsti. A tal fine, considera le quote di CPU del percorso dei dati separatamente dal carico di lavoro dell’applicazione e verifica quali flussi vengono effettivamente elaborati dall’hardware. Un Colli di bottiglia della CPU L'utilizzo di firewall, overlay o inoltro virtuale costituisce un motivo valido per una valutazione; un carico di sistema generalmente elevato, invece, non lo è.

Rendere visibile l'offload durante il funzionamento

Dopo l'implementazione, non è sufficiente considerare attiva un'opzione di offload. Una prova di funzionamento affidabile collega il Stato del flusso con i contatori della scheda, i tassi di perdita e di errore, il carico della CPU e un profilo di carico simile al traffico futuro. Solo nel loro insieme questi dati rivelano se i flussi rilevanti vengono effettivamente elaborati dall’hardware o se l’host continua a sostenere la parte preponderante del percorso dei dati.

Ai fini del confronto, gli operatori dovrebbero considerare le stesse dimensioni dei pacchetti, gli stessi protocolli, lo stesso numero di connessioni e le stesse politiche sia prima che dopo una modifica. La velocità di trasmissione in gigabit da sola può facilmente mascherare un collo di bottiglia in presenza di pacchetti di piccole dimensioni o di numerosi flussi paralleli. Altrettanto importanti sono la latenza, il tempo di CPU per ogni host coinvolto, il carico Softirq, i drop di coda e la distribuzione del traffico tra nodi e porte.

I comandi seguenti non modificano alcuna configurazione. La prima query tiene conto sia dei dispositivi PCI che compaiono come controller Ethernet, sia di quelli che compaiono come controller di rete. ethtool -k Mostra le funzionalità di offload disponibili o attivate su Netdev, ma non fornisce una prova completa né dell’eSwitch, né dello SmartNIC, né del flow offload. Anche gli altri output sono dati di inventario e di configurazione, non costituiscono una prova di una specifica regola completamente trasferita.

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

Nel caso di Open vSwitch, è importante distinguere in particolare tra l’accelerazione hardware configurata e il risultato osservato. La documentazione di sviluppo di OVS 4.0.90 definisce il proprio offload hardware del flusso come sperimentale e descrive l'offload completo o parziale solo per questa configurazione di OVS con DPDK. Per l’utilizzo in produzione è quindi necessario valutare le informazioni sul flusso e i contatori hardware insieme ai contatori software dell’host.

Il monitoraggio richiede inoltre un riferimento temporale. Un breve test può confermare le regole, mentre un profilo simile a quello di produzione può in seguito far emergere capacità delle tabelle, percorsi di log rari o riconfigurazioni. È quindi opportuno registrare i valori normali e le anomalie per ciascun modello di scheda, firmware, driver e versione della piattaforma. In questo modo, dopo gli aggiornamenti, è possibile verificare se il Percorso dati oppure si è semplicemente modificato il carico osservato.

Nell'integrazione con OpenShift 4.22, la vista deve inoltre coprire l'intero percorso di comunicazione. Il supporto documentato per l'offload hardware si applica solo a determinati carichi di lavoro e tipi di comunicazione. Se un nodo compatibile comunica con un nodo privo di una SmartNIC adeguata, quest’ultimo elabora la propria porzione nel kernel; i punti di misurazione presenti su un solo host possono quindi fornire una rappresentazione incompleta del percorso end-to-end.

Casi tipici di errore e percorsi di ricaduta

L'errore più comune è trasferimento incompleto. Un flusso può essere riconosciuto a livello hardware sulla base di semplici caratteristiche, ma per un’azione non supportata deve tornare, in parte o completamente, al percorso software. La documentazione sperimentale di OVS 4.0.90 descrive questo offload parziale per la propria configurazione DPDK. Non si tratta di un'affermazione generale valida per ogni installazione di OVS, ma chiarisce il punto di verifica necessario in ogni integrazione concreta.

La diagnosi inizia lungo il percorso effettivo: porta di ingresso, funzione virtuale o rappresentatore, regola di switch, elaborazione del tunnel o della policy e carico di lavoro di destinazione. Se i contatori a monte e a valle di una fase non corrispondono in modo plausibile, ciò costituisce un motivo per verificare le corrispondenze, le azioni e il fallback. Una funzionalità attivata non sostituisce questa mappatura, poiché la capacità della scheda non comprende ogni combinazione di regole desiderata.

I cluster eterogenei rendono più difficile il confronto. In OpenShift 4.22, l’offload hardware avviene solo se i pod e i servizi coinvolti sono assegnati a nodi dotati di SmartNIC compatibile. Se un percorso di questo tipo incontra un nodo standard, l’elaborazione avviene nel kernel e limita la comunicazione complessiva. Un singolo nodo accelerato non occupa quindi un percorso di cluster completamente accelerato.

Anche una configurazione non corretta dei pod o della rete può impedire il raggiungimento dell’effetto desiderato. Red Hat sottolinea espressamente, in riferimento alla funzionalità di OpenShift 4.22, che l’offload hardware attivato senza pod configurati in modo adeguato può compromettere la velocità di trasmissione dei pod. Gli amministratori non dovrebbero quindi cercare di risolvere eventuali anomalie attivando ulteriori opzioni, ma verificare innanzitutto il collegamento del carico di lavoro, la modalità di rete e i flussi effettivamente raggiunti.

La capacità di regolazione e le discrepanze del firmware rientrano nella stessa classe di errori: in presenza di molti clienti, connessioni di breve durata o politiche dinamiche, il volume di flusso rilevante può crescere in modo diverso dal previsto. Inoltre, un driver legato a una versione specifica o un firmware diverso possono offrire funzionalità diverse rispetto alla combinazione di piattaforme prevista. Per questo motivo, i dati di inventario e i contatori devono sempre essere archiviati insieme alle regole effettivamente in uso.

A percorso di ricaduta controllato garantisce la diagnosticabilità del funzionamento. Ciò significa che l’elaborazione software rimane come alternativa prevista e che le modifiche vengono implementate gradualmente, con finestre di confronto e chiari criteri di interruzione. Il fallback software non costituisce di per sé un difetto, ma può rappresentare la gestione prevista di azioni che il percorso hardware scelto non supporta completamente.

Decisioni realistiche in materia di approvvigionamento e gestione

Una decisione di acquisto parte dal carico di lavoro, non dalla velocità della porta o dalla denominazione del prodotto. L’uso di hardware specializzato è giustificato laddove l’elaborazione ricorrente dei pacchetti occupi in modo dimostrabile tempo di CPU: ad esempio, numerose reti virtuali, insiemi stabili di policy, traffico overlay o un percorso di crittografia definito. In assenza di tale dimostrazione, l’ottimizzazione della CPU e delle code o una scheda di rete classica con adeguati offload di base possono rappresentare la soluzione più semplice.

Il passo successivo consiste nel Certificato di compatibilità per la combinazione specifica: modello di scheda e modalità operativa, firmware, driver, kernel, switch virtuale o CNI, nonché le funzioni di match e action necessarie. Gli acceleratori di infrastruttura programmabili possono, ad esempio, prevedere l’offload del flusso per funzioni relative allo stato o alla sessione; ciò non implica tuttavia che ogni SmartNIC o ogni piattaforma fornisca la stessa funzione.

La riduzione del carico sulla CPU prevista è disponibile come capacità solo quando l’elaborazione dei pacchetti rappresentava il collo di bottiglia e i core ora liberi possono essere utilizzati in modo sensato. Se, ad esempio, vengono destinati a database, web worker o come riserve, si tratta di una scelta architettonica, non di un aumento automatico delle prestazioni. La restante dotazione del server rimane quindi determinante; CPU, memoria e storage devono essere adeguati all’applicazione tanto quanto la rete. Maggiori informazioni sul quadro d’insieme sono disponibili nell’articolo su hardware server rilevante per le prestazioni nel web hosting.

Nel caso di IPsec, la verifica è particolarmente specifica: le varianti di offload documentate vanno dal crypto-offload fino al trasferimento completo delle operazioni di incapsulamento, decapsulamento, crittografia e protezione dal replay. La variante utilizzabile dipende dal modello, dalla generazione, dal firmware e dalla configurazione crittografica. Le note relative al prodotto possono inoltre contenere limitazioni per determinate generazioni o larghezze di banda; tali informazioni devono essere incluse nella verifica di approvazione prima dell’implementazione.

Una DPU amplia il processo decisionale con un proprio ambito amministrativo e di fiducia. Nella modalità BlueField-DPU, il sistema Arm integrato controlla le risorse NIC e il percorso dei dati, anziché limitarsi a far funzionare la scheda come semplice adattatore host. Ciò consente di separare le attività infrastrutturali dall’host, ma richiede un approccio solido in materia di diritti di accesso, immagini, aggiornamenti, monitoraggio e ripristino.

Dal punto di vista economico, quindi, non conta solo il prezzo della scheda. A fronte di ciò vi sono la capacità della CPU host risparmiata o evitata, la durata prevista della piattaforma e i costi aggiuntivi per la qualificazione, i pezzi di ricambio, la manutenzione del firmware e il ripristino in caso di incidenti. Una SmartNIC è utile se questo calcolo si basa su un percorso dei dati riproducibile e su un ciclo di vita gestibile a lungo termine – non perché l’hardware specializzato sembri, in linea di principio, più veloce.