Kernel de Linux 6.x: novedades relevantes para servidores de alojamiento

Clasificar correctamente el estado del kernel

La denominación «Linux 6.x» agrupa numerosas versiones principales, no un nivel de funcionalidad uniforme. Se considera «mainline» la rama principal mantenida por Linus Torvalds: tras la ventana de fusión suelen aparecer las versiones candidatas hasta llegar a la versión principal definitiva. Hay que distinguirlas de las ramas «Stable» y «LTS», que siguen manteniendo los núcleos publicados con correcciones seleccionadas. Por su parte, los núcleos de las distribuciones siguen sus propias versiones de paquetes, compromisos de soporte y decisiones de integración.

Precisamente para los servidores de alojamiento son Puertas traseras Es fundamental: una distribución puede incorporar funciones concretas, mejoras en los controladores o correcciones de seguridad en un núcleo más antiguo que se mantiene a largo plazo. Por el contrario, puede desactivar funciones, modificar parches o limitarlos mediante la configuración. Por lo tanto, a partir de un número de versión no se puede deducir ni el conjunto completo de funciones ni el efecto concreto en el funcionamiento.

El comando uname -r Identifica la cadena de versión actual y constituye un buen punto de partida para realizar un inventario y una comparación de paquetes. Sin embargo, no garantiza que una función esté compilada, activada en tiempo de ejecución o sea accesible para una aplicación. Además, una nueva versión del núcleo no sustituye a la comprobación de la configuración y la documentación proporcionadas por el distribuidor.

Para realizar una clasificación fiable, debes analizar varios niveles: distribución y estado de los paquetes, configuración del núcleo, parámetros de arranque e interfaces de tiempo de ejecución existentes. A esto hay que añadir el hardware, el firmware y los controladores, por ejemplo, en el caso del almacenamiento o la virtualización. Por último, la aplicación utilizada debe utilizar realmente una interfaz; una función existente del núcleo no modifica automáticamente un servidor web.

Por lo tanto, este artículo no sigue una cronología completa de las versiones. Se centra en las funciones relevantes para el funcionamiento de los núcleos 6.x actuales. No todas ellas se introdujeron por primera vez en la serie 6.x; lo decisivo es el nivel de funcionalidad disponible en el núcleo concreto, las posibles ampliaciones y las repercusiones en el comportamiento de la memoria, la concurrencia de la CPU, el aislamiento de procesos y el mantenimiento.

Cuatro áreas de servicio de alojamiento web

En el caso de los servidores de alojamiento, hay cuatro ámbitos operativos especialmente relevantes: presión de almacenamiento, competencia por la CPU, aislamiento adicional de procesos y mantenimiento. No se trata de activar el mayor número posible de funciones del núcleo, sino de utilizar las herramientas adecuadas para un problema concreto. Los grupos de PHP-FPM, las bases de datos, las cachés, los trabajos por lotes y los trabajadores especializados plantean requisitos distintos que no pueden deducirse únicamente a partir de la versión del núcleo.

cgroup v2 Se trata de un tema transversal, pero no es una novedad de la serie 6.x. La jerarquía estructura los recursos de memoria y CPU para servicios, contenedores o grupos de clientes. Para saber qué controladores están disponibles y activados en una subjerarquía, hay que comprobarlo en el montaje correspondiente de cgroup-v2. Por lo tanto, un servidor web dedicado requiere una evaluación diferente a la de un contenedor o un host de máquinas virtuales.

La tabla distingue deliberadamente entre la configuración de compilación, la activación al arrancar, la interfaz en tiempo de ejecución y el uso real. Una función puede estar incluida en el núcleo, pero estar desactivada o carecer de relevancia para la aplicación. Del mismo modo, las distribuciones pueden retroportar funciones. Por lo tanto, evalúa los cambios basándote en la evolución de la carga, la estructura de cgroups, el hardware y los valores de medición de la aplicación, en lugar de basarte en el número de versión más alto disponible.

Presión de memoria y recuperación de páginas

A Linux le gusta utilizar la memoria libre como caché de archivos. Por lo tanto, el hecho de que haya mucha RAM ocupada no es, en sí mismo, un error ni una señal de desperdicio de memoria: las páginas de archivo almacenadas en caché pueden recuperarse cuando sea necesario. Para el diagnóstico, son más relevantes la evolución y las consecuencias de la carga, como los tiempos de respuesta, la actividad del intercambio, los registros de errores y las interrupciones de procesos.

La presión de almacenamiento es determinante Recuperación de páginas , qué páginas se pueden eliminar de la caché o, en su caso, se pueden trasladar a la memoria secundaria. El núcleo puede realizar esta tarea de forma asíncrona a través de kswapd realizar. Si un proceso tiene que recuperar páginas por sí mismo al realizar una solicitud de memoria, la documentación del núcleo habla de «recuperación directa»; esto puede afectar al proceso solicitante y, por lo tanto, a las latencias observadas.

Las señales de alerta suelen presentarse como una combinación de factores: la transferencia continua de datos al espacio de intercambio o desde él, los eventos OOM, el aumento de los tiempos de espera y los errores a nivel de aplicación merecen ser analizados en una línea temporal conjunta. Por el contrario, una oscilación puntual puede deberse a un trabajo por lotes programado. Tampoco un servicio de caché que consuma una gran cantidad de RAM es automáticamente la causa, siempre que su cgroup y el resto de procesos sigan teniendo capacidad de funcionamiento suficiente.

cgroup v2 amplía la visión global con límites de servicio o de contenedor. El controlador de almacenamiento proporciona contadores de eventos; memory.events es jerárquico, mientras que memory.events.local que solo muestra los eventos locales del cgroup correspondiente. De este modo, se puede distinguir si un problema se debe al límite del propio servicio o a la carga en una estructura de nivel superior.

Estos aspectos básicos aún no justifican el tuning. Antes de modificar los límites, la estrategia de intercambio o las interfaces del kernel, debes clasificar las fuentes de carga, la asignación de cgroups y la correlación temporal. En particular, un límite de memoria muy estricto puede provocar que un servicio falle antes de tiempo, en lugar de resolver el pico de carga subyacente. Solo el diagnóstico revela si un cambio dispone realmente de un ajuste técnico adecuado.

Comprobación específica de LRU multigeneración

Multi-Gen LRU es una implementación alternativa para Recuperación de páginas y se describe en la documentación del núcleo que aquí se trata, a partir de Linux 6.1. Cuando hay presión sobre la memoria, el núcleo debe decidir qué páginas de la caché de archivos o de memoria anónima pueden recuperarse. Para ello, Multi-Gen LRU clasifica las páginas en generaciones según su antigüedad de acceso y tiene en cuenta los patrones de acceso, de modo que sea menos probable que las páginas que se necesitan con frecuencia sean seleccionadas para su recuperación.

Esto es relevante en el caso de un servidor de alojamiento web muy saturado, en el que los grupos de PHP-FPM, una base de datos y un servicio de caché consumen memoria RAM al mismo tiempo. Esta función puede modificar la selección que se realiza durante el proceso de recuperación de memoria, pero no supone ni una ampliación de la memoria ni una garantía de tiempos de respuesta más cortos. La carga de trabajo, la capacidad de RAM, el espacio de intercambio, el almacenamiento masivo y los límites de cgroup de los servicios siguen determinando si se nota algún efecto y de qué manera.

Antes de cada evaluación, comprueba primero si la interfaz de tiempo de ejecución está presente y es legible. La documentación actual del núcleo indica las opciones de configuración para ello: CONFIG_LRU_GEN y CONFIG_LRU_GEN_ENABLED así como la ruta en /sys/kernel/mm/lru_gen/. Un núcleo de distribución puede retroportar versiones de funciones o configurarlas de otra manera; por lo tanto, el número de versión por sí solo no constituye una prueba fiable.

test -r /sys/kernel/mm/lru_gen/enabled && cat /sys/kernel/mm/lru_gen/enabled

En un primer momento, una salida solo comprueba que la interfaz sysfs documentada exista y sea legible. Para determinar el estado de activación, lo relevante es el valor del bit: 0x0001 Es el interruptor principal de Multi-Gen LRU. Si falta este bit, el archivo puede mostrar un interruptor principal desactivado a pesar de que la interfaz esté disponible; los demás bits se refieren a componentes adicionales. El hecho de que el bit principal esté activado tampoco supone una recomendación general para modificar el valor en producción.

Por lo tanto, los accesos de escritura a sysfs no forman parte del ajuste estándar. En primer lugar, recopila series temporales sobre «Reclaim», «Swap», latencias y eventos de cgroup; en caso de un cambio justificado, documenta el valor inicial y establece un plan de retorno. De este modo, se podrá comprobar si el problema observado ha cambiado realmente o si simplemente se han modificado varias variables de control al mismo tiempo.

Debes tener especial cuidado cuando los límites de memoria son escasos y los servicios están sobrecargados. Un algoritmo «Reclaim» modificado no corrige los pools de trabajadores PHP demasiado grandes, las cachés de bases de datos inadecuadas ni la falta de separación entre clientes que compiten entre sí. El orden adecuado es el siguiente: determinar la causa y el cgroup afectado, limitar o distribuir la carga y, solo después, evaluar una función disponible del núcleo como posible factor influyente.

Identificar con precisión los problemas de memoria

La RAM ocupada no es en sí misma un error: Linux utiliza la memoria libre específicamente como caché de archivos. Es más probable que haya que tomar medidas cuando las necesidades en Reclaim directo funcionan, aumenta la actividad de swap, se producen eventos OOM o las consultas se ralentizan simultáneamente. Recuperación asíncrona mediante kswapd funciona en segundo plano; por el contrario, la recuperación directa se lleva a cabo en el contexto de la tarea que solicita la memoria y puede retrasar su ejecución.

El archivo de eventos memory.events cuenta los eventos de forma jerárquica, es decir, incluyendo los cgroups subordinados. Para la vista exclusivamente local, se utiliza memory.events.local listo. high significa la limitación de la potencia y la recuperación directa tras superar el límite de memory.high, mientras que oom cuenta como una asignación fallida cuando se alcanza el límite del cgroup. oom_kill Por el contrario, cuenta los procesos de este cgroup que han sido finalizados por cualquier tipo de «OOM-killer».

Comienza el diagnóstico con una identificación clara: ¿qué servicio o contenedor pertenece al cgroup sospechoso?, ¿cuándo se produjeron los incidentes? y ¿qué señales de la aplicación se observaron al mismo tiempo? A continuación, compara los contadores locales con los jerárquicos, el registro del sistema, el historial de swap, así como las latencias HTTP, los tiempos de espera de la base de datos o las tasas de error. En caso de un error OOM, hay que aclarar además si los datos apuntan a un proceso relacionado con el cgroup o a una posible falta de memoria global.

El valor memory.max Se trata de un límite estricto de cgroup y no es la primera medida que se debe adoptar. Un límite más estricto puede proteger a los clientes, pero también puede provocar que una aplicación entre antes en situaciones de OOM; un límite más alto puede agravar la competencia por recursos entre servicios vecinos. Por lo tanto, comprueba primero el número de trabajadores, el tamaño de la caché, los picos de carga y la estructura del cgroup. A continuación, modifica solo un parámetro justificado, con un periodo de observación y un plan de reversión.

Entender la EEVDF y la competencia entre CPU

La documentación oficial actual del núcleo establece el inicio de la transición a EEVDF Linux 6.6. El algoritmo «Earliest Eligible Virtual Deadline First» modifica la selección de tareas normales planificadas de forma equitativa: se tienen en cuenta el tiempo de ejecución virtual, el retraso como desviación respecto a la distribución ideal y los plazos virtuales. De este modo, las tareas elegibles con el plazo virtual más temprano pueden obtener tiempo de CPU en primer lugar.

El término „transición“ es importante. EEVDF no sustituye la decisión de selección de la clase Fair Scheduling en el sentido de que desaparezcan todas las estructuras de datos, interfaces y conceptos que históricamente se han denominado CFS. Además, la documentación actual sigue comparando EEVDF con CFS. Por lo tanto, para un núcleo de distribución concreto, es necesario comprobar su estado integrado de parches y funciones, en lugar de basarse únicamente en 6.6 o superior, deducir un comportamiento totalmente uniforme.

En lo que respecta al alojamiento web, este cambio es especialmente relevante en caso de cargas mixtas. Las solicitudes web, las operaciones con bases de datos y la supervisión compiten, por ejemplo, con las importaciones, la compresión o las copias de seguridad. Es posible que se produzca un perfil de latencia diferente entre los estados del núcleo, pero esto no implica automáticamente un mayor rendimiento global. El programador no resuelve los problemas derivados de núcleos que funcionan a plena capacidad de forma permanente, procesos bloqueados, tiempos de espera de E/S y configuraciones de aplicaciones inadecuadas.

La separación operativa sigue realizándose en función de los límites de los servicios y las plataformas. Las ponderaciones de CPU influyen en la distribución relativa en caso de competencia, mientras que las cuotas pueden limitar el tiempo de cálculo disponible. Si es necesario separar de forma fiable la carga web, en la que la latencia es un factor crítico, de los trabajos por lotes de gran volumen, también puede resultar adecuado utilizar una máquina virtual propia o un servidor independiente. EEVDF sustituye a estos Planificación de recursos no.

Antes de consultar cgroup.controllers Tienes que comprobar si cgroup v2 está montado y, en caso afirmativo, dónde. El siguiente proceso de lectura busca el punto de montaje de cgroup v2, en lugar de la ruta habitual /sys/fs/cgroup Se debe dar por supuesto. En un sistema que utilice exclusivamente cgroup v1, la variable permanece vacía; en una jerarquía híbrida, solo muestra el montaje v2 encontrado.

uname -r
findmnt -t cgroup2 -o TARGET,FSTYPE,OPTIONS
CG2=$(findmnt -n -t cgroup2 -o TARGET | head -n 1)
if [ -n "$CG2" ] && [ -r "$CG2/cgroup.controllers" ]; then
    printf 'cgroup-v2 mount: %s\n' "$CG2"
    cat "$CG2/cgroup.controllers"
    test -r "$CG2/cgroup.subtree_control" && cat "$CG2/cgroup.subtree_control"
fi
systemd-cgtop

uname -r solo indica la cadena de versión actual. cgroup.controllers enumera los controladores que están disponibles para su activación precisamente en este cgroup; no confirma que se hayan activado en las subjerarquías pertinentes. Para ello se utiliza, entre otros, cgroup.subtree_control deberá comprobarse en los respectivos niveles jerárquicos. Los controladores se habilitan de arriba abajo, por lo que un cgroup hijo solo puede transferir los controladores proporcionados por el nodo padre.

systemd-cgtop Esto también ofrece solo una instantánea y no constituye un análisis de las causas. Recopila la carga de la CPU por grupo de servicios, las latencias de las solicitudes, los tiempos de ejecución de los trabajos por lotes y, si procede, los tiempos de espera de E/S durante varias fases de carga comparables. Si los retrasos solo se producen durante una copia de seguridad, su ventana de tiempo, su peso en la CPU o su cuota suelen ser puntos de ajuste iniciales más concretos que un supuesto ajuste del programador.

Landlock para trabajadores especializados

Landlock se introdujo por primera vez con Linux 5.13, por lo que no es una novedad propia de la serie 6.x. En los núcleos 6.x hay disponibles diferentes niveles avanzados de ABI, dependiendo de la versión y del núcleo de la distribución. Esta función es un mecanismo de seguridad complementario que permite a un proceso imponerse restricciones adicionales.

Como módulo de seguridad de Linux apilable, Landlock actúa de forma complementaria a las decisiones de acceso ya vigentes; no sustituye ni a los permisos de archivo de Unix ni a SELinux, AppArmor, los espacios de nombres ni los contenedores. Las reglas pueden, entre otras cosas, limitar el acceso al sistema de archivos y se transmiten a los procesos hijos que se inician posteriormente. El conjunto de funciones prácticas depende de la ABI disponible y de la configuración del núcleo.

Lo más sensato es Sin salida al mar sobre todo para procesos individuales desarrollados internamente o seleccionados específicamente. Un conversor para las subidas de los clientes podría leer archivos únicamente de una carpeta de entrada y guardar los resultados exclusivamente en una carpeta de salida. Incluso si el servicio se procesa de forma errónea, no debe poder leer ni claves SSH, ni secretos de aplicaciones, ni rutas generales del sistema. Esta restricción complementa una asignación cuidadosa de permisos, pero no la hace innecesaria.

Una regla productiva no debe basarse únicamente en un kernel actual. Landlock cuenta con versiones de ABI; una aplicación debería consultar la ABI disponible en tiempo de ejecución y solicitar únicamente los derechos de acceso o las funciones que dicha ABI admita. De este modo, podrá funcionar de forma escalonada en sistemas más antiguos, en lugar de dejar de funcionar por completo debido a una interfaz no disponible.

Por otra parte, establece handled_access_fs establece explícitamente qué accesos al sistema de archivos gestiona un conjunto de reglas y cuáles se deniegan por defecto a falta de una regla adecuada. Este acuerdo explícito entre la aplicación y el núcleo evita que un entorno aislado se vuelva más estricto de forma inadvertida solo por una actualización del sistema y, por lo tanto, provoque fallos en las aplicaciones. Por lo tanto, la consulta de la ABI y los derechos tratados explícitamente van de la mano, pero resuelven tareas de compatibilidad diferentes.

Para el conversor de archivos, esto se traduce en una implementación por etapas: deducir los directorios de lectura, escritura y de trabajo necesarios a partir del flujo de trabajo real, tener en cuenta las rutas de error y comprobarlos primero en el entorno de prueba. Una política de ejemplo demasiado sucinta no constituiría una receta de producción fiable, ya que los archivos temporales, las bibliotecas externas y los programas auxiliares iniciados pueden requerir accesos adicionales. El artículo sobre Fortalecimiento del kernel para servidores de alojamiento.

Se debe tener especial precaución en los siguientes casos: OverlayFS. Las reglas de una capa de superposición no limitan automáticamente la jerarquía de montajes fusionada, y viceversa. Por ello, los entornos de contenedores y de compilación con superposiciones requieren una comprobación específica de los montajes concretos y las rutas de acceso. Landlock es una posible capa adicional en este contexto, pero no supone una separación generalizada de clientes ni sustituye a un concepto sólido de contenedores o de permisos.

DAMON, solo para casos excepcionales

No se puede afirmar de manera generalizada que DAMON y los mecanismos de recuperación basados en él sean funciones introducidas por primera vez con Linux 6.x. Para los administradores, lo que cuenta es el estado funcional del núcleo 6.x o de la distribución que se utilice concretamente. DAMON supervisa los accesos a la memoria con el objetivo de poder clasificar las áreas según su comportamiento de uso.

Partiendo de ahí, se intenta DAMON_RECLAIM, recuperar de forma proactiva la memoria que lleva mucho tiempo sin utilizarse aplicando una ligera presión. Este procedimiento complementa la recuperación normal basada en LRU; no pretende sustituirla. La documentación del núcleo lo clasifica dentro de los sistemas de memoria con sobreasignación general y cita como ejemplo la virtualización basada en el informe de páginas libres.

En este escenario de virtualización, el nivel es decisivo: los invitados notifican al anfitrión las páginas de memoria libres, que este puede asignar a otros invitados. Si un invitado notifica poca memoria libre, aunque mantenga páginas que llevan mucho tiempo sin utilizarse, se puede aplicar una recuperación proactiva como invitado contribuir a notificar más páginas libres al host. Por lo tanto, DAMON_RECLAIM no es, sin una comprobación adicional, una solución por parte del host para la memoria no utilizada de los invitados.

Por lo tanto, no se trata de una medida estándar para un único servidor web o de base de datos. Incluso en entornos virtualizados, primero hay que determinar claramente en qué nivel se produce la sobrecarga y si la causa son realmente áreas que llevan mucho tiempo sin utilizarse. Los cuellos de botella en la CPU, un almacenamiento lento, límites de cgroup inadecuados o cachés de aplicaciones activas pueden explicar los mismos síntomas, sin que la recuperación proactiva sea la respuesta adecuada.

Los porcentajes, los límites de antigüedad y las marcas de agua determinan cuándo y en qué medida funciona DAMON_RECLAIM. No se trata de valores predeterminados que se puedan aplicar de forma generalizada: una selección demasiado agresiva puede desplazar prematuramente la caché de archivos útil o las páginas de memoria que se necesitan de forma recurrente. Esto puede provocar operaciones de E/S adicionales y consumir tiempo de CPU para volver a realizar el trabajo, aunque la memoria libre nominal aumente.

Por lo tanto, para tomar una decisión fundamentada es necesario realizar mediciones con parámetros de referencia claros, como el espacio libre en el almacenamiento declarado por el usuario, la actividad de recuperación, el comportamiento del intercambio, la latencia del almacenamiento y los tiempos de respuesta de las aplicaciones. Prueba primero los cambios en un entorno de prueba comparable, establece un plan de reversión y obsérvalos durante fases de carga representativas. Si no se cumplen estos requisitos o si la causa de la presión sobre el almacenamiento no está clara, DAMON permanecerá desactivado de forma deliberada.

Actualizaciones, parches en tiempo real y reinicios

El mantenimiento del núcleo comienza con la comparación entre el aviso de seguridad, el paquete instalado y el núcleo que se está ejecutando realmente. A continuación, comprueba en las instrucciones de tu propia distribución qué corrección está prevista para esa rama concreta del núcleo y si es necesario reiniciar el sistema. Un número de versión 6.x más alto por sí solo no garantiza ni que se incluya el parche ni que haya disponible un «livepatch» adecuado; las correcciones de seguridad también pueden portarse a núcleos de distribuciones anteriores.

También Aplicación de parches en tiempo real No se introdujo como concepto por primera vez con Linux 6.x. La infraestructura relevante para los núcleos 6.x permite aplicar determinados cambios en el núcleo en tiempo de ejecución. Los parches acumulativos en tiempo real pueden sustituir de forma atómica un parche antiguo por uno más reciente. Las limitaciones documentadas se refieren, entre otras cosas, a los cambios de estado, las llamadas de retorno y el cambio entre parches.

Para saber si existe un «Livepatch» adecuado para un kernel de distribución concreto, hay que consultar la oferta correspondiente y las autorizaciones del proveedor. De la infraestructura general del núcleo no se deduce ni que todas las correcciones de seguridad estén disponibles en tiempo real, ni que un parche instalado sustituya de forma permanente a una actualización completa del núcleo. Por lo tanto, sigue programando ventanas de mantenimiento periódicas.

En primer lugar, evalúa la urgencia y el impacto de una actualización; a continuación, compara el estado de los paquetes y el kernel actual, y comprueba la propuesta concreta de Livepatch. Tras una actualización normal del kernel con reinicio, comprueba si el kernel esperado está activo y si los servicios críticos, las rutas de red, las copias de seguridad y la supervisión funcionan correctamente. Esta comprobación forma parte del proceso de mantenimiento y no debe deducirse únicamente de la simple accesibilidad del servidor.

A reinicio previsto puede seguir siendo necesario a pesar del «live patching». Los cambios en los parámetros de arranque del núcleo no suelen surtir efecto hasta el siguiente arranque. En el caso de los controladores, el firmware de los dispositivos y el hardware, el procedimiento depende, en cambio, del componente, de su integración y de los procedimientos del fabricante: en algunos casos basta con reiniciar un módulo, un dispositivo o un servicio; en otros, es necesario reiniciar completamente el host.

El artículo complementario sobre Aplicación de parches en tiempo real en servidores AlmaLinux Trata una implementación concreta dependiente de la distribución. No apliques estos procedimientos sin comprobarlos previamente a otras ramas del núcleo o a otros proveedores. Lo que prevalece son los paquetes, las versiones del núcleo compatibles y las instrucciones de uso de la plataforma que se utilice realmente.

• No cambiar nada a propósito si la avería observada aún no tiene una causa identificable.
• No se debe planificar ningún parche en vivo ni modificación del núcleo sin una prueba de staging adecuada y un proceso de reversión documentado.
• No se debe activar ninguna función si la aplicación o plataforma en cuestión no utiliza su interfaz.
• No hay que sustituir la falta de una ventana de mantenimiento por la suposición de que el «live patching» cubre todas las actualizaciones del kernel.