Dans ce tutoriel je vais présenter comment mettre en oeuvre une architecture cluster haute disponibilité, à base de serveurs Debian dont le but est de constituer une plate-forme matérielle tolérante aux pannes pour héberger des machines virtuelles OpenVZ ou KVM.

Quel est le but recherché ?

Il s’agit de créer un groupe de serveurs pouvant exécuter des machines virtuelles de type OpenVZ ou KVM, organisés au sein d’une architecture matérielle permettant à ces machines virtuelles d’être exécutées par n’importe lequel de ces serveurs (mais une machine virtuelle ne s’exécute que sur un seul à la fois) et d’être déplacées d’un serveur à un autre aussi rapidement que possible, de manière à ce qu’en cas de panne d’un serveur, les machines virtuelles qu’exécutait le serveur défaillant puissent être instantanément relancées sur les autres serveurs du cluster. La faculté du cluster à permettre de déplacer instantanément les machines virtuelles d’un serveur à un autre constitue par ailleurs un énorme avantage pour l’administrateur système qui a en charge la maintenance des serveurs physiques et virtuels.

Ce type d’architecture est qualifiée de « haute disponibilité » en raison de sa grande tolérance aux pannes. En effet, il n’existe pas de point individuel de défaillance dans cette architecture, car tous les équipements et composants sont redondants.

En complément de la faculté du cluster à permettre la récupération rapide des services d’un serveur défaillant, il est possible d’installer, sur les serveurs physiques, un logiciel de gestion de cluster dont la fonction est de superviser le bon fonctionnement de ces derniers, et d’automatiser les actions de relance des services lorsqu’un serveur est défaillant. Un tel logiciel permet de relancer encore plus rapidement les services tombés en même temps que le serveur défaillant, car il ne nécessite pas d’intervention humaine. Je n’aborderai cependant pas cet aspect dans cet article. En effet, après avoir qualifié architectures matérielles et logicielles différentes et administré plusieurs clusters différents au cours de ces 10 dernières années, il se trouve que la solution qui convient le mieux à mes besoins n’utilise pas un tel logiciel. En outre, les deux logiciels de ce type que j’ai été amené à utiliser, SGI Failsafe et Redhat Cluster m’ont davantage posé de problèmes (déclenchements intempestifs, prises de décisions inadaptées…) qu’apporté une assistance lors de pannes. C’est pourquoi j’ai préféré m’en passer, du moins pour ce cluster.

L’architecture obtenue est décrite dans le schéma ci-dessous :

Architecture haute disponibilité pour l'hébergement de machines virtuelles OpenVZ et KVM

Dans ce schéma, seuls deux liens Fiber Channel et deux liens ethernet sont représentés, mais évidemment, c’est chaque serveur qui doit disposer de deux liens FC et deux liens ethernet.

Quels matériels faut-il ?

Pour mettre en oeuvre un tel cluster, il faut les matériels suivants :

• au moins deux serveurs physiques, comportant chacun deux ports Fiber Channel (sous la forme de 2 cartes x 1 port, ou 1 carte x 2 ports), deux cartes réseau (les serveurs récents ont tous au moins deux ports ethernet). Il est possible de batir la même architecture avec un SAN de type ISCSI au lieu de Fiber Channel, auquel cas les serveurs devront plutôt comporter 4 ports ethernet.
• deux switches Fiber Channel (ou deux switches ethernet configurés pour Jumbo Frames si SAN de type ISCSI)
• au moins une baie de disques Fiber Channel (ou ISCSI)

Les contraintes de mise en oeuvre sont les suivantes :

• Les machines virtuelles doivent être intégralement stockées dans une baie de disques externe aux serveurs, de sorte qu’en panne d’un serveur, un autre puisse immédiatement relancer les services que rendait le premier.
• Les serveurs peuvent être matériellement différents, mais aucun ne doit être particulier, afin qu’ils restent interchangeables. Ils doivent être configurés tous de la même façon, et ne doivent pas fournir un service qui ne soit pas virtualisé ou qui ne soit pas stocké dans une baie de disques.
• Tout ce qui est dans la baie de disques doit être redondant (alimentations, contrôleurs, connectique) et les disques configurés en RAID. Selon vos besoins de sécurité et de performance vous pourrez opter pour le niveau de RAID le plus adapté. Après avoir fonctionné un moment en RAID 5, j’ai rencontré des problèmes de performances j’utilise depuis le RAID 10.
• Je n’utilise pas de système de fichiers permettant des accès concurrents depuis plusieurs serveurs, tel que OCFS ou GFS. Après avoir qualifié ces deux systèmes de fichiers (certes, c’était en 2005 ou 2006), j’en étais arrivé à la conclusion que OCFS était performant mais incomplet (pas de support des ACL dont j’avais besoin) et que GFS était un monstre de lenteur. En outre, pour avoir déjà eu à faire des vérifications de système de fichiers (fsck) je suis un peu réticent à l’idée de mettre « tous mes oeufs dans le même panier », c’est pourquoi je n’ai pas essayé de nouvelles versions depuis. Cela implique que chaque machine virtuelle est stockée dans un volume virtuel de la baie de disque qui lui est dédié, et qui est partitionné et formaté (en ext4).
• L’accès au SAN par les serveurs peut se faire par deux chemins différents, redondants l’un de l’autre. Chaque chemin passe par un switch SAN différent et aboutit sur un contrpoleur différent de la baie de disques. Les volumes sont présentés par la baie de disques sur chaque contrôleur, ce qui implique que les serveurs voient les volumes deux fois, mais avec le même WWNN. La couche logicielle « multipath » permet au système d’exploitation de gérer cette redondance d’accès automatiquement. Suivant le mode de fonctionnement des contrôleurs des baies de disques, les deux ports Fiber Channel peuvent soit fonctionner en mode actif/passif ou actif/actif. Cependant, chaque volume aura un chemin actif et un chemin passif.
• Les cartes réseau des serveurs sont agrégées (bonding) en mode actif/passif et reliées a deux switches ethernet différents, configurés avec le spanning tree activé. Cela autorise la défaillance « transparente » d’un switch ethernet. La configuration des switches n’est pas abordée dans ce tutoriel.

Installation

La documentation d’installation de ce cluster est disponible dans les articles suivants (wiki) :

Voici un article dans lequel je décris le VPN que j’ai mis en oeuvre.

Il s’agit de répondre à un contexte qui est le suivant :

• environ 70 sites distants, faiblement peuplés (5 à 50 utilisateurs) à interconnecter à des sites centraux dans lesquels se trouvent la majorité des ressources informatiques
• le VPN doit fournir une disponibilité importante, et doit être tolérant à la panne d’un serveur ou d’une ligne sur les sites centraux, c’est à dire on peut accepter de « perdre » un site distant momentanément, mais pas tous à la fois => pas de point central unique d’interconnexion
• il doit être possible de filtrer le trafic par un firewall
• il doit être possible de prioriser le trafic
• il doit être maintenable par des personnels « réseau » n’ayant pas de compétence en administration système
• il ne doit pas être dépendant d’un unique fournisseur de réseau => passage par internet
• évidemment, le trafic doit être chiffré pour en assurer la confidentialité
• et comme toujours, aussi économique que possible

Après consultation de l’opérateur historique, ce dernier nous proposait une offre de VPN MPLS (Multi Protocol Label Switching) « tout compris », lignes, routeurs, maintenance, configuration, etc, mais j’ai conseillé mon entrteprise de ne pas retenir cette solution qui ne m’a pas convaincu pour diverses raisons techniques que je n’exposerai pas ici, c’est hors de propos.

Je résumerai simplement en disant que le résultat que j’ai obtenu en configurant un VPN par moi même, tel que décrit dans ce tutoriel, est supérieur à la solution qui nous avait été proposé en bien des points :

• possibilité d’exploiter des lignes ADSL de tout type, et de profiter des meilleurs prix
• possibilité de mixer les fournisseurs de réseau
• davantage de fonctionnalités sur les routeurs (qos et firewall partout) et possibilité de prendre la main sur les routeurs, ce qui est très appréciable pour faire certains diagnostics à distance
• et 70 % moins cher chaque année, ce qui se traduit par une économie d’environ 100 000 € par an dans notre cas

En quelques mots, le VPN ainsi conçu s’appuie :

• des serveurs centraux, qui font office de routeur, sous Debian, avec OpenVPN pour la partie VPN et Quagga pour gérer OSPF, nécessaire au routage
• des routeurs distants Linksys WRT54GL équipés d’un firmware OpenWRT spécifiquement conçu pour mes besoins, incluant notamment OpenVPN, des outils de QOS, des fonctions de firewall avec iptables, la possibilité d’analyser le trafic avec tcpdump…
• un Builder OpenWRT compilé spécifiquement pour permettre de produire à la demande des firmwares spécifiques des sites distants à équiper
• des lignes xDSL, mais on peut tout aussi bien utiliser n’importe quel type de lien IP

Je suis conscient que le tutoriel est un peu « brut de décoffrage ». Initialement, je voulais le commenter davantage, expliquer beaucoup plus les diverses portions de configuration, de telle façon que celui qui souhaiterait s’en inspirer sache le pourquoi de tel ou tel choix. Mais cela fait longtemps que je ne trouve pas le temps de le faire, alors je préfère le sortir à peu près tel quel. Il se trouvera peut-être un courageux pour l’utiliser, et pourquoi pas l’améliorer. Du coup, les versions de logiciels cités dans le guide sont un peu anciennes, mais cela ne change pas le principe de fonctionnement.

La suite du tutoriel est dans le wiki : http://www.libresys.fr/wiki/doku.php/reseau à la section VPN Intranet.

Bonne lecture, et n’hésitez pas à me faire part de vos éventuels commentaires ou remarques.

Il ne s’agit pas un ensemble de règles absolues de bonnes pratiques qu’il est possible de transposer dans tous les cas.

D’abord, parce que dans les principes suivants je privilégie la fiabilité et la stabilité du système d’information et la simplicité d’administration des serveurs, parfois au détriment de l’optimisation des performances et de la consommation des ressources physiques, que je relègue au second plan. Mes priorités ne seront probablement pas les mêmes que les votres.

Ensuite, parce qu’il y a une part de subjectivité dans les choix que je peux faire lorsqu’il s’agit de réunir au sein d’un même serveur virtuel les différents composants nécessaires au bon fonctionnement d’un service, ou au contraire de les répartir sur plusieurs serveurs virtuels.

Ceci étant dit, je vais essayer de décrire en quelques « règles » la façon dont je m’y prends pour organiser la répartition des services en serveurs virtuels.

1. Si je peux installer un service dans un serveur virtuel, je le fais. Il s’agit d’éviter autant que possible d’installer des logiciels directement sur un serveur physique. En effet, le temps passé, parfois sur plusieurs années, à peaufiner le bon fonctionnement d’un service est trop précieux pour risquer de devoir le passer à nouveau lorsque vient le moment de remplacer un serveur en fin de vie et qu’il faut réinstaller le système puis les logiciels, etc…
2. 1 service = 1 serveur virtuel. Lorsque deux services sont indépendants je les installe dans deux serveurs virtuels différents car il est important de préserver cette indépendance entres les services. Je veux notamment pouvoir arrêter ou faire évoluer un serveur sans impacter plus que nécessaire. Différemment, si deux services A et B à priori indépendants se trouvaient dans le même serveur virtuel, une intervention ultérieure sur le serveur nécessaire pour un service pourrait avoir des incidences pour l’autre service.
3. Lorsque plusieurs composants sont nécessaires au bon fonctionnement d’un service je les installe sur le même serveur virtuel. Par exemple, j’installe une application et son serveur de base de données sur le même serveur virtuel.

Dans certains cas les règles 2 et 3 pourront sembler en opposition. Je prends l’exemple simple d’une application Java/Tomcat qui, pour fonctionner, a besoin d’un serveur LDAP pour authentifier les utilisateurs et d’un serveur MySQL pour stocker ses données.

Considérons le serveur LDAP. Par sa nature, il est vraisemblablement utilisé (ou sera utilisé) par plusieurs autres applications. Aussi, il est préférable de l’installer sur un serveur virtuel dédié, afin de ne pas rendre les autres applications dépendantes du serveur de l’application A. Si en revanche, il est certain qu’il n’est utile qu’à cette application et ne doit jamais être utilisé par un autre service réseau, alors je l’installe sur le même serveur virtuel que l’application.

Considérons le serveur MySQL. S’agissant des données de l’application, j’installe le serveur MySQL dans le même serveur virtuel que l’application. Il serait évidemment possible d’utiliser un serveur MySQL distant pour y installer les bases de plusieurs applications, mais dans ce cas on rendrait les serveurs virtuels hébergeant les applications dépendants du serveur virtuel hébergeant MySQL. Aussi je préfère multiplier les serveurs de bases de données, quitte à ce que ces derniers n’hébergent qu’une seule base.

Sur la base de ce cet exemple, j’utiliserais deux serveurs virtuels : un pour LDAP, un pour l’application Java/Tomcat + MySQL.

Ces quelques « règles » présentent l’avantage d’isoler correctement les services réseau et les applications et de simplifier la maintenance globale des serveurs.

Il est malgré tout parfois nécessaire d’y faire des entorses. Par exemple, j’utilise aussi un serveur Oracle comme serveur de base de données. Dans ce cas, les restrictions imposées par la licence d’utilisation m’empêchent d’installer autant de serveurs que je voudrais et à mettre plusieurs bases sur le même serveur… même si quelle que soit la répartition le nombre de bases de données et l’utilisation qui en est faite sont les mêmes.

A présent que la base de la création et de la gestion de serveurs virtuels OpenVZ est posée, nous allons nous pencher sur une possibilité très intéressante offerte par OpenVZ : le checkpointing. Nous verrons également comment cette fonctionnalité peut aider l’administrateur système à gérer des aspects qu’il ne doit pas négliger, à savoir, la sauvegarde et la restauration des serveurs, et le déplacement des services logiciels d’un serveur physique à un autre, par exemple lors du remplacement d’un matériel vieillissant.

Checkpointing de serveur virtuel

Dans la terminologie OpenVZ, le checkpointing consiste à demander, depuis le serveur physique, à figer l’état d’un serveur virtuel et à stocker cet état dans un fichier. Ce fichier contient ainsi les processus qu’exécutait le serveur virtuel et l’état de leur mémoire au moment du checkpoint. En revanche, il ne contient pas les fichiers de l’arborescence du serveur virtuel, ce qui rend le checkpoint rapide à réaliser (à peine quelques secondes).

Lorsque qu’un serveur a subi un checkpoint, il est retiré de la liste des serveurs en cours d’exécution : la commande vzlist ne le montre plus.

Ce fichier de checkpoint peut par la suite être utilisé pour restaurer le serveur exactement dans l’état dans lequel il avait été figé. Du point de vue du serveur virtuel restauré, c’est comme s’il ne s’était rien passé hormis un bond en avant dans le temps puisque les processus n’auront pas « vu passer » les secondes pendant lesquelles le serveur était figé. Si des clients étaient connectés par le réseau au serveur, et que le temps pendant lequel le serveur est figé est inférieur aux durées de timeout des connexion tcp, alors les clients ne s’apercevront de rien, ou guère plus que si le cordon réseau avait été débranché pendant quelques secondes.

Pour réaliser un checkpoint du serveur virtuel n° 123 (supposé démarré), il suffit de taper la commande suivante (en précisant le chemin vers le fichier qui devra contenir le dump) :

vzctl chkpnt 123  --dumpfile /chemin/vers/123.dump

Vous pouvez contrôler avec vzlist qu’une fois le checkpoint réalisé le serveur n’est plus en fonctionnement.

Pour restaurer le serveur dans l’état dans lequel il était au moment du checkpoint, il suffit ensuite de taper la commande suivante :

vzctl restore 123  --dumpfile /chemin/vers/123.dump

Vous pouvez contrôler avec vzlist qu’une fois le checkpoint restauré le serveur est à nouveau en fonctionnement.

Vous pouvez faire le test en ayant pris soin au préalable de vous connecter par le réseau au serveur virtuel au moyen d’un client quelconque (par exemple un client ssh), et vous pourrez constater que votre connexion perdure jusqu’après la restauration du serveur virtuel.

(Live) Migration de serveur virtuel

Là où le checkpointing devient carrément magique, c’est qu’on peut faire un checkpoint d’un serveur virtuel sur un serveur physique et restaurer l’état de ce serveur sur un autre serveur physique !

Alors évidemment il faut prendre soin au préalable de s’assurer que l’autre serveur physique dispose des fichiers qui constituent l’arborescence du serveur virtuel, ainsi que du fichier de configuration openvz pour le serveur virtuel (dans /etc/vz/conf) avant de le relancer. En effet, comme je disais plus haut, le dump ne contient que l’état de la mémoire, et le simple transfert du dump d’un serveur à un autre n’est pas suffisant. Cependant, OpenVZ vient avec un outil intéressant qui permet d’automatiser la « migration » d’un serveur virtuel d’un serveur physique à un autre. Cet outil s’appelle vzmigrate.

vzmigrate permet de déplacer des serveurs virtuels d’un serveur physique à un autre. Il prend en charge la recopie vers le serveur cible de tout ce qui est nécessaire au serveur virtuel (arborescence et fichier de configuration) et peut déplacer les serveurs virtuels soit arrêtés, soit sans interruption de service, en utilisant le mécanisme de checkpointing décrit ci-dessus. Dans ce second cas vzmigrate déplace aussi le fichier de checkpointing réalisé sur le serveur d’origine.

vzmigrate s’appuie sur ssh et rsync pour transférer les données d’un serveur vers l’autre, et il faut au préalable avoir configuré le serveur cible pour qu’il accepte une connexion depuis le serveur source sans mot de passe.

Admettons que vous disposiez de deux serveurs physiques, nommés host1 et host2 capables d’exécuter des serveurs virtuels, installés, par exemple, comme décrit dans un précédent article, et que sur le serveur host1 s’exécute le serveur virtuel 123. Pour déplacer le serveur virtuel 123 du serveur host1 vers le serveur host2, il faut faire ceci :

• une bonne fois pour toutes, on créé une paire de clés sur le serveur host1 et on informe le serveur host2 qu’il doit accepter les connexions avec cette clé sans mot de passe  (c’est à faire sur host1 en tant que root)

ssh-keygen

ssh-copy-id -i ~/.ssh/id_rsa.pub root@host2

• ensuite, pour réaliser la migration du serveur virtuel 123 de host1 vers host2, il suffit de taper ceci pour faire la migration avec une interruption de service (arrêt sur host1 et marche sur host2)

vzmigrate host2 123

• ou ceci pour faire une migration « live », avec checkpointing sur host1 et reprise sur host2

vzmigrate --online host2 123

A noter qu’il est possible de passer d’autres options à vzmigrate, comme –remove-area=yes|no qui indique s’il faut supprimer les fichiers du serveur virtuel sur le serveur source en cas de succès, ou –keep-dst qui indique qu’il ne faut pas supprimer les fichiers du serveur cible en cas de problème pendant la migration. Cette dernière option permet de gagner du temps au moment d’une nouvelle tentative puisque certains fichiers auront déjà été transmis lors de la première.

Sauvegarde et restauration de serveur virtuel

Il est essentiel de savoir sauvegarder et restaurer un serveur et les des données qu’il contient, autant pour pouvoir répondre aux utilisateurs qui demandent régulièrement de récupérer le travail qu’ils ont perdu (oui je sais, c’est pas eux qui ont perdu les fichiers, ce sont les fichiers qui ont disparus tout seuls) que pour pouvoir récupérer un service perdu suite une panne ou un sinistre. Je vous propose plusieurs méthodes.

Méthode n°1 : avec un agent de sauvegarde

Bien entendu vous avez la possibilité de sauvegarder un serveur virtuel de la même manière que vous sauvegarderiez un serveur physique, par exemple, en y installant l’agent de sauvegarde de votre logiciel préféré. A titre d’exemple, j’utilise souvent le couple ssh et rsync pour exécuter des travaux sur les serveurs à sauvegarder et pour répliquer les données sur un serveur de sauvegarde. J’utilise aussi le logiciel bacula, qui fera l’objet d’un autre article.

Je ne détaillerai pas cette méthode car d’une part elle dépend du logiciel de sauvegarde et d’autre part c’est un peu hors sujet cela ne diffère pas de ce que l’on pourrait faire sans OpenVZ, pour sauvegarder un serveur physique. Sachez toutefois que vous devez exclure les répertoires /proc et /sys de votre sauvegarde puisqu’ils correspondent à des points de montage dans lesquels le noyau présente des informations relatives au système et aux processus en cours de fonctionnement.

Pour l’anecdote, les utilisateurs du logiciel de sauvegarde Time Navigator risquent d’être déçus car il refuse de fonctionner dans un serveur virtuel OpenVZ (au moins la version que j’avais). La faute en revient à la conception capricieuse du logiciel qui résulte, à mon avis, de la volonté de l’éditeur d’implanter dans son code des dispositifs de contrôle de licence. Le fait est que j’avais déjà eu toutes les peines du monde à faire fonctionner des agents de sauvegarde Time Navigator sur les serveurs physiques d’un cluster Red Hat malgré le support technique de l’éditeur, alors après quelques essais infructueux pour le faire tourner dans OpenVZ, j’ai préféré abandonner Time Navigator pour une autre solution : Bacula. Plus simple, moins pachydermique, et de mon point de vue, plus sûr en cas de pépin. Et, en prime ça fonctionne ! Mais j’y reviendrai dans un autre article.

Pour restaurer un serveur virtuel complet, à moins que votre logiciel de sauvegarde ne vous propose une autre solution, vous devrez recréer une nouvelle instance d’un serveur virtuel minimal, avec la même distribution qu’avant, installer l’agent de sauvegarde, et restaurer votre serveur virtuel par dessus via l’agent de sauvegarde.

Selon moi, cette méthode présente un avantage et un inconvénient majeurs :

• avantage : la sauvegarde peut souvent se faire sans interruption de service ; rien de spécial à faire pour sauvegarder un serveur de fichiers, on assure le coup pour un serveur de base de données en faisant un export des bases, et voila
• inconvénient : cette méthode ne suffit pas à garantir que la sauvegarde contient bien un serveur dans un état cohérent, et du coup la restauration d’un serveur physique peut avoir des effets inattendus. Par exemple, imaginons une application qui indexe des documents en s’appuyant sur une base de données, dans laquelle on trouve des enregistrements qui contiennent les noms des fichiers indexés. Imaginons que, pendant la durée de la sauvegarde, l’application reçoive un nouveau document à indéxer. Il est tout à fait possible que, dans ce cas, la base de données soit sauvegardée avant l’arrivée du nouveau document, et les fichiers après l’arrivée du nouveau document et que par conséquent, les fichiers de la sauvegarde contiennent un document de plus que ce qui est référencé dans la base. En cas de restauration de cette sauvegarde, le fait que le contenu de la base ne soit pas cohérent avec les fichiers peut poser un problème à l’application.

Lorsqu’on travaille sur un serveur physique, éviter ce type de problème suppose habituellement d’arrêter les applications/les services pendant la durée des sauvegardes. Cependant, cela provoque une interruption de service avec laquelle il est parfois difficile de composer.

Notez que ce problème est lié au fait que la sauvegarde est assurée par un agent de sauvegarde intégré au serveur sauvegardé, et qu’il se pose aussi bien pour un serveur physique qu’un serveur virtuel. Les autres méthodes de sauvegarde que je présente ci-après s’appuient sur OpenVZ et exploitent  les moyens de contrôle que le serveur physique peut exercer sur les serveurs virtuels qu’il héberge pour faciliter leur sauvegarde et leur restauration et éviter le problème d’incohérence de la sauvegarde.

Méthode n°2 : sauvegarde à froid

Je ne m’attarderai pas sur cette méthode. Il s’agit de procéder ainsi :

• arrêter le serveur virtuel,

• sauvegarder le serveur virtuel arrêté,

• redémarrer le serveur virtuel,

par exemple :

vzctl stop 123
tar cf backup_123.tar /var/lib/vz/private/123
vzctl start 123

Evidemment, on peut faire la sauvegarde par n’importe quel autre moyen qu’un tar, mais le principe serait le même. Cette méthode présente quelques avantages par rapport à la méthode n° 1 :

• méthode uniforme : le serveur physique peut appliquer cette méthode pour tous les serveurs virtuels qu’il héberge, et il n’est pas nécessaire d’installer un agent de sauvegarde dans ces derniers
• garantie de cohérence : puisqu’il est arrêté, il ne peut rien se passer dans le serveur virtuel, durant la sauvegarde, qui rendrait cette dernière incohérente

cependant, il n’est pas toujours possible ou souhaitable d’arrêter les services que le serveur virtuel héberge, et même dans le cas ou cet arrêt est acceptable, la durée d’indisponibilité du service peut se révéler assez importante, puisqu’elle cumule la durée de l’arrêt, de la sauvegarde, et de la relance.

La restauration des fichiers se fait par un simple tar,

Méthode n°3 : sauvegarde à chaud avec durée d’indisponibilité réduite

Il s’agit d’une variante de la méthode n° 2, qui utilise le checkpointing afin de gagner du temps sur les opérations d’arrêt et de relance. Cela consiste à :

• faire un « checkpoint » du serveur virtuel,

• sauvegarder le serveur virtuel arrêté ainsi que le fichier de checkpoint,

• faire un « resume » du serveur virtuel,

par exemple :

vzctl chkpnt 123  --dumpfile /chemin/vers/123.dump
tar cf backup_123.tar /var/lib/vz/private/123 /chemin/vers/123.dump
vzctl restore 123  --dumpfile /chemin/vers/123.dump

Cette méthode présente l’avantage, par rapport à la méthode n° 2, d’éviter le temps nécessaire à l’arrêt et à la relance des processus du serveur virtuel, mais ne dispense pas de la durée de la sauvegarde. En outre, si le temps de sauvegarde est long, il est probable que les clients qui seraient toujours connectés pendant la sauvegarde se fasse déconnecter en raison des timeouts, puisque dans cet état figé, le serveur ne répond plus jusqu’à la fin de la sauvegarde.

Pour restaurer une telle sauvegarde, il faut donc extraire le contenu du tar, c’est à dire :

• les fichiers du serveur virtuel à remettre dans /var/lib/vz/private/123
• le fichier du checkpoint 123.dump

Et relancer le serveur virtuel dans le même état qu’au moment de la sauvegarde, avec la commande vzctl restore ci-dessus.

Méthode n°4 : sauvegarde à chaud instantanée

Il s’agit d’une variante de la méthode n° 3 qui permet :

• d’utiliser le checkpointing pour faire un instantané de l’état de la mémoire du serveur virtuel
• d’utiliser un  snapshot  de volume LVM pour faire une instantané de l’état des fichiers du serveur virtuel
• et de sauvegarder tout ça, en garantissant la cohérence, et sans arrêter le serveur.

En effet, nous avons vu que la méthode n° 3 nécessite un temps de sauvegarde qui peut se révéler relativement long et induire une interruption de service et/ou la déconnexion des clients. Avec cette méthode, il est possible de faire une sauvegarde « instantanée ».

En revanche, contrairement aux autres méthodes, cela suppose que le serveur virtuel soit installé dans un volume LVM. Je ne détaillerai pas dans cet article la façon de créer une partition LVM, vous trouverez des infos sur LVM à cette adresse.

Voici comment réaliser une telle sauvegarde. D’abord, on fige l’état du serveur virtuel par un checkpoint. Je vous recommande de placer le fichier du checkpoint dans le même volume lvm que celui ou se trouve le serveur virtuel.

vzctl chkpnt 123  --dumpfile /chemin/vers/123.dump

Ensuite, on fait un snapshot du système de fichiers :

sync ; sleep 1 ; sync
echo 3 > /proc/sys/vm/drop_caches
lvcreate -L 1G -s -n backup_snap /dev/xxx_vg/xxx_lv

La commande qui créé le snapshot est la ligne lvcreate. Cependant, j’ai souvent eu des difficultés à créer le snapshot si je n’exécutais pas les autres commandes juste avant. Vous devrez remplacer les paramètres de la commande lvcreate par des valeurs qui vous conviennent, en particulier la taille maximale du snapshot (-L), qui est fonction de la quantité de modifications susceptibles d’être apportées au système de fichiers pendant tout le temps ou vous conserverez le snapshot (c’est à dire, dans le cas présent, pour la durée de la sauvegarde), le nom du snapshot (-n) , et le chemin du volume logique lvm qui contient le serveur virtuel. Note : il faut qu’il reste assez de place dans le volume group pour créer un volume pour le snapshot.

La création du snapshot est quasiment instantanée, et une fois qu’il est fait, vous pouvez tout de suite relancer le serveur virtuel :

vzctl restore 123  --dumpfile /chemin/vers/123.dump

Nous disposons à présent d’un checkpoint du serveur virtuel et d’un snapshot du système de fichiers, qui à eux deux contiennent une « photo » du serveur virtuel. Pour faire cette « photo », cela n’aura pris que quelques secondes, même si le serveur virtuel contient des centaines de Go de données.  Ces quelques secondes, sont presque imperceptibles du point de vue des clients. Il ne reste plus qu’à faire la sauvegarde proprement dite. Pour cela, il faut d’abord monter le snapshot (là encore, adaptez le chemin vers le volume lvm du snapshot), afin de lire son contenu (contenu qui ne changera pas, quelles que soient l’activité du serveur virtuel relancé et la durée de la sauvegarde), puis faire la sauvegarde :

mkdir /mnt/backup_snap
mount -o ro /dev/xxx_vg/backup_snap /mnt/backup_snap
tar cf backup_123.tar /mnt/backup_snap/var/lib/vz/private/123 /mnt/backup_snap/chemin/vers/123.dump
umount /mnt/backup_snap

Et quand la sauvegarde est finie, il faut supprimer le snapshot (adaptez le chemin vers le volume du snapshot) :

lvremove -f /dev/xxx_vg/backup_snap

La restauration d’une sauvegarde se passera ici comme dans la méthode n° 3.

Conclusion

Nous avons vu dans cet article comment réaliser des checkpoints de serveurs virtuels, ainsi que des applicatiosn intéressantes de ces checkpoints pour déplacer des serveurs virtuels ou les sauvegarder.

En matière de sauvegarde, je vous recommande surtout de choisir une méthode qui soit adaptée à vos besoins. Inutile, par exemple, de monter une solution un peu compliquée avec snapshot du système de fichiers si vous n’avez pas besoin de garantir la cohérence du serveur.  Et surtout, entrainez vous à restaurer vos sauvegardes, car ce n’est généralement pas le moment ou on en a besoin qu’on souhaite découvrir qu’on est pas très au point pour restaurer ses données.

Différences entre venet et veth

(note : cette section est une traduction de la page http://wiki.openvz.org/Differences_between_venet_and_veth, que j’ai trouvée claire et concise)

• veth transmet le broadcast aux machines virtuelles, de sorte que vous pouvez y installer des applications comme un serveur DHCP ou un serveur samba (NDT: sans serveur WINS)
• veth a des conséquences sur la sécurité, et il n’est pas recommandé dans des environnements non sûrs, comme pour la fourniture de services d’hébergement. Ceci est lié au broadcast, à la capture de paquets, au risque de collision d’adresses IP, etc. Un utilisateur de machine virtuelle avec veth peut vraiment mettre à mal votre réseau avec un tel accès direct à la couche ethernet.
• Avec une interface virtuelle venet, seul l’administrateur du serveur physique OpenVZ peut attribuer une adresse IP à une machine virtuelle. Avec une interface virtuelle veth, les paramètres réseau peuvent être intégralement définis dans la machine virtuelle, depuis l’administrateur de cette dernière. La machine virtuelle doit paramétrer correctement une adresse IP, le masque de sous réseau, la passerelle par défaut… et l’administrateur du serveur physique peut seulement choisir vers où router le trafic de la machine virtuelle.
• Les interfaces virtuelles veth peuvent être bridgées ensemble et/ou avec d’autres interfaces. Par exemple, l’administrateur du système hôte peut bridger les veth de deux machines virtuelles avec une interface VLAN eth0.X. Dans ce cas, ces deux machines virtuelles seront connectées à ce VLAN.
• Une interface venet est légèrement plus rapide et plus efficiente.
• Pour une interface veth, l’adresse IPv6 est auto-générée depuis l’adresse MAC.

Tableau récapitulatif :

1. En raison du broadcast, de la possibilité de renifler le réseau ou d’obtenir des collisions d’adresses IP collisions, etc.

En résumé

Le gros intérêt de l’interface venet, c’est que ça permet à l’administrateur du serveur physique de décider de la configuration réseau de la machine virtuelle. C’est particulièrement appréciable pour un hébergeur qui souhaite vendre un service d’hébergement de machines virtuelles, car il peut librement laisser ses clients administrer leur serveur virtuel OpenVZ tout en étant certain qu’ils ne pourront pas perturber le réseau, s’attribuer davantage d’adresses IP que prévu, bidouiller les tables de routage, etc. Si vous utilisez OpenVZ pour fournir des services d’hébergement à vos clients, l’interface veth n’est pas faite pour vous. Je ne suis pas dans ce cas de figure, donc les potentiels problèmes de sécurité que peuvent poser l’interface veth pour un hébergeur ne me concernent pas.

J’utilise à la fois venet et veth sur les serveurs que j’administre : veth lorsque j’ai besoin d’avoir un accès aux couches ethernet depuis les serveurs virtuels, et venet dans tous les autres cas. Mais, contrairement à la simplicité offerte par les interfaces venet, pour pouvoir utiliser une interface veth dans un serveur virtuel, il faut faire quelques opérations de configuration complémentaires pour préparer le serveur physique à recevoir des serveurs virtuels utilisant veth. C’est ce que je vais décrire dans les sections suivantes.

Préparation du serveur physique

Ceci est valable pour un serveur physique Debian Etch et Ubuntu 8.04, et avec les paquets conçus pour ces distributions, qui fournissent OpenVZ dans une version 3.0.22. Au delà de la version 3.0.22 d’OpenVZ, cela devrait être un peu plus simple.

Pour que les serveurs virtuels aient une interface ethernet, via veth, il faut bridger les interfaces veth avec une interface physique du serveur. Nous allons commencer par créer le bridge sur le serveur, puis nous verrons comment faire pour que les interfaces virtuelles s’ajoutent ou se retirent du bridge en fonction du démarrage ou de l’arrêt des serveurs virtuels.

Configuration du bridge sur le serveur physique

Votre serveur physique est certainement déjà paramétré pour votre réseau. Son fichier de configuration du réseau, /etc/network/interfaces, doit ressembler à ceci :

root@vz_host:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
    address 192.168.1.1
    netmask 255.255.255.0
    network 192.168.1.0
    broadcast 192.168.1.255
    gateway 192.168.1.254

Pour que vos serveurs virtuels aient une interface veth qui soit « branchée » sur l’interface physique eth0 du serveur, il faut qu’au moment du boot, le serveur créée un bridge qui, au début, ne contient que l’interface eth0. Pour cela, il est  nécessaire que le paquet bridge-utils soit installé, si ce n’est pas déjà fait :

root@vz_host:~# apt-get install bridge-utils

Ensuite, il suffit de modifier le fichier /etc/network/interfaces comme ceci (il faut également que le serveur ait chargé le module vzethdev, ce qui devrait être le cas si vous avez suivi le tuto jusqu’ici) :

root@vz_host:~# cat /etc/network/interfaces
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet manual

auto vzbr0
iface vzbr0 inet static
    bridge_ports eth0
    address 192.168.1.216
    netmask 255.255.255.0
    network 192.168.1.0
    broadcast 192.168.1.255
    gateway 192.168.1.254

et rebooter.

Après redémarrage, l’exécution des commandes suivantes sur le serveur doit retourner ceci :

root@vz_host:~$ ifconfig
eth0      Link encap:Ethernet  HWaddr 00:15:f2:97:ad:e1 
          adr inet6: fe80::215:f2ff:fe97:ade1/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Packets reçus:925 erreurs:0 :0 overruns:0 frame:0
          TX packets:714 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000
          Octets reçus:893972 (873.0 KB) Octets transmis:86440 (84.4 KB)
          Interruption:16 Adresse de base:0x2000 

lo        Link encap:Boucle locale 
          inet adr:127.0.0.1  Masque:255.0.0.0
          adr inet6: ::1/128 Scope:Hôte
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          Packets reçus:8 erreurs:0 :0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:0
          Octets reçus:560 (560.0 B) Octets transmis:560 (560.0 B)

venet0    Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 
          UP BROADCAST POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1
          Packets reçus:0 erreurs:0 :0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:0
          Octets reçus:0 (0.0 B) Octets transmis:0 (0.0 B)

vzbr0     Link encap:Ethernet  HWaddr 00:15:f2:97:ad:e1 
          inet adr:192.168.1.216  Bcast:192.168.1.255  Masque:255.255.255.0
          adr inet6: fe80::215:f2ff:fe97:ade1/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Packets reçus:904 erreurs:0 :0 overruns:0 frame:0
          TX packets:708 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:0
          Octets reçus:880056 (859.4 KB) Octets transmis:82416 (80.4 KB)

root@vz_host:~# brctl show
bridge name	bridge id		STP enabled	interfaces
vzbr0		8000.0015f297ade1	no		eth0

ce qui montre que l’interface du bridge détient bien l’adresse IP définie dans /etc/network/interfaces et que le bridge est bien constitué, pour le moment, de la seule interface eth0.

Paramétrage OpenVZ sur le serveur hôte

Afin qu’au lancement d’un serveur virtuel OpenVZ ajoute ou retire dynamiquement une interface veth au bridge, il faut créer quelques fichiers sur le serveur physique. Cette opération est à faire une bonne fois pour toutes sur le serveur physique, indépendamment du nombre de serveurs virtuels qui seront créés par la suite. Il est également possible de la faire sur un serveur qui, au final, n’héberge que des serveurs virtuels utilisant des interfaces venet, cela ne perturbe en rien ces derniers.

D’abord, il faut créer le fichier /etc/vz/vznet.conf, avec le contenu suivant :

#!/bin/bash
EXTERNAL_SCRIPT="/usr/local/sbin/vznetaddbr"

puis le fichier /usr/local/sbin/vznetaddbr, avec le contenu suivant :

#!/bin/bash
# /usr/local/sbin/vznetaddbr
# a script to add virtual network interfaces (veth's) in a VE to a bridge on VE0
CONFIGFILE=/etc/vz/conf/$VEID.conf
. $CONFIGFILE
VZHOSTIF=`echo $NETIF |sed 's/^.*host_ifname=\(.*\),.*$/\1/g'`
if [ ! -n "$VZHOSTIF" ]; then
   echo "According to $CONFIGFILE VE$VEID has no veth interface configured."
   exit 1
fi
if [ ! -n "$VZHOSTBR" ]; then
   echo "According to $CONFIGFILE VE$VEID has no bridge interface configured."
   exit 1
fi
echo "Adding interface $VZHOSTIF to bridge $VZHOSTBR on VE0 for VE$VEID"
/sbin/ifconfig $VZHOSTIF 0
echo 1 > /proc/sys/net/ipv4/conf/$VZHOSTIF/proxy_arp
echo 1 > /proc/sys/net/ipv4/conf/$VZHOSTIF/forwarding
/usr/sbin/brctl addif $VZHOSTBR $VZHOSTIF
exit 0

Il faut également associer le droit d’exécution à ce fichier en tapant la commande :

chmod +x /usr/local/sbin/vznetaddbr

Voila. Ce n’était pas grand chose, et à présent le serveur peut héberger des serveurs virtuels dont les interfaces veth seront bridgées avec la ou les siennes. Pour cela, il faut adapter le paramétrage réseau des serveurs virtuels, ce qui fait l’objet de la section suivante.

Paramétrage d’un serveur virtuel pour utiliser une interface veth

En tant qu’administrateur du serveur hôte, vous pouvez ajouter une interface réseau veth à un serveur virtuel avec la commmande

root@vz_host:~# vzctl set $VEID --netif_add eth0 --save

où $VEID est à remplacer par le numéro du serveur virtuel concerné, et eth0 par le nom que vous souhaitez donner à l’interface ethernet à l’interieur du serveur virtuel. Pour le serveur physique, cette interface sera nommée veth$VEID.0, soit, pour le serveur virtuel désigné par le VEID n° 1, veth1.0.

Une fois cette commande appliquée, vous pourrez constater que, dans le fichier de configuration du serveur virtuel; situé dans /etc/vz/conf/$VEID.conf, une ligne telle que celle-ci a été ajoutée.

NETIF="ifname=eth0,mac=00:18:51:2A:AB:99,host_ifname=veth1.0,host_mac=00:18:51:87:7C:50"

Cette commande a généré automatiquement deux adresses MAC qui seront utilisées pour l’interface veth. Une d’entre elles est associée à l’interface eth0, côté serveur virtuel, et l’autre à l’interface veth1.0, côté serveur physique. Il est possible de spécifier les adresses MAC souhaitées sur la ligne de commande vzctl, mais vous devrez alors prendre soin de ne pas avoir de collision d’adresses MAC sur votre réseau.

Nous n’avons pas encore eu l’occasion de spécifier à OpenVZ avec quelle interface physique du serveur il faut bridger cette interface virtuelle. C’est normal, ce paramètre n’est pas pris en charge par OpenVZ dans les versions jusqu’à 3.0.22. C’est pour ça qu’il faut ajouter à la main un script pour la gestion du bridge et qu’il faut ajouter à la main, dans le fichier de configuration du serveur virtuel (dans /etc/vz/conf/$VEID.conf) la ligne suivante :

VZHOSTBR=vzbr0

afin de spécifier à quel bridge du serveur physique l’interface veth doit être ajoutée.

Si vous avez suivi ce tutoriel pour créer le serveur virtuel, vous lui avez peut-être associé une interface réseau venet qui n’est plus nécessaire. Le cas échéant, pour la supprimer, faites :

root@vz_host:~# vzctl set 1 --ipdel 192.168.1.1 --save

Il est temps de (re)lancer le serveur virtuel. Ce n’est qu’à son redémarrage que le script vnetaddbr sera invoqué et que l’interface ethernet virtuelle sera bridgée avec celle du serveur physique. Une fois le serveur virtuel démarré, vous devriez pouvoir constater que le bridge contient bien l’interface veth du serveur virtuel, avec la commande :

root@vz_host:~# brctl show vrzb0
bridge name    bridge id            STP enabled    interfaces
vzbr0          8000.0015f297ade1    no             eth0
                                                   veth1.0

C’est terminé pour la configuration à faire côté serveur hôte. Il vous reste à entrer dans le serveur virtuel pour définir les paramètres réseau. Configuré avec une interface veth, le paramétrage du réseau se fait comme sur un serveur physique : dans l’exemple ci-dessus, le serveur virtuel dispose d’une interface eth0 qui peut être configuré comme d’habitude sur la distribution que vous avez utilisée pour le serveur virtuel (par exemple, sur Debian et Ubuntu, dans le fichier /etc/network/interfaces du serveur virtuel).

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 :

Aperçu de l’outil de calcul de paramètres UBC

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.

Je suis depuis quelques semaines l’heureux possesseur d’un netbook Asus EeePC 1000H. Après avoir eu l’occasion de tester le modèle 701, j’ai décidé de faire l’acquisition du modèle 10′ et d’y installer la distribution eeebuntu.

Mais eeebuntu est une distribution conçue principalement pour l’EeePC 701, et les composants de l’EeePC 1000 étant sensiblement différents, je m’attendais à quelques difficultés. Finalement, ce fut moins difficile que ce que je craignais et abordable pour un utilisateur néophyte en suivant ce tutoriel. Compte rendu de l’opération…

Mon Asus EeePC 1000H après installation
d’eeebuntu selon ce tutoriel

L’EeePC 1000H est un des tout derniers modèles de netbooks de chez Asus, doté d’un écran 10′ et du récent processeur Intel Atom N270. Mon choix s’est porté sur ce modèle pour son clavier confortable, son écran de 10′, sa bonne autonomie (4 heures de travail effectif sur batterie avec le wifi activé) et sa conception cohérente : le chargeur ne fait pas la moitié de ta taille du PC, contrairement à de nombreux modèles concurrents comme le MSI Wind ou ses clones !

La distribution eeebuntu est optimisée pour les netbooks EeePC : moins de logiciels installés par défaut, temps de démarrage optimisé, noyau spécifiquement adapté à l’EeePC 701. Seulement, du fait qu’elle est principalement conçue pour l’EeePC 701, son installation sur le 1000 demande quelques opérations supplémentaires. Je n’ai pas vérifié, mais je pense que ce que je décris ci-après est valable également pour le modèle EeePC 901 dont l’électronique est sensiblement la même. Si ça n’est pas le cas, faites le moi savoir. Voici comment procéder (je vous invite à lire tout cet article avant de vous lancer).

Tout d’abord, téléchargez  la distribution sur http://www.eeebuntu.org. La disrtibution est déclinée en deux versions : Standard ou Netbook Remix (NBR). Netbook Remix propose, en plus de la version standard, un menu simplifié ressemblant à ce qui se fait sur les EeePC équipés de Xandros.

Menu des applications en fond d’écran pour la version Netbook Remix

Choisissez la version qui vous paraît adaptée à vos besoins, sachant que si vous prenez la standard, vous pourrez toujours ajouter Netbook Remix plus tard, sans réinstaller.

L’EeePC étant dépourvu de lecteur de CDROM, vous devrez installer l’iso sur un support d’amorçage sur mémoire tel qu’une carte SD ou une clé USB. Vous pouvez pour cela vous servir du logiciel UNetbootin dont j’ai parlé dans un précédent article.

Une fois votre support d’amorçage prêt, insérez le et allumez l’EeePC. Lorsqu’il affiche l’écran gris « Asus EeePC », pressez la touche « Echap » pour obtenir le menu de sélection du périphérique d’amorçage. Choisissez celui qui convient, vous devriez rapidement voir booter eeebuntu depuis votre live-pasCD.

L’installation d’eeebuntu se passe sans problème, je ne m’attarderai pas sur cette partie qui ne diffère en rien de l’installation d’Ubuntu sur un quelconque PC. Les possesseurs d’EeePC avec un disque SSD devront néanmoins peser le pour et le contre d’une partition de swap. En effet, l’EeePC 1000 version SSD dispose de 2 disques SSD : un de 8 Go, limité mais assez performant, et un autre de 32 Go, très lent en écriture. Ne comptez pas mettre du swap dans le second, c’est trop lent, et mettre une partition de swap dans le premier consommerait de l’espace alors qu’il est assez limité, donc ne créez cette partition que si vous pensez vraiment en avoir besoin. En ce qui me concerne, j’ai la version avec un gros disque dur, à l’ancienne, donc pas de questions existentielles, en avant !

Après l’installation d’eeebuntu, vous constaterez que certaines choses fonctionnent tout de suite, et d’autres pas. Au chapitre de ce qui fonctionne : le son, la webcam, le lecteur de cartes SD, l’USB, la résolution écran, le touchpad en multitouch (un appui avec deux doigts correspond au bouton du milieu et à la molette d’une souris classique), les touches spéciales (volume, luminosité…) et l’OSD. C’est déjà pas mal. Et au chapitre de ce qui ne fonctionne pas : le bluetooth et le réseau, que ce soit ethernet ou wifi. Avouez que c’est gênant pour un netbook… On va régler ces problèmes un par un.

Commençons par le réseau, c’est le plus gênant. Pour corriger ça, il faut télécharger un noyau linux spécialement adapté à l’EeePC sur le site http://array.org/ubuntu/. Vous devrez télécharger deux fichiers, depuis un autre PC bien entendu. Prenez ceux-ci :

linux-image-2.6.24-21-eeepc_2.6.24-21.39eeepc1_i386.deb

linux-ubuntu-modules-2.6.24-21-eeepc_2.6.24-21.30eeepc5_i386.deb

et copiez les sur votre clé USB ou votre carte SD.

Avant d’insérer votre carte mémoire, lancez un terminal et tapez :

sudo gedit /etc/fstab

Si le fichier fstab contient une ligne ressemblant à celle-ci (si elle contient /media/cdrom0)

/dev/sdc1  /media/cdrom0  udf,iso9660 user,noauto,exec  0   0

supprimez la et sauvez le fichier. Conservez le terminal, et tapez :

cd /media
ls

Repérez le résultat de la commande. Vous pouvez à présent insérer votre clé ou carte mémoire. Un nouveau répertoire devrait apparaître dans /media. Tapez à nouveau

ls

et comparez le résultat pour le trouver. Admettons qu’il s’agisse du répertoire disk. Tapez :

cd disk
ls

Vous devriez voir les fichiers suffixés .deb que vous avez téléchargés sur le site array.org. Pour les installer, tapez :

sudo dpkg -i linux-image-2.6.24-21-eeepc_2.6.24-21.39eeepc1_i386.deb linux-ubuntu-modules-2.6.24-21-eeepc_2.6.24-21.30eeepc5_i386.deb

A présent vous pouvez rebooter, ce noyau devrait être celui par défaut, et le réseau ethernet et wifi devraient fonctionner.

Il reste encore quelque chose à faire pour bénéficier de futures mises à jour du noyau disponibles sur array.org. Lancez un terminal et tapez les commandes suivantes :

wget http://www.array.org/ubuntu/array.list
sudo mv -v array.list /etc/apt/sources.list.d/
wget http://www.array.org/ubuntu/array-apt-key.asc
sudo apt-key add array-apt-key.asc
sudo apt-get update
sudo apt-get install linux-eeepc linux-headers-eeepc

Voila. Fini pour le noyau.

Mais maintenant que l’on a le réseau qui fonctionne, l’activation/désactivation du wifi par la touche Fn + F2 fait figer le système d’exploitation. Pas de panique, la solution est ci dessous (trouvée sur le forum eeebuntu.org)

Téléchargez le fichier eee-wifi-on-off.sh et tapez :

sudo chmod +x eee-wifi-on-off.sh
sudo mv eee-wifi-on-off.sh /etc/acpi

A présent, la touche Fn + F2 devrait fonctionner.

Reste le bluetooth. Là c’est très simple, c’est seulement que la distribution eeebuntu est conçue pour des eeepc qui n’ont pas de composant bluetooth et n’installe pas les logiciels adéquats par défaut. Il suffit de les ajouter. Via le gestionnaire de paquets synaptic, installez les paquets bluetooth, bluez-gnome et bluez-utils. Si vous avez toujours votre terminal, vous pouvez les installer avec

sudo apt-get install bluetooth bluez-gnome bluez-utils

Voila, vous avez à présent un EeePC 1000 sous Ubuntu largement opérationnel, qui boote en une trentaine de secondes, et qui offre de très bonnes performances pour une utilisation bureautique (essayez les effets 3D de compiz, c’est bluffant). Je l’utilise ainsi depuis plusieurs semaines sans aucun problème. Enfin… aucun qui me gène, car il y a encore quelques petits détails à régler :

• je crois que le micro intégré ne fonctionne pas. Je n’ai pas insisté, je n’en ai pas l’usage.
• la bascule sur un écran externe par appui sur la touche clavier adéquate (Fn+F8) ne fonctionne pas, mais si on allume l’EeePC avec un écran externe, ça fonctionne. Là non plus, je n’ai pas creusé, ça ne me sert pas.

Si ce tutoriel vous a aidé, ou si vous avez des compléments à y apporter, n’hésitez pas à me laisser un commentaire !

Qui n’a jamais pesté en essayant d’installer la toute dernière distribution fraîchement gravée sur CD en s’apercevant que ledit CD est défectueux et fait planter l’installation au bout de 30 minutes d’attente et de paramétrages ? A moins que ça ne soit à cause du lecteur de CD qui, servant pour la troisième fois depuis son achat, a fini d’étouffer sous l’oisiveté et la poussière.

Bref, les CD, c’était bien à l’époque des disquettes (souvenez vous, quand l’installation d’un logiciel demandait de jongler avec une vingtaine de disquettes), mais maintenant c’est dépassé.

Lorsqu’il s’agit de lire une iso depuis son système d’exploitation favori, il y a plein de méthodes pour éviter de graver des CD : fuseiso ou montage avec l’option loopback sous linux ou, pour les utilisateurs de windows, les daemon tools. Mais lorsqu’il s’agit d’éviter de graver un CD d’installation d’une distribution linux, c’est une autre paire de manches. On trouve bien ici et là des tutoriels sur comment installer telle ou telle distribution sur une clé USB, mais c’est souvent assez compliqué pour parvenir à un résultat qui fonctionne.

Enfin, c’était compliqué. Parce qu’avec UNetbootin, préparer une clé USB, une carte SD ou un disque dur USB pour le rendre bootable avec une iso d’installation ou de live-cd de sa distribution linux préférée, c’est un jeu d’enfant. En quelques mots, voici comment ça se passe sur Ubuntu.

• D’abord, vous téléchargez UNetbooin. Vous devrez aussi avoir installé le paquet p7zip-full (apt-get install p7zip-full) pour éviter un message au moment de le lancer, mais j’ai l’impression que ça n’est pas indispensable.

• Ensuite, vous lancez UNetbootin (note : après téléchargement le fichier n’est pas exécutable et vous devrez donner le droit d’exécuter : bouton droit sur le fichier / propriétés / permissions et rendre le fichier exécutable ou, pour les amateurs du shell, chmod +x unetbootin-linux-282). Vous arriverez sur un écran comme celui-ci :

• Après attention, ça ce complique Vous devez choisir, parmi vos fichiers, l’image iso que vous aurez préalablement téléchargée, ou bien en choisir une dans la liste proposée que UNetbootin se chargera de télécharger pour vous.
• Enfin, vous choisissez le Disque sur lequel vous voulez installer cette iso pour pouvoir booter dessus.
• Cliquez sur OK, allez prendre un café et quelques minutes après, c’est terminé.

Avouez qu’il y a plus difficile !

Sachez enfin qu’il existe également une version Windows du logiciel. Vous pourrez approfondir les options de l’outil sur le site d’UNetbootin.

Croyez vous que l’on verra bientôt disparaître les lecteurs de CD des ordinateurs ? Ou que leur usage se limitera à celui de porte-gobelets ? On assiste déjà à l’explosion des ventes des netbooks qui sont dépourvus de ces deux accessoires, preuve, s’il fallait en apporter, qu’ils sont loin d’être indispensables…

Merci à MD qui m’a fait découvrir ce sympathique petit outil.

Création d’un premier serveur virtuel

Créer un nouveau serveur virtuel avec OpenVZ est quelque chose de très simple. A condition d’avoir installé le bon template (cf. le tutoriel sur l’installation du serveur hôte), il suffit de taper cette commande dans un terminal :

vzctl create 101 --ostemplate debian-4.0-i386-minimal --ipadd 192.168.1.1 --hostname mon-nouveau-serveur

Cette commande a, en quelques secondes, créé un nouveau serveur debian, ayant 101 comme ID de serveur virtuel (son VEID dans la terminologie OpenVZ), répondant à l’adresse IP 192.168.1.1, et dont le hostname est « mon-nouveau-serveur ». Magique !

On peut peaufiner la configuration réseau de ce serveur en lui définissant les paramètres DNS avec :

vzctl set 101 --nameserver l.ip.du.dns --searchdomain mondomaine.fr --save

Et enfin, si l’on veut que ce serveur virtuel soit démarré au reboot du serveur hôte :

vzctl set 101 --onboot yes --save

Notre serveur virtuel est prêt, il est grand temps de le démarrer avec :

vzctl start 101

Après quelques secondes, le serveur est prêt à être utilisé. Pour y entrer, tapez :

vzctl enter 101

depuis le serveur hôte. Sinon, si le template choisi contenait un serveur ssh, vous devriez déjà pouvoir vous y connecter par son adresse IP. Une fois dans votre serveur virtuel, vous pouvez y faire à peu près la même chose que dans un serveur physique. Vous pouvez dès à présent installer vos logiciels sur ce nouveau serveur virtuel.

Qu’avons nous fait ?

Installer un nouveau serveur debian, ubuntu centos ou autre en 10 secondes, ça y ressemble, mais ce n’est pas un tour de magie. Alors voyons plus en détail ce que nous avons fait.

La création du serveur tout d’abord. La commande vzctl create permet de s’appuyer sur un template pour créer un nouveau serveur virtuel. Le template est une archive tar compressée contenant l’arborescence complète d’une installation d’une distribution quelconque depuis la racine. Le nom du template à fournir sur la ligne de commande correspond au nom de l’archive placée dans le répertoir /var/lib/vz/template/cache, sans l’extension .tar.gz.

Au moment de la création, la commande vzctl create extrait tous les fichiers contenus dans l’archive tar dans le répertoire /var/lib/vz/private/x (où x est le numéro  du serveur virtuel). Après la création, on retrouve donc tous les fichiers du serveur virtuel dans le système de fichiers du serveur hôte.

Au moment de la création du serveur virtuel, openvz a également créé son fichier de configuration spécifique dans /etc/vz/conf/101.conf. Ce fichier contient les paramètres d’allocation de ressources du serveur virtuel ainsi que les paramètres réseau. C’est pour que les paramètres fournis à la commande vzctl soient enregistrés définitivement dans ce fichier qu’il faut préciser l’option –save. Sans cette option, les paramètres fournis à vzctl sont appliqués dynamiquement au serveur virtuel mais ne sont pas conservés si le serveur virtuel est redémarré.

La configuration réseau d’un serveur virtuel OpenVZ (lorsqu’il opère dans le mode venet…  j’y reviendrai) diffère de la configuration réseau de la même distribution sur un serveur physique. En effet, les paramètres réseau ne sont stockés dans les fichiers habituels de la distribution hébergée, mais sont utilisés, au moment du démarrage du serveur virtuel pour recréer les fichiers de la distribution hébergée qui concernent le paramétrage réseau, DNS et le hostname (respectivement /etc/network/interfaces, /etc/resolv.conf et /etc/hostname pour debian/ubuntu par exemple).

Enfin, au moment du démarrage, la commande vzctl start « monte » l’espace de fichiers du serveur virtuel, situé par exemple dans /var/lib/vz/private/1 dans un espace de nommage situé dans /var/lib/vz/root/101.  Lorsque le serveur est arrêté, seul le répertoire /var/lib/vz/private/101 contiendra les fichiers, et /var/lib/vz/root/101 apparaîtra vide. A savoir pour ne pas se faire piéger.

Démarrer, lister et arrêter ses serveurs virtuels

Comme nous avons vu précédemment, le démarrage du serveur virtuel se fait depuis le serveur hôte avec la commande :

vzctl start 101

De la même manière, pour arrêter ce serveur virtuel, il faut taper la commande :

vzctl stop 101

Dans le serveur virtuel, le démarrage et l’arrêt se font par la classique séquence de boot des machines unix/linux : un processus init parcourt l’inittab, et ce dernier procède au démarrage des services référencés dans les répertoires /etc/rc?.d/ et /etc/init.d. Les commandes vzctl start et vzctl stop prennent en charge la gestion du processus init du serveur virtuel. Dans vos serveurs virtuels vous gérerez le lancement et l’arrêt des services comme d’habitude, par l’intermédiaire de scripts de service placés dans /etc/init.d, sans vous occuper du reste.

Sur le serveur hôte, vous pouvez lister les serveurs virtuels qui sont démarrés en tapant :

vzlist

Si votre serveur virtuel est démarré, vous devriez lire quelque chose qui ressemble à ceci :

      VEID      NPROC STATUS  IP_ADDR         HOSTNAME
       101         10 running 192.168.1.1     mon-nouveau-serveur

On retrouve dans ce tableau les principaux éléments fournis à la création du serveur virtuel, à savoir son ID (VEID = Virtual Environment ID), son adresse IP et son hostname. On peut lire également le nombre de processus lancés dans ce serveur virtuel et un statut qui précise que ce serveur fonctionne.

C’est tout pour aujourd’hui. Dans un prochain article je poursuivrai ce tutoriel sur OpenVZ par la gestion des ressources allouées à un serveur virtuel par le serveur hôte.

Je ne détaillerai pas de façon précise l’installation d’une distribution Debian Etch ou Ubuntu 8.04. Je suppose que vous connaissez la distribution et que vous savez l’installer et la configurer, en particulier ce qui concerne le réseau. Si vous partez sur une base Ubuntu, ce que je décris s’applique aussi bien à une Ubuntu Desktop ou Server.

Le partitionnement du disque dur du serveur que vous ferez pendant l’installation mérite néanmoins quelques commentaires :

• Vous devrez, bien sûr, créer une partition pour la racine (inutile qu’elle soit grande).
• Selon votre architecture matérielle, vous pouvez choisir si vous le souhaitez de créer une partition pour héberger vos serveurs virtuels. J’utilise généralement des ressources de stockage externes pour mes serveurs virtuels (j’aurai l’occasion d’y revenir dans de prochains articles), alors je n’en créé pas sur les serveurs que j’administre, mais si vous comptez stocker vos serveurs virtuels sur votre serveur physique, vous pouvez leur dédier une partition, à monter sur /var/lib/vz, car c’est là qu’OpenVZ va stocker les serveurs virtuels par défaut.
• Créez également une partition pour la mémoire swap (2 x la mémoire physique). Attention cependant : si votre serveur peut encore se voir ajouter de la mémoire physique, envisagez de dimensionner votre swap en fonction de sa capacité de mémoire une fois que vous l’aurez augmentée. En effet, avec plusieurs serveurs virtuels créés, vous pourriez en manquer. Dans cette situation, il m’arrive de créer 2 partitions de swap, chacune grande comme 2 x la mémoire physique, et je n’active la deuxième que si j’augmente la mémoire.

Nous pouvons passer à l’installation d’OpenVZ.

Si vous êtes sur Debian

La communauté OpenVZ fournit un dépôt de paquetages pour Debian que nous allons utiliser. Pour cela, il faut mettre à jour le fichier /etc/apt/sources.list et ajouter la clé du dépôt OpenVZ au trousseau de clés local en tapant ces commandes dans un terminal :

Le paquet fzakernel-2.6.18-686-bigmem fournit un noyau patché avec OpenVZ, compilé avec sensiblement les mêmes options que le noyau officiel Debian et qui supporte les architectures multi-processeur avec jusqu’à 64 Go de mémoire, tandis que les paquets vzctl, vzquota, vzprocps et vzdump fournissent des outils pour manipuler les serveurs virtuels.

L’installation du noyau OpenVZ doit avoir modifié grub pour que ce soit le noyau par défaut. Vous pouvez rebooter sur ce nouveau noyau.

Si vous êtes sur Ubuntu 8.04

Sur Ubuntu, c’est encore plus simple, car depuis la sortie de la Hardy, le dépot universe intègre tout ce qu’il faut pour faire tourner OpenVZ sur Ubuntu.

Assurez-vous que le dépot universe est bien référencé dans votre fichier /etc/apt/sources.list, qui doit contenir quelque chose comme ceci :

deb http://fr.archive.ubuntu.com/ubuntu/ hardy main restricted universe multiverse
deb http://fr.archive.ubuntu.com/ubuntu/ hardy-updates main restricted universe multiverse
deb http://security.ubuntu.com/ubuntu hardy-security main restricted universe multiverse

Ensuite, installez OpenVZ en tapant ces commandes dans un terminal :

apt-get update
apt-get install linux-openvz vzctl vzquota

Le paquet linux-openvz est un meta-paquet qui dépend toujours du plus récent noyau Ubuntu patché avec openvz, compilé avec les mêmes options que le noyau officiel Ubuntu. Les paquets vzctl et vzquota fournissent des outils pour manipuler les serveurs virtuels.

L’installation du noyau OpenVZ doit avoir modifié grub pour que ce soit le noyau par défaut. Vous pouvez rebooter sur ce nouveau noyau.

Avant de poursuivre

L’installation des paquets OpenVZ doit avoir ajouté quelques lignes dans le fichier /etc/sysctl.conf, mais les seules qui soient importantes pour le fonctionnement des serveurs virtuels sont les suivantes. Vérifiez qu’elles s’y trouvent bien, sinon ajoutez les :

net.ipv4.ip_forward = 1
net.ipv4.conf.default.proxy_arp = 0

Pour que le serveur hôte OpenVZ soit fonctionnel, il faut que le service vz soit démarré. Vérifiez que ce service est bien démarré à chaque boot. Si ce n’est pas le cas, activez le avec rcconf ou en tapant :

update-rc.d -f vz remove
update-rc.d vz defaults

Petite correction de bug

OpenVZ vient avec un script shell qui comporte un petit bug. En effet, le script /usr/sbin/vznetcfg est un script sh (il est exécuté par /bin/sh) mais il contient une instruction « source » qui n’est valide que dans bash. Sous Debian, ce bug passe inaperçu car par défaut sh est un lien symbolique vers bash, mais sous Ubuntu, sh est un lien symbolique vers dash, dans lequel l’instruction « source » n’est pas reconnue.

Ce problème est décrit dans https://wiki.ubuntu.com/DashAsBinSh.

Pour corriger ce problème sous Ubuntu, corrigez le script en question, et remplacez « source » par « . ».

Et pour finir, installez quelques templates

Pour OpenVZ, un template est un serveur virtuel prêt à être instancié. La communauté OpenVZ fournit quelques serveurs virtuels minimalistes qui ne contiennent qu’une installation de base de quelques distributions, mais vous pourrez simplement créer les vôtres ultérieurement.

Les templates fournis par la communauté OpenVZ sont téléchargeables à cette adresse : http://wiki.openvz.org/Download/template/precreated. J’utilise en particulier les templates Debian 4.0 et Ubuntu 8.04. Une fois téléchargés, vous devrez placer les fichiers tels quels dans le répertoire /var/lib/vz/template/cache de votre serveur, sans les extraire.

Vous avez à présent un serveur hôte prêt à créer et héberger des serveurs virtuels. Je présenterai dans un prochain article la création et l’utilisation de serveurs virtuels OpenVZ.