
Ein Ziel des Hosting-Anbieters ist es, die vorhandene Hardware bestmöglich zu nutzen, um den Endnutzern einen qualitativ hochwertigen Service zu bieten. Die Ressourcen der Endserver sind immer begrenzt, jedoch kann die Anzahl der gehosteten Kundendienste, in unserem Fall VPS, erheblich variieren. Wie man auf den Baum klettern und einen Burger essen kann, lesen Sie weiter unten.
Die Verdichtung von VPS auf einem Node, sodass die Kunden dies nicht spüren, hilft, die wirtschaftlichen Kennzahlen jedes Hosting-Anbieters zu verbessern. Natürlich darf der Node nicht überlastet sein, wenn er bis zum Rand mit Containern gefüllt ist, denn jeder Lastanstieg wird sofort von allen Kunden wahrgenommen.
Wie viele VPS auf einem einzigen Node untergebracht werden können, hängt von vielen Faktoren ab, die so offensichtlich sind wie:
1. Die Spezifikationen der Hardware des Nodes
2. Die Größe des VPS
3. Die Art der Last auf dem VPS
4. Softwaretechnologien, die helfen, die Dichte zu optimieren
In diesem Fall teilen wir unsere Erfahrungen mit der Technologie Pfcache für Virtuozzo.
Wir verwenden den 6. Zweig, aber alles, was gesagt wird, gilt auch für den 7.
ist ein Mechanismus von Virtuozzo, der hilft, IOPS und RAM in Containern zu deduplizieren, indem er identische Dateien in Containern in einen gemeinsamen Bereich auslagert.
Er besteht faktisch aus:
1. Kernel-Code
2. User-Space-Daemon
3. User-Space-Dienstprogramm
Auf der Seite des Nodes weisen wir eine gesamte Partition zu, in der Dateien erstellt werden, die direkt von allen VPS auf dem Node verwendet werden. Diese Partition bindet das Blockgerät ploop. Bei Start des Containers erhält dieser einen Verweis auf diese Partition:
[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 ist eine ungefähre Statistik der Anzahl der Dateien auf einem unserer Nodes:
[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 der Funktionsweise von pfcache ist wie folgt:
• Der User-Space-Daemon Pfcached schreibt den SHA-1-Hash der Datei in das xattr-Attribut dieser Datei. Dateien werden nicht alle, sondern nur in den Verzeichnissen /usr, /bin, /usr/sbin, /sbin, /lib, /lib64 verarbeitet.
• Es ist sehr wahrscheinlich, dass Dateien in diesen Verzeichnissen „gemeinsam“ sind und von mehreren Containern verwendet werden;
• Pfcached sammelt regelmäßig Statistiken über das Lesen von Dateien aus dem Kernel, analysiert diese und fügt Dateien in den Cache hinzu, wenn ihre Nutzung häufig ist;
• Diese Verzeichnisse können andere sein und werden in Konfigurationsdateien eingestellt.
• Beim Lesen einer Datei wird überprüft, ob der angegebene Hash in den erweiterten Attributen xattr enthalten ist. Wenn ja – wird die „gemeinsame“ Datei anstelle der Datei des Containers geöffnet. Dieser Austausch erfolgt unbemerkt für den Code des Containers und wird im Kernel verborgen;
• Beim Schreiben in die Datei wird der Hash ungültig. Somit wird beim nachfolgenden Öffnen bereits die Datei des Containers geöffnet und nicht deren Cache.
Indem wir in der Seitencache gemeinsame Dateien aus /vz/pfcache halten, erreichen wir eine Einsparung dieses Caches sowie eine Einsparung an IOPS. Statt 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 Liste der VMA für die Datei bleibt einheitlich (wir deduplizieren den Speicher) und wir lesen seltener von der Festplatte (wir sparen IOPS). Unser „Gemeinschaftsspeicher“ ist auf SSD platziert – ein zusätzlicher Geschwindigkeitsvorteil.
Beispiel für das Caching der Datei /bin/bash:
[root@pcs13 ~]# ls -li /vz/root/2388/bin/bash
524650 -rwxr-xr-x 1 root root 1021112 Okt 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
Die Effizienz der Nutzung wird berechnet .
Dieses Skript durchläuft alle Container auf dem Node und berechnet die gecachten Dateien jedes Containers.
[root@pcs16 ~]# /pcs/distr/pfcache-examine.pl
...
Pfcache-Cache nutzt 831 MB RAM
Die gesamte Nutzung der pfcached-Dateien in Containern beträgt 39837 MB RAM
Effektivität von Pfcache: 39006 MB
Somit sparen wir etwa 40 Gigabyte an Dateien im Speicher von Containern, die aus dem Cache geladen werden.
Damit dieser Mechanismus noch besser funktioniert, sollten auf dem Node möglichst „ähnliche“ VPS untergebracht werden. Zum Beispiel solche, auf die der Benutzer keinen Root-Zugriff hat und bei denen die Umgebung aus einem bereitgestellten Image konfiguriert ist.
Die Arbeit von pfcache kann über die Konfigurationsdatei optimiert werden.
/etc/vz/pfcache.conf
MINSIZE, MAXSIZE – minimale/maximale Dateigröße für das Caching
TIMEOUT – Timeout zwischen den Caching-Versuchen
Eine vollständige Liste der Parameter finden Sie .
Quelle: habr.com
