Em um dos chats, me fizeram uma pergunta:
— Existe algo que eu possa ler sobre como empacotar servidores em racks corretamente?
Percebi que não conhecia esse tipo de texto, então escrevi o meu.
Primeiro, este texto é sobre servidores físicos em data centers (DC) físicos. Em segundo lugar, vamos considerar que existem muitos servidores: centenas ou milhares; para um número menor, esse texto não faz sentido. Em terceiro lugar, vamos assumir que temos três limitações: espaço físico nos racks, energia elétrica por rack, e vamos supor que os racks estejam organizados em filas, de modo que possamos usar um switch ToR para conectar servidores em racks adjacentes.
A resposta para a pergunta depende muito do parâmetro que estamos otimizando e do que podemos variar para alcançar o melhor resultado. Por exemplo, podemos precisar ocupar o mínimo de espaço para deixar mais espaço para um futuro crescimento. Ou talvez tenhamos liberdade para escolher a altura dos racks, a potência por rack, as tomadas no PDU, o número de racks em um grupo de switches (um switch para 1, 2 ou 3 racks), o comprimento dos cabos e o trabalho de cabeamento (isso é crítico nas extremidades das filas: com 10 racks em uma fila e 3 racks para um switch, será necessário puxar os cabos para outra fila ou desperdiçar portas no switch), etc., etc. Histórias separadas: a escolha de servidores e a escolha de DCs, vamos assumir que já foram escolhidos.
Seria bom entender alguns nuances e detalhes, em particular, o consumo médio/máximo dos servidores e como a eletricidade é fornecida a nós. Assim, se tivermos uma alimentação russa de 230V e uma fase por rack, um disjuntor de 32A pode suportar cerca de 7kW. Suponhamos que nominalmente paguemos por 6kW por rack. Se o provedor medir o nosso consumo apenas por uma fila de 10 racks, e não por cada rack, e se o disjuntor estiver configurado com um limite de cerca de 7kW, então, tecnicamente, podemos consumir 6.9kW em um rack isolado, 5.1kW em outro e tudo estará bem — sem penalidades.
Normalmente, nosso principal objetivo é a minimização de custos. O melhor critério para medir isso é a redução do TCO (custo total de propriedade). Ele é composto pelas seguintes partes:
- CAPEX: aquisição da infraestrutura do DC, servidores, equipamentos de rede e cabeamento
- OPEX: aluguel do DC, eletricidade consumida, manutenção. O OPEX depende do tempo de vida útil. É razoável supor que ele seja igual a 3 anos.
Dependendo de como são grandes as partes individuais do todo, precisamos otimizar o mais caro, enquanto o restante deve utilizar todos os recursos restantes da forma mais eficaz possível.
Suponhamos que já temos um DC existente, temos a altura do rack H em unidades (por exemplo, H=47), a eletricidade por rack Prack (Prack=6kW), e decidimos usar servidores de 2U com h=2U. Vamos remover de 2 a 4 unidades do rack para switches, painéis de patch e organizadores. Isso significa que, fisicamente, o número de servidores que podemos ter no rack será Sh=rounddown((H-2..4)/h) (ou seja, Sh = rounddown((47-4)/2)=21 servidores por rack). Vamos lembrar disso Sh.
No caso mais simples, todos os servidores no rack são iguais. Portanto, se formos encher o rack servidores, conseguiremos gastar em média uma potência Pserv=Prack/Sh (Pserv = 6000W/21 = 287W) por servidor. Para simplificar, ignoramos aqui o consumo do switch.
Vamos dar um passo para o lado e definir o que é o consumo máximo de um servidor Pmax. Se formos muito simples, muito ineficientes e totalmente seguros, veremos o que está escrito na fonte de alimentação do servidor — este é o valor.
Se for um pouco mais complicado e mais eficiente, pegamos o TDP (pacote de design térmico) de todos os componentes e somamos (isso não é muito preciso, mas pode ser feito assim).
Normalmente, não conhecemos o TDP dos componentes (exceto CPU), então adotamos a abordagem mais precisa, embora a mais complicada (é necessária uma laboratório) — pegamos um servidor experimental na configuração desejada e o submetemos a carga, por exemplo, com Linpack (CPU e memória) e fio (discos), e medimos o consumo. Se quisermos levar a sério, devemos também criar o ambiente mais quente no corredor frio durante os testes, porque isso afeta tanto o consumo dos ventiladores quanto o dos CPUs. 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. Basta lembrarmos que um novo firmware do sistema, outra versão de software ou outras condições podem afetar o resultado.
Em suma, voltamos a Pserv e como podemos compará-lo a Pmax. Essa é uma questão de entender o funcionamento dos serviços e quão firmes são os nervos do seu diretor técnico.
Se realmente não quisermos correr riscos, devemos considerar que todos os servidores podem, ao mesmo tempo, começar a consumir seu máximo. Nesse mesmo momento, pode haver uma única entrada no DC. A infraestrutura, nessas condições, deve fornecer serviço, portanto, Pserv ≡ Pmax. Esta é uma abordagem onde a confiabilidade é absolutamente crucial.
Se o diretor técnico pensa não apenas na segurança ideal, mas também no dinheiro da empresa e é suficientemente ousado, pode-se concluir que
- começamos a gerenciar nossos fornecedores, em particular, proibindo a realização de manutenção programada durante períodos de carga pico planejada para minimizar a queda de um ponto de entrada;
- e/ou nossa arquitetura permite perder um rack/linha/data center, enquanto os serviços continuam operando;
- e/ou distribuímos bem a carga horizontalmente entre os racks, de modo que nossos serviços nunca atinjam o consumo máximo em um único rack ao mesmo tempo.
Aqui é muito útil não apenas especular, mas monitorar o consumo e saber como, na verdade, os servidores consomem eletricidade em condições normais e de pico. Portanto, após uma certa análise, o diretor técnico compacta tudo o que tem e diz: "decidimos por vontade própria que a média máxima alcançável dos máximos de consumo dos servidores por rack é **tanto** abaixo do consumo máximo", ou seja, Pserv=0.8*Pmax.
E então, em um rack de 6kW, não cabem mais 16 servidores com Pmax = 375W, mas 20 servidores com Pserv = 375W * 0.8 = 300W. Ou seja, 25% a mais de servidores. Isso gera uma grande economia — pois precisamos de 25% menos racks imediatamente (e ainda economizaremos em PDU, switches e cabos). Uma desvantagem séria dessa solução é que precisamos monitorar constantemente se nossas suposições ainda são válidas. Se uma nova versão de firmware não altera substancialmente o funcionamento dos ventiladores e o consumo, ou se o desenvolvimento, de repente, com um novo lançamento, começa a usar os servidores de maneira muito mais eficiente (ou seja, alcançando maior carga e maior consumo nos servidores). Nesse caso, tanto nossas suposições iniciais quanto as conclusões tornam-se imediatamente falsas. Esse é um risco que deve ser assumido com responsabilidade (ou evitado, e então pagar por racks claramente subutilizados).
Nota importante: deve-se tentar distribuir servidores de diferentes serviços horizontalmente entre os racks, se possível. Isso é necessário para evitar situações em que um lote de servidores de um único serviço chega e os racks ficam verticalmente lotados para aumentar a "densidade" (porque é mais fácil assim). Na realidade, ocorre que um rack está cheio de servidores de baixa carga do mesmo serviço, enquanto outro tem servidores de alta carga igualmente. A probabilidade de falha do segundo é substancialmente maior, pois o perfil de carga é o mesmo, e todos os servidores nesse rack começam a consumir a mesma quantidade devido ao aumento da carga.
Voltando à distribuição de servidores nos racks. Consideramos as limitações físicas de espaço nos racks e as limitações de fornecimento de energia; agora vamos analisar a rede. Podemos usar switches de 24/32/48 portas N (por exemplo, temos switches ToR de 48 portas). Felizmente, não há muitas opções, se não pensarmos em cabos break-out. Vamos considerar cenários em que temos um switch por rack, um switch para dois ou três racks em um grupo Rnet. Acho que mais de três racks em um grupo é demais, pois o problema de cabeamento entre os racks se torna muito maior.
Assim, para cada cenário de rede (1, 2 ou 3 racks em grupo), distribuímos os servidores pelos racks:
Srack = min(Sh, rounddown(Prack/Pserv), rounddown(N/Rnet))
Portanto, para a opção com 2 racks no grupo:
Srack2 = min(21, rounddown(6000/300), rounddown(48/2)) = min(21, 20, 24) = 20 servidores por rack.
Da mesma forma, calculamos as outras opções:
Srack1 = 20
Srack3 = 16
E estamos praticamente lá. Vamos calcular o número de racks para distribuir todos os nossos servidores S (vamos assumir 1000):
R = roundup(S / (Srack * Rnet)) * Rnet
R1 = roundup(1000 / (20 * 1)) * 1 = 50 * 1 = 50 racks
R2 = roundup(1000 / (20 * 2)) * 2 = 25 * 2 = 50 racks
R3 = roundup(1000 / (16 * 3)) * 3 = 25 * 2 = 63 racks
Em seguida, calculamos o TCO para cada opção com base no número de racks, no número necessário de switches, no cabeamento, etc. Escolhemos a opção com o menor TCO. Lucro!
Observe que, embora o número necessário de racks para as opções 1 e 2 seja o mesmo, seu custo será diferente, já que o número de switches para a segunda opção é metade, enquanto o comprimento dos cabos necessários é maior.
P.S. Se houver a possibilidade de ajustar a potência do rack e a altura do rack, a variabilidade aumenta. Mas o processo pode ser reduzido ao descrito acima, simplesmente testando as opções. Sim, haverá mais combinações, mas ainda assim um número bastante limitado - a alimentação do rack para cálculo pode ser aumentada em incrementos de 1 kW, as racks padrão têm um número limitado de tamanhos: 42U, 45U, 47U, 48U, 52U. Aqui, uma análise What-If do Excel no modo Tabela de Dados pode ajudar no cálculo. Observamos as tabelas obtidas e escolhemos o mínimo.
Fonte: habr.com
