OpenVZ - Définition

Introduction

OpenVZ
Développeur	Andrey Savochkin
Dernière version	3.0 (avril 2006) [+/−]
Environnement	Linux
Type	Virtualisation
Licence	GNU/GPL
Site Web	OpenVZ.org
modifier

OpenVZ est une technique de virtualisation de niveau système d'exploitation basée sur le noyau Linux. OpenVZ permet à un serveur physique d'exécuter de multiples instances de systèmes d'exploitation isolés, connus sous le nom de serveurs privés virtuels (VPS) ou environnements virtuels (VE).

En comparaison aux machines virtuelles telles que VMware et aux techniques de paravirtualisation telles que Xen, OpenVZ offre moins de flexibilité dans le choix du système d'exploitation : le système d'exploitation invité et hôte doivent être de type Linux (bien que les distributions de Linux peuvent être différentes dans des VEs différents). Cependant, la virtualisation au niveau OS d'OpenVZ offre une meilleure performance, une meilleure scalabilité (i.e. évolution), une meilleure densité, une meilleure gestion de ressource dynamique, et une meilleure facilité d'administration que ses alternatives. Selon le site Web d'OpenVZ, cette méthode de virtualisation introduirait une très faible pénalité sur les performances : 1 à 3% de pertes seulement par rapport à un ordinateur physique.

OpenVZ est la base de Virtuozzo, un produit propriétaire fourni par SWsoft, Inc. OpenVZ est distribué sous la Licence publique générale GNU version 2.

OpenVZ comprend le noyau Linux et un jeu de commandes utilisateurs.

Noyau

Le noyau d'OpenVZ est un noyau Linux modifié qui ajoute la notion d'environnement virtuel. Le noyau fournit la virtualisation, l'isolement, la gestion de ressource, et le checkpoint/restart.

Virtualisation et isolement

Un VE est une entité séparée, et du point de vue de son propriétaire, il ressemble à un vrai serveur physique. Chaque VE a ses propres :

Fichiers

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

Utilisateurs et groupes

Chaque VE a son propre utilisateur root, ainsi que ses propres utilisateurs et groupes.

Arborescence de processus

Chaque VE voit seulement ses propres processus (à partir de l'init). Les Identifiant de processus (PID) sont virtualisés, de telle sorte que le PID de la tâche init est 1, tel qu'il devrait l'être.

Réseau

Interface réseau virtuelle, qui permet à un VE d'avoir ses propres adresses IP, aussi bien qu'un ensemble de règles Netfilter (iptables) et de routage.

Périphériques

Si nécessaire, on peut accorder à n'importe quel VE l'accès à de vrais périphériques comme 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.

Gestion des ressources

Comme tous les VEs 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 VEs.

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 approche de virtualisation telles que la VM ou l'hyperviseur.

Quotas disque à deux niveaux

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).

Scheduler Fair CPU

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 VEs 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.

Beancounters Utilisateur

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.

Checkpointing et migration live

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 VEs sur un autre serveur, vous arrêtez le premier, ajoutez la mémoire, puis rebootez et remigrez tous les VEs.