Duell der Datenbanken: In einem Shootout messen sich MySQL und PostgreSQL. Der Schwerpunkt vom ADMIN 06/2011 überprüft, wer schneller ist und gibt einen ... (mehr)

Hierarchien

Bisher betrachtet der Artikel nur einzelne isolierte Control-Groups. Zur besseren Strukturierung lassen sich aus Gruppen aber auch Hierarchien bilden. So kann der Administrator innerhalb einer Control-Group weitere Control-Groups anlegen, etwa mit »cgreate -g blkio:/dd/user1« . Diese erscheinen dann als Unterverzeichnisse und erben die Eigenschaften der übergeordneten Control-Group. Sämtliche Kind-Cgroups konkurrieren dann um die der übergeordneten Cgroup zugeteilten Ressourcen. Darf diese nur 1 MByte/s schreiben, dürfen sämtliche Kind-Cgroups zusammen dieses Maximum nicht überschreiten. Die Ressourcen werden hierarchisch zugewiesen. Leider funktionieren diese Hierarchien für den Blkio-Controller noch nicht. Die anderen Controller wie CPU, Memory und so weiter unterstützen aber bereits Hierarchien.

Wo können die Cgroups nun sinnvoll eingesetzt werden? Sicher gibt es spezielle Anwendungen, die im Alltag davon profitieren können. Jedoch ist es in vielen Fällen sinnvoller, dass der Linux-Kernel die Ressourcen selbstständig zuweist und hierbei keine Schranken setzt. Setzt man jedoch eine Virtualisierungslösung wie KVM ein und virtualisiert mehrere Gäste auf einem Host, gibt es durchaus Bedarf, die Ressourcennutzung der einzelnen Gäste untereinander zu beschränken, priorisieren und zu messen. Hierfür lassen sich die Cgroups ideal einsetzen.

Virtualisiert

Allerdings muss man beim Einsatz von Cgroups die Virtualisierung über die Libvirt-Bibliotheken steuern und LXC-Container oder Qemu/KVM verwenden. Der Libvirtd-Daemon erzeugt dann beim Start für jeden Gast eine eigene Cgroup mit dem Namen des Gastes. Diese befindet sich in der Hierarchie »libvirtd/qemu|lxc/ Gast « unter jedem Controller. Hier kann der Admin nun für jeden Gast einzeln die Ressourcen verwalten und priorisieren. Damit ein Gast doppelt so viel CPU-Zeit wie ein zweiter Gast erhalten kann, muss man im CPU-Controller die »cpu.shares« ändern. Das angestrebte Ziel lässt sich erreichen, indem man den Default-Wert von 1024 auf 2048 ändert.

Genauso kann der Administrator auch den Verbrauch des Arbeitsspeichers oder die Bandbreitennutzung im Netzwerk konfigurieren. Hierzu nutzt er den Memory-Controller oder den Net_Cls-Controller in Kombination mit dem »tc« -Befehl. Allerdings unterstützen erst die aktuellsten Libvirt-Varianten den Net_Cls-Controller. Er unterscheidet sich von den anderen Controllern, da er lediglich eine Class-ID setzt und man dann mit dem Kommando »tc« die Bandbreite kontrolliert (siehe Kasten "Bandbreitenkontrolle" ). Der Blkio-Controller lässt sich noch nicht mit Libvirt nutzen, da er noch nicht die Hierarchien unterstützt, die der Libvirtd erzeugen möchte. Daran arbeiten die Kernel-Entwickler aber schon [2] . Will der Admin für die verbrauchte Zeit der einzelnen virtuellen Gäste Abrechnungen erstellen, so kann er das mit dem CPUAcct-Controller erreichen. Dieser zählt für jeden Gast in »/cgroup/cpuacct/libvirt/qemu/ Gast /cpuacct.usage« die tatsächlich verbrauchte CPU-Zeit in Nano-Sekunden.

Bandbreitenkontrolle

Wird ein Prozess vom Net_cls-Controller überwacht, kann der Admin für sämtliche Prozesse der Cgroup eine Class-ID vergeben. Diese kann dann mit dem »tc« Kommando genutzt werden. Hierzu setzt der Admin zunächst für die Cgroup die Class-ID:

echo 0x00100001 > /cgroup/net_cls/libvirt/qemu/Gast/net_cls.classid

Diese hexadezimale Zahl besteht aus zwei Teilen: 0xAAAABBBB. Hierbei definieren die Ziffern AAAA die Major-Nummer der Class-ID, während die Ziffern BBBB die Minor-Nummer angeben. Führende Nullen müssen nicht angegeben werden. Der obige Ausdruck hätte also auch 0x100001 lauten können.

Um nun die Class-ID zu nutzen, muss der Admin eine Classbased-Queueing-Discipline (QDisc) auf der ausgehenden Netzwerkkarte (etwas »eth0« ) installieren. Die QDisc entscheidet, wann ein Paket zu versenden ist. Eine klassenbasierte QDisc erlaubt die Einsortierung der Pakete in unterschiedliche Klassen sowie die Priorisierung und Beschränkung dieser Klassen. Eine klassische QDisc für die Beschränkung des Netzwerkverkehrs ist der Hierarchical Token Bucket Filter (HTB). Der Admin muss zunächst diesen auf der Netzwerkkarte installieren. Hierzu löscht er eine möglicherweise vorhandene QDisc und lädt dann den HTB:

tc qdisc del dev eth0 root 2>/dev/null
tc qdisc add dev etho root handle 10: htbU

Nun muss der Admin die Klassen erzeugen.

tc class add dev eth0 parent 10: classid 10:1 htb rate 10mbit
tc class add dev eth0 parent 10: classid 10:2 htb rate 20mbit ceil 100mbit

Diese zwei Zeilen erzeugen zwei verschiedene Klassen. Die erste Klasse verfügt über eine maximale Bandbreite von 10 Megabit/s. Die zwei Klasse verfügt über 20 Megabit/s, darf jedoch bis zu einer maximalen Bandbreite von 100 Mbit/s beanspruchen, wenn keine andere Klasse Ansprüche erhebt. Die Option »default 2« bei der Erzeugung des HTB weist unklassifizierten Verkehr der zweiten Klasse zu.

Um die Class-ID der Cgroup Net_Cls nun auszuwerten, muss der Admin noch einen Filter definieren:

tc filter add dev eth0 parent 10: \
                protocol ip prio 10 \
                handle 1: cgroup

Nun wird die Net_Cls-Class-ID automatisch von dem Kernel für die Einsortierung der Pakete in den HTB-Klassen genutzt. Der Libvirt-Gast erhält nun eine maximale Sendeleistung von 10 Mbit/s.

Jeder Thread eines Prozesses kann in einer eigenen Cgroup kontrolliert werden. Daran muss der Administrator denken, wenn er, wie zu Beginn gezeigt, die Prozesse nach ihrem Start mit dem echo-Kommando einer Cgroup zuweisen möchte. Auch sämtliche gestarteten Threads ( »/proc/pid/task/« ) muss er entsprechenden Cgroups zuweisen. Einfacher ist da das Kommando »cgexec« . Dieser Befehl startet den Prozess bereits in der Cgroup. Alle Kindprozesse und -threads erben dann diese Gruppe.

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023