RAPIDA PEEK: JUNIPER VMX ROUTER

intelligenti che vanno fino a 200 Gbps. Guardando la scheda VMX sembra Juniper ha un certo numero di cose giuste:

Essi disaccoppiati controllo e gli aerei spedizione in separata VM (probabilmente devono ancora eseguire sullo stesso host fisico, ma questo rende più facile dedicare core CPU a singole funzioni);
Trasmissione aereo virtuale utilizza SR-IOV e Intel DPDK, i crediti di performance non sono del tutto irrealistico.
Mi piace anche il loro approccio di licenza: Stai acquistando licenze (perpetue o annuali) a intervalli di 100 Mbps, 1 Gbps e 10 Gbps, che (spero) significa che è possibile effettuare il router virtuale più veloce (o lento), come si bisogno di essere, soprattutto se è possibile trasferire le licenze tra più istanze VMX.

Sarà VMX portare la morte di router fisici? Sarà sicuramente sostituire i router fisici in ambienti di service provider che decidono di utilizzare NFV (esempio: Deutsche Telekom Terastream ), ma poi VMX era l'unica cosa che poteva fare Juniper in quegli ambienti per competere con Cisco e Brocade.

Io non sono così sicuro circa il bordo WAN aziendale. Come Matt Bolick sottolineato durante la Tech Field Day @ Interop New York , tutti i disegni di server per un ciclo di vita di 2 anni, mentre i router edge WAN in genere hanno per sopravvivere 5-10 anni, e io sono positivo acquirenti intelligenti aziendali sanno che ( indipendentemente da quello che dicono a vari eventi Qualcosa-Open-qualcosa).

Ulteriori informazioni

Imparerete di più su router virtuali, appliance e NFV nel mio laboratorio SDN / NFV / SDDC ( piattaforma scorrevole è già a disposizione degli abbonati , le registrazioni saranno pubblicati nel 2014).

FATE ABBIAMO TROPPE MANOPOLE?

L'ultimo giorno di Interop New York mi trovò seduto nel Centro Speaker con alcuni amici meditando la campagna pubblicitaria e la realtà della SDN e brokenness di prodotti di rete tradizionali. Una delle osservazioni durante quella conversazione era molto familiare: "abbiamo troppe manopole per configurare ", e ho risposto" e quante manopole pensi che ci sono nel registro di Windows? (o file del kernel e la configurazione di Linux) ".

Non trovo i moderni sistemi operativi meno complessi rispetto ai dispositivi di rete, e sono sicuro che ci sono persone che si lamentano troppe manopole uno ha bisogno di girare per la configurazione del kernel di Linux (per non parlare della meravigliosa sintassi iptables ), ma la maggior parte persone riescono a fare questi lavori i sistemi operativi. Il trucco: maghi e interfacce di configurazione semplificate.

Parlando di Linux, iptables sembra essere un esempio perfetto (o sendmail , ma sono anche a conoscenza che la sintassi arcana - ho portato a decenni di MS-DOS fa come il nucleo di un prodotto di e-mail che abbiamo scritto in quei giorni). So che iptables sono uno strumento estremamente potente, ma non ho mai preso il tempo per studiarli. Ogni volta che ho bisogno di configurare un firewall su una macchina Linux che uso system-config-firewall. Mi dà un elenco di servizi comuni che potrei essere in esecuzione sulla mia macchina, e mi permette di abilitare o disabilitare l'accesso ad essi.

Perché non possiamo avere una procedura guidata di configurazione simile per gli switch data center? Perché dobbiamo per ottenere la giusta combinazione di parametri STP-correlati?Qualcuno la distribuzione di una nuvola tipica impresa (che a mio avviso non ha bisogno di più di due interruttori Tor) dovrebbe essere in grado di specificare-server fronte link, uplink, VLAN e sottoreti, e ottenere una configurazione ottimizzata per quel particolare disegno (solo L2, L3 o solo mista L2 + L3). Tutte le manopole sarebbe ancora lì, e saresti ancora in grado di configurare lo switch in qualsiasi modo si desidera utilizzare la CLI o API, ma non avrebbero più bisogno di un CCIE per ottenere il diritto di base.

Perché non possiamo configurare OSPF con una procedura guidata? Specificare il numero di switch nella rete (la procedura guidata potrebbe rinunciare e dire per ottenere un esperto se dici avrai più di 50 o giù di lì), specificare il bordo (stub) e collegamenti di transito, le interfacce WAN e LAN ( per regolare i timer OSPF) e il gioco è fatto.

Un altro dei miei preferiti di vita reale: avete mai provato la configurazione di nomi utente e password per l'autenticazione WPA2 su Cisco punto di accesso wireless utilizzando la loro meravigliosa interfaccia grafica? Si può fare, ma non c'è un modo semplice per capire come farlo (suggerimento: avete bisogno di server RADIUS locale sulla scatola, e funziona su porte non standard per rendere i vostri sforzi di risoluzione dei problemi più interessante), e la GUI ottenere con la scatola è solo un piacere per gli occhi abbastanza inutile in cima manopole di configurazione. Non ho bisogno di manopole di configurazione presentati in un browser Web, ho bisogno di un'astrazione che mi permette di pensare in termini di ciò che ho bisogno di ottenere fatto, e tradurlo in quale dispositivo vuole vedere per farlo fare.

Vedremo mai maghi come questo? In base a quello che ho visto fino ad ora, rimango scettico.La maggior parte dei fornitori di rete in modo rapido vengono infettati da casi featuritis e angolo - invece di cercare di capire che cosa funziona per l'80% dei clienti, che cercano di affrontare tutti i casi angolo là fuori - e la maggior parte dei prodotti per la gestione della rete (il luogo ideale per le procedure guidate di configurazione) dimostrare la sezione 2.4 della RFC 1925 . Sembra che abbiamo davvero bisogno di un Steve Jobs di rete .

Sono troppo pessimista? Hai visto qualcosa che funziona davvero? Si prega di condividere nei commenti.

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.

UTILIZZARE UN PROGETTO DI DISASTER RECOVERY PER COSTRUIRE IL TUO NUOVO NUBE

Introduzione
Non ha senso costruire una nuova rete di data center a supporto legacy infrastruttura server bare-metal. Dovrete utilizzare relativamente costosi porte 1G / 10G di essere in grado di connettersi ai server attuali e future, e una volta che gli ingegneri di server e virtualizzazione si svegliano e fanno hardware aggiorna vi ritroverete con troppi porti (oh, e tu sai che ricetrasmettitori potrebbe costare più che l'hardware di commutazione, giusto?).

Nel caso ideale, devi costruire una nuova infrastruttura con server ad alta densità, 100% del carico di lavoro virtualizzato ... e poi tutto quello che avresti bisogno sarebbe due interruttori 1RU o 2RU ToR . Purtroppo la maggior parte delle aziende non riescono a trovare il loro percorso da qui a lì a causa di tonnellate di burocrazia interna (aka budget e periodo di ammortamento ).

Eric Hanselman (451 Research) ha fornito un modo interessante di questo Comma 22 durante uno dei pannelli di interoperabilità:

Avviare un disaster recovery progetto;
Affittare uno spazio in un impianto di colocation ( hat tip a Rick Parker );
Costruisci la tua infrastruttura di disaster recovery laggiù;
Spostare il carico di lavoro, dichiarare il successo, e spegnere l'infrastruttura legacy;
Avviare un altro progetto di disaster recovery;)
Ovviamente ci si vuole la nuova infrastruttura di essere il più lungimirante come la vostra organizzazione si sente a proprio agio. i server ad alta densità (ciascuno di essi ospita 50 - 100 VM) sono un gioco da ragazzi, virtualizzati servizi di rete gli apparecchi sono già una vendita più difficile perché potrebbero richiedere cambiamenti nei processi e delle responsabilità , se si vuole fare nel modo giusto, e il file system distribuito (come Nutanix o VSAN ) potrebbe rivelarsi una missione impossibile, perché, si sa, lo stoccaggio .

Maggiori dettagli

Aspetti di progettazione della moderna infrastruttura cloud sono coperti nel mio Infrastrutture Progettazione Private Cloud webinar e Data Center di design Case Studies libro (incluso con il webinar); altre infrastrutture Cloud e SDDC webinar vi darà i dettagli della tecnologia di cui ha bisogno per capire i compromessi di progettazione. Sono disponibili anche per brevi sessioni di consulenza revisione / design .

Infine, se avete voglia di aspettare un anno e mezzo, goccia a Interop Las Vegas e assistere alla mia concezione di infrastrutture per cloud privati ​​officina .