On Mon, May 18, 2015 at 03:37:12PM +0200, Julien Escario wrote: > Le 18/05/2015 15:00, Dominique Rousseau a écrit : > > Le Tue, May 12, 2015 at 06:25:29PM +0200, fr...@jack.fr.eu.org > > [fr...@jack.fr.eu.org] a écrit: > >> Mouais j'sais pas trop > >> J'utilise drbd sur l'intégralité de mes VM, quasiment aucun soucis > > > > Mais les perfs s'en ressentent, forcément, sur les i/o (latence réseau > > pour le transfert + attente de l'ack) > > En cross-connecte entre deux machines, ça peut aller. Et il reste le mode > async > (protocol A ou B) mais qui n'autorise pas le dual primary (ce qui n'empêche > pas > de passer en dual primary le jour où c'est nécessaire à chaud avec DRBD 8.4). > > L'idéal étant de laisse tomber ethernet pour faire des trucs moins > 'latenceux' > comme infiniband (pas très cher si pas plus de deux nodes). > > Bon, pour en revenir à DRBD/ZFS vs ZFS send/receive : dans mon cas, c'est > pour > stocker de l'image de VM. > Je vois quand même venir un truc moche en prenant un besoin spécifique : de > la > base de données. > > Soit on fait du mode synchrone et la perf en pâtis (pâtit ?) mais on est sûr > que > les I/O que le mariadb au dessus considère comme écris SONT écris. > > Soit on fait du mode asynchrone (que ce soit DRBD A/B ou ZFS send/receive > d'ailleurs) et on a aucune certitude que au moment où sa va repasser sur > l'autre > HV, la base de données va pouvoir retrouver ses petits, en particulier sur > des > trucs fragiles comme innodb (attention, troll inside). > > Une idée pour avoir le meilleur des deux mondes ?
Si tu l'as, garde là pour toi et vend là, tu deviendras riche ;). Trève de plaisanterie, comme je disais dans l'autre mail que j'ai envoyé aujourd'hui dans ce même thread, tu peux peut-être utiliser les deux : - réplication synchrone pour les base de données - réplication asynchrone (zfs send/recv, rsync, whatever) pour le reste De toute façon, pour une base de données, il faudra obligatoirement répliquer le journal de façon synchrone pour ne pas perdre de données. Tu peux peut-être créer un setup qui ne réplique que le journal (il existe d'ailleurs peut-être des technos native avec ta base de données permettant de faire ça, ou alors tu devras le faire en mettant le journal sur un device spécifique tu répliques à l'aide de DRBD ou HAST), et ensuite lors d'un failover tu le rejoues au dessus de la dernière synchro (asynchrone) du fichier data de la base de données. Mais bon voilà, rien qu'à lire le bloc de texte ci-dessus, ça sent le truc compliqué. Je ne dis pas que ce n'est pas à faire, mais il faut vraiment que ce soit justifié et pas uniquement pour la performance technique (jeu de mot intentionel). Cela étant dit, si tu veux faire un truc dans ce genre avec du MySQL ou du MariaDB, je suis sûr que certains outils Percona existent pour simplifier le tout. Mais ça reste complexe. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
