como criar o datacenter menos eficiente do mundo

O que você está construindo

Cada guia neste site ensina a fazer algo corretamente: os comandos na ordem, como deve ser o resultado correto e os modos de falha nomeados. Este guia é diferente. Hoje, de forma totalmente hipotética, vamos projetar o datacenter menos eficiente que o dinheiro, a eletletricidade e a arrogância podem produzir.

Precisamos de uma métrica, então usaremos a da própria indústria: PUE, Power Usage Effectiveness — a energia total da instalação dividida pela energia que realmente chega ao equipamento de computação. Um datacenter hyperscale opera em torno de 1.1: quase todo watt realiza trabalho útil. Uma sala de servidores empresarial decente gerencia 1.5. Nosso alvo é 4.0 ou superior, o que significa que para cada watt de computação, outros três watts são desperdiçados. Referiremos a este número frequentemente, da mesma forma que guias sérios referem-se a backups.

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

O resfriamento é o maior custo operacional em um datacenter real, e é por isso que o nosso lutará contra a termodinâmica em seu próprio terreno. O local ideal é um sótão. Voltado para o sul. Idealmente com uma claraboia posicionada para brilhar diretamente sobre o servidor, para que a máquina receba tanto o seu próprio calor residual quanto o do sol, uma colaboração entre sua conta de luz e uma estrela.

No inverno, o resfriamento é feito abrindo a janela. Datacenters reais usam ar externo — a técnica é chamada de free cooling, e é projetada, filtrada e com controle de umidade. Nós a usaremos acidentalmente, através de uma janela que também permite a entrada de chuva, pólen e pelo menos um pássaro confuso por trimestre.

Para a verdadeira arte, instale um ar-condicionado e coloque um aquecedor de ambiente a sessenta centímetros do seu termostato, configurado dois graus acima do alvo do ar-condicionado. Ambas as máquinas agora rodarão continuamente, para sempre, em perfeito desacordo. A companhia de energia enviará um cartão no Natal.

Um servidor, grande, amado

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

O servidor tem um nome. Não um hostname — um nome. Gandalf, geralmente, ou Odin. Você não pode desativar o Odin. O Odin está ligado 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, e é por isso que você tira um print e o posta, e por que todo atacante que vê o print também o acha impressionante: 1.847 dias de uptime significam 1.847 dias de vulnerabilidades de kernel, sem patches de ninguém. Reiniciar está fora de questão de qualquer maneira — o reboot é como você descobre quais serviços foram iniciados manualmente em 2021 e nunca foram escritos em uma unidade systemd. Ninguém lembra de quais. O servidor agora é um pilar estrutural no organograma da organização.

Armazenamento: velocidade e outras formas de perder dados

Os discos estão configurados em RAID 0, para performance. O zero refere-se ao número de discos que podem falhar. Para efeito máximo, faça o stripe do array em storages de procedência mista: dois SSDs de verdade, um HDD antigo e um pendrive de uma conferência. O array é exatamente tão confiável quanto o pendrive da conferência, que é o projeto.

Os backups são gerenciados por um diretório no mesmo array chamado backup_final_v2_REAL, que contém um tarball do esquema de nomenclatura anterior. Backups off-site são representados por um post-it escrito "configurar backups off-site", que está, tecnicamente, armazenado off-site quando você o leva para casa na tampa do seu laptop.

Um resultado correto parece: df reportando 97% de uso, e um plano para lidar com isso no próximo sprint.

Rede: um único fio de tudo

O servidor DNS roda na própria máquina, para que quando o servidor cair, ele leve consigo o registro DNS que você usaria para descobrir o porquê. Isso é chamado de consolidação.

O firewall foi desativado em 2021 — temporariamente, para debugar algo. O debugging terminou; o firewall não retornou. Cada porta no roteador está encaminhada para o servidor "para economizar tempo depois", e o painel de administração do roteador é acessível pelo lado da WAN com sua senha de fábrica, para gerenciamento remoto conveniente. A sua, e de outros.

O servidor tem rodado anormalmente quente ultimamente, mesmo para padrões de sótão, e top mostra que o processo mais ocupado é algo chamado xmrig. Assumimos que esta é a ferramenta de monitoramento que estamos usando. Nós não a instalamos — ela apareceu sozinha logo após as portas serem encaminhadas, o que consideramos um sinal de que o ecossistema está prosperando. Ela monitora 24 horas por dia.

A energia chega através de uma corrente de réguas de energia domésticas cuja comprimento combinado excede a distância de caminhada até o quadro de disjuntores — o que é eficiente, de certa forma, porque você visitará o quadro de disjuntores com frequência.

Redundância através da complexidade

Tendo recusado a redundância onde ela importa, agora a adicionamos onde não importa. A página inicial da empresa — um único arquivo HTML estático — é servida por um cluster Kubernetes de doze nós. Isso alcança o que os engenheiros chamam de arquitetura orientada ao currículo: a página carrega no mesmo tempo de quarenta milissegundos que o nginx entregaria, mas agora pode falhar de formas que exigem um consultor.

Para isolamento, o cluster em si roda dentro de uma máquina virtual dentro de uma máquina virtual dentro de uma máquina virtual, cada camada adicionando segurança da mesma forma que cada camada de um turducken adiciona uma ave. O formulário de contato é composto por nove microsserviços. Dois deles nunca foram invocados. Um deles é essencial para o funcionamento e ninguém sabe qual.

Aquecimento como serviço

Um servidor moderno converte eletricidade em computação e calor, e pretendemos maximizar a segunda saída. Um media server sem GPU é a jogada clássica: o CPU-transcoding de um único stream 4K manterá dezesseis cores em uso e aquecerá um quarto pequeno, um aquecedor de ambiente que também reproduz filmes. O operador ambicioso evolui para rodar um large language model em CPU — um aquecedor de ambiente de 70 bilhões de parâmetros com uma API, produzindo tokens em uma taxa que é melhor medida sazonalmente.

O monitor observa a si mesmo

Observabilidade importa, então implantamos um monitor de uptime self-hosted — no mesmo servidor que ele monitora. Quando o Odin morre, o monitor morre com ele, e aqui está a parte elegante: nenhum alerta dispara. Sem alertas significa sem incidentes. Sem incidentes significa uptime perfeito, conforme medido. O relatório mensal nunca pareceu tão bom.

E-mails de alerta, para completar, são retransmitidos por um servidor de e-mail que também roda no Odin. O pipeline de alerta é, portanto, totalmente autocontido, da mesma forma que uma cobra comendo a própria cauda está totalmente alimentada.

A parte desconfortável

Aqui está a seção que eu venho adiando. Nada disso é ficção. O servidor amado e insubstituível, o RAID 0 com backups no mesmo volume, o firewall desativado "temporariamente", o cluster Kubernetes servindo uma única página, o monitor observando a si mesmo — eu já vi cada um desses em produção. Alguns eu vi este ano. Um ou dois eu construí em meus primeiros dias.

O que a eficiência real parece é entediante, e é por isso que ela perde o argumento no momento, mas vence ao longo de uma década: um PUE sobre o qual você nunca pensa porque outra pessoa o projetou. Máquinas dimensionadas para sua carga de trabalho em vez de para a autoimagem de seu dono. Um raio de explosão, considerado antes da explosão. Backups que são testados ao serem restaurados, em um cronograma, com um lembrete de calendário e sem heroísmo. Redundância que é monótona — dois itens baratos superam um item magnífico, todas as vezes, em cada falha para a qual eu já fui acionado.

E o datacenter mais eficiente que você pode rodar é aquele que você não roda. Um VPS entrega a energia, o resfriamento, a redundância e as falhas de hardware às 3 da manhã para pessoas que fazem isso em escala, de forma monótona, o que é o maior elogio que a infraestrutura pode receber — e isso deixa para você a parte genuinamente divertida, que é rodar seus próprios serviços em cima dele, em uma máquina que você pode se dar ao luxo de perder, que é o único tipo em que você deve experimentar.

FAQ

Eu devo realmente fazer qualquer uma dessas coisas?

Não. Cada seção deste guia é um anti-padrão documentado com um histórico de fins de semana perdidos. Se o seu setup atual se assemelha a mais de duas seções, pule para a última pergunta deste FAQ — na ordem apresentada, porque a ordem é o triage.

Qual é um bom PUE, na verdade?

Datacenters hyperscale operam em torno de 1.1, uma sala empresarial bem gerida opera entre 1.4 e 1.6, e um armário sem resfriamento com uma disputa de aquecedores pode genuinamente exceder 3. Você não pode competir significativamente com 1.1 em casa, o que é o argumento econômico silencioso para alugar computação de quem pode.

Aquecer um edifício com servidores é algo real?

Sim — se feito corretamente. Projetos de aquecimento urbano em vários países capturam o calor residual de datacenters através de trocadores de calor e o canalizam para residências, por design, com engenharia e contratos. A sátira acima não é que o calor do servidor pode aquecer uma sala; é fazê-lo por acidente e chamar o acidente de estratégia.

Meu servidor já parece com isso. O que eu faço primeiro?

Backups, hoje à noite, para algum lugar que não seja o servidor, e então um teste de restauração — um backup não testado é apenas um boato. Segundo, patches e o reboot que você está evitando, em uma janela planejada, para que você aprenda o que quebra enquanto está observando. Terceiro, divida o ponto único de falha: mova o DNS e o monitoramento para fora da máquina. Todo o resto pode esperar por uma semana mais calma; esses três não podem.