Ressourcenkontrolle mit Cgroups

Gruppendynamik

System-Ressourcen sind ein knappes Gut und sollten gerecht aufgeteilt werden. Der Linux-Kernel bietet zur Steuerung der Ressourcen sogenannte ControlGroups an. Prozesse können somit mehr oder weniger Ressourcen zugewiesen bekommen. Mit der Einführung des neuen Init-Systems systemd hat sich allerdings auch in diesem Bereich einiges verändert – zum Positiven.
Allen Unkenrufen zum Trotz ist die E-Mail nach wie vor das Kommunikationsmedium Nummer eins im Unternehmen. Deshalb geben wir in der Februar-Ausgabe eine ... (mehr)

Das Management von System-Ressourcen ist auf klassischen Unix-Systemen ein alter Hut, gewinnt aber mit Virtualisierung an Bedeutung. Linux unterstützt es in Form sogenannter ControlGroups (Cgroups). Hiermit lassen sich die vorhandenen CPU-, Memory- und I/O-Ressourcen auf einzelne Prozesse aufteilen. Es ist beispielsweise möglich, einem Prozess nur eine gewisse Menge an Speicherseiten zuzuweisen (Limitierung), während ein anderer Prozess mehr CPU-Shares in Anspruch nehmen kann als ein anderer (Priorisierung). Zu Abrechnungszwecken ist ebenfalls ein Accounting der Ressourcen möglich. Sind diese Funktionen bereits auf regulären Server-Systemen interessant, werden diese in virtualisierten Umgebungen unbedingt benötigt. Schließlich möchte ein Systemverantwortlicher beispielsweise einem virtuellen Drucker-Server wahrscheinlich eher weniger Ressourcen zuweisen als einem Datenbank-Server, sollten diese einmal zusammen auf einem gemeinsamen Host-System laufen. Auch zur Isolierung einzelner Prozesse kommen Cgroups gerade in virtualisierten Umgebungen zum Einsatz.

Damit eine Einteilung nicht im Blindflug erfolgen muss, ist es hilfreich, eine Ist-Aufnahme vorzunehmen. Für diese Aufgabe ist die Accounting-Funktion der Cgroups sehr nützlich, die die aktuell verwendeten Ressourcen einer Prozess-Gruppe anzeigt. Auf der anderen Seite kommen die Vorteile eines Ressourcen-Managements natürlich auch im Embedded- oder im Mobile-Bereich zum Tragen. Hier ist es wichtig, die wenigen vorhandenen Ressourcen möglichst gewinnbringend zur Verfügung zu stellen.

Im Jahr 2006 haben die beiden Google-Software-Entwickler Rohit Seth und Paul Menage damit begonnen, eine Funktionalität für das Ressourcen-Management unter Linux zu entwicklen. Diese war zum damaligen Zeitpunkt unter dem Namen "process containers" verfügbar und ist unter dem neuen Namen "ControlGroups" in den offiziellen Linux-Kernel Version 2.6.24 aufgenommen worden. Hiermit lassen sich Prozesse zu einzelnen Gruppen zusammenfassen und unterschiedlichen Subsystemen zuweisen.

Im Userspace steht hierfür das Kommandozeilentool cgcreate aus dem Paket libcgroup-tools zur Verfügung. Prozesse, die zu einem bestimmten Cgroup-Subsystem gehören, wie beispielsweise CPUs, Memory und I/O (diese sind auch als sogenannte Ressource-Controller bekannt), werden dann innerhalb einer eigenen Hierarchie verwaltet. Diese lassen sich durch den cgconfig-Daemon in das Dateisystem einbinden und stehen dort dann zur Konfiguration zur Verfügung. Über den Ordner »/cgroup/cpu« erfolgt beispielsweise die Verwaltung der CPU-Shares, während »/cgroup/net_cls« die Verwaltung der Netz-I/O-Auslastung steuert. Konfiguriert werden die Hierarchien über die Konfigurationsdatei »/etc/cgconfig.conf« . Das Tool cgclassify dient schließlich dazu, Prozesse in die gewünschte ControlGroup zu verschieben. Mit cgset können Sie Parameter dieser Gruppe verändern, mit cgget auch wieder abfragen.

Alles Neue bringt systemd

Seit Mitte 2013 und systemd-Version 205 kümmert sich das neue Init-System um die Verwaltung der Ressourcen auf einem Linux-System. Der Kernel stellt die Ressource-Controller über den Dateisystempfad »/sys/fs/cgroup/« zur Verfügung und systemd greift direkt darauf zu. Die Konfiguration der Ressourcen erfolgt entweder über die Konfigurationsdateien der systemd-Units für persistente Services oder über das Tool systemd-run für weniger langlebige Dienste. An dieser Stelle sei noch erwähnt, dass systemd lediglich ein Labeling und eine Gruppierung einzelner Prozesse erfordert, der Zugriff auf Ressource-Controller ist für systemd hingegen komplett optional.

Listing 1: Kernel-Optionen



CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_CGROUP_HUGETLB=y
CONFIG_CGROUP_PERF=y
CONFIG_CGROUP_SCHED=y
CONFIG_BLK_CGROUP=y
CONFIG_NET_CLS_CGROUP=y
CONFIG_CGROUP_NET_PRIO=y
CONFIG_CGROUP_NET_CLASSID=y

In der Kernel-Konfiguration muss somit nur die Option "CONFIG_CGROUPS" aktiv sein. Das ist für Systemverwalter interessant, die sich um die Performance ihres Systems Sorgen machen, da der Einsatz von Ressource-Controllern natürlich einen geringen Performance Overhead mit sich bringt. Für das Ressourcen-Management sind dann aber natürlich auch die Controller selbst notwendig. Dazu müssen die Kernel-Optionen aus Listing 1 gesetzt sein. Welche Ressource-Controller der eingesetzte Kernel dann tatsächlich verwendet, verrät ein Blick in die Datei »/proc/ cgroups« (Listing 2).

Listing 2: Ressource-Controller



# cat /proc/cgroups
#subsys_name    hierarchy    num_cgroups    enabled
cpuset                 2                 1                        1
cpu                     3                 77                      1
cpuacct              3                 77                      1
memory              4                 3                        1
devices               5                 1                        1
freezer                6                 1                        1
net_cls                7                 1                        1
blkio                   8                 77                      1
perf_event          9                 1                        1
net_prio             7                 1                        1

Nähere Informationen zu den einzelnen Ressource-Controllern finden Sie in der Datei »/usr/share/doc/kernel-doc-Kernel-Version/Documentation/cgroups/« der Kernel-Dokumentation.

Systemd erzeugt für jeden gestarteten Service eine eigene CGroup. Hierbei handelt es sich erst einmal um eine reine Gruppierung von Prozessen, die über eine bestimmte Unit-Datei (oder systemd-run) gestartet wurden. Eine Ressourcen-Zuweisung für einen Service findet erst dann statt, wenn Sie das System dann entsprechend konfigurieren.

Accounting für Dovecot

Die Konfiguration könnte beispielsweise folgendermaßen aussehen. Angenommen Sie wollen das Accounting für den IMAP-Server Dovecot aktivieren, legen Sie hierfür zuerst eine neue Unit-Datei des Services im Ordner »/etc/systemd/system« an und lesen Sie darin die bestehende Unit-Datei ein. Über den Abschnitt "Service" können Sie nun das Accounting für den Dienst aktivieren, indem Sie die folgenden Zeilen in der Datei /»etc/systemd/system/dovecot.service« speichern:

.include /usr/lib/systemd/system/dovecot.service
 
[Service]
CPUAccounting=1
MemoryAccounting=1
BlockIOAccounting=1

Anschließend lesen Sie die Konfigurationsdatei für systemd neu ein und starten den IMAP-Dienst erneut:

# systemctl daemon-reload
# systemctl restart dovecot.service

Rufen Sie nun das Tool systemd-cgtop auf, sehen Sie, wieviele Ressourcen die Prozesse aus der Cgroup des IMAP-Servers in Anspruch nehmen. Welche Prozesse dies sind, zeigt »systemd-cgls« an:

# systemd-cgls /system.slice/dovecot.service
/system.slice/dovecot.service:
├─19680 /usr/sbin/dovecot -F
├─19682 dovecot/anvil
├─19683 dovecot/log
...

Um nun die verwendeten Ressourcen zu begrenzen, gehen Sie ähnlich vor. In der Konfigurationsdatei eines Services können Sie die hierfür notwendigen Parameter setzen. Welche Parameter zur Verfügung stehen, sehen Sie in der Hilfeseite "systemd.resource-control". Dort finden Sie eine ausführliche Beschreibung sämtlicher Parameter. Das folgende Beispiel greift auf mehrere Ressource-Controller zurück:

# cat > /etc/systemd/system/dovecot.service 
CPUShares=500
MemoryLimit=1G
_EOF
Denken Sie wieder daran, im Anschluss die Konfigurationsdatei erneut einlesen zu lassen. Dass die Prozesse des Dovecot-Services nun auch tatsächlich auf die Ressource-Controller der beiden Subsysteme CPU und Speicher zurückgreifen, können Sie über einen Blick in die entsprechenden cgroup-Dateien der einzelnen Prozesse im proc-Dateisystem verifizieren:
# cat /proc/29985/cgroup
9:perf_event:/
8:blkio:/
7:net_cls,net_prio:/
6:freezer:/
5:devices:/
4:memory:/system.slice/dovecot.service
...
Aktivieren Sie ein weiteres Subsystem, taucht auch dieses in der Datei auf:
# cat > /etc/systemd/system/dovecot.service 
BlockIOWeight=200
_EOF
 
# systemctl daemon-reload
# systemctl reload dovecot.service
 
# grep blkio /proc/29985/cgroup
8:blkio:/system.slice/dovecot.service
Fazit
Im Vergleich zur Konfiguration von Cgroups auf älteren Linux-Systemen erleichtert systemd auf aktuellen Linux-Distributionen Administratoren das Leben. Die ausführlichen Hilfeseiten beschreiben sämtliche zur Verfügung stehenden Parameter sehr umfangreich und die Konfiguration erfolgt sehr intuitiv.
(of)

Link-Codes



Systemstart mit Systemd
F2P01
comments powered by Disqus
Mehr zum Thema

Cgroups zur Ressourcenkontrolle in Linux

Mit dem neuen Cgroups-Feature lässt sich bei modernen Linux-Distributionen der Ressourcen-Verbrauch etwa von Prozessen administrativ beschränken. Besonders interessant ist die Anwendung der Technologie bei virtualisierten Systemen.

Artikel der Woche

Systeme mit Vamigru verwalten

Auch wer nur kleine Flotten von Linux-Servern verwaltet, freut sich über Werkzeuge, die ihm diese Arbeit erleichtern. Vamigru tritt mit diesem Versprechen an. Wir verraten, was es leistet und wie Sie es in der eigenen Umgebung in Betrieb nehmen. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Container

Wie setzen Sie Container ein?

  • Gar nicht
  • Docker standalone
  • Docker mit Kubernetes
  • Docker mit Swarm
  • Docker mit anderem Management
  • LXC/LXD
  • Rocket
  • CRI-O auf Kubernetes
  • Container auf vSphere
  • Andere (siehe Kommentare auf der Ergebnisseite)

Google+

Ausgabe /2018

Microsite