Uno degli obiettivi del fornitore di hosting è massimizzare l'utilizzo delle apparecchiature esistenti al fine di fornire un servizio di alta qualità agli utenti finali. Le risorse dei server finali sono sempre limitate, ma il numero di servizi client ospitati, e nel nostro caso stiamo parlando di VPS, può differire in modo significativo. Leggi come arrampicarti sull'albero e mangiare un hamburger sotto il taglio.
Compattare il VPS su un nodo in modo tale che i clienti non lo sentano affatto aiuta molto ad aumentare le prestazioni economiche di qualsiasi fornitore di hosting. Naturalmente, un nodo non dovrebbe scoppiare se è pieno zeppo di contenitori e qualsiasi aumento di carico viene immediatamente avvertito da tutti i client.
Quanti VPS possono essere ospitati su un nodo dipende da molti fattori, ovvi come:
1. Caratteristiche dell'hardware del nodo stesso
2. Dimensioni del VPS
3. Natura del carico sul VPS
4. Tecnologie software che aiutano a ottimizzare la densità
In questo caso condivideremo la nostra esperienza nell'utilizzo della tecnologia Pfcache per Virtuozzo.
Usiamo il 6° ramo, ma tutto quanto detto vale anche per il 7°.
– un meccanismo Virtuozzo che aiuta a deduplicare IOPS e RAM nei contenitori, allocando file identici nei contenitori in un'area comune separata.
Infatti è composto da:
1. Codice del kernel
2. Demone dello spazio utente
3. Utilità dello spazio utente
Lato nodo dedichiamo un'intera sezione in cui verranno creati i file che verranno utilizzati direttamente da tutti i VPS presenti sul nodo. In questa sezione è montato un dispositivo block loop. Quindi, all'avvio del contenitore, riceve un riferimento per questa sezione:
[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
...
Ecco le statistiche approssimative sul numero di file su uno dei nostri nodi:
[root@pcs13 ~]# find /vz/pfcache -type f | wc -l
45851
[root@pcs13 ~]# du -sck -h /vz/pfcache
2.4G /vz/pfcache
2.4G total
Il principio di pfcache è il seguente:
• Il demone dello spazio utente Pfcached scrive l'hash sha-1 del file nell'attributo xattr di questo file. Non tutti i file vengono elaborati, ma solo nelle directory /usr, /bin, /usr/sbin, /sbin, /lib, /lib64
• È molto probabile che i file in queste directory verranno “condivisi” e verranno utilizzati da diversi contenitori;
• Pfcached raccoglie periodicamente statistiche sulla lettura dei file dal kernel, li analizza e aggiunge file alla cache se vengono utilizzati frequentemente;
• Queste directory possono essere diverse e sono configurate nei file di configurazione.
• Durante la lettura di un file, viene controllato se contiene l'hash specificato negli attributi estesi xattr. Se contiene, viene aperto il file “generale” anziché il file contenitore. Questa sostituzione avviene inosservata dal codice contenitore ed è nascosta nel kernel;
• Quando si scrive su un file, l'hash viene invalidato. Pertanto, la prossima volta che lo aprirai, verrà aperto il file contenitore stesso e non la sua cache.
Mantenendo i file condivisi da /vz/pfcache nella cache della pagina, otteniamo risparmi in questa cache stessa, così come risparmi in IOPS. Invece di leggere dieci file dal disco, ne leggiamo uno, che va immediatamente nella cache della pagina.
struct inode {
...
struct file *i_peer_file;
...
};
struct address_space {
...
struct list_head i_peer_list;
...
}
L'elenco VMA per il file rimane singolo (deduplichiamo la memoria) e viene letto dal disco meno spesso (risparmiando iops). Il nostro fondo comune si trova su un SSD: un ulteriore guadagno in termini di velocità.
Esempio per memorizzare nella cache il file /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
Calcoliamo l'efficienza di utilizzo .
Questo script esamina tutti i contenitori sul nodo, calcolando i file memorizzati nella cache di ciascun contenitore.
[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
Pertanto, dalla memoria salviamo circa 40 gigabyte di file in contenitori; verranno caricati dalla cache.
Perché questo meccanismo funzioni ancora meglio è necessario posizionare sul nodo i VPS più “identici”. Ad esempio, quelli a cui l'utente non ha accesso root e su cui è configurato l'ambiente dall'immagine distribuita.
Puoi ottimizzare pfcache tramite il file di configurazione
/etc/vz/pfcache.conf
MINSIZE, MAXSIZE – dimensione minima/massima del file per la memorizzazione nella cache
TIMEOUT – timeout tra i tentativi di memorizzazione nella cache
È possibile visualizzare l'elenco completo dei parametri .
Fonte: habr.com