Salut à tous

J'ai une question qui me turlupine depuis un certain temps... J'ai 1 serveur dédié avec une IP fixe chez un hébergeur, qui contient un site web ainsi que le serveur DNS de mon domaine. Mais j'ai une copie des données et du site sur un serveur local, derrière une connexion ADSL à IP fixe, d'un autre opérateur.

Question : au niveau DNS comment faire en sorte de lui dire que www.monsite.com doit être par défaut l'ip du serveur dédié, MAIS qu'en cas de problème (serveur dédié injoignable), il donne l'ip du serveur de backup sur adsl ?

Eléments de réflexion :
- le mécanisme d'un DNS secondaire n'a rien à voir ici, puisqu'un dns secondaire doit être une copie conforme du serveur primaire, il ne sert qu'à palier à un crash dns.
- impossible de modifier la configuration dns à la volée, puisque les infos mettent énormément de temps à se propager dans les caches DNS des opérateurs du monde entier; de plus si le serveur dns est injoignable, impossible de modifier quoique ce soit
- j'ai entendu parler du mécanisme de "round-robin dns" : ça consiste à renseigner plusieurs IP par adresse, comme ceci

Inconvénient majeur : pas moyen de prioritiser ces IP, le DNS renvoit de manière +/- aléatoire l'une d'entre elle. C'est donc une solution plutôt adaptée pour le load balancing, mais pas pour le failover comme moi je veux.
- en fait la technologie pour ce que je veux faire existe au niveau des dns MAIS... uniquement pour les serveurs mails

Où les chiffres 10 et 50 indiquent la priorité du serveur à renseigner : donc si le serveur principal est joignable il renseignera toujours celui-là, sinon il renseignera l'autre.

Cette prioritisation des records MX est-elle aussi possible sur les records A (alias), et si oui comment ?
Ou bien y a-t-il d'autres moyens d'arriver à mes fins ? Sans avoir une 3e machine de surveillance pour rediriger les appels à la volée, car si elle tombe aussi, ça ne sert à rien...

Merci d'avance à tous ceux qui pourront m'éclairer, j'espère que j'ai été +/- compréhensible

Bah, c'est à toi de dire combien de temps tu veux qu'ils gardent le tout en cache, en général quand je modifie mon record DNS moi c'est updaté en moins d'une heure, encore raisonnable en cas de gros crash de toute façon, non?

Déjà alors :

Pour ton domaine :
ns1.www.be >> serveur paris
ns2.www.be >> serveur bruxelles

tous les deux configurés de la même manière.

Pour la conf dns, ca se complique:

Oui, on peux mettre deux "A" (pratique lors du multiserveurs)
Mais gérer une priorité comme pour le "MX" je ne sais pas...

Faudra fouiller un peu

Oué, si tu mets un TTL bas en effet, mais ça génère un certain trafic, en général on met 12 ou 24h je pense ?

De toute façon, il faudrait que ce soit fait de manière automatique, sans intervention humaine Enfin tu vas me dire qu'avec un petit script il y aurait encore moyen de bidouiller ça (genre si le ping ne répond pas, on update le dns).

Un certain trafic... certainement, mais comparé au trafic généré par l'http ou le mail, ca me semble négligeable si tu laisses 1h de rabe, non?

Et tu voudrais que ca se passe sans intervention humaine... mouais, à part jouer avec un cluster alors je vois pas
J'y ai jamais regardé en tout cas

Bonjour,

J'ai exactement la même problématique.
Voici ce que j'avais posté dans un forum (130 lectures mais pas
1 réponse !!!) :
"
Bonjour à tous,

Je possède un site web (imaginaire) www.toto.fr parfaitement référencé dans dans le domaine .fr (Parent servers existant avec les enregistrements NS précisant 2 serveurs DNS faisant autorité sur la zone toto.fr).

J'appelerai ce site web de nominal et il est géré par un provider.

Je possède également un autre site web (autre machine), qualifié (vous vous en doutez déjà) de secours, wwwsec.toto.fr.

Ce site de secours est utilisé uniquement lorsque le site nominal est indisponible (machine, accès réseaux et tout le toutim).

Dans ce cas, je souhaite que l'internaute continue de saisir comme URL www.toto.fr et je ne veux pas que le DNS lui retourne une erreur (serveur non trouvé).

Si le site nominal présente le vrai site web, le site de secours présente une simple page html précisant que le site nominal est sinsitré. Tout le temps que durera le sinistre, la page html de ce site de secours évoluera (l'information présente dans la page évoluera au fil du temps).

Parmi les possibilités techniques, j'entrevois :

a) modification des DNS faisant autorité sur la zone toto.fr et plus particulièrement de l'enregistrement de type www IN A adr-IP1
par www IN A adr-IP2

b) modification des DNS en ajoutant un enregistrement de type
HTTP redirection dans lequel, et après sinistre sur le premier site,
on map www.toto.fr sur wwwsec.toto.fr

c) ajout d'un 2ème enregistrement de type A sur les serveurs DNS faisant autorité www IN A adr-IP2 (permettant la mise en place d'un roundrobin)

Une autre solution consisterait en un doublement de l'infrastructure réseaux, serveur localisés sur un 2ème site physique + 2ème enreg de type A + round robin, mais je réfute une telle solution pour son coût.

La soluce a) présente l'incovénient du temps de mise à jour des DNS de l'Internet.

La soluce c) présente le gros désaventage d'acheminer, en fonctionnement nominal, des requêtes clients sur le site web de secours à cause du round robin.

La soluce b) me paraît intéressante mais je ne sais pas si il y aura une mise à jour - et surtout sa propagation - sur tout l'internet.

Quelqu'un peut-il répondre sur ce point et/ou indiquer une solution technique viable et fort peu onéreuse (qques euros par mois de location d'un site de secours par exemple) ?

Si la soluce b) est viable (voir raison temps de propagation), serait-il préférable de le faire avec un site web dans une autre zone (par exemple www.totosec.fr) ?

Par avance Merci de votre collaboration.
"

Effectivement vous avez raison pour le secours de machine de type
mail.domaine.fr (par exemple) => il existe alors plusieurs enregistrement de type MX.

Avez-vous reçu une réponse technique (valable) ou des pistes ?

Jose95

Disons que la modification de DNS doit se faire moyennant une détection de panne à priori, donc tu dois avoir un script sur ton DNS secondaire qui détecte que ton serveur primaire est mort et modifier le record automatiquement pour prendre le relai. Seulement, après coup, il faut aussi rechanger le record sur le DNS primaire, sinon ton serial n'ayant pas été incrémenté, des gens resteront sur ton serveur de secours.

Reste alors le cas des gens qui aurons un cache du DNS, tes visiteurs habituels, la, c'est impossible d'agir au niveau du DNS vu qu'ils ont déjà fait leur résolution. La seule solution technique à mon sens pour avoir un downtime minimum, c'est d'avoir un cluster, mais question coût, ca chiffre un peu plus...

Ah oui, evidemment, tu pourrais désactiver le cache DNS, ou du moins mettre une valeur suffisemment petite pour que les gens reloadent le record DNS à chaque visite, mais c'est à double tranchant, tu augmentes aussi la charge de ton serveur DNS et le temps de réponse de ton site (vu qu'il faudra quasi à chaque fois faire un resolve).

C'est pas évident

Jose> Oui : http://forum.adsl-bc.org/viewtopic.php?t=22013

Mais j'avoue ne pas y avoir travaillé depuis (tellement d'autres choses à faire... )

En tout cas ça fait plaisir de ne pas se sentir seul

Sinon si on a du fric, la meilleure solution c'est ça, mais bon... :
http://www.ovh.com/fr/produits/cluster.xml

Dites-le si je me trompe.
pour ton domaine "www.domaine.be", le NS principal se trouve juste derrière le ".be" et indique à qui il faut s'adresser pour trouver "www".
Le NS secondaire contient l'adresse de "www" et ne s'occupe que de "domaine.be".

Si j'ai bien compris (encore...) c'est la mise à jour du serveur primaire qui prend du temps.

Il est donc assez facile et rapide de modifier à la vollée le NS secondaire pour rediriger "www" vers une nouvelle IP sans toucher au NS principal.

Je tire ses conclusion de la manière de fonctionner de ZoneEdit.

Un service de DNS externe avec mise à jour dynamique peut aussi résoudre ton problème, mais c'est moins fun, puisqu'on a pas la main sur tout.

Bonjour,

En fait les NS contiennent la liste des serveurs DNS faisant autorité pour une zone concernée : ils ne contiennent aucune information sur les machines d'une zone donnée.
Ansi, l'adresse de www est indiqué dans un enregistrement de type A sur un serveur DNS (fichiers de zone).

L'adresse de mail.domaine.be est indiqué dans un enregistrement de type MX dans les fichiers décrivant la zone sur un serveur DNS faisant autorité

D'autres serveurs pourraient répondre et par exemple quand un serveur DNS possède l'info et qu'il est interrogé par l'utilitaire nslookup on voit bien
apparaître en réponse "serveur ne faisant pas autorité".

Comme je l'ai vu dans un des messages échangés, avec les enregistrements MX il est possible de configurer plusieurs serveurs relais de messagerie avec un poids différent, ce qui ne semble pas possible avec les enregistrement de type A.

Par ailleurs, le cluster pourrait répondre à la condition que cela soit un cluster "distribué sur 2 sites distants" et entrainerait une problématique concernant le réseau : il faudrait entre les 2 sites un lien réseau transportant les messages de hello du de heartbeat, les mise à jour croisées entre les fonctions de stockage de chacun des sites (j'imagine que chaque sute web est couplé avec une base de données).

Mon besion est un différent : je souhaite qu'en cas de sinistre grave (bombe, inondation, ...) accès au stockage entraînant la disparition des locaux hébergeant le serveur www que les clients, non informés du sinistre, continuent de saisir www... (du reste ils ne pourraient saisir autre chose comme URL) et que cela aboutisse sur un serveur (site web) www présentant une page d'information du type "La Société X a connu un sinitre ... la situation est msopus contrôle ... nous nous efforçons ... etc).

Il faut bien voir que les clients non informés du sinistre, puisque je souhaite pouvoir les informés par le site web www mais pointant sur un autre serveur web -Autre adresse IP-, ne peuvent que saisir le www... saisi en tant ordinaire (hors sinistre).

Cordialement,

Jose95

Jose> C'est impossible tel quel. Tu peux au mieux espérer qu'en cas d'avarie grave sur ton serveur, tu changes automatiquement ton DNS pour aller sur l'autre serveur. A toi de programmer un script qui décide quand le faire (aidé par un outil comme mon/monit par exemple) mais cela ne sera pas immédiat à la seconde, sauf si tu acceptes que ton serveur DNS soit bombardé de requêtes pendant toute l'année.

JC> Non, tu t'es planté, tu as 2 DNS qu'on appele secondaire et primaire mais qui ne sont, en théorie, que des copies l'un de l'autre. Primaire comme secondaire gèrent la même chose.

Chez dns.be, tu as pour informaticien.be 2 ips de DNS, un miroir et celui-ci.
Après, je dois définir informaticien.be, www.informaticien.be et plop.informaticien.be dans le même record.

http://www.commentcamarche.net/internet/dns.php3

Et tu as des exemples de fichier host ici:
http://www.zytrax.com/books/dns/ch8/soa.html

C'est mal foutu quand même, ils auraient pu penser à prioritiser les records A aussi, non mais

Oui, mais tu imagines alors qu'il faut, en permanence, une réplique exacte de ton serveur de l'autre côté pour, qu'en cas de site injoignable 2s, le mec aille sur le deuxième site?

C'est difficilement gérable au niveau DNS, quand on veut ce genre de certitudes, on se paie un cluster

Le CLuster n'est pas forcément la solution et n'amène rien si ce même cluster est centralisé sur un site. Par ailleurs, il n'est pas forcé qu'un site web bouge constament (l'arborescence des pages et formulaires) : ce qui bougera (si le site fonctionne ainsi) ce sont les données saisie et / ou modifiées par les internautes surfant sur le site (par exemple site de commerce).

LEs différentes transactions sont alors enregitrées dans une base sur chaque site, base répliquée entre les sites. Plus exactement, le delta entre les 2 bases sera répliqué (produit de type double take, ... coût environ 10 k€ pour le soft mais dépend de la négo Client - Fournisseur).

Pour la partie DNS : effectivement un ping ou autre continu et schédulé pourrait faire l'affaire si ce n'est que dans mon cas les 2 serveurs DNS sont externalisés. Je pense que le fait de gérer mon propre serveur DNS Maître m'aurait facilité la tâche ? A moins qu'un provider puisse proposer ce genre de service ?

Cordialement.

Jose95

Cela dépends de tes besoins, mais si tu as un site communautaire, en plus des données en DB, tu as aussi des données sur disques que tu dois absolument répliquer (avatars et cie) et qui sont très souvent mises à jour.

Même pour un site de commerce, si tu dois faire gaffe à uploader tes images sur 2 serveurs à chaque fois, tu vas vite en avoir marre et tu risques de ne pas avoir une réplique exacte.... Mais bien sûr, si t'en as pas besoin, tu peux te contenter d'une réplication de DB, MySQL le propose, mais si ton site est gourmant, et il doit l'être pour arriver à de telles solutions ou être sensible, cela va consommer énormément si tes machines ne sont pas localisées dans un même datacenter.

Je ne suis pas prêt à perdre une partie de ma bande passante et de mon CPU pour de la réplication

Mais quoi qu'il en soit, ce ne sont pas des solutions en général pour un particulier, donc à moins de gérer beaucoup par toi même pour avoir un contrôle total, cela risque de te couter un max d'argent...

Tu as raison, il s'agit d'une entreprise de taille ... respectable et capable de mettre en regard d'une perte d'activités mais aussi pour son image (domaine Financier / Bancaire / Assurance)des solutions coûteuses pour palier à la survenue de sinistres graves.

(j'ai peut-être posté un précédent message à moitié coupé => j'ai ripé sur le clavier et là il n'y a aps beaucoup de solution de secours => la dictée vocale ?)



Jose95

Sisi, il y a une solution

C'est aussi une solution pour des projets plus larges, mais cela réclame toujours des moyens ... et des connaissances...

effectivement le coût des solutions DRP sont absolument pharaoniques. Par exemple Oracle RAC ça se compte en centaines de milliers d'euros, sans compter l'infrastructure et le jours/hommes.
Cela est évidement nécessaire pour des institutions à qui x minutes d'indisponibilité d'une application entraine une perte financière conséquente (SLA, Cut off time,...)