Éviter les délais d'attente DNS en cas de défaillance d'un serveur DNS


17

Nous avons un petit centre de données avec une centaine d'hôtes pointant vers 3 serveurs DNS internes (bind 9). Notre problème survient lorsqu'un des serveurs DNS internes devient indisponible. À ce stade, tous les clients qui pointent vers ce serveur commencent à fonctionner très lentement.

Le problème semble être que le résolveur Linux standard n'a pas vraiment le concept de "basculement" vers un autre serveur DNS. Vous pouvez ajuster le délai d'expiration et le nombre de nouvelles tentatives qu'il utilise (et définir la rotation pour qu'il fonctionne dans la liste), mais quels que soient les paramètres que nous utilisons, nos services fonctionnent beaucoup plus lentement si un serveur DNS principal devient indisponible. Pour le moment, il s'agit de l'une des plus importantes sources de perturbations de service pour nous.

Ma réponse idéale serait quelque chose comme "RTFM: tweak /etc/resolv.conf comme ça ...", mais si c'est une option, je ne l'ai pas vue.

Je me demandais comment d'autres personnes ont géré ce problème?

Je peux voir 3 types de solutions possibles:

  • Utilisez linux-ha / Pacemaker et les ips de basculement (pour que les VIP IP DNS soient "toujours" disponibles). Hélas, nous n'avons pas une bonne infrastructure d'escrime, et sans l'escrime, le stimulateur cardiaque ne fonctionne pas très bien (d'après mon expérience, Pacemaker réduit la disponibilité sans l'escrime).

  • Exécutez un serveur DNS local sur chaque nœud et faites pointer resolv.conf vers localhost. Cela fonctionnerait, mais cela nous donnerait beaucoup plus de services à surveiller et à gérer.

  • Exécutez un cache local sur chaque nœud. Les gens semblent considérer nscd comme "cassé", mais dnrd semble avoir le bon ensemble de fonctionnalités: il marque les serveurs DNS comme étant en haut ou en bas, et n'utilisera pas les serveurs DNS "en bas".

Any-casting semble fonctionner uniquement au niveau du routage IP, et dépend des mises à jour de route pour l'échec du serveur. La multidiffusion semblait être une réponse parfaite, mais bind ne prend pas en charge la diffusion ou la multidiffusion, et les documents que j'ai pu trouver semblent suggérer que le DNS de multidiffusion vise davantage la découverte de services et la configuration automatique plutôt que la résolution de DNS standard .

Suis-je en train de manquer une solution évidente?


2
Je suggère qu'en plus de trouver la solution que vous demandez (avec laquelle je ne peux pas vous aider), vous devriez travailler sur le vrai problème racine et résoudre les problèmes de fiabilité avec le serveur DNS.
John Gardeniers

Le problème racine est: pourquoi ces serveurs DNS tombent-ils si souvent en panne pour vous déranger? Pensez à répliquer votre DNS avec des services spécialisés comme BuddyNS . Votre latence diminuera considérablement et le temps de disponibilité ne vous dérangera plus pour les réglages /etc/resolv.conf.
michele

Réponses:


15

Quelques options. Les deux répartiront la charge DNS sur vos serveurs DNS.

  • Essayez d'utiliser options rotatedans resolv.conf. Cela minimisera l'impact de l'arrêt du serveur principal. Si l'un des autres serveurs est en panne, cela ralentira les actions.
  • Utilisez un ordre de serveur de noms différent sur différents clients. Cela permettra à certains clients de fonctionner normalement si le serveur DNS principal est en panne. Cela répartit l'impact d'un serveur DNS hors service.

Ces options peuvent être combinées avec options timeout:1 attempts:5. Augmentez les tentatives si vous diminuez le délai afin de pouvoir gérer les serveurs externes lents.

Selon la configuration de votre routeur, vous pourrez peut-être configurer vos serveurs DNS pour prendre en charge l'adresse IP du serveur DNS principal lorsqu'il est hors service. Ceci peut être combiné avec les techniques ci-dessus.

REMARQUE: je gère des années sans pannes DNS imprévues. Comme d'autres l'ont noté, je travaillerais à résoudre les problèmes entraînant la défaillance des serveurs DNS. Les étapes ci-dessus aident également les serveurs DNS mal configurés à spécifier des serveurs de noms inaccessibles.


4

Découvrez "man resolv.conf". Vous pouvez ajouter une option de délai d'expiration au fichier resolv.conf. La valeur par défaut est 5, mais l'ajout de ce qui suit à resolv.conf devrait le ramener à 1 seconde:

délai d'expiration des options: 1


Après avoir relu votre deuxième paragraphe, j'ai essayé ce qui précède sur un VPS Centos et Debian. Après avoir supprimé le DNS principal, le résolveur a fonctionné exactement comme prévu. En exécutant un tcpdump, je pouvais même voir le résolveur essayer le premier serveur, puis essayer le suivant. Quel comportement voyez-vous?
Niall Donegan

1
Il existe deux grands cas d'utilisation pour la résolution: les processus à courte durée de vie (comme les outils de ligne de commande) et les processus à longue durée de vie, et la même configuration de résolveur doit fonctionner pour les deux. Pour une durée de vie courte (recherche unique), un court délai d'attente basculera rapidement. Mais si vous recherchez une adresse externe qui ne se résout pas dans ce délai: vous obtiendrez un nom introuvable, car le résolveur abandonnera cette requête si elle ne revient pas dans une seconde. (hors de la salle; plus dans le commentaire suivant)
Neil Katin

Les processus à long terme réessayeront chaque recherche, chaque délai d'attente, puis passeront au serveur suivant. Mais il ne semble pas mettre en cache la "mort" du serveur.
Neil Katin

3

Un logiciel de clustering tel que Heartbeat ou pacemaker / corosync est votre ami ici. Par exemple, nous avons configuré pacemaker / corosync comme suit:

  • Associez chaque serveur à un autre
  • Par paire ont 2 vns DNS, généralement un sur chaque
  • En cas de liaison ou de défaillance du serveur, le vip se déplace vers l'autre serveur en quelques millisecondes

Les heures de production sont 24h / 24 et 7j / 7, mais nous croyons fermement qu'il devrait être possible que chaque serveur tombe en panne sans affecter les clients. l'option rotation n'est qu'une solution de contournement, je ne ferais pas cela.


3

Exécutez un serveur DNS local sur chaque nœud et faites pointer resolv.conf vers localhost. Cela fonctionnerait, mais cela nous donnerait beaucoup plus de services à surveiller et à gérer.

FWIW, c'est la seule solution réalisable que j'ai trouvée pour ce problème. Vous devez restreindre le serveur pour écouter uniquement sur localhost, mais cela a complètement éliminé les utilisateurs remarquant des pannes DNS dans notre environnement.

Un effet secondaire intéressant est que si le serveur localhost tombe en panne pour une raison quelconque, les bibliothèques de résolveurs standard semblent gérer le basculement vers le serveur suivant beaucoup plus rapidement que dans le cas standard.

Nous faisons cela depuis environ 3 ans maintenant et je n'ai vu aucun problème pouvant être lié à la panne / panne d'un serveur DNS fonctionnant sur localhost.


2

Si un serveur de noms est en panne pour maintenance, il est normal de réduire à l'avance les délais d'attente dans le SOA pour ce domaine, de sorte que lorsque la maintenance se produit, des changements (comme la suppression des enregistrements NS avant la maintenance et les remettre après la maintenance) ) se propagent rapidement. Notez qu'il s'agit d'une approche côté serveur - le changement de résolveurs est une approche côté client et ... à moins que vous ne puissiez parler à chacun de vos clients et les amener à effectuer cet ajustement sur leur machine ... pourrait ne pas être la bonne approche. Eh bien, je suppose que vous n'avez dit qu'une centaine de clients dans un centre de données utilisant des serveurs DNS internes, mais voulez-vous vraiment changer la configuration d'une centaine de clients alors que vous pouvez simplement changer de zone?

Je vous dirais quelles valeurs dans la SOA ajuster, mais je surfais sur le Web pour trouver ces informations exactes lorsque j'ai rencontré cette question.


3
Cette réponse concerne uniquement le DNS faisant autorité. La question concernait les recherches DNS récursives effectuées par le logiciel client.
Andrew B

1

Peut-être pouvez-vous mettre vos serveurs DNS derrière un équilibreur de charge? Apparemment, LVS peut équilibrer UDP. Évidemment, rendez votre LB hautement disponible afin qu'il ne soit pas un point de défaillance unique.


0

Je sais que cela peut sembler banal, mais que diriez-vous de construire une infrastructure DNS plus stable et résiliente en tant que solution permanente au problème.


Nous avons une infrastructure DNS assez résistante. Mais 2 ou 3 fois par an, nous avons une panne parce qu'un serveur DNS tombe en panne (ou est redémarré, ou a une mise à niveau du système d'exploitation, ou autre).
Neil Katin

1
Eh bien ... les redémarrages et les mises à niveau doivent être planifiés pour les heures hors production. Pour le reste, il semble que vous fassiez une grosse affaire avec quelque chose qui se produit plusieurs fois par an. L'infrastructure supplémentaire, le temps, l'argent et les frais généraux de gestion en valent-ils la peine pour un problème qui se produit si rarement?
joeqwerty

8
Que se passe-t-il lorsque vos heures de production sont 24h / 24 et 7j / 7? Le DNS doit échouer sur le deuxième / troisième / x serveur ET mettre en cache l'échec de l'autre serveur pendant une période. Le délai d'expiration de 5 secondes par défaut est suffisant pour arrêter les services en fonction de la charge.
Ryaner

0

Une solution plus centrée sur le réseau consisterait à utiliser deux serveurs DNS avec le même routage IP (et dédié) et Anycast . (Je n'ai pas encore remarqué cette réponse dans ce fil, mais c'est ce qui est utilisé ici.)

Tant que les deux sont actifs, le serveur le plus proche est utilisé. Si l'un tombe en panne, le trafic pour cette IP sera routé vers l'autre nœud jusqu'à ce qu'il revienne. Cela est particulièrement judicieux si vous avez deux emplacements ou centres de données ou plus.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.