Збільшення щільності контейнерів на ноді за допомогою технології PFCACHE

Однією з цілей хостинг-провайдера є максимально можлива утилізація обладнання для надання якісного сервісу кінцевим користувачам. Ресурси кінцевих серверів завжди обмежені, проте кількість розміщених клієнтських сервісів, а в нашому випадку мова про VPS може істотно відрізнятися. Про те, як на ялинку влізти і з'їсти бургер, читайте під катом.

Ущільнення VPS на ноді таким чином, щоб клієнти цього не відчували, дуже допомагає підвищувати економічні показники будь-якого хостинг-провайдера. Безумовно, нода не повинна тріщати по швах, якщо в неї напхано контейнерів під зав'язку, і будь-який сплеск навантаження відразу відчувають усі клієнти.

Скільки VPS може бути розміщено на одній ноді, залежить від багатьох факторів, таких очевидних як:

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

У цьому випадку ми поділимося досвідом використання технології Pfcache для Virtuozzo.
Ми використовуємо шосту гілку, але все сказане справедливо і для сьомої.

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 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 – тайм-аут між спробами кешування

З повним списком параметрів можна ознайомитись за посиланням.

Джерело: habr.com