OpenVZ evaluation

Mail de @DavidRamblewski
lundi 12 septembre 2011
par  Olivier Duquesne aka DaffyDuke
popularité : 5%

Rappel sur les différentes techniques de Virtualisation

Machines Virtuelles (VM)

Les machines virtuelles émulent les ressources hardware du serveur réel. Cette émulation entraîne un surcoût de ressources (VMM, instructions CPU privilégiées supplémentaires etc...) mais permet d’acueillir des OS invités sans les modifier puisqu’ils ne se rendent pas compte qu’ils fonctionnent sur un environnement émulé.

Solutions : VMware, QEMU, Microsoft Virtual Server

Paravirtualisation

Cette technique requiert une VMM (voir mon draft sur KVM pour plus de détails) et nécessite de porter les guests OS. Cela engendre un surcoût d’administration mais c’est fiable, sécurisé et cela offre les meillleures performances à l’heure actuelle.

Solutions : XEN, UML

OS Level Virtualisation

Cette dernière technique consiste à considérer un système comme une application à part entière. Le principe est de créer plusieurs instances d’un même guest OS sur un seul et unique OS hyperviseur. Ce dernier est un OS modifié en charge d’administrer, d’isoler et de sécuriser les guests. La contrainte est que les guests OS doivent être identiques, à savoir Linux/Linux dans notre cas.

Solutions : OpenVZ, Virtuozzo, Linux-VServer, Solaris Zones, FreeBSD Jails

La technique de virtualisation la plus performante est XEN. Néanmoins, il semblerait qu’OpenVZ entraîne une perte de performance de 1 à 3%, ce qui est acceptable. Nous allons donc étudier cette solution selon les critères qui nous semblent pertinents (stabilité, performance, administration, industrialisation etc...)

OpenVZ

Vocabulaire

 VE (Virtual Environment) : Un VE peut être un guest OS ou le serveur lui-même (hyperviseur). C’est un système d’exploitation à part entière.
 VE0 : Environnement Virtuel maître (hyperviseur)

Le VE0 est utilisé pour administrer les VEs (processus, fichiers etc...), gérer le hardware ou encore upgrader le kernel. Le VE0 peut accéder aux VEs, la réciproque n’est pas vraie.

Installation

Création du kernel hyperviseur

Il est nécessaire d’appliquer un patch au kernel hyperviseur. Pour le moment seul un patch 2.6.18 est stable, 2.6.20 et 2.6.22 sont encore en développement.

La conf grub est standard.

Une fois le kernel compilé, installé et le bootloader modifié on reboot.

Ensuite, les paramètres sysctl à appliquer sont les suivants :

On load les modules qui vont bien :

Outils indispensables

Les outils suivants sont nécessaires à l’utilisation d’OpenVZ.

 vzctl : Permet l’administration des VEs (création/destruction, démarrage/arrêt, paramétrage etc...)
 vzquota : Permet la gestion des quotas par VE

Configuration

Tout est ici :

Modification des variables suivantes :

Par défaut, les arborescences des VEs, les templates de configurations etc... se situent ici :

J’ai crée ici 2 templates (lfslc1 et lfslc4) :

Administration

Création d’un VE

Cette commande effectue principalement les actions suivantes :

 Lecture des fichiers de configuration par défaut :

 Vérifie l’existence du template spécifié pour la création :

 Création du fichier de configuration correspondant au VE 113 :

 Vérifie que la partition cible dispose de l’espace disque nécessaire à la création du VE 113 puis crée le VE :

Destruction d’un VE

Démarrage d’un VE

Arrêt d’un VE

Liste des VEs

Entrer/Sortir d’un VE

Configuration du réseau

OpenVZ propose 2 types d’interfaces réseaux : venetet veth. Nous utiliseront vethpour la souplesse d’implémentation.

Le bonding est configuré de la sorte :

Configuration d’une interface réseau virtuelle

Dans ce mode, nous utilisons du source routing et il n’est pas utile de spécifier une adresse MAC pour les VE.

Configuration d’un interface ethernet virtuelle

Le VE doit être démarré :

Le module kernel suivant doit être chargé :

On configure le réseau du VE depuis VE0 en sauvegardant la conficguration :

On configure les interfaces réseaux du VE0 de la sorte :

Le routage :

Puis le VE :

Depuis VE0 vers VE et inversement, les transferts réseaux ne sont pas fiables, il y a des pertes de paquets à cause d’un mauvaise propagation/réponses ARP. Ce phénomène ne se produit pas quedans le cas VE0 <-> VE.

Ajout des interfaces ethernet virtuelle dans un bridge

Création du bridge :

Ajout des interfaces VE dans le bridge :

Configuration du bridge :

Ajout des informations de routage :

Configuration bridge + vlan

On configure les vlans sur le VE0. (VLANID + TYPE)

La configuration des interfaces dans le VE est standard. Si l’on ne souhaite pas avoir d’IPs dans le domaine VE0 associés à chacun des VLANS, il suffit de les supprimer puis de remettre en place le routage.

Une autre configuration est possible, cette fois on associe les IPs du VE0 au bridge puis on ajoute les interfaces des VE et du VE0 dans le bridge. Cette configuration est la meilleure possible, elle fonctionne dans tous les cas, les VE0 peuvent communiquer avec les VE sans problème.

Aucune règle spécifique de routage n’est nécessaire :

Les IPs sont montées sur les bridge :

Il est aussi possible de ne pas monter d’IPs sur les bridge.

Configuration de keepalived

Les VEs sont des ’jails’ améliorées, par conséquence il n’est pas possible d’accéder aux modules kernel depuis ces instances. La seule solution est de créer un keepalived depuis le VE0 puis de load-balancer sur les instances VE. La configuration réseau à retenir est d’associer les IPs du VE0 directement au bridge comme précisé ci-dessus.

Configuration d’IPtables

IPtables fonctionne parfaitement et indépendamment sur chacun des VE0 et VEs.