L'un des objectifs d'un fournisseur d'hébergement est d'exploiter au maximum le matériel existant pour fournir un service de qualité aux utilisateurs finaux. Les ressources des serveurs finaux sont toujours limitées, cependant, le nombre de services clients hébergés, et dans notre cas il s'agit de VPS, peut varier considérablement. Pour savoir comment grimper sur un sapin et manger un burger, lisez ci-dessous.
L'optimisation des VPS sur un nœud de manière à ce que les clients ne le ressentent pas vraiment aide énormément à améliorer les performances économiques de tout fournisseur d'hébergement. Bien sûr, le nœud ne doit pas craquer si des conteneurs sont surchargés, et toute augmentation de charge est immédiatement ressentie par tous les clients.
Le nombre de VPS pouvant être hébergés sur un seul nœud dépend de nombreux facteurs, tels que certains évidents comme :
1. Les caractéristiques du matériel du nœud lui-même
2. La taille du VPS
3. La nature de la charge sur le VPS
4. Les 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 version 6, mais tout ce qui est dit est également valable pour la version 7.
– un mécanisme Virtuozzo qui aide à dédupliquer les IOPS et la RAM dans les conteneurs, en allouant des fichiers identiques dans les conteneurs à une zone commune distincte.
En fait, il se compose de :
1. Code noyau
2. Démon en espace utilisateur
3. Utilitaire en espace utilisateur
Du côté du nœud, nous allouons une partition entière où des fichiers seront créés, qui seront directement utilisés par tous les VPS sur le nœud. Cette partition est montée sur l'appareil de bloc ploop. Ensuite, lors du démarrage du conteneur, il obtient une référence à cette partition :
[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 les statistiques approximatives du 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 fonctionnement de pfcache est le suivant :
• Le démon en espace utilisateur Pfcached écrit le hash sha-1 du fichier dans l'attribut xattr de ce fichier. Les fichiers ne sont pas tous traités, mais uniquement dans les répertoires /usr, /bin, /usr/sbin, /sbin, /lib, /lib64
• Il est très probable que les fichiers dans ces répertoires soient « communs » et soient utilisés par plusieurs conteneurs ;
• Pfcached collecte périodiquement des statistiques de lecture de fichiers à partir du noyau, les analyse et ajoute les fichiers au cache s'ils sont utilisés fréquemment;
• Les données du répertoire peuvent être différentes et sont configurées 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. Si c'est le cas, un fichier "commun" est ouvert à la place du fichier conteneur. Ce remplacement se produit de manière invisible pour le code du conteneur et est masqué dans le noyau;
• Lors de l'écriture dans un fichier, le hachage est invalidé. Ainsi, lors de l'ouverture suivante, c'est directement le fichier conteneur qui sera ouvert, et non son cache.
En conservant dans le cache de page les fichiers communs de /vz/pfcache, nous économisons ce même cache, ainsi que les IOPS. Au lieu de lire dix fichiers à partir du disque, nous en lisons un seul, qui va directement dans le cache de page.
struct inode {
...
struct file *i_peer_file;
...
};
struct address_space {
...
struct list_head i_peer_list;
...
}
La liste VMA pour le fichier reste unique (nous dédupliquons la mémoire) et nous lisons moins souvent à partir du disque (économisant les IOPS). Notre "caisse commune" est hébergée sur SSD - un gain de vitesse supplémentaire.
Exemple pour le cache d'un 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
Efficacité de l'utilisation calculée .
Ce script parcourt tous les conteneurs sur le nœud, calculant les fichiers mis en cache de chaque conteneur.
[root@pcs16 ~]# /pcs/distr/pfcache-examine.pl
...
La cache Pfcache utilise 831 Mo de mémoire
L'utilisation totale des fichiers pfcached dans les conteneurs est de 39837 Mo de mémoire
Efficacité de Pfcache : 39006 Mo
Ainsi, nous économisons environ 40 Go de fichiers en mémoire dans les conteneurs, qui seront chargés à partir du cache.
Pour que ce mécanisme fonctionne encore mieux, il est nécessaire d'héberger sur le nœud des VPS le plus "semblables" possible. Par exemple, ceux sur lesquels l'utilisateur n'a pas d'accès root et où l'environnement est configuré à partir de l'image déployée.
L'optimisation du fonctionnement de pfcache peut se faire via le fichier de configuration
/etc/vz/pfcache.conf
MINSIZE, MAXSIZE – taille minimale/maximale du fichier pour le cache
TIMEOUT – délai entre les tentatives de mise en cache
Vous pouvez consulter la liste complète des spécifications. .
Source : habr.com
