L'un des objectifs de l'hébergeur est de maximiser l'utilisation des équipements existants afin de fournir un service de haute qualité aux utilisateurs finaux. Les ressources des serveurs finaux sont toujours limitées, mais le nombre de services clients hébergés, et dans notre cas nous parlons de VPS, peut différer considérablement. Découvrez comment grimper à l'arbre et manger un hamburger sous la coupe.
Compacter le VPS sur un nœud de manière à ce que les clients ne le ressentent pas du tout contribue grandement à augmenter les performances économiques de tout fournisseur d'hébergement. Bien entendu, un nœud ne doit pas éclater s'il est rempli de conteneurs, et toute augmentation de charge est immédiatement ressentie par tous les clients.
Le nombre de VPS pouvant être hébergés sur un nœud dépend de nombreux facteurs, aussi évidents que :
1. Caractéristiques du matériel du nœud lui-même
2. Taille du VPS
3. Nature de la charge sur le VPS
4. Technologies logicielles qui aident à optimiser la densité
Dans ce cas, nous partagerons notre expérience d'utilisation de la technologie Pfcache pour Virtuozzo.
Nous utilisons la 6ème branche, mais tout ce qui est dit est également vrai pour la 7ème.
– un mécanisme Virtuozzo qui permet de dédupliquer les IOPS et la RAM dans les conteneurs, en allouant les fichiers identiques dans les conteneurs dans une zone commune distincte.
En fait il se compose de :
1. Code du noyau
2. Démon de l'espace utilisateur
3. Utilitaires de l'espace utilisateur
Côté nœud, nous allouons une section entière dans laquelle seront créés des fichiers qui seront directement utilisés par tous les VPS du nœud. Un dispositif block ploop est monté dans cette section. Ensuite, lorsque le conteneur démarre, il reçoit une référence pour cette section :
[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
...
Voici des statistiques approximatives sur le nombre de fichiers sur l'un de nos nœuds :
[root@pcs13 ~]# find /vz/pfcache -type f | wc -l
45851
[root@pcs13 ~]# du -sck -h /vz/pfcache
2.4G /vz/pfcache
2.4G total
Le principe de pfcache est le suivant :
• Le démon de l'espace utilisateur Pfcached écrit le hachage sha-1 du fichier dans l'attribut xattr de ce fichier. Tous les fichiers ne sont pas traités, mais uniquement dans les répertoires /usr, /bin, /usr/sbin, /sbin, /lib, /lib64
• Il est fort probable que les fichiers de ces répertoires soient « partagés » et utilisés par plusieurs conteneurs ;
• Pfcached collecte périodiquement des statistiques sur la lecture des fichiers du noyau, les analyse et ajoute des fichiers au cache s'ils sont fréquemment utilisés ;
• Ces répertoires peuvent être différents et sont configurés dans les fichiers de configuration.
• Lors de la lecture d'un fichier, il est vérifié s'il contient le hachage spécifié dans les attributs étendus xattr. S'il en contient, le fichier « général » est ouvert à la place du fichier conteneur. Cette substitution se produit inaperçue par le code du conteneur et est cachée dans le noyau ;
• Lors de l'écriture dans un fichier, le hachage est invalidé. Ainsi, la prochaine fois que vous l'ouvrirez, c'est le fichier conteneur lui-même qui sera ouvert, et non son cache.
En conservant les fichiers partagés de /vz/pfcache dans le cache des pages, nous réalisons des économies dans ce cache lui-même, ainsi que des économies en IOPS. Au lieu de lire dix fichiers du disque, nous en lisons un, qui va immédiatement dans le cache des pages.
struct inode {
...
struct file *i_peer_file;
...
};
struct address_space {
...
struct list_head i_peer_list;
...
}
La liste VMA du fichier reste unique (nous dédupliquons la mémoire) et est lue moins souvent sur le disque (économie d'IOPS). Notre fonds commun est implanté sur un SSD – un gain de rapidité supplémentaire.
Exemple de mise en cache du fichier /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
Nous calculons l'efficacité d'utilisation .
Ce script parcourt tous les conteneurs du nœud, calculant les fichiers mis en cache de chaque conteneur.
[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
Ainsi, de la mémoire nous sauvegardons environ 40 gigaoctets de fichiers dans des conteneurs ; ils seront chargés depuis le cache.
Pour que ce mécanisme fonctionne encore mieux, il est nécessaire de placer le VPS le plus « identique » sur le nœud. Par exemple, ceux auxquels l'utilisateur n'a pas d'accès root et sur lesquels l'environnement à partir de l'image déployée est configuré.
Vous pouvez régler pfcache via le fichier de configuration
/etc/vz/pfcache.conf
MINSIZE, MAXSIZE – taille de fichier minimale/maximale pour la mise en cache
TIMEOUT – délai d'attente entre les tentatives de mise en cache
Vous pouvez consulter la liste complète des paramètres .
Source: habr.com