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 ?!!

Il y a quelque chose qui me préoccupe pas mal depuis quelques temps, c’est le web en temps réel ou real time web. C’est le buzz word de ces dernières semaines, notamment de l’autre côté de l’atlantique. Personnellement je m’y intéresse depuis le début de l’année 2009.

J’ai testé plusieurs solutions, toutes plus révolutionnaires les unes que les autres. Toutes plus performantes les unes que les autres. Mais au final il y a un problème. La base de donnée. Pour comprendre, une explication s’impose.

Le RealTime Web est né d’un principe simple. Que l’internaute qui est sur un site soit informé en temps réel d’un changement. Par exemple vous publiez un article sur votre blog, sous quelques secondes, tous les abonnées à votre flux rss le reçoivent. L’idée n’est donc plus que le client (l’internaute) demande les données au serveur mais que le serveur envoie les données quand elles sont modifiées. On passe du Pull au Push. Un peu comme pour les mails sur nos magnifiques smartphones modernes.

Il y a donc en permanence une connexion d’ouverte entre le client et le serveur. Ainsi votre serveur agit comme un serveur de streaming. Tout est en temps réel. Niveau performance, avec un serveur bien fait, on peut monter très haut en connexion simultanées. Ajax Push Engine promet 100 000 connexions, mais je n’ai pas testé ! Dans tous les cas préférez un serveur codé en C qu’en PHP et Nginx à Apache. Pour le coup moi j’ai quelques attirances vers Python + Nginx, mais chuuut

Votre serveur peut ainsi aller chercher une information comme par exemple dans une base de donnée et renvoyer le tout aux clients intéressés. Sur le principe c’est beau et magique. Mais la réalité est plus sombre. Pour que vos internautes soient avertis en temps réel il faut que votre serveur sache quand envoyer les nouvelles données et il doit interroger en permanence la base de donnée. Le problème est donc à ce niveau. Car le serveur doit faire des requêtes disons toutes les secondes. Si il doit vérifier quelques entrées c’est bon, mais imaginons qu’il y est 100 000+ entrées à vérifier. Vous voyez le problème ?

C’est pourquoi il faudrait que les bases de données implémentent un système de callback. Lors d’une modification d’une entrée, il suffirait d’envoyer un ping au « serveur de temps réel » pour qu’il vienne vérifier l’information. Car les bases de données n’ont pas été faites pour être active mais passive. Elles donnent des informations, mais ne les envoient pas. Et c’est pour moi un vrai problème.

Voilà où j’en suis actuellement dans mes réflexions ! Si quelqu’un en sait plus, ou veut m’expliquer quelque chose, ou n’a rien compris, les commentaires sont ouverts

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.

Après PHP et Ruby On Rails sur Nginx, on s’attaque maintenant au Python et a son formidable framework qu’est Django. Et je peux vous le dire tout de suite, un serveur comme Nginx avec la stabilité de Python font qu’avec ces technologies vous pouvez aller loin, très loin niveau performance !
Pour information, je suis monté à plus de 500 pages servies par seconde (d’un blog sous Django) en utilisant moins de 100Mo de Ram (pour les processus Python) et 20% d’un CPU Core2Duo E7200. Plutôt pas mal ! La même chose avec Apache et PHP et vous voilà avec un serveur down :/

Dans un premier temps il faut installer Python/Django sur votre serveur. Vous pouvez suivre ce que dit le site officiel (ce que j’ai fait) ou l’installer via:

apt-get install python-django

Si vous avez pas ce qu’il faut d’installé, apt devrait vous proposer de le faire

Maintenant configurons Python en FastCGI.
Pour lancer un serveur python pour voir votre projet Django il faut aller dans le dossier de votre projet et lancer le fameux serveur

apt-get install python-flup
 
cd /var/www/projet_django
 
python manage.py runfcgi method=prefork host=127.0.0.1 port=8000 pidfile=/var/run/projet_django.pid

Lire la suite »