Je vois souvent des architectures d'applications Web avec un SLB / reverse-proxy devant un tas de serveurs d'applications.

Que se passe-t-il lorsque le nombre de connexions à la SLB nécessite trop de ressources pour qu'une seule SLB puisse gérer efficacement? Pour un exemple concret mais excessif, considérez 2 millions de connexions HTTP persistantes. De toute évidence, un seul SLB ne peut pas gérer cela.

Quelle est la configuration recommandée pour la mise à l'échelle d' une SLB?

Est-il typique de créer un groupe / cluster de LB? Si oui, comment la charge client est-elle répartie entre le groupe de LB?

Les équilibreurs de charge ne peuvent pas être facilement mis à l'échelle par d'autres équilibreurs de charge car il y aura intrinsèquement un seul équilibreur de charge sur la chaîne quelque part pour maintenir les connexions. Cela dit, les équilibreurs tels que LVS ou HAProxy ont une capacité absurde de l'ordre de Gbps. Une fois que vous aurez dépassé les capacités d'un seul équilibreur de charge (logiciel, matériel, etc.), vous devrez passer à d'autres techniques telles que le DNS à tour de rôle.

OK, il y a déjà une réponse acceptée, mais il y a quelque chose à ajouter .. Les plus courants « classiques » des moyens de mise à l' échelle du niveau d'équilibrage de charge sont (sans ordre particulier):

• DNS Round Robin pour publier plusieurs adresses IP pour le domaine. Pour chaque adresse IP, implémentez une paire de serveurs hautement disponibles (2 serveurs coopérant pour maintenir une adresse IP opérationnelle à tout moment.) Chaque IP correspond à un cluster d'équilibrage de charge, en utilisant des appliances ou des serveurs avec un logiciel d'équilibrage de charge. Dimensionnez horizontalement en ajoutant plus de paires d'équilibreurs de charge selon vos besoins.

• Modifications de routage ou de pare-feu pour répartir la charge sur plusieurs équilibreurs de charge. Demandez au routeur avant ou au pare-feu avant d'étendre les connexions entrantes à plusieurs adresses IP (chacune représentant une paire d'équilibreurs de charge) en hachant l'adresse IP source , en disposant de plusieurs routes à coût égal vers les équilibreurs de charge, ou similaire.

• Une couche d' équilibreurs de charge de niveau IP devant une couche d'équilibreurs de charge de niveau HTTP . L'équilibrage de charge de la couche IP peut être implémenté dans les ASIC / silicium, et peut être méchant rapidement pour certaines choses. Ainsi, une seule paire d'équilibreurs de charge IP peut souvent `` suivre '' plusieurs équilibreurs de charge de niveau HTTP / HTTPS et fournir des niveaux de performances multi-gigabits tout en conservant une architecture simple et agréable.

Aller complètement en profondeur sur les différentes façons de faire ce qui précède nécessiterait une réponse très longue. Mais en général, il n'est pas si difficile de faire évoluer le niveau de l'équilibreur de charge , il est beaucoup plus difficile de faire évoluer le niveau du serveur d'applications et en particulier le niveau de la base de données.

Que vous choisissiez un facteur de forme d'appliance (F5, Cisco, A10) ou un serveur générique (Windows / Linux + logiciel) importe moins. Les principales considérations lors de la mise à l'échelle de la couche d'équilibrage de charge sont les suivantes:

• État complet ou apatride. Avez-vous absolument besoin de séances collantes ou pouvez-vous vivre sans? Ne pas garder l'état rend tout plus simple.
• «Matériel» (ASIC) contre «logiciel» (serveurs à usage général) pour l'équilibrage de charge. Chacun a ses avantages et ses inconvénients, voir la documentation de présentation HAProxy liée ci-dessus.
• Équilibrage de charge L3 / 4 (IP / TCP / IP) contre Équilibrage de charge L7 (HTTP) . Encore une fois, le pour et le contre, le document HAProxy offre un bon aperçu.
• Terminaison SSL , où, sur les nœuds Web ou sur l'équilibreur de charge.

Généralement, vous n'avez pas à vous en préoccuper avant que votre site Web ne devienne très volumineux - un seul serveur moderne avec fx nginx traitera des dizaines de milliers de requêtes HTTP simples par seconde. Ne faites donc pas d'optimisation prématurée, ne vous en occupez pas avant de le faire.

La clé pour mettre à l'échelle une couche d'équilibrage de charge HTTP consiste à ajouter d'abord une autre couche d'équilibrage de charge de niveau inférieur (IP ou TCP). Cette couche peut être entièrement construite avec un logiciel open source, bien que vous obtiendrez de meilleurs résultats si vous avez des routeurs modernes.

Les flux (sessions TCP) doivent être hachés à l' aide d'en-têtes tels que les ports IP et TCP source / destination, pour décider à quelle interface ils vont. Vous avez également besoin d'un mécanisme pour vous assurer que lorsqu'un frontal meurt, il cesse de s'utiliser.

Il existe différentes stratégies, je vais en décrire quelques-unes que j'ai utilisées dans la production sur des sites desservant des millions d'utilisateurs, afin que vous puissiez vous faire une idée. Il serait trop long d'expliquer tout en détail mais j'espère que cette réponse vous donnera suffisamment d'informations / pointeurs pour commencer. Afin de mettre en œuvre ces solutions, vous aurez besoin de quelqu'un qui connaît vraiment le réseautage.

Certes, ce que je décris ici est beaucoup plus difficile à mettre en œuvre que ce qui est décrit dans d'autres réponses, mais c'est vraiment l'état de l'art si vous avez un site Web à fort trafic avec de gros problèmes d'évolutivité et des exigences de disponibilité supérieures à 99,9% . À condition que vous ayez déjà un ingénieur réseau un peu à bord, cela coûte moins cher à installer et à exécuter (à la fois en capex et en opex) que les appliances d'équilibrage de charge, et il peut être mis à l'échelle davantage sans frais supplémentaires (par rapport à l'achat d'un nouveau, encore plus appareil coûteux lorsque vous devenez trop grand pour votre modèle actuel).

Première stratégie: avec un pare-feu

Vraisemblablement, vous avez deux routeurs sur lesquels vos liaisons montantes FAI sont connectées. Votre FAI fournit 2 liens (actif / passif, utilisant VRRP). Sur vos routeurs, vous utilisez également VRRP et vous acheminez le trafic allant vers votre réseau public vers un pare-feu. Les pare-feu ( FW 1et FW 2ci - dessous) sont également actifs / passifs et filtreront le trafic et enverront chaque flux vers un serveur frontal sain (vos équilibreurs de charge HTTP FE 1et FE 2inférieurs).

      + -------------- + + -------------- +
      | Routeur FAI A | | Routeur FAI B |
      + -------------- + + -------------- +
             | |
           == # ====================== # == (réseau public)
             | |
      + --------------- + + --------------- +
      | Votre routeur A | | Votre routeur B |
      + --------------- + + --------------- +
             | |
           == # ===== # ========== # ===== # == (réseau privé RFC 1918)
             | | | |
       + ------ + + ------ + + ------ + + ------ +
       | FW 1 | | FE 1 | | FE 2 | | FW 2 |
       + ------ + + ------ + + ------ + + ------ +

L'objectif est d'avoir un flux ressemblant à ceci:

1. Le FAI achemine le trafic allant vers vos adresses IP vers votre routeur actif.
2. Vos routeurs acheminent le trafic vers un VIP qui utilise une adresse RFC 1918 . Ce VIP appartient au pare-feu actif, un peu comme VRRP. Si vous utilisez OpenBSD pour vos besoins de pare-feu, vous pouvez utiliser CARP , une alternative sans brevet à VRRP / HSRP.
3. Votre pare-feu applique le filtre (par exemple, "autorisez uniquement 80 / tcp et 443 / tcp à accéder à cette adresse IP particulière").
4. Votre pare-feu agit également comme un routeur et transmet les paquets à un frontal sain.
5. Votre frontend met fin à la connexion TCP.

Maintenant, la magie opère aux étapes 4 et 5, alors voyons plus en détail ce qu'ils font.

Votre pare-feu connaît la liste des frontends ( FE 1et FE 2), et il en choisira un en fonction d'un aspect particulier du flux (par exemple en hachant l'IP et le port source, entre autres en-têtes). Mais il doit également s'assurer qu'il transfère le trafic vers un frontend sain, sinon vous créerez un trou noir. Si vous utilisez OpenBSD, par exemple, vous pouvez utiliser relayd. Quoirelaydne est simple: il vérifie l'intégrité de tous vos frontends (par exemple en leur envoyant une requête HTTP de sonde), et chaque fois qu'un frontend est sain, il l'ajoute à une table que le pare-feu utilise pour sélectionner le prochain bond des paquets d'un flux donné . Si un frontend échoue aux contrôles de santé, il est supprimé de la table et aucun paquet ne lui est envoyé. Lors du transfert d'un paquet vers un frontend, tout ce que le pare-feu fait est de permuter l'adresse MAC de destination du paquet pour être celle du frontend choisi.

À l'étape 5, les paquets de l'utilisateur sont reçus par votre équilibreur de charge (que ce soit Varnish, nginx ou autre). À ce stade, le paquet est toujours destiné à votre adresse IP publique, vous devez donc alias vos VIP sur l'interface de bouclage. Ceci est appelé DSR (Direct Server Return), car vos frontends mettent fin à la connexion TCP et le pare-feu entre les deux ne voit que le trafic simplex (uniquement les paquets entrants). Votre routeur acheminera les paquets sortants directement vers les routeurs du FAI. C'est particulièrement bon pour le trafic HTTP car les demandes ont tendance à être plus petites que les réponses, parfois de manière significative. Juste pour être clair: ce n'est pas une chose spécifique à OpenBSD et est largement utilisé dans les sites Web à fort trafic.

Gotchas:

• Les utilisateurs finaux se connecteront directement à vos serveurs frontaux car vous utilisez DSR. Peut-être que c'était déjà le cas, mais si ce n'était pas le cas, vous devez vous assurer qu'ils sont correctement sécurisés.
• Si vous utilisez OpenBSD, sachez que le noyau est monothread afin que les performances d'un seul cœur de processeur limitent le débit d'un pare-feu. Cela peut être un problème selon votre type de carte réseau et le taux de paquets que vous voyez. Il existe des moyens de résoudre ce problème (voir ci-dessous).

Deuxième stratégie: sans pare-feu

Cette stratégie est plus efficace mais plus difficile à configurer car elle dépend davantage des spécificités des routeurs dont vous disposez. L'idée est de contourner le pare-feu ci-dessus et de laisser les routeurs faire tout le travail que faisaient les pare-feu.

Vous aurez besoin de routeurs qui prennent en charge les listes de contrôle d'accès L3 / L4 par port, BGP et ECMP et le routage basé sur les politiques (PBR). Seuls les routeurs haut de gamme prennent en charge ces fonctionnalités, et ils ont souvent des frais de licence supplémentaires pour utiliser BGP. Ceci est généralement moins cher que les équilibreurs de charge matériels et est également beaucoup plus facile à mettre à l'échelle. La bonne chose à propos de ces routeurs haut de gamme est qu'ils ont tendance à être à débit de ligne (par exemple, ils peuvent toujours maximiser la liaison, même sur les interfaces 10 GbE, car toutes les décisions qu'ils prennent sont prises en matériel par les ASIC).

Sur les ports sur lesquels vous avez vos liaisons montantes FAI, appliquez l'ACL qui était sur le pare-feu (par exemple, "autorisez uniquement 80 / tcp et 443 / tcp à accéder à cette adresse IP particulière"). Demandez ensuite à chacun de vos frontends de maintenir une session BGP avec votre routeur. Vous pouvez utiliser l'excellent OpenBGPD (si vos frontends sont sur OpenBSD) ou Quagga . Votre routeur ECMP le trafic vers les frontaux qui sont sains (car ils maintiennent leurs sessions BGP). Le routeur acheminera également le trafic de manière appropriée à l'aide de PBR.

Raffinements

• Avec la solution de paire de pare-feu, c'est bien si vous pouvez synchroniser les états TCP à travers les pare-feu, de sorte que lorsqu'un pare-feu tombe en panne, tout bascule en douceur vers l'autre. Vous pouvez y parvenir avec pfsync.
  • Gardez à l'esprit que pfsynccela doublera généralement le taux de paquets sur vos pare-feu.
  • HTTP est un protocole sans état, donc ce n'est pas la fin du monde si vous réinitialisez toutes les connexions lors d'un basculement de pare-feu parce que vous ne l'utilisez pas pfsync.
• Si vous êtes devenu trop grand pour un seul pare-feu, vous pouvez utiliser ECMP sur votre routeur pour acheminer votre trafic vers plusieurs paires de pare-feu.
• Si vous utilisez plus d'une paire de pare-feu, vous pouvez tout aussi bien les rendre tous actifs / actifs. Vous pouvez y parvenir en faisant en sorte que les pare-feu maintiennent une session BGP avec les routeurs, tout comme les frontaux doivent en maintenir une dans la 2ème conception sans pare-feu.

Exemple de relaydconfiguration

Voir aussi HOWTO sur https://calomel.org/relayd.html

vip = "1.2.3.4" # Votre adresse IP publique
               # (vous pouvez en avoir plusieurs, mais vous n'en avez pas besoin)
fe1 = "10.1.2.101"
fe2 = "10.1.2.102"
fe3 = "10.1.2.103"
fe4 = "10.1.2.104" # Vous pouvez avoir un nombre illimité de frontends.
int_if = "em0"
table <fe> {$ fe1 retry 2, $ fe2 retry 2, $ fe3 retry 2, $ fe4 retry 2}
table <fallback> {127.0.0.1}

rediriger le trafic Web {
        écouter sur le port $ vip 80
        délai d'expiration de la session 60
        route vers <fe> vérifiez http "/healthcheck.html" digest "(le sha1sum de healthcheck.html)" interface $ int_if
}

Personnellement, je passe à des équilibreurs de charge matériels plus simples et moins configurables à ce stade - des choses comme Cisco ACE / ASA, Foundry ServerIrons, peut-être même Zeus ZXTM (un SW LB conçu pour des charges très lourdes).

Peut-être qu'au lieu de garder constamment autant de connexions ouvertes pour envoyer des réponses, coder votre application de telle manière que les clients interrogent périodiquement vos serveurs aussi souvent que nécessaire?

Est-ce que tout ce que vous faites nécessite une réponse cette très milliseconde ou un client peut-il attendre 15/20 secondes jusqu'à la prochaine période d'interrogation?

Une approche typique consisterait à créer un cluster suffisamment grand pour gérer la charge requise et à utiliser un SLB capable d'effectuer un équilibrage de charge déterministe (dans le cas de connexions persistantes).

Quelque chose comme CARP utilise un hachage de l'adresse IP demandeuse pour déterminer le serveur Web principal qui traiterait la demande, cela devrait être déterministe mais pas très utile s'il y a un pare-feu ou un NAT devant votre équilibreur de charge.
Vous pouvez également trouver quelque chose comme IPVS utile si vous utilisez Linux.