I TOPI, ELEFANTI E SWITCH VIRTUALI

I topi ed elefanti è un QoS tradizionali favola - traffico in tempo reale sensibile alla latenza (o protocollo di richiesta-risposta come HTTP) bloccato nella stessa coda dietro megabyte di trasferimento di file (o di backup o iSCSI) il traffico.

La soluzione è anche ben noto - colorare il elefanti rosa (aka DSCP) e ordinarli in una coda diversa - fino a quando la realtà interviene.

Sembra oh-così-impossibile capire quali applicazioni possono generare flussi di elefante e segnare di conseguenza sul server di origine; non c'è altro modo per spiegare la necessità di classificazione del traffico e la marcatura sull'interruttore ingresso, e altri aggeggi MacGyver la squadra messa in rete utilizza per assicurarsi che "non è colpa della rete" invece di dire " noi siamo un programma di utilità - che stai ricevendo esattamente quello che hai chiesto. "

TCP e UDP numeri di porta sul server di corrispondenza (perché le sessioni FTP tendono ad essere più elefantiaco di richieste DNS) e impostare valori DSCP dei pacchetti in uscitaè anche, ovviamente, una missione impossibile per alcune persone; è modo più facile far finta che il problema non esiste e la colpa la rete per mancanza di una corretta classificazione del traffico.

Bisogna chiedersi quanto bene la recente ondata di soluzione di networking application-aware passeranno se le squadre di server / applicazione non può essere preso la briga di raccontare la rete che tipo di traffico è di fronte impostando un valore a un byte semplice in ogni pacchetto, ma cerchiamo di non andare lì.

In ogni caso, la situazione peggiora in ambienti con traffico davvero inclassificabile (come l'abominio ultimo immaginare una soluzione che fa i backup su HTTP), dove è impossibile elefante separato dai topi in base ai loro numeri di porta TCP / UDP.

Se, tuttavia, si avrebbe spaccato buffer TCP del sistema operativo, o misurare la frequenza per-flow, si potrebbe essere in grado di capire che scorre esporre le tendenze in sovrappeso - e questo è esattamente ciò che il team di Open switch virtuale (OVS) ha fatto .

Inoltre, OVS appare come un offload con capacità TCP NIC alle macchine virtuali e le applicazioni di massa felicemente discarica segmenti TCP megabyte di dimensioni direttamente nella coda di uscita del VM NIC, dove è facile per il software hypervisor sottostante (OVS) per individuarli e contrassegnarli con un valore DSCP diversa (questa idea è contrassegnato come sospeso nella presentazione di Martin Casado).

I risultati ( documentati in una presentazione ) non dovrebbe essere sorprendente - sappiamo ping non è influenzato da un trasferimento FTP in corso se capita di essere in diverse code fin dai tempi di Fred Baker orgogliosamente presentato i primi risultati di misurazione del poi-rivoluzionaria Weighted meccanismo Fair Queuing ( questa è l'unica presentazione che ho trovato, ma WFQ esisteva già alla fine del 1995 ), a un certo metà degli anni '90 incarnazione di Cisco Live (probabilmente anche prima dei giorni di Cisco Live è stato chiamato Networkers).

L'identificazione elefante basato OVS è una bella idea, anche se ci si deve chiedere come funziona in pratica se misura la portata di ogni flusso che passa attraverso uno switch virtuale (vedi anche OVS scala guai ).

Dire alla gente come impressionante è che gli interruttori Cumulus-powered reagiscono ai flussi di elefanti in hardware è puro marketing - ogni interruttore funziona bene quando di fronte a pacchetti adeguatamente segnalati. Chiamare marcatura "integrazione overlay-to-underlay" DSCP è anche fesserie (no, non voglio link alla fonte); abbiamo usato DSCP per decenni senza bisogno di nomi di fantasia.

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

SENZA NUMERO OSPF INTERFACCE IN QUAGGA (E CUMULUS)

Carlos Mendioroz mi ha inviato una domanda interessante sulle interfacce numerate in Cumulus Linux e alcune delle affermazioni che fanno nella loro documentazione.

TL & DR : Finalmente qualcuno got it! Complimenti per la realizzazione di come utilizzare un antico trucco per rendere i tessuti dei data center più semplice da implementare (e, BTW, le affermazioni sono esagerate).

Perché Sono entusiasta di interfacce non numerati?

Ogni fornitore di data center tessuti sostiene quanto sia facile da configurare i loro tessuti. Collegare i cavi ei dispositivi quasi auto-configurare il tessuto (o potrebbe essere necessario aggiungere un comando di configurazione solo come tessuto modalità switchport ). Rovinare il cablaggio? Nessun problema, tutto solo Lavori ™.

Questi stessi venditori richiedono di configurare sottoreti IPv4 sul point-to-point link in un tessuto di livello 3 foglie-e-colonna vertebrale. Rovinare il cablaggio? Vi auguriamo una felice risoluzione dei problemi!

Solo nel caso vi stiate chiedendo perché qualcuno ha bisogno layer-3 tessuti foglia-e-colonna vertebrale: non è solo sovrapposizione di reti virtuali, che potrebbe anche essere una grande proprietà web, facendo modellazione agli elementi finiti, in esecuzione di un cluster Hadoop ...

Possiamo aggirare l'esigenza di configurare sottoreti IPv4 sui collegamenti che connettono due interfacce indirizzati su interruttori adiacenti? Naturalmente - abbiamo usato le interfacce numerate sul point-to-point link per le età. E 'solo che i programmatori protocollo di routing non hanno capito i giorni del cavo coassiale di spessore se ne sono andati; in questo secolo la maggior parte delle persone usano Ethernet point-to-point link. C'è anche un 6-year-old RFC informativo che descrive questa idea .

Per essere onesti, alcuni venditori hanno implementano interfacce Ethernet numerate. Ad esempio, alcune immagini Cisco IOS hanno il supporto per VLAN non numerata e interfacce Ethernet , ma non possono eseguire protocolli di routing su di loro. Non è esattamente quello che stavo cercando. Fa qualsiasi altro fornitore cavano meglio? Scrivi un commento.

Avete notato ho sottolineato IPv4? IPv6 ha interfacce non numerati costruito nel (si chiamano link indirizzi locali ), e intra-AS protocolli di routing come OSPF devono usarli (quindi è impossibile manipolare l'implementazione in un modo che renderebbe numerate IPv6 point-to-point link obbligatorio ).

E ora per i sinistri

La documentazione Cumulus afferma:

In OSPFv2, configurazione delle interfacce numerate riduce i collegamenti tra i router in elementi topologici puri, e quindi semplifica notevolmente la configurazione della rete e la riconfigurazione. Inoltre, database di routing contiene solo le reti reali, quindi occupazione di memoria è ridotto e SPF è più veloce.

Camminiamo attraverso tutte queste affermazioni:

Configurazione delle interfacce di innumerevoli riduce i collegamenti tra i router in elementi topologici puri

Tradotto in termini ingegneristici: il Type-1 (router) LSA non contiene le reti stub per sottoreti inter-router. Si può fare qualcosa di simile su Cisco IOS con la soppressione del prefisso OSPF .

... E quindi semplifica notevolmente la configurazione della rete e la riconfigurazione.

Marketese per " noi non controlliamo le subnet IP in pacchetti di hello OSPF ".

Inoltre, database di routing contiene solo le reti reali,

Non so quello che chiamano il database di routing . Database di OSPF contiene esattamente lo stesso numero di LSA, la tabella di routing non contiene un minor numero di rotte (ma vedi anche la soppressione prefisso).

... Quindi occupazione di memoria è ridotto e SPF è più veloce.

Ingombro di memoria è ridotto. SPF aumento di velocità è probabilmente misurata in ogni mil - dopo tutto, il router considera le reti stub collegati al router LSA Type-1 solo nel secondo ( distance vector ) parte dell'algoritmo SPF, che ha complessità lineare.

Riassunto

Amo il modo in Quagga gestisce point-to-point link Ethernet - non fare il compito di costruire un tessuto di foglie e spine solo layer-3-molto più facile ed errore resistente, ma avete davvero chiamarlo drammatico ?

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

PER OTTENERE UN LAVORO FATTO BENE, AVETE BISOGNO DI FORMAZIONE ADEGUATA

Il " portare Amazon Web Services mentalità tornare a casa "post generati i commenti attesi, da" gli sviluppatori hanno alcun indizio su rete o rete di servizi "a" siamo andati attraverso il tutto e non è riuscito male . "Bene, anche se potrebbe sembrare così, non ho sostengo lasciare gli sviluppatori vanno incontrollati, stavo solo facendo notare che due pesi e due non hanno senso.

L'effetto Dunning-Kruger

Il mondo è piena di oltre-confident persone che pensano di posti di lavoro di tutti gli altri sono talmente banali che potevano facilmente eccellono nel loro se solo avessero cura abbastanza per affrontarli (e le persone molto intelligenti sono i peggiori , non solo in IT). Questo comportamento è così diffuso c'è un nome ufficiale per il "posso farlo anche se non ho idea di" comportamento: l' effetto Dunning-Kruger ( leggere l'articolo completo , è un capolavoro, c'è anche una sintesi più breve ).

IT è pieno di queste persone:

Rete "architetti" e "designer" che iniziano la progettazione di nuove reti esclusivamente sulla base delle informazioni contenute nel white paper vendor (domanda effettiva mi sono: per favore mi mandi procedura step-by-step che porterà ottimale progettazione dei data center per il mio cliente);

Gli ingegneri che implementano la tecnologia totalmente sconosciuto, trovando frammenti di configurazione casuali su Google e ciecamente le applicano alle loro reti;

Ingegneri senza esperienza nube buiding che hanno intenzione di scaricare OpenStack codice sorgente e un lavoro di cloud privato o pubblico in due settimane (ci sono state, visto che);

Ingegneri fai da te con la sindrome non l'abbiamo inventato noi, che affermano di poter reinventare ogni soluzione proposta da un fornitore (i nostri ragazzi Flip-IT hanno decine di storie da condividere - nella maggior parte dei casi tutti i tecnici fai da te sono riusciti a fare è stato quello di perdere 2-3 anni);

Le persone che ciecamente scaricano gli script e li usano senza nemmeno controllando se gli script sono applicabili al loro ambiente;

Gli sviluppatori di applicazioni che pensano di poter distribuire le applicazioni complesse su AWS senza avere alcuna esperienza di rete o di servizi di rete solo perché "è tutto point-and-click in ogni caso."

Vuoi lasciare i vostri bambini in auto la vostra auto?

Lasciando persone che soffrono di effetto Dunning-Kruger vanno è come dare le chiavi della vostra auto per i vostri bambini. Alcuni di loro potrebbero avere talenti nascosti e riporterà l'auto in un unico pezzo, ma non si può contare su questo. C'è una buona ragione per cui abbiamo scuole e gli esami di guida del conducente.

Lo stesso ragionamento deve essere applicato ai team di sviluppo applicazioni (o chi inizia la costruzione di una nuova rete da googling per "progettazione della rete"). Devono essere interessati a ottenere indipendente (sono tutti a livello verbale), ottenere una corretta esposizione alle sfide della progettazione e cloud operativo implementazioni, reti virtuali e servizi di rete (evitando disegni come questo ), e poi lentamente lasciano andare con qualcuno guardando attentamente i risultati.

Ad esempio, la prima lezione tecnica nella mia Progettazione scalabile di applicazioni Web corso universitario è TCP, HTTP e SPDY ; il corso tratta anche di sicurezza, bilanciamento del carico e cloud distribuzioni.

Investire in un equivalente di corso di guida chiusa fa sempre grande senso. Fortunatamente è davvero poco costoso per fare che nel mondo lo sviluppo di applicazioni; invece di sviluppatori che lavorano sulle proprie workstation e server locali, dare loro un ambiente virtuale cloud-based in piena regola tra cui firewall e bilanciatori di carico .

Ha senso investire in questo processo? Chiedete a qualsiasi mamma di calcio che vuole avere qualcos'altro da fare nella vita che guidare bambini intorno. Investire nei team di sviluppo delle applicazioni e renderle più indipendenti renderà il vostro migliore, più flessibile, ed eventualmente ridurre i costi come gli sviluppatori realizzano la follia di spingere i problemi lungo la pila .

Funzionerà in ogni ambiente? Molto probabilmente no, ma allora forse è il momento di iniziare la ricerca di una società diversa da lavorare. Funzionerà con ogni squadra? Certo che no, ci sono ancora i programmatori là fuori che pensano che ti raggiungono scrivere applicazioni COBOL età pensionabile ... ma se si riesce ad ottimizzare pochi i team di sviluppo applicazioni, è meglio di niente, e il loro successo potrebbe innescare una riorganizzazione obbligatoria di altri squadre.

Infine, tenere presente che un grande potere comporta grandi responsabilità - come bambini seduti al volante di guida, gli sviluppatori che vogliono ottenere un'implementazione più rapida controllando il proprio ambiente e servizi di rete virtuale devono anche assumersi la piena responsabilità per i risultati delle loro azioni .

Oh, e, ultimo ma non meno importante - i miei bambini sempre dovuto pagare per il proprio gas. Sembra un approccio simile potrebbe aiutare in qualche debacle di distribuzione nube .

Hai bisogno di maggiori informazioni?

Check out my costruzione di una infrastruttura di Private Cloud webinar e altri cloud computing e il networking webinar (e assicuratevi di iniziare con le esigenze di business ).

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

SARÀ NETWORK ENGINEERS DIVENTARE PROGRAMMATORI?

So che numerosi ingegneri che hanno deciso di intraprendere una carriera in ambito networking, perché non volevano profonda immersione nella programmazione. Sarà che il cambiamento quando il Software Defined Tutto prende il sopravvento il mondo?

TL & DR Riassunto : Certo che no.

Fare un esperto di networking una riluttante (e potenzialmente cattivo) programmatore rende molto senso come over-promozione di lui e facendo di lui un capo non ottimale (alcune persone, me compreso, non solo sono bravi a gestire gli altri).

Se avete bisogno di una soluzione di automazione di rete su misura, associare un esperto di networking (chissà cosa deve essere fatto) con una persona con competenze di programmazione che possono tradurre tali esigenze in codice in esecuzione - l'esperto di networking diventa solo un altro esperto di materia (PMI ) collaborazione con i programmatori per documentare le esigenze di business (del dipartimento di rete).

Sarà l'esperto di networking a far parte del team di programmazione? Dipende. Per i grandi progetti rende probabilmente il senso di incorporare esperti con competenze di networking in squadre di programmazione, di progetti di sviluppo a bassa intensità a più lungo termine si potrebbe aggiungere un programmatore o due per la tua squadra networking, o unire sviluppo e le operazioni.

Indipendentemente dal metodo che si prende, ricordate che si dovrebbe trattare gli strumenti di automazione della rete come qualsiasi altra applicazione mission-critical - le esigenze di automazione della rete devono essere adeguatamente documentate, il progetto priorità, ed eseguito con la gestione del progetto regolare e strumenti di garanzia della qualità per sicuri di ottenere quello che hai chiesto in tempi ragionevoli (progetti IT interni tendono a rimanere in un limbo indefinito in quanto ognuno lavora su più importanti problemi immediati).

D'altra parte, se sei un lavoro generalista in un piccolo negozio, allora è giunto il momento di fare la conoscenza con gli strumenti di automazione, e imparare un po 'di programmazione - una volta padrone di scripting, la vita diventa più facile su più fronti, tra cui desktop, server, sistemi operativi, virtualizzazione, e alla fine di networking.

Jason Edelman ha pubblicato un post sul blog incentrato sullo stesso dilemma pochi giorni fa. Sicuramente vale la pena di leggere.

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

FCOE E NEXUS 1000V QOS

Uno dei miei lettori volevano implementare FCoE su UCS in combinazione con Nexus 1000V e chiese come FCoE impatto del traffico QoS su Nexus 1000v. Ha scritto:

Diciamo che voglio 4Gb per FCoE. Devo aggiungere azioni di banda fino al 60% nel nesso 1000v CBWFQ config in modo che il 40% sono nel default-classe come 1kv non è a conoscenza del traffico FCoE? O aggiungere fino al 100% con l'assunzione che la 1kv sa che c'è solo 6Gb canali via rete? Inoltre, sarà il Nexus 1000v in grado di rilevare contesa in uplink, anche se non vede il traffico FCoE?

Come sempre, le cose non sono così semplici come sembrano.

Background: adattatore FEX e FCoE

Gli adattatori Ethernet UCS implementare FCoE in hardware - il sistema operativo non lo sa si tratta di un singolo adattatore fisico con un unico set di uplink 10GE. Ogni adattatore 10GE ​​fisico appare come (almeno) due adattatori PCI: un 10GE ​​Ethernet NIC e un host Fibre Channel Bus Adapter (HBA).

Ogni adattatore 10GE attuazione FCoE in hardware è dotato di funzionalità NIC + HBA. Carte di Cisco adattatore (P81E o VIC1225) o adattatori di terze parti che supportano la tecnologia Cisco proprietaria VNTag (esempio: Broadcom BCM57810) consentono di fare un passo avanti e creare numerosi adattatori Ethernet dalla stessa scheda di rete fisica.

L'allocazione della larghezza di banda e la coda in uplink 10GE ​​fisica è nascosto dalle NIC presentati al sistema operativo. Il sistema operativo pensa che si tratta di interfacce multiple in piena regola 10GE/FC, e succede solo che le interfacce trasmettono pacchetti dall'hardware TX-ring più lento di quanto ci si aspetterebbe ... ma poi si potrebbe ottenere gli stessi risultati utilizzando frame PAUSE (o PFC ) su un'interfaccia 10GE ​​dedicato.

Uscita in coda su Nexus 1000v

Uscita in coda su Nexus 1000v funziona allo stesso modo di qualsiasi altra applicazione in uscita in coda: il driver di interfaccia accoda i pacchetti in uscita in hardware TX-ring fino a quando il TX-ring raggiunge una lunghezza prefissata, a questo punto il software di accodamento (CBWFQ) avvia.

Il driver di interfaccia non ha bisogno di conoscere l'esatta banda dell'interfaccia, tutto ciò che deve sapere è quando l'anello TX è inferiore al limite minimo (a cui i pacchetti dei punti sono levati dalla coda dalle code CBWFQ e spostate l'anello TX). Le percentuali banda specificata nel CBWFQ influenzano la relativa quantità di dati trasferiti da ciascuna coda singola classe; funzionano altrettanto bene indipendentemente dalla velocità di interfaccia fisica o il flusso effettivo.

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