Quindi hai sentito parlare di questa cosa chiamata cgroups e sei interessato a saperne di più. Forse ne hai sentito parlare mentre ascoltavi un discorso sulla containerizzazione. Forse stavi esaminando l'ottimizzazione delle prestazioni di Linux, o forse un giorno stavi attraversando il tuo file system e hai scoperto /sys/fs/cgroups . Ad ogni modo, vuoi saperne di più su questa funzionalità che è stata inserita nel kernel per un po' di tempo. Quindi siediti, prendi dei popcorn e preparati a (si spera) imparare qualcosa che potresti non sapere prima.
Cosa sono i cgroup?
Il dizionario di Webster definisce cgroups come... Sto solo scherzando. Ho sempre odiato ascoltare discorsi che iniziavano con definizioni noiose del dizionario. Invece, cercherò di distillare la definizione tecnica di cgroup in qualcosa di facile da capire.
I Cgroup sono un argomento enorme. Ho suddiviso questa discussione in una serie di quattro parti. La prima parte, questo articolo, copre i concetti fondamentali dei cgroup. La seconda parte esamina CPUShare in modo più approfondito. La terza parte, intitolata "Fare cgroup nel modo più duro", esamina le attività amministrative di cgroup. Infine, la quarta parte copre i cgroup gestiti da systemd.
Come forse saprai o meno, il kernel Linux è responsabile dell'interazione affidabile di tutto l'hardware su un sistema. Ciò significa che, a parte solo i bit di codice (driver) che consentono al sistema operativo (OS) di comprendere l'hardware, pone anche limiti al numero di risorse che un particolare programma può richiedere al sistema. Questo è più facilmente comprensibile quando si parla della quantità di memoria (RAM) che un sistema deve suddividere tra tutte le applicazioni che il tuo computer potrebbe eseguire. Nella sua forma più elementare, un sistema Linux può eseguire la maggior parte delle applicazioni senza restrizioni. Questo può essere ottimo per l'informatica generale se tutte le applicazioni funzionano bene insieme. Ma cosa succede se c'è un bug in un programma e inizia a consumare tutta la memoria disponibile? Il kernel ha una funzione chiamata Out Of Memory (OOM) Killer. Il suo compito è fermare le applicazioni per liberare RAM sufficiente in modo che il sistema operativo possa continuare a funzionare senza arresti anomali.
È fantastico, dici, ma cosa ha a che fare con cgroups? Bene, il processo OOM funge da ultima linea di difesa prima che il tuo sistema si blocchi intorno a te. È utile fino a un certo punto, ma poiché il kernel può controllare quali processi devono sopravvivere all'OOM, può anche determinare quali applicazioni non possono consumare troppa RAM in primo luogo.
I Cgroup sono, quindi, una struttura integrata nel kernel che consente all'amministratore di impostare limiti di utilizzo delle risorse su qualsiasi processo sul sistema. In generale, cgroups controlla:
- Il numero di condivisioni CPU per processo.
- I limiti di memoria per processo.
- Blocca I/O dispositivo per processo.
- Quali pacchetti di rete sono identificati come dello stesso tipo in modo che un'altra applicazione possa applicare le regole del traffico di rete.
Ci sono più sfaccettature oltre a queste, ma queste sono le categorie principali a cui interessa la maggior parte degli amministratori.
Gli umili inizi di Cgroups
I gruppi di controllo (cgroup) sono un meccanismo del kernel Linux per il controllo granulare delle risorse. Inizialmente proposti dagli ingegneri di Google nel 2006, i cgroup sono stati infine fusi nel kernel Linux intorno al 2007. Sebbene attualmente ci siano due versioni di cgroup, la maggior parte delle distribuzioni e dei meccanismi utilizza la versione 1, poiché è stata nel kernel dalla 2.6.24. Come con la maggior parte delle cose aggiunte al kernel principale, all'inizio non c'era un enorme tasso di adozione. La versione 2 continua questa tendenza, essendo in circolazione da quasi mezzo decennio ma non ancora ampiamente implementata.
Un problema che affligge l'adozione di cgroup è la mancanza di conoscenza della sua esistenza e del suo ruolo nel moderno sistema Linux. Una scarsa consapevolezza e adozione spesso significa che l'interazione con un'interfaccia del kernel è goffa, contorta o semplicemente un processo manuale. Inizialmente era il caso di cgroups. Certo, non è così difficile creare cgroup una tantum. Ad esempio, se volevi simulare i primi giorni prima che fosse sviluppato il tooling attorno a cgroups, potresti creare un mucchio di directory, montare il cgroup filesystem e inizia a configurare tutto a mano. Ma prima di arrivare a tutto questo, parliamo un po' del perché i cgroup sono vitali nell'ecosistema Linux di oggi.
Perché i cgroup sono importanti
I Cgroup hanno quattro caratteristiche principali strettamente correlate tra loro che li rendono molto importanti in un sistema moderno, soprattutto se stai eseguendo un carico di lavoro containerizzato.
1. Limitazione delle risorse
Come accennato in precedenza, i cgroup consentono a un amministratore di garantire che i programmi in esecuzione sul sistema rimangano entro determinati limiti accettabili per CPU, RAM, I/O di dispositivi a blocchi e gruppi di dispositivi.
NOTA :i gruppi di dispositivi CGroup possono essere un componente chiave della strategia di sicurezza completa del tuo sistema. I gruppi di dispositivi includono il controllo delle autorizzazioni di lettura, scrittura e mknod operazioni. Le operazioni di lettura/scrittura sono abbastanza autoesplicative, quindi diamo un'occhiata a mknod funzionalità in un sistema Linux. mknod è stato inizialmente progettato per popolare tutte le cose che appaiono in /dev/ . Si tratta di cose come dischi rigidi, interfacce USB per dispositivi come Arduino, microcontrollori ESP8266 o altri dispositivi che potrebbero esistere su un sistema. La maggior parte dei moderni sistemi Linux utilizza udev per popolare automaticamente questo filesystem virtuale con le cose rilevate dal kernel. mknod consente inoltre a più programmi di comunicare tra loro creando una named pipe. Questo concetto esula dallo scopo di questa spiegazione, ma è sufficiente comprendere che ciò facilita il passaggio di informazioni da un programma all'altro. Indipendentemente da ciò, il mknod in un ambiente controllato è qualcosa che un amministratore dovrebbe esaminare attentamente per limitare.
2. Priorità
La definizione delle priorità è leggermente diversa dalla limitazione delle risorse perché non si limitano necessariamente i processi. Invece, stai semplicemente dicendo che, indipendentemente dal numero di risorse disponibili, elabora X avrà sempre più tempo sul sistema rispetto al processo Y .
3. Contabilità
Sebbene l'accounting sia disattivato per impostazione predefinita per la maggior parte delle versioni aziendali di Linux a causa dell'utilizzo aggiuntivo delle risorse, può essere davvero utile attivare l'utilizzo delle risorse per un albero particolare (ne parleremo più avanti). Puoi quindi vedere quali processi all'interno di quale cgroup stanno consumando quali tipi o risorse.
4. Controllo di processo
C'è una funzione in cgroups chiamata freezer . Sebbene una profonda comprensione di questa funzionalità esuli dallo scopo di questo articolo, puoi pensare al congelatore come alla capacità di scattare un'istantanea di un particolare processo e spostarlo. Consulta la documentazione del kernel per una comprensione più approfondita.
Ok, quindi cosa significa tutto questo? Bene, dal punto di vista di un amministratore di sistema, significa diverse cose.
Innanzitutto, anche senza approfondire la tecnologia dei container, significa che puoi ottenere una maggiore densità su un singolo server gestendo con attenzione il tipo di carico di lavoro, le applicazioni e le risorse che richiedono.
In secondo luogo, migliora un po' la tua posizione di sicurezza. Sebbene una tipica installazione Linux utilizzi cgroups per impostazione predefinita, non pone alcuna restrizione ai processi. Puoi imporre restrizioni per impostazione predefinita, se lo desideri. Puoi anche limitare l'accesso a dispositivi specifici per utenti, gruppi o processi specifici, il che aiuta ulteriormente a bloccare un sistema.
Infine, puoi eseguire una quantità significativa di ottimizzazione delle prestazioni tramite cgroups. Ciò, in combinazione con tuning, significa che puoi creare un ambiente appositamente adattato per i tuoi carichi di lavoro individuali. Su larga scala, o in un ambiente sensibile alla latenza, queste modifiche possono fare la differenza tra il rispetto o la mancanza degli accordi sul livello di servizio (SLA).
Come funzionano i cgroup?
Ai fini di questa discussione, stiamo parlando di cgroups V1 . Sebbene la versione 2 sia disponibile in Red Hat Enterprise Linux 8 (RHEL 8), è disabilitata per impostazione predefinita. La maggior parte delle tecnologie container come Kubernetes, OpenShift, Docker e così via si basano ancora su cgroups versione 1.
Abbiamo già discusso del fatto che i cgroup sono un meccanismo per controllare alcuni sottosistemi nel kernel. Questi sottosistemi, come dispositivi, CPU, RAM, accesso alla rete e così via, sono chiamati controller nella terminologia di cgroup.
Ogni tipo di controller (cpu , blkio , memory , ecc.) è suddiviso in una struttura ad albero. Ogni ramo o foglia ha i suoi pesi o limiti. Un gruppo di controllo ha più processi associati, rendendo l'utilizzo delle risorse granulare e facile da mettere a punto.
NOTA :Ogni figlio eredita ed è limitato dai limiti impostati sul cgroup padre.
Nel diagramma sopra, puoi vedere che è possibile avere PID 1 nella memory , disk i/o e cpu gruppi di controllo. I cgroup vengono creati per tipo di risorsa e non hanno alcuna associazione tra loro. Ciò significa che potresti avere un database gruppo associato a tutti i controllori, ma i gruppi sono trattati in modo indipendente. Come i GID, a questi gruppi viene assegnato un valore numerico al momento della creazione e non un nome descrittivo. Sotto il cofano, il kernel usa questi valori per determinare l'allocazione delle risorse. Per pensarci in un altro modo, supponiamo che ogni nome cgroup, una volta collegato a un controller, sia rinominato con il nome del controller più il nome di tua scelta. Quindi un gruppo chiamato database nella memory il controller può effettivamente essere considerato memory-database . Pertanto, non esiste alcuna relazione con un database gruppo associato al controller cpu poiché il nome descrittivo può essere considerato come cpu-database .
NOTA :Questa è una semplificazione grossolana e NON è tecnicamente accurata se stai cercando di essere coinvolto con il codice cgroup sottostante. La spiegazione di cui sopra serve per chiarezza di comprensione.
Concludi
Quindi ora hai un'idea di cosa sono i cgroup e di come potrebbero aiutarti con l'ottimizzazione delle prestazioni e la sicurezza. Hai anche una migliore comprensione di come i cgroup interagiscono con i controller.
Questo articolo non è una ripartizione di tutti i tipi di controller che esistono in cgroups. Qualcosa di simile richiederebbe un intero libro per essere spiegato correttamente. Nel prossimo articolo, esaminerò CPUShares a causa della loro relativa complessità e dell'importanza che svolgono nella salute generale di un sistema. Gli altri controller funzionano in modo simile. Pertanto, dovresti essere in grado di trarre le lezioni apprese dal controller della CPU e applicarle alla maggior parte dei restanti controller cgroup.
Non dimenticare che nella terza parte esamineremo le attività amministrative e nella quarta parte concluderemo con come systemd interagisce con cgroups.
[ Iniziare con i container? Dai un'occhiata a questo corso gratuito. Distribuzione di applicazioni containerizzate:una panoramica tecnica. ]