COSTRUIRE UNA PICCOLA NUVOLA CON UCS MINI

Durante l'ultimo giro di lucidatura della mia Progettazione Infrastrutture per Private Clouds sessione Interop New York (disponibile anche in formato webinar ) Mi chiedevo se si potesse usare il lanciato di recente UCS Mini per costruire il mio campione cloud privato.

L' UCS 6324 tessuto di interconnessione fornisce più che sufficiente larghezza di banda: ogni modulo dispone di 80 Gbps di connettività uplink (per un totale di 160 Gbps) e 20 Gbps verso ogni server (per un totale di 40 Gbps di capacità di uplink per server).

I server blade sicuramente sembrano promettenti:

Fino a 24 core per blade, per un totale di 192 core per UCS Mini chassis - abbastanza probabilmente per eseguire ~ 1.000 macchine virtuali;

Fino a 768 GB di RAM per blade, per un totale di oltre 6 TB di RAM per chassis - ancora una volta, più che sufficiente per ~ 1.000 macchine virtuali

... E poi mi sono imbattuto su le specifiche del disco : due dischi, il più grande è di 1 TB (HDD) o 800 GB (SSD), per un totale di 8 TB di archiviazione ridondante per chassis. Meh.

Stephen Foskett trovato un modo interessante a questo problema : aggiungere un server di C3160 cremagliera per un totale di 360 TB di storage. In alternativa, utilizzare due server rack C240 M3, collegarli al tessuto di interconnessione, e roba pieno con unità disco (fino a 24 unità disco 1,2 TB per server per un totale di 28,8 TB di storage su disco completamente ridondante).

E ora per la domanda difficile: come si fa a fare i server di storage accessibili ai nodi di calcolo? Qui ci sono alcune idee:

Se si prevede di utilizzare OpenStack, eseguire Ceph o Gluster sui nodi di storage e le destinazioni iSCSI o NFS fare. Problema risolto;

Se sei un utente di Hyper-V, non si dispone di un problema. Windows Server dispone di tutti i componenti necessari;

vSphere è un osso più duro (è evidente che società madre di VMware è): è possibile utilizzare una delle idee che ho citato sopra per costruire un sistema di storage distribuito tale host vSphere potrebbe collegarsi a tramite iSCSI o NFS, ma che puzza chiaramente di fatto in casa kludgeitis.

VSAN potrebbe essere un'alternativa, ma non sono sicuro di quanto bene si comporta in un ambiente dove la maggior parte del traffico disco virtuale passa attraverso la rete LAN. Commenti molto apprezzati!

Webinar correlati

Progettazione di Private Cloud Infrastructure copre numerose opzioni di progettazione, comprese le soluzioni di storage scale-out. Virtualizzazione e Data Center webinar discutono i singoli tecnologie si potrebbe considerare nella progettazione di infrastrutture di cloud (e si può sempre me impegnarsi se avete bisogno di una revisione di design, tecnologia discussione, o un secondo parere).

SCHPROKITS CON JEREMY SCHULMAN SU SOFTWARE GONE WILD

Jeremy Schulman è stata la forza trainante dietro l'agente delle marionette che Juniper implementata su alcuni interruttori Junos (una delle prime implementazioni completamente supportate Puppet-on-a-switch). Nel frattempo, ha lasciato Juniper e ha iniziato la sua società focalizzata su un prodotto di automazione di rete - più che sufficienti motivi per chiacchierare con lui su Software Gone Wild .

Non abbiamo potuto fare a meno di cominciare con l'agente Puppet on Junos:

Perché Juniper ha creato un agente Puppet su un interruttore?
Perché è stato limitato alla creazione di VLAN?
Come è possibile limitare i cambiamenti uno strumento di automazione in grado di innescare?
Perché Junos API equivale a digitare manualmente i comandi?
Jeremy ci ha anche detto molto circa il suo nuovo bambino:

Che cosa è Schprokits?
Quali sono le idee di base e gli impieghi concetti Schprokits?
Quanto è Schprokits diverso da Puppet, Chef & Co? Come è diverso da NCS Tail-f?
Quali fornitori supporta? Come orribile sono le loro API?
Perché è (tra le altre cose) un ulteriore strumento di costruzione di modello?
Come si Schprokits ridurre il divario di esecuzione ... e qual è il divario di esecuzione?
Ritiene Schprokits hanno un demo OpenStack e perché suona quella domanda come le tartarughe fino in fondo?
Quando vedremo il prodotto? Posso scaricare e giocare con lui?
Sarà Schprokits essere un prodotto open-source? Qual è la strategia di go-to-market?
Infine, non abbiamo potuto resistere a scendere un intero campo di fori di coniglio:

Qual è la differenza tra DevOps e NetOps?
Che cosa è un raggio di esplosione e perché è importante?
Perché è difficile da usare strumenti di gestione della configurazione, come Chef, Puppet o Ansible in rete?
Che cosa è YAML e perché è meglio di JSON o XML?
Perché screen scraping un'idea davvero terribile?
Qual è l'architettura di disaccordo in rete?
Perché saremo mai d'accordo su API nord?
Perché "abbiamo un API per farlo" non sempre la risposta giusta?
Che cosa significa "idempotente" media ... e ne abbiamo davvero dovuto imparare tutte queste nuove parole folli?

DINAMICA FCOE - SPARSE MODE FCOE STRIKES AGAIN

Qualche tempo fa, Cisco ha aggiunto dinamica FCoE supporto per Nexus 5000 switch. Sembrava interessante e ho voluto parlarne nel mio Data Center Tessuti sessione di aggiornamento, ma non ho potuto trovare alcuna documentazione in quel momento.

Nel frattempo, la Configurazione dinamica FCoE Utilizzando FabricPath guida di configurazione apparso sul sito web di Cisco e J Metz ha scritto un post sul blog lengthly spiegare come funziona il tutto , innescando un grave attacco di déjà vu.

Ho chiamato l'approccio tradizionale di Cisco per multi-hop FCoE dense-mode FCoE - ogni switch della rete è un Fibre Channel Forwarder (FCF - equivalente Fibre Channel di un router) con un ID univoco di dominio che partecipano a FSPF.

Tony Bourke ha scritto un messaggio ancora più strutturata blog su topologie FCoE multihop . Sicuramente vale la pena di leggere.

Dinamica FCoE è l'implementazione di Cisco sparse-mode FCoE (si noti che il mio post sul blog descrivendo che è di quattro anni) - gli interruttori foglia (Nexus 5000s) sono FCFS, core switch forniscono layer-2 di trasporto basato FabricPath-tra gli interruttori foglia. Non c'è davvero nulla di nuovo sotto il sole;)

Fa senso dinamico FCoE trucco? Dipende. Se siete disposti a fidarsi del tessuto Transport Layer-2 e trattare archiviazione come ancora un'altra applicazione in cima Ethernet + IP, dinamico FCoE perfettamente senso, ma di tenere presente che avrete più visibilità in tessuto di trasporto sottostante come con iSCSI o NFS ... o sovrapporre reti virtuali.

Maggiori informazioni

FCoE è solo uno dei tanti argomenti descritti nella sezione di stoccaggio del mio Data Center 3.0 per Networking Ingegneri webinar .

IPV6 NEIGHBOR DISCOVERY (ND) E MULTICAST LISTENER DISCOVERY (MLD) SFIDE

Pochi giorni fa Garrett Wollman pubblicato la sua esperienza esasperante esecuzione IPv6 su grandi sottoreti L2 con switch Juniper EX4200 , concludendo che " ... tanto nella progettazione e implementazione di IPv6 è stata pasticciata dai progettisti di protocollo e fornitori ... "(alcuni di noi sarebbero d'accordo con forza) fare IPv6 " ... semplicemente non sicuro per l'esecuzione su una rete di produzione ... "

Il dibattito risultante su Hacker News è molto interessante (e Andrew Yourtchenko sta provando duramente per tenerlo vicino ai fatti) e sicuramente la pena di leggere ... ma è ND / MLD davvero come rotto come alcune persone sostengono che è?

Che cosa? Cosa multicast?

Solo nel caso in cui non hai familiarità con gli intricati dettagli di IPv6: MLD sta per Multicast Listener Discovery, e se si vuole chiedere, "perché devo multicast per ottenere prossimo scoperta", non siete soli. Dopo tutto, ARP in IPv4 funziona abbastanza bene con la trasmissione indirizzo MAC ... o così la gente pensa fino a quando sono di fronte a una realtà di una tempesta in onda su un IPv4 sottorete di grandi dimensioni.

Ho sentito parlare di gente che corre 10K + host nella stessa sottorete. Cerchiamo di essere diplomatico e dire che sono un po 'di stretching i limiti di progettazione di Ethernet e rete IPv4.

Progettisti protocollo IPv6 hanno cercato di risolvere il problema di ogni host sulla sottorete coinvolto in lavorazione ARP, utilizzando una serie di L2 + L3 gruppi multicast. Indirizzo IPv6 viene assegnata in un indirizzo IPv6 multicast (che è ulteriormente memorizzato nella cache in un indirizzo MAC multicast), e le query ND (richieste ARP in IPv4 gergo) sono inviati al multicast IPv6 / MAC indirizzo multicast associato con l'indirizzo IPv6 di destinazione, invece della trasmissione dell'indirizzo MAC. Troverete maggiori informazioni nella RFC 4861 e nei miei webinar IPv6 .

In una rete ben progettato con pile ospitanti correttamente implementate utilizzando schede di rete che sono in grado di filtri multicast basati su hardware, l'idea in realtà riduce il carico inutile finali padroni di casa.

Hai fatto notare i numerosi condizionali nel paragrafo precedente, vero?

Andando un passo avanti, i progettisti del protocollo hanno cercato di ridurre il carico di collegamento su reti commutate L2 - snooping MLD (quasi identica alla IGMP snooping) permette L2 passa per ottimizzare la struttura di distribuzione per gli indirizzi MAC multicast, fornendo le query ND solo per i padroni di casa che li aspetta (senza MLD snooping, le query ND vengono consegnati a tutti gli host e filtrati da NIC).

Se si desidera MLD snooping a lavorare, si deve ovviamente spingere i padroni di casa a riferire ciò che si aspettano di ricevere - un router IPv6 collegato a una sottorete L2 deve generare query periodiche MLD per aiutare gli switch L2 scoprono host terminali multicast abilitato.

Cosa è andato storto?

E 'difficile capire che cosa esattamente è andato storto con la rete CSAIL, perché stiamo probabilmente manca un sacco di dettagli, ma ci sono un paio di conclusioni facili da fare:

Un design con numerose VLAN diffuso in tutto il luogo e collegato ad un unico insieme di L3 switch è un dominio guasto singolo (non ho potuto resistere a scrivere questo in giù);
Non prendetevela con il protocollo, se il fornitore manca di funzionalità di parità sulle caratteristiche basali graziosi, o è in ritardo nella loro attuazione. Diversi commenti sull'articolo originale hanno menzionato utilizzando DHCPv6 per sbarazzarsi di più indirizzi privacy IPv6 per host, ma naturalmente è necessario un relè di lavoro DHCPv6 per questo;
Non prendetevela con il protocollo quando si colpisce bug di implementazione;
Implementazione di IPv6 è come qualsiasi altra grande diffusione delle nuove tecnologie: fare un disegno corretto, eseguire un progetto pilota, e poi gradualmente distribuire la nuova tecnologia (in attesa di alcuni problemi sulla strada). Tutti coloro che hanno frequentato il mio Enterprise IPv6 101 webinar è ben consapevole di questo;)
Non aspettatevi di girare solo su IPv6 se si sta già allungando i limiti delle vostre tecnologie esistenti o dalla vostra attrezzatura (vedi anche questa e-mail se avete bisogno di una buona dose di sarcasmo).
Aspettatevi di fare qualche messa a punto in sede di attuazione disegni che sono al di fuori di utilizzo "normale" (per qualsiasi valore di "normale"). Non ci si aspetterebbe di eseguire 1.000 router in un'area OSPF senza qualche pesante Sintonia-Fu, vero?
Piattaforme anziane con 0,02 dollari CPU potrebbe ottenere sovraccaricato durante l'elaborazione MLD risponde (supponendo ho capito bene i numeri da il post sul blog, EX4200 ha incontrato problemi a circa 300 MLD risponde al secondo);
Protezione di controllo-piano (Copp) - ammesso che funziona per IPv6 sulla vostra piattaforma - è lì per un motivo;
Sovraccarico della CPU (o qualsiasi altro controllo-plane problema tecnico) si tradurrà in STP composizione e inoltro loop (suggerimento: MLAG potrebbe aiutare - almeno non sarà possibile ottenere i loop di inoltro);
Controllare le dimensioni delle tabelle dei vostri interruttori durante il controllo di disponibilità IPv6 (si ha intenzione di fare una verifica prima della distribuzione IPv6, vero?). EX4200 non è uno dei peggiori delinquenti - EX4500 e EX4550 avere solo voci 1K IPv6 ND (tutti e tre gli interruttori hanno anche dimensioni delle tabelle di inoltro IPv6 tristi).
Troverete dimensioni delle tabelle per la maggior parte degli switch data center prodotte dai principali produttori (tra cui serie EX di Juniper) nel mio Data Center Tessuti webinar.

Sul tema delle dimensioni delle tabelle:

Avete bisogno ND ingresso in uno switch L3 per ogni indirizzo attivo (attivo = comunicazione con lo switch L3) su ogni host IPv6 - che sarebbe di almeno 2 indirizzi per host, e potenzialmente molti di più a causa del modo in cui alcuni dispositivi mobili implementano privacy estensioni;
Non dovrebbe essere necessario una voce IPv6 multicast per ogni gruppo multicast ND - dopo tutto, questi gruppi sono link-local, quindi non c'è bisogno di switch L3 per mantenere il loro stato.
Allo stesso modo, gli switch L2 NECESSARIO NON utilizzare le voci IPv6 (ammesso che li hanno) per i filtri multicast IPv6; come sono switch L2, devono utilizzare lo stesso multicast MAC hardware inoltro usano per IPv4 (o qualsiasi altro protocollo).
Su una nota tangenziale, non sto sostenendo che gli indirizzi di privacy e numerosi indirizzi per l'interfaccia sono l'idea migliore mai. Allo stesso modo, io non sono esattamente un fan di SLAAC in reti aziendali strettamente controllati, ma queste opinioni non sono esattamente pertinente nel contesto di questo post del blog.

Soluzioni alternative

Se tutto il resto fallisce, è il momento per una bravata MacGyver (nota: non farlo a casa). Se non si sta utilizzando MLD snooping su switch L2, non c'è bisogno di query MLD frequenti - cambiare MLD intervallo di query a qualsiasi valore massimo possibile.

Inoltre, se non si utilizza IPv6 multicast, non vedo alcuna necessità di eseguire MLD sulla LAN - spegnerlo se è possibile ... o forse mi manca qualcosa di ovvio, in questo caso potete scrivere un commento.

Per ulteriori informazioni su IPv6 multicast, ND e MLD, passare attraverso questa presentazione . Si noti inoltre che non avremmo questo problema se vogliamo usare L3-solo inoltro IPv6 .

Tags: IPv6 , LAN
email
Etichette:
Condividi su Twitter
Condividi su Facebook
Ivan Pepelnjak, CCIE # 1354, è il consigliere tecnologia principale per NIL Data Communications . Egli progetta e implementazione di reti di comunicazione di dati su larga scala, nonché l'insegnamento e la scrittura di libri su tecnologie avanzate dal 1990 Vedere il suo profilo completo , contattare lui o seguireioshints su Twitter.
POSTS RELATED PER CATEGORIE

IPv6
Se qualcuno usa DMVPN-over-IPv6?
Perché IPv6 layer-2 di sicurezza così complessa (e come risolvere il problema)
Vantaggi di SDN (o: SDN è come IPv6)
Risorse IPv6 su ipSpace.net
Risoluzione dei problemi di connettività residenziale IPv6
IPv6-unico centro di distribuzione dei dati
Facebook è vicino ad avere un solo IPv6 Data Center
Cisco IOS supporta RFC 6106 (RDNSS)
Siamo tutti fratelli su Link-Local
LAN
First-Hop Security IPv6 Caratteristiche in Cisco IOS
VRRP, Anycasts, Tessuti e ottimale Forwarding
VLAN sono l'astrazione sbagliato per il networking virtuale
Dove è la mia VLAN provisioning?
Che cosa hai fatto per sbarazzarsi di manuale VLAN provisioning?
IPv6 di Neighbor Discovery sicura (SEND)
VXLAN e OTV: Sono stato fregato
QFabric Lite
Networking virtuale è più di macchine virtuali e VLAN nastro adesivo

MIGLIORAMENTI DELLA SCALABILITÀ A CISCO NEXUS 1000V

L' ultima versione di Cisco Nexus 1000V per vSphere in grado di gestire il doppio di molti host vSphere come il precedente (250 invece di 128). Cisco probabilmente ha fatto un sacco di codice lucidatura per migliorare Nexus 1000V scalabilità, ma io sono positivo la maggior parte del miglioramento deriva da cambiamenti architettonici interessanti.

NetFlow distribuita:

Con Distribuito NetFlow, lo switch invia i pacchetti di esportazione di NetFlow direttamente dai VEMS ai collezionisti. Non è più invia i pacchetti di esportazione attraverso l'interfaccia mgmt0 VSM, migliorando significativamente la scalabilità ( fonte ).

IGMP Multicast offload:

Prima della 5.2 (1) SV3 (1.1), i moduli VEM dipendevano VSM per supportare IGMP multicast. Da 5.2 (1) SV3 (1.1), VEMS può eseguire il rilevamento IGMP Mrouter, membro inoltre IGMP, e la cancellazione senza supporto VSM ( fonte ).

Poi c'è la distribuzione VXLAN MAC :

Distribuzione MAC utilizza unicast per distribuire MAC, riducendo in tal modo i messaggi di aggiornamento MAC e migliorare la bilancia ( fonte ).

Infine, non posso correre centralizzata (con sede a VSM) LACP più:

Nella Release 5.2 (1) SV3 (1.1), solo LACP offload di VEM è supportato ( fonte).

E 'abbastanza facile da individuare il modello. Ogni miglioramento scalabilità spinto alcuni aspetti del piano di controllo centralizzato in elementi di commutazione distribuite, ben dimostra il punto che ho fatto pochi giorni prima del Nexus 1000V 3.1 lancio: centralizzato di controllo dei limiti aereo scalabilità (nota: non avevo idea circa l'imminente lancio del prodotto - Cisco smesso di me il briefing qualche tempo fa, probabilmente intorno al tempoche ho trovato interessante NSX ).

Sono una persona positiva riuscirà a dimostrare che questo ragionamento non si applica al suo controllore preferito OpenFlow. La gente è anche riuscito a dimostrare che la Terra deve essere piatta .

INFRASTRUTTURA DI RETE COME DATABASE

Qualche tempo fa ho scritto circa l'idea di trattare infrastrutture di rete (e tutte le altre infrastrutture) come codice , e utilizzando gli stessi sviluppatori di applicazioni di processi stanno usando per scrivere, testare e implementare il codice per progettare e realizzare reti.

Questo approccio funziona bene chiaramente se è possibile virtualizzare (e clone all'infinito) tutto. Siamo in grado di virtualizzare elettrodomestici o anche router, ma le attrezzature installate e infrastrutture fisiche ad alta velocità rimangono alquanto resistente a tale idea. Abbiamo bisogno di un paradigma diverso, e la migliore analogia che potevo venire con è un database.

Immaginate un'organizzazione che ha bisogno di un grande database transazionale per eseguire la propria attività, e richiede agli operatori di prima linea per modificare i dati in quel database con istruzioni SQL (INSERT, UPDATE, DELETE). Non ho mai sentito di nessuno essere anche solo lontanamente quella stupida - ma è così che la maggior parte di noi gestiscono nostre reti. Il tempo di prendere un'altra lezione dal mondo, lo sviluppo di applicazioni.

E 'ovvio che si debba interagire con un database di produzione solo attraverso operazioni ben definite ed accuratamente testati (se li chiami transazioni , programmi applicativi o script web è irrilevante). CLI (SQL) Accesso diretto al database dovrebbe essere vietato o limitato al minimo assoluto.

Allo stesso modo, dobbiamo modificare i nostri dispositivi di rete con operazioni ben definite (esempio: CREATE VLAN o RIMUOVERE VLAN ). Tali operazioni (loro script, Playbook o ricette chiamare se lo si desidera) devono essere trattati come qualsiasi codice dell'applicazione, e testati in un ambiente di laboratorio prima di poter toccare la rete di produzione.

E ora per la consueta serie di obiezioni:

Ma non mi fido script . Fantastico. Ora dimmi: è meglio fare affidamento su qualcosa che è testato e ripetibile, o fare modifiche di configurazione al volo sperando per il meglio?

Come faccio a sapere che funzionerà? Benvenuti nel mondo dello sviluppo software. Scrivere il codice, includere test di unità e di integrazione, testare tutto, distribuire in un ambiente pilota, e infine in produzione. Schiuma, sciacquare, ripetere.

Ma potrebbe rovinare le mie configurazioni . E pensi che nessuno mai incasinato loro database? Abbiamo backup per una buona ragione - e la maggior parte delle apparecchiature di rete dispone di alcuni meccanismi di versioning configurazione e rollback.

Ma potrebbe andare in crash il mio interruttore . Potrebbe. Sistemi di database hanno i loro bug, e io sono positivo sono stati in grado di mandare in crash alcuni database con dati non validi o richieste strane a pochi decenni fa ... ma indovinate un po ': se non cominciamo a urlare ai fornitori, e votano con i nostri portafogli, non accadrà nulla cambiare.

Che dire di finestre di manutenzione? Dobbiamo usare le finestre di manutenzione nelle reti attuali, perché non possiamo fidarci del processo di configurazione manuale. Quando è stata l'ultima volta che si potrebbe fare la transazione di e-banking solo alle 2 del mattino in una mattina di Domenica? Una volta che tutti cominciano confidando le operazioni di configurazione della rete, sarete in grado di utilizzarli in qualsiasi momento.

Avete incontrato altri obiezioni? Scrivi un commento!

Infine, si potrebbe decidere che la rete non è abbastanza grande da giustificare una soluzione di automazione di rete (o che non hanno la manodopera per lavorare su di esso). La prossima cosa migliore che potrebbe fare è disaccoppiamento : spostare le parti dinamiche della vostra infrastruttura di rete nel mondo virtuale in cui è possibile trattare sia come codice , e mantenere la parte fisica della vostra infrastruttura di rete statica possibile.

Corso Cisco - Corso CCNA - Corso Security - Corso CCNA Security - Certificazione Cisco - CCNA 200-120 Corso CCNP