Cómo Meta aplica parches a Linux a gran escala

• Aplicar parches a servidores Linux es sencillo, pero aplicar parches a decenas de miles de servidores sin tiempo de inactividad no es fácil
• Meta usa Kpatch de Red Hat y KLP (Kernel Live Patching) para aplicar parches a millones de servidores Linux
  • KLP permite aplicar las actualizaciones de seguridad más recientes al kernel de Linux sin reiniciar

Parches en vivo del kernel

• Los parches en vivo del kernel se distribuyen como paquetes que contienen el código corregido, por separado del paquete principal del kernel
• Los parches en vivo son acumulativos, por lo que el parche más reciente incluye todas las correcciones de los parches anteriores
• Los parches en vivo no se aplican a todo; no pueden modificar datos ni estructuras, y crear un parche en vivo requiere trabajo adicional de ingeniería

Kpatch

• Kpatch funciona comparando el kernel original con el kernel parcheado, y luego usa módulos de kernel personalizados para aplicar el nuevo código al kernel en ejecución
• Después, el proceso de Kpatch usa ftrace para inspeccionar la pila de los procesos existentes y verificar si puede aplicar el parche sin efectos perjudiciales
• Si se determina que es seguro, redirige el código en ejecución a la función parcheada y luego elimina el código que ya quedó obsoleto
• En ese momento, el servidor ya tiene el parche aplicado sin provocar tiempo de inactividad

En el caso de Meta

• Por supuesto, en la práctica no es tan simple
• En Meta, al aplicar un parche en vivo, normalmente toma entre 1 y 2 segundos aplicar el parche a un host
• Ese tiempo de 1 a 2 segundos por host es realmente rápido en comparación con kexec, el mecanismo del kernel de Linux para arrancar un nuevo kernel
• No se necesita tiempo de inactividad ni migración de cargas de trabajo; basta con aplicar el parche en vivo y queda listo para usarse de inmediato

Cómo aplicar parches a millones de máquinas

• Cuando se aplican parches a millones de máquinas, eso no es todo
• En Meta, como pueden descubrirse errores durante el despliegue del parche, los administradores primero aplican el parche al nivel de candidatos de lanzamiento
• El package roller que distribuye parches basados en RPM también verifica automáticamente el estado de salud de los servidores
• Meta monitorea fallas, alertas críticas, problemas de aplicaciones y rendimiento en el nuevo kernel, y si la tasa de error supera 1 caída por cada 1000 servidores, el parche se detiene y se revierte al kernel anterior
• Meta usa Kpatch, pero también existen otras alternativas
  • SUSE ofrece kGraft, Oracle usa Ksplice y Canonical soporta Livepatch
  • Sin importar el código, todos ofrecen resultados similares

Opinión de GN⁺

Lo más importante de este artículo es que Meta ha implementado un método eficiente de aplicación de parches sin tiempo de inactividad para millones de servidores en todo el mundo. Este es un tema interesante incluso para ingenieros de software junior y resalta la importancia del mantenimiento y la seguridad en los sistemas Linux. Además, este artículo puede ayudar a entender la complejidad y la necesidad de la tecnología de parches en vivo.

[GN⁺]

Comentarios en Hacker News

• Ksplice es la tecnología original de parcheo en vivo que, después de ser adquirida por Oracle, se extendió a programas de espacio de usuario mientras yo trabajaba allí. Es una tecnología muy genial que no se ha vuelto obsoleta porque, incluso con el cambio hacia la nube, evita la necesidad de reiniciar sistemas completos a gran escala.
• Parece un detalle importante que Meta no haya mencionado cuánto tiempo toma aplicar esto a todo su despliegue. Con el parcheo en vivo, se puede operar sin tiempo de inactividad en servidores, centros de datos y la nube.
• Si trabajas a la escala de Meta, el parcheo en vivo puede tener sentido, pero la mayoría de los servicios y aplicaciones bien diseñados deberían poder tolerar reinicios completos de servidores sin problema. Es difícil imaginar la complejidad de administrar millones de servidores.
• KernelCare es un servicio de parcheo en vivo del kernel que soporta la mayoría de las distribuciones de Linux.
• He usado Kpatch en muchas máquinas virtuales y funciona bastante bien.
• Actualmente operan alrededor de 13 millones de servidores y planean gastar 20 mil millones de dólares en nuevo equipo para centros de datos en 2023 y otros 20 mil millones adicionales en 2024. Actualmente usan CentOS 8 Stream y pronto migrarán a 9.
• Dicen que drenar y volver a habilitar hosts es difícil. En la práctica, eso significa que no es fácil sacar un host de servicio y luego restaurarlo, lo que sugiere que el kernel de Linux no fue diseñado para parcheo en vivo y que intentar hacerlo siempre introduce incertidumbre, además de ser costoso en términos de trabajo de ingeniería y con el desastre siempre al acecho. En cambio, modificar el sistema de drenado y recuperación de servicio de los hosts para que sea muy sólido y confiable traería una gran ganancia en confiabilidad. Este enfoque parece encubrir una disfunción organizacional. Un equipo puede parchear todos los kernels, pero lograr que todos los hosts soporten drenado y recuperación de servicio es imposible, y como no hay incentivos reales para arreglar eso, nadie intenta corregirlo. Solo los hacks llamativos y los proyectos nuevos reciben la recompensa adecuada.
• La mayoría de las organizaciones no obtiene beneficios por imitar a Meta, ni necesita hacerlo.
• Es la primera vez que escucho el concepto de "hiperescala". Me pregunto en qué se diferencia del simple escalado.