Re: Système de sauvegarde distribué, participatif et souverain.
Bonjour Pierre-Philipp, Xavier Désolé pour la réponse tardive, je ressorts mollement d'une grippe intéressante, la dernière datait de 2016. Il en faut de temps en temps pour maj le SI :)
Perso je suis un fan de DRBD et ils ont un module pour les longues distances https://linbit.com/disaster-recovery/ Cette option ne semble pas libre, mais c'est intéressant :) je sais pas si DR est libre ou pas, ce serait dommage car DRBD lui-meme est bien libre. https://github.com/LINBIT/drbd
Linbit a toujours eu un mal de chien à monétiser son travail. DRDB est libre mais tout ce qui tourne autour ne l'est pas... trop.
J'avais des résultats allant de spectaculaires à plantés (sans vraiment comprendre parfois). Bon en local ça marche, mais de DC à DC... J'ai trituré toutes les options possibles pour voir, testé DRDB 8 et 9 (à l'époque, je ne sais plus où ils en sont). Je dois être moins doué qu'AWS ;>>>
moi j'ai des bon resultats en terme de perf et je pense que j'ecrase Ceph RBD assez facilement. ce serait normal d'ailleurs, car il n'y a aucun overhead (pas de hash table ou d'algo de distribution, juste des configs qui point vers des paires de noeuds variees). en plus c'est ideal pour un cluster convergent, c'est meme fait pour, alors qu'avec Ceph RBD faut quand meme se poser la question de savoir si les noeuds supporteront la double charge (virtu + stockage). Bon et puis CephFS il n'y a pas le choix, c'est force'ment un autre cluster de'die', mais c'est un autre cas d'usage.
CEPH n'est pas KISS. Ce simple fait suffit à ne pas aller plus loin pour moi. DRDB est KISS, mais...
je joue beaucoup avec. Je fais des cluster XEN et utilisais LVM2 et maintenant OpenZFS zvol **sous** les resources DRBD. il faut noter que DRBD v8 inclus dans le noyau nunux fait simplement des mirrors, alors que DRBD v9 sait aussi faire du diskless, donc un noeud qui n'a pas de mirroir local peut aussi voir les volumes.
Oui. J'ai testé les deux. DRDB9 a plus de possibilités, comme d'avoir n miroirs (1 master 2 slaves, ça peut être bien). Pas testé avec ZFS, je croyais même que ZFS et DRDB étaient incompatibles...
J'ai aussi fait des tests avec les snapshots, c-a-d qu'on peut faire des templates sur des vdisk normaux (des resources DRBD quoi) et puis des snapshots soit LVM2 soit ZFS pour obtenir des instances base'es sur ces vdisks. C'est funky et pas pret pour la prod j'en conviens, mais bon dans mes PoCs pour l'instant cela marche. J'ai parle' de mes peurs concernant LVM2 ici: https://www.youtube.com/watch?v=gUnFc99VfTo&list=PLQMQQsKgvLntZiKoELFs22Mtk-...
Ta vidéo est très intéressante et reflète mes propres recherches. Toutefois j'ai appris des trucs aussi, merci ! La salle est très sympa mais il est choquant de voir qu'il y a si peu de gens à t'écouter (i.e à se poser les bonnes questions, même non conventionnelles). J'ai la même impression concernant un langage que je promeus depuis longtemps, Ada.
J'ai pouss'e le vice jusqu'`a tenter la convergence re'seau en plus de la convergence XEN + DRBD: https://pub.nethence.com/network/fuck-martinez-part4
Ouah, son site, on dirait (presque) du gopher :> En pratique ? Pour nos use cases ? mmm... Mais j'ai gardé les liens :)
Comme j'ai pas trouvé d'équivalent sous Linux (dans mon use-case), je rêvais à me mettre à FreeBSD/ZFS qui semble avoir ce qu'il faut nativement, lui. Mais, une seule vie, pas assez de temps :)
ah non c'est l'inverse. FreeBSD HAST n'est probablement pas capable de faire du dual-primaries, ce qui est absolument ne'cessaire lors de la live-migration d'une instance XEN d'un noeud `a l'autre, ne serait-ce que pendant une micro-seconde. Je n'ai jamais essaye' HAST et cela reste `a faire (si un jour vous vous ennuyez, on pourrait faire cela ensemble en visio). Quant `a ZFS c'est juste un gestionnaire de volume + filesystem, pas un outils de stockage distribue' en soit. Ceux qui s'en servent comme cela jouent sur la fonction re'seau mais il n'y a qu'un seul controlleur, c'est le client. Un peu comme du RAID ge're' avec un seul controlleur. Avec DRBD et HAST c'est deux tetes, deux controlleurs. Et en plus duellement actif avec DRBD si besoin. De la magie pure !
Je n'ai pas été jusque là. Jamais utilisé ZFS, par manque de temps (je suis curieux par défaut) et pragmatisme puisque Xen + GNU/Linux Debian + mdadm + lvm2 forment une stack avec une stabilité qui s'oublie, donc pas cherché plus loin. 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). Après plein d'essais, allant de magie noire (quand ça marche, c'est beau) à la migration avortée, jusqu'à la destruction instantanée et inexplicable du volume LVM (et... non ! je ne m'étais pas emmêlé les scripts dans les primaires/secondaires), j'ai enfin admis que c'était overkilled par rapport aux besoins de l'infra. Nos clients peuvent supporter une coupure de quelques minutes (transfert de la VM, maj IPFO, maj routage+FW du node, maj IP de l'instance - pointopoint). 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. 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 ;) 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 :) -- Stéphane Rivière Ile d'Oléron - France
Oui. J'ai testé les deux. DRDB9 a plus de possibilités, comme d'avoir n miroirs (1 master 2 slaves, ça peut être bien).
ah oui `a voir... je n'ai jamais teste' deux slaves.
Je n'ai pas été jusque là. Jamais utilisé ZFS, par manque de temps (je suis curieux par défaut) et pragmatisme puisque Xen + GNU/Linux Debian + mdadm + lvm2 forment une stack avec une stabilité qui s'oublie, donc pas cherché plus loin.
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.
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. https://docs.ganeti.org/docs/ganeti/3.1/html/install.html si je comprends bien votre profil, nous avons des gouts similaires et de fait, OpenStack (Nova) est tout `a fait hors de question ;-) 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.
Après plein d'essais, allant de magie noire (quand ça marche, c'est beau) à la migration avortée, jusqu'à la destruction instantanée et inexplicable du volume LVM (et... non ! je ne m'étais pas emmêlé les scripts dans les primaires/secondaires), j'ai enfin admis que c'était overkilled par rapport aux besoins de l'infra. Nos clients peuvent supporter une coupure de quelques minutes (transfert de la VM, maj IPFO, maj routage+FW du node, maj IP de l'instance - pointopoint).
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 ) 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).
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, 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.
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').
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. -elge
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
participants (2)
-
Pierre-Philipp Braun -
Stéphane Rivière