Le DNS Round-Robin est-il "suffisant" pour l'équilibrage de charge de contenu statique ?

Je suis en retard sur ce fil, donc ma réponse va probablement planer toute seule au fond, négligée, sniff sniff.

Tout d'abord, la bonne réponse à la question n'est pas de répondre à la question, mais de dire :

1. "Vous voulez probablement que Windows Équilibrage de la charge du réseau à la place." O
2. "Soyez à la page, placez votre contenu statique sur quelque chose comme Fichiers en nuage ou S3 et qu'un CDN en fasse un miroir dans le monde entier."

NLB est mature, bien adapté à la tâche, et assez facile à mettre en place. Les solutions de cloud computing ont leurs propres avantages et inconvénients, qui sortent du cadre de cette question.

Pregunta

Le DNS round robin est-il suffisant comme solution de départ, mieux que rien, "pendant que nous recherchons et mettons en œuvre de meilleures alternatives" pour équilibrer la charge de notre contenu statique ?

Entre, disons, 2 ou 3 serveurs web statiques ? Oui, c'est mieux que rien. Les fournisseurs de DNS qui intégreront le DNS Round Robin avec contrôles de santé du serveur et supprimera temporairement les serveurs morts des enregistrements DNS. De cette façon, vous obtenez décent la répartition de la charge et un peu de haute disponibilité ; et tout cela prend moins de 5 minutes à configurer.

Mais les mises en garde formulées par d'autres dans ce fil s'appliquent :

• Les navigateurs Microsoft actuels mettent en cache les données DNS pour 30 minutes Vous pouvez donc envisager un temps de basculement de plus de 30 minutes pour un sous-ensemble de vos utilisateurs, en fonction de l'état initial de leur cache DNS.
• Qu'est-ce que le les utilisateurs voient pendant le basculement peut être ... étrange (vous n'utilisez pas l'authentification sur le contenu statique, et certainement pas l'authentification par formulaire, mais le lien montre quelque chose à surveiller).

Autres solutions

HAProxy est fantastique, mais puisque Stack Overflow est sur la pile technologique de Microsoft, peut-être que l'utilisation des outils d'équilibrage de charge et de haute disponibilité de Microsoft aura moins de frais d'administration. L'équilibrage de la charge du réseau s'occupe d'une partie du problème, et Microsoft dispose en fait d'un outil d'équilibrage de la charge. L7 Proxy inverse HTTP / équilibreur de charge maintenant.

Je n'ai jamais utilisé ARR moi-même, mais étant donné qu'il en est à sa deuxième version majeure et qu'il provient de Microsoft, je suppose qu'il a été suffisamment testé. Il a des documents faciles à comprendre Voici un exemple de la façon dont ils voient distribution de contenus statiques et dynamiques sur les webnodes, et voici un article sur comment utiliser ARR avec NLB pour obtenir à la fois une répartition de la charge et une haute disponibilité.

Il est remarquable de constater que de nombreux contributeurs contribuent à la désinformation sur le DNS Round Robin en tant que mécanisme de répartition de la charge et de résilience. Il fonctionne généralement, mais vous devez comprendre comment il fonctionne et éviter les erreurs causées par toute cette désinformation.

1) Le TTL des enregistrements DNS utilisés pour le Round robin doit être court - mais PAS ZERO. Le fait d'avoir le TTL à zéro brise le principal moyen d'assurer la résilience.

2) DNS RR répartit, mais n'équilibre pas la charge, il la répartit parce que sur une large base de clients, ils ont tendance à interroger le serveur DNS indépendamment, et se retrouvent donc avec des entrées DNS de premier choix différentes. Ces différents premiers choix signifient que les clients sont servis par différents serveurs et que la charge est répartie. Mais tout dépend de l'appareil qui effectue la requête DNS et de la durée pendant laquelle il conserve le résultat. Un exemple courant est que tous les clients derrière un proxy d'entreprise (qui effectue la requête DNS pour eux) finissent par cibler un seul serveur. La charge est répartie, mais elle n'est pas équilibrée.

3) Le DNS RR offre une résilience tant que le logiciel client l'implémente correctement (et que le TTL et la capacité d'attention des utilisateurs ne sont pas trop courts). En effet, le DNS round robin fournit une liste ordonnée d'adresses IP de serveurs, et le logiciel client doit essayer de contacter chacune d'entre elles tour à tour, jusqu'à ce qu'il trouve un serveur qui accepte la connexion.

Ainsi, si le serveur de premier choix est hors service, la connexion TCP/IP du client est interrompue et, à condition que ni le TTL ni la durée d'attention n'aient expiré, le logiciel client effectue une nouvelle tentative de connexion à la deuxième entrée de la liste, et ainsi de suite jusqu'à ce que le TTL expire, ou qu'il arrive à la fin de la liste (ou que l'utilisateur abandonne par dégoût).

Une longue liste de serveurs en panne (votre faute) et de grandes limites de tentatives de connexion TCP/IP (erreur de configuration du client) peuvent entraîner une longue période avant que le client ne trouve un serveur fonctionnel. Un TTL trop court signifie qu'il n'arrive jamais à se frayer un chemin jusqu'à la fin de la liste, mais qu'il lance une nouvelle requête DNS et reçoit une nouvelle liste (dans un ordre différent, espérons-le).

Parfois le client n'a pas de chance et la nouvelle liste commence toujours avec des serveurs cassés. Pour donner au système les meilleures chances d'assurer la résilience du client, vous devez vous assurer que le TTL est plus long que le temps d'attention typique et que le client arrive en bas de la liste.

Une fois que le client a trouvé un serveur fonctionnel, il doit s'en souvenir, et lorsqu'il doit établir la prochaine connexion, il ne doit pas répéter la recherche (sauf si le TTL a expiré). Un TTL plus long réduit la fréquence à laquelle les utilisateurs subissent un retard pendant que le client cherche un serveur opérationnel - ce qui donne une meilleure expérience.

4) Le TTL DNS entre en jeu, lorsque vous souhaitez modifier manuellement les enregistrements DNS (par exemple pour supprimer un serveur en panne depuis longtemps), un TTL court permet à ce changement de se propager rapidement (une fois que vous avez pris le temps de le faire), il faut donc trouver un équilibre entre le temps qu'il faudra avant que vous ne soyez au courant du problème et que vous fassiez ce changement manuel, et le fait que les clients normaux ne devront effectuer une nouvelle recherche d'un serveur en état de marche que lorsque le TTL aura expiré.

Le DNS round robin présente deux caractéristiques exceptionnelles qui le rendent très rentable dans un large éventail de scénarios : premièrement, il est gratuit et, deuxièmement, il est presque aussi dispersé géographiquement que votre base de clients.

Il n'introduit pas une nouvelle "unité d'échec", comme le font tous les autres systèmes "intelligents". Il n'y a pas de composants ajoutés qui pourraient subir une défaillance commune et simultanée sur toute une série d'éléments interconnectés.

Les systèmes "intelligents" sont formidables et introduisent des mécanismes merveilleux pour coordonner et fournir un équilibre transparent et un mécanisme de basculement, mais en fin de compte, les méthodes mêmes qu'ils utilisent pour fournir cette expérience transparente sont leur talon d'Achille - la chose compliquée supplémentaire qui peut mal tourner, et quand cela arrive, fournira une expérience transparente de la défaillance à l'échelle du système.

Donc OUI, le DNS round robin est définitivement "suffisant" pour votre première étape au-delà d'un serveur unique hébergeant tout votre contenu statique en un seul endroit.

Windows Vista et Windows 7 implémenter le support client pour le round robin différemment car ils ont reporté la sélection d'adresses IPv6 sur IPv4. ( RFC 3484 )

Ainsi, si vous avez un nombre important d'utilisateurs de Vista, Windows 7 et Windows 2008, vous risquez de trouver un comportement incompatible avec ce que vous aviez prévu dans votre ersatz de solution d'équilibrage de charge.

J'ai toujours utilisé le DNS Round-Robin, avec un long TTL, comme équilibreur de charge. Cela fonctionne très bien pour les services HTTP/HTTPS. avec des navigateurs .

Je suis vraiment stressé avec des navigateurs car la plupart des navigateurs mettent en œuvre une sorte de "réessai sur une autre IP", mais je ne sais pas comment les autres bibliothèques ou logiciels gèrent la solution des IP multiples.

Lorsque le navigateur n'obtient pas de réponse d'un serveur, il appelle automatiquement l'IP suivante, et s'y tient (jusqu'à ce qu'elle soit en panne... et en essaie une autre).

En 2007, j'ai effectué le test suivant :

• ajouter une iframe sur mon site web, pointant vers une entrée du Round-Robin, telle que http://roundrobin.test:10080/ping.php
• la page était servie par 3 sockets PHP, écoutant sur 3 IP différentes, toutes sur le port 10080 (je ne pouvais pas me permettre de tester sur le port 80, car mon site web fonctionnait dessus)
• une prise (disons A ) était là pour vérifier que le navigateur pouvait se connecter sur le port 10080 (car beaucoup d'entreprises n'autorisent que les ports standards)
• les deux autres prises (disons B y C ) peuvent être activés ou désactivés à la volée.

Je l'ai laissé tourner une heure, j'avais beaucoup de données. Les résultats sont les suivants : pour 99,5 % des occurrences sur la douille A j'ai eu une touche sur l'une ou l'autre des prises B o C (Je n'ai pas désactivé les deux en même temps, bien sûr). Les navigateurs étaient : iPhone, Chrome, Opera, MSIE 6/7/8, BlackBerry, Firefox 3/3.5... Donc, même les navigateurs qui ne sont pas conformes à cette norme s'en sortent bien !

À ce jour, je ne l'ai jamais testé à nouveau, mais peut-être que je mettrai en place un nouveau test un jour ou que je publierai le code sur github pour que d'autres puissent le tester.

Remarque importante : même s'il fonctionne la plupart du temps, cela n'enlève rien au fait que certaines requêtes sera échouer. Je l'utilise également pour les requêtes POST, car mon application renvoie un message d'erreur en cas d'échec, afin que l'utilisateur puisse renvoyer les données, et il est fort probable que le navigateur utilise une autre IP dans ce cas et que la sauvegarde fonctionne. Et pour le contenu statique, cela fonctionne très bien.

Donc, si vous travaillez avec des navigateurs, utilisez le DNS Round-Robin, que ce soit pour du contenu statique ou dynamique, et tout ira bien. Les serveurs peuvent également tomber en panne au milieu d'une transaction, et même avec le meilleur équilibreur de charge, vous ne pouvez pas gérer un tel cas. Pour le contenu dynamique, vous devez faire en sorte que vos sessions/bases de données/fichiers soient synchrones, sinon vous ne pourrez pas gérer cela (mais c'est également vrai avec un véritable équilibreur de charge).

Note supplémentaire : vous pouvez tester le comportement sur votre propre IP en utilisant iptables . Par exemple, avant votre règle de pare-feu pour le trafic HTTP, ajoutez :

iptables -A INPUT -p tcp --dport 80 --source 12.34.56.78 -j REJECT

(où 12.34.56.78 est évidemment votre IP)

N'utilisez pas DROP à la sortie du port filtré et votre navigateur attendra jusqu'à la fin du délai d'attente. Donc maintenant, vous pouvez activer ou désactiver un serveur ou l'autre. Le test le plus évident est de désactiver le serveur A, de charger la page, puis d'activer le serveur A et de désactiver le serveur B. Lorsque vous chargerez à nouveau la page, vous verrez une petite attente de la part du navigateur, puis elle se chargera à nouveau depuis le serveur A. Dans Chrome, vous pouvez confirmer l'IP du serveur en regardant la requête dans le panneau réseau. Dans le General onglet de Headers vous verrez un faux en-tête appelé Remote Address: . C'est l'IP d'où vous avez obtenu une réponse.

Ainsi, si vous avez besoin de passer en mode maintenance sur un serveur, il suffit de désactiver le trafic HTTP/HTTPS avec un seul bouton iptables REJECT En règle générale, toutes les demandes seront transmises aux autres serveurs (avec une petite attente, presque imperceptible pour les utilisateurs).

Je ne pense pas qu'il s'agisse d'une solution suffisante, car disons que vous avez deux serveurs et que vous utilisez le DNS à tour de rôle pour l'adresse IP de chaque serveur. Lorsqu'un serveur tombe en panne, les serveurs DNS ne savent pas qu'il est tombé en panne et continuent à servir cette adresse IP, dans le cadre du processus RR. Dans ce cas, 50 % de votre public aura un site cassé, sans javascript ni images.

Il est peut-être plus facile de pointer vers une adresse IP commune qui est gérée par Windows NLB représentant deux serveurs derrière. À moins que vous n'utilisiez un serveur Linux pour votre contenu statique, si je me souviens avoir lu cela quelque part ?