bah pour la gestion des VM base'es sur des screenshots, il n'y pas le choix. ZFS est simplement plus robuste que LVM dans ce cadre l`a (zvol snapshot clones). Sinon pour des vdisks classiques, oui ZFS ou LVM kiff kiff bourico.
Je te fais confiance, connaît pas ZFS. Coté volumes LVM pour Xen et snapshots pour les sauvegardes, c'est nickel aussi.
Ce que je voulais faire, c'était de la migration à chaud. Dans un process automatique, éventuellement avec une prise de décision automatique (ce dernier point étant débattable, je me méfie comme de la peste des "automatismes de décision" fondés sur des conditions).
ah bah l`a c'est un tout autre sujet. tu veux un orchestrateur. Ganeti en avait fait mais tourne avec DRBD v8.
Connais un peu Ganeti. Je l'avais recompilé pour le tweaker. Faut le vouloir (le mix Python Haskell est pervers, enfin l'environnement Haskell n'est pas simple), très bonne idée mais c'est du code ancien, malaisé avec ce duopole de langage et qui ne gère pas le mode PVH de Xen, donc on a pas poursuivi.
si je comprends bien votre profil, nous avons des gouts similaires et de fait, OpenStack (Nova) est tout `a fait hors de question ;-)
On est Kiss oriented. Pour nos besoins qui restent modestes ;)
je re'fle'chis personnellement `a avoir un orchestrateur distribue' sur les nœuds, afin d’éviter d'avoir un service de'die' `a la vCenter.
On a ça sur une bécane dédiée, en dehors du réseau géré. Bécane qui est aussi la supervision. Notre truc est tout en commande SSH, rien sur les clients (nodes ou instances). Idem pour notre supervision.
ah non la gestion primary/secondary (et dual-primaries un bref instant) est entirerement automatique, il n'y a rien `a faire. la migration `a chaud sur une base DRBD fonctionne out-of-the-box. Je vous fais une demo quand vous voulez )
En labo oui, en vrai non (en tout cas chez nous). Oui, faut passer ça en dual primary le temps de la migration. Tout dépend de la stabilité du réseau, je suppose. Peut-être que le vRack n'est pas DRDB friendly ou je m'y suis mal pris :()
Et quant au reseau bah c'est transparent aussi (de memoire, ARP gratuitous, et pas besoin de re'fl'echir aux e'tats TCP et cie puisque les IP ne changent pas, les sessions SSH par exemple survivent la migration `a chaud).
Oui et non, on peut faire ainsi et créer un SPOF sur les IP, ou galérer avec des IPFO à balader, et la tempo qui va avec, l'absence de migration à chaud qui en découle et on limite le SPOF. Tout le compromis.
Je n'ai pas pu, en boucle, faire tourner ça des dizaines de fois, sans que ça foire à un moment, donc useless pour moi. C'était peut-être le réseau, mais bon, le vrack OVH, ça marche. La lecture attentive des sources de DRDB m'a un peu achevé. C'est comme regarder les sources ISDN (RNIS/numeris) d'Asterisk (expérience d'il y a 15 ans). En regardant le tas de spaghetti, les rustines, toussa, on soupire et on comprend mieux pourquoi c'est chaud et pourquoi la peinture ne sera jamais sèche ; il faudrait tout réécrire.
je ne suis pas alle' jusque l`a
T'as bien fait.
, mais je compense en sachant comment re'tablir une resources DRBD en status "Inconsistent". Dans tous mes PoCs je n'ai jamais perdu de donne'es et ai toujours pu re'tablir les resources en mode optimal. Je n'ai rencontre' de re'els probl`emes que si je monte trois+ dual-primaries (pour faire du GFS), mais c'est un cas de figure qui m'est pas officiellement supporte', donc de'conseille', et je confirme que c'est gal`ere lors de la maintenance, meme si cela fonctionne.
DRDB, on l'avait également utilisé en 2010 et quelques... avec, comment ça s'appelait ? REMUS ? Tu sais le truc pour faire de la machine "immortelle" (pardon de la haute-dispo) : tu prends (mini) 2 bécanes avec au moins 2 cartes réseau, chaque bécane est connectée au réseau et les deux bécanes ont au moins une connexion directe (nous on avait du au moins bounder 2 interfaces pour que ça écoule un minimum). Ensuite tu démarres un doze sur une instance sur la bécane A. Elle est exécutée en miroir sur la bécane B. T'es en connexion VNC sur ton instance qui supporte le dodoze en plein téléchargement d'une iso Debian et tu débranches A. Le téléchargement se fige une demi-seconde et reprend, le temps que l'instance active soit devenue celle de B. Totalement inefficace mais diabolique. On s'est même amusé à débrancher des disques, des barrettes RAM et même dégager un CPU de son support, le tout sous tension bien sûr ;>>> Pas de casse, haute dispo toujours OK ! Par contre, la reprise de l'instance coupée (resynchro) prenait un max de temps... https://www.usenix.org/legacy/event/nsdi08/tech/full_papers/cully/cully_html...
Rien que le bidule à base de volaile (COQ) pour aller faire correspondre la version des sources avec la version du noyau était une horreur. Finalement, j'allais me servir dans les dépôts Proxmox. Au moins, eux, ils avaient la bonne réponse ;)
ah oui j'admets que leur truc de patch `a la vole'e c'est quand m^eme limite... Bon, suffit de pas avoir le dernier noyau qui vient de sortir, et le module drbd v9 se laisser compiler (si je me souviens bien, il existe des cas o`u le patch `a la vole'e n'est pas necessaire, mais j'ai peut-^etre re've').
Leur bidule au poulet "calculait" comme une poussin malade. Je l'ai pris en flagrant délit d'erreur. À la fin, je n'avais confiance que dans le dépôt Proxmox :)
Mais si tu me dis que tu y es arrivé, de façon systématique et récurrente, sans aucune erreur, dans un vrai réseau (pas un lab, en lab ça marche), c'est que j'ai loupé une marche, ce qui est très possible :)
oui oui c'est stable et performant dans tous mes PoCs bare-metal comme nested. reste `a voir ce que cela donne en prod.
J'ai aussi laissé tomber aussi car nos instances d'hébergement sont organisées en triplettes (proxy/https/micro cache > serveur ouaib/cache fast_cgi > cache redis / mysql). Ça permet d'allouer efficacement les ressources avec des perfs de tueur. Genre un site marchand wordpress/woocommerce qui tourne à la vitesse d'un site statique (j'ai des preuves :). Les trois instances sont sur le même node et elles discutent entre-elles par un réseau interne à la carte-mère (un bridge), donc les débits sont justes monstrueux et n'impactent pas. Quand je bouge une telle entité, c'est 3 instances qui bougent. Bref, pour tout un tas de raison, ça devenait trop compliqué... -- Stéphane Rivière Ile d'Oléron - France