Gestire cgroup con systemd

In questa puntata finale della mia serie di articoli in quattro parti su cgroups, mi occupo dell'integrazione di cgroup con systemd. Assicurati di controllare anche le parti uno, due e tre della serie.

Cgroup con systemd

Per impostazione predefinita, systemd crea un nuovo cgroup sotto system.slice per ogni servizio monitorato. Tornando al nostro host OpenShift Control Plane, eseguendo systemd-cgls mostra i seguenti servizi sotto system.slice (l'output è troncato per brevità):

└─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]

È possibile modificare questo comportamento modificando il file di servizio systemd. Esistono tre opzioni per quanto riguarda la gestione di cgroup con systemd:

• Modifica del file di servizio stesso.
• Utilizzo dei file drop-in.
• Utilizzo di systemctl set-property comandi, che sono gli stessi della modifica manuale dei file, ma systemctl crea le voci richieste per te.

Di seguito li tratterò in modo più dettagliato.

Modifica dei file di servizio

Modifichiamo il file dell'unità stesso. Per fare ciò, ho creato un file unit molto semplice che esegue uno script:

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

[Install]
WantedBy=multi-user.target

Lo script bash ha solo due righe:

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

Quando esamini l'output di systemd-cgls , vedi che il nostro nuovo servizio è nidificato in system.slice (output troncato):

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

Cosa succede se aggiungo la seguente riga al file del servizio systemd?

Slice=my-beautiful-slice.slice

L'output di systemd-cgls mostra qualcosa di curioso. Il cat.service il file è ora profondamente nidificato:

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

Perchè è questo? La risposta ha a che fare con il modo in cui systemd interpreta i cgroup nidificati. I bambini vengono dichiarati nel modo seguente:-.slice . Poiché systemd cerca di essere utile, se un genitore non esiste, systemd lo crea per te. Se avessi usato caratteri di sottolineatura _ invece dei trattini - il risultato sarebbe stato quello che ti saresti aspettato:

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

Utilizzo dei file drop-in

I file drop-in per systemd sono abbastanza banali da configurare. Inizia creando una directory appropriata basata sul nome del tuo servizio in /etc/systemd/system . Nel cat esempio, eseguire il comando seguente:

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

Questi file possono essere organizzati come preferisci. Vengono gestiti in base all'ordine numerico, quindi dovresti nominare i tuoi file di configurazione come 10-CPUSettings.conf . Tutti i file in questa directory dovrebbero avere l'estensione di file .conf e richiedono di eseguire systemctl daemon-reload ogni volta che modifichi uno di questi file.

Ho creato due file drop-in per mostrare come dividere diverse configurazioni. Il primo è 00-slice.conf . Come mostrato di seguito, imposta le opzioni predefinite per una sezione separata per il cat servizio:

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

L'altro file imposta il numero di CPUShares e si chiama 10-CPUSettings.conf .

[Service]
CPUShares=256

Per dimostrare che questo metodo funziona, creo un secondo servizio nella stessa sezione. Per rendere più facile distinguere i processi, il secondo script è leggermente diverso:

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

Quindi ho semplicemente creato delle copie del cat file, sostituendo lo script e modificando il valore 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

Infine, ricarica il demone e avvia i servizi:

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

[ Ai lettori è piaciuto anche:cosa succede dietro le quinte di un contenitore Podman senza radici? ]

Invece di mostrarti l'output da top , ora è un buon momento per presentarti systemd-cgtop . Funziona in modo simile al normale top tranne per il fatto che ti fornisce una ripartizione per sezione e poi di nuovo per servizi in ogni sezione. Questo è molto utile per determinare se stai facendo un buon uso di cgroup in generale sul tuo sistema. Come mostrato di seguito, systemd-cgtop mostra sia l'aggregazione per tutti i servizi in una particolare sezione come parte del sistema generale sia l'utilizzo delle risorse di ciascun servizio in una sezione:

Utilizzo della proprietà set systemctl

L'ultimo metodo che può essere utilizzato per configurare cgroup è la systemctl set-property comando. Inizierò con un file di servizio di base md5sum.service :

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

[Install]
WantedBy=multi-user.target

Usando la systemctl set-property comando inserisce i file in /etc/systemd/system.control . Questi file non devono essere modificati manualmente. Non tutte le proprietà sono riconosciute da set-property comando, quindi Slice la definizione è stata inserita nel file di servizio stesso.

Dopo aver impostato il file unit e aver ricaricato il demone, utilizzo il systemctl comando simile al seguente:

# systemctl set-property md5sum.service CPUShares=1024

Questo crea un file drop-in che si trova in /etc/systemd/system.control/md5sum.service.d/50-CPUShares.conf . Sentiti libero di guardare i file se sei curioso del loro contenuto. Poiché questi file non sono pensati per essere modificati a mano, non ci dedicherò tempo.

Puoi verificare se le modifiche hanno avuto effetto eseguendo:

systemctl start md5sum.service cat.service sha256sum.service

Come puoi vedere nello screenshot qui sotto, le modifiche sembrano aver avuto successo. sha256sum.service è configurato per 2048 CPUShares, mentre md5sum.service ha 1024. Infine, cat.service ne ha 256.

[ Stai pensando alla sicurezza? Dai un'occhiata a questa guida gratuita per aumentare la sicurezza del cloud ibrido e proteggere la tua azienda. ] 

Concludi

Spero che tu abbia imparato qualcosa di nuovo durante il nostro viaggio insieme. C'era molto da affrontare e abbiamo a malapena scalfito la superficie su ciò che è possibile con cgroups. A parte il ruolo che i cgroup svolgono nel mantenere in salute il tuo sistema, svolgono anche un ruolo in una strategia di "difesa in profondità". Inoltre, i cgroup sono un componente fondamentale per i moderni carichi di lavoro Kubernetes, in cui aiutano nella corretta esecuzione dei processi containerizzati. I Cgroup sono responsabili di tante cose, tra cui:

• Limitazione delle risorse dei processi.
• Decidere le priorità quando sorgono contese.
• Controllo dell'accesso ai dispositivi di lettura/scrittura e mknod.
• Fornire un livello elevato di contabilità per i processi in esecuzione su un sistema.

Si potrebbe obiettare che la containerizzazione, Kubernetes e una miriade di altre implementazioni business-critical non sarebbero possibili senza sfruttare cgroups.

Se hai domande o commenti o forse altre idee per articoli, non esitare a contattarmi su Twitter. Non vedo l'ora di sentire tutti i tuoi commenti.

Fonti

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