Équilibrage de charge des couches 4 et 7

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?

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.

É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.

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.