[si c'est la mauvais sous cat, indiquez le moi et je changerais]
 
Bonjour,
 
J'aimerais connaitre quels sont les moyens possible (sans etre trop cher et infaisable) pour avoir une disponibilite parfaite pour un site.
 
Dans l'idee j'avais pense a:
 
- avoir deux serveurs heberges dans 2 endroits geographiquement different
- tenir synchroniser les 2 serveurs regulierement
- DNS: rediriger automatiquement les requetes sur les serveurs en verifiant avant si le serveur est toujours en ligne  
J'ai lu qu'en theorie au niveau du dns avec une methode dérivée du robin round on pouvait diriger vers une ip alternative si la premiere ne réponds pas, mais j'en sais pas plus.
 
C'est faisable? comment? d'autres methodes?

quel service souhaite tu mettre en place  ? un service web ? une application lourde ? des bases de données ?
 

incohérence détectée

en fait c'est la même chose, du GSLB, et ça coute cher.
 
Sinon il y a la solution interlan et extension de vlan (donc plus besoin de DNS, mais ça coute cher aussi)

 
site web
 

 
qu'est qui coute cher exactement? c'est pas juste une machine qui dirige tout ça? (je dis ça au pif en fait j'en sais rien )
 
grace a ton acronyme GSLB, j'ai trouvé un article qui a l'air interessant : http://tenereillo.com/GSLBPageOfShame.htm (ca commence bien ) vais commencer par lire ça.

oui, mais la machine coute elle même très cher

ok, effectivement ils parlent de 30.000$ dans le lien plus haut
 
J'ai donc lu l'article, et ils disent que la meilleur solution c'est simplement de renvoyer 2 ip dans le A record du DNS. Car meme avec un GSLB, du fait du cache des DNS et des navigateurs il y aura toujours un temps de coupure.
 
Sachant que pour le site en question il n'y a pas de e-commerce et que la perte de la session n'est pas tres grave, pensez-vous donc que simplement 2 servers et 2 ip dans le A record du DNS suffit?

 
Je bosse sur un GSLB pour mon stage mais réalisé à partir d'une machine Linux et Powerdns avec le module GeoBackend.
 
J'ai juste fait des tests et ça marche bien pour le moment.
 
Le principal souci est de trouver une base de données qui devine le pays à partir de l'IP de l'internaute pour le rediriger sur le bon datacenter. J'utilise donc une base gratuite pour le moment.
 
Quelques liens :
 
http://wiki.blitzed.org/DNS_balancing
http://www.micro-gravity.com/wiki/ [...] age=GeoDns
http://www.nedworks.org/~mark/presentations/hd2006/

ben pour la db y a celle des RIR (RIPE et compagnie) par contre faut la parcourir et la traiter et ça c'est une autre histoire

 
Tout à fait, il faut récupérer les données et les mettre en base, ça promet de jolie moment mais ce n'est pas pour moi, cela est réservé à un autre stagiaire

il va s'amuser le pauvre

Clair
 
Mais la société utilise pas mal la géolocalisation donc il leur faut quelque chose de solide donc développer totalement, alors que moi j'aurai fait quelque chose de rapide pour tester.
 
En tout cas, powerdns + geobackend fonctionnent parfaitement

 
Le top c'est effectivement d'avoir 2 équipements du genre Foundry ServerIron Load Balancer pour faire du GSLB, au prix que tu as donné effectivement. L'avantage c'est qu'il sait vraiment bien gérer geolocalisation et tests de temps de réponse, indispo selon des critères poussés. A la base en plus il permet aussi surtout de gérer X machines pour chaque lieu selon moultes critères.
 
Niveau DNS en fait il réécrit la réponse DNS du serveur en fonction de la geolocalisation ( database interne modifiable dans la conf si besoin ) entre les continents ( pas les pays cependant ). Il joue également sur le TTL DNS pour réduire les effets de cache.  
 
On a mis ça en place il y a peu pour un client avec 2 load balancer par site, ça marche super bien mais bon c'est pas donné clairement ( tout comme d'avoir des plateformes sur plusieurs continents )
 
C'est jouable d'avoir des solutions softs sur serveurs mais c'est forcément moins fiable et performant, cependant c'est surtout une question de coût et de temps passé je pense.
 
 
 
MaxMind fournit ça avec GeoIP normalement, y'a aussi des API d'ailleurs
 
 
 
Quand tu arrives à un certain volume et coût en général ça passe quand même plutôt sur des solutions hard ( comme le fond tous les gros fournisseurs de contenu internationnaux ), c'est indiscret de demander un ordre de grandeur des volumes qui transitent sur les différents sites ? ( requête / BP )
 
 
Après sinon pour de la redondance multi sites, quand on a son propre réseau et sous certaines conditions il est aussi possible d'avoir le même bloc IP défini pour les 2 sites et d'annoncer les routes en fonction du site qu'on veut joindre. Si le primaire tombe ça bascule sur le second par exemple. Mais bon c'est pas simple à faire non plus et ce n'est pas adapté pour toutes les situations.
 
P.S. : Uptime 100% c'est une utopie dans l'informatique

Tiens j'avais pas lu ce truc...

Cet article, bien qu'intéressant au niveau des éléments présentés me semble assez exagéré, les TTL courts fonctionnent plutôt bien dans de nombreux cas et le GSLB représente une solution qui dans beaucoup de situations est vraiment utile. Après il faut rester lucide, il est évident qu'une petite partie des utilisateurs ressentira le problème en raison de caches divers. Le GSLB permet surtout de gérer plusieurs sites pour envoyer le client vers le meilleur et ne pas l'y envoyer s'il y a un problème. Si un cache fait merder le système, le visiteur va ailleurs et revient plus tard et ça marchera même si le site A n'est pas revenu par exemple. Entre perdre quelques visiteurs sur quelques minutes, resetter des sessions et perdre tout son trafic complet pendant plusieurs heures, en général l'échelle des pertes financières n'est pas le même.

Je me demande si l'auteur n'a pas eu un problème avec une plateforme de ce type ou s'il n'est pas un peu aigri par rapport au budget nécessaire pour en profiter mais il me parait quand même pas très objectif. Surtout que ça se trouve quand même à bien moins de 30K$ un SLB. De toute manière l'efficacité totale pour un multisite n'existe pas, c'est forcément au moins du léger dégradé pendant la phase de transition.

La question c'est surtout de bien étudier le contexte, le préjudice financier en cas de panne, le risque de panne d'un site complet, équipements réseaux compris. Tous les datacenter ne sont pas comme Redbus, la coupure totale quand on a 2 arrivées électriques sur des circuits différents a moins de chances d'arriver par exemple, on peut également avoir des batteries pour les équipements réseaux ou prévoir d'autres sécurités en fonction de la solution qu'on envisage. Le premier intérêt d'un GSLB pour moi reste quand même la geolocalisation pour amener un utilisateur au plus près de chez lui sur une même adresse web mondiale, à rebasculer la majorité du trafic ( cad dire limiter l'impact ) sur un site de secours quand l'un tombe. Le GSLB n'a jamais été une solution pour assurer une bascule immédiate sans perturbation pour personne.

C'est pareil en réseau, le reroutage c'est pas toujours instantanné quand il y a beaucoup de routes à réapprendre parce qu'un lien est pété, mais y'a pas de solution miracle à partir du moment où on n'a pas le contrôle de bout en bout du client au serveur...

D'ailleurs quand on fait du web on ne peut pas assurer 100% à tout le monde puisqu'il y a d'autres intervenants que soi. Dans un système qui se fait ultra fiable, les clients sont des postes de la société par exemple et on contrôle au niveau client également le cache et la manière de fonctionner. Dans  ce cas on peut assurer une bascule de manière quasi parfaite et assurer le service sans dégradation pénalisante. Dans l'article le mec parait un peu confondre le contexte du client externe et l'exigence d'un système interne...

My 2 cents...

Je suis pas tout à fait d'accord la dessus (concernant le NAT, en fait) :
 

 
J'ai une petite idée en tête, et je vais essayer de trouver si qqun en a pas imlémenté une solution commerciale, ce qui m'étonnerait tellement la solution m'a parue "simple" et m'est vite venue à l'esprit ...

 
   
 
Ce que j'ai réalisé est seulement en test donc 2/3 IP viennent tester PowerDNS et c'est tout
 
En tout cas, c'est très intéressant. La je bosse sur du clustering Linux

 
et comme ca le jour ou une machine plante, la moitié des requetes n'arrivent pas à destination.
 
Tout dépend de ce que tu dois load balancer et de ton budget.
 
Le plus simple serait de mettre une grappe de serveur web avec quelques load balancers devant en frontal.
 
Pour les load balancer t'as le choix entre du linux home made, ca marche très bien mais t'es limité au niveau hardware (sauf si tu tune bien comme il faut) pour pousser plus de 400-500 mbits/sec et encore un peu moins si tu firewallises aussi.
 
Si t'as besoin de plus, il faudra regarder du coté des load balancer hardware qui coutent cher mais s'ils sont nécessaires, je suppose que ce qu'il y a derriere a de quoi les rentabiliser.
 
edit : ya des solutions déja toutes faites de load balancer logiciel réalisés a partir d'open source un peu tunné (du genre Zeus ZXTM) mais je trouve ca cher pour ce que c'est, autant le faire soit meme. Sinon en load balancer hardware je ne connais que un petit peu Foundry qui font du bon matos, ya plein de produits qui coutent de pas très cher à vraiment très très cher, en fonction de la puissance/capacité à load balancer et des couches OSI à load balancer.

Une solution économique pour avoir un bon uptime sur Linux est le couple HeartBeat et DRBD + le (les) service désirer.
Mais bon les serveurs doivent être sur le même site (LAN)

Tiens je suis tombé sur un autre article causant de GSLB et load balancing divers basé sur le DNS.
 
J'ai plusieurs clients qui sont tombés sur les problèmes de temps de reprise ou persistance à cause des mécanismes de cache.
 
Je cherche de la doc sur le comportement des caches DNS de windows, Squid et Bind dans leurs configs par défaut. Ainsi que le comportement de bind lorsqu'il reçoit plusieurs IPs lors d'une résolution de nom, j'ai lu qu'il ne conservait pas l'ordre. Et également sur le respect du TTL placé dans les réponses DNS.
 
Quelqu'un aurait de la doc récente là dessus ?

up
 
l'auteur est en fait (vous ne trouverez pas l'info sur le net) l'ancien responsable du dev du Cisco GSS, qui est le produit GSLB de Cisco

Il y a une chose que je comprends pas.
En dehors de la curiosité et culture que représente GSLB, ca répond pas à son besoin.
Le principal intérêt de GSLB, en plus d'méliorer la dispo, bien sûr, c'est d'optimier le traffic Internet (géolocalisation, toussa).
Mais pour un uptime de 100%, c'est pas si compliqué.
2 datacenters reliés par des liens fibres, et du réseau layer2
2 liens internet avec 2 routeurs et un peu de BGP.
2 Firewall en cluster
2 load balancer en failover (type CSS/CSM cisco)
x front-end serveur derrière le loadbalancer (ou au pire, un système type NLB sans loadbalancer)
2 server de DB en cluster en Backend.
Et 2 Baies de disque pour les data ( de préférence en FC )
 
Avec ça, et un peu de rigueur dans les opération de maintenance, du obtiens un uptime de quasi 100%. C'est pas super bon marché, certes, mais c'est pas usine à gaz comme GSLB.
 
C'est que j'ai, et ca marche plutôt bien  

Ouais, vu comment Cisco est pas doué dans le domaine par rapport à la concurrence, ça se comprend
 

Bah le GSLB n'est pas compliqué en soit, son réel défaut c'est de dépendre des DNS ce qui le rend moins souple. Après pour de la vraie redondance multisite le BGP reste la meilleure solution je trouve aussi, mais c'est pas forcément simple au niveau répartition de trafic et ça nécessite d'avoir son propre réseau, ce qui n'est pas forcément envisagé par tout le monde.
 
Après de toute façon 99% du temps les problèmes d'uptime sont causés par des erreurs humaines et non par un défaut d'archi si la redondance a été prévue au départ.

heu non, c'est même eux qui l'ont inventé (distributed director en 95) le monsieur qui a écrit l'article décrit plus haut a même deux brevets dessus
 
voilà le gus qui est à l'origine du GSLB  : http://www.linkedin.com/in/kevindelgadillo

en fait le gslb amène plus de problèmes que de solutions (persistance de site, géo-localisation moisie qui ne reflète ni la localisation du client "final" ni l'état du réseau (latence) du client...
 
La meilleure solution étant effectivement le niveau 2 étendu, sauf que c'est jouable sur des distances courtes, au delà de 1000 kms, ce n'est plus très viable (outre le fait que l'ISP doit t'amener la plage publique sur chaque site). Tu peux demander du L2VPN (EoMPLS, VPLS...) mais je l'ai jamais vu déployé où que ce soit. Et si tu as plus de deux sites, ça devient très compliqué d'éliminer la propagation du spanning tree sur des topologies en anneau (au pire tu peux jouer sur des régions MSTP, mais tu as le problème de l'instance 0 qui est propagée partout). Si on considère des sites comme google, cisco.com et autres il font tous du GSLB parce que je pense que c'est encore ce qu'il y a de plus "simple" pour distribuer de la charge tout en ayant de la redondance pour tout le monde, même si à cause de toutes les problématiques liées au DNS (TTL, persistance...) je trouve ça peu viable dans l'internet
 
Ma préco cliente est effectivement le L2 étendu quand c'est faisable (au niveau technique et finance) (c'était dans mon premier message )

quand tu as une bonne tempête de broadcast sur ton site principal, ben sur ton site de backup y a plus rien qui marche (sauf si t'as mis un coup de storm control qui te sauve la vie) le pire c'est le spanning-tree qui part en sucette. Si tu n'as pas isolé les domaines STP entre tes deux sites, ça pourrit tout le réseau
 
la problématique venant du fait que sur de très longues distances, les mouvements de plaques tectoniques font "bouncer"/flapper les liens ce qui provoque une génération de BPDU et une perturbation de la topologie STP (en longue distance, les fibres sont moins stables qu'en local).

c'est au contraire ça qui le rend très souple. La granularité va jusqu'au nom de machine, tu peux faire des modifs de politiques de load balancing à chaud, passer d'actif/actif à actif/passif à chaud sans la moindre interruption de service.
 
En fait c'est tellement souple que tu n'as que peu de contrôle sur les utilisateurs finaux avec tous les problèmes de cache/TTL non respectés.

Reste que sur le marché actuellement sur SLB, Cisco n'a pas la place qu'il a pour le reste du milieu du réseau.

 
C'est pour ça qu'il est préférable de passer par une redondance de niveau 3 que de mettre un niveau 2 et de laisser juste un LAN to LAN pour l'interne.
 

C'est un avis, je trouve de mon côté que c'est trop dépendant des cache/TTL des autres DNS sur lesquels on a aucun contrôle, ce qui pour moi enlève sérieusement de la souplesse de conf.

sauf que certains serveurs ne sont pas ré-addressables et que certaines applis ne passent pas le NAT, d'où la nécessité d'étendre le L2

pour info, ils vendent autant que F5 (pas en france certes). F5 et Citrix ne voient pas passer tous les projets "chassis" (et sur les grands comptes, je peux te dire que des cartes ACE dans des 6500, y en a pas mal pour les avoir vus de mes yeux en salle). Après le produit est pas terrible mais c'est une autre histoire
 
Ils ont une base de 60000 CSS installés, ce qui est juste énorme

Bon si tu préfères c'est de la merde et les gros préfèrent d'autres solutions

bof, groupama, ministère des finances, technip... ça va y a de la référence quoi
 
c'est rigolo cette manière de prendre cisco pour ces cons sur ce marché alors qu'ils proposent certaines features qu'ils sont les seuls à implémenter.

Non attention, je ne prends pas Cisco pour des cons, je dis juste que dans ce domaine ce ne sont pas des stars comme c'est le cas pour d'autres. Tu me parles de routeurs je les trouve bons, tu parles VoIP pareil. Mais sur ce domaine, je les trouve en retrait. Groupama est-ce que c'est par choix pour du volume ou un choix de compatibilité, Ministère des finances je vais éviter de commenter, j'ai déjà vu assez de choses dans les ministères pour... Euh bon bref Y'a forcément des références, on parle de Cisco, rien qu'avec un deal complet ça peut passer pour avoir une homogénéité. Après quand je dis gros, je parle volume surtout, Yahoo par exemple, AOL, Google etc passent par autre chose pour cette partie et ils ont vraiment des problématiques d'un autre niveau.

Je ne suis pas contre Cisco, mais chaque fabricant a ses qualités et défauts. Je trouve au contraire que tu es un peu à fond Cisco

dreamer, à fond cisco ??? non, tu rigoles ??
 
Sinon, c'est vrai que dans le domaine du load balancing, même s'ils n'on pas forément le meilleur produit sur le marché, j'avoue que pour avoir 2 CSM dans des chassis 6500, c'est quand meme super pratique ...
D'autant plus que je dois avouer qu'on doit utiliser 5% des fonctionnalités à tout casser, donc eux ou des autres ...

je suis loin d'être pro cisco en load balancing, c'est juste que dire que c'est super pourri ne reflète pas vraiment l'état de leurs produits. D'ailleurs pour être honnête en LB, je fais 95% de NetScaler et 5% de Cisco
 
tiens, je vais même te dire que la carte ACE est bugguée, qu'en prod parfois toute la persistance des clients gicle, que de temps en temps elle se met à envoyer des TCP reset et qu'il faut la rebooter, qu'il faut upgrader trois fois avant que le ssl-proxy fonctionne et qu'un network processor à tendance à crasher... et qu'il était temps qu'en 2008, ils arrivent au niveau des autres.
 
Par contre l'appliance est bien

désolé de remonter ce sujet des profondeurs du forum mais je trouve ce thread particulierement interessant et je vous fais donc part de mon experience.
 
Nous réalisons actuellement ce que beaucoup chez nous appelent a tord et à travers PCI/PCA
bref nous redondons notre datacenter actuel avec un 2eme tout ca en actif/actif sur la partie frontale web et active/passive sur la partie back
 
Le load balancing entre les 2 datacenters sera réalisé par notre CDN (akamai)  car c'est la solution la plus simple et rapide (surement pas la moins chere)  et ce à mon plus grand regret, j'aurais plutot opté pour du BGP ou du GSLB ....
sur la partie back nous avons pris un dwdm entre les 2 sites qui nous permet d'avoir une interco niveau 3 ainsi que de véhiculer le niveau 2 dont nous avons besoin pour les serveurs de bases de données qui fonctionnent en actif/passif (cluster), . on a renoncé au full niveau 2 étendu pour les raisons évoquées au dessus ... une solution VSS sur 6500 a également été étudiée mais ca faisait renouveller un max de matos > trop cher
et pour la solution de cluster géographique nous avons pris Recoverpoint d'emc.
nous sommes actuellement sur le poc et c'est un beau bordel mais au moins y a du challenge ....
 
Je pense qu'a terme vu les couts du CDN , le GSLB est envisageable , j'aimerais savoir si qqun a deja utilisé les BIGIP GTM et si c'etait efficace pour servir des clients essentiellement européen.

tous les constructeurs majeurs font du GSLB : F5, Cisco, Citrix, Radware, Brocade (ex foundry)....
 
Le GSLB DNS ça fonctionne bien en Europe (en Asie ça chie) mais il faut que les mécanismes de persistance et de cache soient bien maitrisés par le gus qui fait la conf (et ça c'est très mal documenté).
 
Par contre la gamme F5 est trop chère de mon point de vue et je préfère passer sur d'autres produits qui font la même chose à moindre coût.

Thx , je cherche un retour sur ce produit spécifiquement parce qu'on est heureusement ou malheureusement maké avec eux...

oui t'inquiète pas ce sont eux les leaders et les feedbacks techniques que j'ai sont très bons (les pricing c'est autre chose )

Pour ma culture perso, pourquoi ça a tendance à chier en Asie le GSLB/GTM ?

@lessive : Je peux te faire un retour positif sur le GSLB Radware/Nortel Alteon et F5, ça marche très bien. Avec évidemment une préférence pour F5, vu le nombre pléthorique de features. Je sais pas trop que te dire de plus dessus...

En Asie y a le phénomène dit du "méga proxy" qui est encore présent et bon nombre d'opérateurs ne respectent pas les TTLs (en Europe et US maintenant c'est à peu près clean, ça n'a pas toujours été le cas - AOL étant le pire exemple) ce qui donne des surprises dans les répartitions d'utilisateurs, les dead A records etc...