Est-il possible d'utiliser plusieurs équilibreurs de charge pour rediriger le trafic vers mes serveurs d'applications?


9

Je suis nouveau dans l'équilibrage de charge et je me demande s'il est possible d'utiliser plusieurs équilibreurs de charge pour rediriger le trafic vers mes serveurs d'applications. Je ne comprends pas vraiment comment cela peut être fait. Un nom de domaine ne doit-il pas correspondre un à un avec l'adresse IP d'un certain serveur (dans ce cas, l'IP d'un équilibreur de charge)? Si chaque serveur d'équilibrage de charge a une IP différente, comment la demande peut-elle être reçue par les deux équilibreurs de charge (ou par 10 équilibreurs de charge ou 50 ou 100)?


Merci pour votre réponse. Donc, fondamentalement, si je veux utiliser plusieurs équilibreurs de charge pour gérer mon trafic, je n'ai qu'à configurer un CNAME différent pour chacun d'eux? Plus précisément, si j'ai besoin de 10 équilibreurs de charge pour gérer le trafic vers mon site, c'est la seule façon de le faire?
user3790827

1
Je recommande de laisser les questions ouvertes pendant au moins une journée avant de les fermer. Même cela est généralement hâtif. Ce n'est pas parce que vous avez reçu une réponse que c'est nécessairement la seule (ou la meilleure) réponse, et marquer votre Q&R comme réponse signifie généralement qu'elle reçoit moins d'attention.
Andrew B

1
@Anatoly Je n'ai pas encore pris de décision. J'ai passé en revue les solutions présentées ici et j'ai également parlé avec certains de mes amis qui m'ont recommandé d'autres solutions. Je pense que pour mon cas d'utilisation, la meilleure solution jusqu'à présent serait d'utiliser des serveurs VPS d'un fournisseur bon marché comme DO ou Vultr qui n'offrent pas d'IP virtuelle et d'utiliser la méthode utilisée par Algolia avec l'équilibrage de la charge client. J'ai besoin de HA et d'évolutivité pour l'API uniquement, donc il n'y aurait pas de gros problème si je crée des sous-domaines différents pour chaque équilibreur de charge. Ces utilisateurs finaux du widget ne les remarqueront jamais de toute façon.
user3790827

@ user3790827 ressemble à un plan. Malgré le type d'exigences ayant HA et Failover, il y a trop de modèles, tout le monde rencontre le même problème mais personne n'a SLA 99.9 (8 heures d'indisponibilité par an) ou plus. Les solutions de haute disponibilité sont généralement coûteuses et le compromis commercial entre la disponibilité et le coût. Les clients acceptent généralement 99.9 et conscients des temps d'arrêt potentiels ou des délais planifiés, même une disponibilité de 100% ne vous garantit pas zéro bogue avec le développement / déploiement / sécurité ou des erreurs humaines.
Anatoly

J'ai enquêté sur le fait que Google Chrome force l'invalidation DNS et la requête à se produire en cas de délai d'expiration de 3 secondes. Pas sûr du comportement des autres navigateurs.
Anatoly

Réponses:


12

L'utilisation du DNS à tour de rôle n'est pas idéale pour la haute disponibilité - si un serveur se déconnecte, les clients essaieront toujours de s'y connecter et attendront un délai d'attente.

Il existe d'autres moyens d'y parvenir.
1) Équilibreurs de charge actifs / passifs
Fondamentalement, un équilibreur de charge gère tout le trafic pour une seule adresse IP.
Si cet équilibreur tombe en panne, le nœud passif intervient et prend en charge l'IP.
Gardez à l'esprit que les équilibreurs de charge ne sont à peu près que le transfert de trafic, donc pour les sites de petite à moyenne taille, cela peut fonctionner correctement.

2) Équilibreurs de charge actifs / actifs
La même IP de trafic est configurée sur les deux (ou plusieurs autres) équilibreurs de charge.
Le trafic entrant est envoyé à tous les équilibreurs de charge, mais un algorithme choisit quel équilibreur doit répondre, tous les autres rejetent ce trafic.
Pour y penser simplement, vous avez deux équilibreurs de charge:
lorsque l'IP demandante se termine par un nombre pair, alors l'équilibreur de charge A répond, sinon l'équilibreur de charge B répond.

Bien sûr, votre infrastructure doit prendre en charge cela et il y a des frais généraux dus au trafic envoyé mais rejeté.
Plus d'informations, par exemple ici: http://community.brocade.com/t5/SteelApp-Docs/Feature-Brief-Deep-dive-on-Multi-Hosted-IP-addresses-in-Stingray/ta-p/73867


Lorsque vous dites «bien sûr, votre infrastructure doit prendre en charge cela», vous voulez dire que j'ai besoin d'une machine ou d'une machine virtuelle supplémentaire qui enverra des demandes aux équilibreurs de charge?
user3790827

2
@ user3790827 Dans ce contexte, l'infrastructure est l'équipement réseau, pas les serveurs. '
Jenny D

1
Je prévois d'utiliser un fournisseur de cloud donc je n'ai pas de contrôle direct sur l'infrastructure physique. Que dois-je demander à mon fournisseur de services vps?
user3790827

1
Il n'y a que des recommandations abstraites car cela dépend d'une tonne de détails. Nous ne savons même pas s'il est logique d'avoir une IP multi hébergée ici - peut-être que son trafic n'est que de quelques centaines de Mbit / s. Si vous en avez besoin, j'évaluerais le logiciel approprié, vérifierais les exigences et déterminerais quel fournisseur le prend en charge. Est-ce que DNS RR fonctionnerait? Sûr. L'utiliserais-je? Cela dépend du type de disponibilité que vise le propriétaire de l'entreprise pour laquelle je travaille!
faker

@faker Je suis désolé, je suppose que c'est ma faute car je n'ai pas donné suffisamment de détails. Je veux créer un script javascript qui sera inséré dans les sites Web d'autres personnes et collectera les données de trafic (pensez à Google Analytics), il accédera également au serveur pour afficher des statistiques pour chaque page sur laquelle il est chargé. Fondamentalement, il y aurait un fichier javascript qui sera chargé pour chaque site Web sur lequel il est utilisé.
user3790827

6

La haute disponibilité avec équilibreurs de charge est généralement mise en œuvre à l'aide d'un protocole d' adresse IP virtuelle (VIP) qui permet à plusieurs hôtes (c'est-à-dire des équilibreurs de charge) de répondre à une adresse IP commune de l'une des manières possibles (variations sur actif / passif, actif / actif) .

Il existe un bon nombre de ces protocoles, ceux que j'ai vus le plus avec les équilibreurs de charge réguliers sont VRRP et NLB (ainsi qu'un bon nombre de protocoles en boîte noire non descriptifs dans les appliances). En étendant les routeurs et les pare-feu, on peut également rencontrer CARP , HRSP , GLSP par exemple.

Cette stratégie présente un certain nombre d'avantages par rapport à l'équilibrage de charge DNS, qui est une stratégie plus simple (et qui est prise en charge dans une autre réponse).

L'équilibrage de charge DNS est par exemple surchargé avec:

  • la rotation lente des mécanismes de mise en cache DNS
  • algorithmes d'équilibrage de charge limités (généralement juste tourniquet)
  • l'externalisation de la décision d'équilibrage de charge vers le client (via la mise en cache de l'enregistrement DNS)
  • Vidange lente des files d'attente de service lorsqu'un serveur (c'est-à-dire un équilibreur de charge) est retiré de la rotation (basé sur les TTL d'enregistrement DNS gérés par les FAI et les clients )
  • Basculement lent en cas de défaillance de l'équilibreur de charge

En utilisant un protocole IP virtuel pour HA, on peut avoir le choix de réaliser par exemple:

  • Choix de l'algorithme d'équilibrage de charge parmi les équilibreurs de charge
  • Décisions d'équilibrage de charge centrées sur le serveur (facilitant par exemple les mesures et le routage basés sur l'intégrité du service)
  • Vidange plus rapide des files d'attente de service lorsqu'un équilibreur de charge est retiré de la rotation.
  • Basculement instantané en cas de défaillance de l'équilibreur de charge

Vous seul savez quelle stratégie et quel protocole correspondent le mieux à votre scénario.


1
J'ajouterais également que certains équilibreurs de charge prennent en charge l'établissement de sessions BGP avec des routeurs à proximité, ce qui vous permet de configurer des solutions Anycast . Si l'équilibreur de charge tombe en panne ou arrête la publicité pour le VIP (échec du contrôle de santé), le meilleur candidat de routage suivant gagne. La dernière phrase de cette réponse est cependant impérative: vous devez vraiment parler aux administrateurs réseau de votre entreprise.
Andrew B

Voici une belle description de ce que vous décrivez dans le premier paragraphe cisco.com/c/en/us/support/docs/application-networking-services/…
Martin Podval

2

Les exigences: avoir une solution pratique qui fonctionne pour le cloud ou tout type d'environnement où aucun accès aux équilibreurs de charge matérielle, aux protocoles BGP et tout le reste.

Le numéro de demande de revenu d'une application est inconnu mais devrait être suffisamment élevé pour répondre à une attente de charge accrue sans crainte.

Trouvons une application avec une nature de charge similaire, par exemple un magasin de journalisation et une application de recherche. J'en ai trouvé un .

Ce qu'ils veulent:

  1. Équilibrez la charge entre les capteurs
  2. Offrir une tolérance aux pannes, nous permettant de continuer à ingérer des données si l'un des collecteurs décède ou rencontre des problèmes
  3. Échelle horizontale avec la croissance de nos volumes de journaux

Qu'ont-ils essayé et appris sur ELB:

  1. Ne fonctionne pas comme prévu
  2. Problèmes de latence dus à une charge accrue
  3. Pas assez de surveillance
  4. Trop de limitations (nombre de ports et protocoles ouverts)

Pourquoi ont-ils choisi avec Route53:

  1. "Round robin est un équilibrage de charge assez basique, mais il fonctionne bien pour nous du point de vue de l'efficacité"
  2. "Nous profitons des contrôles de santé de basculement Route 53."
  3. "S'il y a un problème avec un collecteur, Route 53 le retire automatiquement du service; nos clients ne verront aucun impact."
  4. Aucun préchauffage requis avec Route 53

La route 53 s'est avérée être le meilleur moyen pour Loggly de tirer parti de nos collecteurs haute performance compte tenu de nos énormes volumes de journaux, de variations imprévisibles et de la croissance constante de notre entreprise. Cela correspond aux objectifs principaux des collecteurs: collecter des données à la vitesse de la ligne du réseau sans perte, et cela nous permet de bénéficier de l'élasticité de tous les services AWS que nous utilisons chez Loggly.

Cet exemple particulier montre que dans certains scénarios (collecteur de journaux, service d'annonces ou similaire), l'équilibreur de charge est redondant et que la «solution de round robin de contrôle de santé DNS» fait très bien son travail.


Voyons ce que AWS dit du basculement DNS:

Avec le basculement DNS, Route 53 peut détecter une panne de votre site Web et rediriger vos utilisateurs finaux vers des emplacements alternatifs ou de sauvegarde que vous spécifiez. Le basculement DNS de Route 53 s'appuie sur des vérifications de l'état - en effectuant régulièrement des requêtes Internet vers les points de terminaison de vos applications à partir de plusieurs emplacements à travers le monde - pour déterminer si chaque point de terminaison de votre application est actif ou non.

Cette technique rend également ELB (non requis, juste pour une note) plus robuste, encore une fois, il est basé sur RR + Health Check:

Le basculement DNS Route 53 gère tous ces scénarios de défaillance en s'intégrant à ELB en arrière-plan. Une fois activé, Route 53 configure et gère automatiquement les contrôles de santé pour les nœuds ELB individuels.


Voyons maintenant comment cela fonctionne en arrière-plan. La question évidente est de savoir comment gérer la mise en cache DNS:

Cependant, la mise en cache DNS peut toujours être un problème ici (voir notre article précédent où le problème de "longue queue" est couvert) si TTL n'est pas respecté par toutes les couches entre votre client et Route 53. Vous pouvez alors appliquer une technique de "cache busting": envoyer une demande à un domaine unique

("http://<unique-id>.<your-domain>") 

et définir une ressource générique

Record "*.<your-domain>" to match it.

L'Algolie a introduit une "stratégie de relance client" qui fonctionne plutôt bien si votre client (JS dans votre cas) peut gérer cela:

Nous avons fini par mettre en œuvre une stratégie de nouvelle tentative de base dans nos clients API. Chaque client API a été développé pour pouvoir accéder à trois machines différentes. Trois enregistrements DNS différents représentaient chaque utilisateur: USERIDID-1.algolia.io, USERID-2.algolia.io etUSERID-3.algolia.io. Notre première implémentation a été de sélectionner au hasard l'un des enregistrements, puis de réessayer avec un autre en cas d'échec.


1
Je pense que l'approche d'Algolia est la meilleure pour mon budget et mes cas d'utilisation. Normalement, je serais de nouveau en utilisant un sous-domaine différent pour chaque équilibreur de charge, mais comme seul le widget JS les utilise, l'utilisateur final ne remarquera jamais la différence.
user3790827

1
Quelqu'un a également suggéré d'utiliser DNS cloudflare.com/features-optimizer de Cloudflare pour rediriger le trafic vers l'équilibreur de charge de secours une fois qu'une défaillance se produit avec l'équilibreur de charge actuellement utilisé. cloudflare.com/dns
user3790827
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.