Centro de Conocimiento DevOps
Centro de Conocimiento DevOps

Guía completa de cgroups de Systemd para limitación y aislamiento de recursos

Domina la gestión de recursos de Linux con systemd y cgroups. Esta guía explica cómo usar slices, scopes y services de systemd para aplicar límites precisos de CPU, memoria y E/S. Aprende a aislar procesos críticos, prevenir el agotamiento de recursos y garantizar la estabilidad del sistema con ejemplos prácticos y mejores prácticas para una optimización eficaz del rendimiento.

34 vistas

Guía Completa de Cgroups de Systemd para la Limitación y Aislamiento de Recursos

Systemd, el sistema de inicialización moderno y gestor de sistemas y servicios para Linux, ofrece potentes herramientas para la administración de recursos del sistema. Entre sus capacidades más significativas se encuentra la integración con los Control Groups (cgroups), una característica del kernel de Linux que permite la limitación, contabilidad y aislamiento del uso de recursos (CPU, memoria, E/S de disco, red, etc.) para una colección de procesos. Esta guía profundizará en cómo systemd utiliza los cgroups a través de sus tipos de unidades—slices, scopes y services—para permitir la limitación y el aislamiento precisos de recursos, asegurando que los procesos críticos reciban los recursos que requieren mientras previene que las aplicaciones descontroladas impacten la estabilidad del sistema.

Comprender y aprovechar la integración de cgroups de systemd es crucial para los administradores de sistemas, desarrolladores y cualquier persona responsable de mantener el rendimiento y la fiabilidad de los sistemas Linux. Al establecer límites de recursos apropiados, puede prevenir el agotamiento de recursos, mejorar la previsibilidad del rendimiento de las aplicaciones y aumentar la estabilidad general del sistema. Esta guía proporcionará un enfoque práctico para configurar estos límites, haciendo que la gestión compleja de recursos sea accesible y efectiva.

Comprensión de los Control Groups (cgroups)

Antes de sumergirnos en la implementación de systemd, es esencial comprender los conceptos fundamentales de los cgroups. Los Cgroups son un mecanismo jerárquico en el kernel de Linux que permite agrupar procesos y luego asignarles políticas de gestión de recursos a esos grupos. Estas políticas pueden incluir:

  • CPU: Limitar el tiempo de CPU, priorizar el acceso a la CPU.
  • Memoria: Establecer límites de uso de memoria, previniendo condiciones de falta de memoria (OOM).
  • I/O: Controlar las operaciones de lectura/escritura en disco.
  • Red: Limitar el ancho de banda de la red.
  • Acceso a Dispositivos: Controlar el acceso a dispositivos específicos.

El kernel expone las configuraciones de cgroup a través de un sistema de archivos virtual, típicamente montado en /sys/fs/cgroup. Cada controlador (por ejemplo, cpu, memory) tiene su propio directorio, y dentro de estos, jerarquías de directorios representan grupos y sus límites de recursos asociados.

Arquitectura de Gestión de Cgroups de Systemd

Systemd abstrae la complejidad de la manipulación directa de cgroups al proporcionar un sistema de gestión de unidades estructurado. Organiza los procesos en una jerarquía de unidades, que luego se mapean a jerarquías de cgroup. Los tipos de unidades principales relevantes para la gestión de recursos son:

  • Slices: Son contenedores abstractos para unidades de servicio. Los Slices forman una jerarquía, permitiendo la delegación de recursos. Por ejemplo, un slice para sesiones de usuario podría contener slices para aplicaciones individuales. Systemd crea automáticamente slices para servicios del sistema, sesiones de usuario y máquinas virtuales/contenedores.
  • Scopes: Estos se utilizan típicamente para grupos de procesos temporales o creados dinámicamente, a menudo asociados con sesiones de usuario o servicios del sistema que no se gestionan como unidades de servicio completas. Son transitorios y existen mientras los procesos dentro de ellos estén en ejecución.
  • Services: Estas son las unidades fundamentales para gestionar demonios y aplicaciones. Cuando se inicia una unidad de servicio, systemd coloca sus procesos en una jerarquía de cgroup, generalmente dentro de un slice. Los límites de recursos se pueden aplicar directamente a las unidades de servicio.

La jerarquía predeterminada de Systemd a menudo se ve así:

-.slice (Slice Raíz)
  |- system.slice
  |  |- <service_name>.service
  |  |- another-service.service
  |  ... 
  |- user.slice
  |  |- user-1000.slice
  |  |  |- session-c1.scope
  |  |  |  |- <application>.service (si es iniciado por el usuario)
  |  |  |  ...
  |  |  ...
  |  ... 
  |- machine.slice (para VMs/contenedores)
  ...

Aplicación de Límites de Recursos con Archivos de Unidad de Systemd

Systemd permite especificar límites de recursos de cgroup directamente dentro de los archivos de unidad .service, .slice o .scope. Estas directivas se colocan bajo las secciones [Service], [Slice] o [Scope], respectivamente.

Límites de CPU

Las directivas principales para el control de recursos de CPU son:

  • CPUQuota=: Limita el tiempo total de CPU que la unidad puede utilizar. Esto se especifica como un porcentaje (p. ej., 50% para la mitad de un núcleo de CPU) o una fracción de un núcleo de CPU (p. ej., 0.5). También es posible especificar un valor en microsegundos por período. El período predeterminado es 100 ms.
  • CPUShares=: Establece una ponderación relativa para el tiempo de CPU. Una unidad con CPUShares=2048 obtendrá el doble de tiempo de CPU que una unidad con CPUShares=1024 cuando haya contención.
  • CPUWeight=: Un alias para CPUShares= pero con un rango diferente (1-10000, predeterminado 100).
  • CPUQuotaPeriodSec=: Establece el período para CPUQuota. El predeterminado es 100ms.

Ejemplo: Limitar un servidor web al 75% de un núcleo de CPU:

Cree o edite un archivo de servicio, por ejemplo, /etc/systemd/system/mywebapp.service:

[Unit]
Description=My Web Application

[Service]
ExecStart=/usr/bin/mywebapp
User=webappuser
Group=webappgroup

# Limitar al 75% de un núcleo de CPU
CPUQuota=75%

[Install]
WantedBy=multi-user.target

Después de crear o modificar el archivo de servicio, recargue el demonio de systemd y reinicie el servicio:

sudo systemctl daemon-reload
sudo systemctl restart mywebapp.service

Límites de Memoria

Los límites de memoria se controlan mediante directivas como:

  • MemoryLimit=: Establece un límite estricto en la cantidad de RAM que pueden consumir los procesos de la unidad. Esto se puede especificar en bytes o con sufijos como K, M, G, T (p. ej., 512M).
  • MemoryMax=: Similar a MemoryLimit, pero a menudo se considera más moderno y flexible en cómo interactúa con la contabilidad de la memoria. Generalmente se recomienda sobre MemoryLimit.
  • MemoryHigh=: Establece un límite blando. Cuando se aproxima este límite, la recuperación de memoria (swapping) se activa de manera más agresiva, pero el límite estricto aún no se aplica.
  • MemorySwapMax=: Limita la cantidad de espacio de intercambio (swap) que la unidad puede utilizar.

Ejemplo: Limitar una base de datos a 2 GB de RAM:

Cree o edite un archivo de servicio, por ejemplo, /etc/systemd/system/mydb.service:

[Unit]
Description=My Database Service

[Service]
ExecStart=/usr/bin/mydb
User=dbuser
Group=dbgroup

# Limitar la memoria a 2 Gigabytes
MemoryMax=2G

[Install]
WantedBy=multi-user.target

Recargar y reiniciar:

sudo systemctl daemon-reload
sudo systemctl restart mydb.service

Límites de E/S

El control de E/S (I/O throttling) se puede controlar utilizando directivas como:

  • IOWeight=: Establece una ponderación relativa para las operaciones de E/S. Los valores más altos dan mayor prioridad de E/S. El rango es de 1 a 1000 (predeterminado 500).
  • IOReadBandwidthMax=: Limita el ancho de banda de E/S de lectura. Se especifica como [<device>] <bytes_per_second>. Por ejemplo, IOReadBandwidthMax=/dev/sda 100M limita las operaciones de lectura en /dev/sda a 100 MB/s.
  • IOWriteBandwidthMax=: Limita el ancho de banda de E/S de escritura. Formato similar a IOReadBandwidthMax.

Ejemplo: Limitar un servicio de procesamiento en segundo plano a 50 MB/s en un disco específico:

Cree o edite un archivo de servicio, p. ej., /etc/systemd/system/batchproc.service:

[Unit]
Description=Batch Processing Service

[Service]
ExecStart=/usr/bin/batchproc
User=batchuser
Group=batchgroup

# Limitar las operaciones de escritura a 50 MB/s en /dev/sdb
IOWriteBandwidthMax=/dev/sdb 50M

# Darle una prioridad de lectura moderada
IOWeight=200

[Install]
WantedBy=multi-user.target

Recargar y reiniciar:

sudo systemctl daemon-reload
sudo systemctl restart batchproc.service

Gestión y Monitorización de Cgroups

Systemd proporciona herramientas para inspeccionar y gestionar los cgroups asociados a sus unidades.

Inspección del Estado de Cgroup

El comando systemctl status proporciona información sobre la membresía del cgroup de una unidad y su uso de recursos.

systemctl status mywebapp.service

Busque las líneas que indican la ruta del cgroup. Por ejemplo:

● mywebapp.service - My Web Application
     Loaded: loaded (/etc/systemd/system/mywebapp.service; enabled; vendor preset: enabled)
     Active: active (running) since Tue 2023-10-27 10:00:00 UTC; 1 day ago
       Docs: man:mywebapp(8)
   Main PID: 12345 (mywebapp)
      Tasks: 5 (limit: 4915)
     Memory: 15.5M
        CPU: 2h 30m 15s
      CGroup: /system.slice/mywebapp.service
              └─12345 /usr/bin/mywebapp

También puede inspeccionar directamente el sistema de archivos cgroup:

systemd-cgls # Muestra la jerarquía de cgroup gestionada por systemd
systemd-cgtop # Similar a top, pero para cgroups

Para ver los límites específicos aplicados al cgroup de un servicio:

# Para límites de memoria
catsysfs /sys/fs/cgroup/memory/system.slice/mywebapp.service/memory.max

# Para límites de CPU
catsysfs /sys/fs/cgroup/cpu/system.slice/mywebapp.service/cpu.max

(Nota: Las rutas exactas y los nombres de archivo pueden variar ligeramente dependiendo de la versión de cgroup y la configuración del sistema.)

Modificación de Límites de Cgroup al Vuelo

Aunque la mejor práctica es establecer límites en los archivos de unidad, puede ajustarlos temporalmente utilizando systemctl set-property:

sudo systemctl set-property mywebapp.service CPUQuota=50%

Estos cambios no son persistentes después de los reinicios. Para hacerlos permanentes, actualice el archivo de unidad y recargue el demonio de systemd.

Slices (Segmentos) para la Delegación de Recursos

Los Slices son potentes para gestionar grupos de servicios o aplicaciones. Puede definir límites de recursos en un slice, y todos los servicios o scopes dentro de ese slice heredarán o estarán restringidos por esos límites.

Ejemplo: Creación de un slice dedicado para trabajos por lotes intensivos en recursos:

Cree un archivo slice, p. ej., /etc/systemd/system/batch.slice:

[Unit]
Description=Batch Processing Slice

[Slice]
# Limitar el total de CPU para todos los trabajos en este slice a 1 núcleo
CPUQuota=100%
# Limitar la memoria total a 4GB
MemoryMax=4G

Ahora, puede configurar servicios para que se ejecuten dentro de este slice utilizando la directiva Slice= en sus archivos .service:

[Unit]
Description=Specific Batch Job

[Service]
ExecStart=/usr/bin/mybatchjob

# Colocar este servicio en el batch.slice
Slice=batch.slice

[Install]
WantedBy=multi-user.target

Recargue systemd, habilite/inicie el slice si es necesario (aunque a menudo se activa implícitamente) e inicie el servicio.

sudo systemctl daemon-reload
sudo systemctl start mybatchjob.service

Este enfoque le permite agrupar procesos relacionados y gestionar su consumo colectivo de recursos.

Mejores Prácticas y Consideraciones

  • Comience con Límites Incrementales: Al establecer límites, comience con valores conservadores y auméntelos gradualmente según sea necesario. Los límites agresivos pueden desestabilizar las aplicaciones.
  • Monitorización: Monitoree regularmente el uso de recursos de su sistema y el impacto de sus configuraciones de cgroup. Herramientas como systemd-cgtop, htop, top e iotop son invaluables.
  • Comprenda Cgroup v1 vs. v2: Systemd admite tanto cgroup v1 como v2. Aunque muchas directivas son similares, v2 ofrece una jerarquía unificada y algunas diferencias de comportamiento. Asegúrese de saber qué versión está utilizando su sistema si encuentra problemas complejos.
  • Priorización vs. Límites Estrictos: Utilice CPUShares/CPUWeight para la priorización cuando los recursos son escasos, y CPUQuota para límites estrictos fijos. De manera similar, MemoryHigh es para límites blandos y MemoryMax para límites estrictos.
  • Service vs. Slice: Utilice unidades de servicio para aplicaciones individuales y slices para gestionar grupos de aplicaciones relacionadas o pools de recursos.
  • Documentación: Documente claramente los límites de recursos aplicados a servicios críticos, especialmente en entornos de producción.
  • OOM Killer: Tenga en cuenta que si un proceso excede su límite MemoryMax, el eliminador por falta de memoria (OOM killer) del kernel podría terminarlo, incluso si está dentro de un cgroup. Systemd puede gestionar cómo se comporta el OOM killer para cgroups específicos utilizando directivas como OOMPolicy=.

Conclusión

La integración de Systemd con cgroups proporciona un mecanismo robusto y fácil de usar para controlar y aislar los recursos del sistema. Al dominar el uso de las unidades service, scope y slice, los administradores pueden aplicar eficazmente límites de CPU, memoria y E/S para garantizar la estabilidad del sistema, un rendimiento predecible y evitar la inanición de recursos. La implementación de estos controles es un aspecto fundamental de la administración moderna de sistemas Linux, permitiendo un mayor control sobre sus entornos de aplicación y la infraestructura subyacente.