Come convinci il management che i 3560/3750 sono una cattiva idea nella tua DC?

I 3560/3750 hanno piccoli buffer e creano buoni interruttori per armadi elettrici. Tuttavia, molto spesso vedo questi interruttori in CC. Molte persone tendono ad usarli in quanto sono generalmente in grado di 1 Gb e L3.

C'è un modo per dimostrare quanto siano cattivi nelle distribuzioni DC? Sento abbastanza spesso la gente dire che hanno rimosso i loro 3750 appena potevano, ma non ho ancora sentito uno scenario di fallimento reale che potrebbe essere usato per far sapere alla direzione di farli uscire.

FWIW Ho avuto esperienza con i 3750 (3750G, e successivamente 3750E / 3560E) su scala in una configurazione TOR; inizialmente con L2 port-channel / GLBP (varianti di 2x1G e 2x2G e il raro 2x4G per rack db) e poi con L3 al TOR (è andato con questo per 3750E / 3560E e 10G al core). Ne sto parlando a migliaia. Abbiamo visto solo problemi con buffer per le maggior parte dei servizi ad alta intensità di banda, ea quel punto stavamo guardando 10G per l'host in ogni caso (e scatole per pizza densi di 24-48 SFP + s ').

Se sarai in grado di dimostrare qualcosa alla direzione dipenderà davvero dall'applicazione e dai compiti a casa su quali sono i requisiti del tuo progetto e dell'applicazione e sapendo esattamente quali sono le specifiche dell'applicazione , nonché la velocità di crescita prevista di esso. Imposta una revisione del design con la tua catena di gestione, nonché i principali proprietari / clienti della rete.

La direzione desidera visualizzare i dati e, se non si dispone delle risorse per testare a fondo la scatola (elaborare un piano di prova, collegarlo a un hardware di generazione del traffico, portarlo completamente in campo e sottoporlo a stress alle specifiche di progettazione, ecc.) sarà difficile da fare. Non saranno colpiti da prove aneddotiche e trovare questo tipo di dati concreti potrebbe rivelarsi difficile, dal momento che sono sicuro che le persone che pubblicano questo genere di cose violerebbero tutti i tipi di NDA.

Tutti gli altri che hanno pubblicato una risposta a questo hanno delineato piuttosto bene le "aree problematiche" della piattaforma 3750: accatastamento e strane modalità di errore intrinseche, dimensioni del buffer, ecc. C'è anche questa domanda che delinea i problemi con la raccolta delle statistiche SNMP sui drop delle code di output - i buffer sono condivisi tra gli ASIC, quindi tutte le statistiche ottenute con questo tramite SNMP saranno le stesse per specifici intervalli di porte (questo potrebbe essere un punto critico che potresti far emergere con la tua catena di gestione).

Per riassumere, direi che il 3750/3560 andrebbe "bene" per la maggior parte delle distribuzioni, anche su scale piuttosto grandi. Evita di impilarli se puoi, ma direi che non è troppo orribile farlo in quantità molto piccole e gestibili.

Dipende molto dallo scenario di distribuzione. I 3560/3750 sono ottimi switch, hanno buffer decenti e di solito funzionano bene per la maggior parte delle applicazioni. Se il tuo data center rileva flussi di traffico che richiedono buffer più grandi, dovresti essere in grado di estrarre le statistiche dagli switch, come l'utilizzo del buffer e il drop dei pacchetti. La gestione convincente di abbandonare gli switch che stanno rilasciando i loro pacchetti non dovrebbe essere una grande sfida. Penso.

All'inizio del 3750, in particolare la tecnologia di stacking rilasciata poco prima del 2010, c'erano molti problemi con i guasti degli switch che causavano il fallimento dello stack in un modo non così grazioso. Combinalo con il fatto che l'aggiornamento di uno stack non è stato il processo più intuitivo (è migliorato da allora), il 3750 ha davvero avuto una cattiva reputazione che da allora è rimasta bloccata.

Nei piccoli data center, lo stack 3750 rappresenta un'opzione relativamente a basso costo per ottenere la densità delle porte senza il costo di uno switch basato su chassis. Io stesso ho appena installato per un cliente più piccolo una soluzione per data center che coinvolge alcuni server Cisco UCS C220 M3 con un Netapp FAS2240 e ho usato uno stack di 3750 per fornire ridondanza etherchannel multi-telaio a ogni nuovo dispositivo e a tutti i loro vecchi server durante la transizione. Ha funzionato davvero molto bene.

Quindi - il 3750 ha dei problemi? Probabilmente lo stesso di qualsiasi altro interruttore che è in circolazione da così tanto tempo. Il 6500 ha avuto problemi all'inizio del suo ciclo di vita, e ora che è stato fuori per anni e anni non è poi così male. Ti consiglio di guardare a ciò che stai per lanciare, e se le metriche delle prestazioni reggono, assicurati di monitorarle con vigilanza.

Onestamente, il modo più comune in cui ho visto i 3750 colpire il marciapiede, è stato quando gli switch core sono stati aggiornati a Nexus 7k. Di solito (ma non sempre) parte di tale aggiornamento consiste nello spostare TOR in FEX Nexus 2000 o Nexus 5000.

Anche se i 3750 non hanno i buffer più grandi, nella mente della maggior parte delle persone, funzionano "abbastanza bene" nella maggior parte degli ambienti DC aziendali.

A meno che tu non riesca a dare un valore in dollari ai problemi causati dall'avere 3560/3750 in un DC, dubito che sarai in grado di convincere il management a sostituirli al di fuori di un normale ciclo di aggiornamento del prodotto.

@mellowd ha certamente ragione, questi switch non sono switch DC molto utilizzabili, a causa di buffer molto limitati faranno microburst e faranno cadere il traffico.

Considera di avere l'ingresso 2 * 1GE e l'uscita 1 * 1GE. Lo scenario peggiore è che la porta di uscita inizia a cadere dopo che le porte di ingresso sono state inviate contemporaneamente per 2 ms. Lo scenario migliore è che puoi gestire un burst di 8ms.

Hai 2 MB di buffer di uscita per 4 porte, quindi 2 MB / (1 Gbps / 8) = massimo 16 ms e 16/4 = minimo 4 ms. Dividi quel numero per la quantità di porte di ingresso che desideri inviare e ottieni il numero di quanto tempo puoi gestirlo. Cioè, più porte di ingresso (server) vengono aggiunte, meno microbursting è possibile gestire.

Se devi vivere con 3750/3560, dovresti leggere questo documento per massimizzare l'uso del buffer. E se stai ancora abbandonando, usa LACP in uscita, anche se i tuoi grafici mostrano che la domanda media in uscita è molto bassa.

Per dimostrare ai tuoi manager che i buffer non sono sufficienti per monitorare / toccare / estendere le tue reti attuali commuta tutti i downlink, quindi avrai timestamp e dimensioni dei pacchetti che vanno in uscita e puoi calcolare quanto su 1 Gbps è la tua richiesta istantanea e quanto buffer dovrai gestirlo.

Le prestazioni sono certamente un problema importante e sono ben affrontate sopra ma c'è anche molta differenziazione in base alle caratteristiche e ai set di funzionalità:

1. La necessità di unità RPS esterne è un grosso problema in molte installazioni: uno switch 1U diventa più costoso in termini di costi iniziali, spazio perso e gestione continua. La potenza ridondante deve essere considerata un must assoluto in tutti gli ambienti, tranne i data center più piccoli.

2. Sono in esecuzione un sacco di codice non necessario per la connettività dell'utente finale - maggiori opportunità di difetti, problemi di sicurezza e tempi di inattività.

3. Le funzionalità DC (ISSU, DCB, archiviazione, alcuni elementi di scripting integrati) non sono - e non lo saranno - sui dispositivi focalizzati sul campus. Anche i meccanismi per gestire e ridimensionare l'estensione L2 in modo sano (ovvero FabricPath / TRILL, OTV, VXLAN, ecc.) Tendono a mancare sia allo stato attuale che alle tabelle di marcia al di fuori dei prodotti DC. L'elenco qui sta solo per crescere: virtualizzazione on-box, supporto di meccanismi di assistenza HW, ecc.

4. Scalabilità: come si fa a crescere l'infrastruttura? Tanti e molti switch (costosi da gestire)? L'accatastamento (difficile dal punto di vista operativo, importanti problemi di cablaggio) è un casino. Inoltre, la flessibilità dei tipi di interfaccia (fibra vs rame, ad esempio) a densità può essere difficile.

In generale, le differenze tra DC e switching dell'armadio stanno crescendo. Nel mondo Cisco esistono sistemi operativi distinti (NXOS vs IOS) per ottime ragioni: requisiti molto diversi producono soluzioni divergenti. La velocità delle funzionalità per i meccanismi di autenticazione utente (802.1x) o l'integrazione fantasia AV non sono necessari nel data center mentre la capacità di terminare tonnellate di 10GE non è necessaria nell'armadio dei cablaggi. Diversi strumenti per diversi lavori. Una scatola Nexus che collega i desktop sarebbe anche un piano tutt'altro che ideale.

Vorrei anche indicarti le varie guide alla progettazione (CVD, ecc.) Che espongono la logica dei tipi di switch utilizzati in vari punti della rete. C'è qualcosa da dire per soluzioni che in genere assomigliano alle migliori pratiche comuni nel settore, e gli switch che stai citando in genere non hanno posto nel controller di dominio, a parte le reti di gestione o alcune situazioni di connettività locale di casi speciali.

Ho un cliente che li ha implementati come uno stack switch SAN (usando 3750X) con la SAN connessa a 10 Gbit e quindi i loro host ESX collegati a Gbit (o più Gbit usando LAG) e la quantità di cadute di output è astronomica, non importa come si tenta di ottimizzare i buffer.

Lo stesso cliente ha altri due stack 3750 nella stessa DC per altre reti e questi sono tutti puliti.

TL; DR: Dipende molto dal tipo di traffico che stai attraversando e da dove si trovano i colli di bottiglia.

Gli alimentatori / le ventole entro 3560/3750 non sono sostituibili a caldo / una volta montato lo switch e si verifica l'inevitabile guasto di questi dispositivi, tutti i server devono essere scollegati dal 3560/3750 mentre è smontato e sostituito con l'RMA.

Anche la direzione della ventola sui 3560s / 3750s diventa un problema con corridoio caldo / corridoio freddo e altre configurazioni di raffreddamento. Il montaggio degli switch in cui le porte degli switch sono rivolte verso la parte posteriore dei server crea una situazione in cui le ventole degli switch soffiano nella direzione sbagliata. Questo surriscalda l'interruttore, il che rende più probabile il fallimento / necessità di sostituzione.