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.
venerdì 20 febbraio 2015
giovedì 5 febbraio 2015
DOBBIAMO PASSARE DA MONTAGGIO DI PARTI DI AUTOMOBILI A GUIDARE AUTOMOBILI
Durante una conversazione che ho avuto con Terry Slattery durante Interop New York, ha detto " beh, io non credo che nessuno dovrebbe essere configurazione delle VLAN e chiedendo ÔÇśHow per configurare una VLAN su uno switch '- dobbiamo concentrarci sulla fornitura end-to connettività -end ", e non c'è assolutamente nulla in questa affermazione che si potrebbe non essere d'accordo con.
Tuttavia, qualcuno alla fine dovranno sapere come risolvere VLAN, e quando sono presentati con tale argomento Terry ha detto " Sì, questo è assolutamente vero - ma che sarebbe come un meccanico auto guardando il motore in macchina ", e poi mi ha colpito : uno dei veri problemi che abbiamo con le nostre reti di oggi è che l'industria di rete è un settore parti di automobili. Invece di concentrarsi su come costruire e vendere automobili meravigliose, l'intero settore è occupato parti di automobili di vendita ai costruttori di casa, che li usano in maniera guazzabuglio per ottenere i loro aggeggi unici .
Perchè dovrebbe essere così? Ogni volta che un nuovo operatore sta cercando di fare una mossa dirompente (e potrebbe essere 3Com o Cisco negli anni '90, o HP a pochi anni fa, quando hanno deciso di entrare in rete data center), dicono il cliente che può sostituire le parti dalla "macchina" esistente con un più economico, più nuovo, più lucidi e parti maggiormente compatibili fatte da loro, che si concentra inevitabilmente la discussione sulle specifiche delle "parti di automobili" invece di fruibilità della vettura e la facilità di andare in giro (che dovrebbe essere il punto di possedere una macchina per la maggior parte delle persone).
Per cambiare la situazione, abbiamo bisogno di un cambiamento fondamentale nel comportamento, dove iniziamo acquistare soluzioni (auto) invece di parti (router, switch, firewall ...) che abbiamo accuratamente colla insieme ... ma, naturalmente, che non accadrà mai perché sarebbe il massimo lock-in del valore di milioni di dollari e nessuno è disposto a scommettere il proprio futuro o il futuro di tutta l'azienda su una macchina unico fornitore (a meno che, naturalmente, che è fornitore IBM o Oracle).
Tuttavia, qualcuno alla fine dovranno sapere come risolvere VLAN, e quando sono presentati con tale argomento Terry ha detto " Sì, questo è assolutamente vero - ma che sarebbe come un meccanico auto guardando il motore in macchina ", e poi mi ha colpito : uno dei veri problemi che abbiamo con le nostre reti di oggi è che l'industria di rete è un settore parti di automobili. Invece di concentrarsi su come costruire e vendere automobili meravigliose, l'intero settore è occupato parti di automobili di vendita ai costruttori di casa, che li usano in maniera guazzabuglio per ottenere i loro aggeggi unici .
Perchè dovrebbe essere così? Ogni volta che un nuovo operatore sta cercando di fare una mossa dirompente (e potrebbe essere 3Com o Cisco negli anni '90, o HP a pochi anni fa, quando hanno deciso di entrare in rete data center), dicono il cliente che può sostituire le parti dalla "macchina" esistente con un più economico, più nuovo, più lucidi e parti maggiormente compatibili fatte da loro, che si concentra inevitabilmente la discussione sulle specifiche delle "parti di automobili" invece di fruibilità della vettura e la facilità di andare in giro (che dovrebbe essere il punto di possedere una macchina per la maggior parte delle persone).
Per cambiare la situazione, abbiamo bisogno di un cambiamento fondamentale nel comportamento, dove iniziamo acquistare soluzioni (auto) invece di parti (router, switch, firewall ...) che abbiamo accuratamente colla insieme ... ma, naturalmente, che non accadrà mai perché sarebbe il massimo lock-in del valore di milioni di dollari e nessuno è disposto a scommettere il proprio futuro o il futuro di tutta l'azienda su una macchina unico fornitore (a meno che, naturalmente, che è fornitore IBM o Oracle).
Iscriviti a:
Post (Atom)