Proxmox, la virtualisation en entreprise à portée de tous

Linux Essentiel HS n° 001 | juillet 2012
Creative Commons
  • Actuellement 0 sur 5 étoiles
0
Merci d'avoir participé !
Vous avez déjà noté cette page, vous ne pouvez la noter qu'une fois !
Votre note a été changée, merci de votre participation !
Claude « zatmania » Charpentier
Sous ce nom un peu barbare qui ferait penser à un produit pharmaceutique se cache en fait une solution de virtualisation open source très facile à mettre en œuvre. Tout se pilote via une interface web, pas besoin d'être un administrateur système pour déployer cette solution. Il s'agit ici d'une solution destinée à l'entreprise ; pour un poste de bureau, il serait préférable d'utiliser VirtualBox.

1. Plantons le décor

Avant toute chose, je tiens à vous parler du retour d'expérience dont je dispose sur le produit. J'ai commencé à déployer la solution quand Proxmox était en version 0.9 bêta, en juillet 2008. Le produit était déjà très stable et je devais mettre en place plusieurs serveurs Linux, donc plutôt que de déployer un type de serveur par entité physique, j'ai préféré trouver une solution de virtualisation. Mon objectif était simple : trouver une solution open source et facile d'administration, car même si la ligne de commandes ne me rebute pas, je ne serai pas le seul dans le service à devoir l'utiliser.

À l'heure actuelle, nous avons donc deux serveurs de virtualisation Proxmox, en version 1.9, l'un est maître et l'autre esclave (je reviendrai plus loin sur cette notion). L'uptime est de 130 jours (au moment où j'écris cet article), date de la dernière mise à jour nécessitant un redémarrage du serveur.

Pour les personnes ayant peur de ne pas être à la hauteur, il est possible de souscrire un support auprès de la société qui mène le projet. La version 2.0 est sortie le 30 mars 2012 ; nous allons donc détailler cette version plutôt que la version 1.9.

2. Composants techniques

Proxmox se base sur une distribution GNU/Linux Debian 6.0 (Squeeze) qui n'a plus rien à prouver en termes de stabilité et d'utilisation dans le milieu professionnel ou personnel. Concernant la virtualisation, nous aurons le choix entre deux types :

-la paravirtualisation : basée sur le projet OpenVZ [OPENVZ], qui va donc permettre de faire tourner uniquement des machines virtuelles GNU/Linux. Elles s'appuieront ainsi sur le noyau de la machine hôte, mais pourront être de nature différente (entendez par là de distribution différente par rapport à l'hôte, par exemple une Fedora) ;

-la full virtualisation : basée sur le projet KVM [KVM], permettra de virtualiser des systèmes d'exploitation qui n'ont rien à voir avec la machine hôte, dans la mesure d'une compatibilité matérielle et notamment d'un point de vue processeur (par exemple, installation de NetBSD, Windows, etc.).

L'interface d'administration, quant à elle, a été développée avec le framework ExtJS [SENCHA]. Elle a l'avantage d'être agréable d'un point de vue ergonomique et d'être compatible tout navigateur.

Je ne détaillerai pas plus les autres composants, car ce n'est pas l'objet de cet article.

3. Installation

3.1 Pré-requis

L'outil devra obligatoirement s'installer sur un serveur 64 bits, avec un processeur disposant des instructions de virtualisation Intel VT/AMD-V. Concernant la mémoire, un minimum de 4Go sera nécessaire, mais avec cette quantité, vous serez très vite limité. Il est également conseillé de disposer de disques durs à 15000 tours afin d'accroître les performances [REQ].

Passons à l'installation du produit. Personnellement, j'opte pour une installation à partir de l'ISO Bare-metal (Bare-metal ISO installer). Il s'agit tout simplement d'un fichier au format ISO que l'on pourra graver, et il suffira de démarrer sur celui-ci pour lancer l'installation. Il embarque tous les éléments nécessaires au bon fonctionnement de l'outil. L'autre alternative est d'installer une Debian Squeeze et d'y ajouter les dépôts dédiés à Proxmox [SQUEEZE].

3.2 C'est parti !

On appuie sur la touche [Entrée] pour lancer l'installation. Celle-ci est assez triviale et se déroule en plusieurs étapes : acceptation de la licence (GPL3), sélection du disque dur, sélection de la zone géographique et du type de clavier, saisie du mot de passe root. Pour la configuration réseau, on renseignera le nom de la machine, son IP (il faut absolument une IP fixe), le masque de sous-réseau, la passerelle et le DNS.

L'installation commence par la création des partitions au format LVM. Il s'agit de pouvoir étendre la capacité de notre serveur aisément par ce biais. L'installation terminée, on redémarre la machine.

Fig. 1 : Écran de démarrage de l'installation après avoir booté sur le CD-ROM

Fig. 2 : L'installation est finie, le serveur doit rebooter pour être opérationnel.

Après le reboot, vous obtenez le message suivant :

Welcome to the Proxmox Virtual Environment. Please use your web browser to configure this server – connect to : https://192.168.1.51:8006/

On pointe notre navigateur favori vers l'URL indiquée (une erreur de certificat SSL risque de survenir, ne pas en tenir compte). La boîte de dialogue qui nous invite à s'authentifier comporte deux champs en plus du login et du mot de passe : vous choisirez votre langue (une fois connecté, on ne pourra pas la changer durant la session), ainsi que le mode d'authentification (le module PAM, est la valeur par défaut).

Fig. 3 : Proxmox fonctionne. On doit s'identifier afin d'accéder à la console d'administration.

4. À la découverte de l'interface

La page d'accueil regroupe l'ensemble des informations relatives à notre serveur. Par défaut, c'est la vue serveur qui est choisie (1 sur la figure 4) ; elle permet, via une arborescence, de montrer le(s) serveur(s) disponible(s), ainsi que les stockages qui leur sont liés. Il en existe au moins un, le stockage local, qui correspond au disque dur du serveur. Nous verrons plus tard que nous pourrons rattacher un serveur réseau NFS [NFS].

La partie centrale (2 sur la figure 4) est décomposée en plusieurs onglets. Tous ces onglets correspondent à un paramètre du serveur hôte.

Fig. 4 : Interface d'accueil après authentification

4.1 Page d'accueil avec centre de données

Ces onglets permettront une gestion globale de tous les serveurs faisant partie du centre de données ; on pourra y trouver plusieurs nœuds ou serveurs Proxmox.

Rechercher : permet d'effectuer une recherche tous composants du serveur confondus, qu'il s'agisse d'un pool, d'un lecteur réseau, d'une machine virtuelle, ...

Résumé : dresse un aperçu global des serveurs Proxmox (on peut lier plusieurs serveurs, nous verrons cela plus tard dans l'article), indique s'ils sont en ligne, les services qui fonctionnent, …

Options : configuration du clavier et utilisation éventuelle d'un serveur Proxy.

Stockage : c'est ici que l'on paramètre les options de stockage de notre serveur. Comme je vous le disais précédemment, on pourra ajouter du NFS, iSCSI, LVM, répertoires... Le stockage local nécessite d'être partagé pour être disponible au niveau des VM, notamment pour les sauvegardes si on les laisse en local, ce qui n'est pas conseillé. Pour effectuer cette opération, vous choisissez « local », puis Éditer et dans le pop-up qui s'ouvre il faut cocher Partagé et dans la liste déroulante Contenu il faut cliquer sur Backupet enfin, indiquer le nombre de backups maximum. C'est uniquement après ces paramétrages que le stockage local sera disponible partout.

Sauvegarde : c'est ici que seront planifiés les travaux de sauvegarde de nos machines virtuelles, mais j'y reviendrai plus en détails par la suite.

Utilisateurs : nouveauté de la version 2.0, on peut ajouter des utilisateurs et leur affecter des rôles ; dans les versions précédentes, seul l'utilisateur root pouvait se connecter à l'interface.

Groupes : permettent de réunir des utilisateurs devant avoir un même rôle au sein du serveur. Il s'agit également d'une nouveauté de la version 2.0.

Pools : les pools servent à réunir soit des stockages, soit des machines virtuelles afin de pouvoir les administrer plus facilement. Par exemple, sur la figure 4, vous apercevez un pool « Web Servers » : on pourrait y trouver toutes les machines virtuelles qui sont des serveurs web, qu'elles soient destinées au développement, à la production, au recettage, etc. En face de ce pool, on pourra affecter un ou des groupe(s) d'utilisateurs ayant des droits différents (gestion du stockage, administrateur d'une machine virtuelle...).

Permissions : c'est ici que l'on va octroyer les droits à nos utilisateurs/groupes.

Rôles : rôles que l'on peut donner à des utilisateurs/groupes et niveaux de droits. Il faut avouer que ce n'est pas très explicite, car sont détaillés les objets de gestion de droits sans descriptif clair.

Authentification : par défaut, Proxmox permet deux modes d'authentification : PAM et PVE. On pourrait ajouter un autre mode comme l'identification via un serveur LDAP ou un serveur Windows Active Directory.

HA : pour High Availibility ou haute disponibilité en français. On peut donc élaborer une infrastructure type ferme de machines virtuelles grâce à Proxmox. L'idée est que si une machine virtuelle est déclarée en tant que HA, si un nœud (un serveur Promox qui fait partie de la ferme) tombe, la machine est automatiquement démarrée sur un autre serveur. Il faudra bien entendu disposer d'au moins deux serveurs Proxmox liés entre eux (il s'agit d'une utilisation avancée, cela pourra faire l'objet d'un autre article, mais pour en savoir plus, vous pouvez en attendant consulter la documentation sur le site [PVEHA]).

Support : partie utilisée dans le cas d'une souscription de support auprès de l'éditeur de la solution.

4.2 Page d'accueil avec sélection du premier nœud

Même principe que la partie 4.1, sauf que les onglets sont propres au serveur sélectionné.

Rechercher : fonctionne de la même façon que décrit précédemment.

Résumé : se divise en plusieurs parties :

-le statut (Fig. 5) : nous obtenons des informations liées au serveur comme son uptime, sa charge, le pourcentage d'utilisation du processeur, l'utilisation de la mémoire, du fichier d'échange, l'espace disque, la version du PVE, la version du kernel sous forme texte à un instant t. Pour la partie historique de certains éléments, des graphiques sont disponibles.

Fig. 5 : Statut de notre serveur

-le pourcentage d'utilisation du processeur (Fig. 6) : il s'agit d'un graphique dynamique obtenu à l'aide de RRDtool [RRDTOOL]. Vous pouvez ainsi surveiller les événements anormaux qui seraient survenus.

Fig. 6 : Charge du processeur

-Serveur load : comme pour le graphique d'utilisation du CPU, nous obtenons un historique de la charge serveur.

-Memory usage : toujours sous forme de graphique, on visualise ici l'utilisation de la mémoire au fil du temps. Il y a une barre bleue sur le graphique qui nous montre le seuil de la totalité de la mémoire, ce qui nous permet de voir si le serveur est saturé ou pas et s'il faut le booster en RAM.

-Network traffic : ce graphique nous donne des indications sur les échanges réseau au niveau de l'interface ; vous pouvez observer les entrées et les sorties.

L'échelle de temps des différents graphiques peut être changée via la liste déroulante située à droite sur l'écran (Fig. 7).

Fig. 7 : Choix de l'échelle pour les graphiques de l'onglet « Résumé ».

Services : regroupe les démons qui sont lancés sur le serveur (Fig. 8). Leur gestion s'effectue soit en ligne de commandes, mais ce n'est pas le but, soit via l'interface. Il suffit d'en sélectionner un et de choisir l'action Démarrer, Stopper ou Redémarrer.

Fig. 8 : Liste des services lancés

Réseau : vous pouvez y changer les paramètres initialement spécifiés lors de l'installation. Attention aux modifications que vous allez opérer à ce niveau, au risque de ne plus pouvoir vous connecter sur votre serveur via l'interface web ou SSH.

DNS : on y paramètre les DNS (maximum 3), ainsi que le domaine.

Temps : c'est ici que l'on gère l'heure du serveur, ainsi que la zone.

Syslog : informations liées aux différents démons qui tournent sur le serveur.

Task history : ici, on pourra vérifier la bonne exécution de nos tâches planifiées (sauvegardes, etc.).

UBC : permet d'obtenir les messages/codes d'erreurs qui pourraient survenir au niveau des machines virtuelles.

Support : idem que décrit plus haut. Vous pouvez voir l'ID serveur unique généré pour votre serveur, à fournir lors de la souscription d'un contrat de support. C'est ici que vous uploaderez votre clé.

4.3 Page d'accueil avec sélection du stockage local du nœud)

On descend à nouveau d'un niveau pour arriver à l'espace de stockage local du serveur.

La partie Résumése scinde en deux parties :

-une partie Status vous indique si ce stockage est actif, son contenu, s'il est partagé ou non, etc. ;

-un graphique Usage permet de suivre l'évolution du taux d'occupation de l'espace disque.

Contenu : c'est ici que nous pouvons mettre à disposition des modèles ou les images ISO des systèmes d'exploitation que l'on souhaite virtualiser. Je m'explique : je vous ai parlé de paravirtualisation dans la première partie ; je vous avais dit que l'on allait utiliser le noyau de la machine hôte, donc toute l'arborescence d'un système GNU/Linux n'est pas nécessaire. D'autre part, ces modèles nous permettent de créer des machines virtuelles pré-paramétrées, comme une machine de type LAMP [LAMP] pour le développement web.

Concernant, la full virtualisation, il s'agit ici d'utiliser des systèmes d'exploitation autres que GNU/Linux. C'est donc au niveau de cet onglet que l'on pourra par exemple uploader l'ISO de NetBSD.

Permissions : c'est ici que l'on pourra ajouter un groupe ou un utilisateur, avec des droits particuliers pour permettre la gestion de l'espace local.

Après ce long descriptif de l'interface, étape néanmoins nécessaire pour la bonne prise en main de l'outil, nous allons rentrer dans le vif du sujet. Je vais vous proposer de créer deux types de machines virtuelles : une machine paravirtualisée et une full virtualisée.

5. Création d'une machine paravirtualisée

Pour l'exemple, on va s'appuyer sur un modèle provenant du site de Turnkey [TURNKEY]. L'opération préalable consiste donc à télécharger le modèle en question. Nous allons installer un serveur LAMP. Il faut donc se trouver sur le stockage local de notre nœud, se positionner sur l'onglet Contenu puis Modèles, choisir « Turnkey Lamp », puis le téléchargement débute (Fig. 9)...

Fig. 9 : Téléchargement d'un modèle

Ce modèle, une fois téléchargé, restera disponible pour d'autres VM à moins qu'il ne soit supprimé. Un petit bug pas méchant est présent : une fois le téléchargement terminé et le pop-up fermé, on ne voit pas le modèle. Un rafraîchissement du navigateur vous permettra de le voir apparaître dans la liste. Vous constaterez également, si vous vous positionnez sur l'onglet Résumé, que le graphique de la courbe a progressé au niveau de l'usage disque.

Pour créer une machine paravirtualisée, il suffit de cliquer sur le bouton Créer CT (CT pour container, terme employé pour une machine virtuelle paravirtualisée OpenVZ). Un pop-up s'ouvre dans lequel nous allons renseigner les différents champs pour le paramétrage de notre VM (Fig. 10).

Fig. 10 : Création d'un conteneur OpenVZ

5.1 Paramétrage de la machine

Dans l'onglet Général, on définit :

-le choix du serveur/nœud, ici « lp » vu qu'il n'y en a qu'un ;

-l'ID de la VM, donné par défaut en général ;

-le nom de la VM (Hostname) ;

-le pool de ressource ;

-le stockage : ici local par défaut, car nous n'avons pas encore ajouté de stockage supplémentaire ;

-le mot de passe root et sa confirmation.

Après avoir renseigné tous les champs, l'onglet Modèle devient actif. On y sélectionne le modèle « Turnkey Lamp » après avoir choisi le lieu de stockage (ici local).

Dans l'onglet Ressources, nous allons définir :

-la quantité de mémoire que nous allons utiliser,

-la taille du fichier d'échange (swap),

-la taille du disque (en Go),

-le nombre de processeurs.

Dans l'onglet Réseau, nous avons le choix entre deux modes :

-le mode « routeur » (routed mode venet) : permet l’interconnexion entre 2 réseaux différents (de classe différentes) ;

-le mode « pont » (mode bridge) : permet la connexion sur un réseau de même classe et masque de sous-réseau.

Ici, nous choisirons le mode routeur nous permettant de spécifier directement une IP au niveau de l'interface.

L'onglet DNS permet de spécifier d'autres DNS/domaines, mais nous optons pour la 2ème solution, qui consiste à conserver la valeur use host settings.

L'onglet Confirmation ne fait que résumer le paramétrage des onglets précédents.

On valide la création de notre VM via le bouton Terminé. Une fois notre pop-up fermé, on voit apparaître notre VM au niveau du nœud. La petite icône est celle du projet OpenVZ ; un clic droit vous permettra plusieurs actions au niveau de la VM : la démarrer, la migrer vers un autre nœud, l'arrêter, la stopper ou ouvrir un terminal (Fig. 11). Une fois la machine démarrée, l'onglet Résumé nous montre que le statut est passé à Running.

Fig. 11 : Options sur un conteneur OpenVZ

5.7 Automatiser le démarrage de la VM (si le nœud redémarre)

Il y a des options qui ne sont pas activées par défaut et qui peuvent poser problème. Nous venons de créer notre VM et si le nœud redémarre pour une raison quelconque, notre VM ne sera pas relancée. Pour pallier le problème, il suffit de se positionner sur notre VM, de cliquer sur l'onglet Options, de se positionner sur la ligne Démarrer au bootet de cliquer sur le bouton Éditer. Un pop-up s'ouvre nous permettant de changer la valeur, puis on valide en cliquant sur OK. La VM redémarrera automatiquement au démarrage.

5.8 Sauvegarde/restauration de la VM

5.8.1 Sauvegarde

Nous disposons de plusieurs scénarios concernant la sauvegarde. Nous allons aborder le premier sachant que le deuxième fera l'objet d'un autre paragraphe. Pour forcer la sauvegarde de notre VM, il suffit de se positionner sur l'onglet Sauvegarde, puis de cliquer sur Backup now. Il faudra renseigner trois paramètres :

-le lieu de sauvegarde, ici local ;

-le mode de sauvegarde, ici snapshot (instantané), mais vous avez le choix entre suspend et stopped. Dans ces deux derniers cas, la VM n'est plus joignable ;

-le type de compression, par défaut LZO (gzip est également disponible). L'archive occupera ainsi moins d'espace disque.

Nous cliquons ensuite sur le bouton Sauvegarde pour lancer le processus. Le nom du fichier est de type vzdump-openvz-100-2012_04_19-11_48_16.tar.lzo. La structure du fichier consiste en :

-le nom du programme de sauvegarde, ici vzdump-openvz(utilitaire faisant partie de la solution de paravirtualisation OpenVZ) ;

-l'ID de notre VM, ici 100 ;

-la date à laquelle a été faite la sauvegarde, ici 19/04/2012 ;

-l'heure à laquelle la sauvegarde s'est exécutée, ici 11h48 et 16 secondes ;

-enfin, l'extension du fichier compressé.

5.8.2 Restauration

Dans ce même onglet, nous disposons d'un bouton Restaurer. Il reste grisé tant que l'on n'a pas sélectionné une archive. Nous choisissons l'archive citée précédemment, puis nous cliquons sur Restaurer. Un pop-up s'ouvre nous indiquant le nom de l'archive, l'endroit du stockage, ainsi que l'ID de la VM ; on clique sur Restaurer pour lancer le processus. Une boîte de dialogue nous informe que nous allons définitivement écraser la VM actuelle, on confirme en cliquant sur Yes. Et là, dans notre configuration actuelle, nous obtenons une erreur liée au fait que la VM fonctionne et donc, que l'espace disque de celle-ci est monté et donc ne peut être écrasé. La seule solution est d'arrêter notre VM. Dans le cas d'une configuration possédant plusieurs stockages, le choix d'un stockage différent aurait résolu notre problème.

Après un laps de temps, les logs nous informent : Task OK. Notre VM a été restaurée. Il s'agit là encore d'une évolution de la version 2.0 de Proxmox. Dans la version 1.X, on ne pouvait que programmer les backups sans les forcer et on ne pouvait pas restaurer ceux-ci via l'interface.

5.8.3 Suppression d'un backup

Les sauvegardes peuvent vite s'accumuler et prendre trop d'espace disque ou simplement être obsolètes. Pour les supprimer, il suffit de sélectionner l'archive et de cliquer sur Supprimer.

6. Création d'une machine full virtualisée

Pour l'explication, j'ai choisi d'installer au hasard NetBSD [NETBSD]. J'ai donc téléchargé la dernière ISO de la version 6, qui est en bêta sur mon poste. Je dois l'uploader sur le serveur pour pouvoir m'en servir. Pour cela, il suffit de cliquer sur l'espace local du nœud. Ensuite, on se rend dans l'onglet Contenu, puis on clique sur Upload.

Un pop-up nous demande le type de fichier que l'on veut uploader : image ISO, dump OpenVZ, modèle OpenVZ. On choisit ISO, puis le fichier de l'image de NetBSD et on clique sur Upload. Une fois l'opération exécutée, on rafraîchit la page pour visualiser notre nouveau contenu. On peut passer à la création de notre nouvelle VM en cliquant sur Créer VM. Il faut alors renseigner un certain nombre d'onglets ; notez que l'onglet suivant ne devient actif que lorsque tous les champs de l'onglet courant sont renseignés.

Dans l'onglet Général, on définit :

-le choix du serveur/nœud, « lp » par défaut vu qu'il n'y en a qu'un seul ;

-l'ID de la VM, donné par défaut en général (incrémenté de 1 automatiquement, donc l'ID est passé à 101) ;

-le nom de la VM ;

-le pool de ressource.

Dans l'onglet OS, on déclare le type de système d'exploitation que l'on veut installer. Vous aurez le choix entre différents types de Windows, GNU/Linux (noyau 2.4 ou 2.6 et plus) et d'autres types d'OS (ce choix pour notre VM).

Dans CD/DVD, nous avons le choix entre :

-utiliser des images ISO en local ou autre stockage, dans notre cas l'ISO qu'on vient d'uploader ;

-utiliser le lecteur CD/DVD physique de la machine hôte ;

-n'utiliser aucun des cas précédents.

Pour le Disque dur, plusieurs paramètres sont à configurer :

-Bus/Device : le type de disque dur que l'on veut, IDE ou Virtio [VIRTIO]. Nous choisirons Virtio pour de meilleures performances ;

-Stockage : le lien de stockage de notre VM ;

-Taille du disque : par opposition à OpenVZ, on ne pourra pas changer dynamiquement la taille du disque, il faut donc penser dès le départ à choisir la bonne taille (nous prendrons 4Go pour nos tests) ;

-Format : RAW, QCOW2 (format de l'émulateur Qemu) et VMDK (format de disque VMware). Nous choisirons par défaut le format QCOW2, qui a l'intérêt de n'occuper en termes d'espace disque que ce qui est utilisé ;

-Cache : nous laisserons la valeur par défaut qui est None (pas de cache).

Dans l'onglet CPU, nous allons paramétrer tout ce qui touche au processeur :

-le nombre de sockets, ici 2 pour tester ;

-le nombre de cœurs, ici 2 également ;

-le type de CPU, par défaut Qemu64, mais sont aussi disponibles : 486, core2duo, Athlon... Intéressant pour mener certains tests ;

-une indication sur le nombre total de cœurs, qui équivaut au nombre de sockets multiplié par le nombre de cœurs.

On indique dans Memory la quantité de mémoire allouée à notre VM ; nous laisserons 512 Mo, qui sont amplement suffisants pour les tests.

Comme pour la VM paravirtualisée, nous pouvons choisir un mode réseau par pont, mais également :

-un mode NAT ;

-pas d'interface réseau ;

-le modèle de la carte, ici par défaut une Realtek RTL8139 (mais on aurait pu également choisir Virtio ou Intel e1000) ;

-une adresse MAC, ici on laisse la valeur auto ;

-une limitation du débit, nous laisserons la valeur par défaut qui est illimitée (Unlimited).

Comme pour notre VM précédente, l'écran Confirmation résume toutes les options sélectionnées. On lance la création en cliquant sur Terminé. La création ajoute notre VM à la liste des machines de notre nœud, mais ne la démarre pas pour autant. Pour ce faire, on effectue un clic droit et on choisit Démarrer.

7. Différence de gestion entre une VM paravirtualisée et une full virtualisée

Les VM full virtualisées ont moins d'onglets d'administration, dans la mesure où les paramètres ne sont pas évolutifs comme pour une machine paravirtualisée. Cette dernière étant tributaire de l'hôte, on pourra changer directement et dynamiquement un certain nombre de paramètres comme la mémoire, la taille du disque, le swap, etc., car il s'agit en fait, au niveau du stockage, que d'un répertoire qui contient notre VM et par défaut, qui se trouve dans :

root@lp:~# ls /var/lib/vz/private/

100

root@lp:~# ls /var/lib/vz/private/100/

aquota.group   bin   dev   fastboot   lib   mnt   proc   sbin   srvtmp   var   aquota.user   boot   etc   home   media   opt   root   selinux   sys   usr

On reconnaît bien l'arborescence type d'un système GNU/Linux. Pour limiter les ressources, comme par exemple la taille disque, OpenVZ ajoute deux fichiers à la racine de l'arborescence : aquota.user et aquota.group.

La VM full virtualisée fonctionne donc bien de manière autonome par rapport à l'hôte, d'où la rapidité de création de cette dernière par rapport à notre VM paravirtualisée. On pourra intervenir sur le matériel via l'onglet du même nom et on pourra changer notamment :

-la disposition du clavier,

-la mémoire,

-les processeurs,

-l'affichage, en choisissant la carte par défaut, une carte standard VGA, une cirrus logique GD 5446 ou enfin, une carte VMware compatible,

-changer le contenu du CD (les options sont les mêmes que lors de la création de la VM),

-changer le cache du disque dur ou spécifier de ne pas le sauvegarder,

-changer les paramètres du réseau.

Chaque type de virtualisation a donc ses avantages et ses inconvénients. Il reste néanmoins plus intéressant de se servir de la paravirtualisation dans le cadre de l'utilisation de GNU/Linux, sachant que les modèles nous font gagner un temps précieux et que les performances sont meilleures (il n'y a pas d'abstraction du disque dur par exemple, mais un accès direct au système hôte).

Une fois la VM démarrée, on s'y connecte via un clic droit, puis Console (qui lancera une session VNC [VNC]) afin d'installer notre OS. Par la suite, une connexion SSH suffira :)

8. Ajout d'un stockage réseau

On va maintenant ajouter un stockage réseau à notre centre de données (nous disposons d'un NAS au sein de l'entreprise). Pour cela, on sélectionne Centre de données, puis on se positionne sur l'onglet Stockage et on clique sur Ajouter. Dans notre exemple, nous choisirons NFS Share. On définit alors :

-l'ID de notre stockage, on lui donne un nom, par exemple « NAS » ;

-le serveur, l'IP de notre NAS : 172.20.1.60 ;

-l'export : suite au paramétrage du serveur, quand on clique pour obtenir le contenu de la liste déroulante, Proxmox va scanner le serveur distant afin de connaître les exports déclarés sur celui-ci ; dans notre cas, je choisis /data/proxmox (notre NAS nous sert déjà pour la version 1.9 de Proxmox en tant qu'espace de stockage) ;

-contenu : on définit quel type de contenu sera placé sur le NAS, ici Backups pour y poser nos sauvegardes, mais on peut également effectuer une multisélection dans la liste, en maintenant la touche [Ctrl] appuyée et cliquer sur les autres options comme images, ISO, templates... ;

-les nœuds : on peut laisser la valeur par défaut, qui permet à tous les nœuds existants d'utiliser ce stockage, ou alors uniquement l'affecter à celui de votre choix ;

-on coche la case activer afin de le rendre disponible ;

-le nombre maximum de backups (Max backups) à conserver.

On finit par valider notre paramétrage en cliquant sur Ajouter ; l'écran se rafraîchit et un nouvel espace de stockage apparaît au niveau de notre nœud, ainsi qu'au niveau de l'onglet Stockage.

9. Planification des sauvegardes

Nous avons abordé le forçage des sauvegardes précédemment dans l'article. Nous allons voir maintenant comment mettre en place le plan de sauvegarde de nos machines virtuelles.

On se replace au niveau du Centre de données et de l'onglet Sauvegarde. On clique sur Ajouter et on renseigne dans la fenêtre (Fig. 12) :

-le Nœud : on peut laisser la valeur par défaut, ainsi toutes les VM seront listées ;

-le Stockage : on choisit ici le NAS ;

-le Jour de la semaine : pour effectuer une sauvegarde quotidienne, il faut comme auparavant sélectionner toutes les valeurs de la semaine dans la liste ;

-l'Heure du début de la sauvegarde ;

-le Mode de sélection : toutes, inclure les VM sélectionnées ou les exclure ;

-un e-mail de contact : pratique pour être informé du statut de la sauvegarde ;

-le type de Compression : LZO par défaut ;

-le mode : Snapshot par défaut ;

On valide en cliquant sur Créer. L'écran se rafraîchit et nous donne les informations de la planification sous forme de résumé.

Fig. 12 : Plan de sauvegarde

10. Ajouter un nœud au centre de données

10.1 Avantages

J'ai une configuration identique au sein de l'entreprise. Nous avons deux nœuds Proxmox en version 1.9. Le premier est considéré comme maître et le deuxième comme esclave. Une fois la liaison créée entre les nœuds, il suffit de se connecter à la première instance pour piloter la 2ème. Il s'agit en fait d'un cluster Proxmox [CLUSTER].

L'avantage est multiple, notamment avec les améliorations de la version 2. Une fois la liaison créée, toutes les données de configuration liées aux VM seront répliquées en temps réel sur chaque nœud grâce au Proxmox cluster file system (pmxcfs), qui utilise l'utilitaire corosync [COROSYNC]. Le tout se gère en ligne de commandes via l'utilitaire pvecm [PVECM]. D'autre part, les VM peuvent être migrées d'un nœud à un autre à chaud.

10.2 Mise en œuvre

Conformément au wiki, je crée le cluster :

root@lp:~# pvecm create LINUXPRATIQUE

Generating public/private rsa key pair.

Your identification has been saved in /root/.ssh/id_rsa.

Your public key has been saved in /root/.ssh/id_rsa.pub.

The key fingerprint is:

[...]

Restarting pve cluster filesystem: pve-cluster[dcdb] notice: wrote new cluster config '/etc/cluster/cluster.conf'

Starting cluster:

   Checking if cluster has been disabled at boot... [ OK ]

   Checking Network Manager... [ OK ]

   Global setup... [ OK ]

   Loading kernel modules... [ OK ]

   Mounting configfs... [ OK ]

   Starting cman... [ OK ]

   Waiting for quorum... [ OK ]

   Starting fenced... [ OK ]

   Starting dlm_controld... [ OK ]

   Unfencing self... [ OK ]

Puis, on contrôle le statut :

root@lp:~# pvecm status

Version: 6.2.0

Config Version: 1

Cluster Name: LinuxPratique

Cluster Id: 32827

Cluster Member: Yes

Cluster Generation: 4

Membership state: Cluster-Member

Nodes: 1

Expected votes: 1

Total votes: 1

Node votes: 1

Quorum: 1

Active subsystems: 5

Flags:

Ports Bound: 0

Node name: lp

Node ID: 1

Multicast addresses: 239.192.128.187

Node addresses: 127.0.0.1

Tout fonctionne, notre cluster est initialisé et le nœud à partir duquel a été lancée l'opération a été ajouté automatiquement. Pour ajouter le deuxième nœud à notre cluster, on se connecte à celui-ci via SSH, puis :

root@lp2:~# pvecm add 172.20.102.114

[...]

root@172.20.102.114's password:

copy corosync auth key

stopping pve-cluster service

Stopping pve cluster filesystem: pve-cluster.

backup old database

Starting pve cluster filesystem

Starting cluster:

   Checking if cluster has been disabled at boot... [ OK ]

   Checking Network Manager... [ OK ]

   Global setup... [ OK ]

   Loading kernel modules... [ OK ]

   Mounting configfs... [ OK ]

   Starting cman... [ OK ]

   Waiting for quorum... [ OK ]

   Starting fenced... [ OK ]

   Starting dlm_controld... [ OK ]

   Unfencing self... [ OK ]

generating node certificates

merge known_hosts file

restart services

Restarting PVE Daemon: pvedaemon.

Restarting web server: apache2 ... waiting .

successfully added node 'lp2' to cluster.

On vérifie le statut du cluster :

root@lp2:~# pvecm status

Version: 6.2.0

Config Version: 2

Cluster Name: LINUXPRATIQUE

Cluster Id: 36955

Cluster Member: Yes

Cluster Generation: 8

Membership state: Cluster-Member

Nodes: 2

Expected votes: 2

Total votes: 2

Node votes: 1

Quorum: 2

Active subsystems: 5

Flags:

Ports Bound: 0

Node name: lp4

Node ID: 2

Multicast addresses: 239.192.144.235

Node addresses: 172.20.102.113

Fig. 13 : Visualisation du cluster et des nœuds

Conclusion

Nous avons vu de quoi est capable Proxmox en termes de virtualisation. Tous les aspects n'ont pas été abordés, notamment les rôles et droits au niveau des différents niveaux de l'outil, comme les pools, le stockage... Un autre aspect - mais qui, je pense, nécessiterait un article à lui tout seul - est la mise en œuvre de la haute disponibilité. J'invite ceux qui voudraient aller plus loin à consulter le wiki [WIKI], ainsi que le forum [FORUM] toujours source de connaissances supplémentaires.

Avec le recul, Proxmox ne m'a jamais déçu et on peut saluer le travail énorme qui a été fait depuis le début du projet [ROADMAP]. La version 2 apporte un lot de nouveautés tant au niveau de l'interface que dans la gestion fine des droits et permet dorénavant de se passer de la ligne de commandes pour l'administration, notamment au niveau des sauvegardes. L'essayer c'est l'adopter !

Références

[OPENVZ] : http://wiki.openvz.org/Main_Page

[KVM] : http://www.linux-kvm.org/page/Main_Page

[SENCHA] : http://www.sencha.com/products/extjs

[REQ] : http://pve.proxmox.com/wiki/Installation#Recommended_system_requirements

[SQUEEZE] : http://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_Squeeze

[NFS] : https://fr.wikipedia.org/wiki/Network_File_System

[PVEHA] : http://pve.proxmox.com/wiki/High_Availability_Cluster

[RRDTOOL] : http://oss.oetiker.ch/rrdtool/

[LAMP] : https://fr.wikipedia.org/wiki/LAMP

[TURNKEY] : http://gotofreedom.org/2012/02/turnkey-ajoute-le-support-dopenstack-proxmox-openvz-et-xen-a-ses-machines-virtuelles/

[NETBSD] : http://www.unixgarden.com/index.php/administration-systeme/a-la-decouverte-de-netbsd-saison-1-episode-2

[VIRTIO] : https://fr.wikipedia.org/wiki/Virtio

[VNC] : https://fr.wikipedia.org/wiki/Virtual_Network_Computing

[CLUSTER] : http://pve.proxmox.com/wiki/Proxmox_VE_2.0_Cluster

[COROSYNC] : http://www.corosync.org/doku.php

[PVECM] : https://pve.proxmox.com/pve2-api-doc/man/pvecm.1.html

[WIKI] : http://pve.proxmox.com/wiki/Documentation

[FORUM] : http://forum.proxmox.com/

[ROADMAP] : http://pve.proxmox.com/wiki/Roadmap