Ee vun den Ziler vum Hosting Provider ass d'Notzung vun existente Ausrüstung ze maximéieren fir e qualitativ héichwäerteg Service un Endbenotzer ze bidden. D'Ressourcen vun den Endserveren sinn ëmmer limitéiert, awer d'Zuel vun de gehoste Clientsservicer, an an eisem Fall schwätze mir iwwer VPS, kënne wesentlech ënnerscheeden. Liest wéi Dir op de Bam klammen an e Burger ënner dem Schnëtt iessen.
Kompaktéiere vu VPS op engem Node sou datt d'Clienten et guer net fillen hëlleft immens d'wirtschaftlech Leeschtung vun all Hosting Provider ze erhéijen. Natierlech däerf e Knuet net op d'Nähte platzen, wann et voller Container gefëllt ass, an all Iwwerschwemmung vun der Belaaschtung gëtt direkt vun all Client gefillt.
Wéi vill VPS kënnen op engem Node gehost ginn hänkt vu ville Faktoren of, sou evident wéi:
1. Charakteristike vun der Hardware vum Node selwer
2. VPS Gréisst
3. Natur vun der Laascht op der VPS
4. Software Technologien déi hëllefen Dicht ze optimiséieren
An dësem Fall wäerte mir eis Erfahrung mat der Pfcache Technologie fir Virtuozzo deelen.
Mir benotzen déi 6. Branche, awer alles gesot stëmmt och fir de 7.
- e Virtuozzo Mechanismus deen hëlleft IOPS a RAM a Container ze deduplizéieren, identesch Dateien an Containeren an e separaten gemeinsame Beräich ze verdeelen.
Tatsächlech besteet et aus:
1. Kernel Code
2. Benotzer-Raum Dämon
3. Benotzer-Plaz Utilities
Op der Node Säit verdeele mir eng ganz Sektioun an där Dateien erstallt ginn déi direkt vun all VPS um Node benotzt ginn. E Block Ploop Apparat ass an dëser Sektioun montéiert. Dann, wann de Container ufänkt, kritt en eng Referenz fir dës Sektioun:
[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
...
Hei sinn ongeféier Statistiken iwwer d'Zuel vun de Dateien op engem vun eisen Noden:
[root@pcs13 ~]# find /vz/pfcache -type f | wc -l
45851
[root@pcs13 ~]# du -sck -h /vz/pfcache
2.4G /vz/pfcache
2.4G total
De Prinzip vum pfcache ass wéi follegt:
• De User-Space Daemon Pfcached schreift den sha-1 Hash vun der Datei op d'xattr Attribut vun dëser Datei. Net all Dateie ginn veraarbecht, awer nëmmen an den /usr, /bin, /usr/sbin, /sbin, /lib, /lib64 Verzeichnisser
• Et ass héchstwahrscheinlech datt d'Fichier'en an dëse Verzeichnisser "gedeelt" ginn a vu verschiddene Container benotzt ginn;
• Pfcached sammelt periodesch Statistiken iwwer d'Liesen vun Dateien aus dem Kernel, analyséiert et a füügt Dateien un de Cache, wa se dacks benotzt ginn;
• Dës Verzeichnisser kënnen ënnerschiddlech sinn a sinn an Konfiguratiounsdateien konfiguréiert.
• Wann Dir e Fichier liest, gëtt gepréift ob et de spezifizéierte Hash an den xattr erweiderten Attributer enthält. Wann et enthält, gëtt d'"Allgemeng" Datei opgemaach amplaz vun der Containerdatei. Dës Ersatz geschitt onnotéiert vum Containercode an ass am Kärel verstoppt;
• Wann Dir un e Fichier schreift, gëtt den Hash ongëlteg. Also, déi nächst Kéier wann Dir se opmaacht, gëtt d'Containerdatei selwer opgemaach, an net säi Cache.
Andeems mir gedeelt Dateien aus /vz/pfcache am Säitecache halen, erreechen mir Spuerungen an dësem Cache selwer, souwéi Spuerungen am IOPS.Amplaz zéng Dateien vun der Disk ze liesen, liesen mir een, deen direkt an de Säitecache geet.
struct inode {
...
struct file *i_peer_file;
...
};
struct address_space {
...
struct list_head i_peer_list;
...
}
D'VMA Lëscht fir d'Datei bleift eenzeg (mir deduplizéieren Erënnerung) a gëtt manner dacks vun der Disk gelies (iops spueren). Eise gemeinsame Fonds läit op enger SSD - en zousätzleche Gewënn u Geschwindegkeet.
Beispill fir d'Caching vun der /bin/bash Datei:
[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
Mir berechnen d'Effizienz vum Gebrauch .
Dëse Skript geet duerch all d'Container um Node, berechent déi cache Dateien vun all Container.
[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
Also, aus der Erënnerung späichere mir ongeféier 40 Gigabyte vu Dateien a Container; si ginn aus dem Cache gelueden.
Fir datt dëse Mechanismus nach besser funktionnéiert, ass et néideg déi "identesch" VPS op den Node ze setzen. Zum Beispill déi, op déi de Benotzer kee Root-Zougang huet an op deenen d'Ëmfeld vum ofgebauten Bild konfiguréiert ass.
Dir kënnt pfcache duerch d'Configuratiounsdatei ofstëmmen
/etc/vz/pfcache.conf
MINSIZE, MAXSIZE - Minimum / maximal Dateigréisst fir Cache
TIMEOUT - Timeout tëscht Cache Versich
Dir kënnt déi komplett Lëscht vu Parameteren gesinn .
Source: will.com