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…


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…


Auto-hébergement : ma ligne ADSL est morte, que faire ?

Bien fait ! Fallait y réfléchir avant…

Note à moi-même : configurer d’urgence un MX secondaire, planifier un hébergement de secours, acheter un second modem/routeur (on sait jamais…) et ne pas oublier d’ajouter le café ainsi que le sucre à la liste des courses.

Bref, mardi dernier dans la matinée, je sirotais tranquillement mon déca-cappuccino-triplement-recaféiné et paf : plus de débit, plus de ping, plus de connexion, plus rien.

Comprenez-moi bien : trois visiteurs déboulent chaque jour sur ce blog et, de ce fait, une interruption de service n’est pas envisageable. Bah vi, ce serait une perte grave pour l’humanité toute entière car Internet serait diminué.1

Gestion de crise dans la panique : comment gruger « Elle-Sait-Faire »

Dans l’immédiat, le problème n’est pas de savoir pourquoi la ligne ADSL a sautée mais de rétablir la connectivité au plus vite.

J’ai smartphone, OK. C’est un Android, OK. On peut faire du tethering, OK. SFR interdit formellement cette pratique dans ses CGV si on n’a pas souscrit cette option au prix fort, OK.

Heu… Ah non, zut ! Bon, faut voir. Non, en fait, et après avoir mûrement réfléchi 3 secondes : rien à foutre.

Lire la suite…

  1. Si vous ne voyez à qui je fais allusion, votre éducation est à refaire. ^^

Auto-hébergement et QOS 2/7 : centraliser et NATer les flux sortants

Suite de l’épisode précédent : Auto-hébergement et QOS 1/7 : comment télécharger comme un goret.

« un routeur qui commute des paquets, c’est bête à manger du foin »1

Aujourd’hui on va piquer à la Chine ce qui a fait sa fierté nationale, à savoir « Chinternet » . Parce que bon c’est vrai quoi, nous aussi on a le droit d’avoir un accès Internet bridé, filtré et censuré.

Afin d’atteindre cet objectif, il est nécessaire que tout le trafic réseau (entrant et sortant) passe par la nobox. Je ne vous fais pas un dessin, on va donc instaurer un point unique de centralisation avec tous les effets de bord que cela comporte.

Bref, pour devenir un dictateur en puissance, z’avions deux solutions : remplacer la machinbox par n’importe quel Linux de base (mais ça va se voir) ou gentiment proposer à notre entourage « d’optimiser » leurs paramètres de connexion.

Comme la naïveté l’emporte toujours, il y a fort à parier qu’ils ne remarqueront pas le tout petit changement insignifiant qui consiste à modifier l’adresse IP de leur passerelle par défaut. Après ça, souriez, c’est du billard.

Depuis que ma nobox intercepte les connexions, c’est du fun à tous les étages

On peut modifier la passerelle par défaut de chaque équipement de deux façons : soit à la main (en se cognant le paramétrage sur chaque appareil), soit d’une manière beaucoup plus fourbe en installant un serveur DHCP sur la nobox. (N’oubliez pas ensuite de désactiver le DHCP de la machinbox car sinon ça va être la foire d’empoigne et au final, vous allez vous faire gauler)

La seconde méthode est de loin la plus élégante car la configuration est centralisée, vos « sujets » n’y verront que du feu et on peut assigner des IP fixes tout en réservant un pool d’adresses pour les nouveaux équipements qui voudraient se joindre à la fête.

Et si les « dissidents » au sein de votre joyeux foyer ne jurent que par le WiFi, même pas peur, ça marche aussi. (Pas besoin de configurer un Access Point sur la Nobox)

Lire la suite…

  1. Qu’est-ce qu’Internet ? 1/3, à la 37ème minute