Umfassender Leitfaden zu Systemd Cgroups für Ressourceneinschränkung und -isolierung

Umfassender Leitfaden zu Systemd Cgroups für Ressourcenbegrenzung und -isolierung

Systemd, das moderne Init-System sowie System- und Dienstemanager für Linux, bietet leistungsstarke Werkzeuge zur Verwaltung von Systemressourcen. Eine seiner bedeutendsten Fähigkeiten ist die Integration mit Control Groups (cgroups), einer Linux-Kernel-Funktion, die die Begrenzung, Abrechnung und Isolierung der Ressourcennutzung (CPU, Speicher, Festplatten-I/O, Netzwerk usw.) für eine Sammlung von Prozessen ermöglicht. Dieser Leitfaden beleuchtet, wie systemd cgroups über seine Einheitentypen – Slices, Scopes und Services – nutzt, um eine präzise Ressourcenbegrenzung und -isolierung zu ermöglichen und sicherzustellen, dass kritische Prozesse die benötigten Ressourcen erhalten, während gleichzeitig verhindert wird, dass durchgehende Anwendungen die Systemstabilität beeinträchtigen.

Das Verständnis und die Nutzung der cgroup-Integration von systemd sind entscheidend für Systemadministratoren, Entwickler und alle, die für die Aufrechterhaltung der Leistung und Zuverlässigkeit von Linux-Systemen verantwortlich sind. Durch die Festlegung geeigneter Ressourcengrenzen können Sie eine Ressourcenerschöpfung verhindern, die Vorhersagbarkeit der Anwendungsleistung verbessern und die allgemeine Systemstabilität erhöhen. Dieser Leitfaden bietet einen praktischen Ansatz zur Konfiguration dieser Grenzen, wodurch ein komplexes Ressourcenmanagement zugänglich und effektiv wird.

Verständnis von Control Groups (cgroups)

Bevor wir uns mit der Implementierung von systemd befassen, ist es wichtig, die grundlegenden Konzepte von cgroups zu erfassen. Cgroups sind ein hierarchischer Mechanismus im Linux-Kernel, mit dem Sie Prozesse gruppieren und diesen Gruppen dann Richtlinien für die Ressourcenverwaltung zuweisen können. Diese Richtlinien können umfassen:

CPU: Begrenzung der CPU-Zeit, Priorisierung des CPU-Zugriffs.
Speicher: Festlegung von Speichernutzungslimits, Vermeidung von Out-of-Memory (OOM)-Bedingungen.
I/O: Drosselung von Festplatten-Lese-/Schreibvorgängen.
Netzwerk: Begrenzung der Netzwerkkapazität (Bandbreite).
Gerätezugriff: Steuerung des Zugriffs auf bestimmte Geräte.

Der Kernel stellt cgroup-Konfigurationen über ein virtuelles Dateisystem bereit, das typischerweise unter /sys/fs/cgroup eingehängt ist. Jeder Controller (z. B. cpu, memory) verfügt über ein eigenes Verzeichnis, und innerhalb dieser repräsentieren Hierarchien von Verzeichnissen Gruppen und ihre zugehörigen Ressourcengrenzen.

Die Cgroup-Verwaltungsarchitektur von Systemd

Systemd abstrahiert die Komplexität der direkten cgroup-Manipulation, indem es ein strukturiertes Einheitenverwaltungssystem bereitstellt. Es organisiert Prozesse in einer Hierarchie von Einheiten, die dann auf cgroup-Hierarchien abgebildet werden. Die wichtigsten Einheitentypen für das Ressourcenmanagement sind:

Slices: Dies sind abstrakte Container für Service-Einheiten. Slices bilden eine Hierarchie und ermöglichen die Delegation von Ressourcen. Beispielsweise kann ein Slice für Benutzersitzungen Slices für einzelne Anwendungen enthalten. Systemd erstellt automatisch Slices für Systemdienste, Benutzersitzungen und virtuelle Maschinen/Container.
Scopes: Diese werden typischerweise für temporäre oder dynamisch erstellte Prozessgruppen verwendet, die oft mit Benutzersitzungen oder Systemdiensten verbunden sind, die nicht als vollständige Service-Einheiten verwaltet werden. Sie sind transient und existieren, solange die darin enthaltenen Prozesse laufen.
Services: Dies sind die grundlegenden Einheiten zur Verwaltung von Daemons und Anwendungen. Wenn eine Service-Einheit gestartet wird, platziert systemd deren Prozesse in eine cgroup-Hierarchie, normalerweise innerhalb eines Slices. Ressourcengrenzen können direkt auf Service-Einheiten angewendet werden.

Die Standardhierarchie von systemd sieht oft wie folgt aus:

-.slice (Root-Slice)
  |- system.slice
  |  |- <service_name>.service
  |  |- another-service.service
  |  ...
  |- user.slice
  |  |- user-1000.slice
  |  |  |- session-c1.scope
  |  |  |  |- <application>.service (falls vom Benutzer gestartet)
  |  |  |  ...
  |  |  ...
  |  ... 
  |- machine.slice (für VMs/Container)
  ...

Anwenden von Ressourcengrenzen mit Systemd-Unit-Dateien

Systemd ermöglicht es Ihnen, cgroup-Ressourcengrenzen direkt in den Unit-Dateien .service, .slice oder .scope festzulegen. Diese Direktiven werden unter den Abschnitten [Service], [Slice] bzw. [Scope] platziert.

CPU-Begrenzungen

Die wichtigsten Direktiven für die CPU-Ressourcensteuerung sind:

CPUQuota=: Begrenzt die gesamte CPU-Zeit, die die Einheit nutzen kann. Dies wird als Prozentsatz angegeben (z. B. 50% für einen halben CPU-Kern) oder als Bruchteil eines CPU-Kerns (z. B. 0.5). Es ist auch möglich, einen Wert in Mikrosekunden pro Periode anzugeben. Die Standardperiode beträgt 100 ms.
CPUShares=: Legt eine relative Gewichtung für die CPU-Zeit fest. Eine Einheit mit CPUShares=2048 erhält die doppelte CPU-Zeit einer Einheit mit CPUShares=1024, wenn es zu Konflikten kommt.
CPUWeight=: Ein Alias für CPUShares=, jedoch mit einem anderen Bereich (1-10000, Standard 100).
CPUQuotaPeriodSec=: Legt die Periode für CPUQuota fest. Standard ist 100ms.

Beispiel: Begrenzung eines Webservers auf 75 % eines CPU-Kerns:

Erstellen oder bearbeiten Sie eine Service-Datei, zum Beispiel /etc/systemd/system/mywebapp.service:

[Unit]
Description=Meine Webanwendung

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

# Auf 75 % eines CPU-Kerns begrenzen
CPUQuota=75%

[Install]
WantedBy=multi-user.target

Nach dem Erstellen oder Ändern der Service-Datei laden Sie den systemd-Daemon neu und starten den Dienst neu:

sudo systemctl daemon-reload
sudo systemctl restart mywebapp.service

Speichergrenzen

Speichergrenzen werden durch Direktiven wie folgt gesteuert:

MemoryLimit=: Legt eine harte Grenze für die RAM-Menge fest, die die Prozesse der Einheit verbrauchen dürfen. Dies kann in Bytes oder mit Suffixen wie K, M, G, T angegeben werden (z. B. 512M).
MemoryMax=: Ähnlich wie MemoryLimit, gilt aber oft als moderner und flexibler in der Art und Weise, wie es mit der Speicherabrechnung interagiert. Es wird im Allgemeinen gegenüber MemoryLimit empfohlen.
MemoryHigh=: Legt eine weiche Grenze fest. Wenn diese Grenze erreicht wird, wird die Speicherfreigabe (Swapping) aggressiver ausgelöst, aber die harte Grenze wird noch nicht durchgesetzt.
MemorySwapMax=: Begrenzt die Menge an Swap-Speicher, die die Einheit verwenden darf.

Beispiel: Begrenzung einer Datenbank auf 2 GB RAM:

Erstellen oder bearbeiten Sie eine Service-Datei, zum Beispiel /etc/systemd/system/mydb.service:

[Unit]
Description=Mein Datenbankdienst

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

# Speicher auf 2 Gigabyte begrenzen
MemoryMax=2G

[Install]
WantedBy=multi-user.target

Neu laden und neu starten:

sudo systemctl daemon-reload
sudo systemctl restart mydb.service

I/O-Begrenzungen

I/O-Drosselung kann mit Direktiven wie diesen gesteuert werden:

IOWeight=: Legt ein relatives Gewicht für I/O-Operationen fest. Höhere Werte geben eine höhere I/O-Priorität. Der Bereich liegt zwischen 1 und 1000 (Standard 500).
IOReadBandwidthMax=: Begrenzt die Lese-I/O-Bandbreite. Wird angegeben als [<Gerät>] <Bytes_pro_Sekunde>. Zum Beispiel begrenzt IOReadBandwidthMax=/dev/sda 100M Lesezugriffe auf /dev/sda auf 100 MB/s.
IOWriteBandwidthMax=: Begrenzt die Schreib-I/O-Bandbreite. Ähnliches Format wie IOReadBandwidthMax.

Beispiel: Begrenzung eines Hintergrundverarbeitungsdienstes auf 50 MB/s auf einer bestimmten Festplatte:

Erstellen oder bearbeiten Sie eine Service-Datei, z. B. /etc/systemd/system/batchproc.service:

[Unit]
Description=Batch-Verarbeitungsdienst

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

# Schreibvorgänge auf /dev/sdb auf 50 MB/s begrenzen
IOWriteBandwidthMax=/dev/sdb 50M

# Geben Sie ihm eine moderate Lesepriorität
IOWeight=200

[Install]
WantedBy=multi-user.target

Neu laden und neu starten:

sudo systemctl daemon-reload
sudo systemctl restart batchproc.service

Verwaltung und Überwachung von Cgroups

Systemd bietet Werkzeuge zur Inspektion und Verwaltung der cgroups, die mit Ihren Einheiten verbunden sind.

Überprüfung des Cgroup-Status

Der Befehl systemctl status liefert Informationen über die cgroup-Zugehörigkeit und Ressourcennutzung einer Einheit.

systemctl status mywebapp.service

Suchen Sie nach Zeilen, die den cgroup-Pfad angeben. Zum Beispiel:

● mywebapp.service - Meine Webanwendung
     Loaded: loaded (/etc/systemd/system/mywebapp.service; enabled; vendor preset: enabled)
     Active: active (running) since Di 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

Sie können auch das cgroup-Dateisystem direkt inspizieren:

systemd-cgls # Zeigt die von systemd verwaltete cgroup-Hierarchie an
systemd-cgtop # Ähnlich wie top, aber für cgroups

Um die spezifischen Grenzen anzuzeigen, die auf die cgroup eines Dienstes angewendet werden:

# Für Speicherbegrenzungen
catsysfs /sys/fs/cgroup/memory/system.slice/mywebapp.service/memory.max

# Für CPU-Begrenzungen
catsysfs /sys/fs/cgroup/cpu/system.slice/mywebapp.service/cpu.max

(Hinweis: Die genauen Pfade und Dateinamen können je nach cgroup-Version und Systemkonfiguration leicht variieren.)

Ändern von Cgroup-Grenzen im laufenden Betrieb

Obwohl es bewährte Methode ist, Grenzen in Unit-Dateien festzulegen, können Sie diese vorübergehend mit systemctl set-property anpassen:

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

Diese Änderungen sind nach einem Neustart nicht persistent. Um sie dauerhaft zu machen, aktualisieren Sie die Unit-Datei und laden Sie den systemd-Daemon neu.

Slices für die Ressourcen-Delegation

Slices sind leistungsstark für die Verwaltung von Gruppen von Diensten oder Anwendungen. Sie können Ressourcengrenzen für einen Slice definieren, und alle Dienste oder Scopes innerhalb dieses Slices erben diese Grenzen oder unterliegen ihnen.

Beispiel: Erstellen eines dedizierten Slices für ressourcenintensive Batch-Jobs:

Erstellen Sie eine Slice-Datei, z. B. /etc/systemd/system/batch.slice:

[Unit]
Description=Batch-Verarbeitungs-Slice

[Slice]
# Die gesamte CPU für alle Jobs in diesem Slice auf 1 Kern begrenzen
CPUQuota=100%
# Den gesamten Speicher auf 4 GB begrenzen
MemoryMax=4G

Nun können Sie Dienste so konfigurieren, dass sie innerhalb dieses Slices ausgeführt werden, indem Sie die Direktive Slice= in ihren .service-Dateien verwenden:

[Unit]
Description=Spezifischer Batch-Job

[Service]
ExecStart=/usr/bin/mybatchjob

# Diesen Dienst in den batch.slice verschieben
Slice=batch.slice

[Install]
WantedBy=multi-user.target

Systemd neu laden, den Slice bei Bedarf aktivieren/starten (obwohl er oft implizit aktiviert wird) und den Dienst starten.

sudo systemctl daemon-reload
sudo systemctl start mybatchjob.service

Dieser Ansatz ermöglicht es Ihnen, verwandte Prozesse zu gruppieren und deren kollektiven Ressourcenverbrauch zu verwalten.

Bewährte Verfahren und Überlegungen

Beginnen Sie mit inkrementellen Grenzen: Wenn Sie Grenzen festlegen, beginnen Sie mit konservativen Werten und erhöhen Sie diese schrittweise nach Bedarf. Aggressive Grenzen können Anwendungen destabilisieren.
Überwachen: Überwachen Sie regelmäßig die Ressourcennutzung Ihres Systems und die Auswirkungen Ihrer cgroup-Einstellungen. Tools wie systemd-cgtop, htop, top und iotop sind von unschätzbarem Wert.
Verständnis von Cgroup v1 vs. v2: Systemd unterstützt sowohl cgroup v1 als auch v2. Obwohl viele Direktiven ähnlich sind, bietet v2 eine einheitliche Hierarchie und einige Verhaltensunterschiede. Stellen Sie sicher, dass Sie wissen, welche Version Ihr System verwendet, wenn Sie auf komplexe Probleme stoßen.
Priorisierung vs. harte Grenzen: Verwenden Sie CPUShares/CPUWeight zur Priorisierung, wenn Ressourcen knapp sind, und CPUQuota für strenge harte Grenzen. Ebenso sind MemoryHigh für weiche Grenzen und MemoryMax für harte Grenzen.
Service vs. Slice: Verwenden Sie Service-Einheiten für einzelne Anwendungen und Slices für die Verwaltung von Gruppen verwandter Anwendungen oder Ressourcenpools.
Dokumentation: Dokumentieren Sie klar die Ressourcengrenzen, die für kritische Dienste gelten, insbesondere in Produktionsumgebungen.
OOM Killer: Beachten Sie, dass der Out-Of-Memory (OOM) Killer des Kernels einen Prozess beenden kann, auch wenn er sich innerhalb einer cgroup befindet, wenn er sein MemoryMax-Limit überschreitet. Systemd kann steuern, wie sich der OOM Killer für bestimmte cgroups mithilfe von Direktiven wie OOMPolicy= verhält.

Fazit

Die Integration von systemd mit cgroups bietet einen robusten und benutzerfreundlichen Mechanismus zur Steuerung und Isolierung von Systemressourcen. Durch die Beherrschung der Verwendung von Service-, Scope- und Slice-Einheiten können Administratoren effektiv CPU-, Speicher- und I/O-Limits anwenden, um die Systemstabilität, vorhersagbare Leistung zu gewährleisten und eine Ressourcenverknappung zu verhindern. Die Implementierung dieser Kontrollen ist ein grundlegender Aspekt der modernen Linux-Systemadministration und ermöglicht eine größere Kontrolle über Ihre Anwendungsumgebungen und die zugrunde liegende Infrastruktur.