2008/10/30 Patrick Viet <[EMAIL PROTECTED]> > > Cette archi permet de fonctionner en actif/actif... sur n branches >> >> Pas de temps de bascule. >> > > Donc en fait si on a le site A et B en actif/actif, que le site A tombe en > panne, il n'y a pas besoin de basculer les gens qui utilisaient le site A > vers le site B ? Mais c'est prodigieux !! Je n'y aurais jamais pensé. S'il y > a un problème, soulevons le tapis et glissons la poussière dessous. > Puisqu'on est en actif/actif, les pannes et les bascules n'existent pas !! >
T'as lu la note ? L'enregistrement NS de ton domaine renvoie deux NS : A.domain.tld et B.domain.tld, chacun des ces deux dns jouent le rôle de redirecteur, et l'important c'est que chaque application/ferme héberge son propre dns, ainsi, même si A.domain.tld n'est pas cassé, lorsque tu requetes le sous domaine www. il renvoie le NS de toute les branches... si celui de la branche A ne répond pas, c'est que l'appli A est gaufré, donc le client bascule sur la branche B pour sa requete NS et le NS de www. lui renverra le bon A. si A.domain.tld pete, ton client passe automatiquement sur B.domain.tld, mais le fait de mettre du roundrobin à ce niveau te permet de faire de l'actif/actif sur toutes tes branches. Une fois la requete arrivée sur B.domain.tld, B renvoie les NS de la zone www. (un sur chaque branche donc) avec en priorité le NS WWW de la banche B (car venant de B ça implique que la branche B est viable et permet de ne pas perdre de temps à tester, même une fois sur deux, l'autre branche), et le NS www. pourra lui renvoyer le champ A qui correspond, mais là il ne renvoie que le sien. > > > >> >> Le problème se situe sur la réplication de donnée. S'il y en a bcp, et >> selon la distance entre sites, il ne sera pas envisageable de travailler en >> mode synchrone. Mais bon c'est ce qui se passe chez google aujourd'hui ou >> n'importe quel autre système réparti. >> > > Non ça c'est un autre problème. Je parlais de celui de la bascule mais > comme elle n'existe pas... > > BGP n'est absolument pas utile ici. >> >> Pour preuve, nous avons plusieurs accès internet, plusieurs IP, nous >> sommes une banque donc tout est redondé et maillé de A à Z, et pour >> autant... on n'utilise pas de BGP. BGP c'est utile quand tu ne sais pas >> faire autrement. Dans ce cas, on peut faire mieux, plus souple, et ce n'est >> pas du bricolage. >> > > C'est imparable : > > "nous sommes une banque" ----> "tout est super infaillible et parfait" > Ce n'est pas le discours... c'est pour dire que si ça n'était pas fiable... on aurait choisi autre chose. > > > Ah les banques, ces organismes surpuissants à la pointe de la technologie, > qui ne font jamais d'erreurs, et encore moins des erreurs monumentales. > Enfin heureusement il ne s'agit ici que d'une erreur technique de > compréhension sur la durée de bascule. Et franchement, 1h de panne de temps > en temps ce n'est pas si grave. > Je te laisse libre de ce que tu penses... loin de moi l'idée de faire penser que les banques sont à la pointe de la techno... ce serait même le contraire, car mastodonte donc difficile de mettre en prod quand tous les jours de la semaine tu as une ouverture et une fermeture de bourse et que tu n'as pas le droit de casser le réseau... > > > En tout cas merci pour la leçon, c'était instructif. Clair, précis et > détaillé. Avec des arguments de poids !! La prochaine fois qu'un client me > demande de lui faire le design d'une architecture redondante, je lui dirai > qu'il n'y a plus de bascule à gérer car un mec d'une banque (référence > incontournable) m'a dit que les bascules ça ne servait plus à rien. > Tu avais demandé des arguments ? Je maintiens que si bascule il y a... c'est par soucis de disposer de données à jour mais pas d'archi. > > > PS: je suis un peu dur mais ne le prends pas au premier degré ; ça m'amuse > juste beaucoup de faire du troll sur frnog ou ailleurs > ça arrive à tout le monde de se tromper et moi le premier ; sauf qu'ici je > suis sur de mon coup. > tu t'amuses tout seul je crois. > > Cordialement, > > Patrick Viet > -- Steven Le Roux Jabber-ID : [EMAIL PROTECTED] 0x39494CCB <[EMAIL PROTECTED]> 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB
