Rastreando falhas no Hetzner AX162 com powerstat, sensors e dmidecode

• A Ubicloud adotou os novos servidores AX162 da Hetzner porque pareciam melhores que os AX161 em desempenho e preço, mas enfrentou um problema de confiabilidade em produção, com falhas ocorrendo 16 vezes mais frequentemente
• A investigação da causa começou com logs do sistema contendo bytes NULL e avançou eliminando, em sequência, carga, temperatura, informações de componentes e consumo de energia, tendo sensors, dmidecode e powerstat como ferramentas principais
• Nos dados iniciais, o AX161 teve 11 falhas em 3.784 dias de serviço, com AFR de 1,06, enquanto o AX162 registrou 34 falhas em 737 dias, com AFR de 16,84
• Em servidores que já tinham falhado uma vez, 80% sofreram uma segunda falha em até 24 horas, e a Hetzner informou um defeito em um lote de placas-mãe sem confirmar se havia limitação de energia
• O AX162 -v3, migrado para a placa-mãe mais recente, caiu para AFR de 0,39 após meses de monitoramento, reforçando que novo hardware deve ser validado gradualmente começando por cargas não críticas

---

Travamentos recorrentes após a adoção do AX162

• A Ubicloud cria software que transforma provedores bare metal em uma plataforma de nuvem e vinha usando a Hetzner como fornecedora de servidores baratos e confiáveis
• A linha de servidores AX162 da Hetzner oferecia melhor desempenho e menor preço do que o modelo anterior AX161, então foi adotada rapidamente
• Três semanas após a compra do primeiro AX162, um servidor travou, e os logs do sistema continham bytes NULL
  • Isso foi interpretado como sinal de uma falha súbita, como perda de energia, em que as operações de escrita não foram concluídas normalmente
• Na inspeção inicial de hardware da Hetzner não foi encontrado nenhum problema, mas uma semana depois ocorreu outro travamento, e as falhas passaram a se repetir ao longo de alguns dias

Como as falhas se manifestavam

• Todos os travamentos ocorriam apenas em servidores AX162
• As falhas se dividiam em dois tipos
  • casos em que, após uma reinicialização manual, o servidor voltava a ficar online
  • casos em que o servidor não respondia nem ao pedido de reinicialização nem ao código de diagnóstico dos engenheiros da Hetzner, exigindo substituição
• Em geral, os servidores funcionavam normalmente por longos períodos, mas, depois do primeiro travamento, a chance de novos travamentos aumentava bastante
• Observou-se um padrão em que várias falhas do primeiro tipo acabavam evoluindo para o segundo tipo, levando à troca do servidor

Eliminando primeiro carga e temperatura

• O AX162 oferecia 96 vCPU, e a Ubicloud tinha cargas de trabalho que utilizavam todos os vCPU ao mesmo tempo
• Foi avaliada a hipótese de que carga elevada pudesse causar aumento de temperatura ou algum problema inesperado, mas as falhas também ocorriam em momentos de baixa carga ou sem carga alguma
• Para verificar a correlação entre temperatura e falha, foram coletadas temperaturas dos componentes do sistema com o comando sensors
• Os dados de temperatura foram reunidos com uma tarefa simples de cron e, quando houve novo travamento, as temperaturas verificadas não estavam significativamente acima da média

Investigando componentes e consumo de energia

• Com lshw e dmidecode, foram verificados os modelos e números de série dos componentes de hardware
• Foram comparados os componentes de servidores AX162 que falharam com os de servidores que não falharam, mas nenhuma diferença significativa foi encontrada
• Também foi verificada a progressão dos números de série, considerando a possibilidade de componentes mais antigos falharem com mais frequência, mas travamentos também ocorreram em servidores com números de série mais recentes
• Em expansões de datacenter, muitas vezes energia é um recurso mais limitante do que espaço, e o operador pode restringir o consumo por máquina
  • A Ubicloud não sabia se a Hetzner limitava o consumo de energia, mas avaliou que o padrão de longos períodos estáveis seguidos de travamentos repetidos combinava com desgaste de hardware
  • Depois de descartar uma hipótese após outra, a limitação de energia permaneceu como hipótese forte
• Com powerstat -R, foi medido o consumo máximo de energia ao longo de períodos prolongados e comparado com os valores anunciados
  • AX161: consumo máximo anunciado de 147W, consumo máximo medido de 168W
  • AX162: consumo máximo anunciado de 408W, consumo máximo medido de 266W
• Essa diferença levantou a suspeita de que a Hetzner pudesse estar limitando o uso real de energia

Taxa de falhas vista pelo AFR

• Para comparar a confiabilidade do hardware, foi usado o Annualized Failure Rate (AFR)
• O AFR tem limitações, mas era uma métrica simples o suficiente para servir como ponto de partida na comparação das taxas de falha
• Na medição inicial, a taxa de falhas do AX162 era muito mais alta do que a do AX161
  • AX161: 11 falhas, 3.784 dias totais de serviço, AFR 1,06
  • AX162: 34 falhas, 737 dias totais de serviço, AFR 16,84
• Esses dados sustentavam a observação de que o AX162 tinha 16 vezes mais probabilidade de apresentar falhas do que outros modelos
• Servidores que já tinham travado uma vez apresentavam probabilidade muito alta de travar de novo, e 80% dos servidores que passaram por um travamento sofreram um segundo em até 24 horas

Troca de placa-mãe e os limites da v2

• A Ubicloud abriu um ticket detalhado de suporte com a Hetzner, incluindo a suspeita de limitação de energia e os dados de AFR
• A Hetzner não confirmou nem negou a possibilidade de limitação de energia, mas informou que havia identificado um defeito em um lote de placas-mãe
• A Hetzner recebeu placas-mãe de um novo lote e recomendou trocar as placas-mãe dos servidores afetados
• Uma substituição em larga escala de servidores poderia afetar as cargas de trabalho dos clientes, mas a maioria dos trabalhos importantes já havia sido removida do AX162 por causa dos travamentos recorrentes, então a troca foi possível
• Mesmo após a substituição pelas novas placas-mãe, as cargas críticas não foram colocadas de volta no AX162, e o monitoramento de longo prazo continuou
• No início não houve travamentos, mas duas semanas depois ocorreu nova falha até mesmo em um servidor com a nova placa-mãe
  • AX162 -v2: 11 falhas, 758 dias totais de serviço, AFR 5,30
• A v2 travava com menos frequência do que o AX162 original, mas a taxa de falhas ainda era alta

Resultados estabilizados na v3

• Após novo contato com a Hetzner, foi descoberto que existia uma versão mais recente da placa-mãe com melhorias adicionais de confiabilidade
• Os servidores foram migrados para a versão mais recente, e a confiabilidade passou a ser monitorada
• Depois de observar os novos servidores por vários meses, concluiu-se que o problema de travamentos do AX162 havia sido resolvido
• A comparação final de AFR foi a seguinte
  • AX161: 11 falhas, 3.784 dias totais de serviço, AFR 1,06
  • AX162: 34 falhas, 737 dias totais de serviço, AFR 16,84
  • AX162 -v2: 11 falhas, 758 dias totais de serviço, AFR 5,30
  • AX162 -v3: 4 falhas, 3.738 dias totais de serviço, AFR 0,39
• O AFR do AX162 -v3 ficou até mais baixo que o do AX161

Melhoria do processo operacional

• Adotar cedo uma nova linha de servidores pode trazer problemas inesperados
• O AX162 tinha especificações atraentes, e o fato de a Hetzner ter descontinuado o AX161 também parecia um sinal de que a nova linha estava pronta para produção
• A avaliação foi de que esperar seis meses teria evitado muitos problemas
• As mudanças daqui para frente são as seguintes
  • realizar uma validação mais rigorosa de novos modelos de servidor
  • introduzir novo hardware gradualmente, começando por cargas de trabalho não críticas
  • adicionar mais provedores bare metal para distribuir o risco
• A Ubicloud já oferece suporte a mais dois provedores bare metal, Leaseweb e Latitude, e também está trabalhando na adição de um quarto provedor

[GN⁺]

Opiniões no Hacker News

• Outros modelos AX (AX42, AX52, AX102) também têm problemas sérios de confiabilidade, falhando depois de alguns meses
  Como são baseados em placas-mãe defeituosas, a Hetzner terá que substituir, nos próximos 12 meses, a maioria — talvez todas — as placas-mãe dos servidores fabricados antes de uma determinada data [0]
  [0] https://docs.hetzner.com/robot/dedicated-server/general-info...

  • Uso dois AX42: um está estável desde que o recebi durante a promoção da Eurocup, e o outro já foi trocado duas vezes até agora
    A substituição mais recente parece estar aguentando, então, por essa amostra pequena, parece uma taxa de falha de 50%. Os números reais provavelmente só a Hetzner e a ASRock sabem

• Em uma empresa anterior, o DevOps frequentemente encontrava falhas no ventilador da CPU em máquinas da Hetzner
  Isso era separado das falhas de HDD/SSD normalmente esperadas e precisava ser monitorado diretamente. É um dos motivos pelos quais servidores não gerenciados são mais baratos que instâncias de cloud

  • Também vi muitos sistemas de refrigeração com defeito no Azure e, quando trabalhei no Google, isso era uma dor de cabeça constante, embora em baixo nível
    No meu primeiro dia na Dropbox, disse à equipe que “dava para encontrar máquinas rodando a 400 MHz na fleet”, e eu estava certo. Um controlador de PSU redundante defeituoso estava acionando PROCHOT. Quando há muitas máquinas, esse tipo de coisa acontece
  • Não ser gerenciado significa que você recebe acesso em nível de silício e KVM remoto, não que a responsabilidade pelo hardware físico passe para o cliente
    Possuir, manter e consertar corretamente o equipamento físico ainda é responsabilidade da empresa de hospedagem, e isso inclui monitoramento. Antigamente era preciso instalar scripts ou pacotes para conectar ao monitoramento, mas hoje, com IPMI e afins como padrão, dá para fazer isso sem ajuda do cliente
    Se o serviço não for apenas espaço em rack, energia e rede, o que fica sob responsabilidade de cada parte é uma questão contratual. Se a Hetzner não consegue nem detectar falhas no ventilador da CPU do próprio hardware e colocou sistemas novos em produção sem testá-los o suficiente, isso parece evidência de que continua escorregando
  • Sou fortemente contra tanto depender de dependências gratuitas quanto escolher sempre a opção mais barata
    Ao avaliar uma compra, se você nem por um momento pensa no lado da outra parte e só tenta reduzir custo e aumentar receita, não vai durar muito, a menos que esteja em algum setor de vendas suspeito
    Hardware de servidor é realmente barato, e um programador minimamente competente consegue fazer a maioria dos programas rodar em um único servidor ou em uma única máquina virtual. Em vez de pagar 25 dólares por mês, é preciso pagar 50 dólares por mês e deixar alguma margem. Ainda assim, não há garantia de que a empresa não vá quebrar ou que vá ver você como um cliente valioso; no fim, você fica dependente de uma estrutura em que o conjunto dá lucro graças aos grandes clientes
    Se o seu negócio fica nos EUA, faz sentido usar uma empresa de hospedagem dos EUA

• O conselho de que “se você tivesse esperado 6 meses, poderia ter evitado muitos problemas, e os early adopters normalmente encontram os problemas primeiro, que depois são corrigidos” se aplica a qualquer sistema que precise de estabilidade
  Se não houver problema de segurança, espere alguns meses ou mantenha-se uma ou duas versões atrás

  • O GitHub está tentando adicionar esse recurso ao dependabot: https://github.com/dependabot/dependabot-core/issues/3651
  • É um padrão de sucesso antigo também na natureza: indivíduos mais velhos usam os mais jovens e inexperientes como unidades de teste entusiasmadas
    Por exemplo, na floresta, javalis mais velhos emitem sinais de segurança para tentar mandar os filhotes primeiro para clareiras pouco confiáveis. Em termos de tecnologia, é parecido com escrever posts de blog exagerando tecnologias que ainda não estão prontas para produção
  • Sou o autor do post. Em geral, isso é uma boa prática
    Ainda assim, pelo menos o nosso sofrimento ajudou a revelar a causa raiz mais rapidamente
    Não escrevi isso no post, mas também consideramos, daqui em diante, receber servidores e deixá-los ociosos por cerca de um mês, sem workloads reais de clientes. Custa mais, mas pode ajudar a encontrar problemas latentes sem impactar usuários. No nosso caso, os crashes começaram 3 semanas depois de colocarmos o primeiro servidor AX162 em produção, então seria necessário um período de amortecimento de pelo menos um mês, talvez mais
  • Depende do sistema. Kelly Johnson, da Skunk Works, tinha como uma das principais regras que o sistema de inspeção atual atendia ao espírito dos requisitos militares e deveria ser usado também em novos projetos, com mais responsabilidade básica de inspeção passada para subcontratadas e fornecedores, sem duplicar inspeções
    Dito isso, esta será a primeira e última vez que a Ubicloud usa um novo modelo ou tranche de compra sem burn-in. Eu também trabalho lá e sou cofundador

• A Dell também tem esse tipo de problema às vezes. Quando recebemos o primeiro lote de servidores antigos, eles perdiam por algum tempo os dispositivos do I/O traseiro, e era preciso substituir a seção traseira de I/O da placa-mãe
  Por exemplo, o controlador Ethernet, o iDRAC e, às vezes, até o BIOS desapareciam. Depois que resolvemos esse problema, eles rodaram bem por quase 10 anos
  Recentemente, aposentamos tudo porque estava se desgastando, de placas RAID a reguladores de energia. É uma experiência que faz você acordar para a realidade reiniciar um servidor que estava rodando bem por causa de uma mudança de configuração e perder para sempre a placa RAID, porque a eletromigração corroeu trilhas internas do processador RAID

  • A Dell tem problemas demais. Uma única miniplaca defeituosa dos LEDs frontais pode impedir o servidor de inicializar ou até de funcionar, e nesse caso o DRAC também morre

• A Hetzner não confirmou nem negou a possibilidade de limitação de energia, e fico curioso sobre qual seria o resultado dessa limitação de energia
  No texto dizem que o hardware poderia se degradar mais rapidamente, mas não entendo por quê
  Pela falta de resposta da Hetzner e pelas medições da UbiCloud, parece que eles de fato limitam a energia. Se não fosse o caso, teriam dito que não

  • Já vi algo parecido em vários produtos de nuvem: o governor de escalonamento da CPU vem configurado com um valor “verde” que só beneficia o provedor de nuvem, não traz benefício nenhum ao usuário e apenas reduz bastante o desempenho máximo da CPU
    Para verificar, execute cat /sys/devices/system/cpu/cpu/cpufreq/scaling_governor. O valor deve ser performance
    Se não for, dá para configurar com echo performance | sudo tee /sys/devices/system/cpu/cpu/cpufreq/scaling_governor. Isso ajuda em workloads que usam muita CPU. Como volta ao estado anterior ao reiniciar, mantenha via cron/systemd etc.
    Claro, se você paga a conta de luz diretamente ou o hardware é seu, decida por conta própria sobre o governor de escalonamento. Mas, em um servidor bare metal alugado, performance é o correto

• A parte em que o operador do datacenter limita o consumo de energia por servidor para aumentar o número de máquinas dentro das restrições de energia, e isso poderia acelerar a degradação da placa-mãe, é contraintuitiva
  Pelo pouco que pesquisei, limitação de energia parecia mais algo que aumenta a vida útil efetiva de vários componentes
  Os únicos resultados de busca dizendo o contrário falavam que temperaturas operacionais altas, quando há thermal throttling, podem degradar mais rapidamente componentes como capacitores. Mas o texto verificou vários sensores de temperatura, e esse caso foi explicitamente descartado

  • Na época da investigação, encontrei alguns textos dizendo que limitação de energia poderia causar degradação de hardware, mas agora não tenho a fonte exata
    A resposta abaixo compartilhou um exemplo, e ao pesquisar encontrei mais algumas fontes [1], [2]
    Dito isso, não sou engenheiro eletrônico, então meu entendimento pode não estar totalmente correto. A degradação talvez fosse causada não pela limitação de energia em si, mas por variações de energia, ou talvez houvesse outro fator
    [1] https://electronics.stackexchange.com/questions/65837/can-el...
    [2] https://superuser.com/questions/1202062/what-happens-when-ha...
  • Potência = tensão × corrente
    A tensão é o valor fornecido pela concessionária de energia, e a corrente é monitorada por rack. Em um datacenter, a reação comum ao ultrapassar o limite de corrente é queimar um fusível ou cobrar mais dinheiro
    A única forma de reduzir a energia consumida por um servidor é fazer throttling da CPU. Normalmente isso é feito pelo sistema operacional, então exige cooperação
    Imagino que talvez seja possível fazer isso por um controlador baseband lights-out sem envolvimento do SO, mas, se fosse assim, acho que provavelmente apareceria em /sys
  • Estranho. Sempre li que potência e temperatura constantemente altas degradam eletrônicos muito mais rápido. Algum engenheiro eletrônico consegue explicar?
  • Todos os racks de um datacenter têm um orçamento de energia e, na prática, são limitados pela quantidade de calor que o sistema de climatização consegue retirar do datacenter, mais do que pela quantidade de energia disponível
    Ainda assim, há limites por rack para impedir que alguns servidores de alta potência derrubem uma área maior do datacenter
    Não sei ao certo como essa limitação é feita, mas um disjuntor simples, como o de casa, poderia ser uma solução fácil. Nesse caso, ao desarmar, o rack perde energia, afetando o rack inteiro e vários clientes, então não é ideal
    Outra opção é um limitador de corrente/potência[0], mas, como P = U * I, isso pode criar mais problemas. A tensão (U) cai, todo o sistema fica em subtensão, e surgem glitches estranhos. Esse também é um método comum para contornar vários mecanismos de segurança em chips. A Raspberry Pi também lançou um desafio[1] para encontrar esse tipo de bug e testar o quanto o chip resiste a ataques, incluindo ataques de tensão
    [0] - https://en.m.wikipedia.org/wiki/Current_limiting
    [1] - https://www.raspberrypi.com/news/security-through-transparen...
  • Uma possibilidade é que, com uma configuração de energia mais baixa, a CPU esquente menos, então as ventoinhas girem menos, e outros componentes recebam menos fluxo de ar e acabem ficando mais quentes
    Normalmente a solução é monitorar também a temperatura desses outros componentes e incluí-la como entrada no algoritmo de velocidade das ventoinhas. Não sei se foi isso que aconteceu de fato aqui

• Não dá para saber, mas também poderia ser um problema de alimentação, sinal ou VRM
  O fato de a CPU não estar quente não significa que outra coisa na placa não tenha saído da especificação e entrado em falha fatal
  Problemas de placa-mãe em torno de alimentação e sinal são horríveis de diagnosticar. Por fora, aparecem como todo tipo de sintoma que parece problema em outros componentes e, pela minha experiência, falhas na inicialização da RAM e reinicializações aleatórias são muito comuns. No fim, você acaba trocando tudo antes de realmente trocar a placa-mãe

• Tive algo parecido no AX102 que uso atualmente, e parecia que os crashes eram causados por um problema relacionado à placa de rede
  Felizmente, o suporte da Hetzner lidou bem com o hardware de reposição. Foi bem trabalhoso, mas uma boa oportunidade para aprender a solucionar problemas de hardware e, para mim, valeu a pena

  • Comigo foi igual. O AX102 travava mesmo quase sem carga, não havia nada nos logs e nem ligava de novo
    A Hetzner verificou várias vezes, mas não encontrou nada, ou apenas trocou a pasta térmica da CPU e o conector da PSU. Migrei para um AX162 e até agora está tudo bem

• Alguém com experiência em data centers poderia especular que tipo de solução comercial a Hetzner pode ter feito aqui com o fornecedor da placa-mãe?
  Devemos supor que ela recebeu a troca gratuita de todas as placas-mãe e ainda alguma compensação?

  • Ao comprar servidores de marcas conhecidas, é certo que hardware defeituoso será substituído.
    Compensação só é possível quando negociada previamente e, nesse caso, é preciso pagar um custo adicional. Em vez de tentar receber do fornecedor os custos de downtime, provavelmente faz mais sentido contratar algo como seguro contra interrupção de negócios. Isso vale mesmo que a culpa seja do fornecedor.
    A Hetzner não é um cliente comum. Como parte de uma otimização extrema de custos, é provável que compre os componentes mais baratos, e pode até ter negociado um preço menor sem garantia. Nesse caso, ela teria de comprar as placas-mãe de substituição por conta própria.
  • Acho que, para começar, eles conseguiram esse volume por um preço muito baixo. Esses servidores foram oferecidos inicialmente sem taxa de instalação.
    Foi na época em que a Copa do Mundo de futebol acontecia na Alemanha.

• Foi a primeira vez que ouvi dizer que uma operadora de data center limita o consumo de energia por servidor por causa de restrições de energia, e que isso pode acelerar a degradação da placa-mãe; achei bastante surpreendente.