Le 18/03/2021 à 10:30, Stéphane Rivière a écrit : >> Un NAS-HA, forcément, c’est sur un site, faut pas rêver. > C'est intéressant ce que tu dis. Je le croyais aussi. > > Avec la techno qu'on développe en interne (qui n'est que la synthèse des > possibilités réunies de xen linux lvm drbd avec de la glue logique pour > résumer), on fait aujourd'hui 'NAS de pauvre' entre GRA et RBX (2ms > entre, avec des serveurs NVMe qui poutrent et lien stable à 2Gbps). > > Bon, c'est pas du CEPH, hein, c'est un truc de pauvre. Mais qui marche. > > Voire même en triplette entre GRA RBX SBG (latence max 13ms) et sur SBG > un serv avec disques mécas 8To raid 10 (pour des trucs moins sensibles à > la perf mais triplement redondés). Et on triche pas coté vitesse puisque > l'acquittement vient après l'écriture sur le disque pour privilégier la > sûreté.
Ah, un peu de tech ! ;-) Alors, même avec Ceph, y'a pas mal de possibilités avec rbd-mirror qui fonctionne de manière asynchrone. Avec ça, la latence, tu t'en fous, il faut juste que le lien puisse engranger le débit de tes écritures. Et ça marche en 'two-way'. Je n'ai pas encore testé mais en Octopus, tu peux aussi faire du mode snapshot, qui revient, peu ou prou avec un ZFS send/receive (si j'ai bien compris). En version 'du pauvre', il est tout à fait possible de faire tourner un cluster Ceph avec ... un seul nœud (un étant un nombre impair) + rbd-mirror. Même avec un seul OSD pour avoir la couche CephFS, RBD, export NFS, exporter prometheus et tout le reste du stack. Tout ça implique 2/3 manips au moment du PRA (changement de sens de synchro, passage en primaire, etc ...). Chez nous, on a choisit de documenter ça plutôt que de faire de l'automatique mais chacun ces préférences et son engagement de service. Mais même avec une des deux solutions ci-dessus, on peut trouver des use-cases où un delta de 30s voire de 13ms n'est pas acceptable. Julien
OpenPGP_signature
Description: OpenPGP digital signature
