OpenVZ

Un environnement virtuel est une entité séparée et cloisonnée. Du point de vue de son propriétaire, il ressemble à un vrai serveur physique. Il possède en propre :

Fichiers

Sont virtualisés : les bibliothèques système, applications, /proc et /sys, les verrous, etc.

Utilisateurs et groupes

Chaque Environnement Virtuel a son propre compte système "root", ainsi que ses propres utilisateurs et groupes.

Arborescence de processus

Chaque Environnement Virtuel voit seulement ses propres processus (à partir de l'init). Les Identifiants de processus (PID) sont virtualisés, de telle sorte que l'identifiant « PID » de la tâche init soit 1, conformément à l'habitude.

Réseau

L'interface réseau virtuelle permet à un Environnement Virtuel d'avoir ses propres adresses IP, aussi bien qu'un ensemble de règles pare-feu Netfilter (iptables) et de routage.

Périphériques

Si nécessaire, on peut accorder à n'importe quel Environnement Virtuel l'accès à de vrais périphériques tels que des interfaces réseau, des ports séries, des partitions de disque, etc.

IPC

Mémoire partagée, sémaphores, file d'attente de messages.

Comme tous les VE utilisent le même noyau, la gestion des ressources est d'importance primordiale. Chaque VE doit rester dans ses limites et ne pas affecter d'autres VE.

La gestion des ressources d'OpenVZ est composée des trois éléments suivants : des quotas disque à deux niveaux, un scheduler fair CPU, et des beancounters utilisateurs. Toutes ces ressources peuvent être modifiées pendant le temps d'exécution d'un VE, sans avoir à rebooter. Il est par exemple possible d'allouer à chaud plus de mémoire à un VE, en changeant des paramètres appropriés à la volée. C'est une fonctionnalité souvent impossible ou complexe avec d'autres approches de virtualisation telles que la VM ou l'hyperviseur.

L'utilisateur root du système hôte (OpenVZ) peut établir des quotas disque par VE, spécifiés en termes de bloc disque et d'inode (plus ou moins le nombre de fichiers). C'est le premier niveau des quotas disque. En plus de ceux-ci, un propriétaire de VE (utilisateur root) peut utiliser les outils habituels de gestions des quotas à l'intérieur de son propre VE pour placer des quotas disque standards par utilisateur et par groupe d'UNIX.

Il est possible d'allouer dynamiquement de l'espace disque à un VE, en modifiant simplement son quota disque (autrement dit, sans qu'il soit nécessaire de redimensionner les partitions du disque).

Le scheduler CPU d'OpenVZ est également à deux niveaux. Au premier niveau, le scheduler décide à quel VE le time slice sera affecté, basé sur des cpuunits par VE. Au deuxième niveau, le scheduler standard Linux décide quel processus s'exécutera dans le VE, en utilisant les priorités de processus standards.

L'administrateur d'OpenVZ peut établir différentes valeurs des cpuunits pour des VE différent, et le temps CPU sera donné à ceux-ci proportionnellement.

Il est en outre possible de limiter le temps CPU, par exemple à 10 % de temps CPU disponible.

Les Beancounters utilisateur sont un ensemble de compteurs, de limites, et de garanties par VE. Environ 20 paramètres, soigneusement choisis, couvrent tous les aspects des opérations d'un VE ; ainsi, aucun VE ne peut abuser d'une ressource qui est limitée pour le nœud entier et de cette façon nuire à un autre VE.

Les ressources comptabilisées et contrôlées sont principalement la mémoire et divers objets noyau tels que les segments de mémoire partagés, les buffers réseau, etc. Chaque ressource peut être vue depuis /proc/user_beancounters et cinq valeurs lui sont associées : utilisation courante, utilisation maximum (pour la vie d'un VE), barrière, limite, et compteur d'échec. La signification de la barrière et de la limite est dépendante du paramètre ; en bref, ceux-ci peuvent être considérés comme une limite soft et une limite hard. Si n'importe quelle ressource atteint la limite, le compteur d'échec est incrémenté, ainsi le propriétaire du VE peut voir si quelque chose de néfaste se produit en analysant la sortie de /proc/user_beancounters dans son VE.

La fonctionnalité de migration live et de checkpoint pour OpenVZ a été annoncé au milieu d'avril 2006. Elle permet de migrer un VE d'un serveur physique à un autre sans arrêt/relance du VE. Ce processus est connu comme application checkpointing : le VE est gelé et son état entier est sauvegardé dans un fichier sur disque. Ce fichier peut alors être transféré sur une autre machine sur laquelle le VE pourra être restauré. Le délai de migration est de quelques secondes, et ce n'est pas un temps d'arrêt, juste un retard.

Chaque morceau d'état de VE, y compris les connexions de réseau ouvertes, est sauvé. De la perspective de l'utilisateur, cela ressemble à un retard dans la réponse : une transaction de base de données prendra un peu plus longtemps que d'habitude, quand le VE redémarre, l'utilisateur ne note pas que sa base de données fonctionne déjà sur une autre machine.

Cette fonctionnalité rend possible des scénarios tels que la mise à jour du serveur sans avoir besoin de le rebooter : si votre base de données a besoin de plus de mémoire ou de CPU, vous achetez un nouveau serveur, migrez votre VE dessus et vous augmentez ensuite ses limites. Si vous voulez ajouter plus de RAM à votre serveur, vous migrez tous les VE sur un autre serveur, vous arrêtez le premier, ajoutez la mémoire, puis rebootez et remigrez tous les VE.

C'est un outil en ligne de commande simple pour contrôler un VE.

vzctl create VEID [--ostemplate <name>] [--config <name>]

Cette commande crée un nouvel environnement virtuel avec l'identification numérique de VEID, qui sera basé sur un template d'OS (un distro de Linux) et qui aura des paramètres de gestion de ressource pris dans le fichier de configuration spécifié en ligne de commande. Les deux paramètres --ostemplate et --config sont facultatifs, il existe des valeurs par défaut définies dans fichier global de configuration.

vzctl start VEID

Démarre un VE donné, ce qui signifie créer un contexte virtuel d'environnement dans le noyau, en plaçant tous les paramètres de gestion de ressource et démarrer le /sbin/init du VE dans ce contexte.

vzctl stop VEID

Arrête un VE donné. Un VE peut également être arrêté (ou rebooté) par son propriétaire en employant les commandes standards /sbin/halt ou /sbin/reboot.

vzctl exec VEID <command>

Exécute une commande à l'intérieur d'un VE. Pour voir la liste des processus à l'intérieur du VE 102, il suffit de lancer la commande vzctl exec 102 ps ax.

vzctl enter VEID

Ouvrir un shell VE. C'est utile si par exemple le sshd est mort dans ce VE et vous voulez le dépanner.

vzctl set VEID --parameter <value> [...] [--save]

Affecte un paramètre pour un VE. Il y a beaucoup de différents paramètres. Pour ajouter une adresse IP à un VE, lancez vzctl set VEID --ipadd x.x.x.x --save. Pour changer le quota disque d'un VE, lancez vzctl set VEID --diskspace soft:hard --save. Pour fixer la barrière et la limite de mémoire noyau d'un VE, lancez vzctl set VEID --kmemsize barrier:limit --save.

Les templates (en français : gabarit) sont des images précréées utilisées pour créer un nouveau VE. Globalement, un template est un ensemble de packages, et un template cache est un tarball d'un environnement chrooté avec ces packages installés. Pendant l'étape de création vzctl, un tarball est déballé. En utilisant la technique template cache, un nouveau VE peut être créé en quelques secondes.

Les outils vzpkg sont un ensemble d'outils facilitant la création de template cache. Ils supportent actuellement rpm et les repositories de type yum. Ainsi, pour créer un template, par exemple, de distribution de Fedora Core 5, vous devez indiquer un ensemble repository (yum) qui ont les rpm FC5, et un ensemble de rpm à installer. De plus, des scripts de pre- et post-install peut être utilisés pour optimiser ou modifier un templace cache. Toutes les données ci-dessus (les repositories, listes de paquets, les scripts, clefs GPG etc.) forment un template metadata. Un template cache peut être créé automatiquement à partir d'un template metadata; vous lancez juste l'utilitaire vzpkgcache. le vzpkgcache téléchargera et installera les packages énumérés sur un VE provisoire, et emballera le résultat comme un template cache.

Des template cache pour les distros non-RPM peuvent aussi être créées, bien que ce soit plus un processus manuel. Par exemple, ce HOWTO donne des instructions détaillées pour créer un template cache de Debian.

Les template cache suivants (a.k.a. templates precréés) sont actuellement (mai 2006) disponibles :

• dans les dérivés de Red Hat
  • Fedora Core Version 5 (et les versions précédentes : 3 et 4)
  • CentOS 4 (4.3)
• Gentoo 2006.0 (20060317)
• openSUSE 10
• Debian Sarge et Etch télécharger
• Ubuntu

Comme OpenVZ utilise un modèle de noyau unique, il se comporte comme le noyau 2.6 de Linux, ce qui signifie qu'il supporte jusqu'à 64 processeurs et jusqu'à 64 gigaoctets de mémoire vive. Un environnement virtuel unique peut être étendu jusqu'à la machine physique dans sa totalité, c'est-à-dire tous les CPU et toute la RAM.

En effet, certains déploient un unique environnement virtuel OpenVZ. C'est étrange à première vue, mais étant donné qu'un VE unique peut employer toutes les ressources matérielles avec une performance proche du natif, tout en bénéficiant d'autres avantages tels que l'indépendance du matériel, la gestion des ressources et la migration à chaud, ceci est un choix évident dans beaucoup de scénarios.

OpenVZ density on a 768Mb (¾Gb) RAM box

OpenVZ peut accueillir des centaines d'environnements virtuels sur un matériel décent (les limitations principales sont la quantité de mémoire vive et le nombre de processeurs).

Le graphique montre la relation du temps de réponse du serveur web Apache dans un VE sur le nombre de VE. Les mesures ont été faites sur une machine avec 768 Mo (¾ Gb) de RAM ; chaque VE faisait tourner l'ensemble habituel de processus : init, syslogd, crond, sshd et apache. Les daemons d'Apache servaient des pages statiques, qui étaient chargées par le http_load, et le premier temps de réponse était mesuré. Comme vous pouvez le voir, plus le nombre de VE se développe, plus le temps de réponse se dégrade en raison du manque de mémoire et du swap excessif.

Dans ce scénario, il est possible de faire tourner jusqu'à 120 VE sur une machine avec ¾ Go de RAM. Ceci s'extrapole de façon linéaire, et il est donc possible de faire tourner jusqu'à près 320 VE sur une machine avec 2 Gb de RAM.

Un propriétaire (root) du serveur physique OpenVZ (également connu sous le nom de nœud matériel) peut voir tous les processus et les fichiers des VE. Ceci permet de faire de la gestion de masse. Ainsi, par exemple, vous pouvez faire tourner un simple script qui mettra à jour tous les (ou juste certains choisis) VE immédiatement.