Et af målene for hostingudbyderen er at maksimere udnyttelsen af eksisterende udstyr for at levere service af høj kvalitet til slutbrugere. Ressourcerne på slutservere er altid begrænsede, men antallet af hostede klienttjenester, og i vores tilfælde taler vi om VPS, kan variere betydeligt. Læs om, hvordan du klatrer i træet og spiser en burger under snittet.
At komprimere VPS på en node på en sådan måde, at kunderne slet ikke føler det, hjælper i høj grad med at øge den økonomiske ydeevne for enhver hostingudbyder. Selvfølgelig bør en knude ikke briste i sømmene, hvis den er proppet fuld af containere, og enhver stigning i belastningen mærkes straks af alle klienter.
Hvor mange VPS der kan hostes på én node afhænger af mange faktorer, så indlysende som:
1. Karakteristika af hardwaren i selve noden
2. VPS størrelse
3. Arten af belastningen på VPS'en
4. Softwareteknologier, der hjælper med at optimere tætheden
I dette tilfælde vil vi dele vores erfaring med at bruge Pfcache-teknologi til Virtuozzo.
Vi bruger den 6. gren, men alt sagt gælder også for den 7.
– en Virtuozzo-mekanisme, der hjælper med at deduplikere IOPS og RAM i containere, ved at allokere identiske filer i containere til et separat fælles område.
Faktisk består den af:
1. Kernelkode
2. User-space dæmon
3. Bruger-rum hjælpeprogrammer
På nodesiden tildeler vi en hel sektion, hvor der vil blive oprettet filer, som vil blive direkte brugt af alle VPS på noden. Der er monteret en blok-ploop-enhed i denne sektion. Derefter, når beholderen starter, modtager den en reference til dette afsnit:
[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
...
Her er omtrentlige statistikker over antallet af filer på en af vores noder:
[root@pcs13 ~]# find /vz/pfcache -type f | wc -l
45851
[root@pcs13 ~]# du -sck -h /vz/pfcache
2.4G /vz/pfcache
2.4G total
Princippet for pfcache er som følger:
• User-space-dæmonen Pfcached skriver sha-1-hashen af filen til xattr-attributten for denne fil. Ikke alle filer behandles, men kun i mapperne /usr, /bin, /usr/sbin, /sbin, /lib, /lib64
• Det er mest sandsynligt, at filerne i disse mapper vil blive "delt" og vil blive brugt af flere containere;
• Pfcached indsamler periodisk statistik om læsning af filer fra kernen, analyserer den og tilføjer filer til cachen, hvis de bruges ofte;
• Disse mapper kan være forskellige og er konfigureret i konfigurationsfiler.
• Når en fil læses, kontrolleres det, om den indeholder den angivne hash i de udvidede xattr-attributter. Hvis den indeholder, åbnes den "generelle" fil i stedet for containerfilen. Denne substitution sker ubemærket af containerkoden og er skjult i kernen;
• Når du skriver til en fil, bliver hashen ugyldig. Næste gang du åbner den, vil selve containerfilen blive åbnet, og ikke dens cache.
Ved at holde delte filer fra /vz/pfcache i sidecachen opnår vi besparelser i selve denne cache, samt besparelser i IOPS I stedet for at læse ti filer fra disk læser vi én, som straks går til sidecachen.
struct inode {
...
struct file *i_peer_file;
...
};
struct address_space {
...
struct list_head i_peer_list;
...
}
VMA-listen for filen forbliver enkelt (vi deduplikerer hukommelse) og læses sjældnere fra disk (sparer iops). Vores fælles fond er placeret på en SSD - en ekstra gevinst i hastighed.
Eksempel på cachelagring af /bin/bash-filen:
[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
Vi beregner brugseffektiviteten .
Dette script går gennem alle containerne på noden og beregner de cachelagrede filer for hver 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
Fra hukommelsen gemmer vi således omkring 40 gigabyte filer i containere; de vil blive indlæst fra cachen.
For at denne mekanisme skal fungere endnu bedre, er det nødvendigt at placere den mest "identiske" VPS på noden. For eksempel dem, som brugeren ikke har root-adgang til, og som miljøet fra det installerede image er konfigureret på.
Du kan indstille pfcache gennem konfigurationsfilen
/etc/vz/pfcache.conf
MINSIZE, MAXSIZE – minimum/maksimum filstørrelse til caching
TIMEOUT – timeout mellem cachingforsøg
Du kan se den fulde liste over parametre .
Kilde: www.habr.com