Një nga qëllimet e ofruesit të pritjes është të maksimizojë përdorimin e pajisjeve ekzistuese në mënyrë që të ofrojë shërbime me cilësi të lartë për përdoruesit përfundimtarë. Burimet e serverëve fundorë janë gjithmonë të kufizuara, por numri i shërbimeve të klientëve të pritur, dhe në rastin tonë po flasim për VPS, mund të ndryshojë ndjeshëm. Lexoni se si të ngjiteni në pemë dhe të hani një burger nën prerje.
Kompaktimi i VPS-së në një nyje në mënyrë të tillë që klientët të mos e ndiejnë fare atë, ndihmon shumë në rritjen e performancës ekonomike të çdo ofruesi të pritjes. Natyrisht, një nyje nuk duhet të shpërthejë në qepje nëse është e mbushur plot me kontejnerë dhe çdo rritje e ngarkesës ndihet menjëherë nga të gjithë klientët.
Sa VPS mund të strehohen në një nyje varet nga shumë faktorë, të tillë të dukshëm si:
1. Karakteristikat e harduerit të vetë nyjës
2. Madhësia VPS
3. Natyra e ngarkesës në VPS
4. Teknologjitë softuerike që ndihmojnë në optimizimin e densitetit
Në këtë rast, ne do të ndajmë përvojën tonë të përdorimit të teknologjisë Pfcache për Virtuozzo.
Ne përdorim degën e 6-të, por gjithçka që thuhet është e vërtetë edhe për të 7-ën.
– një mekanizëm Virtuozzo që ndihmon në heqjen e IOPS dhe RAM në kontejnerë, duke shpërndarë skedarë identikë në kontejnerë në një zonë të veçantë të përbashkët.
Në fakt ai përbëhet nga:
1. Kodi i kernelit
2. Demon i hapësirës së përdoruesit
3. Shërbimet e hapësirës së përdoruesit
Në anën e nyjës, ne ndajmë një seksion të tërë në të cilin do të krijohen skedarë që do të përdoren drejtpërdrejt nga të gjithë VPS-të në nyje. Një pajisje bllok ploop është montuar në këtë seksion. Pastaj, kur kontejneri fillon, ai merr një referencë për këtë seksion:
[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
...
Këtu janë statistikat e përafërta për numrin e skedarëve në një nga nyjet tona:
[root@pcs13 ~]# find /vz/pfcache -type f | wc -l
45851
[root@pcs13 ~]# du -sck -h /vz/pfcache
2.4G /vz/pfcache
2.4G total
Parimi i pfcache është si më poshtë:
• Daemon i hapësirës së përdoruesit Pfcached shkruan hash-in sha-1 të skedarit në atributin xattr të këtij skedari. Jo të gjithë skedarët përpunohen, por vetëm në drejtoritë /usr, /bin, /usr/sbin, /sbin, /lib, /lib64
• Ka shumë të ngjarë që skedarët në këto direktori do të "ndahen" dhe do të përdoren nga disa kontejnerë;
• Pfcached mbledh periodikisht statistika mbi leximin e skedarëve nga kerneli, e analizon atë dhe shton skedarë në cache nëse ato përdoren shpesh;
• Këto direktori mund të jenë të ndryshme dhe janë konfiguruar në skedarë konfigurimi.
• Gjatë leximit të një skedari, kontrollohet nëse ai përmban hash-in e specifikuar në atributet e zgjeruara xattr. Nëse përmban, skedari "i përgjithshëm" hapet në vend të skedarit të kontejnerit. Ky zëvendësim ndodh pa u vënë re nga kodi i kontejnerit dhe fshihet në kernel;
• Kur shkruani në një skedar, hash-i është i pavlefshëm. Kështu, herën tjetër që ta hapni, do të hapet vetë skedari i kontejnerit dhe jo cache-i i tij.
Duke mbajtur skedarë të përbashkët nga /vz/pfcache në cache-in e faqeve, ne arrijmë kursime në vetë këtë memorie, si dhe kursime në IOPS, në vend që të lexojmë dhjetë skedarë nga disku, lexojmë një, i cili menjëherë shkon në cache të faqeve.
struct inode {
...
struct file *i_peer_file;
...
};
struct address_space {
...
struct list_head i_peer_list;
...
}
Lista VMA për skedarin mbetet e vetme (ne heqim memorien) dhe lexohet nga disku më rrallë (duke ruajtur iops). Fondi ynë i përbashkët ndodhet në një SSD - një fitim shtesë në shpejtësi.
Shembull për ruajtjen e skedarit /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
Ne llogarisim efikasitetin e përdorimit .
Ky skrip kalon nëpër të gjithë kontejnerët në nyje, duke llogaritur skedarët e memorizuar të çdo kontejneri.
[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
Kështu, nga memoria ruajmë rreth 40 gigabajt skedarë në kontejnerë; ato do të ngarkohen nga cache.
Që ky mekanizëm të funksionojë edhe më mirë, është e nevojshme të vendosni VPS më "identike" në nyje. Për shembull, ato në të cilat përdoruesi nuk ka qasje në rrënjë dhe në të cilat është konfiguruar mjedisi nga imazhi i vendosur.
Ju mund të sintonizoni pfcache përmes skedarit të konfigurimit
/etc/vz/pfcache.conf
MINSIZE, MAXSIZE – madhësia minimale/maksimale e skedarit për ruajtje në memorie
TIMEOUT – skadimi i kohës ndërmjet përpjekjeve për memorie
Ju mund të shikoni listën e plotë të parametrave .
Burimi: www.habr.com