Proxmox 2/3 : outil de sauvegarde incrémentale pour containers OpenVZ

EDIT 1 : Après plusieurs mois de gestation le projet est désormais disponible ici :

La doc est sera bientôt disponible, ainsi qu’un forum pour les retours d’expérience.

EDIT 2 : Openvz-diff-backups fonctionne avec Debian 6/7 + OpenVZ et/ou Proxmox 2 & 3.

EDIT 3 : L’outil de backup ayant énormément évolué (euphémisme), ce billet est complètement « outdated ».

« Boarf… Un bon gros tar.gz de 137 Go, ça n’a jamais tué personne… » (Patrice B., réfractaire aux backups journaliers)

Avant, j’utilisais vzdump et mes cheveux backups étaient gras

Faire des sauvegardes c’est bien, les répliquer sur un serveur distant c’est mieux.

Sauf que, si vous vous amusez chaque jour à transférer les archives générés par vzdump, à mon avis ça va mal se mettre au niveau de la bande passante (sans parler de l’espace disque nécessaire pour conserver un historique décent).

Pour l’instant ma nobox ne contient que 50 Go de données (libres, toussa…) mais vu l’upload tout moisi que l’on a derrière une misérable ligne ADSL et le fait que je voulais quand même disposer d’une sauvegarde distante et journalière, fallait bien trouver autre chose que le transfert des tar.gz classiques.

Maintenant, j’utilise rsync et mon delta est resplendissant

Bon, ok, même si dans la pratique cette affirmation est globalement vraie (si, si…), il y a certains cas « particuliers » où cela ne se passe pas aussi bien. (Ben tiens ! On s’en serait pas douté…)

A chaque appel du script de sauvegarde, celui-ci va faire sa tambouille puis, afin de créer un historique, stocker dans un nouveau répertoire les différences par rapport à l’ancien backup.

L’archivage se fait à l’aide de liens hard en utilisant la directive « –link-dest » de rsync. Le principal avantage de cette méthode, contrairement à « cp -al », est que les changements de propriétaires ou de permissions sont pris en en compte sans impacter rétroactivement les anciennes sauvegardes.

Donc, en français dans le texte, cela signifie que, dès qu’une modification est détectée sur un fichier (taille, données, permissions, etc), rsync ne va pas créer un hard link lors de l’archivage mais tout simplement copier intégralement le fichier modifié.

Étant donné qu’il s’agit du comportement attendu et souhaité, jusqu’ici tout va bien.

Lire la suite…


Proxmox 2 : compilation d’un kernel OpenVZ à partir des sources

Comme dirait Luke : même pas mal ! (d’abord…)

A part occuper (un peu) les geeks et frimer (bêtement) sur IRC, ça sert à quoi ?

Si comme bibi vous avez soumis un bug auprès des développeurs d’OpenVZ, la première chose qu’ils vont vous demander c’est, justement, de reproduire ledit bug avec un kernel OpenVZ « stock ». Donc là, forcément, pas moyen, va falloir s’y coller.

Sinon, et c’est ce qui m’intéressait le plus, en ayant accès aux sources il devient alors possible de modifier certains modules du noyau car, croyez le ou non, certains paramètres utiles sont hardcoded. Non seulement c’est mal mais en plus ça ennuie tout le monde.

Bref, je voulais juste augmenter la taille de la file d’attente du scheduler SFQ (Stochastic Fair Queue) mais pour cela, il est nécessaire de modifier directement les valeurs dans le code source.

Étape 1/10 : récupérer le « Source RPM » qui va bien même qu’il y a tout dedans

Pour cela, direction l’espace de download d’OpenVZ : http://download.openvz.org/kernel/

La branche stable actuelle est la « rhel6-2.6.32 » donc z’allions fouiller à l’intérieur et nous poser sagement dans le répertoire « current ». Là, parmi les différents RPM, il y en a un qui contient le mot « src » (flash, flash…) et il est facile à trouver vu que c’est le plus gros.

Ensuite, tant qu’on y est, nous allons récupérer la config du noyau adéquate dans le sous répertoire « configs ». Deux choix possibles en fonction de votre processeur,  32 ou 64 bits.

Mais, j’aperçois quelques feignasses dans le fond, alors voici le lien direct : lien-magique-toujours-à-jour-vers-le-dernier-noyau-openvz

Bon, ok, elle est nulle mais comme le lien change à chaque mise à jour, il est plus sûr de chercher le bon fichier soi-même.

Lire la suite…


Auto-hébergement : configurer un cluster Proxmox 2 sans multicast

Ou comment interconnecter, via Internet et en Unicast, plusieurs noeuds Proxmox installés sur des réseaux distincts.

MAJ 30 mars 2012 : la version stable de Proxmox VE 2 est disponible et le billet est à jour. 🙂

Charlatan ! Le wiki de Proxmox 2 est formel : pas de multicast, pas de cluster

Oui mais non. (D’abord…)

Non seulement ça marche mais en plus, chose appréciable, la solution est plutôt élégante : suffit de faire tourner les noeuds Proxmox sur un réseau virtuel (supportant le Multicast) et d’interconnecter l’ensemble avec OpenVPN (en Unicast).

Bon, là, à priori et si vous êtes normalement constitués, z’avez les yeux qui brillent et la langue qui pendouille, sans parler du filet de bave qui coule le long de votre barbe encore tâchée par la pizza de la veille. (Ok, alors le cliché, ça c’est fait…)

Mais, halte camarades, rendons d’abord à César ce qui lui appartient car en fait (et sauf erreur), c’est « ned Productions Ltd » qui a dégainé le premier avec un tutorial (en Anglais) fort sympathique sur le sujet :

Configuring a Proxmox VE 2.x cluster running over an OpenVPN intranet

Ce que je vous propose ici n’est autre qu’une « traduction » libre, en français dans le texte, des différentes étapes à suivre avec en prime une petite touche de personnalisation car nous allons procéder d’une manière un peu différente.

En résumé, si après avoir lu ce billet vous n’y arriviez pas, franchement, je n’ai plus qu’à me pendre.

Retour en arrière : monter un cluster avec Proxmox 2, ça sert à quoi ?

A frimer dans la cour de récré…

D’abord, essayez d’oublier le discours marketing environnant et totalement merdique qui tente de vous vendre le « cloud » à toutes les sauces : l’intérêt majeur pour les hébergeurs est de rationaliser leurs coûts (donc plus de marge) tout en vendant un produit trois fois plus cher que sa valeur intrinsèque (donc encore plus de marge).

Proxmox, c’est d’abord un système de virtualisation (Open Source) qui permet de faire tourner plusieurs serveurs virtuels sur une même machine. Rien que ça, c’est déjà fort sympathique. (Si, si…)

Il y a deux modes de virtualisation possibles : Full Virtualization (KVM) et Container Virtualization (OpenVZ).

  • KVM : possibilité de faire tourner différents OS (Windows et Linux par ex mais nécessite un CPU avec instructions « VT »)
  • OpenVZ : uniquement des distributions utilisant un noyau Linux commun (celui de l’hôte, meilleures perfs)

Ensuite, vient le clustering qui permet de regrouper plusieurs serveurs Proxmox (les noeuds) au sein d’une même entité (le cluster).

Donc, supposons : vous avez chez vous un serveur Linux (normal pour un auto-hébergé) mais également un second serveur (lui aussi sous Linux) à votre disposition chez vos parents/amis/connaissances/autres auto-hébergés. (Rayez la mention inutile)

Avec un cluster, il est possible de déplacer une machine virtuelle d’un noeud à l’autre en un clic afin, par exemple, d’équilibrer la charge entre les serveurs. Il est également possible de faire des sauvegardes complètes (toujours en un clic) des machines virtuelles, synchroniser ces sauvegardes avec Rsync et, le jour ou un des deux noeud meurt (liaison ADSL coupée, panne EDF, météorite, attaque extraterrestre, etc), suffira juste de restaurer les machines virtuelles sur le noeud encore en vie, modifier les DNS et basta : les services repartiront comme si de rien n’était.

Bref, si avec tout ça vous n’êtes toujours pas convaincu que Proxmox « ça rox du poney » et bien retournez donc cliquer sous Windows. (Non mais c’te blague… Ces djeunz, ils ne respectent plus rien ! Et comme disait pépé : « de mon temps, on se contentait d’une orange à Noël… »)

Lire la suite…