Centro di Conoscenza DevOps
Centro di Conoscenza DevOps

Guida Completa ai Cgroup di Systemd per la Limitazione e l'Isolamento delle Risorse

Padroneggia la gestione delle risorse Linux con systemd e cgroups. Questa guida spiega come utilizzare slice, scope e servizi di systemd per applicare limiti precisi a CPU, memoria e I/O. Impara a isolare processi critici, prevenire l'esaurimento delle risorse e garantire la stabilità del sistema con esempi pratici e migliori pratiche per un'efficace ottimizzazione delle prestazioni.

39 visualizzazioni

Guida completa ai cgroup di Systemd per la limitazione e l'isolamento delle risorse

Systemd, il moderno sistema di inizializzazione e gestore di sistema e servizi per Linux, offre potenti strumenti per la gestione delle risorse di sistema. Tra le sue capacità più significative vi è l'integrazione con i Control Group (cgroup), una funzionalità del kernel Linux che consente la limitazione, la contabilità e l'isolamento dell'utilizzo delle risorse (CPU, memoria, I/O disco, rete, ecc.) per un insieme di processi. Questa guida approfondirà come systemd utilizza i cgroup attraverso i suoi tipi di unità—slice, scope e service—per abilitare una limitazione e un isolamento precisi delle risorse, garantendo che i processi critici ricevano le risorse di cui hanno bisogno, impedendo al contempo alle applicazioni fuori controllo di influire sulla stabilità del sistema.

Comprendere e sfruttare l'integrazione dei cgroup di systemd è fondamentale per amministratori di sistema, sviluppatori e chiunque sia responsabile del mantenimento delle prestazioni e dell'affidabilità dei sistemi Linux. Impostando limiti di risorse appropriati, è possibile prevenire l'esaurimento delle risorse, migliorare la prevedibilità delle prestazioni delle applicazioni e aumentare la stabilità generale del sistema. Questa guida fornirà un approccio pratico alla configurazione di questi limiti, rendendo la gestione complessa delle risorse accessibile ed efficace.

Comprensione dei Control Group (cgroup)

Prima di addentrarci nell'implementazione di systemd, è essenziale comprendere i concetti fondamentali dei cgroup. I cgroup sono un meccanismo gerarchico nel kernel Linux che consente di raggruppare processi e quindi assegnare politiche di gestione delle risorse a questi gruppi. Tali politiche possono includere:

  • CPU: Limitazione del tempo di CPU, prioritizzazione dell'accesso alla CPU.
  • Memoria: Impostazione dei limiti di utilizzo della memoria, prevenzione delle condizioni di esaurimento della memoria (OOM).
  • I/O: Throttling delle operazioni di lettura/scrittura su disco.
  • Rete: Limitazione della larghezza di banda della rete.
  • Accesso ai Dispositivi: Controllo dell'accesso a dispositivi specifici.

Il kernel espone le configurazioni dei cgroup attraverso un file system virtuale, tipicamente montato in /sys/fs/cgroup. Ogni controller (ad es. cpu, memory) ha la propria directory e, al loro interno, gerarchie di directory rappresentano gruppi e i loro limiti di risorse associati.

Architettura di Gestione dei Cgroup di Systemd

Systemd astrae la complessità della manipolazione diretta dei cgroup fornendo un sistema strutturato di gestione delle unità. Organizza i processi in una gerarchia di unità, che vengono quindi mappate alle gerarchie dei cgroup. I principali tipi di unità rilevanti per la gestione delle risorse sono:

  • Slice: Questi sono contenitori astratti per le unità di servizio. Gli slice formano una gerarchia, consentendo la delega delle risorse. Ad esempio, uno slice per le sessioni utente potrebbe contenere slice per singole applicazioni. Systemd crea automaticamente slice per i servizi di sistema, le sessioni utente e le macchine virtuali/container.
  • Scope: Questi sono tipicamente utilizzati per gruppi di processi temporanei o creati dinamicamente, spesso associati a sessioni utente o servizi di sistema che non sono gestiti come unità di servizio complete. Sono transitori ed esistono finché i processi al loro interno sono in esecuzione.
  • Service: Queste sono le unità fondamentali per la gestione di daemon e applicazioni. Quando un'unità di servizio viene avviata, systemd inserisce i suoi processi in una gerarchia di cgroup, solitamente all'interno di uno slice. I limiti di risorse possono essere applicati direttamente alle unità di servizio.

La gerarchia predefinita di systemd spesso appare così:

-.slice (Slice root)
  |- system.slice
  |  |- <service_name>.service
  |  |- another-service.service
  |  ... 
  |- user.slice
  |  |- user-1000.slice
  |  |  |- session-c1.scope
  |  |  |  |- <application>.service (se avviato dall'utente)
  |  |  |  ...
  |  |  ...
  |  ... 
  |- machine.slice (per VM/container)
  ...

Applicazione dei Limiti di Risorse con i File di Unità di Systemd

Systemd consente di specificare i limiti di risorse dei cgroup direttamente all'interno dei file di unità .service, .slice o .scope. Queste direttive sono collocate rispettivamente nelle sezioni [Service], [Slice] o [Scope].

Limiti CPU

Le direttive principali per il controllo delle risorse CPU sono:

  • CPUQuota=: Limita il tempo totale di CPU che l'unità può utilizzare. Questo viene specificato come percentuale (ad es. 50% per metà core CPU) o come frazione di un core CPU (ad es. 0.5). È anche possibile specificare un valore in microsecondi per periodo. Il periodo predefinito è 100ms.
  • CPUShares=: Imposta un peso relativo per il tempo di CPU. Un'unità con CPUShares=2048 otterrà il doppio del tempo di CPU di un'unità con CPUShares=1024 in caso di contesa.
  • CPUWeight=: Un alias per CPUShares= ma con un intervallo diverso (1-10000, predefinito 100).
  • CPUQuotaPeriodSec=: Imposta il periodo per CPUQuota. Il predefinito è 100ms.

Esempio: Limitare un web server al 75% di un core CPU:

Creare o modificare un file di servizio, ad esempio /etc/systemd/system/mywebapp.service:

[Unit]
Description=La mia applicazione web

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

# Limita al 75% di un core CPU
CPUQuota=75%

[Install]
WantedBy=multi-user.target

Dopo aver creato o modificato il file di servizio, ricaricare il demone systemd e riavviare il servizio:

sudo systemctl daemon-reload
sudo systemctl restart mywebapp.service

Limiti di Memoria

I limiti di memoria sono controllati da direttive come:

  • MemoryLimit=: Imposta un limite rigido sulla quantità di RAM che i processi dell'unità possono consumare. Questo può essere specificato in byte o con suffissi come K, M, G, T (ad es. 512M).
  • MemoryMax=: Simile a MemoryLimit, ma spesso considerato più moderno e flessibile nel modo in cui interagisce con la contabilità della memoria. È generalmente raccomandato rispetto a MemoryLimit.
  • MemoryHigh=: Imposta un limite morbido. Quando questo limite viene raggiunto, la liberazione della memoria (swapping) viene attivata in modo più aggressivo, ma il limite rigido non è ancora applicato.
  • MemorySwapMax=: Limita la quantità di spazio di swap che l'unità può utilizzare.

Esempio: Limitare un database a 2GB di RAM:

Creare o modificare un file di servizio, ad esempio /etc/systemd/system/mydb.service:

[Unit]
Description=Il mio servizio di database

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

# Limita la memoria a 2 Gigabyte
MemoryMax=2G

[Install]
WantedBy=multi-user.target

Ricaricare e riavviare:

sudo systemctl daemon-reload
sudo systemctl restart mydb.service

Limiti I/O

Il throttling dell'I/O può essere controllato utilizzando direttive come:

  • IOWeight=: Imposta un peso relativo per le operazioni di I/O. Valori più alti conferiscono maggiore priorità I/O. L'intervallo è da 1 a 1000 (predefinito 500).
  • IOReadBandwidthMax=: Limita la larghezza di banda I/O in lettura. Specificato come [<dispositivo>] <byte_al_secondo>. Ad esempio, IOReadBandwidthMax=/dev/sda 100M limita le operazioni di lettura su /dev/sda a 100MB/s.
  • IOWriteBandwidthMax=: Limita la larghezza di banda I/O in scrittura. Formato simile a IOReadBandwidthMax.

Esempio: Limitare un servizio di elaborazione batch a 50MB/s su un disco specifico:

Creare o modificare un file di servizio, ad es. /etc/systemd/system/batchproc.service:

[Unit]
Description=Servizio di elaborazione batch

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

# Limita le operazioni di scrittura a 50MB/s su /dev/sdb
IOWriteBandwidthMax=/dev/sdb 50M

# Dagli una priorità di lettura moderata
IOWeight=200

[Install]
WantedBy=multi-user.target

Ricaricare e riavviare:

sudo systemctl daemon-reload
sudo systemctl restart batchproc.service

Gestione e Monitoraggio dei Cgroup

Systemd fornisce strumenti per ispezionare e gestire i cgroup associati alle tue unità.

Ispezione dello Stato dei Cgroup

Il comando systemctl status fornisce informazioni sull'appartenenza ai cgroup di un'unità e sull'utilizzo delle risorse.

systemctl status mywebapp.service

Cerca le righe che indicano il percorso del cgroup. Ad esempio:

● mywebapp.service - La mia applicazione web
     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

Puoi anche ispezionare direttamente il file system dei cgroup:

systemd-cgls # Mostra la gerarchia dei cgroup gestiti da systemd
systemd-cgtop # Simile a top, ma per i cgroup

Per visualizzare i limiti specifici applicati al cgroup di un servizio:

# Per i limiti di memoria
catsysfs /sys/fs/cgroup/memory/system.slice/mywebapp.service/memory.max

# Per i limiti CPU
catsysfs /sys/fs/cgroup/cpu/system.slice/mywebapp.service/cpu.max

(Nota: i percorsi esatti e i nomi dei file potrebbero variare leggermente a seconda della versione del cgroup e della configurazione del sistema.)

Modifica dei Limiti dei Cgroup al Volo

Sebbene sia buona norma impostare i limiti nei file di unità, puoi modificarli temporaneamente utilizzando systemctl set-property:

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

Queste modifiche non sono persistenti ai riavvii. Per renderle permanenti, aggiorna il file di unità e ricarica il demone systemd.

Slice per la Delega delle Risorse

Gli slice sono potenti per gestire gruppi di servizi o applicazioni. Puoi definire limiti di risorse su uno slice, e tutti i servizi o scope all'interno di quello slice erediteranno o saranno vincolati da tali limiti.

Esempio: Creazione di uno slice dedicato per job batch intensivi dal punto di vista delle risorse:

Crea un file slice, ad es. /etc/systemd/system/batch.slice:

[Unit]
Description=Slice per l'elaborazione batch

[Slice]
# Limita la CPU totale per tutti i job in questo slice a 1 core
CPUQuota=100%
# Limita la memoria totale a 4GB
MemoryMax=4G

Ora puoi configurare i servizi per essere eseguiti all'interno di questo slice utilizzando la direttiva Slice= nei loro file .service:

[Unit]
Description=Job batch specifico

[Service]
ExecStart=/usr/bin/mybatchjob

# Inserisci questo servizio nello slice batch
Slice=batch.slice

[Install]
WantedBy=multi-user.target

Ricarica systemd, abilita/avvia lo slice se necessario (anche se spesso viene attivato implicitamente) e avvia il servizio.

sudo systemctl daemon-reload
sudo systemctl start mybatchjob.service

Questo approccio consente di raggruppare processi correlati e gestire il loro consumo collettivo di risorse.

Best Practice e Considerazioni

  • Inizia con Limiti Incrementali: Quando imposti i limiti, inizia con valori conservativi e aumentali gradualmente secondo necessità. Limiti aggressivi possono destabilizzare le applicazioni.
  • Monitora: Monitora regolarmente l'utilizzo delle risorse del tuo sistema e l'impatto delle impostazioni dei cgroup. Strumenti come systemd-cgtop, htop, top e iotop sono inestimabili.
  • Comprendi cgroup v1 vs v2: Systemd supporta sia cgroup v1 che v2. Sebbene molte direttive siano simili, v2 offre una gerarchia unificata e alcune differenze comportamentali. Assicurati di essere consapevole di quale versione il tuo sistema sta utilizzando se riscontri problemi complessi.
  • Prioritizzazione vs. Limiti Rigidi: Usa CPUShares/CPUWeight per la prioritizzazione quando le risorse sono scarse, e CPUQuota per limiti rigidi. Allo stesso modo, MemoryHigh è per limiti morbidi e MemoryMax per limiti rigidi.
  • Servizio vs. Slice: Usa le unità di servizio per singole applicazioni e gli slice per gestire gruppi di applicazioni correlate o pool di risorse.
  • Documentazione: Documenta chiaramente i limiti di risorse applicati ai servizi critici, specialmente in ambienti di produzione.
  • OOM Killer: Sii consapevole che se un processo supera il suo limite MemoryMax, l'Out-Of-Memory (OOM) killer del kernel potrebbe terminarlo, anche se è all'interno di un cgroup. Systemd può gestire come si comporta l'OOM killer per cgroup specifici utilizzando direttive come OOMPolicy=.

Conclusione

L'integrazione di Systemd con i cgroup fornisce un meccanismo robusto e di facile utilizzo per controllare e isolare le risorse di sistema. Padroneggiando l'uso delle unità di servizio, scope e slice, gli amministratori possono applicare efficacemente limiti di CPU, memoria e I/O per garantire la stabilità del sistema, prestazioni prevedibili e prevenire la fame di risorse. L'implementazione di questi controlli è un aspetto fondamentale dell'amministrazione moderna dei sistemi Linux, consentendo un maggiore controllo sui tuoi ambienti applicativi e sull'infrastruttura sottostante.