Comment les équilibreurs de charge s'intègrent-ils dans un centre de données avec un débit beaucoup plus élevé que ce qu'ils peuvent gérer?

10

Vous disposez d'un data center standardisé sur les connexions 10GE. Avec, disons, des Nexus 7000 dans le noyau, des Nexus 5000 au niveau de l'agrégation et des extensions de matrice pour la périphérie des serveurs (j'utilise des équipements Cisco comme exemples, car c'est ce qui se trouve dans mon laboratoire spécifique). Certains équilibreurs de charge ACE 4710 sont suspendus à vos Nexus 5000, mais ils n'ont que des interfaces 1GE. Toutes vos connexions de commutation sont 10GE, nécessaires pour le trafic massif est-ouest (VM-à-VM) dans les centres de données virtualisés modernes.

Les équilibreurs de charge ne deviennent-ils pas un goulot d'étranglement dans certaines conditions de circulation? Je peux voir comment un trafic local est-ouest n'a même pas besoin d'atteindre l'équilibreur de charge, mais il existe d'autres situations où vous devez traverser le cœur, et peut-être même une interconnexion de centre de données.

Fondamentalement, je sais que les équilibreurs de charge sont utilisés dans le trafic client-serveur (nord-sud), et des choses comme HTTP GET n'ont pas besoin de 10GE, mais y a-t-il des situations dans lesquelles votre équilibreur de charge 1GE peut entraver un tout autrement- Chemin de trafic 10GE et causer des problèmes pour des choses comme vMotion (par exemple)?

load-balancer

— sentinelle
source

1

L'ACE 4710 est EOL / EOS depuis 2010. Êtes-vous lié à cet équilibreur de charge ou êtes-vous prêt à utiliser un équilibreur de charge moderne qui peut évoluer beaucoup plus haut? (De nombreux fabricants les fabriquent.) Il n'y a aucune raison d'imposer artificiellement des limites à votre débit de la manière que vous décrivez. Eh bien, aucune raison en dehors du coût, mais si vous avez acheté l'infrastructure que vous décrivez, il vous restera probablement de l'argent pour une configuration d'équilibrage de charge réelle.

— Brett Lykins

Ce n'est en fait pas un environnement de production, mais un véritable scénario de «laboratoire» qui contient ces périphériques particuliers. Dans un sens plus général, ma question est, étant donné la charge de trafic d'un centre de données typique, comment vous assurez-vous que l'équilibreur de charge ne devient pas un goulot d'étranglement dans votre conception? Cela joue dans votre conception, comme par exemple si votre centre de données est à plusieurs niveaux, à quel niveau effectuez-vous l'équilibrage de charge, etc. Dans mon exemple particulier, que je ne peux pas changer car ce n'est pas ma conception, est-il logique de les avoir Les appareils ACE à un bras des Nexus 5000 sont beaucoup plus puissants.

— sentinelle

6

Les équilibreurs de charge ne deviennent-ils pas un goulot d'étranglement dans certaines conditions de circulation?

Certes, mais ce n'est généralement pas le cas dans un réseau bien conçu.

Vous devriez être en mesure de concevoir votre réseau de manière à autoriser la majorité de votre trafic interne de serveur à serveur ("est-ouest" comme vous le dites) même s'il doit traverser votre cœur ou entre des centres de données.

Bien que souvent l'équilibreur de charge soit la passerelle par défaut pour les serveurs derrière lui, j'ai vu des configurations où un protocole de routage (c'est-à-dire OSPF ou RIP) est exécuté pour permettre au trafic "est-ouest" de contourner l'équilibreur de charge, ou dans des déploiements plus petits où les routes statiques ont été utilisées.

Si les équilibreurs de charge vont être un goulot d'étranglement même avec une bonne conception (c'est-à-dire que le volume de trafic est juste aussi élevé), il existe également des moyens d'équilibrer la charge sur plusieurs équilibreurs de charge.

— YApprendre
source

4

En effet. S'il y a un LB dans votre chemin vMotion, vous avez échoué en tant qu'ingénieur.

— Ricky Beam

"... il existe également des moyens d'équilibrer la charge sur plusieurs équilibreurs de charge" - tels que la sélection de l'équilibreur de charge réseau dans le DNS?

— Andrei Rînea

2

Il s'agit en effet d'un goulot d'étranglement qui limitera votre débit au «maillon le plus faible de la chaîne» qu'est votre LB. Cependant, vous pouvez le contourner. Si vous utilisez quelque chose appelé "retour en arrière" ou "retour direct du serveur", vous pouvez effectuer des flux de trafic asynchrones. Voici comment cela fonctionne:

a) le client fait une requête http au 2.2.2.2

b) LB répond au 2.2.2.2 et transmet la demande entrante à un serveur - puisque le LB et le serveur sont sur le même LAN, cela se fait à la couche 2.

c) Le serveur accepte cette connexion entrante car l'IP 2.2.2.2 est sur une interface de bouclage aliasée (sinon il laisserait tomber un paquet qui ne correspondait pas à une interface).

d) Le serveur répond directement au client.

La demande est de quelques octets. Le contenu servi peut être de n'importe quelle taille. Le trafic sortant ne passe pas par le LB, vous pouvez donc gérer BEAUCOUP plus de trafic.

À votre santé,

--tc

— Thomas Cannon
source

1

Gardez à l'esprit que cette opération n'est appropriée que pour les clusters L4. Pour les clusters L7, cela interrompra les réécritures d'en-tête, l'insertion de cookies (persistance), la terminaison SSL, toute sorte de correspondance d'URL et toutes les autres fonctionnalités plus avancées de nombreux équilibrages de charge.

— Apprendre