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)?
la source
Réponses:
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.
la source
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
la source