VM-AWARE NETWORKING MIGLIORA LA SCALABILITÀ CLOUD IAAS

Nel switch virtuale VMware - la linea di base della semplicità post ho descritto semplice layer-2 switch offerti dalla maggior parte dei venditori hypervisor e la scalabilità sfide vi stanno davanti quando si cerca di costruire soluzioni su larga scala con loro. È possibile risolvere almeno uno dei problemi di scalabilità abbastanza facilmente: VM-aware soluzioni di rete disponibili dai fornitori più data center networking di regolare dinamicamente l'elenco delle VLAN su server-to-switch link.

Qual è il problema

Vediamo brevemente rivisitare il problema: switch virtuali non hanno quasi piano di controllo. Uno switch virtuale così non si può dire gli switch VLAN adiacente fisico che ha bisogno di supportare macchine virtuali collegati alla switch virtuale. In mancanza di tali informazioni, è necessario configurare una vasta gamma di VLAN sul server rivolto a porte sullo switch fisico per permettere la libera circolazione delle macchine virtuali tra i server (hypervisor host).

Il diagramma seguente illustra il problema:

• Due inquilini sono in esecuzione in un cluster vSphere (ESX ESX-A e-B);
• Red inquilino sta usando VLAN 100, Blu inquilino sta usando VLAN 200;
• Con la distribuzione VM mostrato nel diagramma, ESX-A deve accedere a VLAN 100; ESX-B ha bisogno di accedere alle VLAN 200.
• Come dispositivi di rete non può prevedere in che modo le macchine virtuali si muoverà tra gli host vSphere, è necessario configurare sia VLAN su tutti i server di fronte porte (GE1 / 0 su SW-1 e GE2 / 3 SW-2) così come su tutti gli inter -switch link.

L'elenco delle VLAN configurata sul server rivolti porte degli accessi a livello di switch comprende così comunemente VLAN completamente inutile.

La vasta gamma di VLAN configurate su tutti i server di fronte le porte cause inondazione di trasmissioni, multicast e unicast sconosciuto a tutti i server indiscriminato, anche se i pacchetti non sono necessari dai server (perché la VLAN su cui siamo sommersi non è attiva nel server). I pacchetti inondato aumentare l'utilizzo del server di uplink, la loro elaborazione (e caduta) aumenta anche il carico della CPU.

La soluzione standard

VSI Discovery Protocol (VDP) , parte di Edge Virtual Bridging (EVB, 802.1Qbg) avrebbe risolto quel problema, ma non è implementato in qualsiasi switch virtuale. Di conseguenza, non c'è alcun supporto nella switch fisici, anche se HP e Force10 tenere promettente EVB supporto; HP per più di un anno.

Il più vicino che abbiamo mai avuto modo di un prodotto di spedizione EVB-simili si Cisco VM-FEX . Il Virtual Ethernet Module (VEM) in esecuzione all'interno del kernel vSphere utilizza un protocollo simile a VDP per comunicare la sua VLAN / interfaccia esigenze con il dirigente UCS.

Sembra più persone hanno visto Nessie che un EVB-compliant switch virtuale

Il mondo reale le soluzioni

Di fronte alla mancanza di sostegno EVB (o qualsiasi altro simile control-plane protocollo) in switch virtuali, i venditori di rete implementata una varietà di impiego di espedienti.Alcuni di loro sono implementati nel livello di accesso interruttori (Arista di VM Tracer , HyperLink Force10, la integrazione vCenter Brocade), altri nel software di gestione della rete (Juniper Junos Spazio Virtuale di controllo e ALU OmniVista Virtual Machine Monitor).

Ho perso un VM-aware soluzione di rete? Si prega di scrivere un commento ... e notare che non ho dimenticato VM-FEX, ma utilizza una architettura completamente diversa .

In tutti i casi, un VM-aware soluzione deve scoprire la topologia della rete prima. Quasi tutte le soluzioni di inviare i pacchetti CDP da accesso a livello di switch e usare ascoltatori CDP gli ospiti alla scoperta di vSphere host-to-switch connettività. Le informazioni raccolte da CDP ospita vSphere è solitamente estratto da usare VMware vCenter API (sì, di solito si deve parlare con il vCenter se si vuole comunicare con l'ambiente VMware).

Ah, i fornitori di rete fastidiosi. Vogliono
parlare con qualcuno, devono parlare con me.

Avete notato che ho citato VMware API nel paragrafo precedente? Bene. Poiché non hypervisor venditore briga di implementare un protocollo standard, i fornitori di rete sono tenuti ad attuare una soluzione diversa per ogni hypervisor. Quasi tutti i VM-aware soluzioni di supporto vSphere / vCenter, pochi venditori affermano anche il supporto a Xen, KVM o Hyper-V, e non ho visto nessuno di supporto nulla al di là delle quattro grandi.

Dopo l'accesso a livello di topologia è stato scoperto, la VM-aware soluzioni di tracciare i movimenti di VM tra host e hypervisor di regolare dinamicamente la gamma di VLAN in materia di accesso a livello di porte switch. Idealmente ci si combinano con MVRP nel nucleo della rete per tagliare ulteriormente le VLAN, ma solo pochi venditori implementato MVRP (e presumibilmente solo pochi clienti stanno utilizzando). QFabric è un (proprietario) brillante eccezione: perché la sua architettura mandati ricerca di ingresso singolo, che dovrebbe sfociare in un elenco di porte in uscita , esegue anche ottimale inondazioni VLAN.

Corso Cisco - Corsi Cisco - Corso CCNA

 Corso Security - CCNA Security - Certificazione Cisco