Wir studieren weiterhin Gruppen. In Red Hat Enterprise Linux 7 sind sie standardmäßig aktiviert, da systemd verwendet wird und er wiederum bereits integrierte cgroups hat. Mit Red Hat ist Red Hat Enterprise Linux 6 etwas anders. Tatsächlich waren die cgroups-Controller ursprünglich dort, aber diese Version wurde veröffentlicht, erinnern Sie sich an Januar 2010, dh vor ein paar Jahrhunderten in Bezug auf Computerjahre.
Cgroups in Red Hat Enterprise Linux 6 können jedoch auch heute noch viel, was wir heute veranschaulichen werden.
Lassen Sie uns die Funktionen von cgroups in Red Hat Enterprise Linux 6 anhand eines rein hypothetischen Beispiels analysieren, das ausschließlich auf realen Ereignissen basiert. Aber für den Anfang traditionell ein kleiner Exkurs.
Es gab noch nie so viele Probleme mit der IT-Sicherheit wie jetzt. Kein Wunder, denn heute sind nicht nur alle Computer und Telefone an das Netzwerk angeschlossen, sondern auch Kühlschränke, Staubsauger und vieles mehr - der Spielraum für Netzwerkbedrohungen ist einfach immens. Und der Kampf gegen diese Bedrohungen beginnt in der Regel sofort an allen Fronten. Schnelle Installation von Sicherheitspatches? Ja, unbedingt! Stärkung der Systemsicherheit - Firewalls, SELinux, intelligente Authentifizierung, ist das alles? Natürlich! Antivirenscanner auf Linux-Computern? Nun, wie soll ich sagen ...
Auf Linux-Computern schaden Antivirenscanner manchmal mehr als sie nützen. Sicherheitspersonal hat jedoch seine eigenen Gründe und verlangt häufig, dass Sie regelmäßig Antivirenscans durchführen, ohne wirklich über ihre Solidität aus technischer Sicht nachzudenken. Und das ist eine Realität, mit der man sich abfinden muss und mit der früher oder später fast jeder IT-Spezialist konfrontiert ist.
Der zweite Punkt ist, dass Red Hat Enterprise Linux 7 natürlich modisch, fortschrittlich und cool ist, aber viele verwenden immer noch Red Hat Enterprise Linux 6 und denken nicht daran, es abzulehnen. Aus diesem Grund entscheiden sich die Leute für Red Hat - Sie können jahrelang auf derselben Version sitzen und haben immer noch die neuesten Patches, Updates und Support.
Kehren wir zu unserem Beispiel zurück ... Stellen Sie sich vor, es gibt einen Typen namens Jerry. Jerry arbeitet in einem großen Büro und ist für den Red Hat Enterprise Linux 6-Server verantwortlich. Er ist vollkommen zufrieden mit der Funktionsweise und benötigt keine neuen Probleme und Probleme.
Aber dann entscheiden die Leute von der Sicherheitsabteilung, dass Sie auf all seinen Servern eine Sache namens ScanIT platzieren müssen. Und da dieses Ding Festplatten und Speicher regelmäßig auf Viren und andere Malware überprüft, benötigt es vollen Root-Zugriff.
Jerry seufzt, stellt seine Gitarre ab und setzt ScanIT auf eine Testmaschine. Ziemlich schnell stellt sich Folgendes heraus:
- Wenn Sie einen Antivirenscan durchführen, verbraucht scanit (dies ist ein Skript zum Starten des Prozesses) die gesamte Prozessorzeit, die es erreichen kann. Und das wirkt sich sehr stark auf die Arbeit der Testmaschine aus - sobald Jerry sie auf ssh nicht einmal erreichen konnte.
- Darüber hinaus verbraucht der Scanit-Prozess von Zeit zu Zeit Speicherplatz wie in sich selbst. Infolgedessen wacht OOM Killer auf und beginnt, alle anderen Prozesse als Scanit selbst zu beenden.
Im Allgemeinen muss damit etwas getan werden.
Jerry nimmt die Gitarre und beginnt, nachzudenken, während er die Grateful Dead spielt. Ziemlich schnell kam ihm der Gedanke, dass wahrscheinlich die gleichen Gruppen von Red Hat Enterprise Linux 7 hier helfen könnten, worüber ein Freund namens Alex durch seine Ohren summte. Jerry setzt seine Gitarre wieder ab und macht sich daran, die
Docks zu lesen, die Alex
unter Red Hat Enterprise Linux 6 gesendet hat. Es stellt sich heraus, dass das erste, was er braucht, libcgroup ist.
Auf dem Testcomputer befindet sich keine libcgroup, daher beginnt Jerry mit der Installation:
Darüber hinaus umfasst Jerry zwei Dienste, die für die Arbeit permanenter (persistenter) Gruppen erforderlich sind:
- cgconfig - bietet eine mehr oder weniger einfache Oberfläche für die Arbeit mit Gruppengruppenbäumen. Jerry könnte cgroups sicherlich manuell mounten und konfigurieren, aber warum, wenn Sie Zeit sparen können?
- cgred - Dieses Ding ist eine cgroup-Regelengine: Wenn ein Prozess gestartet wird, ordnet dieser Dienst ihn gemäß den angegebenen Regeln der einen oder anderen cgroup zu.
Nachdem Jerry dies alles installiert und konfiguriert hat, kann er endlich direkt mit dem Problem selbst fortfahren. Nach sorgfältiger Überlegung trifft er folgende Entscheidung:
- scanit und seine untergeordneten Prozesse sollten nicht mehr als 20% der CPU-Ressourcen verbrauchen. Noch weniger - nicht mehr als 20% der Ressourcen eines Prozessorkerns, selbst auf einem Multi-Core-Computer. In cgroups erfolgt dies unter Verwendung von CPU-Kontingenten.
- In Bezug auf den Speicher sollten scanit und seine untergeordneten Prozesse nicht mehr als 512 MB Systemspeicher belegen. Wenn sie diese Grenze überschreiten, sollte das System sie töten und keine anderen Prozesse.
Sie müssen mir nicht sagen, was ich tun soll!
Jerry muss sich mit zwei Konfigurationsdateien befassen:
- /etc/cgconfig.conf - Wird bei der Installation von libcgroup automatisch generiert.
- /etc/cgrules.conf - enthält eine Reihe von Regelsatzregeln, nach denen cgred laufende Prozesse nach Gruppen gruppiert.
So sieht die Standarddatei cgconfig.conf aus:
Jerry hätte die notwendigen Änderungen direkt an ihm vornehmen können, aber es ist besser, dafür Drop-In-Conf-Dateien zu verwenden. Wie funktioniert es Wenn Sie eine Datei mit der Erweiterung .conf in den Ordner /etc/cgconfig.d einfügen (dt. Drop-in - drop), verarbeitet das System diese und nimmt die entsprechenden Änderungen an der Konfiguration vor. Dies ist praktisch, da Sie Drop-Ins für verschiedene Aufgaben erstellen und diese mit den Tools hinzufügen oder aus der Konfiguration entfernen können, die Ihnen am besten gefallen (z. B. Ansible, nun, es ist immer noch ein Red Hat-Blog).
Jerry erstellt zuerst eine Drop-In-Datei für die CPU:
Wir schauen uns an, was wir hier haben und wie es funktioniert.
Das Schlüsselwort group legt einfach den Namen der neuen cgroup fest, in unserem Fall scanit. In den geschweiften Klammern geben wir die cgroup-Steuerelemente an, die wir verwenden möchten. Mit cpu.cfs_period_us und cpu.cfs_quota_us können Sie die entsprechenden Grenzwerte im Completely Fair Scheduler festlegen, dem Kernel-Scheduler, der standardmäßig in Red Hat Enterprise Linux 6 verwendet wird. Sehen wir uns an, was im
Red Hat Enterprise Linux Resource Management-Handbuch darüber geschrieben wird 6 :
Mit anderen Worten, Jerry schrieb dies in seinem Drop-In: „Überprüfen Sie für jeden Prozess im Zusammenhang mit der cgroup namens scanit einmal pro Sekunde die Menge der ihm zugewiesenen CPU-Ressourcen. Wenn die Gesamtprozessorzeit für alle Prozesse in dieser Gruppe mehr als 200.000 Millisekunden beträgt, geben Sie diesen Prozessen keine Prozessorzeit mehr. " Das heißt, allen Prozessen in der scanit cgroup-Gruppe sowie ihren untergeordneten Prozessen insgesamt nicht mehr als 20% der Prozessorzeit zuzuweisen.
Nach dem Neustart von cgconfig aktualisiert der Server die Konfiguration. Wenn Sie in das Dateisystem gelangen, sehen Sie, dass sich scanit jetzt im CPU-Controller-Verzeichnis befindet:
Das ist natürlich gut, aber wir müssen Scanit noch irgendwie in diese Gruppe drängen. Crged ist hier praktisch, standardmäßig sieht es ungefähr so aus:
Die Verwendung dieser Datei ist mehr oder weniger einfach. Dazu müssen wir jedoch die Datei cgrules.conf direkt bearbeiten, da der Drop-In-Mechanismus hier nicht unterstützt wird. Wir geben den Benutzer oder die Gruppe an, der der Prozess gehört, sowie den Namen des spezifischen Prozesses - wenn Sie möchten - sowie einen benutzerdefinierten Controller und eine cgroup-Zielgruppe.
In unserem Beispiel verwenden wir anstelle des echten Antivirenscanners scanit ein Skript, das auch scanit genannt wird, aber tatsächlich nur die Last emuliert. Ohne cgroup sieht alles so aus:
Die CPU ist voll belegt, hauptsächlich durch Benutzerplatz und ein bisschen System.
Jerry kratzt sich am Bart. Es startet vi und nimmt mit genau einem Zeigefinger einige Änderungen vor und startet den cgred-Daemon neu:
Dann wird scanit manuell gestartet ...:
Und - Prost! Sieg
Wie Sie sehen können, verbrauchen unsere lastemulierenden Prozesse (untergeordnete Prozesse von Scanits) jetzt insgesamt 20% der CPU-Ressourcen, hauptsächlich im Benutzerbereich und ein wenig im System. Dieses verdammte Antivirenprogramm wird das Auto also nicht mehr bis zum Wahnsinn beladen.
Erinnerst du dich, was als nächstes kommt?
Jerry freute sich über den Erfolg und vergaß fast sein Gedächtnis. Aber dann erinnert er sich immer noch und startet vi erneut, um seine Konfigurationsdatei zu reparieren.
Jetzt fügt er dort zwei Einstellungen zum Speicher hinzu:
- Memory.limit_in_bytes - max. Die Größe des Arbeitsspeichers, den alle Prozesse in der Scanit-Gruppe verwenden können. Und ohne Swap Space. Jerry begrenzt es auf 256 MB
- Memory.memsw.limit_in_bytes - max. RAM-Volume plus Speicherplatz in der Auslagerungsdatei, der insgesamt allen Prozessen in der scanit cgroup-group zugewiesen werden kann. Wenn dieser Schwellenwert überschritten wird, werden die Prozesse vom OOM-Killer beendet. Jerry setzt es auf 512 MB.
Oh nein! Was ist los
Jerry schaut nach oben und sieht, dass untergeordnete Scanit-Prozesse noch ausgeführt werden. Da diese cgroup derzeit verwendet wird, kann Jerry den Dienst nicht starten. Daher werden untergeordnete Prozesse manuell beendet und solche Dienste neu gestartet.
Jetzt ein wenig in cgred.conf bearbeiten:
Um dies zu überprüfen, führt Jerry mehrere Scanit-Aufgaben gleichzeitig aus, damit der OOM-Killer sicher funktioniert.
Dann schaut Jerry auf das Systemprotokoll und nickt zufrieden - scanit kann den Speicher nicht mehr ungestraft in beliebigen Mengen verlassen.
Wir hoffen, dass unsere cgroups-Artikelserie Ihnen geholfen hat, zu verstehen, was es ist, wie es in Red Hat Enterprise Linux 7 verwendet wird, wie es in Red Hat Enterprise Linux 6 erstellt wird und wie es in Ihrer Umgebung verwendet wird.