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

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

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

Колко VPS могат да бъдат хоствани на един възел зависи от много фактори, такива очевидни като:

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

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

Pfcache – механизъм 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