Re: [FRnOG] Backup de prod multi-site
Tu peux lire la note 1047 de radware... tu verras la lumière :) . Elle décrit exactement ton besoin. 2008/10/30 Denis Alligand [EMAIL PROTECTED] Bonjour, je gère pour l'un de mes clients son infra prod. Aujourd'hui il y a une baie complête dans un datacenter avec des clusters web, sql, fichiers, tout cela en HA gérer par des solutions de réplications et de basculement de serveur en cas de soucis sur un serveur. Jusque là, pas de problème. Hors le soucis est que c'est bien beau de tout mettre dans une seule baie, mais en cas de coupure de cette baie (courant électrique/reseaux ...), malgré les beaux système HA, plus rien ne répond. Donc je dois répliquer cette solution sur un autre datacenter, et pourvoir rediriger de facon la plus transparente possible le traffic en cas de failure de l infra principale. Le traffic a diriger est uniquement du HTTP et du HTTPS sur plusieurs dizaine de M/s avec des pointes a 150/200 M/s Pour cela plusieurs solutions envisageable: 1: avoir un redirecteur HA dans un endroit neutre et rediriger le flux vers un datacenter ou un autre, et secourir ce redirecteur HA sur un autre site indemendant au cas ou. Probleme: point faible si le reseau ou se trouve le le redirecteur HA tombe, tout tombe, meme si la prod ou le site de secours est OK. Probleme: -soit le traffic est remonté totalement au redirecteur qui se charge de répondre aux requettes des clients directement, donc il faut imaginer un systeme de tunelling pour atteindre le datacenter 1 ou 2 (prod ou secours), et dans ce cas, on double l'utilisation de la bande passante (BP sorti datcenter vers redirecteur et bp sorti redirecteur vers client) -soit les machines repondent directement aux requettes vers le client. Cela pose une interrogation: il faut que le systeme indique comme adresse source: le redirecteur, mais le systeme qui repondra sera le serveur reel. C'est ce qui est implémenté aujourd'hui par des solutions type LVS tun. Re probleme: on tombe dans la RFC2267 http://www.isi.edu/in-notes/rfc2267.txt et on prend le risque de se faire bloquer nos ips pour probleme de spoof. Question: est-ce que on peut controler cela si on se met d'accord uniquement avec nos fournisseurs de BP qui ne sont pas des carrier-1 et qui peuvent odnc par consequent peut etre se faire bloquer eux meme par leur carrier. 2: on met le redirecteur sur site A avec IP site A. L'ensemble des sites webs pointe sur un cname qui lui meme pointe sur IP A. Un redirecteur sur site B avec IP B Ce record Cname a un ttl agresssif genre 5 minutes tel que peut l utiliser aujourd'hui des dyndsn et compagnie. En prod normal on pointe sur redirecteur A, en prod backupé on pointe sur redirecteur B. Question: certains ISP semblent utliser de facon massive le cache dns sur leur reseau: donc est-ce que la propag est quand meme envisageable rapidement pour passer de A vers B ? 3: On fait pointer les sites web vers un redirecteur de type 301 ou 303, et on redirect les demande du type: www.dc1.site.com ou www.dc2.site.com (dc1=datacenter 1, dc2 = datacenter 2): pas forcement terrible pour le referencement mais on parle bien d un mode de secours pour dc2 au cas ou. Bien entendu le point faible est toujours sur le fait que le redirecteur doit etre disponible et on revient un peu au cas 1. Autre possibilité: mixe d'un peu de ces 3 solutions, en jouant sur les dns, sur les propags et sur l emplacement des redirecteur. Question: quel type de produit proposent aujourd'hui de la dispo multi-site, faut-il passer par des solution type HAproxy ou type LVS, sachant que nous sommes sur du 100% LAMP. Chaque cas de figure a ses points faibles et ses avantages. Avez-vous eu deja ce genre de problematique et quelle a été votre choix la dessus. Cordialement, Denis Alligand -- Steven Le Roux Jabber-ID : [EMAIL PROTECTED] 0x39494CCB [EMAIL PROTECTED] 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB
Re: [FRnOG] Backup de prod multi-site
Denis Alligand a écrit : Bonjour, Ahu, je vais me limiter à ce que je peux affirmer sans me tromper =) Jusque là, pas de problème. Hors le soucis est que c'est bien beau de tout mettre dans une seule baie, mais en cas de coupure de cette baie (courant électrique/reseaux ...), malgré les beaux système HA, plus rien ne répond. J'ai deux arrivées électrique indépendantes dans chaque baie, mais ça ne doit pas être partout pareil ... 2: on met le redirecteur sur site A avec IP site A. L'ensemble des sites webs pointe sur un cname qui lui meme pointe sur IP A. Un redirecteur sur site B avec IP B Ce record Cname a un ttl agresssif genre 5 minutes tel que peut l utiliser aujourd'hui des dyndsn et compagnie. Ca fait déjà 5 minutes de panne dans le meilleur des cas. Pour du HA ça colle pas trop. Question: certains ISP semblent utliser de facon massive le cache dns sur leur reseau: donc est-ce que la propag est quand meme envisageable rapidement pour passer de A vers B ? Non. Les ISP prennent en général en compte un ttl supérieur à la valeur par défaut, mais avec un ttl inférieur les résultats ne sont pas garantis dans la pratique (= pas bon pour HA) 3: On fait pointer les sites web vers un redirecteur de type 301 ou 303, et on redirect les demande du type: www.dc1.site.com http://www.dc1.site.com ou www.dc2.site.com http://www.dc2.site.com (dc1=datacenter 1, dc2 = datacenter 2): pas forcement terrible pour le referencement mais on parle bien d un mode de secours pour dc2 au cas ou. Bien entendu le point faible est toujours sur le fait que le redirecteur doit etre disponible et on revient un peu au cas 1. 301 : non. C'est ok pour le référencement en cas de changement définitif (Moved Permanently), mais il ne faut pas l'utiliser pour du temporaire / exceptionnel 302 pourrait coller --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Backup de prod multi-site
Salut, je gère pour l'un de mes clients son infra prod. Aujourd'hui il y a une baie complête dans un datacenter avec des clusters web, sql, fichiers, tout cela en HA gérer par des solutions de réplications et de basculement de serveur en cas de soucis sur un serveur. Jusque là , pas de problème. Hors le soucis est que c'est bien beau de tout mettre dans une seule baie, mais en cas de coupure de cette baie (courant électrique/reseaux ...), malgré les beaux système HA, plus rien ne répond. Donc je dois répliquer cette solution sur un autre datacenter, et pourvoir rediriger de facon la plus transparente possible le traffic en cas de failure de l infra principale. Le traffic a diriger est uniquement du HTTP et du HTTPS sur plusieurs dizaine de M/s avec des pointes a 150/200 M/s Pour cela plusieurs solutions envisageable: [SNIP tout un tas de solutions cracra et pas forcement bon marché] Le plus simple, moins cher et efficace reste à mon avis d'avoir un bloc d'IP anycasté depuis tes 2 sites. Si ton site A tombe complètement (niveau éléctrique, réseau ou matériel...) ton traffic se retrouve basculé sur le site B sans aucune action de ta part et surtout sans aucun delais du à des bascules DNS co. Question: quel type de produit proposent aujourd'hui de la dispo multi-site, faut-il passer par des solution type HAproxy ou type LVS, sachant que nous sommes sur du 100% LAMP. Avec un bloc d'IP anycasté, aucun produit magique qui fait brillé le réseau et fait le café en meme temps n'est requis. C'est les pousseurs de boites qui vont faire la gueule. Chaque cas de figure a ses points faibles et ses avantages. Avez-vous eu deja ce genre de problematique et quelle a été votre choix la dessus. Oui, c'est en prod et ca marche très bien :) Mathieu --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Backup de prod multi-site
Le sujet m'interesse aussi. Est ce qu'on peut avoir un lien vers cette note 1047 ? Youssef -- On Oct 30, 2008, at 9:40 AM, Steven Le Roux wrote: Tu peux lire la note 1047 de radware... tu verras la lumière :) . Elle décrit exactement ton besoin. 2008/10/30 Denis Alligand [EMAIL PROTECTED] Bonjour, je gère pour l'un de mes clients son infra prod. Aujourd'hui il y a une baie complête dans un datacenter avec des clusters web, sql, fichiers, tout cela en HA gérer par des solutions de réplications et de basculement de serveur en cas de soucis sur un serveur. Jusque là, pas de problème. Hors le soucis est que c'est bien beau de tout mettre dans une seule baie, mais en cas de coupure de cette baie (courant électrique/reseaux ...), malgré les beaux système HA, plus rien ne répond. Donc je dois répliquer cette solution sur un autre datacenter, et pourvoir rediriger de facon la plus transparente possible le traffic en cas de failure de l infra principale. Le traffic a diriger est uniquement du HTTP et du HTTPS sur plusieurs dizaine de M/s avec des pointes a 150/200 M/s Pour cela plusieurs solutions envisageable: 1: avoir un redirecteur HA dans un endroit neutre et rediriger le flux vers un datacenter ou un autre, et secourir ce redirecteur HA sur un autre site indemendant au cas ou. Probleme: point faible si le reseau ou se trouve le le redirecteur HA tombe, tout tombe, meme si la prod ou le site de secours est OK. Probleme: -soit le traffic est remonté totalement au redirecteur qui se charge de répondre aux requettes des clients directement, donc il faut imaginer un systeme de tunelling pour atteindre le datacenter 1 ou 2 (prod ou secours), et dans ce cas, on double l'utilisation de la bande passante (BP sorti datcenter vers redirecteur et bp sorti redirecteur vers client) -soit les machines repondent directement aux requettes vers le client. Cela pose une interrogation: il faut que le systeme indique comme adresse source: le redirecteur, mais le systeme qui repondra sera le serveur reel. C'est ce qui est implémenté aujourd'hui par des solutions type LVS tun. Re probleme: on tombe dans la RFC2267 et on prend le risque de se faire bloquer nos ips pour probleme de spoof. Question: est-ce que on peut controler cela si on se met d'accord uniquement avec nos fournisseurs de BP qui ne sont pas des carrier-1 et qui peuvent odnc par consequent peut etre se faire bloquer eux meme par leur carrier. 2: on met le redirecteur sur site A avec IP site A. L'ensemble des sites webs pointe sur un cname qui lui meme pointe sur IP A. Un redirecteur sur site B avec IP B Ce record Cname a un ttl agresssif genre 5 minutes tel que peut l utiliser aujourd'hui des dyndsn et compagnie. En prod normal on pointe sur redirecteur A, en prod backupé on pointe sur redirecteur B. Question: certains ISP semblent utliser de facon massive le cache dns sur leur reseau: donc est-ce que la propag est quand meme envisageable rapidement pour passer de A vers B ? 3: On fait pointer les sites web vers un redirecteur de type 301 ou 303, et on redirect les demande du type: www.dc1.site.com ou www.dc2.site.com (dc1=datacenter 1, dc2 = datacenter 2): pas forcement terrible pour le referencement mais on parle bien d un mode de secours pour dc2 au cas ou. Bien entendu le point faible est toujours sur le fait que le redirecteur doit etre disponible et on revient un peu au cas 1. Autre possibilité: mixe d'un peu de ces 3 solutions, en jouant sur les dns, sur les propags et sur l emplacement des redirecteur. Question: quel type de produit proposent aujourd'hui de la dispo multi-site, faut-il passer par des solution type HAproxy ou type LVS, sachant que nous sommes sur du 100% LAMP. Chaque cas de figure a ses points faibles et ses avantages. Avez- vous eu deja ce genre de problematique et quelle a été votre choix la dessus. Cordialement, Denis Alligand -- Steven Le Roux Jabber-ID : [EMAIL PROTECTED] 0x39494CCB [EMAIL PROTECTED] 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Backup de prod multi-site
Hello, Le 30 octobre 2008 09:32, Mathieu Paonessa [EMAIL PROTECTED] a écrit : Salut, je gère pour l'un de mes clients son infra prod. Aujourd'hui il y a une baie complête dans un datacenter avec des clusters web, sql, fichiers, tout cela en HA gérer par des solutions de réplications et de basculement de serveur en cas de soucis sur un serveur. Jusque là, pas de problème. Hors le soucis est que c'est bien beau de tout mettre dans une seule baie, mais en cas de coupure de cette baie (courant électrique/reseaux ...), malgré les beaux système HA, plus rien ne répond. Donc je dois répliquer cette solution sur un autre datacenter, et pourvoir rediriger de facon la plus transparente possible le traffic en cas de failure de l infra principale. Le traffic a diriger est uniquement du HTTP et du HTTPS sur plusieurs dizaine de M/s avec des pointes a 150/200 M/s Pour cela plusieurs solutions envisageable: [SNIP tout un tas de solutions cracra et pas forcement bon marché] Le plus simple, moins cher et efficace reste à mon avis d'avoir un bloc d'IP anycasté depuis tes 2 sites. Si ton site A tombe complètement (niveau éléctrique, réseau ou matériel...) ton traffic se retrouve basculé sur le site B sans aucune action de ta part et surtout sans aucun delais du à des bascules DNS co. Oui, mais quid si le site A et le site B sont géré par 2 société différentes et parfois meme concurrente, dans le cas de la securisation du type: je veux pas mettre mes oeufs de le meme panier. Je suppose que ca nécessite du BGP, au moins une /24 PI (PA peut etre mais, on laisse ses oeufs ds le meme panier). Cette solution peut sembler bien au premier abord ds le cas d'homogéneité sur le fournisseur. Donc question: quelles sont les contraintes de cette solution? ;-) Question que ser passe-t-il si tes routes flaps (le reseau site A annonce, annonce pas, annonce, annonce pas). Que se passe-il si le topo reseau change et que tu te retrouve sur le site B alors que ton A fonctionne toujours? (je dis peut etre des grosses betises la, donc merci de me rectifier si je suis en dehors de la réalité). Question: quel type de produit proposent aujourd'hui de la dispo multi-site, faut-il passer par des solution type HAproxy ou type LVS, sachant que nous sommes sur du 100% LAMP. Avec un bloc d'IP anycasté, aucun produit magique qui fait brillé le réseau et fait le café en meme temps n'est requis. C'est les pousseurs de boites qui vont faire la gueule. Remarque j'en pleurerais pas ;-)
Re: [FRnOG] Backup de prod multi-site
2008/10/30 Steven Le Roux [EMAIL PROTECTED] 2008/10/30 [EMAIL PROTECTED] Le sujet m'interesse aussi. Est ce qu'on peut avoir un lien vers cette note 1047 ? C'était la 1045... autant pour moi... -- Steven Le Roux Jabber-ID : [EMAIL PROTECTED] 0x39494CCB [EMAIL PROTECTED] 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB
Re: [FRnOG] Backup de prod multi-site
Denis Alligand wrote: Hello, Le plus simple, moins cher et efficace reste à mon avis d'avoir un bloc d'IP anycasté depuis tes 2 sites. Si ton site A tombe complètement (niveau éléctrique, réseau ou matériel...) ton traffic se retrouve basculé sur le site B sans aucune action de ta part et surtout sans aucun delais du à des bascules DNS co. Oui, mais quid si le site A et le site B sont géré par 2 société différentes et parfois meme concurrente, dans le cas de la securisation du type: je veux pas mettre mes oeufs de le meme panier. Je suppose que ca nécessite du BGP, au moins une /24 PI (PA peut etre mais, on laisse ses oeufs ds le meme panier). Tout a fait. Cette solution peut sembler bien au premier abord ds le cas d'homogéneité sur le fournisseur. Donc question: quelles sont les contraintes de cette solution? ;-) Question que ser passe-t-il si tes routes flaps (le reseau site A annonce, annonce pas, annonce, annonce pas). Que se passe-il si le topo reseau change et que tu te retrouve sur le site B alors que ton A fonctionne toujours? Meme avec des fournisseurs différents ca ne pose pas de gros problèmes. La seule chose qui se passera c'est que tu n'aura pas 1 site actif et l'autre en backup mais 2 sites actifs qui, suivant le voodoo du BGP mondial, se partageront le traffic. Après tout dépend de ton type de contenu: si c'est du e-commerce et qu'en plein milieu de la transaction le client change de site, ca peut effectivement etre genant mais pas plus qu'avec une bascule utilisant une des solutions que tu as propose avant. D'experience pour un client qui a 1 site a Singapour anycaste avec son autre site en France, nous n'avons pas connu de problemes particuliers sur sa prod. Mathieu --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Backup de prod multi-site
2008/10/30 Patrick Viet [EMAIL PROTECTED] 2008/10/30 Steven Le Roux [EMAIL PROTECTED]: hop : http://www.securitytechnet.com/resource/rsc-center/vendor-wp/radware/app1045.pdf C'est éprouvé... mangez en. Ha oui mangez-en. Enfin si une bascule de 1/2h est OK ... Cette archi permet de fonctionner en actif/actif... sur n branches Pas de temps de bascule. 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. (sans compter les ISP type AOL ou Free qui ne respectent même pas le TTL et le remontent à bien plus de 1h) http://www.tenereillo.com/GSLBPageOfShame.htm Heureusement que je me sers de BGP pour basculer mon traffic parce qu'avec des bricolages comme ça merci l'absence de maitrise de ce qu'on fait. Patrick 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. -- Steven Le Roux Jabber-ID : [EMAIL PROTECTED] 0x39494CCB [EMAIL PROTECTED] 2FF7 226B 552E 4709 03F0 6281 72D7 A010 3949 4CCB
Re: [FRnOG] Backup de prod multi-site
Bonjour, tu fais de l'anycast sur ton bloc d'ip, il sera donc routé vers deux lieux différent, en utilisant le plus proche, et le cas échéant celui encore en vie. ça te permet de répartir la charge de manière externe et non interne, ça t'évite de tirer sur tes liens inter-site, et de subir par la même occasion les eventuels probleme que ça engendre (coup de tractopelle, lenteurs, etc), et ça te permet d'être redondant de manière immédiate (qu'on me corrige si je dis des conneries.) Arthur Denis Alligand wrote: Bonjour, je gère pour l'un de mes clients son infra prod. Aujourd'hui il y a une baie complête dans un datacenter avec des clusters web, sql, fichiers, tout cela en HA gérer par des solutions de réplications et de basculement de serveur en cas de soucis sur un serveur. Jusque là, pas de problème. Hors le soucis est que c'est bien beau de tout mettre dans une seule baie, mais en cas de coupure de cette baie (courant électrique/reseaux ...), malgré les beaux système HA, plus rien ne répond. Donc je dois répliquer cette solution sur un autre datacenter, et pourvoir rediriger de facon la plus transparente possible le traffic en cas de failure de l infra principale. Le traffic a diriger est uniquement du HTTP et du HTTPS sur plusieurs dizaine de M/s avec des pointes a 150/200 M/s Pour cela plusieurs solutions envisageable: 1: avoir un redirecteur HA dans un endroit neutre et rediriger le flux vers un datacenter ou un autre, et secourir ce redirecteur HA sur un autre site indemendant au cas ou. Probleme: point faible si le reseau ou se trouve le le redirecteur HA tombe, tout tombe, meme si la prod ou le site de secours est OK. Probleme: -soit le traffic est remonté totalement au redirecteur qui se charge de répondre aux requettes des clients directement, donc il faut imaginer un systeme de tunelling pour atteindre le datacenter 1 ou 2 (prod ou secours), et dans ce cas, on double l'utilisation de la bande passante (BP sorti datcenter vers redirecteur et bp sorti redirecteur vers client) -soit les machines repondent directement aux requettes vers le client. Cela pose une interrogation: il faut que le systeme indique comme adresse source: le redirecteur, mais le systeme qui repondra sera le serveur reel. C'est ce qui est implémenté aujourd'hui par des solutions type LVS tun. Re probleme: on tombe dans la RFC2267 http://www.isi.edu/in-notes/rfc2267.txt et on prend le risque de se faire bloquer nos ips pour probleme de spoof. Question: est-ce que on peut controler cela si on se met d'accord uniquement avec nos fournisseurs de BP qui ne sont pas des carrier-1 et qui peuvent odnc par consequent peut etre se faire bloquer eux meme par leur carrier. 2: on met le redirecteur sur site A avec IP site A. L'ensemble des sites webs pointe sur un cname qui lui meme pointe sur IP A. Un redirecteur sur site B avec IP B Ce record Cname a un ttl agresssif genre 5 minutes tel que peut l utiliser aujourd'hui des dyndsn et compagnie. En prod normal on pointe sur redirecteur A, en prod backupé on pointe sur redirecteur B. Question: certains ISP semblent utliser de facon massive le cache dns sur leur reseau: donc est-ce que la propag est quand meme envisageable rapidement pour passer de A vers B ? 3: On fait pointer les sites web vers un redirecteur de type 301 ou 303, et on redirect les demande du type: www.dc1.site.com http://www.dc1.site.com ou www.dc2.site.com http://www.dc2.site.com (dc1=datacenter 1, dc2 = datacenter 2): pas forcement terrible pour le referencement mais on parle bien d un mode de secours pour dc2 au cas ou. Bien entendu le point faible est toujours sur le fait que le redirecteur doit etre disponible et on revient un peu au cas 1. Autre possibilité: mixe d'un peu de ces 3 solutions, en jouant sur les dns, sur les propags et sur l emplacement des redirecteur. Question: quel type de produit proposent aujourd'hui de la dispo multi-site, faut-il passer par des solution type HAproxy ou type LVS, sachant que nous sommes sur du 100% LAMP. Chaque cas de figure a ses points faibles et ses avantages. Avez-vous eu deja ce genre de problematique et quelle a été votre choix la dessus. Cordialement, Denis Alligand --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Backup de prod multi-site
2008/10/30 Steven Le Roux [EMAIL PROTECTED] 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. Oui oui pour autant qu'il fasse une requête DNS. Je ne parle pas de nouveaux visiteurs/requeteurs DNS. Je parle des gens qui ont déjà dans leur cache DNS l'entrée du site A. Qui peuvent être des ISP entiers vu que les caches DNS sont partagés. Ils ne feront PAS de requête DNS. Donc pas de bascule ; et on voit une *panne*. Pour rappel le cache DNS final est fait par le browser, qui fait un appel système gethostbyname ; lequel n'a aucune connaissance des TTL. Donc de manière totalement arbitraire, il cache pendant 1/2h. C'est programmé comme ça. Pendant 1/2h il va continuer à taper sur la vieille IP. Qui ne marche pas. Enfin maxi 1/2h, David Amiel a précisé auparavant que en pratique plus de 80% du trafic était basculé au bout de 15-20min. Ce qui est déjà pas mal si mal au passage. Ce n'est pas le discours... c'est pour dire que si ça n'était pas fiable... on aurait choisi autre chose. Et que le fait d'être une banque donne de la légitimité technique supérieure à vos choix ? Tu avais demandé des arguments ? J'en ai reçu spontanément ; et un seul, ça commençait par : _ pour preuve _ , suivi de _ nous sommes une banque donc _ Je maintiens que si bascule il y a... c'est par soucis de disposer de données à jour mais pas d'archi. Donc un client qui visitait le site A quand il est en panne continue d'essayer de le visiter et tombe dans le vide ? Ou si bascule il y a il bascule quand son cache dns de browser expire ?
Re: [FRnOG] Backup de prod multi-site
Article interessant à ce sujet mais qui date un peu: http://www.tenereillo.com/GSLBPageOfShame.htm 2008/10/30 Patrick Viet [EMAIL PROTECTED]: 2008/10/30 Steven Le Roux [EMAIL PROTECTED] 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. Oui oui pour autant qu'il fasse une requête DNS. Je ne parle pas de nouveaux visiteurs/requeteurs DNS. Je parle des gens qui ont déjà dans leur cache DNS l'entrée du site A. Qui peuvent être des ISP entiers vu que les caches DNS sont partagés. Ils ne feront PAS de requête DNS. Donc pas de bascule ; et on voit une *panne*. Pour rappel le cache DNS final est fait par le browser, qui fait un appel système gethostbyname ; lequel n'a aucune connaissance des TTL. Donc de manière totalement arbitraire, il cache pendant 1/2h. C'est programmé comme ça. Pendant 1/2h il va continuer à taper sur la vieille IP. Qui ne marche pas. Enfin maxi 1/2h, David Amiel a précisé auparavant que en pratique plus de 80% du trafic était basculé au bout de 15-20min. Ce qui est déjà pas mal si mal au passage. Ce n'est pas le discours... c'est pour dire que si ça n'était pas fiable... on aurait choisi autre chose. Et que le fait d'être une banque donne de la légitimité technique supérieure à vos choix ? Tu avais demandé des arguments ? J'en ai reçu spontanément ; et un seul, ça commençait par : _ pour preuve _ , suivi de _ nous sommes une banque donc _ Je maintiens que si bascule il y a... c'est par soucis de disposer de données à jour mais pas d'archi. Donc un client qui visitait le site A quand il est en panne continue d'essayer de le visiter et tombe dans le vide ? Ou si bascule il y a il bascule quand son cache dns de browser expire ? -- David Ramahefason [EMAIL PROTECTED] --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] Backup de prod multi-site
Le 30 octobre 2008 13:22, David Ramahefason [EMAIL PROTECTED] a écrit : Article interessant à ce sujet mais qui date un peu: http://www.tenereillo.com/GSLBPageOfShame.htm effectivement instructif Donc, si on se réfère à cette article (donc la dernèire update date de fin 2007, c'est pas si vieux), il est indiqué que la meilleure solution de passer outre la problematique du multi-site actif/passif via les solutions de dns tel que proposer dans le draft de radware et de tout simplement faire du multi A mais en fixed order, avec un record sur site 1 et un record sur site 2. via l'option rrset-order. Des fois on se demande pourquoi on cherche des solutions bizaroide alors que 2 lignes de config peuvent resoudre le probleme ;-) Question: admettons que mon domaine soit géré par 2 DNS avec cette fameuse option, lors des querys recursives et la mise en cache sur les dns de nos chers ISP, est-ce que cette ordre sera toujours repecté? (par les 2 dns, mais aussi par les dns non autoritaires) Je veux dire le dns autoritaire repond: www.monsite.com = 1.1.1.1 www.monsite.com = 2.2.2.2 dans cet ordre et toujours dans cette ordregrace au rrset-order. Je mets un ttl de 0 (soyons fou), mais ora9frealiaol mette en cache sur leur dns le resultat. Un abonné B demandera www.monsite.com est-ce que j ai l'assurance que ca repondra toujours 1.1.1.1 et 2.2.2.2 dans cet ordre? ;-) (et que par un effet magique ca retourne a du round-robin ce que je en veux pas) sur cette ML il est sensé y avoir des pros du dns qui bossent en plus chez ces isp... alors messieurs? Denis
Re: [FRnOG] Backup de prod multi-site
Bonjour, Faire confiance à des DNS ou à des annonces dans BGP ? Vous n'avez aucune vision de ce qui se fait chez les autres opérateurs au niveau de leurs caches .. Alors que quand on a la main sur les annonces c'est d'autant plus facile de router le trafic. On ne peut pas s'appuyer sur une infrastructure qu'on ne maîtrise pas dans ce type de setup .. Ce que propose Radware c'est vraiment pour ceux qui ne connaissant pas les technos .. On veut faire croire aux clients qu'ils ont une ferrari alors qu'ils ont acheté une logan .. On ne peux pas remplacer ce qui fonctionne très bien depuis des lustres .. Enfin c'est un avis personnel :) Nico Le 30 oct. 08 à 14:15, Denis Alligand a écrit : Le 30 octobre 2008 13:22, David Ramahefason [EMAIL PROTECTED] a écrit : Article interessant à ce sujet mais qui date un peu: http://www.tenereillo.com/GSLBPageOfShame.htm effectivement instructif Donc, si on se réfère à cette article (donc la dernèire update date de fin 2007, c'est pas si vieux), il est indiqué que la meilleure solution de passer outre la problematique du multi-site actif/passif via les solutions de dns tel que proposer dans le draft de radware et de tout simplement faire du multi A mais en fixed order, avec un record sur site 1 et un record sur site 2. via l'option rrset-order. Des fois on se demande pourquoi on cherche des solutions bizaroide alors que 2 lignes de config peuvent resoudre le probleme ;-) Question: admettons que mon domaine soit géré par 2 DNS avec cette fameuse option, lors des querys recursives et la mise en cache sur les dns de nos chers ISP, est-ce que cette ordre sera toujours repecté? (par les 2 dns, mais aussi par les dns non autoritaires) Je veux dire le dns autoritaire repond: www.monsite.com = 1.1.1.1 www.monsite.com = 2.2.2.2 dans cet ordre et toujours dans cette ordregrace au rrset-order. Je mets un ttl de 0 (soyons fou), mais ora9frealiaol mette en cache sur leur dns le resultat. Un abonné B demandera www.monsite.com est-ce que j ai l'assurance que ca repondra toujours 1.1.1.1 et 2.2.2.2 dans cet ordre? ;-) (et que par un effet magique ca retourne a du round-robin ce que je en veux pas) sur cette ML il est sensé y avoir des pros du dns qui bossent en plus chez ces isp... alors messieurs? Denis PGP.sig Description: This is a digitally signed message part
Re: [FRnOG] Backup de prod multi-site
Bonjour, Le 30 octobre 2008 14:27, Nicolas Strina [EMAIL PROTECTED] a écrit : Bonjour, Faire confiance à des DNS ou à des annonces dans BGP ? Vous n'avez aucune vision de ce qui se fait chez les autres opérateurs au niveau de leurs caches .. Alors que quand on a la main sur les annonces c'est d'autant plus facile de router le trafic. On ne peut pas s'appuyer sur une infrastructure qu'on ne maîtrise pas dans ce type de setup .. Encore faut-il avoir la main sur nos annonces, ie avoir des /23 ou 24, verfier qu on se fait aps filtrer par ce que ce n'est pas aggreger et que on se fait annoncer dans un /16 d'un carrier et que les routeurs filtres le /24 parce que on pourrait optimiser les routes en face. De plus le multi-site veut pas forcement dire avoir la main egalement sur le BGP, et que l on veut peut etre controler plus finemement le mode passif/actif et que l on ne maitrise pas forcement le chemin le plus court sur la topologie reseau pour faire arriver au bon endroit. De plus le flap penalties et autre methode du genre font que le BGP n''est pas adapté a tte les solutions. J en ai mis des tonnes en place des solutions BGP, sous cisco, juniper et quagga et compagnie, je me suis battu parfois pendant des semaines avec certains operateurs americain parce que le community string balancé sur les 701 ou 702 et 3215 etaient pas tout a fait formé comme ils le souhaitait sur certains peering comme le MAE, donc je pense que d'experience j ai a peu pres autant confiance dans le BGP que dans des DNSn cet a dire assez limité quand meme. Ce que propose Radware c'est vraiment pour ceux qui ne connaissant pas les technos .. On veut faire croire aux clients qu'ils ont une ferrari alors qu'ils ont acheté une logan .. radware, Barracuda, nortel/alteon, LVS, HA Proxy ..., certe tu n'agits pas forcement complement sur la Layer 3 mais si tu veux comprendre un minimum ce que tu fais je suis pas sur que ca soit du plug and play des boiboites et ca demandes 2-3 neuronnes quand meme On ne peux pas remplacer ce qui fonctionne très bien depuis des lustres .. Des operateurs, des réseaux, des société sont morts avec de genre de raisonnement: on ne change pas un truc qui marche.. sauf que le reseau est en perpetuel evolution, je me souviens qu'il y a pas si longtemps parler d'ATM, de Frame relay c'etait réservé a une certaine élite, maintenant n'importe quel gars unepu débrouillard te sort ce que tu veux en ATM, te fais des PPPoA etc etc. C'est sur on pourrait rester sur des LS en serial avec du SLIP pour communiquer entre les terminaisons, ca marche très bien aussi ;-) Enfin c'est un avis personnel :) Pareil ;-) Nico Le 30 oct. 08 à 14:15, Denis Alligand a écrit : Le 30 octobre 2008 13:22, David Ramahefason [EMAIL PROTECTED] a écrit : Article interessant à ce sujet mais qui date un peu: http://www.tenereillo.com/GSLBPageOfShame.htm effectivement instructif Donc, si on se réfère à cette article (donc la dernèire update date de fin 2007, c'est pas si vieux), il est indiqué que la meilleure solution de passer outre la problematique du multi-site actif/passif via les solutions de dns tel que proposer dans le draft de radware et de tout simplement faire du multi A mais en fixed order, avec un record sur site 1 et un record sur site 2. via l'option rrset-order. Des fois on se demande pourquoi on cherche des solutions bizaroide alors que 2 lignes de config peuvent resoudre le probleme ;-) Question: admettons que mon domaine soit géré par 2 DNS avec cette fameuse option, lors des querys recursives et la mise en cache sur les dns de nos chers ISP, est-ce que cette ordre sera toujours repecté? (par les 2 dns, mais aussi par les dns non autoritaires) Je veux dire le dns autoritaire repond: www.monsite.com = 1.1.1.1 www.monsite.com = 2.2.2.2 dans cet ordre et toujours dans cette ordregrace au rrset-order. Je mets un ttl de 0 (soyons fou), mais ora9frealiaol mette en cache sur leur dns le resultat. Un abonné B demandera www.monsite.com est-ce que j ai l'assurance que ca repondra toujours 1.1.1.1 et 2.2.2.2 dans cet ordre? ;-) (et que par un effet magique ca retourne a du round-robin ce que je en veux pas) sur cette ML il est sensé y avoir des pros du dns qui bossent en plus chez ces isp... alors messieurs? Denis
Re: [FRnOG] Backup de prod multi-site
Alors, Le 30 oct. 08 à 14:54, Denis Alligand a écrit : Bonjour, Le 30 octobre 2008 14:27, Nicolas Strina [EMAIL PROTECTED] a écrit : Bonjour, Faire confiance à des DNS ou à des annonces dans BGP ? Vous n'avez aucune vision de ce qui se fait chez les autres opérateurs au niveau de leurs caches .. Alors que quand on a la main sur les annonces c'est d'autant plus facile de router le trafic. On ne peut pas s'appuyer sur une infrastructure qu'on ne maîtrise pas dans ce type de setup .. Encore faut-il avoir la main sur nos annonces, ie avoir des /23 ou 24, verfier qu on se fait aps filtrer par ce que ce n'est pas aggreger et que on se fait annoncer dans un /16 d'un carrier et que les routeurs filtres le /24 parce que on pourrait optimiser les routes en face. Pourquoi sans cesse refuser de faire confiance aux opérateurs ? Il faut appeler un chat un chat. Quand on part sur ce type de projet on ne peut pas se permettre de faire de l'approximatif .. certes ça a un coût .. Mais on a rien sans rien. Pour ma part nous n'avons aucun problème à gérer ce type de setup même pour une tiers partie. Pourquoi ça doit systématiquement mal ce passer ? De plus le multi-site veut pas forcement dire avoir la main egalement sur le BGP, et que l on veut peut etre controler plus finemement le mode passif/actif et que l on ne maitrise pas forcement le chemin le plus court sur la topologie reseau pour faire arriver au bon endroit. De plus le flap penalties et autre methode du genre font que le BGP n''est pas adapté a tte les solutions. J en ai mis des tonnes en place des solutions BGP, sous cisco, juniper et quagga et compagnie, je me suis battu parfois pendant des semaines avec certains operateurs americain parce que le community string balancé sur les 701 ou 702 et 3215 etaient pas tout a fait formé comme ils le souhaitait sur certains peering comme le MAE, donc je pense que d'experience j ai a peu pres autant confiance dans le BGP que dans des DNSn cet a dire assez limité quand meme. Pour info le dampening est considérer comme has been et même si il existe dans la plus part des réseaux c'est une question de savoir faire tourner son affaire. J'aimerai vraiment qu'on me démontre par A + B que ce type de solution est une horreur à gérer. On ne parle pas du même monde alors car dans le miens c'est BGP qui fait tourner la planète (sans rentrer dans le détails des IGP etc ..). C'est une question de choix de matériel et de partenaires .. Ce que propose Radware c'est vraiment pour ceux qui ne connaissant pas les technos .. On veut faire croire aux clients qu'ils ont une ferrari alors qu'ils ont acheté une logan .. radware, Barracuda, nortel/alteon, LVS, HA Proxy ..., certe tu n'agits pas forcement complement sur la Layer 3 mais si tu veux comprendre un minimum ce que tu fais je suis pas sur que ca soit du plug and play des boiboites et ca demandes 2-3 neuronnes quand meme Pour avoir vu des tonnes et des tonnes de présentations sur ces produits (Je ne parle pas de load balancers mais bien de ces pseudo routeurs type Radware etc) ,très honnêtement c'est vraiment simpliste :) Quand on va plus en détail avec ces gens on entend souvent Ah nan mais pour une utilisation plus pointue il vaut mieux utiliser des routeurs digne de ce nom. Que dire ? Critiquer ? On va dire qu'on est mauvaise langue ... mais dans ce cas rien ne remplace la clue d'une personne qui sait manager son réseau correctement. Et il y en a heureusement beaucoup. On ne peux pas remplacer ce qui fonctionne très bien depuis des lustres .. Des operateurs, des réseaux, des société sont morts avec de genre de raisonnement: on ne change pas un truc qui marche.. sauf que le reseau est en perpetuel evolution, je me souviens qu'il y a pas si longtemps parler d'ATM, de Frame relay c'etait réservé a une certaine élite, maintenant n'importe quel gars unepu débrouillard te sort ce que tu veux en ATM, te fais des PPPoA etc etc. C'est sur on pourrait rester sur des LS en serial avec du SLIP pour communiquer entre les terminaisons, ca marche très bien aussi ;-) Enfin c'est un avis personnel :) Pareil ;-) Je ne parle pas de techno de transport mais de routing. Qui a fait mieux que BGP aujourd'hui pour router nos jolis paquets ? A ma connaissance personne. Pour ma part c'est une philosophie. Encore une fois je ne suis pas contre les choses qui sont fiable et qui ont fait leur preuve. Mais la on est vraiment loin du compte .. Il suffit de lire les back logs des Mailing list .. On peut toujours monter un lab et voir ce qui en ressort mais j'ai peur qu'au final les RFC's qui ont été pondus donnent raison à BGP et à son fonctionnement. (Au fait Radware participe à ce genre de documents ?) Nico Nico Le 30 oct. 08 à 14:15, Denis Alligand a écrit : Le 30 octobre 2008 13:22, David Ramahefason [EMAIL PROTECTED] a écrit :
