Ressourcen-Verwaltung mit Control Groups (cgroups)
Die sogenannten cgroups (Control Groups) dienen der Gruppierung von Prozessen. Dies ermöglicht dem Betriebssystem, einer Gruppe von definierten Prozessen ausgewählte Ressourcen zuzuweisen. Dabei werden auch Hierarchien unterstützt. Dieser Artikel zeigt an praktischen Beispielen, wie man cgroups nutzbringend verwendet.
Herausforderung Ressourcen-Verwaltung
Aktuelle Plattformen besitzen gewaltige Hardware-Ressourcen. Heutzutage sind symmetrische Multiprozessor-Systeme (SMP) in den meisten Bereichen gängiger als Uniprozessor-Systeme. Moderne CPUs haben mehrere Kerne, und einige SMP-Systeme sind wiederum mit mehreren solcher CPUs bestückt. Many Core-Systeme stellen Betriebssystem- und Softwareentwickler sowie Systemadministratoren vor neue Herausforderungen. Es müssen Lösungen gefunden werden, wie man Herr der vielen zusätzlichen Ressourcen wird und diese effizient einsetzt. Mit einer Vervielfachung der CPUs werden Systeme (leider) nicht automatisch um das entsprechende Vielfache schneller - im Gegenteil. Bei der Softwareentwicklung muss Multithread-Skalierbarkeit berücksichtigt werden, und die steigende Anzahl und Last der Prozessoren fordert die Ressourcenverwaltung moderner Betriebssysteme heraus.
Der verstärkte Einsatz virtueller Maschinen, um z.B. einzelne Dienste voneinander zu isolieren, ist gängige Praxis geworden. Dies erlaubt auch eine Art Ressourcen-Verwaltung, indem den virtuellen Maschinen (unter Umständen auch dynamisch, also im laufenden Betrieb) Hardware-Ressourcen wie Prozessoren oder Arbeitsspeicher zugewiesen werden können. Mit KVM wird der Linux-Kernel zum Hypervisor. Diese virtuellen Maschinen tauchen als reguläre Prozesse im System auf, jede virtuelle CPU eines Gastsystems als separater Thread, und werden wie normale Anwendungsprogramme über den Scheduler verwaltet. Aber nicht nur VM-Hosts, sondern auch gewöhnliche Systeme müssen ihre beschränkten Ressourcen an eine große Anzahl von Prozesse verteilen.
Wie Ressourcen effizient aufteilen?
Aber wie sollen diese Ressourcen aufgeteilt werden? Jeden System-Prozess an die erste CPU binden und Prozesse von kritischen Diensten an die zweite CPU? Und wie geht man mit den ständig wechselnden PIDs um? Wie behält man den Überblick, welche Prozesse zusammenarbeiten oder mit fork() ihre Herkunft »verwischen«? Wie verhindert man, dass kritische Dienste unter Speicherknappheit/Page-Faults leiden müssen? Wie macht man all dies mit mehreren tausend Prozessen?
Wie weist man individuell zugeschnittene Ressourcen zu, abhängig davon, zu welcher Dienst-Gruppe oder Abteilung eines Unternehmens eine Anwendung gehört? Und kann zugleich von aktuellen Hardware-Entwicklungen profitiert werden, die »many core«-Systeme effizienter machen sollen? Ist GNU/Linux überhaupt dazu in der Lage, Ressourcen-Verwaltung von großen Plattformen mit vielen Hardware-Ressourcen zu betreiben?
Lösung: Gruppierung von Prozessen?!
Eine Möglichkeit ist die Gruppierung aller Prozesse anhand ihrer Zugehörigkeit zu Diensten oder Besitzern und die Zuteilung bestimmter Ressourcen zu diesen Gruppen. Ein Anwendungs-Beispiel ist ein Unternehmens-Server, der von verschiedenen Abteilungen genutzt wird und unterschiedliche Dienste betreibt.
Ein weiteres gutes Beispiel ist das System einer Universität mit vielen CPUs und einer großen Menge Arbeitsspeicher, das von mehreren Benutzergruppen - Professoren, Assistenten, Studenten - genutzt wird, die verschiedene Prozesse zur selben Zeit betreiben:
){kind=small}
Daniel Gollub und Stefan Seyfried
Abbildung 1: Beispiel: (Prozess) Gruppierung eines Universitäts-Systems
Abbildung 1 zeigt die Gruppen Professoren, Studenten und Assistenten. Jede dieser Gruppen bekommt deren zugehörige Prozesse zugewiesen. Alle anderen Prozesse bleiben in der Haupt-Gruppe (Root Group), z.B. System-Prozesse wie Standard Cron-Jobs oder Distributor-System-Dienste.
Hierbei muss beachtet werden, dass jeder Prozess nur in einer Gruppe existieren darf. Zudem muss dafür gesorgt werden dass Kindprozesse, Threads und Forks in derselben Gruppe erstellt werden wie der Ursprungs-Prozess.
Der beste Ort, um diese Funktionalität zu implementieren, ist der Linux-Kernel selbst, da dieser volle Kontrolle über die Prozess-Erstellung besitzt. Dies vereinfacht auch die Aufgabe, Prozesse zu gruppieren, da keine Userspace-Applikation nötig ist, die die Prozesse »einsammelt« und entsprechenden Gruppen zuweist, sobald sie erstellt werden. Eine Kernel-Implementierung kann auch verhindern, dass neu erstellte Prozesse aus einer Gruppe »durchsickern« und in der falschen Gruppe landen.
Control Groups
Die so genannten cgroups (Control Groups) dienen der Gruppierung von Prozessen. Dies ermöglicht dem Betriebssystem, einer Gruppe von definierten Prozessen ausgewählte Ressourcen zuzuweisen. Hierarchien werden ebenfalls unterstützt und besitzen über alle Ebenen hinweg dieselben Regeln:
- jeder Prozess kann zur selben Zeit nur in einer Gruppe existieren
- neu erstellte Untergruppen sind leer
- eine Gruppen kann nur aufgelöst werden, wenn ihr keine Prozesse zugeordnet sind
- eine Gruppen kann nur aufgelöst werden, wenn keine weitere Untergruppe besteht
Egal ob es sich um einen Userspace-Prozess, dessen Threads oder einen Kernel-Thread handelt - sämtliche Prozesse werden in Control Groups verwaltet, sofern der genutzte Linux-Kernel Control Groups aktiviert hat.
In der Tat findet sich die Control Groups-Funktionalität in allen gängigen GNU/Linux Distributionen und sie wird auch von den sogenannten Unternehmens-GNU/Linux-Distributoren entsprechend beworben. Ob Control Groups auf einem System verfügbar sind, lässt sich anhand des /proc-Dateisystem-Eintrags /proc/cgroups feststellen. Diese Datei beinhaltet eine Liste aller lokal verfügbaren Control Group- Subsysteme.
