[ libresys ]

Suite du tutoriel sur OpenVZ… Maintenant que nous avons vu comment créer des serveurs virtuels je vais aborder dans cet article la gestion des ressources allouées aux serveurs virtuels. Ce n’est clairement pas la partie la plus simple de l’utilisation d’OpenVZ, et il m’a fallu quelques temps de pratique pour en comprendre les subtilités. 

Je ne prétends pas faire de cet article un substitut de la documentation de référence sur la gestion des ressources par OpenVZ, loin de là, mais j’espère au moins faire une présentation succincte des bases qui devrait vous simplifier la lecture de la documentation, ou vous en dispenser dans un premier temps.

OpenVZ offre une multitude de paramètres permettant de gérer finement la quantité de ressources allouées aux serveurs virtuels hébergés. Ces paramètres peuvent être classés en plusieurs catégories :

• ceux touchant aux quotas d’espace disque
• ceux agissant sur le temps d’utilisation du CPU
• ceux touchant aux limitations des diverses sources de consommation directe ou indirecte de mémoire, les paramètres UBC

Paramètres de quota d’espace disque

Définir le quota d’espace disque d’un serveur virtuel est plutôt simple. Pour ceux qui ont déjà mis en place des quotas d’espace disque sous linux, ça fonctionne de la même manière, et pour cause : les fichiers des serveurs virtuels sont dans le système de fichiers du serveur hôte (dans /var/lib/vz/private/VEID, où VEID est le n° ID du serveur virtuel)

Le paramètre diskspace permet de contrôler l’espace occupé par les fichiers du serveur virtuel dans le système de fichiers (la somme de la taille de tous les fichiers), et le paramètre diskinodes contrôle le nombre d’inodes (le nombre de fichiers et de répertoires). Chaque paramètre est associé à une limite soft et une limite hard. La limite hard ne peut pas être dépassée, et la soft peut être dépassée temporairement. Pour définir les quotas, utilisez les commandes suivantes :

vzctl set VEID --diskspace $SoftLimit$:$HardLimit$ --save
vzctl set VEID --diskinodes $SoftLimit$:$HardLimit$ --save

Et pour contrôler le taux d’occupation du quota d’espace disque par le serveur virtuel, il suffit d’exécuter la commande df dans le serveur virtuel, par exemple :

# vzctl exec VEID df -h
Filesystem            Size  Used Avail Use% Mounted on
simfs                 7.2G  637M  6.6G   9% /
none                  1.9G     0  1.9G   0% /lib/init/rw
none                  1.9G     0  1.9G   0% /dev/shm

et pour contrôler les inodes :

# vzctl exec VEID df -i
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
simfs                 200000   22803  177197   12% /
none                  219779       2  219777    1% /lib/init/rw
none                  219779       1  219778    1% /dev/shm

A savoir : OpenVZ maintient, pour chaque serveur virtuel, un fichier de quota, placé par défaut dans /var/lib/vzquota. Ce fichier contient des informations sur la consommation d’espace du serveur virtuel. Cependant, si ce fichier venait à être corrompu ou incohérent avec la consommation réelle d’espace disque,, vous devrez le regénérer. Dans ce cas, le plus simple consiste à arrêter le serveur virtuel, supprimer le fichier de quota et redémarrer le serveur virtuel. Le fichier de quota est alors recalculé au lancement du serveur virtuel (ce qui peut prendre un peu de temps s’il contient beaucoup de fichiers).

Paramètres de temps d’utilisation du CPU

Il y a deux manières  de réguler l’utilisation du CPU par les serveurs virtuels OpenVZ.

La première consiste à utiliser le paramètre cpuunits. En utilisant ce paramètre, sur tous les serveurs virtuels, on peut demander à OpenVZ d’accorder à un serveur virtuel plus de temps CPU qu’à un autre en proportion de leurs valeurs de cpuunits respectives. Ici, la valeur donnée importe peu, c’est la proportionnalité entre les valeurs des différents serveurs virtuels qui compte.

Par exemple, si on créé 3 serveurs virtuels, et que leurs valeurs respectives de cpuunits sont 1000, 2000 et 3000, et que ces trois serveurs ont tous besoin de beaucoup de temps CPU, alors OpenVZ accordera au deuxième serveur deux fois plus de temps CPU qu’au premier, et au troisième trois fois plus qu’au premier. Le paramètre cpuunits n’empêche pas un serveur virtuel d’utiliser du temps CPU : si un serveur virtuel a besoin de temps CPU et qu’aucun autre n’en a besoin simultanément, OpenVZ accordera 100% du temps CPU au serveur qui en a besoin.

La seconde consiste à utiliser le paramètre cpulimit. Cette fois il s’agit d’empêcher un serveur virtuel d’utiliser plus qu’un certain pourcentage du temps CPU. Avec une valeur de cpulimit de 50, un serveur virtuel ne pourra pas consommer plus de 50% du temps CPU, même si le CPU ne fait rien le reste du temps. J’avoue que je ne vois pas bien dans quel cas ce paramètre pourrait servir, à moins de vouloir reproduire les performances d’un matériel moins performant.

Pour définir la valeur de cpuunits d’un serveur virtuel, il faut utiliser la commande :

vzctl set VEID --cpuunits <valeur> --save

et pour définir la valeur de cpulimit :

vzctl set VEID --cpulimit <valeur> --save

Paramètres UBC (User Bean Counters)

Je gardais le meilleur pour la fin, car c’est là que ça se corse. Je ne répéterai pas le contenu de la documentation de référence sur les paramètres UBC. Je préfère introduire quelques notions sur ce qu’elles représentent afin d’une part de vous faciliter la lecture de la documentation OpenVZ, et d’autre part de vous proposer un petit outil que j’ai conçu pour me faciliter la vie après avoir galéré quelques temps à essayer de régler ces paramètres sur les serveurs virtuels que j’administre.

Le principe de garantie

Une chose à savoir sur les paramètres UBC, c’est que l’allocation de ressources aux serveurs virtuels fonctionne sur le principe de garantie. Les ressources utilisées par un serveur virtuel sont, schématiquement, comprises entre 0 et une limite supérieure paramétrable. Cependant chaque serveur virtuel a une garantie de disposer d’au moins un minimum, paramétrable également. Pour chaque serveur virtuel, l’administrateur peut donc paramétrer un minimum garanti et une limite à ne pas dépasser pour un grand nombre de paramètres comme, le nombre de processus, le nombre de pages de mémoire ou le nombre de sockets réseau. Ce principe de garantie permet, par rapport à une réservation des ressources, d’augmenter la densité des serveurs virtuels.

Comptabilisation, limitation… ou les deux

Comme décrit dans http://wiki.openvz.org/UBC_parameters les paramètres UBC sont tantôt des paramètres de comptabilisation de la quantité de ressources consommées, tantôt des paramètres de limitation de la consommation de ressources, tantôt les deux. Par exemple, le paramètre physpages ne fait que comptabiliser le nombre de pages mémoires utilisées par un serveur virtuel, le paramètre vmguarpages permet d’offrir une garantie sur la quantité de mémoire disponible pour un serveur virtuel, mais n’en comptabilise pas la consommation, et le paramètre numproc joue à la fois un rôle de comptabilisation et de limite du nombre de processus d’un serveur virtuel.

Limite (limit) et seuil (barrier)… ou pas

Les paramètres UBC qui jouent un rôle de limitation des ressources consommées peuvent prendre deux valeurs : un premier seuil, appelé barrier et une limite haute, appelée limit. Suivant le paramètre, il faudra régler ces deux valeurs ou une seule seulement, et parfois il faudra faire en sorte qu’il y ait un écart entre les deux, et parfois donner la même valeur aux deux.

Le mode de fonctionnement de chaque paramètre est décrit dans http://wiki.openvz.org/UBC_parameters. et je vous invite à y lire la signification de ces valeurs si vous êtes curieux.

Des paramètres étroitement liés

Si vous avez tenu jusque là, sachez enfin que certains paramètres sont étroitement liés. Par exemple, le paramètre kmemsize règle la quantité de mémoire d’un serveur virtuel allouée par le noyau et qui ne sera jamais swappée. Sachant que pour chaque processus le noyau consomme quelques dizaines de Ko de mémoire, on comprend que le paramètre numproc qui limite le nombre processus et le paramètre kmemsize sont liés. Inutile d’autoriser l’exécution de milliers de processus si on n’autorise pas le noyau à consommer de la mémoire pour la gestion des processus !

OpenVZ n’empêche pas de définir des valeurs incohérentes pour les paramètres UBC, mais fournit un outil de vérification de la cohérence des paramètres. C’est donc bien à l’administrateur de veiller à définir correctement les différent paramètres. Par exemple si son serveur virtuel est bloqué par le nombre de processus, l’administrateur doit savoir qu’il doit augmenter les valeurs du paramètre nbproc, que pour ce paramètre il faut mettre la même valeur pour barrier et limit et qu’il vaut mieux également augmenter les valeurs de kmemsize, afin que le serveur virtuel ne soit pas bloqué à nouveau quelques heures plus tard parce que les processus à présent autorisés consomment davantage de mémoire. Et si ces mêmes processus sont susceptibles d’ouvrir des sockets TCP, même chose, il faut autoriser davantage de sockets (paramètre numtcpsock) et dimensionner les buffers mémoire pour la gestion des sockets en conséquence (paramètres tcpsndbuf et tcprcvbuf).

Bref, tout ça pour vous faire comprendre que définir les paramètres UCB à l’arrache en ayant vaguement lu la doc en diagonale n’est pas une bonne idée, car ce que vous risquez d’obtenir, c’est un serveur virtuel qui « craque » parce qu’il a atteint une limite, que vous augmenterez, mais qui craquera parce qu’il en atteindra une autre, etc.

Un outil pour calculer les valeurs des paramètres UBC

Le problème, c’est que même en ayant lu la doc, ça reste fastidieux d’essayer de dimensionner les ressources d’un serveur virtuel par rapport à ce que l’on sait qu’on attend de lui. C’est pourquoi j’ai réalisé une feuille de calcul OpenOffice afin de m’aider à calculer des valeurs cohérentes et adaptées aux besoins des serveurs virtuels que j’administre. Vous pouvez la télécharger ici.

Cette feuille se présente ainsi :

Les cases en rouge sont celles dans lesquelles vous devrez saisir obligatoirement des valeurs. Il s’agit :

• de la quantité de mémoire maximale allouée au serveur vituel, c’est à dire de combien de RAM, swap inclus vous auriez besoin dans un serveur physique qui rendrait le même service,
• d’une estimation du nombre de processus qui fonctionneront sur le serveur en temps normal (la feuille estimera un maximum)
• de la quantité maximale d’espace disque allouée au serveur

Une fois que vous aurez renseigné ces trois valeurs, la feuille les utilise et s’appuie sur un certain nombre de règles empiriques pour déterminer un ensemble de paramètres cohérent. Elle génère également des lignes de commande (en vert) à copier/coller et exécuter sur votre serveur hôte, dans un terminal, pour affecter les ressources à un serveur virtuel. Et c’est tout. Facile comme ça, non ?

Bon… ca ne fait pas de miracle non plus et si vous voulez ajuster plus finement les ressources allouées au serveur virtuel, vous devrez agir sur les cases vertes. Par exemple, vous trouverez dans une case verte un coefficient permettant d’indiquer combien de sockets TCP seront ouverts par processus en moyenne, ce qui permet d’ajuster empiriquement la valeur de numtcpsock en fonction de numproc. Et ce qui convient à un serveur de fichiers samba (beaucoup de processus et beaucoup de connexions réseau) n’est pas forcément justifié pour un serveur J2EE (peu de processus mais beaucoup de connexions).

Je vous suggère d’utiliser cette feuille sans toucher aux coefficients par défaut, dans un premier temps, et de ne saisir que les valeurs sur fond rouge. Puis quand vous aurez fait plus ample connaissance avec OpenVZ, vous pourrez affiner les coefficients sur fond vert et cette feuille vous aidera à ne rien oublier.

Par exemple, si vous souhaitez virtualiser un serveur samba, pour servir des fichiers à un parc de 200 machines et en accordant un espace disque de 300 Go aux utilisateurs. Vous savez que samba n’est pas très consommateur de mémoire, vous pourrez tenter de commencer en accordant disons 300 Mo de mémoire au serveur virtuel. Voici comment procéder :

• ouvrez la feuille de calcul et dans les cases à fond rouge, saisissez 300 Mo de mémoire, 300 Go d’espace disque, et 200 processus (samba créé un fork pour chaque client, donc il faut 1 processus par poste client connecté)
• (optionnel) si vous souhaitez obtenir une indication de la proportion de ressources physiques que ce serveur virtuel va utiliser, renseignez les cases à fond bleu
• copiez / collez les deux lignes de commandes OpenVZ générées et exécutez les dans le serveur physique. Vous devrez remplacer la chaîne « changer_no_VE » par le VEID du serveur virtuel, et ajouter manuellement l’option –save à la fin de la ligne de commande si vous souhaitez que les nouvelles valeurs soient sauvegardées dans le fichier de configuration ; pour cet exemple, et pour un serveur virtuel ayant 1 pour VEID, les lignes de commande seraient (en ajoutant l’option –save)

Je vous invite tout de même à utiliser l’outil de vérification de la cohérence des paramètres UBC fourni par OpenVZ. Cet outil vérifie le fichier de configuration, ce qui suppose que vos nouveaux paramètres UBC soient enregistrés avec l’option –save. Vous pouvez alors taper la commande :

vzcfgvalidate /etc/vz/conf/VEID.conf

en remplaçant VEID par le numéro VEID de votre serveur virtuel.

Contrôler la consommation de ressources d’un serveur virtuel

OpenVZ fournit un moyen simple de vérifier combien de ressources vos serveurs virtuels consomment réellement. Il suffit de taper, dans le serveur virtuel, la commande :

cat /proc/user_beancounters

et vous obtiendrez quelque chose comme ceci :

Version: 2.5
       uid  resource           held    maxheld    barrier      limit    failcnt
      123:  kmemsize        2037156    3051143   14745600   16220160          0
            lockedpages           0          0        128        128          0
            privvmpages       41123      48516     196608     216269          0
            shmpages             16        672      65536      65536          0
            dummy                 0          0          0          0          0
            numproc              26         44        300        300          0
            physpages         12380      13650          0 2147483647          0
            vmguarpages           0          0      65536 2147483647          0
            oomguarpages      12380      13650      65536 2147483647          0
            numtcpsock            4          6        300        300          0
            numflock              4          5        300        330          0
            numpty                0          0         16         16          0
            numsiginfo            0          2        256        256          0
            tcpsndbuf         35712     100440    1228800    1996800          0
            tcprcvbuf         65536      65536    1228800    1996800          0
            othersockbuf       6696     145024     460800    1228800          0
            dgramrcvbuf           0       2416      36000      36000          0
            numothersock          5         13        300        300          0
            dcachesize       154550     211874    4423680    4866048          0
            numfile             689        973       7500       7500          0
            dummy                 0          0          0          0          0
            dummy                 0          0          0          0          0
            dummy                 0          0          0          0          0
            numiptent            10         10        128        128          0

On retrouve ici l’ensemble des paramètres UBC avec, pour chaque paramètre, 5 colonnes qui sont :

• la quantité de ressources détenue à cet instant
• la quantité maximale de ressources atteinte sur ce serveur virtuel
• la valeur « barrier »
• la valeur « limit »
• le nombre de fois ou la limite a été atteinte

Si vous aviez exécuté cette commande dans le serveur hôte, vous auriez obtenu autant de fois ce tableau que de serveurs virtuels, ainsi qu’un tableau supplémentaire, ayant un VEID à 0, qui correspond aux ressources du serveur physique.

Cette commande vous permet de constater si la valeur de la colonne maxheld s’approche des valeurs barrier ou limit, ce qui signifie qu’il faudra peut-être faire quelque chose pour votre serveur virtuel. Enfin, si la valeur failcount est supérieure à 0, cela signifie que votre serveur virtuel a déjà atteint les limites qui lui sont imposées et qu’il est probable que les applications qu’il héberge aient rencontré des erreurs.

C’est tout pour cette fois. J’espère que cette présentation des paramètres de gestion des ressources d’OpenVZ et que l’outil pour se simplifier la vie que je vous propose vous servira. Si vous vous en servez ou si vous pensez qu’il faut y corriger quelque chose, j’apprécierais que vous me teniez informé. Merci.

Dans un prochain article je poursuivrai ce tutoriel sur OpenVZ par une présentation des différentes formes de configuration du réseau dans les serveurs virtuels.