Bonjour, Ca fait quelques semaines maintenant que je cherche la solution pour faire une réplication de données entre deux pops en datacenter. Ma problématique : j'ai besoin que les données soient trés proches dans le temps (quelques secondes seraient bien) mais l'écriture synchrone n'est guère possible : la latence entre deux sites est mal maîtrisable et si on attends que la données soit écrite sur le second site pour la considérer comme valide, la latence va tuer les performances. C'est, par exemple, ce que j'ai constaté avec DRBD protocole C. Il y a d'autres possibilités : http://www.drbd.org/users-guide-emb/s-replication-protocols.html Quelles autres possibilités existent pour ce type de besoin ? Quelqu'un a déjà fait ça d'une autre manière ? L'autre idée serait de demander au noeud client d'écrire sur deux NAS. Aucune idée de la façon dont c'est faisable. Mon utilisation est le stockage de VMs. Bonne soirée, Julien Escario
Bonjour Julien, En Opensource ou en blackbox de constructeur ? Car je pense que snapmirror (de netapp) a un mode semi-synchrone ou asynchrone (mais rapide) qui pourrait te convenir. Mais dans ce cas, tu as un site en R/W et un site en read only (il me semble) et surtout tu dois avoir un filer netapp de chaque coté. Je ne l'ai jamais déployé, mais je crois que c'est possible. :) Après, je suis partisan de l'open source aussi, mais je ne sais trop comment le faire. DRBD, de façon personnelle, j'évite. En cas de corruption d'un FS, la corruption va se propager... :( Bonne soirée. Le 28/04/2011 17:21, Julien Escario a écrit :
Bonjour, Ca fait quelques semaines maintenant que je cherche la solution pour faire une réplication de données entre deux pops en datacenter.
Ma problématique : j'ai besoin que les données soient trés proches dans le temps (quelques secondes seraient bien) mais l'écriture synchrone n'est guère possible : la latence entre deux sites est mal maîtrisable et si on attends que la données soit écrite sur le second site pour la considérer comme valide, la latence va tuer les performances. C'est, par exemple, ce que j'ai constaté avec DRBD protocole C. Il y a d'autres possibilités : http://www.drbd.org/users-guide-emb/s-replication-protocols.html
Quelles autres possibilités existent pour ce type de besoin ? Quelqu'un a déjà fait ça d'une autre manière ?
L'autre idée serait de demander au noeud client d'écrire sur deux NAS. Aucune idée de la façon dont c'est faisable.
Mon utilisation est le stockage de VMs.
Bonne soirée, Julien Escario _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le 28/04/2011 17:45, David B. a écrit :
Bonjour Julien,
En Opensource ou en blackbox de constructeur ?
Car je pense que snapmirror (de netapp) a un mode semi-synchrone ou asynchrone (mais rapide) qui pourrait te convenir. Mais dans ce cas, tu as un site en R/W et un site en read only (il me semble) et surtout tu dois avoir un filer netapp de chaque coté. Je ne l'ai jamais déployé, mais je crois que c'est possible. :)
Tu m'as devancé. Je n'aime pas trop netapp (plantage, prix, etc..); mais il faut reconnaitre que cette fonctionnalité est vraiment excellente. Pour du vmware en revanche, le storage sur nfs netapp c'est pas super niveau performance (je ne parle même pas de l'iscsi).
Après, je suis partisan de l'open source aussi, mais je ne sais trop comment le faire. DRBD, de façon personnelle, j'évite. En cas de corruption d'un FS, la corruption va se propager... :(
Bonne soirée.
Je suis pareillement à la recherche de ce genre de solution. Peut être un mix de NFS / MooseFS ? mais cela risque d'être lent. -- Raphael
David B. wrote:
Après, je suis partisan de l'open source aussi, mais je ne sais trop comment le faire. DRBD, de façon personnelle, j'évite. En cas de corruption d'un FS, la corruption va se propager... :(
La réplication ne dispense pas de faire des sauvegardes... DRBD n'est qu'un RAID1 et n'aspire à rien d'autre. -- Mathieu
Le 04/05/2011 15:35, Mathieu Chouteau a écrit :
La réplication ne dispense pas de faire des sauvegardes...
DRBD n'est qu'un RAID1 et n'aspire à rien d'autre.
Bonjour, Soit pour ta remarque, oui il faut faire des sauvegardes. Mais dans le cas du HA, ta sauvegarde ne va clairement pas te sauver la mise, car tu vas perdre du temps à remonter toute la machine. Je ne dis pas que ce n'est pas bien, je dis juste que c'est loin d'être parfait. :)
Le 28 avril 2011 17:21, Julien Escario <escario@azylog.net> a écrit :
Bonjour, Ca fait quelques semaines maintenant que je cherche la solution pour faire une réplication de données entre deux pops en datacenter.
Ma problématique : j'ai besoin que les données soient trés proches dans le temps (quelques secondes seraient bien) mais l'écriture synchrone n'est guère possible : la latence entre deux sites est mal maîtrisable et si on attends que la données soit écrite sur le second site pour la considérer comme valide, la latence va tuer les performances. C'est, par exemple, ce que j'ai constaté avec DRBD protocole C. Il y a d'autres possibilités : http://www.drbd.org/users-guide-emb/s-replication-protocols.html
Quelles autres possibilités existent pour ce type de besoin ? Quelqu'un a déjà fait ça d'une autre manière ?
L'autre idée serait de demander au noeud client d'écrire sur deux NAS. Aucune idée de la façon dont c'est faisable.
Mon utilisation est le stockage de VMs.
Bonsoir, Ne sachant pas quel dimensionnement (financier, technique, ...) la solution aura, je me permets de répondre avec ce que je connais / mets en place. - Basée sur la machine (hlm) : Veritas Cluster te permet d'avoir un miroir à X membres, certains synchrones, d'autres asynchrones. Tu peux, dés lors, faire fi de la latence de ton site distant. Je n'ai jamais testé (dis moi si tu as besoin d'un test), mais je pense que LVM sait en faire autant. - Basée sur la baie : - EMC2 : SRDF pour les dm/vmax, Mirrorview pour les clariion ou encore les géoclusters nas te permettent une réplication synchrone et/ou asynchrone, assez facilement et de manière sure et fiable. Les deux premiers sont basés sur FC, le dernier sur FC ET IP. - Netapp : Snapmirror est la solution "idéale" pour ce faire. N'hésite pas à me contacter si tu veux plus d'informations, Olive
Bonjour, Avec inotify tu regardes les changements d'inodes et tu pousses les modifications. Par contre je n'ai pas testé en bi directionnel. Sinon DRBD en protocol A ou B tu as pu tester? Le 28 avr. 2011 à 17:21, Julien Escario a écrit :
Bonjour, Ca fait quelques semaines maintenant que je cherche la solution pour faire une réplication de données entre deux pops en datacenter.
Ma problématique : j'ai besoin que les données soient trés proches dans le temps (quelques secondes seraient bien) mais l'écriture synchrone n'est guère possible : la latence entre deux sites est mal maîtrisable et si on attends que la données soit écrite sur le second site pour la considérer comme valide, la latence va tuer les performances. C'est, par exemple, ce que j'ai constaté avec DRBD protocole C. Il y a d'autres possibilités : http://www.drbd.org/users-guide-emb/s-replication-protocols.html
Quelles autres possibilités existent pour ce type de besoin ? Quelqu'un a déjà fait ça d'une autre manière ?
L'autre idée serait de demander au noeud client d'écrire sur deux NAS. Aucune idée de la façon dont c'est faisable.
Mon utilisation est le stockage de VMs.
Bonne soirée, Julien Escario _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Pierre-Henry Muller
DRBD d'une manière générale en distant est fortement déconseillé, quelque soit le protocole: - Protocol A: réplicaiton asynchrone. Les données écrite en local sont réputées écrites en distant. La moindre interruption de la liaison inter-DC provoque une perte de données. De plus, les écritures sont bloquées dès que le buffer de sortie est plein :-/ - Protocol B: réplication semi-asynchrone (buffer mémoire). Il ne faut pas que l'interruption dure trop longtemps... tout en sachant qu'un FS fortement sollicité remplira le buffer plus vite - Protocol C: le plus sûr... mais également le plus exposé aux latences. En cas de problème de liaison inter-DC, le disque va se mettre à lagguer comme un gros porc. Solution (avec DRBD): DRBD-proxy, payant. Aucune idée des tarifs par contre. http://www.drbd.org/users-guide-emb/s-drbd-proxy.html JB Le 28/04/11 23:11, Pierre-Henry Muller a écrit :
Bonjour,
Avec inotify tu regardes les changements d'inodes et tu pousses les modifications. Par contre je n'ai pas testé en bi directionnel.
Sinon DRBD en protocol A ou B tu as pu tester?
Le 28 avr. 2011 à 17:21, Julien Escario a écrit :
Bonjour, Ca fait quelques semaines maintenant que je cherche la solution pour faire une réplication de données entre deux pops en datacenter.
Ma problématique : j'ai besoin que les données soient trés proches dans le temps (quelques secondes seraient bien) mais l'écriture synchrone n'est guère possible : la latence entre deux sites est mal maîtrisable et si on attends que la données soit écrite sur le second site pour la considérer comme valide, la latence va tuer les performances. C'est, par exemple, ce que j'ai constaté avec DRBD protocole C. Il y a d'autres possibilités : http://www.drbd.org/users-guide-emb/s-replication-protocols.html
Quelles autres possibilités existent pour ce type de besoin ? Quelqu'un a déjà fait ça d'une autre manière ?
L'autre idée serait de demander au noeud client d'écrire sur deux NAS. Aucune idée de la façon dont c'est faisable.
Mon utilisation est le stockage de VMs.
Le 29/04/2011 08:57, Jean Baptiste Favre a écrit :
DRBD d'une manière générale en distant est fortement déconseillé, quelque soit le protocole: - Protocol A: réplicaiton asynchrone. Les données écrite en local sont réputées écrites en distant. La moindre interruption de la liaison inter-DC provoque une perte de données. De plus, les écritures sont bloquées dès que le buffer de sortie est plein :-/ - Protocol B: réplication semi-asynchrone (buffer mémoire). Il ne faut pas que l'interruption dure trop longtemps... tout en sachant qu'un FS fortement sollicité remplira le buffer plus vite - Protocol C: le plus sûr... mais également le plus exposé aux latences. En cas de problème de liaison inter-DC, le disque va se mettre à lagguer comme un gros porc.
Solution (avec DRBD): DRBD-proxy, payant. Aucune idée des tarifs par contre. http://www.drbd.org/users-guide-emb/s-drbd-proxy.html
Moui, pourquoi pas. Mais dans tous les cas le problème ne me paraît pas soluble : en mode synchrone, les I/O s'écrasent, en mode asynchrone, en cas de perte de connexion entre les deux sites, des écritures sont perdues (au minimum celles faites durant durant les x dernières ms x étant la latence entre les sites). Ces données non écrites peuvent correspondre avec une corruption du FS, quel qu'il soit. J'aimerais bien voir le constructeur qui a trouvé la parade a un problème aussi insoluble. Julien P.S. : merci à tous ceux qui m'ont donné des pistes. Rien de tout prêt mais il faut bien que j'ai un peu de boulot, non ?
Bonjour, J'utilise quotidiennement, une solution qui fait de la réplication asynchrone entre 2 sites distants de 50Km. C'est basé sur l'utilisation de baie SAN proprietaire (IBM) et la technologie ERM. Ca fonctionne plutôt pas mal pour le moment ______________ Renaud Hager ________________________________ De : Julien Escario <escario@azylog.net> À : frsag@frsag.org Envoyé le : Vendredi 29 Avril 2011 9h04 Objet : Re : [FRsAG] Réplication temps réel de données entre sites Le 29/04/2011 08:57, Jean Baptiste Favre a écrit :
DRBD d'une manière générale en distant est fortement déconseillé, quelque soit le protocole: - Protocol A: réplicaiton asynchrone. Les données écrite en local sont réputées écrites en distant. La moindre interruption de la liaison inter-DC provoque une perte de données. De plus, les écritures sont bloquées dès que le buffer de sortie est plein :-/ - Protocol B: réplication semi-asynchrone (buffer mémoire). Il ne faut pas que l'interruption dure trop longtemps... tout en sachant qu'un FS fortement sollicité remplira le buffer plus vite - Protocol C: le plus sûr... mais également le plus exposé aux latences. En cas de problème de liaison inter-DC, le disque va se mettre à lagguer comme un gros porc.
Solution (avec DRBD): DRBD-proxy, payant. Aucune idée des tarifs par contre. http://www.drbd.org/users-guide-emb/s-drbd-proxy.html
Moui, pourquoi pas. Mais dans tous les cas le problème ne me paraît pas soluble : en mode synchrone, les I/O s'écrasent, en mode asynchrone, en cas de perte de connexion entre les deux sites, des écritures sont perdues (au minimum celles faites durant durant les x dernières ms x étant la latence entre les sites). Ces données non écrites peuvent correspondre avec une corruption du FS, quel qu'il soit. J'aimerais bien voir le constructeur qui a trouvé la parade a un problème aussi insoluble. Julien P.S. : merci à tous ceux qui m'ont donné des pistes. Rien de tout prêt mais il faut bien que j'ai un peu de boulot, non ? _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour, Dans l'idée du stockage à distance, il y a GlusterFS qui peut peut-être trouver sa place ( on l'utilise sur du backup et ça marche correctement ) Autrement pour ce qui est de DRBD, il faut au moins une MTU à 9000 et peut-être regarder du côté de DRBD Proxy. On Fri, 29 Apr 2011 09:30:05 +0100 (BST), Renaud Hager wrote: Bonjour, J'utilise quotidiennement, une solution qui fait de la réplication asynchrone entre 2 sites distants de 50Km. C'est basé sur l'utilisation de baie SAN proprietaire (IBM) et la technologie ERM. Ca fonctionne plutôt pas mal pour le moment ______________ Renaud Hager ------------------------- DE : Julien Escario À : frsag@frsag.org ENVOYÉ LE : Vendredi 29 Avril 2011 9h04 OBJET : Re : [FRsAG] Réplication temps réel de données entre sites Le 29/04/2011 08:57, Jean Baptiste Favre a écrit :
DRBD d'une manière générale en distant est fortement déconseillé, quelque soit le protocole: - Protocol A: réplicaiton asynchrone. Les données écrite en local sont réputées écrites en distant. La moindre interruption de la liaison inter-DC provoque une perte de données. De plus, les écritures sont bloquées dès que le buffer de sortie est plein :-/ - Protocol B: réplication semi-asynchrone (buffer mémoire). Il ne faut pas que
l'interruption dure trop longtemps... tout en sachant qu'un FS fortement
sollicité remplira le buffer plus vite - Protocol C: le plus sûr... mais également le plus exposé aux latences. En cas de problème de liaison inter-DC, le disque va se mettre à lagguer comme un gros porc.
Solution (avec DRBD): DRBD-proxy, payant. Aucune idée des tarifs par contre.
http://www.drbd.org/users-guide-emb/s-drbd-proxy.html [1] Moui, pourquoi pas. Mais dans tous les cas le problème ne me paraît pas soluble : en mode synchrone, les I/O s'écrasent, en mode asynchrone, en cas de perte de connexion entre les deux sites, des écritures sont perdues (au minimum celles faites durant durant les x dernières ms x étant la latence entre les sites). Ces données non écrites peuvent correspondre avec une corruption du FS, quel qu'il soit. J'aimerais bien voir le constructeur qui a trouvé la parade a un problème aussi insoluble. Julien P.S. : merci à tous ceux qui m'ont donné des pistes. Rien de tout prêt mais il faut bien que j'ai un peu de boulot, non ? _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/ [2] -- RIGARD Lilian - Devclic SARL Gérant - CEO & CTO Téléphone (Standard) / Phone : +33 3 57 75 61 46 Portable / Cell Phone : +33 6 29 59 21 34 E-mail : lilian@devclic.fr Web : http://www.devclic.fr Links: ------ [1] http://www.drbd.org/users-guide-emb/s-drbd-proxy.html [2] http://www.frsag.org/
2011/4/29 Lilian - Devclic <lilian@devclic.fr>:
Bonjour,
Dans l'idée du stockage à distance, il y a GlusterFS qui peut peut-être trouver sa place ( on l'utilise sur du backup et ça marche correctement )
Salut, Avec Gluster, ton nombre d'IO est limité par la latence entre les sites... Gluster, en LAN c'est très bien, sur du WAN, ça devient chaud... Julien: quelle latence entre tes sites??? a+
Le 29/04/2011 12:19, Baptiste a écrit :
2011/4/29 Lilian - Devclic <lilian@devclic.fr>:
Bonjour,
Dans l'idée du stockage à distance, il y a GlusterFS qui peut peut-être trouver sa place ( on l'utilise sur du backup et ça marche correctement )
Salut,
Avec Gluster, ton nombre d'IO est limité par la latence entre les sites... Gluster, en LAN c'est très bien, sur du WAN, ça devient chaud...
Julien: quelle latence entre tes sites???
Typiquement : moins de 5 ms. J'ai laissé tourner un mtr depuis un petit moment : moyenne à 4.8ms, worst à 32ms. C'est plutôt direct (300km, 3 routeurs) mais ca reste sans commune mesure avec du LAN. Julien
Le 29/04/2011 11:55, Lilian - Devclic a écrit :
Bonjour,
Dans l'idée du stockage à distance, il y a GlusterFS qui peut peut-être trouver sa place ( on l'utilise sur du backup et ça marche correctement )
Autrement pour ce qui est de DRBD, il faut au moins une MTU à 9000 et peut-être regarder du côté de DRBD Proxy.
On Fri, 29 Apr 2011 09:30:05 +0100 (BST), Renaud Hager <renaud_hager@yahoo.fr> wrote:
Bonjour,
J'utilise quotidiennement, une solution qui fait de la réplication asynchrone entre 2 sites distants de 50Km.
C'est basé sur l'utilisation de baie SAN proprietaire (IBM) et la technologie ERM.
Ca fonctionne plutôt pas mal pour le moment ______________
Renaud Hager ------------------------------------------------------------------------ *De :* Julien Escario *À :* frsag@frsag.org *Envoyé le :* Vendredi 29 Avril 2011 9h04 *Objet :* Re : [FRsAG] Réplication temps réel de données entre sites
Le 29/04/2011 08:57, Jean Baptiste Favre a écrit :
DRBD d'une manière générale en distant est fortement déconseillé, quelque soit le protocole: - Protocol A: réplicaiton asynchrone. Les données écrite en local sont réputées écrites en distant. La moindre interruption de la liaison inter-DC provoque une perte de données. De plus, les écritures sont bloquées dès que le buffer de sortie est plein :-/ - Protocol B: réplication semi-asynchrone (buffer mémoire). Il ne faut pas que l'interruption dure trop longtemps... tout en sachant qu'un FS fortement sollicité remplira le buffer plus vite - Protocol C: le plus sûr... mais également le plus exposé aux latences. En cas de problème de liaison inter-DC, le disque va se mettre à lagguer comme un gros porc.
Solution (avec DRBD): DRBD-proxy, payant. Aucune idée des tarifs par contre. http://www.drbd.org/users-guide-emb/s-drbd-proxy.html
Moui, pourquoi pas.
Mais dans tous les cas le problème ne me paraît pas soluble : en mode synchrone, les I/O s'écrasent, en mode asynchrone, en cas de perte de connexion entre les deux sites, des écritures sont perdues (au minimum celles faites durant durant les x dernières ms x étant la latence entre les sites).
Ces données non écrites peuvent correspondre avec une corruption du FS, quel qu'il soit.
J'aimerais bien voir le constructeur qui a trouvé la parade a un problème aussi insoluble.
Julien
P.S. : merci à tous ceux qui m'ont donné des pistes. Rien de tout prêt mais il faut bien que j'ai un peu de boulot, non ? _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- RIGARD Lilian - Devclic SARL Gérant - CEO& CTO Téléphone (Standard) / Phone : +33 3 57 75 61 46 Portable / Cell Phone : +33 6 29 59 21 34 E-mail : lilian@devclic.fr Web : http://www.devclic.fr
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Salut, Oulla, DRBD ? Si tu veux éviter les problèmes, les crises d'angoisses, les cheveux blancs et éventuellement les pertes de données, évites DRBD. Trop chiant à mettre en place, trop sensible aux problèmes réseaux, tu vas devenir fou. Si tu veux un truc solide, regardes du côté des solutions propriétaires .... malheureusement ! Mais au moins, tu as du support et t'es presque certains d'avoir moins de problème. a+ -- Guillaume
Le 29/04/2011 12:21, DjinnS a écrit :
Oulla, DRBD ? Si tu veux éviter les problèmes, les crises d'angoisses, les cheveux blancs et éventuellement les pertes de données, évites DRBD. Trop chiant à mettre en place, trop sensible aux problèmes réseaux, tu vas devenir fou.
Si tu veux un truc solide, regardes du côté des solutions propriétaires .... malheureusement !
Mais au moins, tu as du support et t'es presque certains d'avoir moins de problème.
Ouep et de ne rien contrôler sur ta solution, voir même d'être captif d'un fournisseur ... Mais au moins, j'ai payé un parachute. Pas trop ma politique en général. Faire appel à un tech pointu sur un domaine pour me conseiller/configurer le tout, oui, mais payer une bonne noire, non merci. Julien
Hello, 2011/4/29 DjinnS <djinns@chninkel.net>
Oulla, DRBD ? Si tu veux éviter les problèmes, les crises d'angoisses, les cheveux blancs et éventuellement les pertes de données, évites DRBD. Trop chiant à mettre en place, trop sensible aux problèmes réseaux, tu vas devenir fou.
C'est-à-dire ? Peux-tu développer ? Fabien
Bonjour, J'ai utilisé du DRBD sans problème dans les conditions suivantes : 2011/4/29 Fabien Germain <fabien.germain@gmail.com>
Hello,
2011/4/29 DjinnS <djinns@chninkel.net>
Oulla, DRBD ? Si tu veux éviter les problèmes, les crises d'angoisses, les cheveux blancs et éventuellement les pertes de données, évites DRBD. Trop chiant à mettre en place, trop sensible aux problèmes réseaux, tu vas devenir fou.
C'est-à-dire ? Peux-tu développer ?
Fabien
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Petite erreur d'envoi. Je recommence ! Bonjour, J'ai utilisé du DRBD sans problème dans les conditions suivantes : - Entre 2 infra distantes de 10 km avec une faible tatence - Réplication de type A - Applications utilisatrices : Debian, Heartbeat, OpenVZ, XEN, Postgresql, Mysql, Octopussy (super outil de gestion des logs), serveurs apache, Tomcat, un peu de tout. ==> Bilan très positif : - si le fichier drbd.conf est bien fait (afin d'éviter le split brain) - reprise après incident sans problème - migration d'instance OpenVZ sans problème - Bref que du bonheur et entièrement Open Source. 2011/5/4 Sébastien Gautrias <sebastien.gautrias@gmail.com>
Bonjour, J'ai utilisé du DRBD sans problème dans les conditions suivantes :
2011/4/29 Fabien Germain <fabien.germain@gmail.com>
Hello,
2011/4/29 DjinnS <djinns@chninkel.net>
Oulla, DRBD ? Si tu veux éviter les problèmes, les crises d'angoisses, les cheveux blancs et éventuellement les pertes de données, évites DRBD. Trop chiant à mettre en place, trop sensible aux problèmes réseaux, tu vas devenir fou.
C'est-à-dire ? Peux-tu développer ?
Fabien
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Sébastien Gautrias <sebastien.gautrias@gmail.com> écrit :
Bonjour,
Hello,
J'ai utilisé du DRBD sans problème dans les conditions suivantes : - Entre 2 infra distantes de 10 km avec une faible tatence - Réplication de type A - Applications utilisatrices : Debian, Heartbeat, OpenVZ, XEN, Postgresql, Mysql, Octopussy (super outil de gestion des logs), serveurs apache, Tomcat, un peu de tout.
Pareil, on a utilisé DRBD pendant quelque temps sur une plateforme de prod, avec une Debian, Oracle et heartbeat, pounr une infra actif/passif. Pas de soucis particuliers, si ce n'est quelques bascules intempestives, mais dûes à un hertbeat un poil trop sensible. Les deux machines étaient sur un lien dédié au DRBD sur un vlan. Marche plutôt bien. On n'a pas gardé le DRBD car on a migré l'appli sur une autre plateforme actif/actif un poil plus performante, plus chère, et totalement pas libre.
On 04/05/2011 17:57, Stephane Dupille wrote:
On n'a pas gardé le DRBD car on a migré l'appli sur une autre plateforme actif/actif un poil plus performante, plus chère, et totalement pas libre.
Bonsoir Stephane, Je suis actuellement sur un projet du même type (actif/actif). Je pense m'orienter vers une solution EMC. Afin d'avoir un retour d'experience, quelle a été la solution retenue chez vous, et pour quelles contraintes ? Merci
Bonsoir Stephane,
Bonsoir,
Je suis actuellement sur un projet du même type (actif/actif). Je pense m'orienter vers une solution EMC.
Totalement différent de ce qu'on a mis en place.
Afin d'avoir un retour d'experience, quelle a été la solution retenue chez vous, et pour quelles contraintes ?
Les machines en question font tourner Oracle. Donc nous nous sommes tourné vers les solutions Oracle et avons mis en place Oracle RAC. On ne peut pas faire plus spécifique et en l'occurence plus adapté je pense, puisque tout est dans les mains du cluster de base de données. Et ça marche plutôt très bien. Pour les serveurs applicatifs, etant donné qu'il y en a trois, on a monté un cluster actif/passif à trois noeuds, et par défaut, chaque machine fait tourner son applicatif, en redondant les autres en cas de défaillance. L'exploitant nous a imposé RedHat Cluster. C'est naze : il arrive régulièrement que le cluster perde les pédales et nous oblige à tout arrêter/relancer. Heartbeat marche beaucoup mieux. En ce qui concerne DRBD lui-même, on est passé à un stockage sur SAN fibre-channel. Donc chaque machine attaque un espage partagé. On gagne en souplesse, perfs, fiabilité, facilité de mise en oeuvre, etc. Mais c'est nettement plus cher. Un NAS pourrait être adapté pour ce genre de choses, mais dans ce cas il faut faire gaffe au SPOF.
On 04/28/2011 05:21 PM, Julien Escario wrote:
Bonjour, Ca fait quelques semaines maintenant que je cherche la solution pour faire une réplication de données entre deux pops en datacenter.
Ma problématique : j'ai besoin que les données soient trés proches dans le temps (quelques secondes seraient bien) mais l'écriture synchrone n'est guère possible : la latence entre deux sites est mal maîtrisable et si on attends que la données soit écrite sur le second site pour la considérer comme valide, la latence va tuer les performances. C'est, par exemple, ce que j'ai constaté avec DRBD protocole C. Il y a d'autres possibilités : http://www.drbd.org/users-guide-emb/s-replication-protocols.html
Quelles autres possibilités existent pour ce type de besoin ? Quelqu'un a déjà fait ça d'une autre manière ?
L'autre idée serait de demander au noeud client d'écrire sur deux NAS. Aucune idée de la façon dont c'est faisable.
Mon utilisation est le stockage de VMs.
Bonne soirée, Julien Escario _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
<touriste> Et qu'en est-t-il des solutions anciennes, inconnues, oubliées, jamais testées en prod du genre CODA [1] ? Ou encore 9P, il parraîtrait que c'est utilisé sur des appliances (j'lai vu sur IRC donc c'est vrai). Je dis ça au pif parce que j'ai jamais eu l'occasion ne serai-ce que de tester, mais sur le papier ça avait l'air fun. </touriste> [1] http://www.coda.cs.cmu.edu/ -- Rémy Sanchez http://hyperthese.net
On Fri, 29 Apr 2011 01:42:26 +0200, Rémy Sanchez <remy.sanchez@hyperthese.net> wrote:
Et qu'en est-t-il des solutions anciennes, inconnues, oubliées, jamais testées en prod du genre CODA [1] ? [1] http://www.coda.cs.cmu.edu/
Ne gère pas les droits Unix. D'autres questions ? :) -- Mathieu Goessens IT consultant. gebura@poolp.org + 33 6 07 91 54 87 http://gebura.eu.org
Bonjour Julien, Le 28 avril 2011 17:21, Julien Escario <escario@azylog.net> a écrit :
Bonjour, Ca fait quelques semaines maintenant que je cherche la solution pour faire une réplication de données entre deux pops en datacenter.
Déjà j'oublierais les solutions de type fichier : du stockage de VM c'est trop lourd à répliquer en FS, il te faut un accès en mode bloc. Ensuite, ça va en partie dépendre te ton hyperviseur : sur du VMWare par exemple, tu as tout intérêt à partir sur une solution SAN classique (et donc propriétaire), c'est prévu pour ça. Mais le plus important à mes yeux, c'est la problématique de lien et de volumétrie. Autant tu pourrais prendre une lambda 2,5Gbps (ou plus) entre les deux pops et y faire passer du FiberChannel, autant si tu n'as pas de migrations à chaud, c'est pas vraiment nécessaire. Par contre, c'est bien plus fiable d'avoir un lien dédié, à cet usage, quitte à le rendonder par de l'IP. J'aurais un faible pour le module (payant) de réplication de Nexenta, qui donne de bonnes performances et sait travailler aussi bien en FC / FCoE qu'en iSCSI, ça peut être un compromis intéressant entre prix et stabilité. -- Jérôme Nicolle 06 19 31 27 14
participants (19)
-
Baptiste -
David B. -
DjinnS -
Fabien Germain -
Jean Baptiste Favre -
Julien Escario -
Jérôme Nicolle -
Laurent CARON -
Lilian - Devclic -
Mathieu Chouteau -
Mathieu Goessens -
Olivier tourchon -
Pierre-Henry Muller -
Raphael Mazelier -
Renaud Hager -
Rémy Sanchez -
Stephane Dupille -
Stephane Dupille -
Sébastien Gautrias