Conoscere le reti virtuali NFVIS: OVS, DPDK e SR-IOV

Introduzione

Questo documento descrive lo schema di rete virtuale fornito dalla piattaforma NFVIS per la comunicazione delle VNF nelle reti aziendali e di servizi.

Componenti usati

Le informazioni di questo documento si basano sui seguenti componenti hardware e software:

• ENCS5412 con NFVIS 4.7.1-FC4
• c8300 uCPE 1N20 con NFVIS 4.12.1-FC2

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Panoramica delle reti in NFVIS

Una rete di gestione interna (int-mgmt-net) e un bridge (int-mgmt-br) vengono utilizzati internamente per il monitoraggio VNF, assegnando indirizzi IP di gestione dalla subnet 10.20.0.0/24.

Piattaforma ENCS54XX

Figura 1. Connessioni interne di switch hardware e schede di interfaccia di rete Uplink WAN/LAN

Catalyst 8200 uCPE

• Per impostazione predefinita, è possibile accedere al NFVIS tramite la porta WAN o la porta LAN GE0/2 per la gestione.

• Per impostazione predefinita, la rete WAN (wan-net e wan2-net) e il bridge WAN (wan-br e wan2-br) sono abilitati per DHCP. Per impostazione predefinita, GE0-0 è associato al bridge WAN e GE0-1 al bridge WAN2.

• L'indirizzo IP di gestione 192.168.1.1 sul Catalyst 8200 UCPE è accessibile tramite GE0-2.

• GE0-2 è associato al bridge LAN.

• Viene creata una rete di gestione interna (int-mgmt-net) e un bridge (int-mgmt-br) che vengono utilizzati internamente per il monitoraggio del sistema.

Figura 2. Bridging interno e switch virtuali assegnati alle schede NIC 8200

Catalyst 8300 uCPE 1N20

1. Per impostazione predefinita, è possibile accedere al NFVIS tramite le porte FPGE (Front Panel Gigabit Ethernet) WAN o tramite la porta LAN GE0-2 per la gestione

2. Per impostazione predefinita, la rete WAN (wan-net) e un bridge WAN (wan-br) sono abilitati per DHCP. Per impostazione predefinita, GE0-0 è associato al bridge WAN

3. La rete WAN (wan2-net) e un bridge WAN (wan2-br) vengono creati per impostazione predefinita ma non associati ad alcuna porta fisica

4. GE0-2 è associato a un bridge LAN; tutte le altre porte non sono associate a OVS

5. Il Management IP 192.168.1.1 su C8300-uCPE è accessibile tramite GE0-2

6. Vengono create una rete di gestione interna (int-mgmt-net) e un bridge (int-mgmt-br), utilizzati internamente per il monitoraggio del sistema.

Figura 3. Bridging interno e switch virtuali assegnati alle schede NIC 8300

Tecnologie di virtualizzazione della rete

Open vSwitch (OVS)

Open vSwitch (OVS) è uno switch virtuale open-source multilivello progettato per consentire l'automazione della rete tramite estensioni programmatiche, fornendo al tempo stesso il supporto per interfacce e protocolli di gestione standard, quali NetFlow, sFlow, IPFIX, RSPAN, CLI, LACP e 802.1ag. È ampiamente utilizzato in ambienti virtualizzati di grandi dimensioni, in particolare con hypervisor per gestire il traffico di rete tra macchine virtuali (VM). Consente la creazione di sofisticate topologie e policy di rete gestite direttamente tramite l'interfaccia NFVIS, fornendo un ambiente versatile per la virtualizzazione delle funzioni di rete.

Figura 4. Configurazione OVS nel kernel Linux

Bridge OVS

Utilizza le regole dei bridge di rete virtuali e dei flussi per inoltrare i pacchetti tra gli host. Si comporta come uno switch fisico, solo virtualizzato.

Figura 5. Esempio di implementazione di 2 VM o VNF collegate al bridge wan-br

Deficit di switching di contesto

Quando un pacchetto di rete arriva a una scheda di interfaccia di rete (NIC, Network Interface Card), attiva un interrupt, un segnale al processore che indica la necessità di attenzione immediata. La CPU sospende le attività correnti per gestire l'interrupt, un processo noto come elaborazione degli interrupt. Durante questa fase, la CPU, sotto il controllo del kernel del sistema operativo, legge il pacchetto dalla scheda NIC nella memoria e decide le fasi successive in base alla destinazione e allo scopo del pacchetto. L'obiettivo è quello di elaborare rapidamente il pacchetto o indirizzarlo all'applicazione a cui è destinato, riducendo al minimo la latenza e massimizzando la velocità di trasmissione.

La commutazione di contesto è il processo con cui una CPU passa dall'esecuzione di operazioni in un ambiente (contesto) a un altro. Ciò è particolarmente importante quando si passa dalla modalità utente alla modalità kernel:

• Modalità utente: si tratta di una modalità di elaborazione con restrizioni in cui viene eseguita la maggior parte delle applicazioni. Le applicazioni in modalità utente non dispongono di accesso diretto all'hardware o alla memoria di riferimento e devono comunicare con il kernel del sistema operativo per eseguire queste operazioni.

• Modalità kernel: questa modalità consente al sistema operativo l'accesso completo all'hardware e a tutta la memoria. Il kernel può eseguire qualsiasi istruzione CPU e fare riferimento a qualsiasi indirizzo di memoria. La modalità kernel è necessaria per l'esecuzione di attività quali la gestione di dispositivi hardware, memoria ed esecuzione di chiamate di sistema.

Quando un'applicazione deve eseguire un'operazione che richiede privilegi a livello di kernel, ad esempio la lettura di un pacchetto di rete, si verifica un cambio di contesto. La CPU passa dalla modalità utente alla modalità kernel per eseguire l'operazione. Al termine, un'altra opzione di contesto riporta la CPU in modalità utente per continuare l'esecuzione dell'applicazione. Questo processo di commutazione è fondamentale per mantenere la stabilità e la sicurezza del sistema, ma introduce un sovraccarico che può influire sulle prestazioni.

OVS viene eseguito principalmente nello spazio utente del sistema operativo, che può diventare un collo di bottiglia con l'aumento del throughput dei dati. Questo perché sono necessari più switch di contesto perché la CPU passi alla modalità kernel per elaborare i pacchetti, rallentando le prestazioni. Questa limitazione è particolarmente evidente in ambienti con elevate velocità di trasmissione dei pacchetti o quando è fondamentale definire con precisione i tempi. Per risolvere questi limiti di prestazioni e soddisfare le esigenze delle reti moderne ad alta velocità, sono state sviluppate tecnologie come DPDK (Data Plane Development Kit) e SR-IOV (Single Root I/O Virtualization).

Data Plane Development Kit (DPDK)

DPDK è un insieme di librerie e driver progettati per accelerare i carichi di lavoro di elaborazione dei pacchetti su un'ampia gamma di architetture CPU. Ignorando il tradizionale stack di rete del kernel (evitando la commutazione di contesto), DPDK può aumentare in modo significativo il throughput del piano dati e ridurre la latenza. Ciò è particolarmente vantaggioso per le VNF ad alto throughput che richiedono comunicazioni a bassa latenza, rendendo NFVIS una piattaforma ideale per funzioni di rete sensibili alle prestazioni.

Figura 6. Ottimizzazioni tradizionali per la commutazione di contesto OVS (lato sinistro) e DPDK OVS (lato destro)

Il supporto per DPDK per OVS è iniziato con NFVIS 3.10.1 per ENCS e 3.12.2 per altre piattaforme.

• Throughput della catena di servizi vicino a SRIOV, migliore rispetto agli OVS non DPDK.
• Driver virtuale richiesto per VNF.
• Piattaforme supportate
• ENCS 3.10.1 e successive.
• UCS, UCS-C, CSP5K 3.12.1 e versioni successive.
• DPDK per canali porte supportato dal 4.12.1.
• Packet /traffic capture : non supportato in DPDK.
• Traffico di span su PNIC : non supportato in DPDK.
• Dopo aver attivato OVS-DPDK, non è possibile disattivarlo come funzione singola. L'unico modo per disabilitare il DPDK sarebbe un reset di fabbrica. 

Copia dei dati

Gli approcci di rete tradizionali spesso richiedono la copia dei dati più volte prima di raggiungere la destinazione nella memoria VM. Ad esempio, è necessario copiare un pacchetto dalla scheda NIC allo spazio del kernel, quindi allo spazio utente per l'elaborazione da parte di uno switch virtuale (come OVS) e infine alla memoria della VM. Ogni operazione di copia subisce un ritardo e aumenta l'utilizzo della CPU nonostante i miglioramenti delle prestazioni offerti da DPDK, bypassando lo stack di rete dei kernel.

Tali costi includono le copie della memoria e il tempo di elaborazione necessario per gestire i pacchetti nello spazio utente prima che possano essere inoltrati alla VM. Le tecnologie PCIe Passthrough e SR-IOV risolvono questi colli di bottiglia consentendo la condivisione diretta di un dispositivo di rete fisico (come una NIC) tra più VM senza coinvolgere il sistema operativo host nella stessa misura dei metodi di virtualizzazione tradizionali.

Pass-through PCIe

La strategia prevede l'esclusione dell'hypervisor per consentire alle funzioni di rete virtuale (VNF) di accedere direttamente a una scheda di interfaccia di rete (NIC) e raggiungere un throughput quasi massimo. Questo approccio è noto come PCI passthrough, che consente a una scheda NIC completa di essere dedicata a un sistema operativo guest senza l'intervento di un hypervisor. In questa configurazione, la macchina virtuale funziona come se fosse collegata direttamente alla scheda NIC. Ad esempio, con due schede NIC disponibili, ciascuna può essere assegnata in modo esclusivo a diverse VNF, fornendo loro accesso diretto.

Tuttavia, questo metodo presenta uno svantaggio: se solo due NIC sono disponibili e utilizzate esclusivamente da due VNF separati, qualsiasi VNF aggiuntivo, ad esempio un terzo, rimarrebbe senza accesso alla NIC a causa della mancanza di una NIC dedicata disponibile per questo. Una soluzione alternativa prevede l'utilizzo di Single Root I/O Virtualization (SR-IOV).

Virtualizzazione I/O a radice singola (SR-IOV)

È una specifica che consente a un singolo dispositivo PCI fisico, come una scheda di interfaccia di rete (NIC), di apparire come più dispositivi virtuali separati. Questa tecnologia fornisce accesso diretto alle VM ai dispositivi di rete fisici, riducendo il sovraccarico e migliorando le prestazioni di I/O. Funziona dividendo un singolo dispositivo PCIe in più slice virtuali, ciascuna assegnabile a diverse VM o VNF, risolvendo in modo efficace il limite causato da un numero finito di NIC. Queste slice virtuali, note come VF (Virtual Functions), consentono di condividere le risorse NIC tra più VNF. La funzione fisica (PF) si riferisce al componente fisico effettivo che facilita le capacità di SR-IOV.

Sfruttando SR-IOV, NFVIS può allocare risorse NIC dedicate a VNF specifiche, garantendo prestazioni elevate e bassa latenza facilitando l'accesso diretto alla memoria (DMA) dei pacchetti di rete direttamente nella rispettiva memoria VM. Questo approccio riduce al minimo il coinvolgimento della CPU nella semplice elaborazione dei pacchetti, riducendo così l'utilizzo della CPU. Ciò è particolarmente utile per le applicazioni che richiedono una larghezza di banda garantita o hanno requisiti di prestazioni rigorosi.

Figura 7. Separazione delle risorse PCIe SR-IOV NFVIS tramite le funzioni hardware

Funzioni fisiche (PF)

Sono funzioni PCIe complete e fanno riferimento a un dispositivo hardware specifico che fornisce funzioni di rete specifiche; sono funzioni PCIe complete che possono essere rilevate, gestite e gestite come qualsiasi altro dispositivo PCIe. Le funzioni fisiche includono le funzionalità SR-IOV che possono essere utilizzate per configurare e controllare un dispositivo PCIe.

Funzioni virtuali (VF)

Sono funzioni semplificate con risorse di configurazione minime (leggere), incentrate esclusivamente sull'elaborazione dell'I/O come semplici funzioni PCIe. Ogni funzione virtuale ha origine da una funzione fisica. L'hardware del dispositivo limita il possibile numero di funzioni virtuali. Una porta Ethernet, il dispositivo fisico, può corrispondere a numerose funzioni virtuali, che possono quindi essere allocate a macchine virtuali diverse.

Driver consigliati per l'accelerazione SR-IOV su hardware compatibile con NFVIS

Piattaforma	NIC	Driver NIC
ENCS 54XX	Interruttore Backplane	i40e
ENCS 54XX	GE0-0 e GE0-1	igb
Catalyst 8200 uCPE	GE0-0 e GE0-1	ixgbe
Catalyst 8200 uCPE	GE0-2 e GE0-5	igb

Casi di utilizzo per DPDK e SR-IOV

Preferenza DPDK

In particolare negli scenari in cui il traffico di rete scorre principalmente da est a ovest (ovvero rimane all'interno dello stesso server), DPDK offre prestazioni superiori a SR-IOV. La logica è semplice: quando il traffico viene gestito internamente all'interno del server senza dover accedere alla scheda NIC, SR-IOV non offre alcun vantaggio. Infatti, SR-IOV potrebbe potenzialmente causare inefficienze estendendo inutilmente il percorso del traffico e consumando le risorse NIC. Pertanto, per la gestione interna del traffico dei server, l'utilizzo di DPDK è la scelta più efficiente.

Figura 8. Attraversamento pacchetti DPDK e SR-IOV nel traffico da est a ovest

Preferenza SR-IOV

In situazioni in cui il traffico di rete scorre da nord a sud, o anche da est a ovest, ma in particolare tra i server, l'utilizzo di SR-IOV si dimostra più vantaggioso rispetto a DPDK. Ciò è particolarmente vero per la comunicazione tra server. Dato che tale traffico deve inevitabilmente attraversare la scheda NIC, optare per l'OVS DPDK-enhanced potrebbe introdurre inutilmente ulteriori complessità e potenziali vincoli di prestazioni. Pertanto, SR-IOV risulta essere la scelta preferibile in queste circostanze, offrendo un percorso semplice ed efficiente per la gestione del traffico tra server.

Figura 9. Attraversamento pacchetti DPDK e SR-IOV nel traffico da nord a sud

Configurazione

Abilitazione di DPDK

Per abilitare DPDK dalla GUI, è necessario selezionare Configurazione > Macchina virtuale > Rete > Reti. Una volta visualizzato il menu, fare clic sullo switch per attivare la funzione

Figura 10. Pulsante di scorrimento disponibile sulla GUI per l'attivazione del PDK

Per la CLI, è necessario abilitarla dalle impostazioni di sistema globali in modalità di configurazione.

nfvis(config)# system settings dpdk enable

Creare una nuova rete e associarla a un nuovo bridge OVS

Passare a Configurazione > Macchina virtuale > Rete > Reti. Nella pagina Reti fare clic sul segno più (+) in alto a sinistra per visualizzare la tabella Reti.

Figura 11. Visualizzazione tabella reti dalla GUI NFVIS

Assegnare un nome alla rete e associarla a un nuovo bridge. Le opzioni di collegamento di VLAN e interfacce possono dipendere dalle esigenze dell'infrastruttura di rete.

Figura 12. Modale "Add Network" (Aggiungi rete) per la creazione di reti virtuali nell'interfaccia grafica NFVIS

Dopo aver fatto clic sul pulsante invia, è necessario essere in grado di esaminare la rete appena creata aggiunta alla tabella Reti. 

Figura 13. Visualizzazione tabella reti dall'interfaccia utente di NFVIS, dove "Refresh Icon" si trova nell'angolo in alto a destra (evidenziato in rosso)

Se eseguito dalla CLI, ogni rete e bridge viene creato dalla modalità di configurazione, il flusso di lavoro è lo stesso della versione GUI.

1. Creare il nuovo ponte.

nfvis(config)# bridges bridge inter-vnf-br2
nfvis(config-bridge-inter-vnf-br2)# commit

2. Creare una nuova rete e associarla al bridge creato in precedenza

nfvis(config)# networks network inter-vnf-net2 bridge inter-vnf-br2 trunk true native-vlan 1
nfvis(config-network-inter-vnf-net2)# commit

Collegamento di VNF

Per iniziare con una topologia di rete o con una singola distribuzione VFN, è necessario selezionare Configurazione > Distribuisci. È possibile trascinare una VM o un contenitore dall'elenco di selezione all'area di creazione della topologia per iniziare a creare l'infrastruttura virtualizzata.

Figura 14. Ad esempio, c8000v-1 è connesso tramite passthrough Ge0-0 SR-IOV e una rete inter-vnf OVS personalizzata, c8000v-2 ha 2 connessioni OVS che la comunicano con c8000v-1 e c8000v-3, e c8000v-3 ha una connessione intra-vnf OVS che permette la comunicazione con c8000v-2, oltre a un'interfaccia di uscita attraverso il bridge della porta LAN (OVS) Ge0-2.

Dove la stessa topologia dell'immagine può essere creata dalla CLI:

c800v-1 Configurazione:

nfvis(config)# vm_lifecycle tenants tenant admin deployments deployment c8000v-1 vm_group c8000v-1 image c8000v-universalk9_16G_serial.17.09.04a.tar.gz flavor C8000V-small
nfvis(config-vm_group-c8kv_group)# interfaces interface 0 network GE0-0-SRIOV-1
nfvis(config-interface-0)# exit
nfvis(config-vm_group-c8kv_group)# interfaces interface 1 network inter-vnf-net
nfvis(config-interface-1)# exit
nfvis(config-vm_group-c8kv_group)# port_forwarding port ssh protocol TCP vnf_port 22 external_port_range 2228 2228
nfvis(config-external_port_range-2228/2228)# commit

c800v-2 Configurazione:

nfvis(config)# vm_lifecycle tenants tenant admin deployments deployment c8000v-2 vm_group c8000v-2 image c8000v-universalk9_16G_serial.17.09.04a.tar.gz flavor C8000V-small
nfvis(config-vm_group-c8kv_group)# interfaces interface 0 network inter-vnf-net
nfvis(config-interface-0)# exit
nfvis(config-vm_group-c8kv_group)# interfaces interface 1 network inter-vnf-net2
nfvis(config-interface-1)# exit
nfvis(config-vm_group-c8kv_group)# port_forwarding port ssh protocol TCP vnf_port 22 external_port_range 2229 2229
nfvis(config-external_port_range-2229/2229)# commit

c800v-3 Configurazione:

nfvis(config)# vm_lifecycle tenants tenant admin deployments deployment c8000v-3 vm_group c8000v-3 image c8000v-universalk9_16G_serial.17.09.04a.tar.gz flavor C8000V-small
nfvis(config-vm_group-c8kv_group)# interfaces interface 0 network inter-vnf-net2
nfvis(config-interface-0)# exit
nfvis(config-vm_group-c8kv_group)# interfaces interface 1 lan-net
nfvis(config-interface-1)# exit
nfvis(config-vm_group-c8kv_group)# port_forwarding port ssh protocol TCP vnf_port 22 external_port_range 2230 2230
nfvis(config-external_port_range-2230/2230)# commit

Articoli e documentazione correlati

Laboratorio pratico e approfondito per unità NFV di classe enterprise

Installa NFVIS aziendale tramite USB