Eines der Ziele des Hosting-Anbieters ist die maximal mögliche Entsorgung vorhandener Geräte, um den Endbenutzern einen qualitativ hochwertigen Service zu bieten. Die Ressourcen der Endserver sind immer begrenzt, jedoch kann die Anzahl der gehosteten Clientdienste, und in unserem Fall handelt es sich um VPS, erheblich variieren. Lesen Sie, wie Sie auf einen Weihnachtsbaum steigen und einen Burger unter einer Katze essen.
Die Konsolidierung eines VPS auf einem Knoten so, dass Kunden dies überhaupt nicht spüren, trägt wesentlich zur Steigerung der wirtschaftlichen Leistung eines Hosting-Anbieters bei. Natürlich sollte ein Knoten nicht an den Nähten reißen, wenn Behälter bis zu den Augäpfeln hineingepfercht sind und alle Kunden sofort einen Lastanstieg spüren.
Wie viele VPS auf einem Knoten platziert werden können, hängt von vielen Faktoren ab, darunter:- Eigenschaften des Eisens des Knotens selbst
- VPS-Größe
- VPS-Lastmuster
- Softwaretechnologien zur Optimierung der Dichte
In diesem Fall werden wir unsere Erfahrungen mit der Pfcache-Technologie für Virtuozzo teilen.
Wir benutzen den 6. Zweig, aber alles, was gesagt wird, gilt für den 7 ..
Pfcache ist ein Virtuozzo-Mechanismus, mit dem IOPS und RAM in Containern
dedupliziert werden können , indem dieselben Dateien in Containern einer separaten gemeinsamen Zone
zugewiesen werden.
In der Tat besteht es aus:- Kernel-Code
- User-Space-Daemon
- User-Space-Dienstprogramme
Auf der Knotenseite markieren wir einen ganzen Abschnitt, in dem Dateien erstellt werden, die alle VPS auf dem Knoten direkt verwenden. In diesem Abschnitt ist die Schaufelblockvorrichtung montiert. Außerdem erhält er zu Beginn des Containers 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 sind Beispielstatistiken 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 lautet wie folgt:- Der User-Space-Pfcached-Daemon schreibt den sha-1-Hash der Datei in das xattr-Attribut dieser Datei. Dateien werden nicht alle verarbeitet, sondern nur 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 zum 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 den Konfigurationsdateien konfiguriert.
- Beim Lesen einer Datei wird geprüft, ob sie den angegebenen Hash in den erweiterten xattr-Attributen enthält. Wenn es enthält, wird anstelle der Containerdatei die "allgemeine" Datei geöffnet. Diese Ersetzung erfolgt unbemerkt durch den Containercode und versteckt sich im Kernel.
- Beim Schreiben in eine Datei wird der Hash ungültig. Somit wird beim nächsten Öffnen die Containerdatei direkt geöffnet und nicht ihr Cache.
Indem wir gemeinsam genutzte Dateien aus / vz / pfcache im Seitencache behalten, speichern wir diesen Cache sowie IOPS. Anstatt zehn Dateien von der Festplatte zu lesen, lesen wir eine, die direkt in den Seitencache gelangt.
struct inode { ... struct file *i_peer_file; ... }; struct address_space { ... struct list_head i_peer_list; ... }
Die VMA-Liste für die Datei bleibt unverändert (deduplizierter Speicher) und wird seltener von der Festplatte gelesen (Save Iops). Unser "Common Fund" wird auf SSD gehostet - 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 Effizienz der Nutzung mit einem
vorgefertigten 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
Somit speichern wir ungefähr 40 Gigabyte an Dateien in Containern aus dem Speicher, sie werden aus dem Cache geladen.
Damit dieser Mechanismus noch besser funktioniert, muss der maximale „identische“ VPS auf dem Knoten platziert werden. Zum Beispiel diejenigen, für die der Benutzer keinen Root-Zugriff hat und für die die Umgebung aus dem erweiterten Image konfiguriert ist.
Sie können den pfcache-Betrieb über die Konfigurationsdatei optimieren
/etc/vz/pfcache.conf
MINSIZE, MAXSIZE - minimale / maximale Dateigröße für das Caching
TIMEOUT - Zeitüberschreitung zwischen Cache-Versuchen
Eine vollständige Liste der Parameter finden Sie
unter dem Link .