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


7

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?


Não tenho uma ótima resposta, mas o isolamento de falhas vem à mente.
Yosef Gunsburg

Sim - eu considerei isso também. Em última análise, é o isolamento de falhas ao custo de criar o risco de mais falhas.
skrumcd

Respostas:


7

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.


Poderíamos debater pontos únicos de falha até o padrão de elétrons cruzando o fio, então acho que vejo adicionando outro, especialmente um governado por um único conjunto de dispositivos, dos quais provavelmente estão executando o mesmo software e poderiam portanto, têm os mesmos erros, desnecessários quando não limitados por um orçamento. Eu acho que você me ajudou a responder à minha própria pergunta :)
skrumcd

De fato. Uma placa de linha é tanto um ponto de falha quanto um FEX. ('embora seja mais fácil desconectar o FEX)'
Ricky Beam

11
Pense em onde estão os domínios de falha. Você pode tolerar servidores únicos versus racks únicos versus uma linha de racks falhando antes de ficarem preocupados demais? Esse entendimento direciona a solução para atender às suas metas de design e determina o nível de confiabilidade que você precisa obter em cada ponto (servidor, rack, linhas) na rede.
generalnetworkerror

13

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.


Eu acho que você tem a impressão de que os FEXs estão fornecendo mais do que eles - podemos, com a mesma facilidade, oferecer hospedagem múltipla nos servidores e nos FEXs.
Skrumcd #

Sim, mas em sua essência, estamos discutindo entre a idéia de executar um cabo direto no núcleo e em dispositivos FEX que podem falhar.
Skrumcd #

Portanto, só para esclarecer, o preço não é preocupante, nem a densidade das portas, pois isso será coberto pelos 5-6 slots restantes em cada nexo. Sabendo disso, você ainda optaria por colocar uma diferença entre os servidores e o núcleo?
Skrumcd #

4
Concordo com o YLearn, a parte superior do rack da FEX voltando ao núcleo será melhor a longo prazo. Descobrimos que não fomos capazes de preencher um chassi completo, pois não conseguimos mais cabos no orifício na parte inferior do rack. Eu acho que é mais provável que você tenha uma interrupção devido à massa de cabos no rack da rede principal do que a falha de um dispositivo. É fácil bater um ou dois cabos quando você procura algo ou está executando em novos cabos também é mais fácil e rápido de usar. substitua um cabo de conexão de 2 m do que um cabo de 20 m de volta ao núcleo, se um cabo falhar.
Epaphus 26/05

3
Já fui a muitos lugares sem uma configuração adequada da chave TOR. É propenso a erros, confuso e leva a mais interrupções. Em última análise, isso não é um argumento - são opiniões baseadas na experiência do mundo real de várias pessoas. Você parece bastante decidido a se conectar diretamente aos 7Ks. Isso é bom. será que vai dar certo? Sim. Se você não tocar muito no seu cabo, ele funcionará bem. Lembre-se disso quando forem duas horas da manhã e você estiver passando um longo cabo de arus entre os racks e se perguntar "Por que não recebi interruptores TOR?" Não é o cabeamento inicial que é péssimo. É todo mundo depois disso.
bigmstone

4

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).


3

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 extensor do Fabric não possui software ou configuração própria. É um dispositivo plug and play que baixa o software dos comutadores Nexus pai. Portanto, acho que você não pode considerá-lo um ponto de falha de software adicional.
Surajram Kumaravel

11
Certamente você pode. Um processo executado em seu pai Nexus está fazendo algo para detectar um fex, fazer a atualização do flash quando detectado, garantir que o fex seja reconhecido corretamente como uma placa de linha, controlar / configurar os FEXs como tal, etc.
skrumcd

E como isso é diferente de uma solução de chassi? Eles executar um processo para detectar quando um módulo é inserido, verificar / atualizar o flash no módulo (e placa-filha se necessário), garantir o módulo está devidamente reconhecido, aplicar a configuração, etc.
YLearn

3

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).


1

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.


11
Não concordo com essa postura, pois essa é uma antiga mentalidade de data center. O IIRC Google, Microsoft, Netflix, Facebook e muitos outros discordam dessa postura. Fique à vontade para pesquisar como eles fazem isso, pois a maioria forneceu alguns detalhes de seus data centers publicamente.
YLearn

11
@YLearn, sem tomar partido aqui, um design para os garotos grandes não é necessariamente correto para um pequeno data center, embora eu desse mais peso ao que eles estão fazendo.
generalnetworkerror
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.