Le DNS Round-Robin est-il "assez bon" pour équilibrer la charge du contenu statique?
Nous avons un ensemble de contenu statique partagé que nous servons entre nos sites Web à http://sstatic.net . Malheureusement, ce contenu n'est actuellement pas du tout équilibré en charge - il est servi à partir d'un seul serveur. Si ce serveur a des problèmes, tous les sites qui en dépendent sont effectivement en panne car les ressources partagées sont des bibliothèques et des images javascript partagées essentielles.
Nous cherchons des moyens d'équilibrer la charge du contenu statique sur ce serveur, afin d'éviter la dépendance à un seul serveur.
Je me rends compte 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 - Le DNS à tour de rôle est-il une solution "assez bonne" pour l'équilibrage de charge de base du contenu statique?
Il y a une discussion à ce sujet dans les balises [dns] [load-balancing] , et j'ai lu quelques excellents articles sur le sujet.
Je connais les inconvénients courants de l'équilibrage de la charge DNS via plusieurs enregistrements à tour de rôle A:
- il n'y a généralement pas de pulsations ou de détection d'échec avec les enregistrements DNS, donc si un serveur donné dans la rotation tombe en panne, son enregistrement A doit être supprimé manuellement des entrées DNS
- le temps de vivre (TTL) doit nécessairement être réglé assez bas 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 voir qu'il existe plusieurs enregistrements A et de sélectionner le bon
Mais, le DNS à tour de rôle est-il assez bon en tant que démarreur, mieux que rien, "alors que nous recherchons et mettons en œuvre de meilleures alternatives" sous forme d'équilibrage de charge pour notre contenu statique? Ou le round robin DNS est-il pratiquement sans valeur dans les circonstances n'importe lesquelles?
Jeff, je ne suis pas d'accord, l'équilibrage de charge n'implique pas de redondance, c'est tout le contraire en fait. Plus vous avez de serveurs, plus vous risquez d'avoir une panne à un instant donné. C'est pourquoi la redondance IS obligatoire lors de l'équilibrage de charge, mais malheureusement, il existe de nombreuses solutions qui ne fournissent que l'équilibrage de charge sans effectuer de contrôle d'intégrité, ce qui entraîne un service moins fiable.
DNS roundrobin est excellent pour augmenter la capacité, en répartissant la charge sur plusieurs points (potentiellement géographiquement distribuée). 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 reprise d'adresse IP standard (VRRP, CARP, ...). Une défaillance de commutateur est couverte par des liens résilients sur le serveur vers deux commutateurs. A WAN peut être couverte par une configuration de liaisons multiples entre vous et votre fournisseur, en utilisant soit un protocole de routage soit une solution de couche 2 (par exemple: PPP multi-liens). Une défaillance de site doit être couvert par BGP: vos adresses IP sont répliquées sur plusieurs sites et vous ne les annoncez sur le net que là où elles sont disponibles.
D'après votre question, il semble que vous ayez seulement 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 un FAI. Il vous suffit de configurer le logiciel approprié sur votre serveur pour cela, et c'est de loin la solution la moins chère et la plus fiable.
Vous avez demandé "et si une machine haproxy tombe en panne?". 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 ucarp, keepalived ou heartbeat sur elles pour s'assurer que l'une d'entre elles est toujours disponible.
En espérant que cela aide!
En tant qu'équilibrage de charge, c'est ghetto mais plus ou moins efficace. Si vous aviez un serveur qui tombait de la charge et que vous vouliez le répartir sur plusieurs serveurs, cela pourrait être une bonne raison de le faire, au moins temporairement.
Il y a un certain nombre de critiques valables du DNS à tour de rôle comme "équilibrage de charge", et je ne recommanderais pas de le faire à part cela 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 retirer les serveurs morts de la rotation, ce n'est pas très utile pour éviter les temps d'arrêt. (Avec un moyen automatisé de retirer les serveurs de la rotation et un court TTL, cela devient un basculement du ghetto. Manuellement, ce n'est même pas ça.)
Si l'un de vos deux serveurs round-robined tombe en panne, alors 50% de vos clients obtiendront un échec. C'est mieux qu'un échec à 100% avec un seul serveur, mais presque toute autre solution qui a fait un véritable basculement serait meilleure que cela.
Si la probabilité de défaillance d'un serveur est N, avec deux serveurs votre probabilité est 2N. Sans basculement automatique rapide , ce schéma augmente la probabilité que certains vos utilisateurs connaîtront un échec.
Si vous prévoyez de retirer manuellement le serveur mort de sa rotation, vous êtes limité par la vitesse à laquelle vous pouvez le faire et le DNS TTL. Et 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 familiariser avec il. Je suggère fortement de l'utiliser, car HAProxy est conçu exactement pour cette situation.
Le DNS à tour de rôle n'est pas ce que les gens pensent qu'il est. En tant qu'auteur du logiciel serveur DNS (à savoir, BIND ), nous obtenons 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 seconde, il y aura une certaine quantité de cache là-bas, car certains caches mettent un temps minimum (souvent 30-300 secondes) quoi qu'il arrive.
De plus, bien que vos serveurs AUTH puissent effectuer un round robin, il n'y a aucune garantie que ceux qui vous intéressent - les caches auxquels vos utilisateurs parlent - le feront. En bref, le tournoi à la ronde ne garantit aucune commande du point de vue du client, seulement ce que vos serveurs d'authentification fournissent à un cache.
Si vous voulez un véritable basculement, 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 d'autres technologies (comme la simple anycast) pour effectuer l'équilibrage de charge réel. Personnellement, je méprise le matériel d'équilibrage de la charge matérielle qui détruit le DNS car il se trompe généralement. Et n'oubliez pas que DNSSEC arrive, donc si vous choisissez quelque chose dans ce domaine, demandez à votre fournisseur ce qui se passe lorsque vous signez votre zone.
Je l'ai déjà dit plusieurs fois auparavant, et je le répète - si la résilience est le problème, les astuces DNS sont pas la réponse .
Les meilleurs systèmes HA permettront à vos clients de continuer à utiliser la même adresse IP exacte pour chaque demande. C'est la seule façon 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 une supercherie de niveau de routage IP . Utilisez un dispositif d'équilibrage de charge, ou "multi-chemin à coût égal" OSPF, 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 changements dynamiques à court terme à ce mappage, et donc lorsque vous essayez d'apporter de tels changements, de nombreux clients ne les remarqueront pas, ou, au mieux, mettra beaucoup de temps à les remarquer.
Je dirais également que puisque la charge n'est pas un problème pour vous, vous pourriez tout aussi bien avoir un autre serveur prêt à fonctionner en tant que redondance d'UC. Si vous utilisez un round-robin stupide, vous devez modifier proactivement vos enregistrements DNS lorsque quelque chose se casse, vous pouvez donc tout aussi bien basculer le serveur de secours en action de manière proactive et pas changez votre DNS.
J'ai lu toutes les réponses et une chose que je n'ai pas vue est que la plupart des navigateurs Web modernes essaieront l'une des adresses IP alternatives si un serveur ne répond pas. Si je me souviens bien, alors Chrome va même essayer plusieurs adresses IP et continuer avec le serveur qui répond en premier. Donc, à mon avis, l'équilibrage de la charge DNS Round Robin est toujours mieux que rien.
BTW: Je vois DNS Round Robin plus comme une solution de distribution de charge simple.
Je suis en retard sur ce fil, donc ma réponse sera probablement juste planer seule au fond, négligée, renifler renifler.
Tout d'abord, la bonne réponse à la question n'est pas de répondre à la question, mais de dire:
- "Vous voulez probablement Windows équilibrage de la charge résea à la place." [~ # ~] ou [~ # ~]
- "Accompagnez le temps, placez votre contenu statique sur quelque chose comme Cloud Files ou S , et ayez un CDN en miroir dans le monde entier."
NLB est mature, bien adapté à la tâche et assez facile à installer. Les solutions cloud ont leurs propres avantages et inconvénients, qui n'entrent pas dans le cadre de cette question.
Question
le DNS à tour de rôle est-il assez bon en tant que démarreur, mieux que rien, "alors que nous recherchons et mettons en œuvre de meilleures alternatives" sous forme d'équilibrage de charge pour notre contenu statique?
Entre, disons, 2 ou 3 serveurs Web statiques? Oui, c'est mieux que rien, car il y a fournisseurs DNS qui intégreront DNS Round Robin avec contrôles de santé du serveur, et supprimera temporairement les serveurs morts des enregistrements DNS. Ainsi, vous obtenez décent répartition de la charge et certains haute disponibilité; et cela prend moins de 5 minutes à installer.
Mais les mises en garde décrites par d'autres dans ce fil s'appliquent:
- Les navigateurs Microsoft actuels mettent en cache les données DNS pendant minutes , vous regardez donc plus de 30 minutes de basculement pour un sous-ensemble de vos utilisateurs, en fonction de leur état de cache DNS initial.
- Ce que les utilisateurs voient pendant le basculement peut être ... étrange (vous n'utilisez pas l'auth sur du contenu statique, et certainement pas sous forme d'auth, mais le lien montre quelque chose à surveiller).
Autres solutions
HAProxy est fantastique, mais comme Stack Overflow se trouve sur la pile de la technologie Microsoft, l'utilisation des outils d'équilibrage de charge et de haute disponibilité de Microsoft entraînera peut-être moins de frais d'administration. L'équilibrage de la charge réseau s'occupe d'une partie du problème, et Microsoft dispose en fait d'un proxy inverse L7 HTTP/équilibreur de charge maintenant.
Je n'ai jamais utilisé ARR moi-même, mais étant donné que c'est sur sa deuxième version majeure, et venant de Microsoft, je suppose qu'il a été assez bien testé. Il a documents faciles à comprendre , en voici un sur la façon dont ils voient distribution de contenu statique et dynamique sur les nœuds Web, et voici un article sur la façon d'utiliser ARR avec NLB pour obtenir à la fois une répartition de la charge et une haute disponibilité.
Il est remarquable de voir combien de contributeurs contribuent à la divulgation d'informations sur DNS Round Robin en tant que mécanisme de répartition de la charge et de résilience. Cela fonctionne généralement, mais vous devez comprendre comment cela fonctionne et éviter les erreurs causées par toute cette désinformation.
1) Le TTL sur les enregistrements DNS utilisés pour le Round robin doit être court - mais PAS ZÉRO. Avoir le TTL à zéro rompt la manière principale de fournir la résilience) .
2) DNS RR se propage, mais n'équilibre pas la charge, il la répartit car sur une large base de clients, ils ont tendance à interroger le serveur DNS indépendamment, et se retrouvent donc avec différentes entrées DNS de premier choix. Ces différents premiers choix signifient que les clients sont desservis 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 le résultat est conservé. Un exemple courant est que tous les clients derrière un proxy d'entreprise (qui exécute 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 de la résilience tant que le logiciel client l'implémente correctement (et que le TTL et la durée d'attention des utilisateurs ne sont pas trop courts). En effet, le round robin DNS fournit un ordre liste des adresses IP du serveur, et le logiciel client doit essayer de contacter chacune d'elles à tour de rôle, jusqu'à ce qu'il trouve un serveur qui accepte la connexion.
Donc, si le serveur de premier choix est en panne, la connexion TCP/IP du client expire et à condition que ni le TTL ou la durée d'attention ne soit expiré, le logiciel client effectue une autre tentative de connexion à la deuxième entrée dans 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 avec dégoût).
Une longue liste de serveurs cassés (votre faute) et de grandes limites de nouvelles tentatives de connexion TCP/IP (configuration incorrecte du client) peuvent durer longtemps avant que le client ne trouve réellement un serveur fonctionnel. Un trop court TTL signifie qu'il ne parvient jamais à se frayer un chemin jusqu'à la fin de la liste, et émet à la place une nouvelle requête DNS et obtient une nouvelle liste (espérons-le dans un ordre différent).
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 de fournir la résilience du client, vous devez vous assurer que le TTL est plus long que la durée d'attention typique et pour 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 connexion suivante, il ne doit pas répéter la recherche (sauf si le TTL a expiré). Un plus long TTL réduit la fréquence à laquelle les utilisateurs subissent un retard pendant que le client recherche un serveur qui fonctionne - offrant une meilleure expérience.
4) DNS TTL prend tout son sens, lorsque vous souhaitez modifier manuellement les enregistrements DNS (par exemple pour supprimer un serveur cassé à long terme) puis un court TTL permet à ce changement de se propager rapidement (une fois que vous avez fini de le faire), alors considérez l'équilibre entre le temps qu'il faudra avant de connaître le problème et effectuez ce changement manuel - et le fait que les clients normaux n'auront qu'à effectuez une nouvelle recherche d'un serveur qui fonctionne lorsque le TTL expire.
Le round robin DNS possède deux fonctionnalités exceptionnelles qui le rendent très rentable dans un large éventail de scénarios - d'une part, il est gratuit et, d'autre part, il est presque aussi dispersé géographiquement que votre clientèle.
Il n'introduit pas une nouvelle "unité de défaillance" que tous les autres systèmes "intelligents" font. Il n'y a pas de composants ajoutés qui pourraient rencontrer une défaillance commune et simultanée sur une charge entière d'éléments interconnectés.
Les systèmes `` intelligents '' sont excellents et introduisent de merveilleux mécanismes pour coordonner et fournir un mécanisme d'équilibrage et de basculement transparent, 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 il le fera, fournira une expérience transparente de l'échec du système à l'échelle.
Alors OUI, le round robin DNS est certainement "assez bon" pour votre première étape au-delà d'un seul serveur hébergeant tout votre contenu statique en un seul endroit.
Windows Vista et Windows 7 implémentez le support client pour le round robin différemment car ils ont rétroporté la sélection d'adresse IPv6 vers IPv4. ( RFC 3484 )
Donc, si vous avez un nombre important d'utilisateurs de Vista, Windows 7 et Windows 2008, vous allez probablement trouver un comportement incompatible avec votre réflexion planifiée dans votre solution d'équilibrage de charge ersatz.
J'ai toujours utilisé Round-Robin DNS, avec un TTL long, comme équilibreur de charge. Cela fonctionne très bien pour les services HTTP/HTTPS avec les navigateurs.
Je souligne vraiment avec les navigateurs car la plupart des navigateurs implémentent une sorte de "réessayer sur une autre IP", mais je ne le fais pas savoir comment d'autres bibliothèques ou logiciels géreraient la solution IP multiple.
Lorsque le navigateur n'obtient pas de réponse d'un serveur, il appellera automatiquement la prochaine adresse IP, puis restera fidèle (jusqu'à ce qu'il soit en panne ... puis essaie un autre).
En 2007, j'ai fait le test suivant:
- ajouter un iframe sur mon site Web, pointant vers une entrée Round-Robin, comme
http://roundrobin.test:10080/ping.php - la page était desservie par 3 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 fonctionnait dessus))
- un socket (disons [~ # ~] un [~ # ~] ) était là pour vérifier que le navigateur pouvait se connecter sur le port 10080 (autant les entreprises n'autorisent que les ports standard)
- deux autres prises (disons [~ # ~] b [~ # ~] et [~ # ~] c [~ # ~] ) pourrait être activé ou désactivé à la volée.
Je l'ai laissé fonctionner une heure, j'avais beaucoup de données. Les résultats ont été que pour 99,5% des hits sur socket [~ # ~] a [~ # ~] , j'ai eu un hit sur chaque socket [~ # ~] b [~ # ~] ou [~ # ~] 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 non conformes le géraient bien!
À ce jour, je ne l'ai jamais testé à nouveau, mais je vais peut-être configurer un nouveau test un jour ou publier le code sur github pour 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 requêtes échouent échouent. Je l'utilise pour les requêtes POST aussi, car mon application renverra un message d'erreur au cas où cela ne fonctionnerait pas, afin que l'utilisateur puisse envoyer à nouveau les données, et très probablement le navigateur utilisera une autre adresse IP dans ce cas et l'enregistrement fonctionnera. Et pour le contenu statique, cela fonctionne vraiment bien.
Donc, si vous travaillez avec des navigateurs, utilisez le DNS Round-Robin, que ce soit pour du contenu statique ou dynamique, tout ira bien. Les serveurs peuvent également descendre 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 rendre vos sessions/base 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).
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, car il laisse le port filtré , et votre navigateur attendra le timeout. Alors 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 rechargerez la page, vous verrez un peu d'attente du navigateur, puis elle se chargera du serveur Encore une fois. Dans Chrome, vous pouvez confirmer l'adresse IP du serveur en consultant la demande dans le panneau réseau. Dans l'onglet General de Headers, vous verrez un faux en-tête nommé Remote Address:. C'est l'adresse IP d'où vous avez obtenu une réponse.
Donc, si vous devez passer en mode maintenance sur un serveur, désactivez simplement le trafic HTTP/HTTPS avec une règle iptablesREJECT, toutes les demandes iront à d'autres serveurs (avec une petite attente, presque pas perceptible pour les utilisateurs).
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 pour, disons, ssh), et de la prendre dans le pool DNS. Et puis vous utilisez un logiciel pour changer ces adresses IP en cas de défaillance d'un serveur. Heartbeat ou CARP peuvent le faire, par exemple, mais il existe d'autres solutions.
Cela a l'avantage que, pour les clients de votre service, rien n'a à changer dans la configuration, et vous n'avez pas à vous soucier de la mise en cache DNS ou du TTL, mais vous pouvez toujours profiter du round robin DNS "load balancing" .
Cela fera probablement le travail, surtout si vous pouvez avoir plusieurs IP sur vos boîtiers statiques. avoir une adresse IP "servir du contenu statique" et une adresse IP "gérer la machine". Si une boîte tombe en panne, vous pouvez utiliser une solution HA existante ou une intervention manuelle pour faire remonter l'IP de la machine défaillante sur l'un des autres "membres du cluster" ou une machine complètement nouvelle (selon la vitesse à laquelle elle serait pour que cela soit opérationnel).
Cependant, une telle solution aura quelques petits problèmes. L'équilibrage de charge ne sera pas proche de la perfection et si vous comptez sur une intervention manuelle, vous pourriez avoir des pannes pour certains visiteurs.
Un équilibreur de charge matériel peut probablement faire un meilleur travail à la fois de partage de la charge et de fourniture de "disponibilité du cluster" que le round-robin DNS. D'un autre côté, c'est un (ou deux, car idéalement vous avez les LB dans un cluster HA) du matériel qui aura besoin d'achat, d'alimentation et de refroidissement et (éventuellement) un certain temps pour se familiariser avec (si vous ne l'avez pas déjà des équilibreurs de charge dédiés).
Pour répondre succinctement à la question (le DNS à tour de rôle est-il assez bon comme démarreur, mieux que rien, "tandis que nous recherchons et mettons en œuvre de meilleures alternatives" sous la forme d'un équilibrage de charge pour notre contenu statique?), Je dirais que c'est mieux que rien, mais vous devez absolument continuer à rechercher d'autres formes d'équilibrage de charge.
Lorsque j'ai effectué des recherches sur l'équilibrage de la charge de 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 plusieurs groupes d'équilibrage de charge, avec un round robin DNS entre eux. Étant donné que plusieurs serveurs DNS peuvent répondre dans chaque espace de noms et que l'équilibrage de charge de Microsoft est auto-réparateur, cela fournit à la fois la redondance et l'équilibrage de 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 faire un round-robin DNS entre les serveurs HAProxy?
Je ne pense pas que ce soit une assez bonne solution car disons que vous avez maintenant deux serveurs et que vous effectuez un round robin en utilisant DNS sur 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 de servir cette adresse IP, dans le cadre du processus RR. Ensuite, 50% de votre audience recevra un site cassé sans javascript ou 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 de l'avoir lu quelque part?
L'équilibrage de charge à tour de rôle ne fonctionne que lorsque vous contrôlez également la zone DNS afin de pouvoir modifier la liste des serveurs et la transmettre aux maîtres de zone en temps opportun.
Comme mentionné dans l'une des autres réponses, le mal caché du 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 avec DNS TTL réglé sur une valeur très faible, vous avez peu de contrôle sur la durée pendant laquelle le FAI ou même le cache DNS du client gardera l'adresse IP désormais morte active.
C'est une amélioration par rapport à un SPOF bien sûr, mais seulement marginale. Je voudrais voir qui héberge votre serveur et voir ce qu'ils ont à offrir, beaucoup ont une sorte de service d'équilibrage de charge de base qu'ils peuvent fournir.
Vous pouvez également avoir un seul serveur avec le contenu statique dupliqué dans S3 et basculer vers le CNAME S3 lorsque votre serveur principal tombe en panne. Vous vous retrouverez avec le même délai mais sans le coût de plusieurs serveurs.
Cela dépend vraiment de ce dont vous parlez et du nombre de serveurs que vous utilisez. J'ai eu une fois un site qui fonctionnait sur plusieurs serveurs, et j'ai utilisé DNS round robin à cause de mon novice à l'époque, et ce n'était vraiment pas un gros problème. Ce n'était pas un gros problème car il n'a pas planté. C'était un système vraiment stupide et non compliqué, donc il a tenu le coup et avait un niveau de trafic assez constant. S'il s'est écrasé à cause de la circulation, c'était pendant la journée et quelque chose dont je pouvais facilement m'occuper. Je dirais que votre contenu statique est suffisamment simple pour ne pas provoquer de plantages à lui seul.
En dehors d'une défaillance matérielle, etc., dans quelle mesure votre serveur a-t-il été stable? Dans quelle mesure votre trafic sur ce contenu est-il "épineux"? En supposant directement Apache ou quelque chose et un trafic relativement plat, cela ne va pas beaucoup planter, et je dirais que le round-robin est "assez bon".
Je suis sûr que je vais voter contre parce que je ne prêche pas une solution 100% HA, mais ce n'est pas ce que vous avez demandé. Cela se résume à ce que vous êtes prêt à accepter comme solution par rapport à l'effort dépensé.
Si vous utilisiez RR DNS pour l'équilibrage de charge, ce serait bien, mais ce n'est pas le cas. Vous l'utilisez pour activer un serveur redondant, auquel cas ce n'est pas bien.
Comme un post précédent l'a dit, vous avez besoin de quelque chose pour détecter le rythme cardiaque et arrêter de le frapper jusqu'à ce qu'il revienne.
La bonne nouvelle est que Heartbeat est disponible à très bon marché, que ce soit dans les commutateurs ou dans Windows.
Je ne sais pas sur les autres OS, mais je suppose que c'est également le cas.
Il a une utilisation très marginale, suffisante pour vous aider à mettre en place une vraie solution. Comme vous le dites, les TTL doivent être réglés assez bas. Cela a l'avantage secondaire, cependant, de retirer une machine problématique du DNS pendant qu'elle a des problèmes. Supposons que SvrA, SvrB et SvrC distribuent votre contenu et que SvrA tombe en panne. Vous le retirez du DNS et après la courte période de temps définie par votre faible TTL, les résolveurs trouveront un serveur différent (SvrB ou SvrC) qui est en place. Vous remettez SvrA en ligne et le remettez dans DNS. Un court temps d'arrêt pour certains, aucun pour d'autres. Pas génial, mais réalisable. Plus vous mettez de serveurs statiques dans le mix, moins vous risquez d'avoir des groupes majoritaires d'utilisateurs en panne.
Vous n'obtiendrez certainement pas la véritable distribution équilibrée qu'une véritable solution d'équilibrage de charge fournira en raison de la topologie d'Internet. Je surveillerais toujours la charge sur tous les serveurs impliqués.