Em uma das conversas, me fizeram uma pergunta:
- E há algo para ler, como empacotar servidores em racks corretamente?
Percebi que não conhecia esse texto, então escrevi o meu.
Primeiramente, este texto é sobre servidores físicos em centros de dados físicos (DCs). Em segundo lugar, acreditamos que existem muitos servidores: centenas ou milhares; para um número menor, esse texto não faz sentido. Em terceiro lugar, acreditamos que temos três limitadores: espaço físico nos racks, energia no rack e deixá-los em filas, para que possamos usar um switch ToR para conectar servidores nos racks vizinhos.
A resposta para a pergunta depende muito de qual parâmetro otimizamos e o que podemos variar para alcançar o melhor resultado. Por exemplo, precisamos apenas de um espaço mínimo para deixar mais para um crescimento adicional. Ou talvez tenhamos liberdade para escolher a altura dos racks, a potência por rack, os soquetes na PDU, o número de racks em um grupo de comutadores (um comutador por 1, 2 ou 3 racks), o comprimento dos fios e o trabalho de puxar (isso é fundamental no final das linhas: com 10 racks em uma linha e 3 racks em um switch, você terá que puxar os fios em outra linha ou subutilizar as portas no switch), etc., etc. Histórias separadas: seleção de servidor e seleção de DC, assumimos que elas foram selecionadas.
Seria bom entender algumas das nuances e detalhes, em particular, o consumo médio / máximo de servidores e como somos fornecidos com eletricidade. Portanto, se tivermos uma fonte de alimentação russa de 230V e uma fase por rack, uma máquina de 32A poderá armazenar ~ 7kW. Suponha que pagamos nominalmente por 6kW por rack. Se um fornecedor mede nosso consumo apenas para uma série de 10 racks, e não para cada rack, e se a máquina estiver com um corte convencional de 7 kW, então tecnicamente podemos engordar 6,9 kW em um rack separado, em outros 5,1 kW e tudo ficará bem - não é punível.
Normalmente, nosso principal objetivo é minimizar os custos. O melhor critério de medição é a redução no TCO (custo total de propriedade). Consiste nas seguintes peças:
- CAPEX: aquisição de infraestrutura de DC, servidores, hardware de rede e cabeamento
- OPEX: aluguel de DC, eletricidade consumida, manutenção. O OPEX depende da vida útil. É razoável supor que é igual a 3 anos.
Dependendo do tamanho das peças individuais em todo o bolo, precisamos otimizar o mais caro e deixar o restante usar todos os recursos restantes da maneira mais eficiente possível.
Suponha que tenhamos um controlador de domínio existente, haja uma altura do rack de unidades H (por exemplo, H = 47), eletricidade no rack P do
rack (
rack P = 6 kW) e decidimos usar h = 2U servidores de duas unidades. Removemos 2..4 unidades do rack para os switches, patch panels e organizadores. I.e. fisicamente, temos S
h = rounddown ((H-2..4) / h) servidores em nosso rack (ou seja, S
h = rounddown ((47-4) / 2) = 21 servidores por rack). Lembre-se de que é S
h .
No caso simples, todos os servidores no rack são os mesmos. Total, se conectarmos o rack aos servidores, em cada servidor poderemos gastar, em média, a potência P
serv = P
rack / S
h (P
serv = 6000 W / 21 = 287 W). Por simplicidade, ignoramos o consumo do comutador aqui.
Damos um passo para o lado e determinamos qual é o consumo máximo do servidor P
máx . Se for muito simples, ineficiente e completamente seguro, lemos o que está escrito na fonte de alimentação do servidor - é isso.
Se for mais complicado, mais eficiente, pegamos o TDP (pacote de design térmico) de todos os componentes e resumimos (isso não é muito verdade, mas pode ser).
Geralmente, como não conhecemos os componentes TDP (exceto a CPU), adotamos a abordagem mais correta, mas também a mais difícil (precisamos de um laboratório) - pegamos um servidor experimental da configuração necessária e carregamos, por exemplo, com Linpack (CPU e memória) e fio (discos) medir consumo. Se você levar a sério, também precisará criar o ambiente mais quente no corredor frio durante os testes, pois isso afetará o consumo do ventilador e o CPU. Obtemos o consumo máximo de um servidor específico com uma configuração específica nessas condições específicas sob essa carga específica. Apenas queremos dizer que o novo firmware do sistema, outra versão do software, outras condições podem afetar o resultado.
No total, retornamos a P
serv e como comparamos com P
max . Essa é uma questão de entender como os serviços funcionam e como são fortes os nervos do técnico.
Se você não arriscar, acreditamos que todos os servidores podem começar imediatamente a consumir o máximo. Ao mesmo tempo, uma entrada para o DC pode ser formada. A infra-estrutura nessas condições deve fornecer um serviço, portanto, P
serv ≡ P
max . Essa é uma abordagem em que a confiabilidade é absolutamente crucial.
Se o techdir pensa não apenas na segurança perfeita, mas também no dinheiro da empresa e é bastante corajoso, podemos decidir que
- começamos a gerenciar nossos fornecedores, em particular, proibimos a manutenção programada nos horários de pico de carga planejado para minimizar a queda em uma entrada;
- e / ou nossa arquitetura permite que você perca o rack / row / DC, e os serviços continuam funcionando;
- e / ou distribuímos a carga horizontalmente pelos racks, para que nossos serviços nunca atinjam o consumo máximo em um rack juntos.
É muito útil aqui não apenas para adivinhar, mas para monitorar o consumo e saber como realmente em condições normais e de pico os servidores consomem eletricidade. Portanto, após algumas análises, o techdir comprime tudo o que possui e diz: “aceitamos voluntariamente que a média máxima alcançável do consumo máximo do servidor por rack é ** muito ** abaixo do consumo máximo", condicionalmente P
serv = 0,8 * P
máx .
E, em um rack de 6kW, não há mais 16 servidores com P
max = 375W, mas 20 servidores com P
serv = 375W \ * 0,8 = 300W. I.e. 25% mais servidores. Essa é uma economia muito grande - afinal, precisamos imediatamente de 25% menos racks (também economizamos em PDUs, comutadores e cabos). Um ponto negativo grave dessa decisão - é necessário monitorar constantemente que nossas suposições ainda são verdadeiras. Que a nova versão do firmware não altera significativamente a operação dos ventiladores e o consumo, que o desenvolvimento de uma nova versão repentinamente não começou a usar o servidor com muito mais eficiência (leia-se, temos mais carga e mais consumo no servidor). Afinal, nossas premissas e conclusões iniciais se tornam imediatamente incorretas. Esse é um risco que deve ser assumido com responsabilidade (ou evitado e, em seguida, pago pelos racks obviamente sobrecarregados).
Uma observação importante - você deve tentar distribuir servidores de diferentes serviços em racks horizontalmente, se possível. Isso é necessário para que as histórias não aconteçam quando um lote de servidores para um serviço chegar, os racks ficarão obstruídos verticalmente para aumentar a "densidade" (porque é mais fácil). Na realidade, verifica-se que um rack está abarrotado com os mesmos servidores de baixa carga de um serviço e o outro é igualmente carregado com muita carga. A probabilidade de uma queda do segundo é muito maior, porque o perfil de carga é o mesmo e todos os servidores juntos nesse rack começam a consumir a mesma quantidade como resultado do aumento da carga.
Voltar para a distribuição de servidores nos racks. Examinamos as limitações físicas do espaço em rack e das limitações de energia e agora examinamos a rede. Você pode usar comutadores nas portas 24/32/48 N (por exemplo, temos comutadores ToR de 48 portas). Felizmente, não há muitas opções se você não pensa em cabos quebrados. Consideramos os cenários em que temos um comutador por rack, um comutador para dois ou três racks no grupo R
líquido . Parece-me que mais de três racks no grupo já são demais, porque o problema de cabeamento entre racks se torna muito maior.
Portanto, para cada cenário de rede (1, 2 ou 3 racks em um grupo), distribuímos o servidor em racks:
Rack S = min (S
h , arredondamento (
rack P /
serviço P), arredondamento (
rede N / R))
Assim, para a opção com 2 racks no grupo:
S
rack 2 = min (21, arredondamento (6000/300), arredondamento (48/2)) = min (21, 20, 24) = 20 servidores por rack.
Da mesma forma, consideramos as opções restantes:
S
rack 1 = 20
S
rack 3 = 16
E nós estamos quase lá. Contamos o número de racks para a distribuição de todos os nossos servidores S (seja 1000):
R = arredondamento (S / (
rack S * R
líquido )) * R
líquidoR
1 = arredondamento (1000 / (20 * 1)) * 1 = 50 * 1 = 50 racks
R
2 = arredondamento (1000 / (20 * 2)) * 2 = 25 * 2 = 50 racks
R
3 = arredondamento (1000 / (16 * 3)) * 3 = 21 * 3 = 63 racks
Em seguida, consideramos o custo total de propriedade para cada opção com base no número de racks, no número necessário de comutadores, cabos, etc. Escolhemos a opção em que o custo total de propriedade é menor. Lucro!
Observe que, embora o número necessário de racks para as opções 1 e 2 seja o mesmo, o preço será diferente, pois o número de comutadores para a segunda opção é metade e o comprimento dos cabos necessários é maior.
PS Se houver uma oportunidade de jogar energia em um rack e na altura do rack, a variabilidade aumenta. Mas o processo pode ser reduzido ao acima, apenas classificando as opções. Sim, haverá mais combinações, mas ainda assim um número muito limitado - a potência do rack para cálculo pode ser aumentada em incrementos de 1 kW, os racks típicos têm um número limitado de tamanhos: 42U, 45U, 47U, 48U, 48U, 52U. E aqui a análise de variações hipotéticas do Excel no modo Tabela de dados pode ajudar a calcular. Olhamos para as placas recebidas e selecionamos o mínimo.