Como convencer a gerência de que 3560 / 3750s são uma péssima ideia no seu controlador de domínio?

Os 3560 / 3750s possuem pequenos buffers e fazem bons interruptores no armário de fiação. No entanto, muitas vezes vejo esses interruptores nos DCs. Muitas pessoas tendem a usá-los, pois geralmente são capazes de 1Gb e L3.

Existe uma maneira de provar o quão ruim eles são nas implantações de DC? Frequentemente ouço pessoas dizendo que removeram seus 3750s o mais rápido possível, mas ainda estou ouvindo um cenário de falha real que poderia ser usado para informar a gerência sobre sua saída.

FWIW Eu já tive experiência com 3750 (3750G e, posteriormente, 3750E / 3560E) em escala em uma configuração de TOR; inicialmente com canais de porta L2 / GLBP (variantes de 2x1G e 2x2G e o raro 2x4G para racks db) e depois com L3 para o TOR (foi usado para 3750E / 3560E e 10G para o núcleo). Eu estou falando milhares deles. Vimos apenas problemas com buffers para os serviços com maior consumo de largura de banda e, naquele momento, estávamos analisando o 10G para o host de qualquer maneira (e caixas de pizza densas com 24-48 SFP + 's).

Se você conseguirá ou não provar alguma coisa ao gerenciamento, realmente dependerá do aplicativo e você fará sua lição de casa sobre quais são os requisitos de seu design e aplicativo e saber exatamente quais são as especificações do aplicativo , bem como a velocidade de crescimento esperada. Configure uma revisão de design com sua cadeia de gerenciamento, bem como com os principais proprietários / clientes da rede.

A gerência deseja ver os dados e, se você não tiver os recursos para testar completamente a caixa (crie um plano de teste, conecte-o a algum hardware de geração de tráfego, faça o escopo completo e teste-o de acordo com as especificações do projeto, etc) isso vai ser difícil de fazer. Eles não ficarão impressionados com evidências anedóticas, e encontrar esse tipo de dados concretos pode ser difícil, pois tenho certeza de que as pessoas que publicam esse tipo de coisa violariam todos os tipos de NDAs.

Todo mundo que postou uma resposta para isso descreveu bastante bem as "áreas problemáticas" da plataforma 3750: modos de empilhamento e falhas estranhas inerentes a ela, tamanhos de buffer etc. Há também essa pergunta que descreve os problemas com a coleta de estatísticas SNMP em quedas na fila de saída - os buffers são compartilhados entre os ASICs, portanto, todas as estatísticas obtidas com isso por meio do SNMP serão as mesmas para intervalos de portas específicos (esse pode ser um ponto difícil que você pode trazer à sua cadeia de gerenciamento).

Para resumir, eu diria que o 3750/3560 seria "bom" para a maioria das implantações, mesmo em escalas um tanto grandes. Evite empilhá-los, se puder, mas eu diria que não é tão horrível fazer isso em quantidades muito pequenas e gerenciáveis.

Realmente depende do seu cenário de implantação. Os 3560 / 3750s são ótimos switches, possuem buffers decentes e geralmente funcionam bem para a maioria dos aplicativos. Se o seu datacenter visualizar fluxos de tráfego que exigem buffers maiores, você poderá extrair estatísticas dos comutadores, como uso de buffer e queda de pacotes. Convencer o gerenciamento a descartar os comutadores que estão descartando seus pacotes não deve ser um grande desafio. Eu acho que.

Nos primeiros dias do 3750, especialmente a tecnologia de empilhamento lançada pouco antes de 2010, havia muitos problemas com falhas de comutação, fazendo com que a pilha falhasse de uma maneira não tão graciosa. Combine isso com o fato de que atualizar uma pilha não foi o processo mais intuitivo (é aprimorado desde então), o 3750 realmente tem uma má reputação que permanece desde então.

Em pequenos data centers, a pilha 3750 representa uma opção de custo relativamente baixo para obter a densidade da porta sem o custo de um comutador baseado em chassi. Eu mesmo acabei de instalar para um cliente menor uma solução de data center envolvendo alguns servidores Cisco UCS C220 M3 com um Netapp FAS2240, e usei uma pilha de 3750s para fornecer redundância de etherchannel de chassi múltiplo para cada novo dispositivo e para todos os servidores antigos durante a transição. Funcionou muito, muito bem.

Então - o 3750 tem seus problemas? Provavelmente o mesmo que qualquer outro switch que existe há tanto tempo. O 6500 teve seus problemas no início de seu ciclo de vida e, agora que está fora há anos e anos, não é tão ruim. Eu recomendo olhar para o que você vai lançar e, se as métricas de desempenho persistirem, certifique-se de monitorar o desempenho delas com vigilância.

Honestamente, a maneira mais comum que vi os 3750's chegarem ao meio-fio foi quando os comutadores principais foram atualizados para o Nexus 7k. Geralmente (mas nem sempre) parte dessa atualização é mover o TOR para o Nexus 2000 FEXs ou Nexus 5000s.

Embora os anos 3750 não tenham os maiores buffers, na mente da maioria das pessoas, eles funcionam "suficientemente bem" na maioria dos ambientes corporativos de DC.

A menos que você possa colocar um valor em dólares nos problemas causados ​​por ter 3560/3750 em um CD, duvido que você consiga convencer a gerência a substituí-los fora de um ciclo regular de atualização de produtos.

A @mellowd certamente está certa, esses switches não são switches DC muito utilizáveis, devido aos buffers muito limitados que eles causam microburst e diminuem o tráfego.

Considere que você tem entrada 2 * 1GE e saída 1 * 1GE. O pior cenário é que a porta de saída começa a cair após o envio das portas de entrada ao mesmo tempo por 2 ms. O melhor cenário é que você pode lidar com 8ms burst.

Você tem 2 MB de buffer de saída por 4 portas, então 2 MB / (1 Gbps / 8) = 16ms no máximo e 16/4 = 4ms no mínimo. Divida esse número pela quantidade de portas de entrada que deseja enviar e você obtém o número de quanto tempo você pode lidar com isso. Ou seja, quanto mais portas de entrada (servidores) você adicionar, menor será a capacidade de lidar com microorganismos.

Se você precisar viver com o 3750/3560, leia este documento para maximizar o uso do buffer. E se você ainda está desistindo, use o LACP na saída, mesmo que seus gráficos mostrem que a demanda média de saída é muito baixa.

Para provar aos seus gerentes que os buffers são insuficientes para monitorar / tocar / abranger, suas redes atuais alternam todos os downlinks, você terá carimbos de data e hora e tamanhos de pacotes que sairão e poderá calcular quanto mais de 1 Gbps é sua demanda instantânea e quanto buffer, você precisará lidar com isso.

O desempenho é certamente uma questão importante e é bem abordado acima, mas também há muita diferenciação com base nos recursos e nos conjuntos de recursos:

1. A necessidade de unidades RPS externas é um grande problema em muitas instalações - um switch de 1U se torna mais caro em termos de custos iniciais, espaço perdido e gerenciamento contínuo. A energia redundante deve ser considerada uma necessidade absoluta em todos os ambientes, exceto nos menores do data center.

2. Muitos códigos desnecessários para a conectividade do usuário final estão em execução - mais oportunidades para defeitos, problemas de segurança e tempo de inatividade.

3. Os recursos de DC (ISSU, DCB, armazenamento, certos elementos de script na caixa) não estão - e não estarão - nos dispositivos focados no campus. Os mecanismos para gerenciar e dimensionar a extensão L2 de maneira sadia também (por exemplo, FabricPath / TRILL, OTV, VXLAN etc.) também tendem a estar ausentes no estado atual e nos roteiros fora dos produtos DC. A lista aqui só vai crescer: virtualização na caixa, suporte a mecanismos de assistência à HW, etc.

4. Escalabilidade - Como você cresce a infraestrutura? Muitos e muitos switches (caros de gerenciar)? Empilhar (operacionalmente difícil, grandes problemas de cabeamento) é uma bagunça. Além disso, a flexibilidade dos tipos de interface (fibra versus cobre, por exemplo) na densidade pode ser um desafio.

Em geral, as diferenças entre comutação DC e armário estão crescendo. No mundo da Cisco, existem sistemas operacionais distintos (NXOS vs IOS) por muito boas razões - requisitos muito diferentes produzem soluções divergentes. A velocidade do recurso para mecanismos de autenticação do usuário (802.1x) ou integração AV sofisticada não é necessária no data center, enquanto a capacidade de terminar toneladas de 10GE não é necessária no armário de cabeamento. Diferentes ferramentas para diferentes trabalhos. Uma caixa Nexus conectando desktops também seria um plano abaixo do ideal.

Eu também indicaria os vários guias de design (CVDs, etc) que explicam os tipos de comutadores usados ​​em vários pontos da rede. Há algo a ser dito para soluções que geralmente se assemelham às melhores práticas comuns do setor, e os switches que você mencionou geralmente não têm lugar no controlador de domínio - além das redes de gerenciamento ou de determinadas situações especiais de conectividade local.

Eu tenho um cliente que os implantou como uma pilha de switches SAN (usando 3750X) com a SAN conectada em 10 Gbit e, em seguida, seus hosts ESX conectados em Gbit (ou vários Gbit usando LAG) e a quantidade de quedas de saída é astronômica, não importa como você tenta ajustar os buffers.

O mesmo cliente possui outras duas pilhas 3750 no mesmo controlador de domínio para outras redes e todas estão limpas.

TL; DR: Depende realmente do tipo de tráfego que você estará colocando na pilha e onde estão seus gargalos.

As fontes de alimentação / ventiladores do 3560/3750 não podem ser trocados a quente / quando o comutador é montado e a inevitável falha desses dispositivos ocorre, todos os servidores devem ser desconectados do 3560/3750 enquanto estão desmontados e substituídos pelo RMA.

Além disso, a direção do ventilador nos 3560s / 3750s se torna um problema com o corredor quente / corredor frio e outras configurações de resfriamento. A montagem dos comutadores em que as portas do comutador estão voltadas para a parte traseira dos servidores cria uma situação em que os ventiladores do comutador sopram na direção errada. Isso superaquece o comutador, o que aumenta a probabilidade de falha / necessidade de substituição.