Адной з мэт хостынг-правайдэра з'яўляецца максімальна магчымая ўтылізацыя наяўнага абсталявання для падавання якаснага сэрвісу канчатковым карыстачам. Рэсурсы канчатковых сервераў заўсёды абмежаваныя, аднак колькасць змесцаваных кліенцкіх сэрвісаў, а ў нашым выпадку прамова аб VPS, можа істотна адрознівацца. Пра тое, як на ёлку ўлезці і бургер з'есці, чытайце пад катом.
Ушчыльненне VPS на нодзе такім чынам, каб кліенты гэтага зусім не адчувалі, вельмі дапамагае падвышаць эканамічныя паказчыкі любога хостынг-правайдэра. Безумоўна, нода не павінна трашчаць па швах, калі ў яе напіхана кантэйнераў пад завязку, і любы ўсплёск па нагрузцы адразу адчуваюць усе кліенты.
Колькі VPS можа быць размешчана на адной нодзе, залежыць ад мноства фактараў, такіх відавочных як:
1. Характарыстыкі жалеза самай ноды
2. Памер VPS
3. Характар нагрузкі на VPS
4. Тэхналогіі софту, якія дапамагаюць аптымізаваць шчыльнасць
У дадзеным выпадку мы падзелімся досведам выкарыстання тэхналогіі Pfcache для Virtuozzo.
Мы выкарыстоўваем 6-ю галінку, але ўсё сказанае справядліва і для 7-й.
– механізм 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