Една од целите на давателот на хостинг е да го максимизира користењето на постоечката опрема со цел да обезбеди висококвалитетна услуга за крајните корисници. Ресурсите на крајните сервери се секогаш ограничени, но бројот на хостирани клиентски услуги, а во нашиот случај зборуваме за VPS, може значително да се разликува. Прочитајте како да се искачите на дрвото и да јадете плескавица под сечењето.
Набивањето VPS на јазол на таков начин што клиентите воопшто не го чувствуваат тоа во голема мера помага да се зголемат економските перформанси на кој било хостинг провајдер. Се разбира, јазолот не треба да пукне на шевовите ако е преполн со контејнери, а секој наплив на оптоварување веднаш го чувствуваат сите клиенти.
Колку VPS може да се хостираат на еден јазол зависи од многу фактори, како што се очигледни:
1. Карактеристики на хардверот на самиот јазол
2. Големина на VPS
3. Природата на оптоварувањето на VPS
4. Софтверски технологии кои помагаат да се оптимизира густината
Во овој случај, ќе го споделиме нашето искуство за користење на технологијата Pfcache за Virtuozzo.
Ја користиме 6-та гранка, но се што е кажано важи и за 7-ма.
– механизам Virtuozzo кој помага да се отстранат IOPS и RAM меморијата во контејнерите, алоцирајќи ги идентичните датотеки во контејнерите во посебна заедничка област.
Всушност се состои од:
1. Код на јадрото
2. Демон на корисничкиот простор
3. Услужни програми за кориснички простор
На страната на јазолот, доделуваме цел дел во кој ќе се креираат датотеки кои директно ќе ги користат сите VPS на јазолот. Во овој дел е монтиран блок ploop уред. Потоа, кога контејнерот ќе започне, добива референца за овој дел:
[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
...
Еве приближна статистика за бројот на датотеки на еден од нашите јазли:
[root@pcs13 ~]# find /vz/pfcache -type f | wc -l
45851
[root@pcs13 ~]# du -sck -h /vz/pfcache
2.4G /vz/pfcache
2.4G total
Принципот на pfcache е како што следува:
• Демонот на корисничкиот простор Pfcached го запишува хашот sha-1 на датотеката во атрибутот xattr на оваа датотека. Не се обработуваат сите датотеки, туку само во директориумите /usr, /bin, /usr/sbin, /sbin, /lib, /lib64
• Најверојатно е дека датотеките во овие директориуми ќе бидат „споделени“ и ќе се користат од неколку контејнери;
• Pfcached периодично собира статистика за читање датотеки од кернелот, ги анализира и додава датотеки во кешот ако тие често се користат;
• Овие директориуми може да се различни и се конфигурирани во конфигурациски датотеки.
• При читање на датотека, се проверува дали го содржи наведениот хаш во проширените атрибути xattr. Ако содржи, се отвора „општата“ датотека наместо датотеката со контејнер. Оваа замена се случува незабележано од кодот на контејнерот и е скриена во кернелот;
• Кога пишувате во датотека, хашот е неважечки. Така, следниот пат кога ќе го отворите, ќе се отвори самата датотека на контејнерот, а не нејзиниот кеш.
Со задржување на споделените датотеки од /vz/pfcache во кешот на страницата, постигнуваме заштеди во самиот кеш на страницата, како и заштеди во IOPS. Наместо да читаме десет датотеки од дискот, читаме една, која веднаш оди во кешот на страницата.
struct inode {
...
struct file *i_peer_file;
...
};
struct address_space {
...
struct list_head i_peer_list;
...
}
Листата VMA за датотеката останува единствена (ја дедупликираме меморијата) и поретко се чита од дискот (зачувување на iops). Нашиот заеднички фонд се наоѓа на SSD - дополнителна добивка во брзината.
Пример за кеширање на датотеката /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
Ја пресметуваме ефикасноста на користењето .
Оваа скрипта поминува низ сите контејнери на јазолот, пресметувајќи ги кешираните датотеки на секој контејнер.
[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
Така, од меморијата зачувуваме околу 40 гигабајти датотеки во контејнери; тие ќе бидат вчитани од кешот.
За овој механизам да работи уште подобро, неопходно е да се постави најидентичниот VPS на јазолот. На пример, оние до кои корисникот нема пристап до root и на кои е конфигурирана околината од распоредената слика.
Можете да го вклучите pfcache преку конфигурациската датотека
/etc/vz/pfcache.conf
MINSIZE, MAXSIZE – минимална/максимална големина на датотека за кеширање
TIMEOUT – тајмаут помеѓу обидите за кеширање
Можете да ја видите целосната листа на параметри .
Извор: www.habr.com