Contenu | Rechercher | Menus

Annonce

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 02/01/2011, à 18:05

benoitne

Architecture Dual Site

Bonjour,

Je m'interesse à construire une architecture Dual Site et je me pose plusieurs questions sur l'architecture optimale...
Pour faire simple :

Deux sites avec adresses IP Fixes (A.A.A.A et B.B.B.B)
Deux serveurs identiques (Atom 1,6 / 500Go DD connectés en direct sur les freebox) qui hébergeront serveurs web/ftp...
OVH pour le registrer DNS type nom.fr (qui pointe avec un champs A vers A.A.A.A et un autre champs A vers B.B.B.B)

J'aimerai faire en sorte que si mon site avec l'adresse A.A.A.A tombe, mon site avec l'adresse IP B.B.B.B prenne le relais (Failover), le problème est que DNS permet un round robin mais pas une détection de panne...

J'ai pensé à deux solutions, la première d'avoir un troisième site avec une IP Failover qui fait une redirection vers le site A ou B en faisant un heartbeat permanent (trop lourd et si ce troisième site tombe tout le système ne sert a rien!)

Deuxième solution : Héberger sur le serveur A.A.A.A un DNS primaire et sur le site B.B.B.B un DNS Secondaire, en entrant c'est DNS chez OVH, à priori si le site A tombe le B devrait répondre (encore faut-il qu'après la synchro il y ait modification de la config pour faire répondre le serveur B à la place)

Que pensez-vous de cette architecture? Avez-vous des idées plus intéressantes sur ce sujet?

Merci d'avance,

Hors ligne

#2 Le 03/01/2011, à 11:12

Peck

Re : Architecture Dual Site

En fait tu es très embêté car le dns n'est pas fait pour ca. Le dns fait du round robin et pas du failover. Et si tu peux faire du failover au niveau du serveur DNS, tu sera embêté par les caches DNS qui sont assez longe un peu partout dans le monde (2h est une valeur fréquente).

Si tu accepte qu'un certain nombre d'utilisateurs aient une indispo de plusieurs heures tandis qu'une majorité on une indispo de seulement quelques minutes tu peux mettre un TTL très bas au niveau du dns et modifier les entrées lorsque tu as un problème.

Sinon il faut partir sur ta solution 1 et accepter que le 3e site peut tomber mais uniquement d'un point de vue réseau (moins de problèmes possible que pour une application complète).

Ta solution 2 ne fonctionne pas car un serveur dns primaire et secondaire doivent être actif en même temps et devraient répondre la même chose.

La seule solution viable multisite est d'être multihomé ce qui veut dire avoir un AS, acheter des IP qui t'appartiennent, avoir un routeur BGP et plueisurs fournisseurs de transit (ou faire faire ça par un hébergeur spécialisé). Dans tous les cas c'est cher.

Hors ligne

#3 Le 03/01/2011, à 18:44

chopinhauer

Re : Architecture Dual Site

Peck a écrit :

En fait tu es très embêté car le dns n'est pas fait pour ca. Le dns fait du round robin et pas du failover. Et si tu peux faire du failover au niveau du serveur DNS, tu sera embêté par les caches DNS qui sont assez longe un peu partout dans le monde (2h est une valeur fréquente).

C'est le serveur autoritaire pour une domaine qui décide de la longueur de mise en cache. Tu peux tourner sur des valeurs très petites (genre 60 secondes), sachant que cela augmentera la charge sur les serveurs et ralentira la connexion à la page Web (les lignes ADSL ont une latence de l'ordre de 30 ms au moins.

Benoitne la solution 2 ne me semble pas si mauvaise et les serveurs DNS ne sont pas obligés à donner les mêmes résultats (même si normalement ils le font).

La solution 1 te fera un long détour sur des lignes ADSL, encore une fois c'est découragé.

Regarde aussi le coût de ta solution : deux ordinateurs de bureau allumé 24/7 consomment assez d'énergie électrique. Un serveur dédié à 10-15€/mois sera certainement moins puissant, mais aura une connectivité meilleure (et plus stable).


Pensez à donner un bon titre à vos sujets : cela permettra d'aider d'autres utilisateurs dans votre même situation. Ce n'est pas qu'en donnant des solutions qu'on aide, mais aussi en posant des bonnes questions et… facilement trouvables.

Hors ligne

#4 Le 03/01/2011, à 22:30

Peck

Re : Architecture Dual Site

Le serveur autoritaire ne fait que donner une valeur de durée du cache, mais un certain nombre de FAI imposent un limite minimale pour cette faleur (ou la remplacent carrément par une valeur fixe) d'où la petite proportion de gens qui ne seront à jour que bien plus tard.

La solution 2 n'est pas viable car aucun système n'impose de consulter un serveur DNS plutot qu'un autre, primaire ou non les 2 serveurs DNS peuvent être interrogés à tout moment.

Hors ligne

#5 Le 04/01/2011, à 01:46

chopinhauer

Re : Architecture Dual Site

Peck a écrit :

La solution 2 n'est pas viable car aucun système n'impose de consulter un serveur DNS plutot qu'un autre, primaire ou non les 2 serveurs DNS peuvent être interrogés à tout moment.

Donc en utilisation normale, la charge serait repartie entre les deux serveurs, tandis qu'en cas de panne de un entre eux seulement un serveur HTTP sera utilisé (sur la même machine que l'unique serveur DNS qui reste). Cela me semble une honnête petite solution. Je pense que c'est ce que benoitne voulait.

Effectivement certains serveurs DNS resolver se permettent de augmenter les TTL donné par les serveurs autoritaires, mais les valeurs ne me semblent pas si grandes : les serveurs Proxad par exemple augmentent la valeur à 10 minutes (mais pas tous, certains gardent la valeur donnée).

De toute manière je ne pense pas que benoitne veut publier un site Web très populaire et vu le nombre de serveurs DNS resolver de chaque FAI (Proxad doit en avoir une 20-aine sur 2 adresses IP) peu de visiteurs tomberont sur une entrée dans le cache.

Dernière modification par chopinhauer (Le 04/01/2011, à 02:54)


Pensez à donner un bon titre à vos sujets : cela permettra d'aider d'autres utilisateurs dans votre même situation. Ce n'est pas qu'en donnant des solutions qu'on aide, mais aussi en posant des bonnes questions et… facilement trouvables.

Hors ligne