Non mi aspettavo che avremmo visto multi-vendor OpenFlow deployment in qualunque momento presto. NEC e IBM hanno deciso di cambiare la situazione e Tervela , azienda specializzata nella costruzione di messaging basati su tessuti di dati , ha deciso di verificare le loro richieste di interoperabilità. Janice Roberts che lavora con NEC Corporation of America mi ha aiutato a entrare in contatto con loro e sono rimasto piacevolmente sorpreso dalla loro visione ottimistica della diffusione OpenFlow nelle reti aziendali tipici .
Un po 'di sfondo
Dati Tervela soluzioni di tessuto in genere eseguiti sulla parte superiore delle infrastrutture di rete tradizionale, e una rete poco efficiente (in particolare interruzioni lunghe innescati da non ottimali implementazioni STP) possono influenzare negativamente il comportamento dei servizi in esecuzione sulla loro piattaforma.
Stavano cercando una soluzione che avrebbe compiuto il modo migliore di ciò che i clienti sono in genere utilizzando oggi (grandi layer-2 reti), mentre allo stesso tempo, essendo facile per la progettazione, la fornitura e la gestione. Sembra che hanno trovato una valida alternativa alle reti esistenti in una combinazione di NEC ProgrammableFlow controller e IBM BNT 8264 switch .
Facile da distribuire?
Fino a quando la rete non è troppo grande (NEC rivendicato il loro controller può gestire fino a 50 switch nella loro presentazione sul campo Tech Day Networking ), la progettazione e la distribuzione non è troppo difficile, secondo gli ingegneri Tervela di:
- Hanno deciso di utilizzare out-of-band rete di gestione e collegato alla porta di gestione del BNT8264 alla rete di gestione (potrebbero anche utilizzare qualsiasi altra porta interruttore).
- Tutto quello che dovete configurare l'interruttore individuo è il VLAN di gestione, un indirizzo IP di gestione e l'indirizzo IP dei controllori OpenFlow.
- Il controller ProgrammableFlow rileva automaticamente la topologia di rete utilizzando i pacchetti LLDP inviati dal controllore attraverso le interfacce switch individuali.
- Dopo queste operazioni di base, è possibile avviare la configurazione di reti virtuali nel controller OpenFlow (vedi demo NEC effettuati durante il giorno Tech Campo Networking ).
Ovviamente, ci si vuole seguire alcune regole di progettazione di base, ad esempio:
- Effettuare la gestione della rete completamente ridondante (leggere la documentazione QFabric per vedere come è fatto correttamente);
- Collegare gli interruttori in una struttura un po 'simile ad un tessuto Clos, non in un anello o un pasticcio casuale di cavi.
I risultati dei test - Latenza
Tervela gli ingegneri gestiva una serie di test, concentrandosi principalmente su latenza e il recupero fallimento.
Hanno scoperto che (come previsto) il primo pacchetto scambiato tra un paio di VM sperimenta un millisecondo di latenza 8-9 perché è trasmesso attraverso il controller OpenFlow, con i pacchetti successivi hanno latenza non erano in grado di misurare (il loro strumento è dotato di 1 msec risoluzione).
Lezione # 1 - Se le prime questioni di latenza dei pacchetti, utilizzare proattiva modalità di programmazione (se disponibile) per pre-popolare le tabelle di inoltro degli interruttori;
Lezione # 2 - Non fare un pieno di 12 tupla ricerche se non assolutamente necessario.Che ci si vuole sperimentare la latenza solo quando l'inter-VM comunicazione non inizia, per ogni TCP / UDP di flusso (per non parlare che cattura ogni flusso in un ambiente di data center è una ricetta sicura per il disastro ).
I risultati dei test di recupero - Mancata
Molto veloce il ripristino di errori è stata un'altra piacevole sorpresa. Hanno testato solo lo scenario di base (collegamenti in parallelo primarie / backup) e ha scoperto che nella maggior parte dei casi il traffico passa alla secondo link in meno di un millisecondo, indicando che NEC / IBM ingegneri hanno fatto un ottimo lavoro e pre-popolato l'inoltro tabelle con le voci di backup .
Se ci vogliono 8-9 millisecondi per il controller di programmare un unico flusso negli switch (vedi la latenza sopra), è assolutamente impossibile che lo stesso controllore avrebbe fatto una riprogrammazione enorme per le tabelle di inoltro in meno di un millisecondo . La risposta fallimento deve essere stato programmato nelle tabelle di inoltro.
Ci sono stati alcuni valori anomali pochi (10-15 secondi), probabilmente causate dalla mancanza di rilevamento degli errori sul livello fisico. Come ho scritto prima, rilevando errori di collegamento tramite pacchetti di controllo inviati da OpenFlow controller non scala - hai bisogno di protocolli distribuiti Linecard (LACP, BFD) se si desidera disporre di una soluzione scalabile.
Infine, supponendo che il loro banco di prova ha permesso il controller ProgrammableFlow per precompilare le voci di backup, sarebbe interessante osservare il comportamento di un quattro-nodo di rete quadrato, dove è impossibile trovare un loop-free percorso alternativo a meno di utilizzare circuiti virtuali come MPLS Reroute veloce fa.
I risultati dei test - l'allocazione di banda e di ingegneria del traffico
Una delle cose interessanti OpenFlow dovrebbero permettere sia la larghezza di banda-aware routing flusso. Tervela gli ingegneri sono stati un po 'delusi per scoprire il software / hardware combinazione che stavano testando non soddisfa tali aspettative ancora.
Sono stati in grado di riservare un link per traffico ad alta priorità e osservare il bilanciamento automatico del carico tra percorsi alternativi (che sarebbe impossibile in un STP-based network layer-2), ma non erano in grado di configurare le statistiche-based routing (importante via flussi attraverso collegamenti sottoutilizzate).
I prossimi passi?
Tervela gli ingegneri ha detto che i risultati del test li ha resi fiduciosi nella soluzione OpenFlow da NEC e IBM. Hanno in programma di eseguire i test più approfonditi e se tali risultati di prova elaborare, inizieranno raccomandando OpenFlow soluzioni basate su un Proof-of-Concept-level alternativa ai loro clienti.
Nessun commento:
Posta un commento
Nota. Solo i membri di questo blog possono postare un commento.