Увеличаване на плътността на контейнерите на нода чрез технологията PFCACHE

Увеличаване на плътността на контейнерите на нода чрез технологията PFCACHE

Една от целите на хостинг доставчика е максималното използване на наличното оборудване за предоставяне на качествено обслужване на крайни потребители. Ресурсите на крайните сървъри винаги са ограничени, но количеството на разположените клиентски услуги, а в нашия случай става дума за VPS, може значително да варира. За повече информация как да се поберем на елхата и да изядем хамбургер, четете нататък.

Уплътняването на VPS на възлите по такъв начин, че клиентите да не го усещат, много помага за повишаване на икономическите показатели на всеки хостинг доставчик. Разбира се, възелът не трябва да се разпада, ако е пълен с контейнери, и всеки ръст на натоварването веднага се усеща от всички клиенти.

Броят на VPS, който може да бъде разположен на един възел, зависи от множество фактори, някои от които са очевидни:

1. Характеристики на железния оборудване на самия възел
2. Размер на VPS
3. Характер на натоварването на VPS
4. Технологии на софтуера, които помагат за оптимизиране на плътността

В този случай ще споделим опит с използването на технологията Pfcache за Virtuozzo.
Използваме 6-та версия, но всичко казано важи и за 7-ма.

Pfcache е механизъм на Virtuozzo, който помага за дедупликиране на IOPS и RAM в контейнерите, като отделя идентични файлове в контейнерите в обща зона.

Всъщност той се състои от:
1. Код на ядрото
2. User-space демон
3. User-space утилита

Отстрани на възела, определяме цял дял, в който ще се създават файлове, които ще се използват от всички 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 е следният:
• User-space демонът 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

Купете надежден хостинг за сайтове със защита от DDoS, VPS и VDS сървъри 🔥 Купете надежден хостинг за сайтове със защита от DDoS, VPS и VDS сървъри | ProHoster