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

    С полным списком параметров можно ознакомится по ссылке.
    Rusonyx
    0,00
    Компания
    Поделиться публикацией

    Комментарии 0

    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

    Самое читаемое