L'un des objectifs du fournisseur d'hébergement est l'élimination maximale possible des équipements existants 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, nous parlons de VPS, peut varier considérablement. Découvrez comment monter sur un arbre de Noël et manger un hamburger sous un chat.
La consolidation d'un VPS sur un nœud de telle manière que les clients ne le sentent pas du tout aide beaucoup à augmenter les performances économiques de tout fournisseur d'hébergement. Bien sûr, un nœud ne doit pas se fissurer au niveau des coutures si des conteneurs y sont entassés jusqu'aux globes oculaires, et tous les clients ressentent immédiatement toute augmentation de charge.
Le nombre de VPS pouvant être placés sur un nœud dépend de nombreux facteurs, tels que:- Caractéristiques du fer du nœud lui-même
- Taille VPS
- Modèle de charge VPS
- Technologies logicielles permettant d'optimiser la densité
Dans ce cas, nous partagerons notre expérience de l'utilisation de la technologie Pfcache pour Virtuozzo.
Nous utilisons la 6ème branche, mais tout ce qui est dit est vrai pour la 7ème.
Pfcache est un mécanisme Virtuozzo qui permet de dédupliquer les IOPS et la RAM dans les conteneurs, en allouant les mêmes fichiers dans les conteneurs à une zone commune distincte.
En fait, il consiste en:- Code du noyau
- Démon de l'espace utilisateur
- Utilitaires de l'espace utilisateur
Côté nœud, nous mettons en évidence une section entière dans laquelle seront créés les fichiers que tous les VPS du nœud utiliseront directement. Le dispositif de bloc de ploop est monté dans cette section. De plus, au début du conteneur, il reçoit une référence à 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 exemples de statistiques 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 Pfcached de l'espace utilisateur écrit le hachage 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 de ces répertoires seront «partagés» et seront utilisés par plusieurs conteneurs;
- Pfcached collecte périodiquement des statistiques sur la lecture des fichiers à partir du noyau, les analyse et ajoute des fichiers au cache si leur utilisation est fréquente;
- 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 xattr étendus. S'il contient, le fichier «commun» est ouvert, au lieu du fichier conteneur. Cette substitution se produit inaperçue par le code conteneur et se cache dans le noyau;
- Lors de l'écriture dans un fichier, le hachage est invalidé. Ainsi, à la prochaine ouverture, le fichier conteneur sera ouvert directement, et non son cache.
En conservant les fichiers partagés dans le cache de page à partir de / vz / pfcache, nous enregistrons ce cache ainsi que les IOPS. Au lieu de lire dix fichiers sur le disque, nous en lisons un 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 du fichier reste la même (mémoire dédupliquée) et lit moins souvent à partir du disque (sauvegarde des iops). Notre «fonds commun» est hébergé sur SSD - un gain de vitesse 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 avec un
script prêt à l'emploi .
Ce script passe par 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, nous économisons environ 40 gigaoctets de fichiers dans des conteneurs de la mémoire, ils seront chargés à partir du cache.
Pour que ce mécanisme fonctionne encore mieux, il est nécessaire de placer le maximum de VPS «identiques» sur le nœud. Par exemple, ceux pour lesquels l'utilisateur n'a pas d'accès root et sur lesquels l'environnement de l'image développée est configuré.
Vous pouvez régler l'opération 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 cache
Une liste complète des paramètres se trouve
sur le lien .