Jednym z celów dostawcy usług hostingowych jest maksymalne wykorzystanie istniejącego sprzętu w celu zapewnienia wysokiej jakości usług użytkownikom końcowym. Zasoby serwerów końcowych są zawsze ograniczone, jednak liczba hostowanych usług klienckich, w naszym przypadku mówimy o VPS, może znacznie się różnić. Przeczytaj o tym, jak wspiąć się na drzewo i zjeść burgera pod rozcięciem.
Kompaktowanie VPS na węźle w taki sposób, że klienci w ogóle tego nie odczuwają, znacznie pomaga zwiększyć wydajność ekonomiczną dowolnego dostawcy usług hostingowych. Oczywiście węzeł nie powinien pękać w szwach, jeśli jest zapchany kontenerami, a każdy wzrost obciążenia jest natychmiast odczuwalny przez wszystkich klientów.
To, ile VPS może być hostowanych na jednym węźle, zależy od wielu czynników, takich oczywistych jak:
1. Charakterystyka sprzętu samego węzła
2. Rozmiar VPS
3. Charakter obciążenia VPS
4. Technologie oprogramowania pomagające zoptymalizować gęstość
W tym przypadku podzielimy się naszymi doświadczeniami z wykorzystania technologii Pfcache dla Virtuozzo.
Używamy szóstej gałęzi, ale wszystko, co powiedziano, odnosi się również do siódmej gałęzi.
– mechanizm Virtuozzo, który pomaga deduplikować IOPS i RAM w kontenerach, przydzielając identyczne pliki w kontenerach do osobnego wspólnego obszaru.
W rzeczywistości składa się z:
1. Kod jądra
2. Demon przestrzeni użytkownika
3. Narzędzia przestrzeni użytkownika
Po stronie węzła przydzielamy całą sekcję, w której zostaną utworzone pliki, które będą bezpośrednio wykorzystywane przez wszystkie VPS na węźle. W tej sekcji zamontowane jest urządzenie blokujące. Następnie po uruchomieniu kontenera otrzymuje odnośnik do tej sekcji:
[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żone statystyki dotyczące 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 total
Zasada pfcache jest następująca:
• Demon przestrzeni użytkownika Pfcached zapisuje skrót sha-1 pliku do atrybutu xattr tego pliku. Nie wszystkie pliki są przetwarzane, ale tylko w katalogach /usr, /bin, /usr/sbin, /sbin, /lib, /lib64
• Najprawdopodobniej pliki w tych katalogach zostaną „współdzielone” i będą wykorzystywane przez kilka kontenerów;
• Pfcached okresowo zbiera statystyki odczytu plików z jądra, analizuje je i dodaje pliki do pamięci podręcznej, jeśli są często używane;
• Katalogi te mogą być różne i są konfigurowane w plikach konfiguracyjnych.
• Podczas odczytu pliku sprawdzane jest, czy zawiera on określony skrót w rozszerzonych atrybutach xattr. Jeśli zawiera, zamiast pliku kontenera otwierany jest plik „ogólny”. To podstawienie następuje niezauważone przez kod kontenera i jest ukryte w jądrze;
• Podczas zapisywania do pliku hash zostaje unieważniony. Dlatego przy następnym otwarciu otwarty zostanie sam plik kontenera, a nie jego pamięć podręczna.
Trzymając udostępnione pliki z /vz/pfcache w pamięci podręcznej strony, osiągamy oszczędności w samej tej pamięci podręcznej, a także oszczędności w IOPS.Zamiast czytać dziesięć plików z dysku, czytamy jeden, który od razu trafia do pamięci podręcznej strony.
struct inode {
...
struct file *i_peer_file;
...
};
struct address_space {
...
struct list_head i_peer_list;
...
}
Lista VMA dla pliku pozostaje pojedyncza (deduplikujemy pamięć) i jest rzadziej odczytywana z dysku (oszczędność IOPS). Nasz wspólny fundusz znajduje się na dysku SSD - dodatkowy przyrost prędkości.
Przykład buforowania 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
Obliczamy efektywność użytkowania .
Ten skrypt przechodzi przez wszystkie kontenery w węźle, obliczając pliki w pamięci podręcznej każdego kontenera.
[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
Zatem z pamięci zapisujemy około 40 gigabajtów plików w kontenerach, które zostaną załadowane z pamięci podręcznej.
Aby ten mechanizm działał jeszcze lepiej, konieczne jest umieszczenie na węźle najbardziej „identycznego” VPS-a. Przykładowo takie, do których użytkownik nie ma dostępu root i na których skonfigurowane jest środowisko z wdrożonego obrazu.
Możesz dostroić pfcache poprzez plik konfiguracyjny
/etc/vz/pfcache.conf
MINSIZE, MAXSIZE – minimalny/maksymalny rozmiar pliku do buforowania
TIMEOUT – limit czasu pomiędzy próbami buforowania
Możesz wyświetlić pełną listę parametrów .
Źródło: www.habr.com