Comment puis-je équilibrer le trafic Web entrant entre les serveurs N apache?

Je cherche à utiliser quelque chose comme Heartbeat / Squid / Varnish / etc pour équilibrer la quantité de trafic entrant parmi les instances internes d'Apache. Il faudrait que ce soit un logiciel et non du matériel, car tous mes trucs sont exécutés sur VPS. Je n'ai pas beaucoup d'expérience dans ce domaine, donc désolé si j'utilise mal la terminologie et que je choisis les mauvais paquets.

J'ai rédigé quelque chose pour illustrer ce que je recherche. Le côté vert est à quoi ressemblerait la configuration initiale et le côté bleu à quoi il pourrait ressembler après avoir ajouté plus d'instances Apache en raison de l'augmentation du trafic. Ce n'est peut-être pas ainsi que ces choses fonctionnent, mais idéalement, j'ajouterais l'IP du ou des équilibreurs au DNS du domaine. Ensuite, le ou les équilibreurs verraient le nombre de connexions sur chaque instance d'apache (via une liste de configuration d'IP internes ou d'éternelles IP) et répartir les connexions de manière égale. Dans le bleu, il y a un deuxième équilibreur car je suis sûr qu'à un moment donné, l'équilibreur aurait également besoin d'aide.

Je me trompe peut-être, mais je cherche de l'aide sur ce que devraient être les "balancer (s)" et les meilleures pratiques pour les configurer.

Toute aide est la bienvenue.

À peu près n'importe quel "proxy inverse" fera ce que vous demandez.

Par exemple, Varnish, Pound et HAProxy sont tous bons dans ce qu'ils font, mais ils ont aussi leurs différences - cependant, pour ce que vous demandez, chacun d'eux fera l'affaire. Personnellement, je pense que vous feriez mieux avec HAProxy, mais ce n'est qu'une supposition.

Vous feriez mieux de lire un article sur les équilibreurs de charge pour vous aider à décider de quel type vous avez besoin: http://1wt.eu/articles/2006_lb/

En outre, vous pourriez envisager d'utiliser un service préconfiguré pour cela - comme exécuter votre logiciel sur Elastic Compute Cloud d'Amazon et utiliser leur équilibrage de charge élastique.

Au début, il y a une question importante à laquelle il faut répondre:
avez-vous besoin que les sessions utilisateur soient gérées par le ou les équilibreurs de charge et toujours dirigées vers le même serveur Web (s'il est actif)?

• sessions non requises : dans ce cas, vous devez utiliser le programme nginx efficace comme équilibreur de charge. La configuration est facile à définir, où vous n'avez qu'à indiquer la liste des serveurs Web dans une upstream upstream_name { server1, ..., serverN }déclaration, puis, pour un domaine donné, vous avez besoin d'une proxy_pass upstream_namedirective simple .
  Voir le wiki Nginx .

• session requise il existe un paramètre similaire pour pound où vous indiquez le nom du cookie qui hébergera l'ID de session ( ID MYCOOKIENAME), puis une liste de BACKENDpour tous vos serveurs.
  Voir par exemple l' exemple de configuration de Pound .

Lorsque le besoin de plusieurs équilibreurs de charge se fait sentir, vous pouvez opter pour une heartbeatconfiguration qui garantira qu'un seul équilibreur monte l'IP virtuelle pour un domaine donné (si des sessions sont nécessaires ou montez les deux et alimentez DNS avec deux adresses IP pour exemple). Peut-être que cela devrait être détaillé dans une autre question au moment où cela devient nécessaire (car les outils évoluent rapidement).
Voir aussi ce lien par exemple.

Vous devriez avoir besoin d'une très bonne raison pour introduire une complexité supplémentaire et un point de défaillance unique dans votre architecture.

Équilibrage de charge Round-Robin

• ne coûte rien
• est simple à mettre en œuvre et à gérer
• implémente le basculement sur le client - le seul endroit où l'échec peut être détecté de manière fiable
• prend en charge implicitement l'affinité du serveur mais permet toujours le basculement sans les problèmes de gestion de session associés aux sessions persistantes
• ne nécessite aucun logiciel / matériel / configuration supplémentaire sur les nœuds de cluster

Cela m'étonne de la quantité d'informations erronées concernant le tourniquet. Si j'étais une personne cynique, je me demanderais s'il existe un lien avec les fournisseurs qui produisent un gros matériel d'équilibrage de charge coûteux.

Le seul point que je vais concéder est que

1. Les adresses IPV4 deviennent rares et donc chères - mais toujours beaucoup. beaucoup moins cher que de dire un CSS Cisco.

2. De plus en plus, Internet fonctionne sur des services Web - et tous les développeurs n'implémentent pas la prise en charge DNS selon les spécifications . Mais chaque navigateur que j'ai utilisé fonctionne comme il se doit

commencez votre quête ici: http://httpd.apache.org/docs/2.1/mod/mod_proxy_balancer.html et http://www.barneyb.com/barneyblog/2009/02/26/apache-httpds-mod_proxy_balancer/

Pour les équilibreurs, vous pouvez consulter LVS sur http://www.linuxvirtualserver.org/ , en exécutant peut-être ldirectord et heartbeat pour diriger le trafic et effectuer le basculement.

Nginx est génial comme proxy en amont, je l'ai utilisé avec grand succès dans une configuration faisant 1M + uniques par jour

OK, cela a été demandé il y a quelque temps, et je suis en retard à la fête. Pourtant, il y a quelque chose à ajouter ici.

Jackie, tu l'as à peu près compris. Votre illustration montre comment l'équilibrage de charge est géré sur la plupart des installations plus petites et moyennes.

Vous devriez lire l' introduction à l'équilibrage de charge de Willy Tarreau à laquelle Nakedible est lié. C'est toujours valable et c'est une bonne introduction.

Vous devez considérer comment ceux-ci répondent à vos besoins:

• Équilibreurs de charge de niveau TCP / IP (Linux Virtual Server et al). Le plus bas par surcharge de connexion, la vitesse la plus élevée, ne peut pas "voir" HTTP.
• Équilibreurs de charge de niveau HTTP (HAProxy, nginx, Apache 2.2, Pound, Microsoft ARR, etc.). Une surcharge plus élevée, peut voir HTTP, peut gzip HTTP, peut faire SSL, peut faire un équilibrage de charge de session collante.
• Proxys inverses HTTP (Apache Traffic Server, Varnish, Squid). Peut stocker des objets pouvant être mis en cache (certaines pages Web, css, js, images) dans la RAM et les transmettre aux clients suivants sans impliquer le serveur Web principal. Peut souvent faire les mêmes choses que les équilibreurs de charge HTTP L7.

il y a un deuxième équilibreur car je suis sûr qu'à un moment donné, l'équilibreur aurait aussi besoin d'aide.

Et bien certainement. Mais l'équilibrage de charge est simple, et souvent un seul équilibreur de charge peut aller vite . Je renvoie à cet article, qui a frappé un nerf sur le Web, comme juste un exemple de la performance que peut fournir un seul serveur moderne . N'utilisez pas plusieurs LB avant d'en avoir besoin. Lorsque vous avez besoin d'une approche commune, les équilibreurs de charge de niveau IP sont tout de suite (ou DNS Round Robin), les équilibreurs de charge de niveau HTTP, les serveurs proxy et les applications Web.

aide sur ce que devraient être les «équilibreurs» et les meilleures pratiques pour les configurer.

Le problème est la gestion de l'état de session et, dans une certaine mesure, le comportement de l'état d'échec. La configuration des équilibreurs de charge eux-mêmes est relativement simple.

Si vous utilisez simplement 2 à 4 serveurs Webapp backend, le hachage statique basé sur l'adresse IP d'origine peut être viable. Cela évite d'avoir besoin d'un état de session partagé entre les serveurs Webapp. Chaque nœud d'application Web voit 1 / N du trafic global, et le mappage client-serveur est statique en fonctionnement normal. Ce n'est pas un bon ajustement pour une installation plus grande.

Les deux meilleurs algorithmes d'équilibrage de charge, en ce sens qu'ils ont un comportement bénin sous une charge élevée et même une distribution de charge, sont le round robin et le véritable équilibrage de charge aléatoire. Les deux nécessitent que l'état de session globale de votre application Web soit disponible sur les nœuds d'application Web. La façon dont cela se fait dépend de la pile technologique de l'application Web; mais il existe généralement des solutions standard disponibles pour cela.

Si ni le hachage statique, ni l'état de session partagée ne vous conviennent, alors le choix est généralement l' équilibrage de charge « session persistante » et l'état de session par serveur. Dans la plupart des cas, cela fonctionne bien et c'est un choix entièrement viable.

le ou les équilibreurs verraient le nombre de connexions sur chaque instance d'apache (via une liste de configuration d'IP internes ou d'éternelles IP) et répartir les connexions de manière égale

Oui, certains sites l'utilisent. Il existe de nombreux noms pour les nombreux algorithmes d'équilibrage de charge différents qui existent. Si vous pouvez choisir le tournoi à la ronde ou aléatoire (ou le tournoi à la ronde pondéré, pondéré au hasard), je vous recommanderais de le faire, pour les raisons indiquées ci-dessus.

Dernière chose: n'oubliez pas que de nombreux fournisseurs (F5, Cisco et autres sur les technologies haut de gamme, fx Coyote Point et Kemp à des prix plus raisonnables) proposent des appliances d'équilibrage de charge matures .