L’Imp’Rock Scénette (by @_daffyduke_)
Logiciel libre, rock’n roll et biochimie ...
OpenVZ evaluation Mail de @DavidRamblewski
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.