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


13

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).


1
¿Funcionaría un servidor con espacio de aire como una máquina que nunca necesita reiniciarse? Después de todo, si nadie puede acceder a él, ¿nunca necesita reiniciarlo? ;) - Por ejemplo, un servidor de monitoreo en una planta de energía nuclear, que simplemente suena una alarma si algo está mal. (Sí, soy consciente de que probablemente se trate de un sistema dedicado en lugar de un servidor aleatorio, pero estoy usando el ejemplo solo para señalar que hay ocasiones en las que reiniciar para 'actualizaciones de seguridad' puede ser una idea completamente fastidiosa.
djsmiley2k TMW

3
@ djsmiley2k Ese es uno de esos casos en los que una máquina que nunca reinicia aún no le ofrece suficiente disponibilidad. En cambio, necesitas redundancia.
kasperd

@kasperd ok, ¿entonces un grupo de máquinas nunca reiniciadas?
djsmiley2k TMW

3
@ djsmiley2k Mi respuesta a la pregunta ya argumenta por qué considero que un grupo de máquinas que se reinician de una en una es más confiable que uno que nunca se reinicia.
kasperd

2
¿Qué te hace pensar que es preferible evitar el tiempo de inactividad del sistema individual?
Warren

Respuestas:


12

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.


30

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.


Me gustó tu descripción del riesgo; "parcheado frente a arrancado con el kernel más nuevo" ... Sin embargo, no respondiste mi pregunta ... que podría reformular, ¿hay distribuciones de Linux que se envían con 'livepatch' fuera de la caja?
user75126

@ user75126 Lo veo como una característica que es más apropiada para máquinas cliente que para servidores. Además, preguntar qué distribuciones son compatibles parece una pregunta de recomendación de producto. Para mí, eso suena como dos razones por las cuales reformular la pregunta de esa manera lo haría fuera de tema para este sitio.
kasperd

3
@ user75126 Ksplice de Oracle tiene una versión de prueba gratuita y un nivel gratuito para escritorios Ubuntu y Fedora (solo, pero en realidad no lo hacen cumplir). El problema es que crear parches en vivo es difícil de automatizar, e incluso las partes que pueden automatizarse también requieren mucho tiempo. La creación de estos parches es una operación relativamente intensiva en mano de obra, y es razonable que las empresas cobren por eso. Investigué lo que se necesitaría para crear los parches en vivo, y salí de allí. No tengo ese tipo de tiempo en mi día.
Michael Hampton

12
@ user75126 Es realmente una mala práctica en este sitio cambiar el título y el cuerpo de la pregunta de una manera que invalide una respuesta existente. Si desea hacer una pregunta diferente, haga una pregunta diferente.
Greg Schmit

2
@ user75126 Gracias. Leí tu pregunta y no pensé que fuera realmente una respuesta. Simplemente estaba comentando por qué este es un servicio pago.
Michael Hampton
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.