¿Reiniciar el servidor ahora o más tarde? (Ninguna de las dos cosas, gracias)

¿Estuvo usted en AWS re:Invent 2019?

Lo fui, y fue una revelación.

"¿Va a reiniciar su servidor Linux en los próximos 30 días?"

Eso es lo que pregunté a casi todos los que se acercaron al stand de KernelCare.

Un tercio de ustedes dijo que sí. ¿La razón principal? La conformidad.

Esto tiene sentido. La mayoría de las políticas de cumplimiento indican a las empresas que deben instalar parches de seguridad en los 30 días siguientes a su emisión. El problema es que, en Linux, parchear el kernel significa reiniciar el servidor: no hay forma de evitarlo. (¿O sí?)

Debo de haber preguntado a unas 2000 personas. Piensa en cuántos servidores cuida cada uno de ellos. Luego multiplique por el tiempo que lleva un reinicio, no sólo realizarlo, sino planificarlo y coordinarlo. Incluso con esta pequeña muestra, resulta una cantidad asombrosa de esfuerzo humano. Y de dinero.

Reiniciar: Una necesidad incómoda

La gestión de parches de Linux es la forma elegante de decir "mantener un servidor actualizado instalando el software más reciente". Cuando ese software es el núcleo de Linux, se encuentra la razón más común de los reinicios del sistema. Para las grandes empresas, los parches de seguridad (como los fallos) no son una opción, sino una obligación.

Una política típica de cumplimiento de la seguridad informática tendrá una cláusula que diga algo así:

"...los parches de seguridad deben aplicarse al sistema en un plazo de X días desde su publicación por el proveedor...".

X suele ser de 30 días. Por eso, en la práctica, los administradores de sistemas procesan los parches por lotes y los instalan en masa, realizando el trabajo en una ventana de mantenimiento previamente planificada, un momento en el que todo el mundo ha acordado que está bien que el sistema se caiga durante un breve periodo de tiempo. (Lamentablemente, esa ventana suele ser el sábado por la noche o el domingo por la mañana, cuando el impacto para los clientes es menor).

Planificar esa ventana requiere mucho esfuerzo: tiempo invertido en reuniones, palabras vertidas en correos electrónicos, corazones rotos en compromisos. Y eso sin contar los fines de semana perdidos de café frío y pizza rancia. Durante mi estancia en AWS re:Invent, tuve la sensación de que el 30% de los administradores de sistemas Linux están sufriendo innecesariamente.

Continúe leyendo: Las 10 principales ventajas de Live Patching con KernelCare

La automatización: Una necesidad absoluta

Nadie debería gestionar los parches manualmente. Incluso para un servidor, supone un enorme esfuerzo mantenerlo actualizado.

A los administradores de sistemas, como criaturas técnicas que son, les encanta automatizar estas tareas rutinarias, sobre todo si gestionan grandes flotas de servidores. A menudo, el trabajo de automatización es más divertido que lo que se automatiza. También hay otras ventajas:

• Es más seguro, menos propenso al error humano.
• El proceso puede registrarse y auditarse.
• Es más fácil compartir el trabajo y la responsabilidad.

Hay muchas formas de automatizar. Decidir cuál utilizar puede ser en sí mismo un obstáculo. Por ejemplo:

1. ¿Quiere crear su propia herramienta de automatización? Hay un montón de lenguajes de programación entre los que elegir, pero ¿cuál es el mejor, y tienes las habilidades, la paciencia y el tiempo?
2. ¿Utilizar la herramienta de soporte preferida del proveedor? Red Hat tiene Satellite (y Spacewalk, el equivalente de código abierto), y Canonical tiene Landscape, pero son para sus propias plataformas y sólo vienen como parte de un paquete de soporte.
3. ¿Utilizar un servicio? De nuevo, hay muchos entre los que elegir: Automox, GFI, Ivanti, Kaseya, ManageEngine, Pulseway, por nombrar algunos. Alguien tiene que estudiarlos, averiguar qué hacen, cómo lo hacen y si serán adecuados. Mientras tanto, siguen llegando parches que hay que instalar.
4. ¿Utiliza una herramienta de orquestación? Ansible, Chef o Puppet son algunas opciones, pero también hay que comprobarlas y tienen una curva de aprendizaje que superar antes de que su potencia resulte rentable.

Hay otra opción tentadora, si trabajas con servicios gestionados en la nube como VMware Cloud en AWS, que cuidará de una plataforma virtualizada por ti (por una tarifa, naturalmente). Pero la virtualización no elimina los reinicios. Solo los hace más rápidos y menos dolorosos, disminuyendo su efecto mediante la agrupación en clústeres y otros enfoques de redundancia del sistema.

Un reinicio, por breve que sea, cierra los gestores de archivos, las conexiones de red, las sesiones de usuario y detiene todos los procesos. Para muchas clases de aplicaciones y usuarios de aplicaciones, pasarán desapercibidas; las sesiones se restauran, las conexiones se restablecen. Pero para otros tipos de aplicaciones, las interrupciones son ruinosas. Piense en cálculos científicos de larga duración, análisis en tiempo real, servidores de juegos en directo, dispositivos IoT...

Continúe leyendo: Endurance implementó actualizaciones sin reinicio con KernelCare

Una cura para el síndrome de reinicio

Live patching es una forma de instalar parches de seguridad del kernel de Linux, de forma automática y sin reiniciar. Aunque la técnica existe desde 2010, no ha encontrado la fama que rodea a Linux.

Esto se debe principalmente a que es difícil de llevar a cabo. Requiere un profundo conocimiento del código fuente del kernel y la capacidad de codificar los parches con rapidez y precisión. Por eso, sólo los grandes proveedores de Linux pueden ofrecer soluciones de parcheo en tiempo real: Oracle (con Ksplice), Red Hat (con Kpatch), SUSE (con SUSE Live Patching, de nombre Kgraft) y Canonical (con Livepatch).

Cómo parchear el kernel de Linux sin reiniciar

KernelCare funciona del mismo modo que Ksplice, Kpatch y Kgraft. La diferencia entre KernelCare y esas herramientas radica en cómo se crean los parches. (Otra diferencia es que esos productos forman parte de los contratos de servicio de los proveedores, mientras que las suscripciones a KernelCare son independientes y, por tanto, mucho más rentables y flexibles). Además, KernelCare es compatible con una amplia selección de versiones y tipos de kernel, muchos más que todos los demás proveedores juntos.

A continuación te explicamos cómo funciona KernelCare.

Por qué los administradores de sistemas adoran KernelCare

He hablado con muchos clientes durante mi etapa como responsable de marketing de KernelCare. Esto es lo que me dicen que son sus beneficios favoritos.

1. Reducción de los informes. Menos necesidad de informes de gestión y cumplimiento que digan qué se hizo, por qué y por quién.
2. Menos correos electrónicos. Reactivar menos significa menos comunicación y negociación con docenas de interesados de diversos departamentos.
3. Dormir más. Reiniciar el sábado por la noche/domingo por la mañana tiene sentido para cualquiera que se vea afectado por el tiempo de inactividad. Pero es un infierno para las personas que tienen que hacerlo. No importa si están in situ o de forma remota, alguien tiene que estar despierto para ejecutar los comandos, para comprobar que la automatización funciona sin problemas y para hacer comprobaciones de cordura en el sistema después de que vuelva a funcionar. En estas situaciones, la paranoia de la dirección se extiende con razón, teniendo en cuenta lo que está en juego.
4. La vida es más sencilla. Tener menos reinicios programados agiliza la configuración de la automatización, independientemente del método. Los playbooks del sistema son más sencillos y fáciles de entender.

Por qué los proveedores de servicios adoran KernelCare

Si crees que KernelCare es sólo para técnicos, te equivocas. Cualquiera con conocimientos básicos de consola Linux puede instalar KernelCare con un par de comandos. Esto es una gran noticia para una clase de personas que yo llamo Proveedores de Servicios. Se trata de gerentes, ejecutivos y propietarios de pequeñas empresas que no pueden molestarse con los tecnicismos de la aplicación de parches en tiempo real. Simplemente quieren saber que sus servidores Linux permanecen parcheados, conformes y seguros. También he hablado con estas personas y, como era de esperar, ven las ventajas de KernelCare desde una perspectiva diferente.

1. Hay menos tiempo de inactividad. Eso significa menos molestias para los clientes y menos motivos para que se vayan o se quejen.
2. Hay menos riesgo de que el sistema no vuelva a ser el mismo después de un reinicio, y menos posibilidades de tener que volver a ponerlo todo en marcha para que la empresa siga funcionando.
3. Se gasta menos dinero en administración. Live patching es un enfoque autosuficiente de la gestión de parches del núcleo de Linux.

El fin (de los reinicios)

El AWS re:Invent 2019 de este año fue una revelación, no solo porque era el primero, sino porque vi por mí mismo la escala de esfuerzo y gasto que sufren los administradores de servidores Linux lidiando con los molestos reinicios. Sentí que debía gritar a los cuatro vientos desde nuestro stand de KernelCare:

 

¡No seas esclavo de los reinicios! ¡Tenemos la respuesta! ¡Únete a nosotros!

Pero, por supuesto, no lo hice. Me limité a repartir folletos, pegatinas y camisetas, y a compadecer a cientos de personas realmente agradables y trabajadoras por tener que reiniciar sus servidores para aplicar actualizaciones de seguridad.

Siga leyendo: 5 malas razones para actualizar tu kernel Linux