Recentemente, um colega me perguntou em um bate-papo:
- Existe um artigo sobre como empacotar servidores corretamente nos racks?
Percebi que não sabia disso. Então, eu decidi escrever meu texto.
Primeiro, este é um artigo sobre servidores bare metal nas instalações de data center (DC). Em segundo lugar, estimamos que existem muitos servidores (centenas ou milhares); o artigo não faz sentido para menos quantidades. Em terceiro lugar, consideramos que há três restrições nos racks: espaço físico, energia elétrica por cada um e armários permanecem nas fileiras adjacentes um ao outro, para que possamos usar um único switch ToR para conectar servidores neles.
A resposta à pergunta original depende significativamente do parâmetro que estamos otimizando e do que podemos mudar para obter um resultado melhor. Por exemplo, precisamos usar menos espaço para deixar mais para crescimento futuro. Ou talvez tenhamos liberdade na seleção de altura do gabinete, potência por rack, número de soquetes por PDU, número de gabinetes por grupo de switches (um switch por 1, 2 ou 3 racks), comprimentos de cabos e trabalhos de cabeamento. O último componente é essencial para as filas de fim de rack, nas quais precisamos puxar cabos para a outra linha ou deixar portas subutilizadas no comutador. Histórias completamente diferentes são a seleção de servidores e a central de dados. Devemos considerar que já os escolhemos.
É bom entender algumas nuances e detalhes, em particular, o consumo médio / máximo de energia do servidor e como nosso fornecedor fornece eletricidade. Portanto, se tivermos uma fonte de alimentação de 230V 1phase, um disjuntor de 32Amps pode suportar até 7kW. Digamos que pagamos formalmente por 6kW por rack. Se um fornecedor mede nosso consumo de energia por fileira de 10 gabinetes, não por um único, e se os disjuntores limitam a potência em 7kW, podemos usar 6,9kW em um rack e 5,1kW em outro. Será ok e impune.
Geralmente, nosso principal objetivo é minimizar os gastos. O melhor critério de medição é a redução do custo total de propriedade (TCO). Consiste nas seguintes partes:
- CAPEX: compra de infraestrutura de data center, servidores, dispositivos de rede, cabeamento
- OPEX: aluguel de DC, consumo de eletricidade, manutenção. OPEX depende da vida útil. É razoável supor que uma vida útil seja igual a 3 anos.
Devemos otimizar as partes mais caras da torta. Todo o resto deve usar os recursos restantes da maneira mais eficaz possível.
Supostamente, temos um CC existente, altura do rack de unidades H (por exemplo, H = 47), energia por rack P de
rack (
rack P = 6kW) e decidimos usar h = 2U servidores de duas unidades. Vamos remover de 2 a 4 unidades do rack para switches, patch panels, gerenciadores de cabos. Em seguida, podemos instalar servidores S
h = arredondamento ((H-2..4) / h) em um rack (ou seja, S
h = arredondamento ((47-4) / 2) = 21 servidores por rack)). Vamos memorizar S
h .
Em um caso simples, todos os servidores são iguais. Portanto, se enchermos um rack por servidores, podemos gastar por servidor uma potência média de P
serv = P
rack / S
h (P
serv = 6000W / 21 = 287W). Ignoramos o consumo de energia da chave aqui.
Vamos nos afastar e definir qual é o consumo máximo de energia do servidor P
max . A maneira direta, completamente segura e altamente ineficiente é ler o que uma etiqueta na fonte de alimentação do servidor diz. Aqui está P
máx .
Uma abordagem mais complicada e eficiente é pegar o TDP de todos os componentes e resumir. Não é preciso, mas podemos fazer dessa maneira.
Normalmente, não conhecemos o TDP dos componentes além da CPU. Portanto, a abordagem mais correta e mais complicada é pegar um servidor experimental adequadamente configurado, carregá-lo, por exemplo, por / Linpack / (CPU e memória) e / fio / (discos) e medir o consumo de energia. Precisamos de um laboratório neste caso. Se levarmos as coisas a sério, devemos criar um ambiente quente no corredor frio, porque uma temperatura mais alta afeta os ventiladores e o consumo de energia da CPU. Portanto, obtemos o consumo máximo de energia do servidor de amostra com essa configuração específica no ambiente atual sob a carga específica. Lembre-se de que um novo firmware, versão de software e outras condições podem afetar o resultado.
Agora, voltemos ao P
serv e como devemos compará-lo com P
max . É uma questão de entender como os serviços funcionam e quão fortes são os nervos do nosso CTO.
Se não aceitarmos nenhum risco, devemos assumir que todos os servidores podem começar a consumir seu potencial máximo simultaneamente. Ao mesmo tempo, um dos feeds DC também pode falhar. A infraestrutura ainda deve fornecer o serviço. Então, P
serv ≡ P
max . É a abordagem em que a confiabilidade é altamente importante.
Se o CIO levar em conta não apenas a segurança ideal, mas também o dinheiro da empresa, se for corajoso o suficiente, poderá decidir que
- começamos a gerenciar nossos fornecedores, em particular, proibimos qualquer manutenção planejada nos períodos de alta carga esperada para minimizar a falta de energia
- e / ou nossa arquitetura nos permite perder um rack / linha / DC enquanto os serviços continuam operações
- e ou distribuímos a carga pelos racks horizontalmente tão bem que nossos servidores em um único gabinete nunca consumirão seu máximo teórico juntos.
É vantajoso não apenas adivinhar aqui, mas monitorar o consumo de energia e entender como os servidores consomem energia durante cargas normais e de pico. Assim e assim, após algumas análises, o CIO trabalha e diz:
"Eu ordeno que a média máxima alcançável de todo o consumo máximo de energia do servidor seja
muito menor que o consumo máximo do servidor único". Seja P
serv = 0.8 * P
maxE então um rack de 6kW pode acomodar não 16 servidores de P
max = 375W, mas 20 servidores de P
serv = 375W * 0,8 = 300W. Ou seja, 25% mais servidores. É uma economia real, porque precisamos de 25% menos racks. E podemos economizar em PDUs, interruptores e cabos de rack. Uma séria desvantagem da solução é a necessidade de verificar continuamente se nossas suposições ainda são válidas. Devemos garantir que um novo firmware não altere significativamente a operação do ventilador e o consumo de energia, para que a equipe de desenvolvimento não comece a usar os servidores com muito mais eficiência (significa que eles conseguiram aumentar a utilização e o consumo de energia). Então, ambas as suposições e conclusões iniciais se tornam erradas. Portanto, é o risco de ser aceito com responsabilidade. Ou o risco pode ser evitado e a empresa paga pelos racks obviamente sobrecarregados.
Uma observação importante: vale a pena tentar distribuir diferentes servidores de serviços pelos racks horizontalmente, se possível. É necessário evitar casos em que vários servidores para serviço chegam e são instalados nos gabinetes verticalmente para melhorar a "densidade" (apenas porque é mais fácil fazer isso). De fato, isso leva à situação em que um rack é preenchido com os mesmos servidores de baixa carga, enquanto todos os altamente carregados residem em outro. Quando o perfil de carga é o mesmo e todos os servidores começam a consumir igualmente muito simultaneamente devido à alta carga, a probabilidade de perder o segundo rack se torna muito maior.
Vamos voltar à distribuição do servidor nos racks. Consideramos restrições físicas nos armários e limitações de energia. Agora vamos considerar a rede. Pode-se usar N = switches de 24/32/48 portas (assumindo switches ToR de 48 portas). Felizmente, não existem tantas opções se ignorarmos os cabos quebrados. Consideramos as opções de um switch em cada rack, um switch para dois ou três armários por grupo (R
net ). Eu acredito que o grupo não deve ter três anos. Caso contrário, isso leva a problemas de cabeamento.
Portanto, distribuímos servidores pelos racks para cada cenário de rede (1, 2 ou 3 racks por grupo):
Rack S = min (S
h , arredondamento (
rack P /
serviço P), arredondamento (
rede N / R))
Assim, um cenário de grupo de dois racks é
S
rack 2 = min (21, arredondamento (6000/300), arredondamento (48/2)) = min (21, 20, 24) = 20 servidores por rack
Da mesma forma, contamos os outros cenários:
S
rack 1 = 20
S
rack 3 = 16
Estamos quase terminando. Devemos contar a quantidade total de racks para distribuir todos os servidores S (que sejam 1000 servidores):
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
2 = arredondamento (1000 / (16 * 3)) * 3 = 21 * 3 = 63 racks
Em seguida, devemos contar o custo total de propriedade para cada opção com base no número de racks, interruptores necessários, cabeamento etc. Escolhemos o cenário com o menor custo total de propriedade. Lucro!
Observe que, embora o número de racks para os cenários 1 e 2 seja o mesmo, o TCO é diferente devido à quantidade duas vezes menor de comutadores e cabos mais longos para o segundo cenário.
PS Se a potência por rack ou a altura do rack puder variar, a variabilidade aumentará. Mas a seleção pode ser reduzida ao método acima por força bruta das opções. Haverá mais cenários, mas sua quantidade será limitada. Podemos aumentar a energia por rack em etapas de 1kW, e há um número limitado de tipos de rack padrão: de 42U, 45U, 47U, 48U. Pode ser útil usar a análise de variações hipotéticas do Excel no modo Tabela de dados. Devemos olhar para a tabela resultante e selecionar a melhor opção.