Neuere Versionen von Podman, Buildah und CRI-O nutzen eine neue Kernel-Funktion, flüchtige Overlay-Mounts. Mit dieser Funktion können Sie ein Overlay-Dateisystem mit einem Flag mounten, das ihm mitteilt, dass es nicht mit der Festplatte synchronisiert werden soll.
Wenn Sie eine Erinnerung an die Verwendung und die Vorteile von Overlay-Halterungen benötigen, lesen Sie meinen Artikel vom letzten Sommer.
Was ist Synchronisierung und warum ist sie wichtig?
Wenn Sie unter Linux in eine Datei oder ein Verzeichnis schreiben, schreibt der Kernel die Daten nicht sofort auf die Festplatte. Stattdessen puffert es eine Reihe von Schreibvorgängen und speichert die Daten dann regelmäßig auf der Festplatte, um die Leistung zu steigern. Dies wird als Synchronisierung bezeichnet . Das Problem dabei ist, dass ein Prozess denkt Die Daten wurden gespeichert, wenn der Schreibvorgang abgeschlossen ist, aber erst, wenn der Kernel diese Daten synchronisiert. Das bedeutet, wenn Sie Daten geschrieben haben und der Kernel abgestürzt ist, besteht die Möglichkeit, dass die Daten nie gespeichert wurden.
Aus diesem Grund werden viele Dateisysteme regelmäßig synchronisiert, und Tools können eine häufige Synchronisierung anfordern. Wenn eine Synchronisierung stattfindet, stoppt der Kernel die Verarbeitung von Daten mit einer Sperre und synchronisiert alle Daten auf die Festplatte. Dies führt natürlich zu einer schlechteren Leistung. Wenn Sie einen Prozess haben, der häufig Synchronisierungen verursacht, kann die Leistung Ihres Jobs wirklich beeinträchtigt werden. Bestimmte Tools wie RPM erfordern eine Synchronisierung, nachdem jede Datei auf die Festplatte geschrieben wurde, was dazu führt, dass alle schmutzigen Seiten für diese Datei geleert werden, und es ist ein beträchtlicher Overhead.
[ Erste Schritte mit Containern? Schauen Sie sich diesen kostenlosen Kurs an. Containerisierte Anwendungen bereitstellen:Eine technische Übersicht. ]
Container müssen möglicherweise nicht synchronisiert werden
In der Containerwelt haben wir viele Anwendungsfälle, bei denen es uns egal ist, ob die Daten gespeichert werden. Wenn der Kernel abstürzt, würden wir die geschriebenen Daten ohnehin nicht verwenden.
Bei einem buildah bud oder podman build , wird das Container-Image in einen Overlay-Bereitstellungspunkt geschrieben, häufig unter Verwendung von DNF oder YUM. Wenn der Kernel mitten in der Erstellung eines Images abstürzt, wäre der in die Overlay-Schicht geschriebene Inhalt nutzlos und muss vom Benutzer bereinigt werden. Alles, was nicht geschrieben werden konnte, wurde einfach gelöscht. Wenn der Build jedoch abgeschlossen ist, wird die Overlay-Ebene in ein Image-Bundle umgewandelt, das dann mit der Festplatte synchronisiert werden kann.
Ein weiterer Anwendungsfall für flüchtige Overlay-Mounts ist das Ausführen von Podman mit --rm Flagge. Der --rm Flag weist Podman an, den Container und den Overlay-Einhängepunkt zu zerstören, wenn der Container abgeschlossen ist. Ein Absturz des Containers würde Inhalte hinterlassen, für die der Benutzer bereits angegeben hat, dass er keine Verwendung hat, sodass es keinen Grund gibt, sich darum zu kümmern, ob ein Schreibvorgang erfolgreich war.
In der Kubernetes-Welt ist CRI-O die Container-Engine. Kubernetes ist fast immer so eingerichtet, dass alle Container beim Booten entfernt werden. Grundsätzlich möchte es mit einem sauberen Zustand beginnen. Das heißt, wenn der Kernel abstürzte, während Daten auf den Overlay-Mount geschrieben wurden, würden diese Daten zerstört, sobald das System bootet. Es ist auch sicher, solche Konfigurationen mit zustandsbehafteten Containern zu verwenden, da die Daten normalerweise auf externe Volumes geschrieben werden, die zur Laufzeit nicht vom „volatile“-Flag betroffen sind.
Hinzufügen einer flüchtigen Option
Giuseppe Scrivano, Ingenieur des Container-Teams, bemerkte diese Anwendungsfälle und dachte, dass wir die Leistung verbessern könnten, indem wir dem Overlay-Dateisystem des Linux-Kernels eine flüchtige Option hinzufügen und dieses Verhalten implementieren. Infolgedessen verwenden neuere Versionen von Buildah, Podman und CRI-O in diesen Anwendungsfällen standardmäßig das flüchtige Flag und erzielen hoffentlich eine bessere Leistung.
Beachten Sie, dass alle in den Container gemounteten Volumes weiterhin das standardmäßige Synchronisierungsverhalten typischer Dateisysteme haben, sodass Sie sich keine Sorgen über den Verlust von Daten machen müssen, die in den permanenten Speicher geschrieben wurden.
Das folgende Diagramm zeigt, wie die Anzahl der Schreib-IOPS in einem Container reduziert wird, der yum install -y texlive ausführt auf einem Rechner mit 16 GB RAM. Wenn der Container mit aktiviertem Volatil-Flag ausgeführt wird, wirkt sich dies außerdem auf seine Uhrzeit aus und wird schneller beendet.
Die Dirty Pages werden schließlich in den Speicher geschrieben, sobald entweder das Dirty Ratio oder das Inode-Timeout abgelaufen ist, da diese Einstellungen nicht durch das volatile Mount-Flag beeinflusst werden.
Abschluss
Mit der Container-Technologie gehen wir ständig an die Grenzen dessen, was das Linux-System verarbeiten kann, und experimentieren mit neuen Anwendungsfällen. Das Hinzufügen einer flüchtigen Option zum Overlay-Dateisystem des Kernels trägt zur Leistungssteigerung bei, sodass sich Container weiterentwickeln und größere Vorteile bieten können.
[ Kostenloser Download:Spickzettel für fortgeschrittene Linux-Befehle. ]