PRESTAZIONI DI HYPERVISOR-BASED OVERLAY VIRTUAL NETWORKING

Anni fa sono riuscito a saturare un uplink 10GE ​​su un server vSphere ho provato con un solo Linux VM utilizzando meno di una CPU virtuale. D'altra parte, stringendo 1 Gbps su Apri switch virtuale utilizzando l'incapsulamento GRE è stato chiamato velocità ridicola non molto tempo fa. Implementazione overlay networking virtuale nel hypervisor porta ovviamente un enorme riduzione delle prestazioni, giusto? Non così in fretta ...

TL & DR Sommario

Solo perché il rilascio di switch virtuale preferito che si è scelto per la distribuzione non funziona veloce come si desidera lavorare non significa che linerate overlay networking virtuale non può essere fatto in kernel hypervisor (nonostante le affermazioni contrarie ).

I punti dati

Sembra rete virtuale basata su hypervisor fa schifo:

Ci sono state diverse segnalazioni di out-of-box OVS spingono intorno 1Gbps con incapsulamento GRE (usare il Google-Fu per trovarli);
Nicira ha deciso di utilizzare l'incapsulamento STT per migliorare le prestazioni di I / O carichi di lavoro intensivi;
D'altra parte, la rete virtuale basata su hypervisor potrebbe oscillare:

VMware misurata solo piccola perdita di prestazioni con incapsulamento VXLAN in vSphere 5.1;
VMware sostiene NSX raggiunge velocità line-rate su due uplink 10GE ​​con ragionevole sovraccarico della CPU nella loro presentazione NET1883 VMworld (non so come si può ottenere on-line);
Cosa sta succedendo?

La Root Cause

C'è una ragione che otteniamo rapporto prestazioni estremamente disparate. Si chiama TCP Offload .

Per farla breve: stack TCP / IP in kernel Linux è lento . L'ultima volta che ho guardato, l'elaborazione basato sul kernel di pacchetto per pacchetto su un singolo core della CPU determinato ~ 3 Gbps di throughput a 1500 byte MTU. Non sono d'accordo? Scrivi un commento!

Un modo ovvio per aumentare le prestazioni è di bypassare il kernel il più possibile. Offload TCP-based NIC aiuta applicazioni basate su TCP regolari. Le soluzioni ad alte prestazioni utilizzano uno stack TCP custom / IP (esempi: Intel DPDK, 6wind, A10, Linerate Sistemi - ora F5).

Vuoi misurare l'impatto di offload TCP? Disabilitare su una macchina virtuale Linux ed eseguire il test delle prestazioni TCP preferito (e inserire i risultati in un commento;).

Riassunto : tutto ciò che interferisce con VM NIC offload TCP capacità uccideranno le prestazioni di inoltro.

Mantenere la corsa TCP Offload

La più nuova generazione di schede di rete di server (Intel XL710, Emulex OneConnect┬ «OCe14000, Mellanox ConnectX-3 Pro) supporta la funzionalità completa TCP Offload con incapsulamento VXLAN, ed entrambi vSphere e Hyper-V può utilizzare le funzionalità avanzate. Se si utilizza una di queste schede di rete e verifica ancora significativo calo di prestazioni con overlay networking virtuale, è il momento di avere un discorso serio con chi ha scritto il codice per l'interruttore virtuale.

NIC diffusa (esempio: Intel 82599) non possono fare completo offload TCP (segmentazione TCP e ricevere lato coalescenza) in combinazione con protocolli di tunneling come VXLAN. Implementazioni switch virtuale potrebbe o:

Disattivare offload TCP in VM NIC e passare MTU dimensioni pacchetti tra macchine virtuali e NIC fisica (sembra che questo potrebbe essere quello che alcune versioni di OVS stanno facendo);
Implementare offload TCP in switch virtuale o driver di periferica.
Ho passato ore a leggere la scheda Intel 82599 e sembra che ci siano modi creativi un programmatore driver di periferica potrebbe utilizzare l'hardware esistente per ottenere il lavoro di segmentazione TCP con incapsulamento VXLAN (email me se volete maggiori dettagli), ma è assolutamente impossibile ottenere Ricezione- lato coalescenza (RSC) di TCP-over-VXLAN flussi di lavoro in hardware.

Tuttavia, come VXLAN utilizza l'incapsulamento UDP, è possibile diffondere l'elaborazione dei pacchetti VXLAN ingresso su più core di CPU ( Receive Side Scaling - RSS ), con conseguente throughput più veloce nel complesso, e sembra che è esattamente il trucco switch virtuale di VMware sta usando.

I miei contatti con VMware mi dicono che i driver vSphere esistenti per NIC basati 82599 Intel supportano la segmentazione TCP con incapsulamento VXLAN (risolvere i problemi di prestazioni di trasmissione-side) e che ci vuole un solo comando per attivare RSS su un host ESXi.