Avant-propos

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 du monde des affaires et aux jeunes entreprises, et prend en charge des milliers ou des millions d'utilisateurs.

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

En règle générale, rappelez-vous que vous voulez rester simple . Chaque intergiciel ajouté est un autre élément critique à maintenir. La perfection n'est pas atteinte lorsqu'il n'y a rien à ajouter, mais lorsqu'il n'y a plus rien à enlever.

Quelques déploiements courants et intéressants

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

Le serveur web est nginx et fonctionne avec php. Quand nginx est déjà là, il peut 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 requête (*.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 mise en cache) + Webserver (application)

Les serveurs ne parlent pas SSL alors que TOUT LE MONDE DOIT PARLER SSL ( en particulier ce lien HAProxy-WebServer avec des informations d'utilisateur privées passant par EC2 ). L'ajout d'un nginx local permet d'amener le SSL jusqu'à l'hôte. Une fois que nginx est là, il peut aussi faire un peu de cache et de réécriture d'URL.

Note : La redirection du port 443:8080 se produit mais ne fait pas partie des fonctionnalités. Il n'y a aucun intérêt à faire une redirection de port. L'équilibreur de charge pourrait 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 des charges (TCP, HTTP, HTTPS)
• Algorithmes multiples (round robin, ip source, headers)
• Persistance de la session
• Résiliation du SSL

Alternatives similaires nginx (serveur web polyvalent pouvant être configuré comme un équilibreur de charge)
Différentes alternatives : Cloud (Amazon ELB, Google load balancer), Hardware (F5, fortinet, citrix netscaler), Other&Worldwide (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 à retenir.

Sauf si vous voulez un produit très bon marché OU rapide et sale OU si vous n'avez pas les compétences nécessaires, alors vous pouvez utiliser un ELB :D

Sauf si vous êtes dans le secteur bancaire, gouvernemental ou similaire et que vous devez utiliser votre propre centre de données avec des exigences strictes (infrastructure dédiée, basculement fiable, 2 couches de pare-feu, audit, accord de niveau de service pour payer x% par minute de temps d'arrêt, tout en un), vous pouvez mettre 2 F5 au-dessus du rack contenant vos 30 serveurs d'application.

Sauf si vous voulez dépasser les 100k HTTP(S) [et les multi-sites], vous DEVEZ avoir multiples HAProxy avec une couche d'équilibrage de charge [global] en amont (cloudflare, DNS, anycast). En théorie, l'équilibreur global pourrait parler directement aux serveurs Web, ce qui permettrait de se passer de HAProxy. Cependant, en général, vous DEVRIEZ garder HAProxy(s) comme point(s) d'entrée public(s) dans votre centre de données et régler les options avancées pour équilibrer équitablement entre les hôtes et minimiser la variance.

Opinion personnelle : Un petit projet, contenu, open source, entièrement dédié à UN VRAI BUT. Parmi les logiciels open source les plus faciles à configurer (UN seul fichier), les plus utiles et les plus fiables que j'ai rencontrés dans ma vie.

Nginx : Un 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
• Mise en cache
• Proxy inversé

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

Apache était le serveur web de facto, également connu comme un gigantesque clusterfuck de dizaines de modules et de milliers de lignes. httpd.conf 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 utiliser toutes ses fonctionnalités.

Sauf si votre application n'est pas destinée à fonctionner sur nginx et que nginx ne se trouve nulle part dans votre pile (Java shop quelqu'un ?) alors il n'y a pas grand intérêt à utiliser 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 web/application manque de fonctionnalités, qu'il est difficile à configurer et/ou que vous préférez mourir plutôt que de le regarder (Gunicorn quelqu'un ?), alors vous pouvez mettre un nginx devant (c'est-à-dire localement sur chaque nœud) pour effectuer la réécriture d'URL, envoyer des redirections 301, renforcer le contrôle d'accès, fournir un 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 cache)
Différentes alternatives : CDN (Akamai, Amazon CloudFront, CloudFlare), Matériel (F5, Fortinet, Citrix Netscaler)

A quoi sert le vernis et quand faut-il l'utiliser ?
Il fait du cache, seulement du cache. Cela ne vaut généralement pas la peine et c'est une perte de temps. Essayez plutôt le CDN. Sachez que la mise en cache est la dernière chose dont vous devez vous préoccuper lorsque vous gérez un site Web.

Sauf si vous exploitez un site Web exclusivement consacré aux images ou aux vidéos, vous devez étudier de près les CDN et réfléchir sérieusement à la mise en cache.

Sauf lorsque vous êtes contraint d'utiliser votre propre matériel dans votre propre centre de données (le CDN n'est pas une option) et que vos serveurs web ne parviennent pas à livrer des fichiers statiques (ajouter des serveurs web supplémentaires n'aide pas), Varnish est le dernier recours.

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

La mise en cache statique est surestimée en 2016

La mise en cache est presque sans configuration, sans argent et sans temps. Il suffit de s'abonner à CloudFlare, ou CloudFront ou Akamai ou MaxCDN. Le temps qu'il me faut pour écrire cette ligne est plus long que le temps qu'il faut 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 fonctionnent d'emblée pour les fichiers statiques *.css *.js *.png et autres. En fait, ils honorent surtout le Cache-Control dans l'en-tête HTTP. La première étape de la mise en cache consiste à configurer vos serveurs web pour qu'ils envoient des directives de cache appropriées. Peu importe quel CDN, quel Varnish, quel navigateur se trouve au milieu.

Considérations sur les performances

Varnish a été créé à une époque où les serveurs web moyens s'étouffaient pour servir une photo de chat sur un blog. Aujourd'hui, une seule instance d'un serveur web moderne, asynchrone et multithread, alimenté par des mots à la mode, peut servir de manière fiable des chatons à un pays entier. Avec l'aimable autorisation de sendfile() .

J'ai effectué quelques tests de performance rapides pour le dernier projet sur lequel j'ai travaillé. Une seule instance de Tomcat pouvait servir 21 000 à 33 000 fichiers statiques par seconde sur HTTP (en testant des fichiers de 20B à 12kB avec un nombre variable de connexions HTTP/client). Le trafic sortant soutenu est supérieur à 2,4 Gb/s. La production n'aura que des interfaces à 1 Gb/s. On ne peut pas faire mieux que le matériel, il est inutile d'essayer Varnish.

Mise en cache d'un contenu dynamique complexe et changeant

Les serveurs CDN et de mise en cache ignorent généralement les URL contenant des paramètres tels que ?article=1843 ils ignorent toute requête contenant des cookies de session ou des utilisateurs authentifiés, et ils ignorent la plupart des types MIME, y compris le format application/json von /api/article/1843/info . Il existe des options de configuration, mais elles ne sont généralement pas très fines, plutôt du type "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 et type MIME et contenu TOUS ENSEMBLE. Cela peut économiser beaucoup de puissance de traitement sur les serveurs web pour certains modèles de charge très spécifiques. C'est à ce moment-là 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'assemblent. J'espère que cela pourra vous aider.

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

Il est vrai que ces trois outils ont des caractéristiques communes. La plupart des configurations sont parfaites avec n'importe quelle combinaison de 2 parmi les 3. Cela dépend de leur objectif principal. Il est courant d'accepter de sacrifier un peu de cache si vous savez que votre serveur d'application est rapide en statique (ex : nginx). Il est courant de sacrifier certaines fonctions d'équilibrage de charge si vous comptez installer 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 des serveurs 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 tous ces serveurs.

Vous devez garder à l'esprit que vous parlez de 3 produits solides. En général, vous n'aurez pas besoin de les équilibrer. Si vous avez besoin d'un SSL frontal, alors nginx en premier lieu comme reverse-proxy est parfait. Si vous n'en avez pas besoin, alors varnish sur le front est parfait. Vous pouvez ensuite utiliser haproxy pour équilibrer la charge de vos applications. Parfois, vous souhaiterez également basculer vers différentes fermes de serveurs sur le haproxy lui-même, en fonction des types de fichiers ou des chemins.

Parfois, vous devrez vous protéger contre de lourdes attaques DDoS, et haproxy en tête sera plus adapté que les autres.

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

J'espère que cela vous aidera !

Toutes les autres réponses sont antérieures à 2010, d'où l'ajout d'une comparaison actualisée.

Nginx

• Un serveur web complet, d'autres fonctionnalités peuvent également être utilisées. Ex : HTTP Compression
• Support 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 proches de celles de Varnish
• Performances proches de celles de l'équilibrage de charge HAProxy

Vernis

• meilleur pour les scénarios complexes de mise en cache et l'intégration avec les applications.
• le meilleur cacheur de fichiers statiques
• Pas de support SSL
• Dévoreur de mémoire et de CPU

Haproxy

• meilleur équilibreur de charge, pour des fonctions d'avant-garde d'équilibrage de charge, comparable à équilibreurs de charge matériels
• SSL est supporté depuis la version 1.5.0
• Plus simple, puisqu'il s'agit d'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 mettre toutes en œuvre dans un ordre approprié.

Toutefois, pour pour un usage général, Nginx est le meilleur car vous obtenez des performances supérieures à la moyenne pour tous : Mise en cache, Proxys inversés, Équilibrage de charge avec une très faible surcharge sur l'utilisation des ressources. Et puis vous avez SSL et des fonctionnalités complètes de serveur web.

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

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

Je configurerais simplement cela avec varnish + stunnel. Si j'avais besoin de nginx pour une autre raison, j'utiliserais simplement nginx + varnish. Vous pouvez faire en sorte que nginx accepte les connexions SSL et les transmette par proxy à varnish, puis que varnish parle à nginx via http.

Certaines personnes peuvent ajouter nginx (ou Apache) au mélange parce que ce sont des outils un peu plus généraux que Varnish. Par exemple, si vous souhaitez transformer du contenu (en utilisant XDV, des filtres Apache, etc.) au niveau du proxy, vous aurez besoin de l'un de ces outils, 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 simple cache et de faire l'équilibrage de charge à une autre couche parce qu'elles sont déjà familières avec Apache/nginx/haproxy comme équilibreur de charge.