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…


Question existentielle : je soutiens la Quadrature du Net, et vous ?

Ou comment rendre (vraiment) utile le pognon que l’on donne, à défaut d’être (politiquement) actif.

Je suis un lâche… Dans un monde idéal, on devrait tous harceler nos députés.

C’est pas l’envie qui manque mais bon, disons que je ne suis pas un « serial vendeur » : le genre de type qui vous déroule, sans relâche et à l’envie, une flopée d’arguments tout aussi irrésistibles que convaincants.

Pourtant nos députés, ils sont comme nous, c’est à dire influençables (dans le bons sens du terme, si les arguments sont légitimes).

Alors quand ils se positionnent sur leur « trône » afin de presser le (bon ?) bouton au sujet de l’acceptation ou du rejet tel ou tel amendement,  qu’ils aient en tête l’avis des « internautes », je pense que c’est un vrai plus.

Mais quand on ne sait pas faire, c’est simple : on délègue à ceux qui savent.

Ah ! Bah tiens, comme par hasard, la Quadrature du Net, elle sait faire…

Je ne partage pas entièrement leur vision mais cela relève du détail : ils militent pour un Internet libre, juste, et surtout pour une société capable de s’adapter aux nouvelles technologies.

Le dernier point étant bien sur, et de loin, le plus important. Pour l’instant « on » rame bêtement avec des futilités comme Hadopi ou ACTA mais le véritable enjeu est celui de la communication de masse, donc sans hiérarchie.

Car dans un avenir proche, ne le perdez pas de vue, terminé les médias « mainstream » ou la messe du 20 heures.

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…


Auto-hébergement : IOwait m’a tuer 1/2 (vmstat, mpstat, atop, pidstat)

« Rien à péter, je suis passé au SSD… » (Bernard M., passionné par la fuite en avant)

IOwait : le mal aimé

« IOwait correspond au temps d’attente du système pour l’écriture ou la lecture de données. Un IOwait de 10 % signifie que 10 % de l’activité du CPU n’est pas destinée à faire des calculs mais à attendre l’exécution d’une opération de lecture/écriture. » (Wikipedia)

Pour afficher le pourcentage d’IOwait, c’est « vmstat » qui s’y colle :

# vmstat 1

procs  -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r  b   swpd   free   buff   cache   si   so    bi    bo   in   cs  us sy id wa
1  0   7680  32200 353264 3111032    0    0 17173 19114  752  536   0  3 72 25
0  1   7680  31124 353376 3114680    0    0 12722 12798  799  569   0  3 75 22
0  1   7680  32916 353396 3114088    0    0  4592  4689  940  552   0  2 76 22
0  1   7680  33208 353432 3117292    0    0 20621 20533  739  592   0  4 77 19
1  1   7680  32096 353448 3119244    0    0 18426 18563  771  592   0  4 77 20

La colonne qui nous intéresse est la dernière, celle qui se nomme « wa ». Plus cette valeur (en pourcentage) est élevée, plus le processeur se tourne les pouces parce que les disques durs sont littéralement à la bourre et n’arrivent pas à suivre la cadence.

Notez que, jusqu’ici tout va bien : « seulement » 20% d’IOwait (mais attendez un peu la suite).

IOwait le retour : petite tentative de démystification

La plupart du temps, quand on cherche rapidement des infos sur le sujet, on tombe surtout sur des personnes plus stressées les unes que les autres : « IOwait à 100%, suis-je maudis ? », « Trop d’IOwait, mon serveur rame à mort. » ou encore « J’ai un load average de fou à cause des IOwait, que faire ? ».

Ceci étant, pas de panique car pour réduire les IOwait, il suffit d’appliquer une des solutions suivantes :

  • diminuer le nombre d’accès disque (Super, t’en as d’autres comme ça ?)
  • augmenter la charge du processeur (Gné ? Keskidi ?)
  • opter pour un processeur poussif (Chérie, fais gaffe, ce type est complètement con…)

Et pourtant, je vous assure que ça marche : installez cpuburn sur un serveur saturé au niveau des IO, lancez autant de burns que le processeur a de coeurs et admirez le résultat.

Félicitations, les IOwait sont maintenant à 0%, n’hésitez pas à demander une augmentation à votre boss…
(Cependant, si le CPU crame à cause de vos conneries, ça va être une autre paire de manche)

J’en vois certains qui froncent les sourcils et c’est bien normal : le nombre d’accès disques n’a pas baissé d’un pouce (et le processeur est à bloc), alors c’est quoi l’embrouille ?

Lire la suite…