Commande: 1. nginx 2. vernis 3. haproxy 4. serveur web?

Question

J'ai vu des gens recommander de combiner tous ces éléments dans un flux, mais ils semblent avoir beaucoup de fonctionnalités qui se chevauchent.J'aimerais donc comprendre pourquoi vous voudrez peut-être passer par 3 programmes différents avant de frapper votre serveur Web réel.

nginx:

ssl: oui
compresser: oui
cache: oui
pool principal: oui

vernis:

ssl: non (stunnel?)
compresser:?
cache: oui (fonctionnalité principale)
pool principal: oui

haproxy:

ssl: non (stunnel)
compresser:?
cache: non
pool principal: oui (fonctionnalité principale)

L'intention est-elle de chaîner tous ces éléments devant vos principaux serveurs Web uniquement pour bénéficier de certains de leurs principaux avantages?

Il semble assez fragile d'avoir autant de démons qui coulent ensemble pour faire des choses similaires.

Quelle est votre préférence de déploiement et de commande et pourquoi?

Arenstar · Accepted Answer

Tout simplement..

HaProxy est le meilleur équilibreur de charge open source sur le marché.
Vernis est le meilleur cache de fichiers statiques open source sur le marché.
Nginx est le meilleur serveur Web open source sur le marché.

(bien sûr, c'est mon opinion et celle de beaucoup d'autres peuples)

Mais généralement, toutes les requêtes ne passent pas par la pile entière.

Tout passe par haproxy et nginx/plusieurs nginx.
La seule différence est que vous "boulonnez" le vernis pour les requêtes statiques.

toute demande est équilibrée en charge pour la redondance et le débit (bon, c'est une redondance évolutive)
toute demande de fichiers statiques atteint d'abord le cache de vernis (bon, c'est rapide)
toute demande dynamique va directement au backend (super, le vernis n'est pas utilisé)

Globalement, ce modèle s'adapte à une architecture évolutive et croissante (supprimez le haproxy si vous n'avez pas plusieurs serveurs)

J'espère que cela vous aidera: D

Note: Je vais également introduire également les requêtes Pound for SSL: D
.

user5994461 · Answer

Préface

Mise à jour en 2016. Les choses évoluent, tous les serveurs s'améliorent, ils prennent tous en charge SSL et le Web est plus étonnant que jamais.

Sauf indication contraire, ce qui suit s'adresse aux professionnels des entreprises et des start-ups, prenant en charge des milliers à des millions d'utilisateurs.

Ces outils et architectures nécessitent beaucoup d'utilisateurs/matériel/argent. Vous pouvez essayer cela dans un laboratoire à domicile ou pour gérer un blog, mais cela n'a pas beaucoup de sens.

En règle générale, n'oubliez pas que vous voulez rester simple . Chaque middleware ajouté est un autre élément essentiel du middleware à maintenir. La perfection n'est pas atteinte quand il n'y a rien à ajouter mais quand il n'y a plus rien à supprimer.

Quelques déploiements courants et intéressants

HAProxy (équilibrage) + nginx (application php + mise en cache)

Le serveur Web exécute php sur nginx. Lorsque nginx est déjà là, il pourrait tout aussi bien gérer la mise en cache et les redirections.

HAProxy ---> nginx-php A ---> nginx-php P ---> nginx-php r ---> nginx-php o ---> nginx-php x ---> nginx-php y ---> nginx-php

HAProxy (équilibrage) + Vernis (mise en cache) + Tomcat (application Java)

HAProxy peut rediriger vers Varnish en fonction de l'URI de la demande (* .jpg * .css * .js).

HAProxy ---> Tomcat A ---> Tomcat ---> Tomcat P ---> Tomcat <----+ r ---> Tomcat <---+| o || x ---> varnish <--+| y ---> varnish <---+

HAProxy (équilibrage) + nginx (SSL à l'hôte et mise en cache) + Webserver (application)

Les serveurs Web ne parlent pas SSL même si TOUT LE MONDE DOIT PARLER SSL ( en particulier ce lien HAProxy-WebServer avec les informations des utilisateurs privés passant par EC2). L'ajout d'un nginx local permet d'apporter SSL à l'hôte. Une fois que nginx est là, il pourrait aussi bien faire de la mise en cache et de la réécriture d'URL.

Remarque : la redirection de port 443: 8080 se produit mais ne fait pas partie des fonctionnalités. Il est inutile de faire la redirection de port. L'équilibreur de charge peut parler directement au serveur Web: 8080.

 (nginx + webserver on same Host) HAProxy ---> nginx:443 -> webserver:8080 A ---> nginx:443 -> webserver:8080 P ---> nginx:443 -> webserver:8080 r ---> nginx:443 -> webserver:8080 o ---> nginx:443 -> webserver:8080 x ---> nginx:443 -> webserver:8080 y ---> nginx:443 -> webserver:8080

Middleware

HAProxy: L'équilibreur de charge

Caractéristiques principales :

Équilibrage de charge (TCP, HTTP, HTTPS)
Algorithmes multiples (round robin, source ip, en-têtes)
Persistance de session
Terminaison SSL

Alternatives similaires : nginx (serveur Web polyvalent configurable comme équilibreur de charge)
Différentes alternatives : Cloud (Amazon ELB, équilibreur de charge Google), Matériel (F5, fortinet, citrix netscaler), Autre et mondial (DNS, anycast, CloudFlare)

Que fait HAProxy et quand devez-vous l'utiliser?
Chaque fois que vous avez besoin d'un équilibrage de charge. HAProxy est la solution idéale.

Sauf lorsque vous voulez très bon marché OR quick & dirty OR you don ') Si vous n'avez pas les compétences disponibles, vous pouvez utiliser un ELB: D

Sauf lorsque vous travaillez dans le secteur bancaire/gouvernemental/similaire nécessitant d'utiliser votre propre centre de données avec des exigences strictes (infrastructure dédiée, basculement fiable, 2 couches de pare-feu, auditer des trucs, SLA pour payer x% par minute de temps d'arrêt, tout en un) alors vous pouvez mettre 2 F5 sur le rack contenant vos 30 serveurs d'applications.

Sauf lorsque vous voulez dépasser 100k HTTP (S) [et multi-sites], alors vous DEVEZ avoir multiples HAProxy avec une couche d'équilibrage de charge [globale] devant eux (cloudflare, DNS, anycast). Théoriquement, l'équilibreur mondial pourrait parler directement aux serveurs Web permettant d'abandonner HAProxy. Cependant, en règle générale, vous DEVEZ conserver HAProxy (s) comme point (s) d'entrée public (s) vers votre centre de données et régler les options avancées pour équilibrer équitablement les hôtes et minimiser les écarts.

Opinion personnelle : Un petit projet open source contenu, entièrement dédié à ONE TRUE PURPOSE. Parmi la configuration la plus simple (UN fichier), le logiciel open source le plus utile et le plus fiable que j'ai rencontré dans ma vie.

Nginx: Apache qui ne craint pas

Caractéristiques principales :

WebServer HTTP ou HTTPS
Exécuter des applications en CGI/PHP/un autre
Redirection/réécriture d'URL
Contrôle d'accès
Manipulation des en-têtes HTTP
Mise en cache
Proxy inverse

Alternatives similaires : Apache, Lighttpd, Tomcat, Gunicorn ...

Apache était le serveur Web de facto, également connu sous le nom d'un clusterfuck géant de dizaines de modules et de milliers de lignes httpd.conf Au-dessus d'une architecture de traitement des demandes cassée. nginx refait tout cela, avec moins de modules, une configuration (légèrement) plus simple et une meilleure architecture de base.

Que fait nginx et quand devez-vous l'utiliser?
Un serveur Web est destiné à exécuter des applications. Lorsque votre application est développée pour fonctionner sur nginx, vous avez déjà nginx et vous pouvez aussi utiliser toutes ses fonctionnalités.

Sauf lorsque votre application n'est pas destinée à s'exécuter sur nginx et que nginx ne se trouve nulle part dans votre pile (Java shop n'importe qui?), Alors il y a peu d'intérêt en nginx. Les fonctionnalités des serveurs Web sont susceptibles d'exister dans votre serveur Web actuel et les autres tâches sont mieux gérées par l'outil dédié approprié (HAProxy/Varnish/CDN).

Sauf lorsque votre serveur/application Web manque de fonctionnalités, difficile à configurer et/ou que vous préférez mourir plutôt que de le regarder (Gunicorn n'importe qui?), vous pouvez alors placer un nginx devant (c'est-à-dire localement sur chaque nœud) pour effectuer la réécriture d'URL, envoyer 301 redirections, appliquer le contrôle d'accès, fournir le cryptage SSL et modifier les en-têtes HTTP à la volée. [Ce sont les fonctionnalités attendues d'un serveur Web]

Vernis: LE serveur de mise en cache

Caractéristiques principales :

Mise en cache
Mise en cache avancée
Mise en cache à grain fin
Mise en cache

Alternatives similaires : nginx (serveur Web polyvalent configurable comme serveur de mise en cache)
Différentes alternatives : CDN (Akamai, Amazon CloudFront, CloudFlare), matériel (F5, Fortinet, Citrix Netscaler)

Que fait Varnish et quand devez-vous l'utiliser?
Il fait la mise en cache, uniquement la mise en cache. Cela ne vaut généralement pas la peine et c'est une perte de temps. Essayez plutôt CDN. Sachez que la mise en cache est la dernière chose à laquelle vous devez vous soucier lorsque vous exécutez un site Web.

Sauf lorsque vous exécutez un site Web exclusivement sur des images ou des vidéos, vous devez examiner attentivement le CDN et réfléchir sérieusement à la mise en cache.

Sauf lorsque vous êtes obligé d'utiliser votre propre matériel dans votre propre centre de données (CDN n'est pas une option) et que vos serveurs Web sont terribles pour fournir des fichiers statiques (l'ajout de serveurs Web n'aide pas), alors Varnish est le dernier recours.

Sauf lorsque vous avez un site avec un contenu généré principalement de manière statique mais complexe et dynamique (voir les paragraphes suivants), alors Varnish peut économiser beaucoup de puissance de traitement sur vos serveurs Web.

La mise en cache statique est surfaite en 2016

La mise en cache est presque sans configuration, sans argent et sans temps. Abonnez-vous simplement à CloudFlare, ou CloudFront ou Akamai ou MaxCDN. Le temps qu'il me faut pour écrire cette ligne est plus long que le temps nécessaire pour configurer la mise en cache ET la bière que je tiens dans ma main est plus chère que l'abonnement CloudFlare médian.

Tous ces services sont prêts à l'emploi pour les fichiers statiques * .css * .js * .png et plus encore. En fait, ils respectent principalement la directive Cache-Control Dans l'en-tête HTTP. La première étape de la mise en cache consiste à configurer vos serveurs Web pour envoyer des directives de cache appropriées. Peu importe le CDN, le vernis, le navigateur au milieu .

Considérations sur les performances

Le vernis a été créé à une époque où les serveurs Web moyens s'étouffaient pour diffuser une photo de chat sur un blog. De nos jours, une seule instance du serveur Web moyen multithread asynchrone moderne basé sur des mots à la mode peut fournir de manière fiable des chatons à un pays entier. Gracieuseté de sendfile() .

J'ai fait quelques tests de performance rapides pour le dernier projet sur lequel j'ai travaillé. Une seule instance de Tomcat pourrait servir de 21 000 à 33 000 fichiers statiques par seconde sur HTTP (test des fichiers de 20B à 12kB avec un nombre de connexions HTTP/client variable). Le trafic sortant soutenu dépasse 2,4 Gb/s. La production n'aura que des interfaces de 1 Gbit/s. Je ne peux pas faire mieux que le matériel, inutile de même essayer Varnish.

Complexe de mise en cache Modification du contenu dynamique

Les serveurs CDN et de mise en cache ignorent généralement l'URL avec des paramètres comme ?article=1843, Ils ignorent toute demande avec des cookies de session ou des utilisateurs authentifiés, et ils ignorent la plupart des types MIME, y compris le application/json De /api/article/1843/info. Il y a des options de configuration disponibles mais généralement pas à grain fin, plutôt "tout ou rien".

Le vernis peut avoir des règles complexes personnalisées (voir VCL) pour définir ce qui est cachable et ce qui ne l'est pas. Ces règles peuvent mettre en cache un contenu spécifique par URI, en-têtes et cookie de session utilisateur en cours et type et contenu MIME TOUS ENSEMBLE. Cela peut économiser beaucoup de puissance de traitement sur les serveurs Web pour un modèle de charge très spécifique. C'est alors que le vernis est pratique et IMPRESSIONNANT.

Conclusion

Il m'a fallu un certain temps pour comprendre toutes ces pièces, quand les utiliser et comment elles s'emboîtent. J'espère que cela peut vous aider.

Cela s'avère assez long (6 heures pour écrire. OMG!: O). Je devrais peut-être créer un blog ou un livre à ce sujet. Fait amusant: il ne semble pas y avoir de limite à la longueur de la réponse.

Willy Tarreau · Answer

Il est vrai que les 3 outils partagent des fonctionnalités communes. La plupart des configurations sont bien avec n'importe quelle combinaison de 2 parmi les 3. Cela dépend de leur objectif principal. Il est courant d'accepter de sacrifier une partie de la mise en cache si vous savez que votre serveur d'applications est rapide en statique (par exemple: nginx). Il est courant de sacrifier certaines fonctionnalités d'équilibrage de charge si vous prévoyez d'installer des dizaines ou des centaines de serveurs sans vous soucier d'en tirer le meilleur parti ni de résoudre les problèmes. Il est courant de sacrifier certaines fonctionnalités du serveur Web si vous avez l'intention d'exécuter une application distribuée avec de nombreux composants partout. Pourtant, certaines personnes construisent des fermes intéressantes avec elles toutes.

Vous devez garder à l'esprit que vous parlez de 3 produits solides. Généralement, vous n'aurez pas besoin de les équilibrer. Si vous avez besoin d'un SSL frontal, alors nginx d'abord en tant que proxy inverse est très bien. Si vous n'en avez pas besoin, le vernis sur le devant est très bien. Ensuite, vous pouvez mettre haproxy pour équilibrer la charge de vos applications. Parfois, vous aimerez également basculer vers différentes batteries de serveurs sur le haproxy lui-même, selon les types de fichiers ou les chemins d'accès.

Parfois, vous devrez vous protéger contre les attaques DDoS lourdes, et le haproxy en face sera plus adapté que les autres.

En général, vous ne devez pas vous soucier du compromis à faire entre vos choix. Vous devez choisir comment les assembler pour obtenir la meilleure flexibilité pour vos besoins actuels et futurs. Même si vous en empilez plusieurs plusieurs fois, cela peut parfois convenir selon vos besoins.

En espérant que cela aide!

beginer · Answer

Toutes les autres réponses sont antérieures à 2010, ajoutant ainsi une comparaison mise à jour.

Nginx

Un serveur Web complet, d'autres fonctionnalités peuvent également être utilisées. Par exemple: compression HTTP
Prise en charge SSL
Très léger car Nginx a été conçu pour être léger dès le départ.
Performances de mise en cache Near Varnish
Performances d'équilibrage de charge proches de HAProxy

Vernis

idéal pour les scénarios de mise en cache complexes et l'intégration avec les applications.
meilleur cache statique de fichiers
Pas de support SSL
Mémoire et mangeur de CPU

Haproxy

meilleur équilibreur de charge, pour couper les fonctions d'équilibrage de charge Edge, comparable aux équilibreurs de charge matériels
SSL est pris en charge depuis 1.5.0
Plus simple, étant juste un proxy tcp sans implémentation http, ce qui le rend plus rapide et moins sujet aux bogues.

La meilleure méthode semble donc être de les implémenter tous dans un ordre approprié.

Cependant, pour sage général, Nginx est le meilleur car vous obtenez des performances supérieures à la moyenne pour tous: Mise en cache, proxy inverse, équilibrage de charge , avec très peu de frais généraux sur l'utilisation des ressources. Et puis vous avez SSL et des fonctionnalités complètes de serveur Web.

larsks · Answer

Varnish prend en charge l'équilibrage de charge: http://www.varnish-cache.org/trac/wiki/LoadBalancing

Nginx prend en charge l'équilibrage de charge: http://wiki.nginx.org/NginxHttpUpstreamModule

Je configurerais simplement ceci avec le vernis + le stunnel. Si j'avais besoin de nginx pour une autre raison, j'utiliserais simplement nginx + vernis. Vous pouvez demander à nginx d'accepter les connexions SSL et de les proxy au vernis, puis de faire parler le vernis à nginx via http.

Certaines personnes peuvent jeter nginx (ou Apache) dans le mélange car ce sont des outils un peu plus généraux que Varnish. Par exemple, si vous souhaitez transformer du contenu (par exemple, en utilisant XDV, des filtres Apache, etc.) au niveau de la couche proxy, vous en aurez besoin, car Varnish ne peut pas le faire seul. Certaines personnes peuvent simplement être plus familières avec la configuration de ces outils, il est donc plus facile d'utiliser Varnish comme un cache simple et d'effectuer l'équilibrage de charge sur une autre couche car ils connaissent déjà Apache/nginx/haproxy comme équilibreur de charge.