Après quelques posts sur Proxmox qui dans l’ensemble ne rentraient pas tellement dans le vif du sujet, je vais ici vous expliquer comment faire un backup (dump) complet de vos machines virtuelles en mode snapshot.

Pourquoi le mode snapshot d’abord ? Pour savoir pourquoi il est mieux que les autres il faut savoir ce qui existe comme autre mode de backup et quels sont leurs particularités. En fait en tout il y a 3 modes de dump. Le premier, simple à comprendre est le mode « stop ». Il fait un « tar » de votre machine qui est à l’arrêt. Rien de plus simple ! Le second est le mode « suspend ». Il n’arrête pas complètement votre VM pendant la sauvegarde mais l’arrête quand même. Ce qui à la fin du mois fait que votre VM est down 20 minutes si vous faites un backup par jour. Ce qui est pas un problème si c’est sur un serveur perso. Mais si dessus vous avez un SLA, le client risque de venir gueuler. Pour les connaisseur « suspend » utilise simplement la commande rsync.

Le troisième mode est le mode snapshot. Et c’est le mieux ! Il permet de faire une sauvegarde complète de votre machine virtuelle en fonctionnement sans l’arrêter. Le problème est que le mode snapshot doit obligatoirement se faire sur des partitions en LVM. En fait ce mode utilise simplement une particularité du LVM, qui est, je vous le donne en mille émile, les snapshots.

Ce qui suit est une explication assez simple de comment créer des partitions LVM à l’installation de votre machine en passant par le manager d’OVH. L’idée finale est d’avoir ça :

Je m’explique. La partition 1 est la partition qui aura votre système. 10Go c’est suffisant. Sauf si vous êtes sur Windows…La partition 2 c’est la swap. 2Go c’est une habitude. De toute façon on a tellement de Ram maintenant que la swap est très rarement utilisée. La partition 3 est une partition LVM qui va comprendre toutes les données de Proxmox. En effet tout est stocké dans /vz (qui est la même chose que /var/lib/vz). La partition 4 est aussi une partition LVM qui va vous permettre de faire vos dumps entre la partition 3 et celle ci. La partition 5 faite là, je vous explique quelques lignes après à quoi elle sert.

Maintenant que vous avez votre partitionnement fait. Lancez l’installation.

Je vais donc vous expliquer à quoi sert cette partition 5. En fait ce post le fait mieux. Mais je vais quand même faire rapidement un résumé. Pour faire la copie des données entre la partition 3 et 4 il faut un espèce de cache. Dans le post c’est noté qu’il faut 512Mo de place. J’ai testé mais vzdump me demande 1024Mo. Dans un esprit de « je prends large on sait jamais » j’ai mis 2Go…

De toute façon une fois votre système installé vous avez juste à faire ça :

umount /var/freespace
lvremove /dev/pve/freespace

Maintenant vous pouvez tester, le mode snapshot de vzdump marche. Et c’est magnifique ! Je dis ça parce que j’en ai particulièrement chier pour le faire marcher (2 jours c’est long ?).

Petit test :

vzdump --snapshot 101

et dans /vz/dump vous avez le dump de votre VM 101. Et n’oubliez pas de mettre d’autres options à vzdump. Comme –mailto et –compress.

Bonnes sauvegardes !

Quand on utilise un système de virtualisation pour héberger des serveurs, à un moment donné il faut migrer les VM sur un autre serveur physique. La virtualisation doit permettre un down du serveur minime et une administration faible. Je vais donc vous expliquer comment faire avec Proxmox.

La première étape est d’avoir au moins 2 machines. Sous Proxmox c’est assez simple. Je ne vais pas vous refaire toute la documentation officielle du site. Il suffit d’aller ici : Cluster Proxmox

N’oubliez pas que votre nouveau serveur est votre Master dans le cluster. Sauf si vous comptez garder vos 2 serveurs.

Une fois votre cluster opérationnel, il suffit d’aller dans la liste de vos machines virtuelles et de simplement cliquer sur « Migrate ». Selectionnez ensuite vers quelle machine physique vous voulez réaliser l’opération et il ne vous reste plus qu’à attendre. D’après mon expérience, comptez 1h d’attente pour 50Go de données.

Une fois que la migration physique est faite, il va falloir re-router l’ip de vos VM vers votre nouvelle machine (là débrouillez-vous !). Ensuite tout est beau et magnifique. Vous pouvez maintenant profiter de la vie et plus faire des réinstallations en série. Elle est pas belle la vie ?!!

Proxmox 1.4 vient de sortir en béta. Avec cette première béta (il y en aura certainement d’autres avec notamment un nouveau kernel) la dev team propose de tester un nouveau modèle de stockage. Proxmox prend désormais en compte les disques iSCSI, NFS et intègre le DRDB. Que du bonheur

Avec l’ajout des disques réseaux (oui j’évangélise !), de nouvelles dimensions s’ouvrent aux utilisateurs de Proxmox. Il est par exemple possible de faire des backups en mode snapshot (sans aucune coupure de VM, donc totalement transparent) sur un autre serveur complètement dédié aux backups. Et ça sur n’importe quel node (serveur non master) de votre architecture de virtualisation.

DRDB sont les initiales pour « Distributed Replicated Block Device ». Pour faire simple, cette technologie permet de répliquer en temps réel et via le réseau un disque dur (ou bien souvent une partition). On appelle souvent ce procédé du « Raid1 over network ». Mais qu’est ce que ça à voir avec Proxmox me direz vous. C’est très simple. Si vous devez avoir des VM disponibles en permanence, il vous suffit d’avoir 2 serveurs identiques, et tout sera identique. En cas de problème sur un serveur, il suffit de tout balancer sur le second sans que personne ne s’en aperçoive ! Couplé à une ip-failover, ce système permet d’avoir une très très haute disponibilité ! Pour un prix assez raisonnable.

Bon maintenant il me reste plus qu’à trouver le budget pour tout mettre en place !

Et pour ceux qui ne savent pas ce qu’est Proxmox, c’est par ici.

La virtualisation est à la mode. Pourquoi ? Simplement pour une question d’argent. Et comme c’est la crise…Et surtout c’est vachement bien pour maintenir des serveurs. Je vais donc vous présenter Proxmox et son petit ami OpenVZ.

On va y aller doucement. Commençons par le coeur. Commençons par OpenVZ. C’est une technologie permettant la virtualisation de système d’exploitation Linux. Ce cher OpenVZ est Open Source sous licence GNU2 et est développé par SWsoft (Plesk par exemple). Quand je dis virtualisation je me trompe, mais consciemment. Car là où des technologies comme VMWare sont très lourdes, car justement elles virtualisent complètement le système d’exploitation, OpenVZ garde le même Kernel Linux (donc le même moteur) pour toutes les VM. On va donc plutôt appeler ça de la para-virtualisation. Donc si vous suivez, cette para-virtualisation permet d’avoir des VM tournant que sur Linux. A ma connaissance, Windows n’a pas de Kernel Linux donc oubliez. Mais de toute façon qui utilise encore Windows ?

OpenVZ c’est bien mais pour faciliter son utilisation, il existe un certain monsieur Proxmox qui est en fait une interface web permettant l’administration de son serveur master très facilement. Grâce à Proxmox vous pourrez démarrer, arrêter, migrer vos VM en 1 clic mais aussi créer, modifier, supprimer, backuper vos VM en 2 clics tout en modifiant la RAM, le disque dur, le CPU en 3 clics. Ce système permet une très grande flexibilité.

Alors maintenant l’utilisation que j’en ai m’amène à avoir 4 serveurs virtuels sur un serveur physique (2Go de Ram) qui n’est pas une bête de course. Avec ce système vous avez ainsi la possibilité de créer une machine de production (ou plusieurs) avec 1Go de RAM. Mais si votre/vos site(s) grandissent. Vous migrez en 1 clic sur un autre serveur sous Proxmox (over SSH). En 2 clics vous augmentez la RAM, le CPU et le disque dur et tout cela sans interruption de service. C’est pas magique ? Donc même pour une seule VM c’est très utile et permet un gain de temps considérable !

Côté performances la virtualisation via OpenVZ ne prend que très peu de ressources en plus (2/3%). Pour rentrer dans la technique chaque VM est un processus de votre serveur physique. Ce qui permet aussi de démarrer/arrêter/rebooter en moins de 5 secondes.

Autre avantage du partage de Kernel. La Ram système est commune. Vous vous en rendrez compte avec les images plus bas, mais si l’addition des différentes RAM est de plus de 1Go, la RAM physiquement utilisée est de 600Mo. C’est beau le partage de kernel hein

Petite information pour les plus connaisseurs, Free/OpenBSD sont entrain d’intégrer le même système de para-virtualisation. D’ailleurs un ami n’utilisant qu’OpenBSD est tombé sous le charme d’OpenVZ

Ps: Proxmox permet aussi de la « vrai » virtualisation de systèmes comme Windows via KVM. Mais bon on s’en tape de ça

Lire la suite »