GNU/Linux >> Tutoriales Linux >  >> Linux

Administrar cgroups con systemd

En esta entrega final de mi serie de artículos de cgroups de cuatro partes, cubro la integración de cgroup con systemd. Asegúrese de consultar también las partes uno, dos y tres de la serie.

Cgrupos con systemd

Por defecto, systemd crea un nuevo cgroup bajo system.slice para cada servicio que supervisa. Volviendo a nuestro host OpenShift Control Plane, ejecutando systemd-cgls muestra los siguientes servicios bajo system.slice (la salida se trunca por brevedad):

└─system.slice
  ├─sssd.service
  ├─lvm2-lvmetad.service
  ├─rsyslog.service
  ├─systemd-udevd.service
  ├─systemd-logind.service
  ├─systemd-journald.service
  ├─crond.service
  ├─origin-node.service
  ├─docker.service
  ├─dnsmasq.service
  ├─tuned.service
  ├─sshd.service
  ├─NetworkManager.service
  ├─dbus.service
  ├─polkit.service
  ├─chronyd.service
  ├─auditd.service
    └─[email protected]

Puede cambiar este comportamiento editando el archivo de servicio systemd. Hay tres opciones con respecto a la administración de cgroup con systemd:

  • Editar el propio archivo de servicio.
  • Uso de archivos drop-in.
  • Usando systemctl set-property comandos, que son lo mismo que editar manualmente los archivos, pero systemctl crea las entradas necesarias para usted.

Los cubro con más detalle a continuación.

Edición de archivos de servicio

Editemos el archivo de la unidad en sí. Para hacer esto, creé un archivo de unidad muy simple que ejecuta un script:

[Service]
Type=oneshot
ExecStart=/root/generate_load.sh
TimeoutSec=0
StandardOutput=tty
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

El script bash tiene solo dos líneas:

#!/bin/bash
/usr/bin/cat /dev/urandom > /dev/null &

Cuando examina la salida de systemd-cgls , verá que nuestro nuevo servicio está anidado en system.slice (salida truncada):

└─system.slice
  ├─cat.service
  ├─tuned.service
  ├─sshd.service
  ├─NetworkManager.service
  ├─sssd.service
  ├─dbus.service
  │ └─[email protected]
  └─systemd-logind.service

¿Qué sucede si agrego la siguiente línea al archivo de servicio systemd?

Slice=my-beautiful-slice.slice

La salida de systemd-cgls muestra algo curioso. El cat.service el archivo ahora está profundamente anidado:

Control group /:
├─my.slice
│ └─my-beautiful.slice
│   └─my-beautiful-slice.slice
│     └─cat.service
│       └─4010 /usr/bin/cat /dev/urandom

¿Por qué es esto? La respuesta tiene que ver con la forma en que systemd interpreta los cgroups anidados. Los niños se declaran de la siguiente manera:-.slice . Dado que systemd intenta ser útil, si no existe un padre, systemd lo crea para usted. Si hubiera usado guiones bajos _ en lugar de guiones - el resultado hubiera sido el que esperabas:

Control group /:
├─my_beautiful_slice.slice
│ └─cat.service
│   └─4123 /usr/bin/cat /dev/urandom

Uso de archivos desplegables

Los archivos drop-in para systemd son bastante triviales de configurar. Comience creando un directorio apropiado basado en el nombre de su servicio en /etc/systemd/system . En el cat ejemplo, ejecute el siguiente comando:

# mkdir -p /etc/systemd/system/cat.service.d/

Estos archivos se pueden organizar de la forma que desee. Se activan según el orden numérico, por lo que debe nombrar sus archivos de configuración algo así como 10-CPUSettings.conf . Todos los archivos en este directorio deben tener la extensión de archivo .conf y requiere que ejecutes systemctl daemon-reload cada vez que ajusta uno de estos archivos.

He creado dos archivos desplegables para mostrar cómo puede dividir diferentes configuraciones. El primero es 00-slice.conf . Como se ve a continuación, configura las opciones predeterminadas para un segmento separado para el cat servicio:

[Service]
Slice=AWESOME.slice
MemoryAccounting=yes
CPUAccounting=yes

El otro archivo establece el número de CPUShares y se llama 10-CPUSettings.conf .

[Service]
CPUShares=256

Para mostrar que este método funciona, creo un segundo servicio en el mismo segmento. Para que sea más fácil diferenciar los procesos, el segundo script es ligeramente diferente:

#!/bin/bash
/usr/bin/sha256sum /dev/urandom > /dev/null &

Luego simplemente creé copias del cat archivos, reemplazando el script y cambiando el valor de CPUShares:

# sed 's/load\.sh/load2\.sh/g' cat.service > sha256sum.service
# cp -r cat.service.d sha256sum.service.d
# sed -i 's/256/2048/g' sha256sum.service.d/10-CPUSettings.conf

Finalmente, recarga el daemon e inicia los servicios:

# systemctl daemon-reload
# systemctl start cat.service
# systemctl start sha256sum.service

[ A los lectores también les gustó:¿Qué sucede detrás de escena de un contenedor Podman sin raíces? ]

En lugar de mostrarle la salida de top , ahora es un buen momento para presentarte systemd-cgtop . Funciona de manera similar al top normal. excepto que le brinda un desglose por segmento y luego nuevamente por servicios en cada segmento. Esto es muy útil para determinar si está haciendo un buen uso de cgroups en general en su sistema. Como se ve a continuación, systemd-cgtop muestra la agregación de todos los servicios en un segmento particular como parte del sistema general y la utilización de recursos de cada servicio en un segmento:

Uso de la propiedad set systemctl

El último método que se puede usar para configurar cgroups es systemctl set-property dominio. Comenzaré con un archivo de servicio básico md5sum.service :

[Service]
Type=oneshot
ExecStart=/root/generate_load3.sh
TimeoutSec=0
StandardOutput=tty
RemainAfterExit=yes
Slice=AWESOME.slice

[Install]
WantedBy=multi-user.target

Uso de la propiedad systemctl set-property El comando coloca los archivos en /etc/systemd/system.control . Estos archivos no deben editarse a mano. No todas las propiedades son reconocidas por set-property comando, por lo que el Slice la definición se colocó en el propio archivo de servicio.

Después de configurar el archivo de la unidad y recargar el demonio, uso el systemctl comando similar al siguiente:

# systemctl set-property md5sum.service CPUShares=1024

Esto crea un archivo desplegable para usted ubicado en /etc/systemd/system.control/md5sum.service.d/50-CPUShares.conf . Siéntase libre de mirar los archivos si tiene curiosidad sobre su contenido. Como estos archivos no están destinados a ser editados a mano, no les dedicaré tiempo.

Puede probar para ver si los cambios surtieron efecto ejecutando:

systemctl start md5sum.service cat.service sha256sum.service

Como puede ver en la captura de pantalla a continuación, los cambios parecen ser exitosos. sha256sum.service está configurado para 2048 CPUShares, mientras que md5sum.service tiene 1024. Finalmente, cat.service tiene 256.

[ ¿Está pensando en la seguridad? Consulte esta guía gratuita para impulsar la seguridad de la nube híbrida y proteger su negocio. ] 

Resumir

Con suerte, aprendiste algo nuevo a lo largo de nuestro viaje juntos. Había mucho que abordar y apenas arañamos la superficie de lo que es posible con cgroups. Aparte del papel que juegan los cgroups en mantener su sistema saludable, también juegan un papel en una estrategia de "defensa en profundidad". Además, los cgroups son un componente crítico para las cargas de trabajo modernas de Kubernetes, donde ayudan en el correcto funcionamiento de los procesos en contenedores. Los Cgroups son responsables de muchas cosas, entre ellas:

  • Limitar los recursos de los procesos.
  • Decidir prioridades cuando surjan conflictos.
  • Control de acceso a dispositivos de lectura/escritura y mknod.
  • Proporcionar un alto nivel de contabilidad para los procesos que se ejecutan en un sistema.

Se podría argumentar que la creación de contenedores, Kubernetes y una gran cantidad de otras implementaciones críticas para el negocio no serían posibles sin aprovechar cgroups.

Si tiene alguna pregunta o comentario o tal vez otras ideas para artículos, no dude en comunicarse conmigo en Twitter. Espero escuchar todos sus comentarios.

Fuentes

https://0xax.gitbooks.io/linux-insides/content/Cgroups/linux-cgroups-1.html
https://sysadmincasts.com/episodes/14-introduction-to-linux-control-groups -cgroups
https://itnext.io/chroot-cgroups-and-namespaces-an-overview-37124d995e3d
https://www.certdepot.net/rhel7-get-started-cgroups/
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/resource_management_guide/chap-introduction_to_control_groups
https://oakbytes.wordpress.com/2012/09/02/ cgroup-cpu-allocation-cpu-shares-examples/
https://www.redhat.com/en/blog/world-domination-cgroups-part-1-cgroup-basics
https:/ /www.redhat.com/en/blog/world-domination-cgroups-rhel-8-welcome-cgroups-v2
https://youtu.be/z7mgaWqiV90
https://youtu.be /el7768BNUPw
https://youtu.be/sK5i-N34im8
https://youtu.be/_AODvcO5Q_8
https://youtu.be/x1npPrzyKfs
https:/ /youtu.be/yZpNsDe4Qzg
https://access.redhat.com/solutions/4489171


Linux
  1. Cómo crear un servicio Systemd en Linux

  2. Detener la unidad Systemd junto con otra. ¿Inicio de obras?

  3. ¿Cómo configurar Systemd para convertir un script simple con Standardio en un servicio de red?

  4. systemd - Dando a mi servicio múltiples argumentos

  5. ¿Cómo ejecutar un script con systemd justo antes de apagar?

Cómo ejecutar Jenkins Container como servicio Systemd con Docker

Cómo ejecutar contenedores como servicio Systemd con Podman

Comandos Systemctl para administrar el servicio Systemd

Instale y ejecute Jenkins con Systemd y Docker

Primeros pasos con systemctl

activación de socket systemd frente a xinetd