Reprise du message précédent :
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...

Ok pour le "méga proxy", je voyais un truc du genre (enfin plutôt du NAT IPv4 massif). Par contre, je savais pas que les opérateurs là-bas respectent pas les TTL, c'est vrai que ça rappelle le début des années 2000.

y a aussi le NAT ipv4 car je crois que toute la chine sort avec une /24

Des sources pour cette info. Ca m'intéresse! C'est a peine coyable si c'est vrai et j'ai tendance à croire que ces pas loin de la vérité!

J'avais vu passer ça sur une mailing list (le mec travaille chez F5)

j'ai dit qu'en Europe c'était clean, c'est pas tout à fait vrai il y a un service d'hébergement d'image qui a changé d'adresse il y a 2 ans, il y avait plein de monde ici même qui tombait sur l'ancienne IP car le(s) cache(s) DNS de leur provider n'étaient pas à jour. Globalement chez neuf telecom je crois qu'il y a des trucs bizarres (proxy transparents ?)

 
Je reviens juste là-dessus : le fail over en "multiple A records" fonctionne t-il (comme dit dans l'article), ou bien est-ce que, comme tu dis, une fois sur deux (dans le cas de deux A records) les requêtes n'arrivent pas ? ce n'est pas le comportement décrit dans l'article, je voudrais savoir ce qu'il en est réellement.

non le multiple A records pour la failover ça fonctionne pas. Pour une raison simple, c'est que le RR DNS (basique)  ne se rend pas compte que la ressource est HS donc il y a deux phénomènes :
 
- le DNS sert toujours cette IP
- si cette IP est dans des caches (en liste ou seule) elle sera servie aux clients
 
Pour le (1) les boites à GSLB sont intelligentes (il y a un serveur DNS open source qui sait le faire aussi) et qui ne va plus répondre avec l'ip de la ressource HS. Par contre si cette IP est stockée dans des caches (TTL trop long ou non respecté) t'es mort

Mais dans l'article il est plutôt question de retourner une liste d'adresses IP en réponse à une requête DNS, et pas une IP parmi un pool (j'espère que je suis clair...).

Charge ensuite au client d'utiliser une autre IP de la liste renvoyée par le serveur DNS si la première ne répond pas, et ça -toujours d'après l'article-, les browsers internet savent le faire.

EDIT pour en dessous : ok merci

oui mais ça dépend du comportement du client. Si tu veux faire du GSLB sur des applis non web (WS ou applis non HTTP tout simplement) ça t'oblige à te reposer sur un comportement du client que tu ne maitrises pas.
 
Sur du pur web effectivement c'est safe.

juste pour finir là dessus perso j'aime pas les listes car comme elles "tournent" dans les resolvers, ça casse toute la politique de load balancing. Je préfère les single A record avec un TTL faible et une mise en place de persistance.
 
Si tu veux de la répartition de charge je préfèrerai un seul A record. Si tu veux de la haute dispo les listes me semblent meilleures.

 
Question innocente : Pourquoi ne pas faire une liste, dont chaque IP correspond à un des FW (ou load balancer) de l'infrastructure et après les laisser eux gérer le trafic? On y gagne quoi avec ton système?

parce que le GSLB c'est fait pour faire du load balancing de site (en gros, c'est inexact mais c'est vendu comme ça ), avec un GSLB inéquitable tu peux saturer un site complet (avec ses propres load balancer locaux et les serveurs associés) alors qu'un autre est sous employé.
 
Imaginons que tu aies un site A sous employé et un site B saturé (mais disponible, on va dire que le service est "juste" lent). Si tu fais une liste ordonnée (A, B) (A est le meilleur site, B est juste là pour la HA) le premier client qui utilise le resolver va recevoir la liste (A, B) et part sur A. Si le TTL n'est pas expiré ou non respecté, le second client qui interroge le resolver reçoit la liste (B, A) et part sur B => pas bien
 
Avec un seul A record tu es sur de ne diriger les clients que sur A
 
Tu peux me dire que dans l'internet, la probabilité que deux clients interrogent le même serveur DNS avant que le TTL expire est faible, ce qui est vrai (encore que chez certains ISP...) mais en entreprise ça peut être faux

Salut,
 
D'accord mais là donc on redirige tout le trafic qui serait passé par A et B vers A seulement. Pourquoi est-ce que ce serait mieux? Parce qu'en n'ayant que A, on peut investir plus dessus et donc avoir un équipement qui sera plus difficilement saturé ?
Et si A devait tomber, qu'est ce qui se passe étant donné que son IP est la seule à être dans les DNS? Tout se pête la gueule?
 
Désolé pour les questions à 2 balles mais là j'ai un peu de peine à faire le point

 
Hum, pourquoi ? Parce que tu dois faire tes requêtes DNS vers l'équipement GSLB qui est forcément sur un des deux sites ?
 

 
Ben dans le cas qu'il citait, c'était volontaire de rediriger tous les nouveaux clients vers le site A, vu que B est saturé. En temps normal tu vas rediriger équitablement, en round robin par exemple, ou en fonction des capacités du site, voire de la géolocalisation.
 
Si A tombe, bien évidemment que le GSLB renverra tous les nouveaux clients vers B. Le souci c'est ceux qui ont déjà A dans leur cache DNS, qui devront attendre la fin du TTL ou de la durée de vie dans le cache DNS si elle est fixée.
 

Ah d'accord je comprend
Donc on joue sur le DNS afin qu'il donne l'IP du serveur qui a moins de charge (A ou B). Alors que si on lui donnait la liste à lui, il balancerait les requêtes 50/50 sans se préoccuper de la charge effective des serveurs
Ca me semble quand même plus risqué (justement à cause du cache DNS) que de donner la liste des IP des load-balancers, en les laissant eux rediriger le trafic comme il faut ... C'est où exactement qu'on y gagne? C'est si cher que ça un serveur de load balancing correct ?

parce que de manière sous-jacente tu peux avoir plusieurs fermes de LB sur un même site, ou bien du cluster étendu sur deux sites différents

 
Pigé