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 1
et FW 2
ci - dessous) sont également actifs / passifs et filtreront le trafic et enverront chaque flux vers un serveur frontal sain (vos équilibreurs de charge HTTP FE 1
et FE 2
infé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:
- Le FAI achemine le trafic allant vers vos adresses IP vers votre routeur actif.
- 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.
- Votre pare-feu applique le filtre (par exemple, "autorisez uniquement 80 / tcp et 443 / tcp à accéder à cette adresse IP particulière").
- Votre pare-feu agit également comme un routeur et transmet les paquets à un frontal sain.
- 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 1
et 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
. Quoirelayd
ne 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
pfsync
cela 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 relayd
configuration
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
}