¿Cómo evitar el tiempo de inactividad con Linux?

Con frecuencia, las actualizaciones de software a Ubuntu requieren reinicios (que pueden tener efectos secundarios como el tiempo de inactividad).

Veo que Ubuntu tiene https://www.ubuntu.com/livepatch que permite actualizaciones del kernel sin reiniciar, sin embargo, este es un servicio pago. También hay ksplice .

¿Hay distribuciones / procesos de Linux donde las actualizaciones / parches nunca requieren reiniciar?

(Sé que configurar servidores de alta disponibilidad (HA) y tener servidores desechables son las mejores prácticas, por lo que no estoy preguntando sobre cómo mantener un servicio, sino en servidores reales).

A su pregunta, "¿Existen distribuciones / procesos de Linux en los que las actualizaciones / parches nunca requieren reinicios?", No estoy al tanto de ninguno, y dudo mucho de que alguna vez haya alguno que sea verdaderamente libre de reinicio. Además del comentario de Michael Hampton sobre por qué el parcheo en vivo no es una experiencia lista para usar en ningún lado, el parcheo en vivo tampoco logra el mismo resultado que el reinicio.

Una anécdota para ilustrar esto: recientemente investigué un problema en el que una utilidad particular había comenzado a fallar en una gran cantidad de máquinas. Traté de mirar las bibliotecas compartidas que solía ver si algo recientemente actualizado lo había roto; ldd dijo que no era un ejecutable (aunque cuando llevé el mismo binario a mi computadora portátil, ldd podía ver muy bien las dependencias de la biblioteca compartida). Traté de atravesarlo en gdb; Segfauló incluso antes de llegar a la primera instrucción.

Al observar el momento de la falla, descubrí que recientemente se había aplicado un parche Ksplice. Retrocedí el parche y el binario no falló, luego lo agregué nuevamente y comenzó a segfaular nuevamente. Reiniciar en kernel parcheado de manera equivalente funcionó bien. Resultó ser un parche para soporte de 32 bits que la gente de Ksplice no había aplicado correctamente. Para su crédito, emitieron un parche fijo en unas pocas horas y volvieron a funcionar correctamente en nuestra flota sin intervención.

Otro ejemplo: los parches Meltdown / Spectre fueron tan invasivos que el equipo del kernel de Ubuntu decidió que los parches en vivo no eran prácticos y requerían que las personas reiniciaran sus sistemas en el kernel fijo antes de recibir parches en vivo nuevamente.

Tenemos una gran flota de servidores físicos y virtuales en el trabajo, con una gran cantidad de sistemas Ksplice y Canonical Livepatch. Ambos han sido mucho más confiables que muchos otros softwares, pero aún así preferiría ver nuestros servicios diseñados con una arquitectura de reinicio que confiar en parches en vivo del kernel.

Hay una distinción importante entre hacer que un servicio esté altamente disponible y hacer que una máquina individual esté altamente disponible.

En la mayoría de los casos, el objetivo es hacer que el servicio esté altamente disponible, y la disponibilidad de máquinas individuales es solo un medio para lograr ese objetivo. Sin embargo, existe un límite en cuanto a la meta que puede alcanzar al mejorar la disponibilidad de máquinas individuales.

Incluso si pudiera eliminar todo el tiempo de inactividad debido a la necesidad de actualizar el software, las máquinas individuales aún no estarán 100% disponibles. Por lo tanto, para aumentar la disponibilidad del servicio por encima de la disponibilidad de máquinas individuales, debe diseñar la redundancia en un nivel superior. La última oración de tu pregunta muestra que al menos en principio lo sabes.

Si diseña un servicio para que esté más disponible de lo que las máquinas individuales pueden ofrecer, ya no hay presión para lograr una alta disponibilidad de máquinas individuales. Por lo tanto, para servicios altamente disponibles no hay necesidad de evitar reinicios. En cambio, puede sacrificar cierta confiabilidad de las máquinas individuales para ahorrar, lo que puede destinarse a otras áreas donde puede obtener ganancias mucho más altas en confiabilidad.

Una vez que el sistema de alto nivel está diseñado para ser confiable en el caso de que los componentes individuales del hardware fallen, el parcheo en vivo de los cambios del núcleo pasa de ser una ventaja a convertirse en un riesgo.

Es un riesgo porque puede haber diferencias sutiles entre el comportamiento de una máquina que fue parcheada en vivo y una máquina que se inició con la última versión del kernel. Esto puede introducir un error latente que puede causar una interrupción la próxima vez que se reinicia una máquina. Este riesgo se amplifica reiniciando para obtener una pizarra limpia que se vea como un método para mitigar algunas interrupciones.

Un día podría tener una interrupción en la que cree que reiniciar la máquina podría ayudar. Pero a medida que reinicia, se encuentra con el error latente que impide que la máquina vuelva al estado deseado. El parcheo en vivo no es la única forma en que puede ocurrir un error latente, también podría ocurrir debido a algo tan mundano como un servicio que se ha habilitado manualmente y nunca configurado para iniciarse durante el arranque, o que se ha configurado para iniciarse demasiado temprano de modo que no aparece debido a dependencias insatisfechas.

Por esas razones, un servicio altamente disponible puede ser más fácil de lograr con reinicios regulares de máquinas individuales a una velocidad lo suficientemente lenta como para detectar problemas y pausar la secuencia de reinicios una vez que los problemas ocurren.