Zwiększenie gęstości kontenerów na węźle za pomocą technologii PFCACHE

Jednym z celów dostawcy hostingu jest maksymalne wykorzystanie dostępnego sprzętu w celu zapewnienia wysokiej jakości usług końcowym użytkownikom. Zasoby serwerów końcowych są zawsze ograniczone, jednak liczba umieszczonych usług klientów, a w naszym przypadku VPS, może się znacznie różnić. O tym, jak zmieścić się na choince i zjeść burgera, przeczytasz poniżej.

Zagęszczenie VPS na węźle w taki sposób, aby klienci tego w ogóle nie odczuwali, bardzo pomaga poprawić wskaźniki ekonomiczne każdego dostawcy hostingu. Oczywiście węzeł nie powinien pękać w szwach, jeśli jest napakowany kontenerami do granic możliwości, a każdy wzrost obciążenia odczuwają wszyscy klienci.

Ilość VPS, które można umieścić na jednym węźle, zależy od wielu czynników, w tym oczywistych, takich jak:

1. Właściwości sprzętu samego węzła
2. Rozmiar VPS
3. Charakter obciążenia na VPS
4. Technologie oprogramowania, które pomagają optymalizować gęstość

W tym przypadku podzielimy się doświadczeniem w wykorzystaniu technologii Pfcache dla Virtuozzo.
Używamy szóstego wydania, ale wszystko, co zostało powiedziane, dotyczy również siódmego.

Pfcache to mechanizm Virtuozzo, który pomaga deduplikować IOPS i RAM w kontenerach, wydzielając te same pliki w kontenerach do jednej wspólnej strefy.

W rzeczywistości składa się on z:
1. Kod jądra
2. Demona w przestrzeni użytkownika
3. Narzędzia w przestrzeni użytkownika

Po stronie węzła wydzielamy cały partycję, na której będą tworzone pliki, z których będą korzystać wszystkie VPS na węźle. Na tę partycję montowane jest urządzenie blokowe ploop. Następnie przy uruchomieniu kontenera otrzymuje on referencję do tej partycji:

[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
...

Oto przybliżona statystyka liczby plików na jednym z naszych węzłów:

[root@pcs13 ~]# find /vz/pfcache -type f | wc -l
45851
[root@pcs13 ~]# du -sck -h /vz/pfcache
2.4G    /vz/pfcache
2.4G    łącznie

Zasada działania pfcache jest następująca:
• Demon Pfcached w przestrzeni użytkownika zapisuje skrót SHA-1 pliku w atrybucie xattr danego pliku. Pliki są przetwarzane tylko w niektórych katalogach: /usr, /bin, /usr/sbin, /sbin, /lib, /lib64

• Prawdopodobnie pliki w tych katalogach będą «wspólne» i będą używane przez kilka kontenerów;

• Pfcached okresowo gromadzi statystyki odczytu plików z jądra, analizuje je i dodaje pliki do cache, jeśli ich użycie jest częste;

• Te katalogi mogą być inne i są konfigurowane w plikach konfiguracyjnych.

• Przy odczycie pliku sprawdzane jest, czy zawiera on podany hash w rozszerzonych atrybutach xattr. Jeśli tak, otwierany jest «wspólny» plik, zamiast pliku kontenera. Ta zamiana dzieje się niezauważalnie dla kodu kontenera i jest ukryta w jądrze;

• Przy zapisie do pliku hash jest unieważniany. W ten sposób przy kolejnym otwarciu otwierany będzie już bezpośrednio plik kontenera, a nie jego cache.

Trzymając w pamięci podręcznej wspólne pliki z /vz/pfcache, osiągamy oszczędność tego cache oraz oszczędność IOPS. Zamiast odczytywać dziesięć plików z dysku, odczytujemy jeden, który od razu trafia do pamięci podręcznej.

struct inode {
...
 struct file             *i_peer_file;
...
};
struct address_space {
...
 struct list_head        i_peer_list;
...
}

Lista VMA dla pliku pozostaje jednolita (deduplikujemy pamięć) i rzadziej odczytujemy z dysku (oszczędzamy IOPS). Nasz «wspólny» plik znajduje się na SSD – dodatkowa oszczędność w prędkości.

Przykład dla cache'owania pliku /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

Efektywność wykorzystania obliczana gotowym skryptem.

Ten skrypt przechodzi przez wszystkie kontenery na węźle, obliczając pliki z pamięci podręcznej każdego kontenera.

[root@pcs16 ~]# /pcs/distr/pfcache-examine.pl
...
Pfcache cache wykorzystuje 831 MB pamięci
Całkowite wykorzystanie plików pfcached w kontenerach wynosi 39837 MB pamięci
Efektywność pfcache: 39006 MB

W ten sposób oszczędzamy około 40 gigabajtów pamięci z plików w kontenerach, które będą wczytywane z pamięci podręcznej.

Aby ten mechanizm działał jeszcze lepiej, należy umieszczać na węźle jak najbardziej «jednorodne» VPS. Na przykład te, na które użytkownik nie ma dostępu root i na których skonfigurowano środowisko z rozpakowanego obrazu.

Działanie pfcache można dostosować za pomocą pliku konfiguracyjnego
/etc/vz/pfcache.conf

MINSIZE, MAXSIZE – minimalny/maximum rozmiar pliku do buforowania
TIMEOUT – czas oczekiwania między próbami buforowania

Pełna lista parametrów jest dostępna pod tym linkiem.

Źródło: habr.com