ESISTE UN SISTEMA DI ORCHESTRAZIONE NUBE HAI BISOGNO DI UN CONTROLLER SDN SOTTOSTANTE?

Qualche tempo fa ho avuto una discussione interessante con un collega SDN esploratore, in cui sono arrivato a una conclusione che non ha senso inserire una rete virtuale del controller SDN sovrapposizione tra il sistema di cloud orchestrazione e switch virtuali. Come sempre, ho perso un pezzo importante del puzzle: Federazione delle istanze cloud.

2014/11/04 16: 48Z: CJ Williams mi ha mandato una e-mail con le informazioni sul controller SDN nel prossimo rilascio di Windows Server. Grazie!

Per controllare o non controllare?

La maggior parte delle soluzioni di rete virtuali sovrapposte utilizzano un controller di rete (obbligatoriamente chiamato regolatore SDN in questi giorni di campagna pubblicitaria SDN), che interagisce con il sistema di cloud orchestration attraverso un'API (esempio: Neutron API).

Microsoft è l'unica eccezione sono a conoscenza: il loro sistema di cloud orchestration installa trasmissione di informazioni direttamente nelle estensibili switch virtuali Hype-V utilizza commandlets PowerShell.

Microsoft è l'aggiunta di funzionalità del controller SDN nel prossimo rilascio di Windows Server. Vedere Next Generation Networking nella prossima versione di Windows Server e altri video per TechEd Europe 2014 per ulteriori dettagli.

Ci potrebbero essere casi d'uso in cui si ha la necessità di un controller dedicato SDN (esempio: controllo ProgrammableFlow di NEC gestisce i flussi attraverso gli switch fisici e virtuali), ma se non si cerca una stretta integrazione fisico a virtuale (che non è esattamente una buona idea ), il controllore SDN sembra superfluo. Dopo tutto, tutto quello che dobbiamo fare è installare trasmissione di informazioni ( MAC-to-VTEP, IP-to-VTEP, ARP e voci di routing IP ) nelle interruttori morbide.

Guardando un quadro più grande, non abbiamo di calcolo o di storage controller dedicati sia (a meno che qualche marketer con troppo tempo sulle sue mani decide di rebrand vCenter), e se è vero che la rete virtuale rimane più complesso di stoccaggio o calcolare la virtualizzazione , Io ancora non ero convinto che ci sia un buon motivo per introdurre un controller di rete dedicata.

Che dire di cloud ibridi?

Sistema di orchestrazione Nube dovrebbe essere l'ultima fonte di verità: sa tutto di macchine virtuali (o contenitori), il loro IP e indirizzi MAC, subnet inquilino, regole di sicurezza, e forse anche caricare le regole di bilanciamento.

Questo paradigma si avvia la rottura verso il basso (almeno a livello di rete virtuale) in ambienti cloud ibridi - le macchine virtuali gestite da un sistema di cloud orchestration devono comunicare con gli endpoint non gestiti nella stessa rete inquilino. Non sarebbe bello avere un controller SDN che comunicare con le reti degli inquilini e lo scambio di informazioni di raggiungibilità con loro?

Non necessariamente - riflettere sulle implicazioni per la sicurezza di avere il controller SDN parlare direttamente con i clienti. Diversi fornitori evitare questo particolare vaso di Pandora eseguendo un'istanza di routing come appliance virtuale nello spazio inquilino.

Hyper-V utilizza il routing di default verso quella macchina (una soluzione rapida ed efficiente, che introduce un singolo punto di errore), gli scambi VMware NSX Edge Services Router informazioni con regolatore NSX che poi distribuisce attraverso switch virtuali di routing. In entrambi i casi, gli inquilini non hanno accesso diretto al controller o nuvola sistema di orchestrazione SDN.

Conclusione : non c'è urgente necessità di introdurre un controller SDN per sostenere cloud ibridi.

Nuvole federati

C'è un altro caso d'uso in cui un sistema di cloud orchestrazione non è abbastanza buono: le istanze di cloud federate dello stesso cloud privato o pubblico. Queste istanze devono avere informazioni di raggiungibilità end-to-end per implementare reti inquilino virtuali che coprono più di una zona disponibilità o regione, e perché si fidano implicitamente l'altro ha senso perfetto per implementare questo requisito con controller di rete che esegue una sorta di distribuito alla fine schema coerente raggiungibilità diffusione delle informazioni (anche conosciuto come un protocollo di routing ).

Venditori virtuali sovrapposizione smart concentrandosi su implementazioni su larga scala realizzati rapidamente i benefici di riutilizzo protocolli testati sul campo esistenti: Nuage Networks VSP, Juniper Contrail e recentemente Cisco Nexus 1000V usare MP-BGP (VPNv4 o famiglie di indirizzi EVPN) per distribuire informazioni di raggiungibilità.

VMware NSX e Microsoft Hyper-V attualmente non hanno soluzione equivalente. Le loro soluzioni di rete sono limitati a una singola istanza nuvola e si basano su apparecchi inquilino-spazio per allungare le reti virtuali tra più istanze - un'architettura funzionalmente equivalente a MPLS / VPN Inter-AS Opzione A (e noi tutti sappiamo quanto bene che una scala).

Stratificazione e Imballaggio

Infine, c'è un altro motivo di interporre un controller SDN tra il sistema di cloud orchestrazione e switch virtuali: confezione del prodotto. E 'più facile confezionare sovrapposizione di funzionalità di rete virtuale in un controller standalone e interagire con più sistemi nuvola di orchestrazione attraverso un sottile strato di colla (rete plugins come Neutron).

Maggiori informazioni

Che sto descrivendo sovrapposizione controller di rete virtuali e EVPN in VXLAN tecnica Deep Dive webinar.

La Scala Overlay Virtual Networking webinar (sponsorizzato da Nuage Networks, e quindi a titolo gratuito - registrati qui ) descrive l'uso di controller SDN in architetture scale-out, e scenari ad alta disponibilità comprese le zone delle disponibilità, le regioni e le nuvole federati.