web-dev-qa-db-fra.com

Comment faire des équilibreurs de charge redondants?

Je comprends que le but des équilibreurs de charge est d'équilibrer la charge entre vos serveurs et de suivre la santé des instances, etc. Mais que faire si l'équilibreur de charge lui-même échoue? Comment configurez-vous des équilibreurs de charge redondants? (équilibrage de charge équilibreurs de charge?)

Je pouvais voir comment les contrôles d'intégrité DNS pourraient être utiles, mais il y a évidemment des problèmes de latence majeurs, n'est-ce pas?

Cela suppose que vous n'utilisez aucun service tiers comme AWS ELB ou quelque chose de similaire. Que faire si vous utilisez simplement Nginx?

nginxload-balancingredundancyload-balance
28
Sherzod

Il existe deux façons d'atteindre la haute disponibilité (haute disponibilité) d'un équilibreur de charge - ou à cet égard, n'importe quel service. Supposons que vous ayez deux machines, avec des adresses IP:

  • 192.168.100.101
  • 192.168.100.102

Les utilisateurs se connectent à une IP, donc ce que vous voulez faire est de séparer l'IP d'une boîte spécifique - par exemple, créer une IP virtuelle. Cette adresse IP sera 192.168.100.100.

Maintenant, vous pouvez choisir le service HA qui se chargera du basculement/rétablissement automatique de l'adresse IP. Certains des services les plus simples pour unix sont (u) carpe et keepalived, certains des plus complexes sont par exemple RedHat Cluster Suite ou Pacemaker.

Prenons l'exemple de keepalived - deux services keepalived - chacun fonctionnant sur sa propre boîte - et ils communiquent ensemble. Cette communication est souvent appelée rythme cardiaque.

|   VIP   |                           |         |
|  Box A  | ------v^-----------v^---- |  Box B  |
|   IP1   |                           |   IP2   |

Si un keepalived cesse de répondre (l'un des services tombe en panne pour une raison quelconque, ou la boîte rebondit ou s'arrête) - keepalived sur une autre box remarquera des battements de cœur manqués, et présumera que l'autre nœud est mort, et prendra des actions de basculement. Cette action dans notre cas sera de faire apparaître l'IP flottante.

                                      |   VIP   |
    ------------------ -------------- |  Box B  |
                                      |   IP2   |

Le pire cas qui peut se produire dans ce cas est la perte de sessions pour les clients, mais ils pourront se reconnecter. Si vous voulez éviter cela, deux équilibreurs de charge doivent être en mesure de synchroniser les données de session entre eux, et s'ils peuvent le faire, les utilisateurs ne remarqueront rien sauf peut-être cassé un court délai.

Un autre écueil de cette configuration est split brain - lorsque les deux boîtes sont en ligne mais que le lien est rompu et que les deux boîtes affichent la même IP. Cela est souvent résolu par une sorte de mécanisme d'escrime (réservation SCSI, redémarrage IPMI, coupure d'alimentation de la PDU intelligente, ...), ou un nombre impair de nœuds nécessitant la majorité des membres du cluster pour être en vie pour le démarrage du service.

|   VIP   |                           |   VIP   |
|  Box A  |                           |  Box B  |
|   IP1   |                           |   IP2   |

Un logiciel de gestion de cluster plus complexe (comme Pacemaker) peut déplacer un service entier (par exemple: l'arrêter sur un nœud et le démarrer sur un autre) - et c'est ainsi que la HA pour des services comme les bases de données peut être réalisée.

Une autre façon possible - si vous contrôlez des routeurs à proximité de vos équilibreurs de charge, est d'utiliser ECMP. Cette approche vous permet également de mettre à l'échelle horizontalement des équilibreurs de charge. Cela fonctionne par chacune de vos deux boîtes parlant BGP à votre routeur (s). Chaque boîte doit annoncer IP virtuelle (192.168.100.100) et le routeur chargera le trafic d'équilibrage via ECMP. Si une machine meurt, elle arrêtera la publicité VIP, ce qui empêchera les routeurs de lui envoyer du trafic. La seule chose à laquelle vous devez faire attention dans cette configuration est d'arrêter la publicité IP si l'équilibreur de charge lui-même meurt.

33
Jakov Sosic

L'utilisation de Nginx comme équilibreur de charge devrait vous permettre de suivre la redirection détaillée dans ce post en modifiant votre configuration pour détecter un délai d'attente sans réponse:

équilibrage de charge de basculement automatique nginx

En théorie, si vous disposez d'un environnement haute disponibilité, plusieurs équilibreurs de charge en cluster devraient permettre de maintenir le service en cas de défaillance d'un.

J'espère que cela t'aides.

3
user4657

Les équilibreurs de charge matérielle prennent en charge les configurations "actives/passives" ou "actives/actives" depuis des années, dans les deux cas, elles sont ensuite configurées en parallèle à partir d'une perspective de couche 1/2 ... active/passive utilise des mécanismes de surveillance/de maintien tels que décrits , active/active peut être implémentée de nombreuses manières. Pour apparaître comme une seule adresse IP sur le frontend, deux équilibreurs ou plus peuvent, tant qu'ils sont tous/les deux en ligne, faire des choses comme:

  • répondre de manière sélective aux requêtes ARP à l'adresse IP partagée sur la base de l'adresse MAC ou IP source lorsque les clients sont sur le même réseau
  • négocier entre eux qui gère le trafic d'une nouvelle connexion donnée TCP
  • laissez le trafic des couches 3-7 dupliqué ou erroné se produire de manière imprudente et comptez sur le client/routeur TCP piles pour le trier)

Et puis changez leur mode pour accepter tout ou plus de trafic lorsque la communication avec/un appareil partenaire est perdue.

côté backend:

  • chacun des équilibreurs peut, en fonctionnement normal, utiliser uniquement un sous-pool donné de serveurs d'applications
  • ou, des demandes en double peuvent simplement être générées ici aussi ...
  • ou, la négociation entre les équilibreurs pourrait être faite
2
rackandboneman