Des expériences utilisant l’équilibrage de la charge logicielle par rapport à un équilibreur de la charge matérielle?

Question

L’application ASP.NET dont je suis actuellement responsable a atteint ses limites en ce qui concerne sa capacité à évoluer au sein d’un seul serveur. De toute évidence, nous travaillons pour que la session soit sortie du processus et que la date de test et, espérons-le, de déploiement, approche. J'aimerais tirer parti de l'expérience de personnes utilisant l'équilibrage intégré de la charge dans Windows par rapport à une solution telle que Baracudda, Coyote Point, F5, etc. p>

pensées et conseils appréciés à l'avance ...

Answer 1

J'ai une certaine expérience des solutions d'équilibrage de la charge, mais cela dépend vraiment de la conception de votre réseau et de vos logiciels afin de déterminer celle qui vous convient le mieux.

En termes de solutions que j'ai rencontrées:

L'équilibrage de charge intégré à Windows fonctionne bien dans la plupart des cas, mais vous devez vous assurer que vos applications peuvent gérer les sessions correctement si elles ne sont pas figées. etc.

J'ai utilisé les produits F5, principalement en tant que solution de mise en cache, mais ils étaient trop complexes pour nous. Nous sommes en train de les quitter, car les développeurs ne les utilisaient pas correctement car ils étaient trop complexes. (Veuillez noter qu'il s'agissait de produits assez anciens F5.)

Nous sommes en train de tester les équilibreurs de charge matérielle de Foundry, et nous les accepterons probablement car ils s'intégreront bien à notre architecture réseau. (Ce qui est assez complexe.).

Je dirais donc que si vous souhaitez une solution simple, utilisez l'équilibrage de charge dans Windows (si vos applications fonctionnent correctement.).

Sinon, utilisez quelque chose de plus complexe.

Quel que soit l’équilibreur de charge utilisé, vous complexifiez votre architecture. Alors planifiez-le et testez-le soigneusement.

Answer 2

quelques pensées

• WLBS est souvent "assez bon". pour vous familiariser avec NLB. Cependant, comme tout bon ingénieur, vous devez "mesurer pour savoir"
.
• il ne s’agit pas seulement d’agrandir l’échelle, mais aussi de redondance douce ou matérielle. Nous effectuons souvent des NLB entre ordinateurs virtuels simplement pour nous permettre une redondance progressive.
• NLB s’applique aussi bien aux réseaux frontaux qu’aux réseaux frontaux
• accélérer l'accélération matérielle vous apporte un nouveau degré de coûts d'exploitation. Nouvelle formation, assistance spécialisée, escalade, etc.
• recherchez une accélération matérielle qui vous donnera beaucoup plus que NLB, par exemple. Protection DDoS, SSL, Compression, Mise en cache, Changement de contenu, Agrégation de connexion, Mise en mémoire tampon.
• éduquer les deux développeurs & amp; Ops SE sur les avantages de l'accélération matérielle, une bonne conception peut fusionner la ligne entre les opérations réseau et le développement d'applications.
• la mise en mémoire tampon matérielle à elle seule a rendu notre ASP.NET environ 30% plus rapide en réduisant simplement le temps que nous passons en GC.
• la commutation de contenu peut vous permettre de fusionner ou de migrer de manière transparente des systèmes disparates. Nous avons fusionné MSDN & amp; MSDN2 dans une seule URL en utilisant cette technique.
• la durée de la session est une arme à double tranchant - utilisez avec parcimonie - encore une fois, aucun substitut pour une bonne ingénierie - mesurez et testez tout

Nous utilisons à la fois WLBS et NLB au sein de notre réseau - les coûts sont souvent le moteur de la conversation. Traitez les deux comme des outils dans la boîte à outils, découvrez leurs nuances, leurs modèles de coûts, etc.

Answer 3

configurer un cluster apache mod_proxy. http://www.howtoforge.com/high_availability_loadbalanced_apache_cluster

plus facile que vous ne le pensez, et à une fraction du prix

Answer 4

F5 est livré avec une puce d’accélération SSL. Cryptage SSL & amp; Le décryptage (nécessitant beaucoup de ressources en processeur) en utilisant les serveurs d’applications leur permet de ralentir le traitement des demandes réelles. En général, le trafic SSL est terminé à la position F5 et le trafic http normal est envoyé aux serveurs d'applications. Cela s'appelle déchargement SSL au niveau de l'équilibreur de charge. Sinces F5 fait cela Cryptage SSL & amp; Le décryptage à l'aide d'une puce (matériel) est 30 à 40 fois plus rapide que le cryptage normal & amp; temps de décryptage.