Administrar grupos de control con systemd | Activar el administrador del sistema

En esta entrega final de mi serie de artículos sobre grupos de control de cuatro partes, analizo la integración de grupos de control con systemd. También asegúrese de revisar las piezas a, de ellos, y Tres en la serie

Índice

    Grupos de control con systemd

    Por defecto, systemd crea un nuevo cgroup bajo el system.slice para cada servicio que supervisa. Volviendo a nuestro host OpenShift Control Plane, ejecutando systemd-cgls muestra los siguientes servicios bajo el 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 modificando el archivo de servicio systemd. Hay tres opciones cuando se trata de administrar cgroups con systemd:

    • Modificación del propio fichero de servicios.
    • Uso de archivos de inserción.
    • Utilizando systemctl set-property comandos, que son lo mismo que la edición manual de archivos, pero systemctl crea las entradas necesarias para usted.

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

    Edición de archivos de servicio

    Modifiquemos 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 bajo el 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é? La respuesta tiene que ver con cómo systemd interpreta los cgroups anidados. Los niños se declaran de la siguiente manera: -.slice. Dado que systemd intenta ser útil, si un padre no existe, systemd lo crea para usted. Si hubiera usado guiones bajos _ en lugar de guiones - el resultado hubiera sido lo que esperabas:

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

    Uso de archivos de inserción

    Los archivos de inserción para systemd son bastante sencillos de configurar. Comience por crear 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 como quieras. Se ejecutan en 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 obligarte a correr systemctl daemon-reload cada vez que ajuste cualquiera de estos archivos.

    Creé dos archivos de inserción para mostrar cómo puedes separar 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 un servicio:

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

    El otro archivo define 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 distinguir entre procesos, el segundo script es ligeramente diferente:

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

    Entonces simplemente creé copias de los 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

    En lugar de mostrarte la salida de top, este es el momento adecuado para presentarte systemd-cgtop. Funciona igual que normal top excepto que le brinda un desglose por tramo, luego nuevamente por servicio en cada tramo. 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 tanto la agregación de todos los servicios en un segmento particular como parte del sistema general como el uso de recursos de cada servicio en un segmento:

    Utilice la propiedad de conjunto systemctl

    El último método que se puede utilizar para configurar cgroups es el systemctl set-property pedido. 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

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

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

    # systemctl set-property md5sum.service CPUShares=1024

    Esto crea un archivo de repositorio para usted ubicado en /etc/systemd/system.control/md5sum.service.d/50-CPUShares.conf. No dude en consultar 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 en 1024. Finalmente, cat.service un 256.

    Conclusión

    Espero que hayas aprendido algo nuevo en nuestro viaje juntos. Había mucho por hacer y apenas arañamos la superficie de lo que es posible con los grupos de control. Además del papel que juegan los grupos de control para mantener su sistema saludable, también juegan un papel en una estrategia de "defensa en profundidad". Además, los cgroups son un componente esencial para las cargas de trabajo modernas de Kubernetes, donde ayudan a que los procesos en contenedores funcionen sin problemas. Los grupos de control son responsables de muchas cosas, entre ellas:

    • Limite los recursos del proceso.
    • Decidir sobre las prioridades cuando surjan conflictos.
    • Controle el acceso a dispositivos de lectura/escritura y mknod.
    • Proporcionar un alto nivel de contabilidad para los procesos que se ejecutan en un sistema.

    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 de historias, 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-introducción-a-linux-control-groups-cgroups
    https://itnext.io/chroot-cgroups-and-namespaces-an-overview-37124d995e3d
    https://www.certdepot.net/rhel7-get-started-cgroups/
    https://access.tipstecnologicos.es/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.tipstecnologicos.es/en/blog/world-domination-cgroups-part-1-cgroup-basics
    https://www.tipstecnologicos.es/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.tipstecnologicos.es/solutions/4489171

    Artículos de interés

    Subir