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

nginx:

• ssl: oui
• compresse: oui
• cache: oui
• piscine principale: oui

vernis:

• ssl: non (stunnel?)
• compresse:?
• cache: oui (fonctionnalité principale)
• piscine principale: oui

haproxy:

• ssl: no (stunnel)
• compresse:?
• cache: non
• pool principal: oui (fonctionnalité principale)

L'intention de chaîner tous ces éléments devant vos serveurs Web principaux est-elle simplement destinée à tirer parti de certains de leurs principaux avantages?

Il semble assez fragile que tant de démons affluent pour faire des choses similaires.

Quelles sont vos préférences en matière de déploiement et de commande et pourquoi?

Tout simplement..

HaProxy est le meilleur équilibreur de charge open source du marché.
Varnish est le meilleur cache statique de fichiers opensource sur le marché.
Nginx est le meilleur serveur web open source du 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 / multiple nginx.
La seule différence est que vous "verrouillez" le vernis pour les demandes 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 commence par frapper le cache de vernis (bon, c'est rapide)
• toute requête dynamique va directement au backend (super, le vernis ne s'habitue pas)

Globalement, ce modèle s’adapte à une architecture évolutive et en pleine croissance (utilisez haproxy si vous n’avez pas plusieurs serveurs)

J'espère que cela aide: D

Remarque: je vais également vous présenter les requêtes Pound for SSL: D
Vous pouvez avoir un serveur dédié au déchiffrement des requêtes SSL et à la transmission des requêtes standard à la pile principale: D (La pile entière est exécutée plus rapidement et plus facilement)

Avant-propos

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

Sauf indication contraire, les éléments suivants sont destinés aux professionnels du secteur des entreprises et des start-ups, qui assistent des milliers, voire des millions d'utilisateurs.

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

En règle générale, rappelez-vous que vous voulez garder les choses simples . Chaque middleware ajouté est un autre composant essentiel à maintenir. La perfection n'est pas atteinte lorsqu'il n'y a rien à ajouter mais lorsqu'il ne reste plus rien à enlever.

Quelques déploiements communs et intéressants

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

Le serveur web est nginx sous php. Quand 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) + Varnish (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 vers l'hôte et la mise en cache) + Webserver (application)

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

Remarque : La redirection de port 443: 8080 est en cours mais ne fait pas partie des fonctionnalités. Il est inutile de faire la redirection de port. L’équilibreur de charge peut s’adresser 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 :

• Equilibrage de charge (TCP, HTTP, HTTPS)
• Algorithmes multiples (round robin, source ip, en-têtes)
• Persistance de session
• Résiliation 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 dans le monde entier (DNS, anycast, CloudFlare)

Qu'est-ce que HAProxy fait et quand devez-vous l'utiliser?
Chaque fois que vous avez besoin d'équilibrer la charge. HAProxy est la solution idéale.

Sauf si vous voulez vraiment pas cher ou rapide et sale ou vous n'avez pas les compétences disponibles, alors vous pouvez utiliser un ELB: D

Sauf si vous êtes dans le secteur bancaire / gouvernement / similaire, vous devez utiliser votre propre centre de données avec des exigences strictes (infrastructure dédiée, basculement fiable, 2 couches de pare-feu, audits, SLA pour payer x% par minute d'indisponibilité, le tout en un). vous pouvez placer 2 F5 au-dessus du rack contenant vos 30 serveurs d'applications.

Sauf si vous voulez dépasser 100k HTTP (S) [et plusieurs sites], vous DEVEZ avoir plusieurs HAProxy avec une couche d'équilibrage de charge [global] devant eux (cloudflare, DNS, anycast). Théoriquement, l’équilibreur global pourrait parler directement aux serveurs Web, ce qui permettrait d’abandonner HAProxy. Cependant, généralement, vous DEVEZ garder HAProxy (s) en tant que point (s) d’entrée public vers votre centre de données et ajuster les options avancées pour équilibrer équitablement les hôtes et minimiser la variance.

Opinion personnelle : Un petit projet open source, confiné, entièrement dédié à UN VRAI OBJECTIF. Parmi la configuration la plus facile (fichier ONE), 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 :

• Serveur Web HTTP ou HTTPS
• Exécuter des applications en CGI / PHP / autres
• Redirection / réécriture d'URL
• Contrôle d'accès
• Manipulation des en-têtes HTTP
• Caching
• Proxy inverse

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

Apache était le serveur Web de facto, également connu sous le nom de cluster géant de dizaines de modules et de milliers de lignes httpd.confau-dessus d’une architecture de traitement de requêtes en panne. Nginx refait tout cela, avec moins de modules, une configuration (un peu) 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 également utiliser toutes ses fonctionnalités.

Sauf si votre application n'est pas destinée à s'exécuter sur nginx et que nginx ne figure nulle part dans votre pile (Java shop any?), Il ne sert à rien d'avoir nginx. Les fonctionnalités des serveurs Web sont susceptibles d'exister sur votre serveur Web actuel et les autres tâches sont mieux gérées par l'outil dédié approprié (HAProxy / Varnish / CDN).

Sauf si votre serveur Web / votre application manque de fonctionnalités, qu'il est difficile de le configurer et / ou que vous préférez ne pas l'examiner (n'importe qui?), Vous pouvez placer un nginx devant (localement sur chaque nœud) pour effectuer l'URL réécrire, envoyer des redirections 301, appliquer le contrôle d'accès, fournir un cryptage SSL et éditer les en-têtes HTTP à la volée. [Ce sont les fonctionnalités attendues d'un serveur Web]

Varnish: LE serveur de cache

Caractéristiques principales :

• Caching
• Mise en cache avancée
• Mise en cache grain fin
• Caching

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

Que fait Varnish et quand dois-tu l'utiliser?
Il met en cache, uniquement en cache. Cela ne vaut généralement pas la peine et c'est une perte de temps. Essayez CDN à la place. Sachez que la mise en cache est la dernière chose à laquelle vous devez prêter attention lorsque vous exploitez un site Web.

Sauf si vous exploitez un site Web exclusivement consacré aux images ou aux vidéos, vous devez examiner le CDN de manière approfondie et envisager sérieusement la mise en cache.

Sauf si 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 ne sont pas en mesure de fournir des fichiers statiques (l'ajout de nouveaux serveurs Web n'est pas utile), alors Varnish est le dernier recours.

Sauf si vous avez un site avec un contenu principalement statique, mais complexe, généré dynamiquement (voir les paragraphes suivants), Varnish peut économiser beaucoup de puissance de traitement sur vos serveurs Web.

La mise en cache statique est surestimée en 2016

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

Tous ces services fonctionnent immédiatement pour les fichiers static * .css * .js * .png et plus. En fait, ils respectent la Cache-Controldirective dans l'en-tête HTTP. La première étape de la mise en cache consiste à configurer vos serveurs Web pour qu'ils envoient les directives de cache appropriées. Peu importe quel CDN, quel vernis, quel navigateur est au milieu.

Considérations de performance

Varnish a été créé à une époque où la plupart des serveurs Web étaient sur le point de servir une image de chat sur un blog. De nos jours, une seule instance du serveur Web moderne multithread basé sur des mots à la mode asynchrones peut livrer de manière fiable des chatons à tout un pays. Gracieuseté de sendfile().

J'ai effectué des tests de performance rapides pour le dernier projet sur lequel j'ai travaillé. Une seule instance de tomcat peut traiter 21 000 à 33 000 fichiers statiques par seconde via HTTP (test des fichiers de 20 à 12 Ko avec un nombre de connexions HTTP / client variable). Le trafic sortant maintenu dépasse 2,4 Gb / s. La production n'aura que des interfaces 1 Gb / s. Ne peut pas faire mieux que le matériel, inutile d'essayer Varnish.

Mise en cache complexe Modification du contenu dynamique

CDN et les serveurs de mise en cache ignorent généralement les URL avec des paramètres tels que ?article=1843, ils ignorent toutes les requêtes avec des cookies de session ou des utilisateurs authentifiés, et la plupart des types MIME, y compris application/jsonfrom /api/article/1843/info. Il y a des options de configuration disponibles mais généralement pas à grain fin, plutôt "tout ou rien".

Varnish 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 de l'utilisateur actuel, ainsi que le type et le contenu MIME ALL TOGETHER. Cela peut économiser beaucoup de puissance de traitement sur les serveurs Web pour un modèle de charge très spécifique. C'est à ce moment que Varnish est pratique et génial.

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 être assez long (6 heures pour écrire. OMG!: O). Peut-être que je devrais commencer un blog ou un livre à ce sujet. Fait amusant: Il ne semble pas y avoir de limite à la longueur de la réponse.

C'est vrai que les 3 outils partagent des fonctionnalités communes. La plupart des configurations conviennent à toutes les combinaisons de 2 parmi 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 installez des dizaines ou des centaines de serveurs et que vous ne vous souciez pas d'en tirer le meilleur parti, ni de résoudre les problèmes. Il est courant de sacrifier certaines fonctionnalités de serveur Web si vous souhaitez exécuter une application distribuée avec de nombreux composants partout. Pourtant, certaines personnes construisent des fermes intéressantes avec toutes.

Vous devriez 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 de SSL avant, alors nginx en tant que proxy inverse convient. Si vous n'en avez pas besoin, le vernis sur le recto convient parfaitement. Ensuite, vous pouvez mettre haproxy pour équilibrer la charge de vos applications. Parfois, vous aimerez également basculer vers différentes batteries de serveurs sur haproxy, en fonction du type de fichier ou du chemin d'accès.

Parfois, vous devrez vous protéger contre les attaques DDoS lourdes, et haproxy en face conviendra mieux que les autres.

En règle générale, vous ne devez pas vous inquiéter des compromis à faire entre vos choix. Vous devez choisir comment les assembler pour obtenir la meilleure flexibilité possible pour vos besoins actuels et futurs. Même si vous en empilez plusieurs fois plusieurs fois, cela peut parfois s'avérer juste en fonction de vos besoins.

En espérant que cela aide!

Toutes les autres réponses datent d'avant 2010, ce qui ajoute une comparaison mise à jour.

Nginx

• Un serveur Web complet, d'autres fonctionnalités peuvent également être utilisées. Ex: 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 la mise en cache Near Varnish
• Performances d'équilibrage de charge proches de HAProxy

Vernis

• convient parfaitement aux scénarios de mise en cache complexes et à l'intégration aux applications.
• meilleur fichier statique cacher
• Pas de support SSL
• Mémoire et mangeur de CPU

Haproxy

• meilleur équilibreur de charge, pour des fonctionnalités d'équilibrage de charge de pointe, comparables aux équilibreurs de charge matériels
• SSL est supporté depuis la version 1.5.0
• Plus simple, étant simplement un proxy TCP sans implémentation http, ce qui le rend plus rapide et moins sujet aux bogues.

La meilleure méthode semble donc les mettre en œuvre dans un ordre approprié.

Toutefois, pour un usage général, Nginx est préférable car vous obtenez des performances supérieures à la moyenne pour tous: mise en cache, reverse proxy, équilibrage de charge , avec très peu de frais généraux pour l'utilisation des ressources. Et puis vous avez SSL et les fonctionnalités du serveur Web complet.

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 faire en sorte que nginx accepte les connexions SSL et leur proxy pour vernir, puis demandez à vernis de parler à nginx via http.

Certaines personnes peuvent ajouter nginx (ou Apache) dans la composition, car il s’agit là d’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 de l'un d'entre eux, car Varnish ne peut pas le faire lui-même. Certaines personnes sont peut-être plus familiarisées avec la configuration de ces outils. Il est donc plus facile d'utiliser Varnish en tant que cache simple et d'effectuer l'équilibrage de la charge sur une autre couche, car ils maîtrisent déjà Apache / nginx / haproxy en tant qu'équilibreur de charge.