Powerstat, sensors y dmidecode descubren problemas en Hetzner

Depuración de Hetzner: resolver problemas con powerstat, sensors y dmidecode

• Contexto

  • Ubicloud adoptó servidores AX162 de Hetzner, pero sufrió graves problemas de confiabilidad.
  • Los servidores AX162 ofrecían mejor rendimiento y menor precio que el modelo anterior, pero fallaban 16 veces más seguido.
  • El problema solo se resolvió después de varias actualizaciones de hardware.

• Aparición del problema

  • El primer servidor AX162 se cayó apenas 3 semanas después de la compra.
  • Se encontraron bytes NULL en los registros del sistema, lo que indicaba una falla repentina como una pérdida de energía.
  • Hetzner realizó una inspección de hardware, pero no encontró anomalías.
  • A medida que aumentaba la frecuencia de las caídas, Hetzner reemplazaba los servidores cada vez que detectaba un defecto de hardware.

• Investigación inicial

  • Carga del sistema: se pensó que el problema podía ocurrir cuando aumentaba la carga, pero también hubo caídas con carga baja o nula.
  • Temperatura: se midió la temperatura con sensores, pero en el momento de las caídas no era más alta que el promedio.
  • Componentes defectuosos: se recopiló información de hardware con el comando dmidecode, pero no hubo grandes diferencias entre los servidores que fallaban y los que no.
  • Consumo eléctrico: se midió el consumo con la herramienta powerstat, y se sospechó que Hetzner podía estar limitando el uso de energía.

• Recolección y comparación de datos de tasa de fallas

  • Se usó la tasa anual de fallas (AFR) para medir la confiabilidad del hardware.
  • Los servidores AX162 fallaban 16 veces más seguido que otros modelos.
  • Después de la primera caída, el 80% de los servidores sufría una segunda caída en menos de 24 horas.

• Observación de estabilidad con hardware nuevo

  • Hetzner confirmó un lote defectuoso de placas madre y recomendó su reemplazo.
  • Incluso después del cambio a una nueva placa madre, siguieron ocurriendo caídas.
  • Tras cambiar a la placa madre más reciente y monitorear durante varios meses, el problema quedó resuelto.

• Mejoras en el proceso

  • Hace falta una revisión exhaustiva al adoptar un nuevo modelo de servidor.
  • El hardware nuevo debe incorporarse de forma gradual, empezando por tareas no críticas.
  • Se deben sumar más proveedores de bare metal para diversificar el riesgo.

• Conclusión

  • La adopción inicial de los servidores de Hetzner causó problemas, pero se resolvieron mediante mejoras continuas.
  • Ubicloud seguirá trabajando para ofrecer soluciones de nube con confiabilidad y capacidad de adaptación.

[GN⁺]

Comentarios de Hacker News

• La mayoría de los otros modelos AX (AX42, AX52, AX102) también tienen problemas graves de confiabilidad y fallan después de unos meses. Esto se basa en una placa madre defectuosa. Hetzner tendría que reemplazar la mayoría de las placas madre de los servidores fabricados antes de cierta fecha
• En una empresa anterior, encontrábamos fallas en los ventiladores de CPU con frecuencia en Hetzner. Esto ocurría además de las fallas normales de HD/SSD. Se necesita monitoreo propio, y esa es una de las razones por las que los servidores no administrados son más baratos que las instancias en la nube
• Viéndolo en retrospectiva, si hubiéramos esperado 6 meses, podríamos haber evitado muchos problemas. Los usuarios tempranos a menudo encuentran problemas que después se corrigen
  • Este es un muy buen consejo, y lo sigo para cualquier sistema que necesite estabilidad
  • Si no hay problemas de seguridad, espero unos meses o me quedo una o dos versiones atrás
• Hetzner no confirmó ni negó la posibilidad de una limitación de energía
  • ¿Cuál es el resultado de una limitación de energía? Según el artículo, el hardware podría degradarse más rápido
  • La falta de respuesta de Hetzner y las mediciones de UbiCloud parecen sugerir que realmente están limitando la energía. Si no fuera así, lo habrían dicho
• Dell también sufre este problema a veces. Cuando recibimos el primer lote de sus servidores antiguos, tuvimos que reemplazar la sección de I/O (trasera). Después de resolver ese problema, operaron durante casi 10 años
  • Hace poco retiramos estos servidores. Todo estaba desgastado, desde la tarjeta RAID hasta los reguladores de energía
  • Es impactante experimentar que reinicias un servidor que funciona perfectamente por un cambio de configuración y pierdes la tarjeta RAID para siempre
• Para aumentar la cantidad de máquinas bajo restricciones de energía, los operadores de centros de datos normalmente limitan el consumo de energía por máquina. Sin embargo, esto puede hacer que la placa madre se degrade más rápido
  • ¿Alguien puede explicar este punto? Va en contra de la intuición
  • Según los resultados de búsqueda, si se alcanza thermal throttling, las altas temperaturas de operación pueden degradar más rápido los componentes (por ejemplo, los capacitores). Sin embargo, el artículo investigó varios sensores de temperatura y esto no parece aplicar aquí
• Me pregunto si podría ser un problema de energía/señal o un problema de VRM. Que el CPU no esté caliente no significa que otras partes de la placa estén fuera de especificación y provoquen una falla catastrófica
  • Los problemas de placa madre relacionados con energía/señal son difíciles de diagnosticar. Se manifiestan como problemas relacionados con otros componentes, y al final terminas reemplazando de todo antes de cambiar realmente la placa madre
• Algo similar ocurrió con un AX102 que estoy usando actualmente. Se producían fallas por un problema relacionado con la tarjeta de red. Por suerte, el soporte de Hetzner ayudó con el reemplazo del hardware. Causó mucho dolor, pero fue una buena lección para resolver problemas de hardware
• ¿Alguien con experiencia en centros de datos puede adivinar a qué solución comercial habrá llegado Hetzner con el proveedor de placas madre? ¿Se puede suponer que reemplazaron todas las placas madre gratis y recibieron compensación?
• Antes de asumir que hay limitación de energía, me gustaría ver qué governor de CPU está corriendo en ese sistema. Muchas instalaciones predeterminadas de Linux ejecutan un governor de ahorro de energía, y eso limita la frecuencia máxima y la energía máxima