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-tBNNOMJ
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
_______________________________________________
Liste de diffusion du French Sysadmin Group
https://www.frsag.org/
