Erhöhung der Containerdichte auf einem Knoten mithilfe der PFCACHE-Technologie

Eines der Ziele des Hosting-Anbieters besteht darin, die Nutzung vorhandener Geräte zu maximieren, um Endbenutzern einen qualitativ hochwertigen Service zu bieten. Die Ressourcen der Endserver sind immer begrenzt, aber die Anzahl der gehosteten Client-Dienste, und in unserem Fall sprechen wir von VPS, kann erheblich variieren. Lesen Sie, wie man auf den Baum klettert und unter dem Schnitt einen Burger isst.

Die Komprimierung von VPS auf einem Knoten so, dass die Kunden es überhaupt nicht spüren, trägt erheblich dazu bei, die wirtschaftliche Leistung jedes Hosting-Anbieters zu steigern. Natürlich darf ein Knoten nicht aus allen Nähten platzen, wenn er mit Containern vollgestopft ist, und jeder Lastanstieg ist für alle Clients sofort spürbar.

Wie viele VPS auf einem Knoten gehostet werden können, hängt von vielen Faktoren ab, darunter offensichtlichen:

1. Eigenschaften der Hardware des Knotens selbst
2. VPS-Größe
3. Art der Belastung des VPS
4. Softwaretechnologien, die zur Optimierung der Dichte beitragen

In diesem Fall werden wir unsere Erfahrungen mit der Verwendung der Pfcache-Technologie für Virtuozzo teilen.
Wir verwenden den 6. Zweig, aber alles Gesagte gilt auch für den 7. Zweig.

Pfcache – ein Virtuozzo-Mechanismus, der dabei hilft, IOPS und RAM in Containern zu deduplizieren und identische Dateien in Containern einem separaten gemeinsamen Bereich zuzuweisen.

Tatsächlich besteht es aus:
1. Kernel-Code
2. User-Space-Dämon
3. User-Space-Dienstprogramme

Auf der Knotenseite weisen wir einen ganzen Abschnitt zu, in dem Dateien erstellt werden, die von allen VPS auf dem Knoten direkt verwendet werden. In diesem Abschnitt ist ein Block-Ploop-Gerät montiert. Wenn der Container dann startet, erhält er eine Referenz für diesen Abschnitt:

[root@pcs13 ~]# cat /proc/mounts
...
/dev/ploop62124p1 /vz/pfcache ext4 rw,relatime,barrier=1,data=ordered,balloon_ino=12 0 0
...
/dev/ploop22927p1 /vz/root/418 ext4 rw,relatime,barrier=1,data=ordered,balloon_ino=12,pfcache_csum,pfcache=/vz/pfcache 0 0
/dev/ploop29642p1 /vz/root/264 ext4 rw,relatime,barrier=1,data=ordered,balloon_ino=12,pfcache_csum,pfcache=/vz/pfcache 0 0
...

Hier finden Sie ungefähre Statistiken zur Anzahl der Dateien auf einem unserer Knoten:

[root@pcs13 ~]# find /vz/pfcache -type f | wc -l
45851
[root@pcs13 ~]# du -sck -h /vz/pfcache
2.4G    /vz/pfcache
2.4G    total

Das Prinzip von pfcache ist wie folgt:
• Der User-Space-Daemon Pfcached schreibt den SHA-1-Hash der Datei in das xattr-Attribut dieser Datei. Es werden nicht alle Dateien verarbeitet, sondern nur die in den Verzeichnissen /usr, /bin, /usr/sbin, /sbin, /lib, /lib64

• Es ist sehr wahrscheinlich, dass die Dateien in diesen Verzeichnissen „gemeinsam genutzt“ werden und von mehreren Containern verwendet werden.

• Pfcached sammelt regelmäßig Statistiken über das Lesen von Dateien aus dem Kernel, analysiert sie und fügt Dateien zum Cache hinzu, wenn sie häufig verwendet werden;

• Diese Verzeichnisse können unterschiedlich sein und werden in Konfigurationsdateien konfiguriert.

• Beim Lesen einer Datei wird geprüft, ob diese den angegebenen Hash in den erweiterten xattr-Attributen enthält. Wenn es enthält, wird die „allgemeine“ Datei anstelle der Containerdatei geöffnet. Diese Ersetzung erfolgt vom Containercode unbemerkt und ist im Kernel verborgen;

• Beim Schreiben in eine Datei wird der Hash ungültig gemacht. Daher wird beim nächsten Öffnen die Containerdatei selbst geöffnet und nicht ihr Cache.

Indem wir freigegebene Dateien aus /vz/pfcache im Seitencache behalten, erzielen wir Einsparungen im Cache selbst sowie Einsparungen bei IOPS. Anstatt zehn Dateien von der Festplatte zu lesen, lesen wir eine, die sofort in den Seitencache geht.

struct inode {
...
 struct file             *i_peer_file;
...
};
struct address_space {
...
 struct list_head        i_peer_list;
...
}

Die VMA-Liste für die Datei bleibt einzeln (wir deduplizieren den Speicher) und wird seltener von der Festplatte gelesen (das spart Iops). Unser gemeinsamer Fonds liegt auf einer SSD – ein zusätzlicher Geschwindigkeitsgewinn.

Beispiel für das Zwischenspeichern der Datei /bin/bash:

[root@pcs13 ~]# ls -li /vz/root/2388/bin/bash
524650 -rwxr-xr-x 1 root root 1021112 Oct  7  2018 /vz/root/2388/bin/bash
[root@pcs13 ~]# pfcache dump /vz/root/2388 | grep 524650
8e3aa19fdc42e87659746f6dc8ea3af74ab30362 i:524650      g:1357611108  f:CP
[root@pcs13 ~]# sha1sum /vz/root/2388/bin/bash
8e3aa19fdc42e87659746f6dc8ea3af74ab30362  /vz/root/2388/bin/bash
[root@pcs13 /]# getfattr -ntrusted.pfcache /vz/root/2388/bin/bash
# file: vz/root/2388/bin/bash
trusted.pfcache="8e3aa19fdc42e87659746f6dc8ea3af74ab30362"
[root@pcs13 ~]# sha1sum /vz/pfcache/8e/3aa19fdc42e87659746f6dc8ea3af74ab30362
8e3aa19fdc42e87659746f6dc8ea3af74ab30362  /vz/pfcache/8e/3aa19fdc42e87659746f6dc8ea3af74ab30362

Wir berechnen die Nutzungseffizienz fertiges Skript.

Dieses Skript durchläuft alle Container auf dem Knoten und berechnet die zwischengespeicherten Dateien jedes Containers.

[root@pcs16 ~]# /pcs/distr/pfcache-examine.pl
...
Pfcache cache uses 831 MB of memory
Total use of pfcached files in containers is 39837 MB of memory
Pfcache effectiveness: 39006 MB

Aus dem Speicher speichern wir also etwa 40 Gigabyte Dateien in Containern; sie werden aus dem Cache geladen.

Damit dieser Mechanismus noch besser funktioniert, ist es notwendig, den möglichst „identischen“ VPS auf dem Knoten zu platzieren. Zum Beispiel diejenigen, auf die der Benutzer keinen Root-Zugriff hat und auf denen die Umgebung aus dem bereitgestellten Image konfiguriert ist.

Sie können pfcache über die Konfigurationsdatei optimieren
/etc/vz/pfcache.conf

MINSIZE, MAXSIZE – minimale/maximale Dateigröße für das Caching
TIMEOUT – Zeitüberschreitung zwischen Caching-Versuchen

Sie können die vollständige Liste der Parameter anzeigen Link.

Source: habr.com