- Ubicloud adoptó los nuevos servidores AX162 de Hetzner porque parecían ofrecer mejor rendimiento y precio que los AX161, pero en operación sufrió un problema de confiabilidad con fallas 16 veces más frecuentes
- La búsqueda de la causa comenzó con registros del sistema que dejaban bytes NULL y fue descartando en orden carga, temperatura, información de componentes y consumo eléctrico;
sensors,dmidecodeypowerstatfueron las herramientas clave - En los datos iniciales, AX161 tuvo 11 fallas en 3,784 días de servicio con un AFR de 1.06, mientras que AX162 registró AFR 16.84 con 34 fallas en 737 días
- El 80% de los servidores que fallaban una vez sufrían una segunda falla dentro de 24 horas, y Hetzner informó un defecto de lote en la motherboard sin confirmar si existía un límite de energía
- AX162 -v3, migrado a la motherboard más reciente, bajó su AFR a 0.39 tras varios meses de monitoreo; el hardware nuevo debe validarse gradualmente empezando por cargas no críticas
Crashes repetidos tras adoptar AX162
- Ubicloud desarrolla software para convertir proveedores de bare metal en una plataforma cloud, y había estado usando Hetzner como un proveedor de servidores económico y confiable
- La línea de servidores AX162 de Hetzner ofrecía mejor rendimiento y menor precio que el modelo anterior AX161, por lo que se adoptó rápidamente
- Tres semanas después de comprar el primer AX162, uno de los servidores se cayó y en los registros del sistema quedaron bytes NULL
- Se interpretó como una señal de falla repentina, similar a una pérdida de energía, en la que no fue posible completar normalmente las escrituras
- En la revisión inicial de hardware de Hetzner no se encontró nada fuera de lo normal, pero una semana después ocurrió otro crash y las fallas se repitieron en pocos días
Cómo se manifestaban las fallas
- Todos los crashes ocurrían solo en servidores AX162
- Las fallas se dividían en dos formas
- Casos en los que el servidor volvía a estar en línea tras un reinicio manual
- Casos en los que no respondía ni a la solicitud de reinicio ni al código de diagnóstico de los ingenieros de Hetzner y había que reemplazarlo
- Normalmente los servidores funcionaban bien durante mucho tiempo, pero después del primer crash aumentaba la probabilidad de fallas adicionales
- Se observó un patrón en el que, tras repetirse varias veces el primer tipo de crash, finalmente se llegaba al segundo tipo y el servidor terminaba siendo reemplazado
Primero se descartaron carga y temperatura
- AX162 ofrecía 96 vCPU, y Ubicloud tenía cargas de trabajo que usaban todos los vCPU al mismo tiempo
- Se revisó la hipótesis de que una carga alta pudiera provocar aumentos de temperatura o problemas inesperados, pero también había fallas cuando la carga era baja o incluso inexistente
- Para ver la correlación entre temperatura y fallas, recolectaron la temperatura de los componentes del sistema con el comando
sensors - Reunieron datos de temperatura con una tarea simple de cron y, al revisar los valores tras otro crash, la temperatura no era significativamente mayor que el promedio
Investigación de componentes y consumo eléctrico
- Con
lshwydmidecodeverificaron el modelo y número de serie de los componentes de hardware - Compararon los componentes de los servidores AX162 que fallaban con los que no, pero no encontraron diferencias significativas
- Como los componentes más antiguos podrían fallar más seguido, también revisaron la secuencia creciente de números de serie, pero hubo crashes incluso en servidores con los números de serie más recientes
- En la expansión de un datacenter, muchas veces la restricción es la energía más que el espacio, y el operador puede limitar el consumo por máquina
- Ubicloud no sabía si Hetzner estaba limitando el consumo energético, pero consideró que el patrón de crashes repetidos tras largos periodos de operación estable encajaba con desgaste de hardware
- Después de ir descartando otras hipótesis, la limitación de energía quedó como la explicación más fuerte
- Con
powerstat -Rmidieron el consumo máximo de energía durante periodos prolongados y lo compararon con los 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
- Esa diferencia llevó a sospechar que Hetzner podría estar limitando el uso real de energía
Tasa de fallas vista con AFR
- Para comparar confiabilidad de hardware usaron Annualized Failure Rate (AFR)
- AFR tiene limitaciones, pero era una métrica lo bastante simple como punto de partida para comparar tasas de falla
- La medición inicial mostró que la tasa de fallas de AX162 era mucho mayor que la de AX161
- AX161: 11 fallas, 3,784 días totales de servicio, AFR 1.06
- AX162: 34 fallas, 737 días totales de servicio, AFR 16.84
- Estos datos respaldaban la observación de que AX162 tenía una probabilidad 16 veces mayor de experimentar fallas que otros modelos
- Los servidores que ya habían sufrido un crash tenían una probabilidad muy alta de volver a fallar, y el 80% de los que fallaron una vez sufrieron un segundo crash dentro de 24 horas
Reemplazo de motherboard y límites de v2
- Ubicloud envió a Hetzner un ticket de soporte detallado que incluía la sospecha de limitación de energía y los datos de AFR
- Hetzner no confirmó ni descartó la posibilidad de una limitación de energía, pero informó que había confirmado un defecto de lote en la motherboard
- Hetzner recibió motherboards de un nuevo lote y recomendó reemplazar las motherboards de los servidores afectados
- Un reemplazo masivo de servidores podía afectar las cargas de trabajo de los clientes, pero como los crashes repetidos ya habían obligado a mover la mayoría de las tareas importantes fuera de AX162, el cambio fue posible
- Incluso después del reemplazo por la nueva motherboard, no volvieron a poner cargas críticas en AX162 y continuaron el monitoreo por un largo periodo
- Al principio no hubo crashes, pero dos semanas después también apareció un crash en un servidor con la nueva motherboard
- AX162 -v2: 11 fallas, 758 días totales de servicio, AFR 5.30
- v2 se caía con menos frecuencia que el AX162 original, pero la tasa de fallas seguía siendo alta
Resultados estabilizados en v3
- Tras volver a contactar a Hetzner, se enteraron de que existía una versión más reciente de motherboard con mayor confiabilidad
- Migraron los servidores a la versión más reciente y monitorearon la confiabilidad
- Después de observar los nuevos servidores durante varios meses, concluyeron que el problema de crashes de AX162 estaba resuelto
- La comparación final de AFR fue la siguiente
- AX161: 11 fallas, 3,784 días totales de servicio, AFR 1.06
- AX162: 34 fallas, 737 días totales de servicio, AFR 16.84
- AX162 -v2: 11 fallas, 758 días totales de servicio, AFR 5.30
- AX162 -v3: 4 fallas, 3,738 días totales de servicio, AFR 0.39
- El AFR de AX162 -v3 fue incluso más bajo que el de AX161
Mejora del proceso operativo
- Adoptar una nueva línea de servidores en una etapa temprana puede traer problemas inesperados
- AX162 tenía especificaciones atractivas, y el hecho de que Hetzner hubiera descontinuado AX161 también parecía una señal de que la nueva línea estaba lista para producción
- Concluyeron que si hubieran esperado 6 meses, podrían haber evitado muchos problemas
- Los cambios hacia adelante son los siguientes
- Realizar una validación más rigurosa para nuevos modelos de servidor
- Introducir hardware nuevo de forma gradual, comenzando por cargas no críticas
- Agregar más proveedores de bare metal para distribuir el riesgo
- Ubicloud ya soporta otros dos proveedores de bare metal, Leaseweb y Latitude, y también está trabajando en incorporar un cuarto proveedor
1 comentarios
Opiniones de Hacker News
Otros modelos AX (AX42, AX52, AX102) también tienen problemas graves de confiabilidad: fallan después de algunos meses.
Como se basan en motherboards defectuosas, Hetzner tendrá que reemplazar en los próximos 12 meses la mayoría, quizá todas, las motherboards de los servidores fabricados antes de cierta fecha [0].
[0] https://docs.hetzner.com/robot/dedicated-server/general-info...
El reemplazo más reciente parece aguantar, así que, con una muestra pequeña, parece una tasa de falla del 50%. Las cifras reales probablemente solo las sepan Hetzner y ASRock.
En una empresa anterior, DevOps encontraba con frecuencia fallas en los ventiladores de CPU de equipos Hetzner.
Esto era aparte de las fallas esperables de HDD/SSD, y había que monitorearlo directamente. Es una de las razones por las que un servidor no administrado es más barato que una instancia en la nube.
Mi primer día en Dropbox le dije al equipo que “podía encontrar máquinas del fleet corriendo a 400 MHz”, y efectivamente era cierto. Un controlador de PSU redundante defectuoso estaba activando PROCHOT. Cuando tienes muchas máquinas, estas cosas pasan.
Poseer, mantener y reparar correctamente el equipo físico sigue siendo responsabilidad de la empresa de hosting, e incluye el monitoreo. Antes había que instalar scripts o paquetes para conectarlo al monitoreo, pero ahora que IPMI y similares son estándar, pueden hacerlo sin ayuda del cliente.
Si no se trata solo de proveer espacio en rack, energía y red, hasta dónde llega la responsabilidad es una cuestión contractual. Si Hetzner no puede detectar fallas en los ventiladores de CPU de su propio hardware y despliega sistemas nuevos sin probarlos lo suficiente, parece una señal de que se siguen resbalando.
Si al evaluar una compra solo intentas bajar costos y subir ingresos sin pensar ni por un momento en la posición de la otra parte, no vas a durar mucho, salvo que estés en un rubro de ventas sospechoso.
El hardware de servidor es realmente barato, y cualquier programador con cierta habilidad puede hacer que la mayoría de los programas corran en un solo servidor o una sola máquina virtual. En vez de pagar 25 dólares al mes, deberías pagar 50 dólares al mes para dejarles un poco de margen. Aun así, no hay garantía de que esa empresa no quiebre o de que te considere un cliente valioso; al final dependes de una estructura donde todo resulta rentable gracias a los clientes grandes.
Si tu negocio está en Estados Unidos, corresponde usar un proveedor de hosting estadounidense.
El consejo de que “si hubieran esperado 6 meses, podrían haber evitado muchos problemas; los early adopters suelen encontrar primero los problemas, que luego se corrigen” aplica a cualquier sistema que necesite estabilidad.
Si no hay problemas de seguridad, conviene esperar unos meses o mantenerse una o dos versiones atrás.
Por ejemplo, en el bosque, un jabalí viejo emite señales de seguridad para intentar mandar primero a sus crías a un claro poco confiable. En términos tecnológicos, se parece a escribir un post de blog exagerando una tecnología que todavía no está lista para producción.
Aun así, al menos es positivo que nuestro sufrimiento haya ayudado a exponer antes la causa raíz.
No lo escribí en el post, pero para el futuro también consideramos recibir los servidores y dejarlos inactivos durante alrededor de un mes, sin workloads reales de clientes. Cuesta más, pero puede ayudar a encontrar problemas latentes sin afectar a los usuarios. En nuestro caso, los crasheos empezaron 3 semanas después de desplegar el primer servidor AX162, así que haría falta un colchón de al menos un mes, quizá más.
Dicho eso, esta será la primera y última vez que Ubicloud use un modelo nuevo o un tranche de compra sin burn-in. Yo trabajo ahí y soy cofundador.
A Dell también le pasan estas cosas a veces. Cuando recibimos el primer lote de un servidor anterior, el servidor perdía durante un rato los dispositivos del lado de I/O trasero, así que hubo que reemplazar la sección trasera de I/O de la motherboard.
Por ejemplo, desaparecían el controlador Ethernet, iDRAC y a veces incluso el BIOS. Después de superar ese problema, funcionaron bien durante casi 10 años.
Hace poco los retiramos porque ya se había desgastado todo, desde la tarjeta RAID hasta los reguladores de energía. Es una experiencia que te despeja la mente reiniciar por un cambio de configuración un servidor que venía funcionando bien y perder para siempre la tarjeta RAID porque la electromigración erosionó trazas internas del procesador RAID.
Hetzner no confirmó ni negó la posibilidad de un límite de energía, y me da curiosidad qué implica el resultado de esa limitación de energía
En el artículo dicen que el hardware podría degradarse más rápido, pero no entiendo por qué
Por la falta de respuesta de Hetzner y las mediciones de UbiCloud, parece que sí están limitando la energía. Si no fuera así, lo habrían dicho
Para verificarlo, ejecuta
cat /sys/devices/system/cpu/cpu/cpufreq/scaling_governor. El valor debería serperformanceSi no lo es, puedes configurarlo con
echo performance | sudo tee /sys/devices/system/cpu/cpu/cpufreq/scaling_governor. Ayuda con cargas de trabajo intensivas en CPU. Como se revierte al reiniciar, conviene mantenerlo con cron/systemd, etc.Por supuesto, si pagas directamente la electricidad o es tu propio hardware, tú decides qué gobernador de escalado usar. Pero si es un servidor bare metal alquilado,
performancees lo correctoLa parte de que un operador de centro de datos limite el consumo por servidor para aumentar la cantidad de máquinas dentro de sus restricciones de energía, y que eso pueda acelerar la degradación de la placa madre, va contra la intuición
Por lo que busqué rápidamente, la limitación de energía parecía más bien aumentar la vida útil efectiva de varios componentes
Los resultados que afirmaban lo contrario solo decían que, al entrar en thermal throttling, las altas temperaturas de operación podían degradar más rápido componentes como capacitores. Pero en el artículo revisaron varios sensores de temperatura, y ese caso estaba explícitamente descartado
La respuesta de abajo compartió un ejemplo, y al buscar aparecieron algunas fuentes más [1], [2]
Dicho eso, no soy ingeniero electrónico, así que mi comprensión podría no ser del todo precisa. Tal vez la degradación no se debía a la limitación de energía en sí, sino a fluctuaciones de energía, o quizá había otro factor
[1] https://electronics.stackexchange.com/questions/65837/can-el...
[2] https://superuser.com/questions/1202062/what-happens-when-ha...
El voltaje es el valor que suministra la compañía eléctrica, y la corriente se monitorea por rack. En un centro de datos, la reacción normal al superar el límite de corriente es que se funda un fusible o que pidan más dinero
La única forma de reducir la energía que consume un servidor es hacer throttling de la CPU. Normalmente se hace throttling de la CPU a través del sistema operativo, así que se necesita cooperación
Supongo que quizá podría hacerse mediante el controlador de banda base lights-out sin intervención del SO, pero si fuera así creo que probablemente se vería en
/sysAun así, se limita por rack para que unos pocos servidores de alto consumo no tumben una zona más grande del centro de datos
No sé con certeza cómo se aplica el límite, pero un simple disyuntor como los de casa podría ser una solución fácil. Eso haría que, al dispararse, se apagara el rack, afectando a todo el rack y a varios clientes, así que no es ideal
Otra opción es un limitador de corriente/potencia[0], pero como P = U * I, puede crear más problemas. El voltaje (U) cae, todo el sistema queda en estado de subvoltaje y aparecen glitches extraños. También es una forma común de eludir varias protecciones de seguridad de los chips. Raspberry Pi también organizó un desafío[1] para encontrar esos bugs y probar cuánto resisten los chips frente a ataques, incluidos ataques de voltaje
[0] - https://en.m.wikipedia.org/wiki/Current_limiting
[1] - https://www.raspberrypi.com/news/security-through-transparen...
La solución habitual es monitorear también las temperaturas de esos otros componentes e incluirlas como entradas del algoritmo de velocidad de los ventiladores. No sé si eso fue lo que pasó realmente aquí
No se puede saber, pero también podría ser un problema de energía, señal o VRM
Que la CPU no esté caliente no significa que otra cosa en la placa no se haya salido de especificación y entrado en una falla crítica
Los problemas de placa madre alrededor de energía y señal son horribles de diagnosticar. Por fuera se manifiestan con todo tipo de síntomas que parecen problemas de otros componentes y, por experiencia, son muy comunes las fallas de inicialización de RAM y los reinicios aleatorios. Al final terminas cambiando todo antes de reemplazar realmente la placa madre
Me pasó algo parecido con el AX102 que uso actualmente, y parecía que los cuelgues venían de un problema relacionado con la tarjeta de red
Por suerte, el soporte de Hetzner gestionó bien el hardware de reemplazo. Fue bastante molesto, pero también una buena oportunidad para aprender a resolver problemas de hardware, y personalmente valió la pena
Hetzner lo revisó varias veces, pero no encontró nada, o solo cambió la pasta térmica de la CPU y el conector de la PSU. Me pasé a un AX162 y hasta ahora va bien
¿Alguien con experiencia en centros de datos podría especular qué tipo de arreglo comercial habrá hecho Hetzner aquí con el proveedor de placas madre?
¿Hay que asumir que recibió reemplazo gratuito de todas las placas madre e incluso compensación?
La compensación solo es posible si se negoció de antemano, y en ese caso hay que pagar un costo adicional. Es probable que convenga más comprar algo como un seguro de interrupción del negocio que intentar cobrarle al proveedor el costo del downtime. Incluso si fue culpa del proveedor.
Hetzner no es un cliente común. Como parte de una optimización extrema de costos, es probable que compre los componentes más baratos, y quizá haya negociado un precio más bajo sin garantía. Si fue así, habría tenido que comprar por su cuenta las placas madre de reemplazo.
Fue durante la época en que se celebraba la Copa Mundial de fútbol en Alemania.
Es la primera vez que escucho que un operador de centro de datos limita el consumo eléctrico por servidor debido a restricciones de energía, y que eso puede acelerar la degradación de la placa madre; me sorprendió bastante.