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
