Uno degli obiettivi del provider di hosting è il massimo utilizzo dell'hardware disponibile per fornire un servizio di qualità agli utenti finali. Le risorse dei server finali sono sempre limitate, ma il numero di servizi clienti allocati, nel nostro caso riguardante le VPS, può variare notevolmente. Per scoprire come arrampicarsi sull'albero e mangiare un hamburger, leggi sotto.
Compattare le VPS su un nodo in modo tale che i clienti non se ne accorgano affatto contribuisce notevolmente a migliorare le performance economiche di qualsiasi provider di hosting. Certamente, il nodo non deve "scoppiare" se è sovraccarico di contenitori, e qualsiasi piccola fluttuazione nel carico è immediatamente avvertita da tutti i clienti.
Il numero di VPS che possono essere allocati su un unico nodo dipende da molti fattori, come:
1. Caratteristiche hardware del nodo stesso
2. Dimensione della VPS
3. Tipo di carico sulla VPS
4. Tecnologie software che aiutano a ottimizzare la densità
In questo caso, condivideremo l'esperienza di utilizzo della tecnologia Pfcache per Virtuozzo.
Utilizziamo il ramo 6, ma quanto detto è valido anche per il ramo 7.
è un meccanismo di Virtuozzo che aiuta a deduplicare IOPS e RAM nei contenitori, allocando file identici nei contenitori in un'area comune separata.
In effetti, è composto da:
1. Codice del kernel
2. Demone in user-space
3. Utility in user-space
Dalla parte del nodo, allocchiamo una partizione intera, nella quale verranno creati i file di cui faranno uso direttamente tutte le VPS sul nodo. In questa partizione viene montato il dispositivo a blocchi ploop. Successivamente, all'avvio del contenitore, riceve un riferimento a questa partizione:
[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 una stima del 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 totale
Il principio di funzionamento di pfcache è il seguente:
• Il demone Pfcached in user-space scrive l'hash sha-1 del file nell'attributo xattr di questo file. I file vengono trattati non tutti, ma solo nelle directory /usr, /bin, /usr/sbin, /sbin, /lib, /lib64
• È molto probabile che i file in queste directory siano "condivisi" e siano utilizzati da più contenitori;
• Pfcached raccoglie periodicamente statistiche di lettura dei file dal kernel, le analizza e aggiunge i file nella cache se il loro utilizzo è frequente;
• Queste directory possono essere diverse e sono configurabili nei file di configurazione.
• Durante la lettura di un file, viene verificato se contiene l'hash specificato negli attributi estesi xattr. Se presente, viene aperto un file "condiviso", invece di quello del contenitore. Questa sostituzione avviene senza che il codice del contenitore se ne accorga ed è gestita dal kernel;
• Durante la scrittura di un file, l'hash viene invalidato. Così, alla successiva apertura, verrà aperto il file del contenitore e non quello in cache.
Mantenendo nella cache delle pagine file condivisi da /vz/pfcache otteniamo un risparmio proprio di quella cache, oltre a risparmiare IOPS. Invece di leggere dieci file dal disco, ne leggiamo uno, che va direttamente nella cache delle pagine.
struct inode {
...
struct file *i_peer_file;
...
};
struct address_space {
...
struct list_head i_peer_list;
...
}
La lista VMA per il file rimane unica (deduplica la memoria) e leggiamo meno spesso dal disco (risparmiamo IOPS). Il nostro "pool" è posizionato su SSD – un ulteriore vantaggio in termini di velocità.
Esempio per la memorizzazione nella cache del file /bin/bash:
[root@pcs13 ~]# ls -li /vz/root/2388/bin/bash
524650 -rwxr-xr-x 1 root root 1021112 Ott 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
L'efficienza nell'utilizzo è calcolata .
Questo script attraversa tutti i contenitori nel nodo, calcolando i file cached di ogni contenitore.
[root@pcs16 ~]# /pcs/distr/pfcache-examine.pl
...
La cache di Pfcache usa 831 MB di memoria
L'uso totale dei file pfcached nei contenitori è di 39837 MB di memoria
Efficacia di Pfcache: 39006 MB
In questo modo, risparmiamo circa 40 gigabyte di file nei contenitori in memoria, che verranno caricati dalla cache.
Per far sì che questo meccanismo funzioni ancora meglio, è necessario posizionare nel nodo VPS il più "simili" possibile. Ad esempio, quelli per i quali l'utente non ha accesso root e per i quali è stato configurato un ambiente da un'immagine distribuita.
È possibile ottimizzare il funzionamento di pfcache tramite il file di configurazione
/etc/vz/pfcache.conf
MINSIZE, MAXSIZE – dimensione minima/massima del file per la cache
TIMEOUT – timeout tra i tentativi di caching
È possibile consultare l'elenco completo dei parametri .
Fonte: habr.com
