
Eines der Ziele des Hosting-Anbieters besteht darin, die vorhandene Hardware so weit wie möglich zu nutzen, um den Endbenutzern einen qualitativ hochwertigen Service zu bieten. Die Ressourcen der Endserver sind immer begrenzt, jedoch kann die Anzahl der platzierten Client-Dienste, in unserem Fall VPS, erheblich variieren. Lesen Sie mehr dazu unter dem Link.
Die Verdichtung von VPS auf einem Node, sodass die Kunden dies überhaupt nicht spüren, hilft sehr, die wirtschaftlichen Kennzahlen jedes Hosting-Anbieters zu verbessern. Natürlich darf der Node nicht aus den Nähten platzen, wenn er bis zum Anschlag mit Containern gefüllt ist, und jeder Anstieg der Last wird sofort von allen Kunden gespürt.
Wie viele VPS auf einem Node platziert werden können, hängt von vielen Faktoren ab, darunter offensichtlich:
1. Die Hardware-Spezifikationen des Nodes
2. Die Größe des VPS
3. Die Art der Last auf dem VPS
4. Softwar Technologien, die helfen, die Dichte zu optimieren
In diesem Fall teilen wir Erfahrungen mit der Nutzung der Pfcache-Technologie für Virtuozzo.
Wir verwenden die 6. Version, aber alles Gesagte gilt auch für die 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 verschiebt.
Er besteht faktisch aus:
1. Kernel-Code
2. User-Space Daemon
3. User-Space Utility
Auf der Node-Seite weisen wir einen gesamten Abschnitt zu, in dem die Dateien erstellt werden, die von allen VPS auf dem Node direkt genutzt werden. In diesen Abschnitt wird das Blockgerät ploop eingebunden. Bei der Starts des Containers erhält er einen Verweis auf 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 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 das folgende:
• 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" sind und von mehreren Containern verwendet werden.
• Pfcached sammelt regelmäßig Statistiken über das Lesen von Dateien aus dem Kern, analysiert diese und fügt Dateien in den Cache ein, wenn ihre Nutzung häufig ist;
• Die Datenverzeichnisse können unterschiedlich sein und werden in den Konfigurationsdateien angepasst.
• Beim Lesen einer Datei wird überprüft, ob der angegebene Hash in den erweiterten Attributen xattr enthalten ist. Falls ja, wird eine "gemeinsame" Datei anstelle der Containerdatei geöffnet. Dieser Austausch findet unsichtbar für den Containercode statt und wird im Kern verborgen;
• Beim Schreiben in eine Datei wird der Hash ungültig gemacht. Somit wird bei nachfolgender Öffnung direkt die Containerdatei und nicht deren Cache geöffnet.
Indem wir gemeinsame Dateien aus /vz/pfcache im Seitencache halten, sparen wir diesen Cache sowie IOPS. Anstatt zehn Dateien von der Festplatte zu lesen, lesen wir eine, die direkt 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 (Speicher wird dedupliziert) und wir lesen seltener von der Festplatte (wir sparen IOPS). Unser "Gemeinschaftsbestand" ist auf SSD gespeichert – 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 Knoten und berechnet die zwischengespeicherten Dateien jedes Containers.
[root@pcs16 ~]# /pcs/distr/pfcache-examine.pl
...
Pfcache-Cache verwendet 831 MB RAM
Die gesamte Nutzung von pfcached Dateien in Containern beträgt 39837 MB RAM
Pfcache-Effektivität: 39006 MB
Somit sparen wir etwa 40 Gigabyte an Dateien im Container im Speicher, diese werden aus dem Cache geladen.
Um diesen Mechanismus noch besser funktionieren zu lassen, sollten auf dem Knoten so viele "ähnliche" VPS wie möglich bereitgestellt werden. Zum Beispiel solche, auf denen der Benutzer keinen Root-Zugang hat und auf denen eine Umgebung aus einem entpackten Image eingerichtet ist.
Die Arbeit von pfcache kann über die Konfigurationsdatei optimiert werden
/etc/vz/pfcache.conf
MINSIZE, MAXSIZE – minimales/maximales Dateigröße für das Caching
TIMEOUT – Timeout zwischen den Cache-Versuchen
Mit der vollständigen Liste der Parameter kann man sich vertraut machen .
Quelle: habr.com
