Guia do datacenter menos eficiente do mundo

O que você está a construir

Todos os guias deste site ensinam a fazer algo corretamente: os comandos pela ordem certa, o aspeto de um resultado correto e os modos de falha identificados. Este guia é diferente. Hoje, inteiramente por hipótese, vamos conceber o datacenter menos eficiente que o dinheiro, a eletricidade e a arrogância conseguem produzir.

Precisamos de uma métrica, por isso vamos usar a da própria indústria: PUE, Power Usage Effectiveness, ou eficiência no uso de energia, calculada dividindo a potência total da instalação pela potência que chega efetivamente ao equipamento informático. Um datacenter hyperscale funciona com cerca de 1.1: quase todos os watts realizam trabalho útil. Uma sala de servidores empresarial razoável consegue 1.5. O nosso objetivo é 4.0 ou superior, o que significa que, por cada watt usado na computação, mais três watts são desperdiçados. Vamos referir-nos frequentemente a este número, tal como os guias sérios se referem às cópias de segurança.

Seleção do local: o calor é o objetivo

A refrigeração é o maior custo operacional isolado de um datacenter real, por isso o nosso vai enfrentar a termodinâmica no seu próprio terreno. O local ideal é um sótão. Virado a sul. De preferência com uma claraboia posicionada para iluminar diretamente o servidor, para que a máquina receba tanto o seu próprio calor residual como o calor do sol: uma colaboração entre a sua fatura de eletricidade e uma estrela.

No inverno, a refrigeração é feita abrindo a janela. Os datacenters reais usam ar exterior; a técnica chama-se free cooling e é projetada, filtrada e controlada quanto à humidade. Nós vamos usá-la por acidente, através de uma janela que também deixa entrar chuva, pólen e pelo menos uma ave confusa por trimestre.

Para obter verdadeira excelência, instale um ar condicionado e depois coloque um aquecedor a dois pés do respetivo termóstato, regulado para uma temperatura dois graus superior ao objetivo do ar condicionado. As duas máquinas vão funcionar continuamente, para sempre, em desacordo perfeito. A empresa de eletricidade enviar-lhe-á um cartão no Natal.

Um servidor, grande e querido

A redundância dilui o compromisso. O nosso datacenter contém exatamente um servidor, e ele é enorme, porque uma única máquina com 512 GB de RAM parece infraestrutura, enquanto quatro máquinas pequenas parecem uma lista de tarefas.

O servidor tem um nome. Não um hostname, um nome. Normalmente, Gandalf ou Odin. Não é possível desativar o Odin. O Odin está ativo há cinco anos:

$ uptime
 09:14:02 up 1847 days,  3:22,  1 user,  load average: 6.41, 6.38, 6.40

Esse número é motivo de orgulho. Por isso, você faz uma captura de ecrã e publica-a. Qualquer atacante que veja a captura também o considera impressionante: 1.847 dias de atividade significam 1.847 dias de vulnerabilidades do kernel, sem que ninguém as tenha corrigido. Reiniciar está fora de questão. Um reboot é a forma de descobrir quais serviços foram iniciados manualmente em 2021 e nunca foram escritos numa unidade do systemd. Ninguém se lembra de quais são. Agora, o servidor é essencial para a estrutura organizacional.

Armazenamento: velocidade e outras formas de perder dados

Os discos estão configurados em RAID 0 para obter desempenho. O zero refere-se ao número de discos que podem falhar. Para maximizar o efeito, distribua os dados do array por armazenamento de origens mistas: dois SSD adequados, um disco mecânico antigo e uma pen USB de uma conferência. O array terá exatamente a mesma fiabilidade que a pen da conferência, e esse é o objetivo do projeto.

Os backups são tratados por um diretório no mesmo array, chamado backup_final_v2_REAL, que contém um tarball do esquema de nomenclatura anterior. Os backups externos são representados por uma nota autocolante com o texto "configurar backups externos". Tecnicamente, essa nota fica armazenada externamente quando a leva para casa na tampa do portátil.

Um resultado correto é: df a indicar 97% de utilização e um plano para resolver o problema no próximo sprint.

Rede: um único fio de tudo

O servidor DNS é executado na própria máquina. Assim, quando o servidor fica indisponível, também desaparece o registo DNS que seria usado para descobrir o motivo. Isto chama-se consolidação.

O firewall foi desativado em 2021, temporariamente, para diagnosticar um problema. O diagnóstico terminou, mas o firewall não foi reativado. Todas as portas do router são encaminhadas para o servidor “para poupar tempo mais tarde”. O painel de administração do router pode ser acedido a partir do lado WAN com a palavra-passe de fábrica, para permitir a gestão remota. A sua e a de outras pessoas.

O servidor tem funcionado a uma temperatura invulgarmente elevada ultimamente, mesmo para os padrões de um sótão, e top mostra que o processo mais ativo se chama xmrig. Presumimos que seja a ferramenta de monitorização que estamos a utilizar. Não a instalámos. Ela apareceu sozinha pouco depois de as portas serem encaminhadas, o que interpretamos como um sinal de que o ecossistema está a funcionar bem. Ela monitoriza o sistema continuamente.

A alimentação elétrica chega através de uma cadeia de extensões elétricas de consumo cuja extensão total é superior à distância a pé até ao quadro elétrico. Isto é eficiente, de certa forma, porque irá visitar o quadro elétrico com frequência.

Redundância por complexidade

Depois de recusarmos a redundância onde ela é importante, adicionamo-la onde não é. A página inicial da empresa, um único ficheiro HTML estático, é servida por um cluster Kubernetes de doze nós. Isto concretiza o que os engenheiros chamam arquitetura orientada para o currículo: a página carrega nos mesmos quarenta milissegundos que o nginx teria demorado, mas agora pode falhar de formas que exigem um consultor.

Para isolamento, o próprio cluster é executado dentro de uma máquina virtual dentro de outra máquina virtual dentro de outra máquina virtual, e cada camada acrescenta segurança, tal como cada camada de um turducken acrescenta uma ave. O formulário de contacto é composto por nove microsserviços. Dois nunca foram invocados. Um é essencial para o funcionamento e ninguém sabe qual é.

Aquecimento como serviço

Um servidor moderno converte eletricidade em computação e calor, e o objetivo é maximizar a segunda saída. Um servidor multimédia sem GPU é a abordagem clássica: transcodificar por CPU uma única transmissão 4K pode ocupar 16 núcleos e aquecer um quarto pequeno, funcionando como um aquecedor elétrico que também reproduz filmes. O operador ambicioso passa a executar um modelo de linguagem de grande dimensão na CPU, um aquecedor elétrico com 70 bilhões de parâmetros e uma API, que gera tokens a uma velocidade melhor medida por estação do ano.

O monitoriza-se a si próprio

A observabilidade é importante, por isso instalamos um monitor de disponibilidade alojado no próprio servidor, no mesmo servidor que monitoriza. Quando Odin deixa de funcionar, o monitor também deixa de funcionar, e esta é a parte elegante: não é gerado nenhum alerta. Sem alertas, não há incidentes. Sem incidentes, a disponibilidade medida é perfeita. O relatório mensal nunca teve um aspeto tão bom.

Para completar, os emails de alerta são retransmitidos através de um servidor de email que também é executado no Odin. Assim, o pipeline de alertas é totalmente autónomo, como uma cobra que come a própria cauda e fica completamente alimentada.

A parte desconfortável

Esta é a parte que tenho adiado. Nada disto é ficção. O servidor insubstituível de que todos gostam, o RAID 0 com cópias de segurança no mesmo volume, a firewall desativada “temporariamente”, o cluster Kubernetes a servir uma página, o monitor a monitorizar-se a si próprio: já vi todos estes casos em produção. Alguns aconteceram este ano. Um ou dois deles, nos meus primeiros tempos, fui eu que criei.

A eficiência real é monótona. Por isso perde a discussão no momento, mas vence-a ao longo de uma década: um PUE em que nunca pensa porque outra pessoa o dimensionou. Máquinas dimensionadas para a carga de trabalho, não para a imagem que o proprietário tem de si próprio. Um raio de impacto analisado antes da explosão. Cópias de segurança testadas através de restauros realizados periodicamente, com um lembrete no calendário e sem heroísmo. Redundância sem glamour: duas unidades baratas são melhores do que uma unidade extraordinária, sempre, em todas as falhas para as quais alguma vez fui chamado.

E o datacenter mais eficiente que pode operar é aquele que não opera. Um VPS transfere a energia, a refrigeração, a redundância e as falhas de hardware às 3 da manhã para pessoas que lidam com esses problemas em escala, de forma monótona. Esse é o maior elogio que uma infraestrutura pode receber. E deixa-lhe a parte genuinamente divertida: executar os seus próprios serviços sobre ela, numa máquina que pode perder sem consequências. Essa é a única máquina na qual deve fazer experiências.

FAQ

Devo mesmo fazer alguma destas coisas?

Não. Todas as secções deste guia documentam anti-padrões que custaram muitos fins de semana. Se a sua configuração atual se parecer com mais de duas secções, avance para a última pergunta desta FAQ, pela ordem apresentada, porque essa é a ordem de triagem.

O que é, na prática, um bom PUE?

Os datacenters hyperscale operam perto de 1.1, uma sala empresarial bem gerida mantém valores entre 1.4 e 1.6, e um armário sem refrigeração, em conflito permanente com um aquecedor elétrico, pode ultrapassar 3. Em casa, não é possível competir de forma significativa com 1.1. Este é o argumento económico discreto a favor de alugar capacidade computacional a quem consegue fazê-lo.

Aquecer um edifício com servidores é algo real?

Sim, quando é feito corretamente. Projetos de aquecimento urbano em vários países capturam o calor residual dos datacenters através de permutadores de calor e encaminham-no por tubagens para as habitações, de forma planeada, com engenharia e contratos. A sátira acima não é sobre o calor dos servidores poder aquecer uma sala. É sobre fazê-lo por acidente e chamar estratégia ao acidente.

O meu servidor já está assim. O que faço primeiro?

Faça backups ainda hoje para um local que não seja o servidor e, em seguida, teste uma restauração. Um backup não testado é apenas um rumor. Segundo, instale as atualizações e faça o reboot que tem evitado, numa janela planeada, para descobrir o que falha enquanto está a monitorizar o sistema. Terceiro, elimine o ponto único de falha: transfira o DNS e a monitorização para fora do servidor. Tudo o resto pode esperar por uma semana mais tranquila; estes três passos não podem.