Les DNS Round-Robin sont-ils «assez bons» pour équilibrer le contenu statique du chargement?

Nous diffusons un ensemble de contenu statique partagé entre nos sites Web à l' adresse http://sstatic.net . Malheureusement, ce contenu n’a pas du tout été équilibré: il est servi à partir d’un seul serveur. Si ce serveur a des problèmes, tous les sites qui en dépendent sont effectivement hors service, car les ressources partagées sont des bibliothèques et images javascript essentielles partagées.

Nous recherchons des moyens d’équilibrer la charge du contenu statique sur ce serveur afin d’éviter la dépendance à un seul serveur.

Je réalise que le DNS à tour de rôle est, au mieux, une solution bas de gamme (certains pourraient même dire ghetto ), mais je ne peux m'empêcher de me demander - est-ce que le DNS à tour de rôle est une solution "assez bonne" pour équilibrer la charge de base d'un contenu statique ?

Il en est question dans les balises [DNS] [Équilibrage de la charge] , et j'ai lu d’excellents articles sur le sujet.

Je suis conscient des inconvénients courants de l'équilibrage de charge DNS dans plusieurs enregistrements A à tour de rôle:

• il n'y a généralement pas de battement de cœur ni de détection d'échec avec les enregistrements DNS. Ainsi, si un serveur donné de la rotation tombe en panne, son enregistrement A doit être supprimé manuellement des entrées DNS.
• la durée de vie (TTL) doit nécessairement être assez basse pour que cela fonctionne, car les entrées DNS sont mises en cache de manière agressive sur Internet.
• les ordinateurs clients sont chargés de vérifier qu’il existe plusieurs enregistrements A et de choisir le bon

Mais le tourniquet DNS est-il assez bon en tant que démarreur, mieux que rien, "alors que nous recherchons et mettons en œuvre de meilleures alternatives" comme un équilibrage de charge pour notre contenu statique? Ou est-ce que DNS round robin est quasiment nul en toutes circonstances?

Jeff, je ne suis pas d'accord, l'équilibrage de charge n'implique pas de redondance, c'est plutôt le contraire. Plus vous avez de serveurs, plus vous aurez de chances de tomber en panne à un instant donné. C'est pourquoi la redondance est obligatoire lors de l'équilibrage de la charge, mais malheureusement, il existe de nombreuses solutions qui fournissent uniquement l'équilibrage de la charge sans effectuer de contrôle de l'intégrité, ce qui entraîne un service moins fiable.

La roundrobin DNS est excellente pour augmenter la capacité, en répartissant la charge sur plusieurs points (potentiellement distribués géographiquement). Mais il ne fournit pas de basculement. Vous devez d’abord décrire le type d’échec que vous essayez de couvrir. Une panne de serveur doit être couverte localement à l'aide d'un mécanisme de prise en charge d'adresse IP standard (VRRP, CARP, ...). Une défaillance de commutateur est couverte par des liaisons résilientes du serveur vers deux commutateurs. Une défaillance de la liaison WAN peut être couverte par une configuration multi-liens entre vous et votre fournisseur, à l'aide d'un protocole de routage ou d'une solution de couche 2 (par exemple: PPP multi-liens). Une défaillance de site doit être couverte par BGP: vos adresses IP sont répliquées sur plusieurs sites et vous les annoncez au réseau uniquement là où elles sont disponibles.

D'après votre question, il semble que vous ayez uniquement besoin de fournir une solution de basculement de serveur, qui est la solution la plus simple car elle n'implique aucun matériel ni contrat avec aucun fournisseur de services Internet. Pour cela, il vous suffit d'installer le logiciel approprié sur votre serveur. C'est de loin la solution la moins chère et la plus fiable.

Vous avez demandé "et si une machine haproxy échouait?". C'est le même. Toutes les personnes que je connais qui utilisent haproxy pour l'équilibrage de charge et la haute disponibilité ont deux machines et exécutent ucarpe, keepalived ou heartbeat sur elles pour s'assurer que l'une d'elles est toujours disponible.

En espérant que cela aide!

En termes d’équilibrage de charge, c’est un ghetto mais plus ou moins efficace. Si vous avez un serveur qui est tombé de la charge et souhaitez le répartir sur plusieurs serveurs, c'est peut-être une bonne raison de le faire, du moins temporairement.

Il existe un certain nombre de critiques valables à l'égard du DNS round robin en tant qu'équilibrage de charge, et je ne recommanderais pas de le faire pour cela autrement que comme un pansement à court terme.

Mais vous dites que votre principale motivation est d'éviter une dépendance à un seul serveur. Sans un moyen automatisé de supprimer la rotation des serveurs morts, ce n'est pas très utile pour éviter les temps d'arrêt. (Avec un moyen automatisé d'extraire les serveurs de la rotation et d'un TTL court, cela devient un basculement vers un ghetto. Manuellement, ce n'est même pas ça.)

Si l'un de vos deux serveurs round robined tombe en panne, 50% de vos clients subiront un échec. Cela vaut mieux que 100% d'échec avec un seul serveur, mais presque toute autre solution qui effectue un basculement réel serait meilleure que cela.

Si la probabilité de défaillance d'un serveur est N, avec deux serveurs, votre probabilité est 2N. Sans basculement automatisé et rapide , ce schéma augmente la probabilité que certains de vos utilisateurs rencontrent des échecs.

Si vous envisagez de supprimer manuellement le serveur hors service, vous êtes limité par la vitesse d'exécution et par la durée de vie du serveur DNS. Que faire si le serveur meurt à 4 heures du matin? La meilleure partie du vrai basculement est de dormir toute la nuit. Vous utilisez déjà HAProxy , vous devez donc vous en familiariser. Je suggère fortement de l’utiliser, HAProxy étant conçu exactement pour cette situation.

Le DNS à la ronde n'est pas ce que les gens pensent. En tant qu'auteur du logiciel serveur DNS (à savoir, BIND ), nous avons des utilisateurs qui se demandent pourquoi leur round robin cesse de fonctionner comme prévu. Ils ne comprennent pas que même avec un TTL de 0 secondes, il y aura une certaine quantité de cache, car certains caches mettent un temps minimum (souvent entre 30 et 300 secondes).

En outre, bien que vos serveurs AUTH puissent effectuer le round robin, rien ne garantit que ceux qui vous intéressent - les caches dont parlent vos utilisateurs - le feront. En bref, round robin ne garantit aucune commande du point de vue du client, mais seulement ce que vos serveurs d'authentification fournissent à un cache.

Si vous voulez un vrai basculement, le DNS n’est qu’une étape. Ce n’est pas une mauvaise idée de répertorier plus d’une adresse IP pour deux clusters différents, mais j’utiliserais une autre technologie (par exemple, un simple anycast) pour effectuer l’équilibrage de la charge. Personnellement, je méprise le matériel d’équilibrage de charge matérielle qui gâche le DNS car il se trompe généralement. Et n'oubliez pas que DNSSEC arrive, alors si vous choisissez quelque chose dans cette zone, demandez à votre fournisseur ce qui se passe lorsque vous signez votre zone.

Je l'ai déjà dit plusieurs fois, et je le répète: si la résilience est le problème, les astuces DNS ne sont pas la solution .

Les meilleurs systèmes de haute disponibilité permettront à vos clients de continuer à utiliser exactement la même adresse IP pour chaque demande. C’est le seul moyen de s’assurer que les clients ne remarquent même pas l’échec.

La règle fondamentale est donc que la véritable résilience nécessite des ruses au niveau du routage IP . Utilisez un dispositif d'équilibrage de charge, ou OSPF "multisite à coûts égaux", ou même VRRP.

Le DNS, d’autre part, est une technologie d’ adressage . Il existe uniquement pour mapper d'un espace de noms à un autre. Il n'a pas été conçu pour permettre des modifications dynamiques à très court terme de cette cartographie. Par conséquent, lorsque vous essayez d'effectuer de telles modifications, de nombreux clients ne les remarquent pas ou, au mieux, mettent longtemps à les remarquer.

Je dirais également que, puisque la charge ne vous pose aucun problème, vous pouvez également disposer d’un autre serveur prêt à fonctionner en mode de secours immédiat. Si vous utilisez dumb round-robin, vous devez modifier de manière proactive vos enregistrements DNS en cas de problème. Vous pouvez donc également activer de manière proactive le serveur de secours immédiat et ne pas modifier votre DNS.

J'ai lu toutes les réponses et une chose que je n'ai pas vue, c'est que la plupart des navigateurs Web modernes essaient l'une des adresses IP alternatives si un serveur ne répond pas. Si je me souviens bien, Chrome essaiera même plusieurs adresses IP et poursuivra avec le serveur qui répond en premier. Donc, à mon avis, DNS Round Robin L'équilibrage de la charge est toujours meilleur que rien.

BTW: Je vois DNS Round Robin plus comme une simple solution de distribution de charge.

Je suis en retard sur ce fil, donc ma réponse sera probablement planer au sol, tout en bas, négligée, renifler.

Tout d’abord, la bonne réponse à la question ne consiste pas à répondre à la question, mais à dire:

1. "Vous voulez probablement l' équilibrage de la charge réseau Windows à la place." OU
2. "Suivez l'évolution du temps, placez votre contenu statique sur quelque chose comme Cloud Files ou S3 et faites-le reproduire dans le monde entier par un CDN."

NLB est mature, bien adapté à la tâche et assez facile à configurer. Les solutions en nuage ont leurs propres avantages et inconvénients, ce qui dépasse le cadre de cette question.

Question

Le Round Robin DNS est-il assez bon en tant que démarreur, mieux que rien, "alors que nous recherchons et mettons en œuvre de meilleures alternatives" comme un équilibrage de charge pour notre contenu statique?

Entre, disons, 2 ou 3 serveurs Web statiques? Oui, c'est mieux que rien, car certains fournisseurs DNS intégreront DNS Round Robin aux vérifications de l'état du serveur et supprimeront temporairement les serveurs hors service des enregistrements DNS. Ainsi, vous obtenez ainsi une répartition de charge décente et une disponibilité élevée. et tout cela prend moins de 5 minutes à mettre en place.

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

• Les navigateurs Microsoft actuels mettent en cache les données DNS pendant 30 minutes . Par conséquent, vous disposez de plus de 30 minutes de basculement pour un sous-ensemble de vos utilisateurs, en fonction de l'état initial du cache DNS.
• Ce que les utilisateurs voient pendant le basculement peut être ... étrange (vous n'utilisez pas d'authentification sur du contenu statique, et certainement pas d'authentification de forme, mais le lien indique un élément à surveiller).

Autres solutions

HAProxy est fantastique, mais comme Stack Overflow se trouve sur la pile technologique de Microsoft, l'utilisation des outils d'équilibrage de la charge et de haute disponibilité de Microsoft peut entraîner moins de frais administratifs. L'équilibrage de la charge réseau prend en charge une partie du problème et Microsoft dispose actuellement d'un équilibreur proxy inverse / charge L7 HTTP .

Je n'ai jamais utilisé ARR moi-même, mais étant donné qu'il en est à sa deuxième version majeure et provenant de Microsoft, je suppose qu'il a été suffisamment testé. Les documents sont faciles à comprendre . En voici un qui explique comment ils perçoivent la distribution de contenu statique et dynamique sur des nœuds Web et un article sur l’utilisation de ARR avec NLB pour obtenir à la fois une répartition de la charge et une haute disponibilité.

Il est remarquable de constater combien de contributeurs contribuent à la diss-information sur DNS Round Robin en tant que mécanisme de répartition de la charge et de résilience. Cela fonctionne habituellement, mais vous devez comprendre comment cela fonctionne et éviter les erreurs causées par toute cette désinformation.

1) La durée de vie des enregistrements DNS utilisée pour Round Robin doit être courte, mais PAS ZÉRO. Avoir la durée de vie (TTL) à zéro interrompt le principal moyen d'assurer la résilience.

2) Le DNS RR se propage, mais n'équilibre pas la charge, il la répartit car, sur une base de clients importante, ils ont tendance à interroger le serveur DNS indépendamment, et se retrouvent donc avec des entrées DNS de premier choix différentes. Ces premiers choix différents signifient que les clients sont desservis par différents serveurs et que la charge est répartie. Mais tout dépend du périphérique 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) finiront tous par cibler un seul serveur. La charge est répartie - mais elle n'est pas équilibrée uniformément.

3) DNS RR offre la résilience tant que le logiciel client le met en œuvre correctement (et que la durée de vie et la durée d'attention des utilisateurs ne sont pas trop courtes). En effet, DNS round robin fournit une liste ordonnée d'adresses IP de serveur et le logiciel client doit essayer de contacter chacune d'elles à son tour, jusqu'à ce qu'il trouve un serveur acceptant la connexion.

Par conséquent, si le serveur de premier choix est hors service, la connexion TCP / IP du client expire. Si le délai de latence ou l'attention n'est pas écoulé, le logiciel client effectue une nouvelle tentative de connexion à la deuxième entrée de la liste - et ainsi de suite. TTL expire ou arrive à la fin de la liste (ou l'utilisateur abandonne avec dégoût).

Une longue liste de serveurs cassés (votre faute) et de grandes limites de tentatives de connexion TCP / IP (configuration incorrecte du client) peuvent durer longtemps avant que le client ne trouve réellement un serveur en fonctionnement. Un TTL trop court signifie qu'il ne parvient jamais à se retrouver à la fin de la liste. Il émet plutôt 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 par des serveurs défectueux. Pour donner au système les meilleures chances d'assurer la résilience du client, vous devez vous assurer que la durée de vie est plus longue que la durée d'attention habituelle et que le client parvienne au bas de la liste.

Une fois que le client a trouvé un serveur en fonctionnement, il doit s'en souvenir et s'il ne doit pas établir la connexion suivante, il ne doit pas répéter la recherche (à moins que la durée de vie ait expiré). Une durée de vie plus longue réduit la fréquence à laquelle les utilisateurs subissent un retard pendant que le client recherche un serveur en fonctionnement, ce qui améliore l'expérience.

4) DNS TTL prend tout son sens lorsque vous souhaitez modifier manuellement les enregistrements DNS (par exemple, pour supprimer un serveur endommagé à long terme), puis une courte durée de vie permet à ce changement de se propager rapidement (une fois que vous êtes sur le point de le faire), Considérez le temps qu'il faut entre le temps nécessaire pour connaître le problème et apportez des modifications manuelles - et le fait que les clients normaux ne devront effectuer une nouvelle recherche de serveur opérationnel que lorsque le délai de validité sera écoulé.

DNS round robin présente deux fonctionnalités 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 clientèle.

Il n'introduit pas une nouvelle "unité de défaillance" comme tous les autres systèmes "intelligents". Il n'y a pas de composants ajoutés susceptibles de connaître une défaillance commune et simultanée de tout un ensemble d'éléments liés.

Les systèmes "intelligents" sont excellents et introduisent de merveilleux mécanismes pour coordonner et assurer un mécanisme homogène d'équilibre et de basculement, mais les méthodes mêmes qu'ils utilisent pour offrir cette expérience homogène sont leur talon d'Achille - la chose compliquée supplémentaire qui peut mal tourner, et quand cela se produira, vous obtiendrez une expérience transparente des défaillances à l'échelle du système.

Donc, OUI, le round robin DNS est certainement "assez bon" pour votre première étape au-delà d’un serveur hébergeant tout votre contenu statique au même endroit.

Windows Vista et Windows 7 implémentent différemment la prise en charge des clients pour la répétition alternée puisqu'ils rétroportent la sélection d'adresses IPv6 sur IPv4. ( RFC 3484 )

Par conséquent, si vous avez un nombre important d'utilisateurs de Vista, Windows 7 et Windows 2008, vous constaterez probablement un comportement incohérent par rapport à votre idée prévisionnelle dans votre solution d'équilibrage de charge ersatz.

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

Je suis vraiment stressé par les navigateurs, car la plupart des navigateurs implémentent une sorte de «nouvelle tentative sur une autre IP», mais je ne sais pas comment d’autres bibliothèques ou logiciels géreraient la solution à plusieurs adresses IP.

Lorsque le navigateur ne reçoit pas de réponse d'un serveur, il appelle automatiquement la prochaine adresse IP, puis s'en tient à celle-ci (jusqu'à ce qu'elle soit hors service ... et en tente une autre).

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

• ajouter un iframe sur mon site Web, en pointant vers une entrée Round-Robin, telle que http://roundrobin.test:10080/ping.php
• la page a été servie par 3 sockets PHP, écoutant sur 3 adresses 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 (de nombreuses entreprises n'autorisant que des ports standard)
• deux autres sockets (disons B et C ) pourraient être activés ou désactivés à la volée.

Je l'ai laissé fonctionner une heure, j'avais beaucoup de données. Les résultats sont que pour 99,5% des hits sur le socket A , j'ai eu un hit sur le socket B ou C (je n'ai pas désactivé les deux en même temps, bien sûr). Les navigateurs étaient les suivants: iPhone, Chrome, Opera, MSIE 6/7/8, BlackBerry, Firefox 3 / 3.5 ... Ainsi, même les navigateurs non conformes se comportaient correctement!

À ce jour, je ne l'ai plus jamais testé, mais peut-être que je configurerai un nouveau test un jour ou que je publierai le code sur github afin que d'autres puissent le tester.

Remarque importante: même si cela fonctionne la plupart du temps, cela ne supprime pas le fait que certaines demandes vont échouer. Je l'utilise également pour les demandes POST, car mon application renvoie un message d'erreur au cas où cela ne fonctionnerait pas, afin que l'utilisateur puisse envoyer les données à nouveau, et le navigateur utilisera probablement une autre adresse IP dans ce cas et la sauvegarde fonctionnera. . Et pour le contenu statique, cela fonctionne vraiment bien.

Donc, si vous travaillez avec des navigateurs, utilisez Round-Robin DNS, que ce soit pour du contenu statique ou dynamique, tout ira bien. Les serveurs peuvent également tomber en cours de 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 rendre vos sessions / bases de données / fichiers synchrones, sinon vous ne pourrez pas gérer cela (mais c'est également vrai avec un véritable équilibreur de charge).

Remarque supplémentaire: vous pouvez tester le comportement sur votre propre adresse IP à l'aide de 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.78est évidemment votre adresse IP)

Ne l'utilisez pas DROP, car le port est filtré , et votre navigateur attendra jusqu'à l'expiration du délai. Alors maintenant, vous pouvez activer ou désactiver l’un ou l’autre des serveurs. 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 rechargerez la page, le navigateur affichera une petite attente, puis le serveur se chargera. Encore. Dans Chrome, vous pouvez confirmer l'adresse IP du serveur en consultant la demande dans le panneau de réseau. Dans l' Generalonglet de Headers, vous verrez un faux en-tête nommé Remote Address:. Ceci est l'adresse IP d'où vous avez obtenu une réponse.

Donc, si vous devez passer en mode de maintenance sur un serveur, désactivez simplement le trafic HTTP / HTTPS avec une iptables REJECTrègle, toutes les demandes iront sur d'autres serveurs (avec une petite attente, presque imperceptible pour les utilisateurs).

Je ne pense pas que ce soit une bonne solution car disons que vous avez maintenant deux serveurs et que vous arrondissez robin en utilisant DNS 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 continueront à servir cette adresse IP dans le cadre du processus RR. Ensuite, 50% de votre auditoire aura un site endommagé qui manque de javascript ou d'images.

Peut-être est-il plus facile de désigner une adresse IP commune gérée par Windows NLB représentant deux serveurs situés en arrière. Sauf si vous utilisez un serveur Linux pour votre contenu statique, si je me souviens de l'avoir lu quelque part?

L'équilibrage de charge alternatif ne fonctionne que lorsque vous maîtrisez également la zone DNS. Vous pouvez ainsi modifier la liste des serveurs et la transmettre aux maîtres de zone en temps voulu.

Comme mentionné dans l'une des autres réponses, le mal caché de round-robin est la mise en cache DNS, qui peut se produire n'importe où entre vos serveurs et le client, ce qui annule complètement le petit avantage de cette solution. Même lorsque DNS TTL est défini sur une valeur très faible, vous avez peu de contrôle sur la durée pendant laquelle le cache DNS du fournisseur d'accès ou même du client gardera l'adresse IP maintenant morte active.

C'est certes une amélioration par rapport à un SPOF, mais seulement marginale. Je voudrais regarder qui a déjà hébergé votre serveur et voir ce qu'il a à offrir, beaucoup ont une sorte de service d'équilibrage de charge de base qu'ils peuvent fournir.

Vous pouvez également disposer d’un seul serveur avec le contenu statique dupliqué dans S3 et basculer vers le CNAME S3 lorsque votre serveur principal est arrêté. Vous vous retrouverez avec le même retard, mais sans le coût pour plusieurs serveurs.

Cela dépend vraiment de ce dont vous parlez et du nombre de serveurs en rotation. Un jour, j'avais un site qui fonctionnait sur plusieurs serveurs, et j'ai utilisé le Round Robin DNS à cause de mon novice à l'époque, et ce n'était pas un gros problème. Ce n'était pas un gros problème car il ne s'est pas écrasé. C'était un système vraiment stupide et non compliqué, donc il a tenu le coup, et avait un niveau de trafic assez constant. Si la circulation s’écrasait, c’était pendant la journée et c’était quelque chose que je pouvais facilement régler. Je dirais que votre contenu statique est qualifié de suffisamment simple pour ne pas causer de crash à lui seul.

En dehors des pannes matérielles, etc., dans quelle mesure votre serveur est-il stable? À quel point votre trafic sur ce contenu est-il «en épi»? En supposant un Apache direct ou quelque chose de similaire et un trafic relativement plat, cela ne va pas beaucoup crasher, et je dirais que le round robin est "assez bon".

Je suis sûr que je serai voté parce que je ne prêche pas une solution 100% HA, mais ce n'est pas ce que vous avez demandé. Cela dépend de ce que vous êtes prêt à accepter comme solution par rapport aux efforts déployés.

Si vous utilisiez le DNS RR pour équilibrer la charge, tout irait bien, mais vous ne l'êtes pas. Vous l'utilisez pour activer un serveur redondant, auquel cas ce n'est pas bien.

Comme un article précédent l'a dit, vous avez besoin de quelque chose pour détecter le battement de coeur et arrêter de le frapper jusqu'à ce qu'il revienne.

La bonne nouvelle est que le rythme cardiaque est disponible à très bas prix, que ce soit dans les commutateurs ou dans Windows.

Je ne sais pas pour les autres systèmes d'exploitation, mais je suppose que c'est là aussi.

Je vous suggère d'attribuer une adresse IP supplémentaire à chacun de vos serveurs (en plus de l'adresse IP statique que vous utilisez, par exemple, ssh), et de l'intégrer au pool DNS. Et vous utilisez ensuite un logiciel pour commuter autour de ces adresses IP en cas de défaillance d'un serveur. Heartpeat ou CARP peuvent le faire, par exemple, mais il existe d'autres solutions.

Cela présente l'avantage que, pour les clients de votre service, rien ne doit changer dans la configuration et vous n'avez pas à vous soucier de la mise en cache DNS ou de la durée de vie, mais vous pouvez toujours tirer parti de l'équilibrage de la charge DNS "équilibrage de charge". .

Cela fera probablement l'affaire, surtout si vous pouvez avoir plusieurs adresses IP sur vos boîtes statiques. avoir un IP "servir du contenu statique" et un "IP gérer la machine". Si une boîte tombe ensuite en panne, vous pouvez utiliser une solution haute disponibilité existante ou une intervention manuelle pour amener l'IP de la machine défaillante sur l'un des autres "membres du cluster" ou sur une toute nouvelle machine (en fonction de sa rapidité). pour que cela soit opérationnel).

Cependant, une telle solution posera quelques problèmes mineurs. L'équilibrage de la charge sera loin d'être parfait et si vous comptez sur une intervention manuelle, il est possible que certains visiteurs subissent des pannes.

Un équilibreur de charge matérielle peut probablement faire un meilleur travail en partageant la charge et en fournissant le "temps de disponibilité du cluster" que ne le fera le round-robin DNS. De l’autre côté, c’est un (ou deux, car idéalement, vous avez les LB dans un cluster HA), il vous faudra acheter, mettre sous tension et refroidir et (éventuellement) avoir un peu de temps pour vous familiariser (si vous ne le faites pas déjà). avoir des équilibreurs de charge dédiés).

Pour répondre de façon succincte la question (est ronde DNS assez bon en entrée, mieux que rien « alors que nous effectuons des recherches et mettre en œuvre de meilleures alternatives » forme équilibrage de charge pour notre contenu statique?), Je dirais que c'est mieux que rien, mais vous devriez certainement continuer à rechercher d'autres formes d'équilibrage de charge.

Lors de mes recherches sur l'équilibrage de charge Windows il y a plusieurs années, j'ai vu un document indiquant que la batterie de serveurs Web de Microsoft était configurée en tant que groupes d'équilibrage de charge multiples, avec une répétition alternée DNS. Étant donné que plusieurs serveurs DNS peuvent répondre dans chaque espace-noms et que l'équilibrage de la charge de Microsoft est à réparation automatique, cela fournit à la fois la redondance et l'équilibrage de la charge.

Inconvénient: vous avez besoin d'au moins 4 serveurs (2 serveurs x 2 groupes).

Répondant au commentaire de Jeff sur la réponse de Schof, existe-t-il un moyen de procéder à un va-et-vient DNS entre serveurs HAProxy?

Son utilisation est très marginale, suffisante pour vous permettre de mettre en place une solution réelle. Comme vous le dites, la durée de vie doit être assez basse. Cela a cependant l'avantage de retirer une machine problématique du DNS alors qu'elle a des problèmes. Supposons que SvrA, SvrB et SvrC distribuent votre contenu et que SvrA tombe en panne. Vous le sortez du DNS et après la courte période définie par votre faible durée de vie, les résolveurs détermineront un serveur différent (SvrB ou SvrC) actif. Vous récupérez SvrA en ligne et le remettez dans DNS. Un temps d'arrêt court pour certaines personnes, pas pour d'autres. Pas génial, mais réalisable. Plus vous mélangez de serveurs statiques, moins vous risquez d’avoir des groupes majoritaires d’utilisateurs en panne.

Vous n'obtiendrez certainement pas la véritable répartition équilibrée qu'une solution d'équilibrage de la charge fournira en raison de la topologie d'Internet. Je regardais toujours la charge sur tous les serveurs impliqués.