Една от целите на хостинг доставчика е максимално използване на наличното оборудване за предоставяне на качествена услуга на крайни потребители. Ресурсите на крайни сървъри винаги са ограничени, но броят на разположените клиентски услуги, а в нашия случай става въпрос за 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 кешът използва 831 MB памет
Общото използване на файловете pfcached в контейнери е 39837 MB памет
Ефективност на Pfcache: 39006 MB
Така, съхраняваме около 40 гигабайта файлове в контейнерите, които ще се зареждат от кеша.
За да работи този механизъм още по-добре, е необходимо да се разполагат на нода максимално "еднакви" VPS. Например, такива, за които потребителят няма root-достъп и на които е настроено околната среда от разширен образ.
Работата на pfcache може да се настройва чрез конфигурационния файл
/etc/vz/pfcache.conf
MINSIZE, MAXSIZE – минимален/максимален размер на файла за кеширане
TIMEOUT – таймаут между опитите за кеширане
С пълен списък на параметрите можете да се запознаете .
Източник: habr.com
