Em um dos chats me fizeram uma pergunta:
— Há algo que eu possa ler sobre como empacotar corretamente os servidores em racks?
Percebi que não conhecia esse texto, então escrevi o meu próprio.
Primeiramente, este texto trata de servidores físicos em data centers físicos (DCs). Em segundo lugar, acreditamos que existem muitos servidores: centenas de milhares; para um número menor este texto não faz sentido. Terceiro, consideramos que temos três restrições: espaço físico nos racks, fonte de alimentação por rack e deixar os racks alinhados para que possamos usar um switch ToR para conectar servidores em racks adjacentes.
A resposta à pergunta depende muito de qual parâmetro estamos otimizando e do que podemos variar para obter o melhor resultado. Por exemplo, só precisamos ocupar um mínimo de espaço para deixar mais para um maior crescimento. Ou talvez tenhamos liberdade na escolha da altura dos racks, potência por rack, soquetes na PDU, quantidade de racks em um grupo de switches (um switch para 1, 2 ou 3 racks), comprimento dos fios e trabalho de tração ( isso é crítico nas extremidades das linhas: com 10 racks em uma linha e 3 racks por switch, você terá que puxar os fios para outra linha ou subutilizar as portas no switch), etc., etc. Histórias separadas: seleção de servidores e seleção de DCs, assumiremos que eles estão selecionados.
Seria bom compreender algumas nuances e detalhes, em particular, o consumo médio/máximo dos servidores, e como a eletricidade nos é fornecida. Portanto, se tivermos uma fonte de alimentação russa de 230 V e uma fase por rack, uma máquina de 32 A pode suportar aproximadamente 7 kW. Digamos que pagamos nominalmente 6kW por rack. Se o fornecedor medir nosso consumo apenas para uma linha de 10 racks, e não para cada rack, e se a máquina estiver configurada para um corte condicional de 7 kW, então tecnicamente poderemos consumir 6.9 kW em um único rack, 5.1 kW em outro e tudo ficará bem - não é punível.
Normalmente nosso principal objetivo é minimizar custos. O melhor critério para medir é a redução do TCO (custo total de propriedade). É composto pelas seguintes peças:
- CAPEX: aquisição de infraestrutura DC, servidores, hardware de rede e cabeamento
- OPEX: aluguel de DC, consumo de energia elétrica, manutenção. OPEX depende da vida útil. É razoável supor que seja de 3 anos.
Dependendo do tamanho das peças individuais no bolo geral, precisamos otimizar as mais caras e deixar que o resto utilize todos os recursos restantes da forma mais eficiente possível.
Digamos que temos um DC existente, há uma altura de rack de H unidades (por exemplo, H=47), eletricidade por rack Prack (Prack=6kW) e decidimos usar h=2U servidores de duas unidades. Removeremos 2 a 4 unidades do rack para interruptores, painéis de conexão e organizadores. Aqueles. fisicamente, temos servidores Sh=rounddown((H-2..4)/h) em nosso rack (ou seja, Sh = rounddown((47-4)/2)=21 servidores por rack). Vamos lembrar disso Sh.
No caso simples, todos os servidores em um rack são idênticos. No total, se enchermos um rack com servidores, então em cada servidor poderemos gastar em média a potência Pserv=Prack/Sh (Pserv = 6000W/21 = 287W). Para simplificar, ignoramos aqui o consumo de switch.
Vamos dar um passo de lado e determinar qual é o Pmax máximo de consumo do servidor. Se for muito simples, muito ineficaz e totalmente seguro, então lemos o que está escrito na fonte de alimentação do servidor - é isso.
Se for mais complexo e mais eficiente, então pegamos o TDP (pacote de design térmico) de todos os componentes e somamos (isso não é muito verdade, mas é possível).
Normalmente não conhecemos o TDP dos componentes (exceto CPU), então adotamos a abordagem mais correta, mas também a mais complexa (precisamos de um laboratório) - pegamos um servidor experimental com a configuração necessária e carregamos isto, por exemplo, com Linpack (CPU e memória) e fio (discos), medimos o consumo. Se levarmos isso a sério, também precisamos criar o ambiente mais quente no corredor frio durante os testes, porque isso afetará tanto o consumo do ventilador quanto o consumo da CPU. Obtemos o consumo máximo de um servidor específico com uma configuração específica nestas condições específicas sob esta carga específica. Queremos simplesmente dizer que um novo firmware do sistema, uma versão de software diferente e outras condições podem afetar o resultado.
Então, voltando ao Pserv e como o comparamos com o Pmax. É uma questão de entender como funcionam os serviços e quão fortes estão os nervos do seu diretor técnico.
Se não corrermos nenhum risco, acreditamos que todos os servidores podem começar a consumir simultaneamente o seu máximo. Ao mesmo tempo, pode ocorrer uma entrada no DC. Mesmo nessas condições, a infra deve prestar serviço, portanto Pserv ≡ Pmax. Esta é uma abordagem onde a confiabilidade é absolutamente importante.
Se o diretor de tecnologia pensar não apenas na segurança ideal, mas também no dinheiro da empresa e for corajoso o suficiente, então você pode decidir que
- Estamos começando a gerenciar nossos fornecedores, principalmente, estamos proibindo manutenções programadas em horários de pico de carga planejado para minimizar a queda de um insumo;
- e/ou nossa arquitetura permite que você perca um rack/linha/DC, mas os serviços continuam funcionando;
- e/ou distribuímos bem a carga horizontalmente pelos racks, para que nossos serviços nunca saltem para o consumo máximo em um rack todos juntos.
Aqui é muito útil não apenas adivinhar, mas monitorar o consumo e saber como os servidores realmente consomem eletricidade em condições normais e de pico. Portanto, após algumas análises, o diretor técnico aperta tudo o que tem e diz: “tomamos uma decisão voluntária de que a média máxima alcançável do consumo máximo do servidor por rack está **muito** abaixo do consumo máximo”, condicionalmente Pserv = 0.8* Pmáx.
E então um rack de 6kW não pode mais acomodar 16 servidores com Pmax = 375W, mas 20 servidores com Pserv = 375W * 0.8 = 300W. Aqueles. 25% mais servidores. Esta é uma economia muito grande - afinal, precisamos imediatamente de 25% menos racks (e também economizaremos em PDUs, switches e cabos). Uma séria desvantagem de tal solução é que devemos monitorar constantemente se as nossas suposições ainda estão corretas. Que a nova versão do firmware não altera significativamente o funcionamento das ventoinhas e o consumo, que o desenvolvimento repentinamente com o novo lançamento não passou a utilizar os servidores com muito mais eficiência (leia-se: conseguiram maior carga e maior consumo no servidor). Afinal, tanto nossas suposições quanto nossas conclusões iniciais tornam-se imediatamente incorretas. Este é um risco que deve ser assumido com responsabilidade (ou evitado e depois pagar por racks obviamente subutilizados).
Uma observação importante: você deve tentar distribuir servidores de diferentes serviços horizontalmente entre racks, se possível. Isso é necessário para que não ocorram situações em que chega um lote de servidores para um serviço, os racks são embalados verticalmente com ele para aumentar a “densidade” (porque assim é mais fácil). Na realidade, acontece que um rack está preenchido com servidores idênticos de baixa carga do mesmo serviço e o outro está preenchido com servidores igualmente de alta carga. A probabilidade da segunda queda é significativamente maior, porque o perfil de carga é o mesmo e todos os servidores juntos neste rack começam a consumir a mesma quantidade como resultado do aumento de carga.
Voltemos à distribuição dos servidores em racks. Vimos o espaço físico do rack e as limitações de energia, agora vamos dar uma olhada na rede. Você pode usar switches com portas 24/32/48 N (por exemplo, temos switches ToR de 48 portas). Felizmente, não há muitas opções se você não pensar em cabos break-out. Estamos considerando cenários em que temos um switch por rack, um switch para dois ou três racks no grupo Rnet. Parece-me que mais de três racks num grupo já é demais, porque... o problema do cabeamento entre racks torna-se muito maior.
Assim, para cada cenário de rede (1, 2 ou 3 racks em grupo), distribuímos os servidores entre os racks:
Srack = min(Sh, arredondamento(Prack/Pserv), arredondamento(N/Rnet))
Assim, para a opção com 2 racks em grupo:
Srack2 = min(21, rounddown(6000/300), rounddown(48/2)) = min(21, 20, 24) = 20 servidores por rack.
Consideramos as opções restantes da mesma maneira:
Srack1 = 20
Srack3 = 16
E estamos quase lá. Contamos o número de racks para distribuir todos os nossos servidores S (seja 1000):
R = arredondamento(S / (Srack * Rnet)) * Rnet
R1 = arredondamento(1000 / (20 * 1)) * 1 = 50 * 1 = 50 racks
R2 = arredondamento(1000 / (20 * 2)) * 2 = 25 * 2 = 50 racks
R3 = arredondamento(1000 / (16 * 3)) * 3 = 25 * 2 = 63 racks
A seguir, calculamos o TCO para cada opção com base no número de racks, no número necessário de switches, cabeamento, etc. Escolhemos a opção onde o TCO é menor. Lucro!
Observe que embora o número necessário de racks para as opções 1 e 2 seja o mesmo, seu preço será diferente, pois o número de switches para a segunda opção é a metade e o comprimento dos cabos necessários é maior.
PS Se você tiver a oportunidade de brincar com a potência por rack e a altura do rack, a variabilidade aumenta. Mas o processo pode ser reduzido ao descrito acima simplesmente percorrendo as opções. Sim, haverá mais combinações, mas ainda um número muito limitado - a fonte de alimentação do rack para cálculo pode ser aumentada em etapas de 1 kW, os racks típicos vêm em um número limitado de tamanhos padrão: 42U, 45U, 47U, 48U , 52U. E aqui a análise de variações hipotéticas do Excel no modo Tabela de dados pode ajudar nos cálculos. Olhamos as placas recebidas e escolhemos o mínimo.
Fonte: habr.com