Équilibrage de charge des couches 4 et 7


21

J'essaie de décider entre l'utilisation d'une solution d'équilibrage de charge de couche 4 pour mon centre de données ou une solution de couche 7. Malheureusement (pour ma raison, c'est), mon cas d'utilisation est assez simple pour que les deux solutions fonctionnent bien, évitant la plupart des faiblesses et n'utilisant pas vraiment les forces de l'autre. Quelle que soit la solution que nous finissons par utiliser, elle doit avoir une disponibilité élevée et un débit élevé. Mais nous ne prévoyons de l'utiliser que pour équilibrer la charge sur un cluster de serveurs Web, dont aucun ne requiert de gestion de session «collante» (cookie ou IP), de règles de réécriture complexes - ou, d'ailleurs, de règles de réécriture sur tout.

Les équilibreurs de charge seront connectés à deux commutateurs, tous deux avec une connexion indépendante jusqu'à la couche d'agrégation du centre de données et fusionnés ensemble à l'aide de Rapid Spanning Tree et du protocole propriétaire que les commutateurs utilisent pour la virtualisation. Les équilibreurs de charge seront également réticulés entre eux sur un câble croisé. Tous les serveurs du cluster sont connectés aux deux commutateurs. Tout ce que les équilibreurs de charge doivent faire est de pointer le trafic sur eux.

Comme il ne s'agit que de HTTP, je peux utiliser une solution d'équilibrage de charge de couche 7 comme HAProxy ou nginx. Mais je pourrais aussi utiliser le projet LVS avec ldirectord ou keepalived ou autre chose.

J'ai essayé de briser les avantages et les inconvénients tels que je les vois, mais ça finit par se laver. Que recommanderiez-vous et pourquoi? Suis-je en train de manquer quelque chose?

Réponses:


17

Un avantage utile de "L7" comme haproxy est de pouvoir utiliser des cookies pour garder le même navigateur sur le même serveur principal. Cela facilite le débogage des hits client.

L'équilibrage L4 peut faire rebondir un seul utilisateur sur plusieurs serveurs principaux. (ce qui, dans certains cas, peut être avantageux, mais dans un sens de débogage / profilage, l'utilisation de "L7" est beaucoup plus utile.)

EDIT: Il existe également un avantage de vitesse potentiel à utiliser l'équilibrage HTTP. Avec Keep-Alives, les clients peuvent établir une seule session TCP vers votre équilibreur, puis envoyer de nombreux HIT sans avoir à rétablir de nouvelles sessions TCP (prise de contact à 3 voies). De même, de nombreux LB maintiennent des sessions persistantes sur les systèmes dorsaux, ce qui évite de faire la même prise de contact sur le serveur principal.

Un équilibrage de charge TCP strict peut ne pas accomplir ces deux tâches aussi facilement.

/ * FWIW: Je ne dirais pas "L7" ou "L4", je dirais HTTP ou TCP. Mais je suis un bâton pour éviter d'utiliser l'OSI pour décrire des choses avec lesquelles il ne correspond pas bien. * /

Je pense que fondamentalement, si vous ne savez pas quoi déployer, optez pour ce qui vous semble simple et naturel. Testez-le (utilisez un banc Apache?) Et assurez-vous qu'il fonctionne selon vos besoins. Pour moi, HTTP LB est plus naturel.


L'adhérence, basée sur les cookies ou sur IP, est certainement un avantage de la commutation L7. Mais ce n'est pas une application que notre application pourrait particulièrement utiliser.
Scrivener

Un inconvénient de l'équilibrage de charge de niveau HTTP ne serait-il pas que vous deviez avoir un équilibreur de charge de niveau TCP devant les équilibreurs HTTP pour permettre le basculement entre les deux?
Scrivener

@Scrivener - vous ne devriez pas, non. Je pense que le DNS à tour de rôle peut s'en occuper, sauf si je comprends mal votre question.
mfinni

@mfinni: Le DNS géographique mondial pourra pointer vers une adresse IP par centre de données. J'ai besoin de quelque chose pour répondre à cette adresse IP.
Scrivener

Je vois. Eh bien, cela dépend des capacités de vos appareils. Vous pouvez probablement trouver un périphérique compatible L7 qui peut fonctionner par paires avec un seul cluster VIP qui ne nécessiterait pas d'équilibreur de charge TCP / IP matériel. Si IIS et MS Windows NLB peuvent le faire, j'imagine que la plupart des autres produits commerciaux peuvent le faire.
mfinni

4

Étant donné le manque d'avantages pour vous de l'équilibrage L7, je me contenterais plutôt de l'équilibrage L4. Je suis un grand fan de garder le plus simple possible, sans trop sacrifier.

L7 exige que les équilibreurs inspectent les en-têtes http dans les paquets qui les traversent pour un routage approprié, ajoutant une surcharge supplémentaire et une augmentation marginale de la latence pour l'utilisateur final. Cela me semble une dépense inutile si vous n'y gagnez rien.


0

Certains fournisseurs DNS ont une fonctionnalité de basculement simple. Vous avez mentionné ce que vos besoins ne sont pas et ce qu'ils ne sont pas, mais si tout ce dont vous avez besoin est un round robin avec basculement en cas de problème , vous pouvez utiliser par exemple le basculement de zoneedit.com . En fonction de vos besoins en HA, cela peut être suffisant et vous pouvez sauter un niveau entier dans votre architecture.


Je souhaite que ce soit aussi simple - nous avons besoin de quelque chose de plus comme un tournoi à la ronde avec basculement, plus une séparation géographique. Tout cela n'est pas en cause, cependant, car il est fait par une entreprise extérieure.
Scrivener

Que voulez-vous dire - je suppose que je veux dire que le DNS est également effectué par une entreprise extérieure, et certains d'entre eux prennent en charge à la fois l'équilibrage de la charge géographique et le basculement en tant que service DNS - ou vous voulez dire qu'il y a un tiers supplémentaire entre vous et le fournisseur DNS, ou que vous n'avez tout simplement pas de mot à dire sur le DNS?
Ernest Mueller

Le premier - nous faisons déjà du DNS avec une entreprise extérieure qui effectue le basculement et l'équilibrage de la charge géographique vers les différents centres de données. J'ai juste besoin d'équilibrer la charge à l'intérieur du centre de données.
Scrivener

Vous pouvez utiliser le même round robin pour serveur par serveur sur le frontal, non? Le DNS pour l'équilibrage de charge à tour de rôle est souvent utilisé pour un seul centre de données; géolocalisations multiples est une exigence de grand garçon au sommet de cela.
Ernest Mueller
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.