Computer sind Hardware. Und heute sind wir zum Ausgangspunkt zurückgekehrt, in dem Sinne, dass Sie jetzt selten einen physischen Host finden, auf dem eine einzelne Aufgabe ausgeführt wird. Selbst wenn nur eine Anwendung auf dem Server ausgeführt wird, besteht sie höchstwahrscheinlich aus mehreren Prozessen, Containern oder sogar virtuellen Maschinen (VMs), die alle auf demselben Server arbeiten. Red Hat Enterprise Linux 7 kommt in solchen Situationen gut mit der Verteilung von Systemressourcen zurecht, verhält sich jedoch standardmäßig wie eine freundliche Großmutter, die ihre Enkelkinder mit hausgemachtem Kuchen behandelt und sagt: "Gleich für alle, gleich für alle."
Theoretisch ist das Prinzip "gleichmäßig aufgeteilt" natürlich schön, aber in der Praxis sind einige Prozesse, Container oder VMs wichtiger als andere und sollten daher mehr erhalten.
Linux verfügt seit langem über Ressourcenverwaltungstools (nett, ulimit usw.), aber mit dem Aufkommen von Red Hat Enterprise Linux 7 und systemd haben wir endlich einen leistungsstarken Satz solcher Tools in das Betriebssystem selbst integriert. Tatsache ist, dass die Schlüsselkomponente von systemd eine vorgefertigte, angepasste Gruppe von Gruppen ist, die auf Betriebssystemebene vollständig genutzt wird.
Nun, welche Art von Gruppen sind das und wohin geht das Ressourcen- oder Leistungsmanagement?
Steuerung der Kernel-Ebene
Ab der im Januar 2008 veröffentlichten Version 2.6.24 erschien der Linux-Kernel, der ursprünglich in Google unter dem Namen "Prozesscontainer" erfunden und erstellt wurde. Unter Linux wurde er als "Kontrollgruppen", abgekürzt "cgroups", bekannt. Kurz gesagt, cgroups ist ein Kernel-Mechanismus, mit dem Sie die Verwendung einschränken, Aufzeichnungen führen und den Verbrauch von Systemressourcen (CPU, Speicher, Festplatten-E / A, Netzwerk usw.) auf der Ebene der Prozesssammlungen isolieren können. Cgroups können auch Prozesse zum Überprüfen und Neustarten einfrieren. Cgroups-Controller wurden zuerst in Version 6 von Red Hat Enterprise Linux angezeigt, mussten dort jedoch manuell konfiguriert werden. Mit dem Aufkommen von Red Hat Enterprise Linux 7 und systemd wird der vorkonfigurierte Satz von cgroups mit dem Betriebssystem gebündelt.
All dies funktioniert auf Kernel-Ebene des Betriebssystems und garantiert daher eine strikte Kontrolle über jeden Prozess. Daher ist es für Malware äußerst schwierig, das System so zu laden, dass es nicht mehr reagiert und einfriert. Obwohl fehlerhafter Code mit direktem Zugriff auf Hardware (z. B. Treiber) dies natürlich immer noch kann. Gleichzeitig bietet Red Hat Enterprise Linux 7 eine Schnittstelle für die Interaktion mit cgroups, und die gesamte Arbeit mit ihnen erfolgt hauptsächlich über den Befehl systemd.
Dein Stück Kuchen
Das folgende Diagramm, das an einen geschnittenen Kuchen erinnert, zeigt drei Gruppen, die sich standardmäßig auf dem Red Hat Enterprise Linux 7-Server befinden - System, Benutzer und Maschine. Jede dieser Gruppen wird als "Slice" (Slice-Sektor) bezeichnet. Wie Sie in der Abbildung sehen können, kann jedes Slice untergeordnete Slicing-Sektoren haben. Und wie beim Kuchen ergeben alle Scheiben insgesamt 100% der entsprechenden Ressource.
Betrachten wir nun einige cgroups-Konzepte am Beispiel von Prozessorressourcen.
Die obige Abbildung zeigt, dass die Prozessorzeit gleichmäßig auf die drei Slices der oberen Ebene (System, Benutzer und Maschine) aufgeteilt ist. Dies geschieht aber nur unter Last. Wenn ein Prozess aus dem Benutzer-Slice 100% der Prozessorressourcen anfordert und derzeit niemand diese Ressourcen benötigt, erhält er alle 100% der Prozessorzeit.
Jedes der drei Slices der obersten Ebene ist für die Art der Arbeitslast ausgelegt, mit der die untergeordneten Sektoren innerhalb des übergeordneten Slice aufgeteilt werden:
- System - Dämonen und Dienste.
- Benutzer - Benutzersitzungen. Jeder Benutzer erhält ein untergeordnetes Slice, und alle Sitzungen mit derselben UID "leben" in demselben Slice, sodass besonders listige Weisheiten nicht mehr Ressourcen erhalten können, als sie sollten.
- Maschine - virtuelle Maschinen wie KVM-Gäste.
Darüber hinaus wird das Konzept des sogenannten „Balls“ (Share) verwendet, um den Ressourceneinsatz zu steuern. Ein Ball ist ein relativer numerischer Parameter; Sein Wert ist nur im Vergleich zu den Werten anderer Bälle in derselben Gruppe sinnvoll. Standardmäßig haben alle Slices einen Ball gleich 1024. In dem System-Slice in der obigen Abbildung sind CPU-Bälle gleich 1024 für httpd, sshd, crond und gdm festgelegt. Die Ballwerte für System-, Benutzer- und Maschinen-Slices sind ebenfalls 1024. Ist das etwas verwirrend? In der Tat kann dies als Baum dargestellt werden:
- System - 1024
- httpd - 1024
- sshd - 1024
- crond - 1024
- GDM - 1024
- Benutzer - 1024
- Bash (Richter) - 1024
- Bash (Dorf) - 1024
- Maschine - 1024
In dieser Liste haben wir mehrere laufende Daemons, einige Benutzer und eine virtuelle Maschine. Stellen Sie sich nun vor, dass alle gleichzeitig die gesamte Prozessorzeit anfordern, die erhalten werden kann.
Zusammenfassend:
- Das Slice-System erhält 33,333% der Prozessorzeit und teilt sie zu gleichen Teilen auf vier Dämonen auf, wodurch jeder von ihnen 8,25% der CPU-Ressourcen erhält.
- Das Benutzer-Slice empfängt 33,333% der Prozessorzeit und teilt sie zwischen zwei Benutzern auf, von denen jeder 16,5% der CPU-Ressourcen besitzt. Wenn sich der Benutzer mrichter abmeldet oder alle laufenden Prozesse stoppt, hat dorf Zugriff auf 33% der CPU-Ressourcen.
- Slice Machine erhält 33,333% der Prozessorzeit. Wenn Sie die VM ausschalten oder in den Leerlaufmodus versetzen, erhalten System- und Benutzer-Slices ungefähr 50% der CPU-Ressourcen, die dann von ihren untergeordneten Slices gemeinsam genutzt werden.
Darüber hinaus können Sie für jeden Daemon, Benutzer oder jede virtuelle Maschine nicht nur relative, sondern auch absolute Einschränkungen für den Prozessorverbrauch eingeben, nicht nur für einen, sondern auch für mehrere Prozessoren. Beispielsweise verfügt der Benutzer-Slice-Richter über die Eigenschaft CPUQuota. Wenn Sie 20% festlegen, erhält mrichter unter keinen Umständen mehr als 20% der Ressourcen einer CPU. Auf Multi-Core-Servern kann die CPUQuota mehr als 100% betragen, sodass das Slice die Ressourcen von mehr als einem Prozessor verwenden kann. Beispielsweise kann mit CPUQuota = 200% ein Slice zwei Prozessorkerne vollständig nutzen. Es ist wichtig zu verstehen, dass CPUQuota nicht reserviert, dh keinen bestimmten Prozentsatz der Prozessorzeit für eine Systemlast garantiert - dies ist nur das Maximum, das einem Slice unter Berücksichtigung aller anderen Slices und Einstellungen zugewiesen werden kann.
In vollem Umfang drehen!
Wie kann ich die Slice-Einstellungen ändern?
Zu diesem Zweck verfügt jedes Slice über benutzerdefinierte Eigenschaften. Und da es sich um Linux handelt, können wir die Einstellungen manuell in die Konfigurationsdateien schreiben oder über die Befehlszeile festlegen.
Im zweiten Fall wird der Befehl systemctl set-property verwendet. Folgendes passiert auf dem Bildschirm, wenn Sie diesen Befehl eingeben, den Namen des Slice am Ende hinzufügen (in unserem Fall Benutzer) und dann die Tabulatortaste drücken, um die Optionen anzuzeigen:
Nicht alle Eigenschaften in diesem Screenshot sind Gruppeneinstellungen. Wir sind hauptsächlich an solchen interessiert, die mit Block, CPU und Speicher beginnen.
Wenn Sie nicht die Befehlszeile, sondern Konfigurationsdateien bevorzugen (z. B. für die automatisierte Bereitstellung auf mehreren Hosts), müssen Sie sich mit den Dateien im Ordner / etc / systemd / system befassen. Diese Dateien werden automatisch erstellt, wenn Sie Eigenschaften mit dem Befehl systemctl festlegen. Sie können jedoch auch in einem Texteditor erstellt, über Puppet gestempelt oder sogar von Skripten im laufenden Betrieb generiert werden.
Mit den Grundkonzepten von cgroups sollte also alles klar sein. Beim nächsten Mal werden wir einige Szenarien durchgehen und sehen, wie sich Änderungen an bestimmten Eigenschaften auf die Leistung auswirken.
Und buchstäblich morgen laden wir alle zum Red Hat Forum Russia 2018 ein - es besteht die Möglichkeit, Fragen direkt an die Red Hat-Ingenieure zu stellen.Weitere Beiträge von cgroups aus unserer Resource Fight-Reihe finden Sie unter: