DEDIBOX-NEWS.COM

Bonjour Calimero, peux tu m'expliquer le RR DNS ?

Merci

Nusa a fait le gros de l'explication pour le RR DNS.

Je vais juste préciser les limitations (qu'il faut garder en mémoire).

Premier écueil: maintenir des sessions.

Si par exemple on veut faire du HTTP, il faut se rappeler que le protocole HTTP est "stateless", c'est à dire sans état/session.

Il faut donc avoir recours à des "magouilles" pour maintenir un semblant de session. Le serveur (comprendre le moteur de script: php, asp...) va envoyer un marqueur au client. Lorsque le client va envoyer une nouvelle requête pour une 2ème page, il va renvoyer ce marqueur au serveur. Le serveur, à partir du marqueur, va pouvoir retrouver les informations du client dans sa mémoire.

C: client
S: serveur

- C ==> S : "envoie moi index.php"
- S ==> C : <contenu de index.php> + marqueur SESSION=4242
- C ==> S : "envoie moi article.php" + marqueur SESSION=4242
- S recherche en mémoire la session N°4242 et récupère les infos
- S ==> C : <contenu de article.php> + marqueur SESSION=4242
- C ==> S : "envoie moi profile.php> + marqueur SESSION=4242
...

Bref, on voit que ce marqueur fait constamment des A/R entre client et serveur pour que le serveur puisse retrouver les informations de session de son côté.

Ce marqueur est typiquement un cookie mais peut aussi être un paramètre ajouté dans l'URL, genre "article.php?SESSION=4242".

En RR DNS, le principe même est d'avoir différents serveurs/IP pour un même nom DNS, disons: www.site.com qui correspond aux IP 1.2.3.4, 4.5.6.7 et 6.7.8.9.

Donc le client fait une requête sur www.site.com, celle-ci arrivera sur l'IP 1.2.3.4. Une seconde requête sur www.site.com l'enverra peut-être sur l'IP 6.7.8.9 ou 4.5.6.7.
Le soucis, c'est qu'en passant de serveur à serveur (de manière transparente), une session commencée sur l'un n'existera pas (ou aura un contenu différent) sur l'autre.
C'est le phénomène que tu auras si tu fais du RR DNS avec du apache/php standard: les informations de session sont stockées côté serveur dans des petits fichiers sur le disque dur.

Il faut donc que les informations de session soient partagées par les serveurs: un répertoire partagé sur le réseau, une base de données, ...

Au lieu que chaque serveur stocke ses propres infos de session sur son disque dur, les informations seront stockées dans une base de données communes, ou un daemon réseau spécialisé.

Bref, du coup, il est possible de maintenir les sessions même quand l'utilisateur tape successivement sur les différents serveurs/IP qui correspondent à www.site.com

Si on ne veut pas d'un tel mécanisme, ou si l'application le permet pas, il faut se tourner vers un système de load balancing qui va gérer les choses plus finement, mais c'est pas la même complexité ni le même coût.

Second écueil: la panne

Si on a un ensemble de N serveurs dont un serveur tombe, on va se retrouver avec (en théorie...) 1/Nème des requêtes qui vont échouer.

Il faut donc un mécanisme pour éliminer les serveurs morts des DNS pour que les clients n'essaient plus de se connecter vers ces serveurs.
On peut imaginer d'avoir des entrées DNS www0.site.com, www1.site.com, www2.site.com pour éventuellement permettre aux utilisateurs de taper dans une machine directement sans passer par le RR DNS et "contourner" une machine down.

Autre solution, avoir des DNS "actifs" qui vont permettre la suppression automatisée des serveurs morts. C'est concevable même si un tel mécanisme ne peut emêcher la mise en cache de l'information DNS au niveau du FAI ou même au niveau de l'OS du visiteur, voir à son navigateur (Internet Explorer a sa propre cache DNS...).

Sur ce point aussi, le load balancing permet de résoudre ce problème: le load balancer interroge à intervalle régulier les serveurs, si l'un tombe, plus aucun traffic ne sera forwarder vers lui. Mais à nouveau, c'est pas la même complexité, ni les mêmes couts.

Bref, le RR DNS sur certaines applications permet d'améliorer la tenue à la charge et dans une certaine mesure d'améliorer la disponibilité.

Le round robin DNS ne permet pas un vrai controle de la répartition de la charge. Si un serveur tombe, c'est _très_ théoriquement 1/5ème de tes visiteurs qui vont aller mourir.
Maintenant, il y a différents facteurs qui font que tu peux pas dire exactement ce qui va se passer. En tout état de cause, tu as intérêt à avoir un TTL assez bas pour permettre le plus rapidement (modulo les caches qui ne respectent pas les TTL) de dégager l'IP d'un serveur down.
Si tu veux vraiment une transparence totale, c'est du côté du load balancing qu'il faut regarder (LVS ou autres solutions). C'est pas la même complexité et ca peut être sportif à gérer sur un réseau où tu controles à peu près rien (le cas ici).

Concernant les sessions PHP, le fonctionnement est le suivant:

A/ un visiteur arrive sur le site et fait une requête HTTP du genre "GET /index.php". Il est fraîchement débarqué, il n'a aucun cookie du site, donc il n'en envoie aucun au serveur...
B/ le serveur traite la requête. La couche PHP déclenche le traitement des sessions (parce que session_start() dans index.php). Il n'y a pas d'identifiant de session (PHPSESSID, ici on en a ni dans l'URL, ni dans les cookies). Un identifiant de session est généré. Les informations de session ($_SESSION[*]) sont stockées par le serveur par le session_handler: typiquement un fichier sur le disque dur du serveur, mais ca peut être en RAM, ou dans tout autre système de stockage.
C/ le serveur renvoie l'id de session sous forme de cookie à l'utilisateur, en servant le contenu de index.php

D/ notre cher visiteur décide de cliquer sur un lien vers toto.php. Il envoie une requête "GET /toto.php" et envoie par la même son cookie PHPSESSID avec son ID.
E/ le serveur récupère le PHPSESSID et peut récupérer dans son backend de stockage les infos de session pour les rendre dispo au script ($_SESSION[*] toujours).
etc...

Pour ton histoire de cookie, il n'y pas de problème vu que les cookies sont par hostname (et éventuellement path) et non par IP.
Donc un navigateur qui serait balancer d'IP en IP enverra bien son cookie.

Le "souci", pour les sessions, c'est qu'il faut que le stockage côté serveur soit partagé: tous les serveurs doivent partager les mêmes informations pour qu'un utilisateur qui bascule de serveur ne se retrouve pas sans infos de session. Y a différentes techniques pour ca.

pour mysql, je pense pas qu'il y a de probleme, mysql cluster semble etre une bonne solution (que je n'ai pas encore teste).

pour l'histoire des session, il faut pas compter sur le cache dns pour que la meme ip revienne? J'en suis pas sur car j'ai cru lire que certain browser (dont IE) recupere toutes les addresse ip d'un nom de domaine et fait du load balancing directe dedans. D'ailleurs, quand une des ip est down, le browser essaye automatiquement les autres.

Il suffirait de stocker les session dans mysql...

L'autre solution assez simple est de faire du load balancing a travers la redirection.
www. est un round robin dns
chaque serveur repond au www par une redirection vers un serveur reel (www2.xxx) Une fois attribue un serveur, l'utilisateur reste dessus, plus de probleme de session.

J'ai une autre question sur la solution heartbeat (auto surveillance entre 2 serveurs)
admettons que je loue 2 dedibox A et B avec des ip sur le meme subnet.
Si A tombe, est que B peut recuperer l'ip de A pour prendre le relais?
Dans ce cas, B pourrait repondre aux deux ips?
Une fois que A se reveille, elle recupere alors l'ip de B.
Ca concerne comment dedibox gere les ip et surtout comment les routeurs et switchs ethernet sont configures.
Ca me parait pas impossible non?

sophana a écrit:

pour l'histoire des session, il faut pas compter sur le cache dns pour que la meme ip revienne? J'en suis pas sur car j'ai cru lire que certain browser (dont IE) recupere toutes les addresse ip d'un nom de domaine et fait du load balancing directe dedans. D'ailleurs, quand une des ip est down, le browser essaye automatiquement les autres.

De ce que j'ai constaté personnelement, la gestion DNS d'IE (et globalement de Windows) est plutôt misérable.
IE garde en cache en se foutant royalement des TTL. Faut relancer IE... pour ensuite échouer sur la cache de Windows.
Pour le retry successif sur les différentes IP, j'avoue ne pas connaître le comportement des différents user agents qui trainent.

Reste qu'en théorie, entre deux requêtes, un utilisateur peut arriver sur différents serveurs. Il faut donc s'assurer, côté serveur, de la presistence des sessions.

sophana a écrit:

Il suffirait de stocker les session dans mysql...

Un backend du type memcached/mcache(msession) est sans doute plus intéressant. Et ca a l'avantage de pas surcharger inutilement le serveur SQL.
Mais il est effectivement tout à fait possible de faire un save_handler en base.

sophana a écrit:

J'ai une autre question sur la solution heartbeat (auto surveillance entre 2 serveurs)
admettons que je loue 2 dedibox A et B avec des ip sur le meme subnet.
Si A tombe, est que B peut recuperer l'ip de A pour prendre le relais?
Dans ce cas, B pourrait repondre aux deux ips?
Une fois que A se reveille, elle recupere alors l'ip de B.
Ca concerne comment dedibox gere les ip et surtout comment les routeurs et switchs ethernet sont configures.
Ca me parait pas impossible non?

Arnaud semblait dire que la configuration des VLAN permettent dans une certaine mesure le "vol" d'IP entre dédibox (entre dedibox d'un même client).
Toutefois, je suis un peu circonspect sur un tel montage dans un réseau que tu ne controles pas.
Le setup classique est d'avoir 2 machines, 3 ip publiques.
Chaque machine a son IP publique propre et la 3ème ip publique fait office d'IP "virtuelle", c'est à dire l'IP envoyée aux gens et qui va être basculée du serveur primaire au serveur secondaire en cas de panne.
Bref, c'est peut-être possible, mais partir sur une solution poussée dans un environnement où tu subis plus que tu contrôles, je pense qu'il faut bien étudier la question et ne pas écarter trop rapidement des solutions plus simples.

La bascule DNS peut prendre entre quelques dizaines de secondes et quelques minutes, selon le respect des TTL par les différents "acteurs" impliqués.

Le système de cache DNS est assez bien conçu et est nécessaire au fonctionnement global. Si tu supprimes les caches, tu accrois salement le trafic pour la résolution ainsi que la charge sur les serveur DNS. Globalement la majorité des applications et services se contentent de TTL assez élevés (dizaines de minutes, voire dizaines d'heures). Ce qui est par contre regrettable, c'est que certains "maillons" de la chaine ne jouent pas le jeux: IE (et la cache DNS de Windows) ne respectent pas les RFC, typiquement sur la question des TTL. Donc t'as beau mettre un TTL de 5 minutes, les utilisateurs de ce couple de navigateur/système verront la MaJ des infos DNS pas aussi tôt que si les softs étaient bien écrits. Pour les applications qui doivent limiter au maximum la durée de bascule, il vaut mieux regarder du côté du load balancing.

Ensuite, concernant la bascule entre deux sites... faut déjà réfléchir à la question de base: combien me coûte une indisponibilité de 30 minutes ? Combien me couteraient les moyens nécessaires (techniques et humains) pour réduire ce délais de bascule ?

On peut imaginer des solutions niveau IP pour éviter les histoires DNS (tu dis à ton transitaire de balancer le trafic réseau normalement destiné au site A vers le site B)...

Mais y a pas de système qui t'assurera une disponibilité totale. Ca tombe bien, les applications qui en ont besoin sont très très très rares.

Peu de ressource, ça dépend .
Un gros forum ça va aider d'avoir un web frontal et un sql derriere

Bon vous êtes pret pour faire un test de cluster sql et de load balancing ? ^^

XaT

Bonjour ;

Je me permet de remonter ce post qui date car justement, je suis entrain de plancher sur la mise en place d'un cluster haute disponibilité avec équilibrage de charge pour un service web (apache)

Ici, deux noeud serait employés (deux dedibox) :

Soit :

NS1 ( ADRESSE REELLE -->88.191.xx.01)
et
NS2 (ADRESSE REELLE -->88.191.xx.02)

Ensuite, une VIP serait créé sur NS1 ( ip addr add 192.168.0.100 netmask 255.255.255.0 dev eth0)

Le premier problème rencontré ici, c'est que la VIP serait une  adresse privée non accessible de l'extérieure. Pour réglé le problème, j'ai pensé à faire du NAT.

Le deuxième problème, c'est de savoir comment permettre au noeud NS2 d'être accessible lorsqu'il s'attribut la VIP sur l'interface eth0 en cas de panne de NS1. Dans le contexte réseau dedibox, c'est bien entendu quasi impossible.

J'ai donc pensé à une solution (vraiment tordue) mais qui théoriquement devrait fonctionnerait.

Il s'agirait en fait de créer une pseudo passerelle pour la VIP qui serait adressée dynamiquement via system NO_IP.

En gros, nous aurions :


POUR NS1 : (LoadBalancer actif)

88.191.xx.01:80 ---> NAT --- 192.168.0.100 ----> 88.191.xx.01:81( dans le cas de rqst 1)
                                                                               88.191.xx.02:81 (dans le cas de rqst 2)

POUR NS2 : (LoadBalancer passif)

88.191.xx.02:80 ---> NAT ---> 192.168.0.100 ----> 88.191.xx.02:81( dans le cas de rqst 1)


Ainsi, pour que la VIP soit accessible, il faudrait en fait que l'adresse de la passerelle soit adressée dynamiquement.

soit  que sont adresse soit  88.191.xx.01 si NS1 et NS2 sont OK ou que NS1 seul est OK

ou 88.191.xx.02 si NS2 et pas ok

Pour arriver à cela, j'ai pensé utiliser le service No Ip. Ainsi, sur NS1, j'installerais un client no_ip toujours actifs qui indiquerais que l'adresse et 88.191.xx.01 et sur NS2, je ferais du monitoring sur NS1 (via ping) sur adresse 88.191.xx.01 et selon la réponse, je démmarerais un client no_ip passive qui ne rentrerais pas en conflit avec le client installé sur NS1 puisque ce dernier étant dead. Le client no_ip mettrais donc à jour l'adresse de la passerelle VIP en 88.191.xx.02 et s'arrêterais de suite.

Voilà théoriquement ce à quoi j'ai pensé.

Note : Ici, apache écouterais sur le port 81 mais cela serait transparent pour les clients.

Ps : Je sais que ceci est du chinois pour ceux qui ne connaisse pas la chose.

Je remercie les pro de TCP/IP de le donner leur avis concernant cette théorie qui je le reconnais est assez tordue.

Dernière modification par nuxwin (2007-10-03 11:54:01)