Racks de servidor de cabeamento estruturado


8

Na semana que vem, temos a oportunidade de reconectar cinco racks de servidor, que estão atualmente em uma verdadeira bagunça. Atualmente, cada rack possui um switch instalado na parte superior, com muitos cabos pendurados.

Estamos pensando em instalar painéis de correção em cada rack, conectados de volta ao primeiro rack em outro painel, a partir daí os cabos de conexão que entram nos comutadores e nos outros racks, os cabos de conexão que entram nos servidores.

insira a descrição da imagem aqui

Portanto, um servidor no rack 5, por exemplo, seria conectado assim:

[server] -> [patch lead] -> [patch panel no rack 5] -> -> -> -> -> -> [patch panel no rack 1] -> [patch lead] -> [switch]

Algo assim funcionará?

Quaisquer pontos, sugestões apreciadas.

Agradeço antecipadamente!


+1, Bom para organização / separação ... O NOC do nosso colo coloca os painéis de conexão do servidor na parte inferior dos racks, pois eles têm um piso elevado e passam o cabeamento por lá.
jscott

1
Bom esforço no desenho mspaint. :)
user78940

Respostas:


4

Isso funcionará, mas qual é a vantagem para você sobre a limpeza de cabos existentes e a manutenção dos comutadores nos racks locais (você tem muitas conexões cruzadas entre os racks que poderiam ser eliminados?).
Lembre-se de que os painéis de manobra não tornam magicamente a sua fiação mais limpa: disciplina, manutenção e muitos laços de velcro fazem isso.

Geralmente, separar os racks pode ser uma coisa boa, principalmente porque os painéis de remendo geralmente vêm com bons troncos sólidos de painel para painel (menos lixo embaixo do chão ou nas bandejas de cabos).
A grande desvantagem é que, se você perder o link em um switch, agora terá muito mais para solucionar problemas (é o cabo do servidor para o patch panel local, o tronco de painel para painel, o cabo do patch panel para o switch, o próprio switch, o próprio servidor etc.).
A desvantagem menor é ter que abrir dois racks para conectar um servidor a um switch. No entanto, isso pode ser discutido como um aumento na segurança (alguém com chaves para o rack de switch precisa estar por perto para conectar novos equipamentos.


Um pequeno conselho, não importa o que você decida fazer: Documente o máximo de seus cabos - ESPECIALMENTE se estiver usando painéis de manobra. Você se agradecerá mais tarde quando precisar descobrir qual caminho o servidor percorre para chegar a uma porta do switch. (Existem algumas perguntas aqui sobre esquemas de identificação de cabos - /server/64259/what-is-the-most-effective-solution-you-used-to-label-cables é um deles)


1
+1 Apenas para gravatas velco ... Quero levar os diques para qualquer pessoa que carregue um pacote de gravatas.
jscott

Obrigado pelo seu comentário e eu concordo, ter o patch panel adiciona alguns pontos de falha adicionais que precisariam ser investigados se, por exemplo, um servidor perdesse a conectividade. Atualmente, temos algumas conexões cruzadas e vamos implantar duas unidades SAN com caminhos múltiplos ... essa é a principal razão pela qual estamos pensando em seguir a rota do painel de patch.
22411 PeterG

consolidar conexões cruzadas vale totalmente qualquer IMHO aéreo adicional - quanto menos porcaria no seu piso / bandeja, melhor você está. Note-se que também existem painéis de fibras (no caso de você estiver considerando uma fibra SAN), que pode valer a pena olhar para, mas eles são terrivelmente caros, como são todas as coisas fibra :)
voretaq7

4

Eu, pessoalmente, estive envolvido na fiação de data centers com os dois métodos que você descreveu e devo dizer que ter o comutador no rack provou ser uma solução muito melhor. Tanto a instalação quanto a manutenção são mais fáceis com o switch no rack e, a menos que você planeje ter uma contagem de servidores bem abaixo da densidade da porta do switch no rack, o switch no rack provavelmente será mais barato.

Aqui estão algumas das vantagens que encontrei para a solução switch in rack

  • Requer menos cabeamento inter-rack - 1 (+ backups / ligação) uplink para cada switch principal em vez de 1 por host. Isso é ENORME.
    • Menos tempo para implementar
    • Menos cabos para testar
    • Custo mais baixo (supondo que você possa dimensionar adequadamente os comutadores de rack)
  • Requer 1 cabo de conexão em vez de 2 - Cada cabo executado é outro local que requer teste
  • Menos documentação - no mínimo, cada cabo precisa ser rotulado e 1 é mais fácil do que 2
  • Cabos de patch totalmente rastreáveis ​​- Supervisões acontecem e a documentação é perdida. Em um único rack, é muito mais fácil rastrear um cabo (mas ainda assim não é divertido)
  • Remoções / mudanças de servidor mais fáceis - O painel de correção requer muita confiança em sua documentação. Comutação no rack Eu puxo o cabo do servidor, corte a extremidade e o alimente de volta no switch e remova. Nenhuma confiança / adivinhação de volta ao patch panel
  • Menos erros de dados - O painel de remendo tem 6 pontos para perfurar / prensar antes de atingir um interruptor, o interruptor no rack possui 2. Cada ponto de prensagem / perfurador é um local onde o sinal é perdido. Este é um problema menor com 100Mb e 1Gb +. Também achei mais fácil certificar um crimp rj45 do que um punchdown no painel.
  • Inventário de switch mais rápido - Imprimir uma configuração de um único switch e verificar um rack é muito mais fácil do que imprimir todas as configurações de todos os switches e verificar
  • Menos confusão - A solução de painel de remendo exige muitos cabos em um espaço pequeno e, se você estiver vendo confusão com 1 rack de servidores (~ 40 cabos), imagine se você tivesse mais de 160 em um só lugar

Isso não quer dizer que sou totalmente contra o patch panel, mas tento limitar seu uso a locais onde não consigo trazer os comutadores para o equipamento. A instalação de cabines nos escritórios vem à mente como um local perfeito para a utilização de painéis de remendo, mas no datacenter eu o incentivaria a chegar o mais próximo possível de 0 painéis de remendo.


3

Atualmente, fazemos exatamente isso onde trabalho. E eu odeio isso .

  1. Muitos pontos extras de falha
  2. Nós sempre temos uplinks curtos no gabinete.
  3. Quando precisamos de novos links, alguém está conectando o gabinete em uma escada, arriscando todos os outros links.
  4. Temos guias de fios instaladas para limpar os fios abaixo de cada painel de remendo e depois as guias de fios no lado do comutador, desperdiçando espaço.
  5. triplicar o número de cabos. Yay. Eu preciso de mais desses!
  6. E os bajilhões de cabos de conexão são executados sem rima ou razão e sem maneira de rastreá-los facilmente .

Esse último ponto é o pior. Quando você está com pressa, os vários níveis de rastreamento são um inferno e seu switch fica muito longe quando tudo o que você quer fazer é verificar as luzes no servidor e no switch ao mesmo tempo.

Se você fizer dessa maneira, o que eu recomendo é que você intercale interruptores de 1 µ com guias de 2 µ para que você não tenha um mega-tijolo de fios correndo de cada lado de um bloco de uplinks para um bloco de interruptores . Você precisa amarrar o fio para mantê-lo sob controle quando tiver mais de 200 fios em um canal e não conseguir rastrear QUALQUER COISA.

Se você possui uma malha SAN que é um segundo comutador, eu a colocaria na parte inferior para que sua fiação seja de maneiras diferentes.

ATUALIZAÇÃO com conselhos

Usamos painéis de conexão pop-up da Panduit e os dois com fio, ambos são bons se o seu eletricista for bom. Muito alívio do estresse é fundamental com a fiação de longo prazo, dobra-os, enrola-os e amarra-os. E, honestamente, você precisa incutir uma cultura de fazer as coisas direito ... então pegue guias de arame verticais e use-os religiosamente. (O velcro na estrutura do rack é bom!) Cabos cortados são cabos que a gravidade está destruindo.

Para o ponto de @ voretaq7: pré-conectar todo o bloco de 24 é uma boa idéia que você encontrará usos para eles mais tarde (acabamos puxando o KVM, usando-os como links de gabinete para gabinete e muito mais).

Trabalhe duro para manter as coisas consistentes. 1-24 deve conectar-se para 1-24 na outra extremidade. Se você possui as portas do switch, pré-conecte todas (ou metade) também. Se você executar mais do que dados na Ethernet, codifique por cor todos os cabos desse link. Você quer ser capaz de identificar os estranhos com pressa. Considere atribuir portas pelo número de rack µ em vez de carregar da esquerda para a direita. Tudo o que ajuda a evitar uma planilha gigante cheia de endereços encadeados que as pessoas não conseguem ler com pressa.

Uma vez que as coisas estão no ar, ninguém quer deixar você voltar e tornar as coisas consistentes; portanto, ter padrões naturais fáceis que as pessoas podem seguir em tempos de emergência sem papelada significa que você não perde a disciplina toda vez que um servidor morre.


1
Posso concordar com você no nº 1 e nº 4, dependendo do tipo de guia de cabos que você usa, mas o resto parece problemas de processo local - Especialmente nº 3: se você está fazendo isso, está fazendo errado (tm) - - Seus painéis de conexão devem ser pré-conectados de ponta a ponta e não precisam de trabalho adicional depois de colocados no rack. fiação a partir de um painel de ligações de um dispositivo é exactamente o mesmo como de um comutador de um dispositivo ...
voretaq7

Na sua experiência, que tipo de falhas são as mais comuns nesse tipo de configuração? A última coisa que queremos fazer é introduzir problemas em um ambiente sólido como uma rocha, mas confuso como o inferno. Quero dizer que não há cabos amarrados, eles estão apenas pendurados nos switches para servidores, mas como a maioria concorda, é um desastre esperando para acontecer. Estamos pensando em colocar aproximadamente 2 48 painéis de patch de porta nos racks 2 - 5, que serão mais do que suficiente para o nosso uso agora e no futuro próximo.
PeterG

Só para checar, eu nunca fiz isso antes, com tão pouca incerteza - é possível cabear da parte traseira de um patch panel até a outra parte traseira do próximo patch panel? Qualquer coisa a observar, tome cuidado extra?
PeterG

+1 para voretaq7. No entanto, "problemas locais de processo" são problemas que quase todo mundo tem. O @PeterG atualmente tem cabos cortados, então as coisas que funcionam com falhas humanas são melhores do que as regras draconianas que as pessoas não seguem. Quanto maior a empresa, mais você tem razão. ;-)
Mark

2

Daria certo, e acho que é uma boa ideia. Dessa forma, você separa racks de servidor e racks de telecomunicações ...


1
Eu sinceramente aprovaria isso, com uma exceção - se você tiver dispositivos SAN, eles deverão estar preferencialmente no mesmo rack que os servidores que eles servem e conectados via cabeamento dentro desse rack.
181111 Mike Insch

Estávamos pensando mais no sentido de ter as unidades SAN no primeiro rack, para que toda a fiação de cada um e do multipath possa ser feita lá e apenas conectar cada servidor. Se eu pensar sobre isso, parece que será um solução muito elegante, mas novamente, como alguns responderam, ele acrescenta pontos de falha, etc ... Obrigado pelos comentários e sugestões. Isso realmente ajuda! :)
PeterG

1

Eu fiz os dois. Parece que você deseja passar da alternância do topo do rack para a alternância no final da linha.

Acho que pularia os painéis de remendo e re-trabalharia e limparia o que você tem.

Os painéis de remendo não necessariamente vão limpar seus racks.

Eu moveria os comutadores para o meio e executaria fibra / outro entre os comutadores para compor o tecido para o TOR. Você pode dividir a rede física em pedaços e executar o cabo adequadamente, fornecendo o "cabo estruturado" sem muita estrutura rígida. Basta colocar o interruptor onde desejar e executar o cabeamento da mesma maneira que faria como um painel de conexões.

Eu usaria o EOR como você usou acima, mas sem a necessidade de nenhum patch panel. Dependendo da densidade e da topologia geral do comutador, você pode usar uma camada de agregação de comutação.

Você pode rotular parte desse equipamento com marca / modelo / contagem de portas?


Consideramos deixar ou, em vez disso, mover os comutadores para o meio do rack, mas como mencionei em uma resposta anterior, o principal motivo para os patch panels é que estaríamos instalando duas unidades SAN com caminhos múltiplos e Não quero imaginar a bagunça de cabos que criará mais de cinco racks.
PeterG

Não entendi a parte sobre a SAN até agora. O que é a malha SAN?
21411 dmourati

@PeterG - Eu não sou fã de switches ou PDUs "no meio" de um rack - parece uma ótima idéia, porque são cabos mais curtos e metade dos cabos vai "subir" e a outra metade " ", mas eu nunca vi isso parecer bonito na prática.
voretaq7

O SAN será iSCSI (Equallogic)
PeterG

0

Isso funcionará de maneira desafiadora. Fiz a mesma coisa em nosso data center; lembre-se de mantê-lo limpo e organizado com algumas barras de gerenciamento de cabos e passar os cabos pelas laterais do rack e não na frente do equipamento.

Um problema que tive foi que nossos cabos passam por baixo do piso e decidi colocar o patch panel na parte superior dos racks, para que eu tenha mais de 48 cabos passando pela lateral do rack até o patch panel, ocupando um espaço valioso.

Se eu fizesse novamente, diria que se os cabos passarem sob o piso, o patch panel na parte inferior, se o cabo estiver acima dos racks, então o patch panel na parte superior.

Decidi seguir esse caminho para que meu núcleo da Cisco estivesse junto e eu pudesse ter uma boa pilha em vez de conectá-los por fibra. Também facilita a aplicação de patches em um switch DMZ.

Obviamente, você perderá alguns U de espaço no rack e documentará tudo e deixará algum cabo frouxo, caso precise mover um pouco os racks um pouco


Ótimo, obrigado pela dica. Nosso fornecedor de colo decidiu colocar os cabos acima dos racks, então eu definitivamente vou manter os painéis lá em cima ... no meu esboço muito primitivo, não adicionei as barras de gerenciamento de cabos, mas planejamos colocá-las lá também.
22411 PeterG
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.