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…
« 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…
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é.
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…
Quand je ne sais pas, je ferme ma gueule
Ou : « les labs ça ose tout, c’est à même ça qu’on les paye »
(Sinon faut demander poliment à ceux qui savent et là on peut discuter)
Vous l’avez forcément croisé. Mais si, rappelez-vous, le grand dadais qui s’était lancé dans de grandes explications métaphysiques sur la sexualité des mouches. Ayé ? Ça vous revient ? Au bout de trente secondes vous aviez compris que cet énergumène ne faisait pas la moindre distinction entre mammifères et insectes.
Maintenant que vous avez situé le gus en question, prenez garde au lien qui suit.
Afin de préserver la santé mentale des nerds à poil dur, je n’ai pas osé utiliser la balise « <a> » mais je vous préviens : c’est du gros calibre. Et attention, même si ça rigole déjà dans le fond, préparez-vous car celui là il est balèze. Sur l’échelle de Richter, il est bien au delà de 15. (Chuck Norris serait son élève)
Non, ne cliquez pas, vous êtes prévenus : http://labs.hadopi.fr/actualites/linternaute-ce-parletre
Et si la démonstration (d’autrui) est nulle, on ne répond pas
Ou : « On ne parle pas aux labs, ça les instruit »
(Effet de bord : ils vont taxer encore plus les contribuables pour trouver des « experts »)
Face à tant de lyrisme dans un argumentaire aussi bancal qu’approximatif, certains ont trouvé le courage de répondre. Si, si ! Même que c’est vrai : des « humains » ont déployé une énergie titanesque pour tenter d’établir une « connexion » avec ce martien. (Ce qui relève, soit du sacerdoce soit de la psychiatrie. Dans les deux cas, l’esprit est louable).
Et puis, ils y a ceux qui savent à peu près (pléonasme) de quoi on cause.
La réponse est donc à la hauteur de l’énoncé : violente et argumentée. Non seulement sur la forme mais aussi sur le fond. Autant je comprends la volonté de répondre à un billet bourré d’amalgames, autant perdre son temps pour démonter point par point les élucubrations d’un ovni me laisse « admiratif » (dans le bon sens du terme).
Cependant, comme la contre-attaque est intéressante : Hadopi Labs : 35% de socio, 100% de pipeau
Lire la suite…
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 »
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…