Qual é o benefício de um design "top of rack" da Cisco?

Além da bagunça óbvia de cabeamento que você evita (o que eu conheço como engenheiros de rede é ótimo, mas difícil de usar como desculpa para argumentar com alguém que não vê sentido nisso), o que você ganha em relação ao cobre diretamente para uma maior testemunho?

Contexto: - O preço não interessa

• A empresa já havia decidido por um núcleo Nexus duplo.

  • Opção 1: Nexus 7004, que seria quase totalmente preenchido com 10G SFP + e conexões agregadas a vários FEXs na parte superior de cada rack no DC, bem como SAN agregada e várias conexões de servidor

  • Opção 2: núcleos Nexus 7009 que serão aprox. 1/3 foi preenchido com vários módulos para acomodar a agregação de todas as conexões de fibra de todos os dispositivos.

• Este é um data center colocado

• Serviços padrão relacionados ao call center / domínio corporativo hospedados na rede

• A QoS é um ponto de referência muito importante a ser enfatizado, uma vez que esta empresa é um call center

Problema:

• Não consigo justificar a instalação do "top of rack" da Cisco, apesar de querer menos confusão de cabos e um design mais modular. Não consigo fazer isso porque você está inserindo um ponto de falha na rede. Isso aumenta a latência (mesmo que seja apenas em pequena quantidade) etc. Não apenas isso, mas agora que penso nisso, já que todos os FEXs dependem do Nexus para operar, você não apenas aumenta a chance de uma falha de hardware derrubar um bloco de dispositivos, mas agora um processo de software que pode danificar e fazer com que o FEX funcione de alguma maneira.

Portanto, antes de colocar o design do rack no cemitério das ideias para este projeto, alguém mais pode ver uma razão para não usar um núcleo maior e nenhum FEX devido à falta de limitação de orçamento?

Lembre-se de que um FEX é inerentemente um método pelo qual estender a malha, portanto, o nome. A capacidade de gerenciar centralmente e ainda ter "placas de linha" distribuídas pelo controlador de domínio é o verdadeiro motivo para usar um FEX. Reduzir drasticamente o cabeamento é valioso para qualquer pessoa, técnica ou não, e o argumento de poder gerenciar toda a infraestrutura em menos pontos é economia de tempo, pura e simples.

Uma de suas grandes dúvidas é que você está preocupado com pontos únicos de falha. Todos os dispositivos têm a capacidade de ter hospedagem dupla e, em determinadas configurações, você pode até estabelecer canais de porta virtual com os próprios Nexus 2K FEXs.

Veja a documentação da Cisco . Você descobrirá que pode criar uma topologia tão redundante quanto a opção "cabo direto" que está considerando, com menos barulho.

Quanto aos benefícios, os primeiros cabos ficam desleixados e, quando você está desleixado, ocorrerão problemas. Vi o cabeamento de infraestrutura ficar ruim por vários motivos em um data center. Precisa de mais cabos? Então alguém está mexendo com a fábrica de cabos e algo pode ficar danificado. Lidar com quase 400 cabos conectados a um dispositivo leva a mais desconexões acidentais do que 48. É muito mais fácil de gerenciar.

Segundo, isso ajuda a provas futuras. Embora exista cobre de 10 Gbps, as limitações de distância podem ser problemáticas dependendo da situação. Além disso, o cobre 10G tende a consumir energia adicional por mais tempo.

Terceiro, os FEXes podem ser substituídos com mais facilidade. Deseja mudar de 1Gbps de cobre para 10Gbps SFP +, basta alterar o FEX. Seu núcleo permanece o mesmo e a configuração permanece amplamente no local.

Não vejo os negativos que você fornece e apenas vejo benefícios por fazê-lo.

Dependendo da configuração do seu data center, eu usaria dois extensores de malha na parte superior do rack ou um (se os servidores puderem compartilhar com os racks vizinhos). Os servidores devem estar conectados a dois extensores separados. Cada extensor de malha pode ser conectado aos FETs ao Nexus 7k (que também deve ser conectado).

Isso deve reduzir sua chance de falha. Os FEX são uma extensão do chassi (leitura projetada para o data center com MTBF alto) e mais semelhante a um módulo em um "corpo" de 1U, em oposição a um dispositivo secundário de distribuição ou acesso. Eles inicializam, inicializam o software a partir do núcleo, portanto não há diferença de software. Você pode perder um 7k ou um extensor sem perda de serviço em qualquer lugar. Potencialmente um 7k e vários extensores sem perder o serviço.

Você também pode gerenciar isso como uma única unidade lógica, permitindo que coisas como servidores realmente agregem links, mesmo estando conectados a dois extensores diferentes, aumentando o desempenho e reduzindo as chances de falha.

Não vejo como isso aumentaria a latência de alguma forma e poderá realmente melhorá-la.

Quando você começa a usar os recursos mais avançados do Nexus, vejo apenas mais benefícios.

Por fim, você precisa fazer a escolha para suas próprias necessidades. Mas direi isso: se você pesquisar como as principais empresas de Internet administram seus datacenters, verá que a maioria delas possui algum tipo de implantação no topo do rack. Eles não escolhem isso porque aumenta o tempo de inatividade ou diminui o desempenho. Eles fazem isso porque reduz o tempo de inatividade, aumenta o desempenho e aumenta bastante a capacidade de gerenciamento.

Editar: consolidando a partir dos meus comentários para que eu possa excluir. No momento, o trem de comentários é muito longo para esta resposta para ser útil.

1.) As probabilidades são boas de que, se você estiver no espaço colo, gostaria de olhar o 7010 com fluxo de ar da frente para trás, em vez do 7009 de lado a lado.

2.) Um dos pontos óbvios na discussão de troca de ToR vs centralizada é geralmente escalabilidade. Se sua pegada de colo é praticamente fixa, não é uma preocupação. Se estiver programado para crescer de alguma maneira apreciável, é necessário ter a capacidade de expandir a rede de maneira racional. Dito isto, eu provavelmente relutaria em usar um 7004 como ponto de concentração para as unidades FEX se o crescimento fosse uma preocupação. O 7K pode rodar até 48 extensores no momento e provavelmente aumentará no futuro. Se você estiver em 6 armários durante a duração, no entanto, isso não importa muito.

3.) O desconhecido aqui (pelo menos com base na pergunta inicial) é a densidade de servidores nos racks. Se são 6-8 4U, então o FEX é um exagero. Se houver muitas dezenas de links da GE de passagens de 1U ou blade, o argumento do cabeamento assume um elenco mais sério. Eu já vi certas configurações (disfuncionais) com mais de 384 cabos em um único rack. Não é algo que eu quero ver novamente.

No geral, a principal diferença entre um 7K pequeno que hospeda várias unidades FEX e um 7K maior executando essas mesmas conexões em casa não será tremenda em pequena escala. Como foi mencionado acima, o FEX aparece como outra placa de linha no chassi. Com poucas exceções, os recursos e funções das portas FEX serão equivalentes às portas nativas e serão gerenciados como tal.

Além disso - Ao contrário da suspeita popular, a penalidade de desempenho ao usar um FEX não é significativa se for projetada corretamente. Argumentos sobre latência são medidos em microssegundos (e todo o design é melhor abordado com uma plataforma diferente, se isso for um problema).

Não há muita diferença (além do custo) entre passar cabos diretamente para o núcleo ou usar extensores de malha no meio.

1. Se você conectar seus servidores diretamente aos núcleos, conectará cada servidor com dois links, um para cada comutador principal. Dessa forma, mesmo se um switch principal falhar, o outro mantém o serviço.
2. Se você fabricar extensores em cima de cada rack, seus servidores serão conectados por dois links a dois extensores de tecido diferentes, ambos conectados a dois comutadores principais. O link entre o FEX e o Core Switch é um link L1 e toda a configuração dos extensores de malha se comporta como um único switch lógico. A instalação não apresentará nós STP adicionais; portanto, não deve haver mais latência do que a primeira opção. Para perda de conectividade, os switches Core ou os FEXs ou seus links correspondentes devem falhar. A falha de um único comutador FEX ou Core não afetaria o serviço. Embora os extensores de malha sejam uma ideia relativamente mais recente, a maneira como o trabalho é realmente melhor que a opção 1.

Como você mencionou que menciona que os orçamentos não são um problema, convém dimensionar seus 7Ks do Nexus (e conectividade de fibra) para ter capacidade suficiente para oferecer suporte a uma atualização futura para 40G ou 100G. Os FEXs podem ser instalados para atender aos requisitos atuais. Posteriormente, caso deseje atualizar para 100G, você precisará substituir os FEXs sem precisar alterar o Nexus 7ks ou o cabeamento.

O preço geralmente é um dos principais fatores para um design "top of rack", e você disse que o custo não é um problema.

Nós o usamos por dois outros motivos que eu ainda não tinha visto na lista: modularidade ou facilidade de implantação.

Se você tiver um design de "rack" padrão, poderá criar e testar um rack inteiro (ou grupo de racks) juntos como um módulo ou comprá-los prontos. Depois, basta conectar alguns cabos na parte superior, em vez de reconectar todas as máquinas.

O outro caso com parte superior do rack pode fazer muito sentido (ou parte superior de alguns racks, dependendo do seu aplicativo) é se você tiver uma configuração de compilação padrão para implantar uma "célula" da sua infraestrutura. Às vezes, a comunicação dentro de uma "célula" é alta (por exemplo: servidor web, servidor de aplicativos, servidor db, servidor de imagem etc.). Nem todo mundo tem esse tipo de configuração, mas pode ser útil para que você possa caracterizar o desempenho de uma célula, e expandir significa adicionar mais células em vez de aumentar toda a sua infraestrutura (o que pode causar mais surpresas no desempenho).

Por fim, sem uma limitação de orçamento, não faz sentido não seguir simplesmente o design 7009, pois há menos dispositivos afetados pela falha de uma única linha de fibra do que de um extensor de tecido inteiro.

Novamente, o extensor de malha é um ponto de falha extra de hardware e software em um ambiente que não precisa da densidade de porta extra além do que o dispositivo principal fornece.