Merci de ton réponse et de tes suggestions.
Concernant le temps de latence, de point de vue objectif RPO (Recovery Point Objective) du PCI ce n'est pas du tout critique étant donné qu'un RPO de quelques heures est tolérable. Une réplication des données non synchrone est tout à fait tolérable. A moins que le problème de latence se pose ,nativement côté système càd côté solutions VMware (SRM) ou EMC (VPLEX) d'ailleurs si des gens de deux constructeurs sont là peut être ils ont la réponse? Apparemment pour EMC: VPLEX Metro, le RTT inter site max 5 ms => 5 . 10^-3 X 2 .10^8 m/s = 5 x 10^5 m = 500 km, bon ici le temps de traitement de deux côté n'est pas compté, mais ils disent qu' avec leur solution VPLEX Geo, constitué d'un cluster de deux VPLEX: le RTT inter site est de 50 ms max. Pour SRM (VMware), j' ai vue un white paper avec des expériences: RTT inter site allant de 100 (RTT IntraUS), 200 ms (RTT trans Atlantique) à 400 ms (réseaux de satellites) ce qui est largement suffisant par rapport la distance de 240 Km entre mes deux sites . Cordialement, ________________________________ De : Surya ARBY <arbysu...@yahoo.fr> À : frnog@frnog.org Envoyé le : Samedi 8 décembre 2012 14h51 Objet : Re: [FRnOG] [TECH] Disaster Recovery & IP Addressing Fais appel à une boite de consulting spécialisée en PRA / PCA plutôt qu'à une mailing list, surtout sans connaitre la cartographie des applications, les types de clusters... c'est difficile :) Sur 1) tu peux faire une sorte de cold standby avec des configs réseaux identiques (sauf que toutes les interfaces sont shut pour ne pas être annoncées dans le routage); si tu sais remonter toutes les machines (100% virtuelles ?) en cas de désastre ça peut fonctionner (tu peux même automatiser le truc pour remonter les interfaces automatiquement) mais ça ne passera jamais en actif/actif Sur 2) pour les VLANs étendus vu tes distances tu es bien au delà de ce qui est validé; en général les solutions L2 étendu (pour VMotion / clusters divers) c'est bien pour des distances de type métro; pas Wan; d'ailleurs la problématique de latence est plutôt limitée pour le LAN (la plupart des applis Lan tolèrent bien une latence "raisonnable"); ta problématique va être sur le SAN (bb credits / IO accelerator) Sur 3) c'est pas mal mais tu vas rapidement être confronté aux problématiques de TTL dans le DNS; l'idéal dans ce cas là c'est de faire une topologie à 4 sites (en fait 2 paires de clusters distribués, puis traiter chaque bi site comme une entité logique dans ton GSLB) bref, fais appel à une boite de consulting spécialisée en PRA / PCA plutôt qu'à une mailing list :) Avec ce genre d'étude il y en a pour quelques mois de boulot s'il faut tout étudier/cartographier (si c'est 100% virtuel c'est déjà beaucoup plus simple). Le 08/12/2012 14:35, Ccde Cissp a écrit : > Hello, > > Quelqu'un aurait-il confronté le même problème, s'il vous plaît ? > Auriez-vous des conseils, des suggestions, des idées ou des points de vue > personnel? > > Cordialement, > > > > ________________________________ > De : Ccde Cissp <ccdeci...@yahoo.fr> > À : "frnog-t...@frnog.org" <frnog-t...@frnog.org> > Envoyé le : Vendredi 7 décembre 2012 16h20 > Objet : [FRnOG] [TECH] [Urgent] Disaster Recovery & IP Addressing > Bonjour la liste, > > Dans le cadre d'un projet de PCI, un nouveau DataCenter de Backup est à > concevoir. > Le premier point à voir: est-il préférable ou pas de garder le même plan > d'adressage que le site primaire et utiliser des VIP sachant que sur beaucoup > d'applications l'adressage est codé en dur ? > Le but est de faire en prémier lieu de l'Actif/Backup manuel pour évoluer > vers de l'actif/Actif sans nécessairement faire de la réplication > synchrone(ce n'est pas une exigence). > De point de vue système, une solution SRM Vmware sera utilisée. VMotion à > voir aussi si la distance et le lien physique le permettra mais ce n'est pas > vraiment le but? > La distance entre les deux sites est de 240 Km et la liaison n'est pas de la > fibre optique. > Théoriquement, 3 grands Scénarios se posent: > > 1. faire l'image identique du 1er site tout en interdisant tout contact > direct entre les deux sites en utilsant du Source NAT par exemple pour la > réplication des donnés ou autres flux inter sites? Pour l'adressage public on > jouera sur "les poids" des routes annoncés à l'identique de deux côté. > > 2. Garder le même plan d'adressage et utiliser des VIP, et propager les VLANs > entre les deux sites pour faire des extensions de niveau 2 permettant ainsi > de faire des probes sur les serveurs réparties sur les deux sites et détecter > rapidement les pannes. Par contre, un problème de routage optimum se pose si > on veut faire un failover à l'échelle d'une seule appli car on ne peut pas > annoncer son /32 du côté du site secondaire sachant que cela sera filtré par > l'operateur donc le flux INCOMING passera toujours par le site primaire et > traversera le lien inter sites pour attaquer l'appli et le flux OUTCOMING > sortira par la GW local du site secondaire (=routage asymétrique). > > 3. Utiliser un plan d'adressage complètement différent entre les deux sites > et jouer sur le DNS public pour faire du failover ou du Load Balancing entre > les deux sites. Sachant que le DNS public est géré par l'opérateur et que sur > beaucoup des appli les adresseS IP sont codées en dur. > > Je ne sais pas si LISP est mis en oeuvre actuellement chez les opérateurs ou > pas ou peut-être il n'y aurai pas besoin ? > Je ne sais pas si des solutions Cisco GSS (Global Site Selector) avec ACE > existent chez les opérateurs ou pas? > > Bien cordialement, > Merci d'avance de votre aide. > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/ --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
