Увеличение плотности контейнеров на ноде с помощью технологии 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 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