NGINX est couramment utilisé comme serveur Web, mais il fait également un excellent travail en tant que proxy inverse et équilibreur de charge—un périphérique réseau conçu pour gérer la majeure partie de votre trafic et acheminer les demandes vers plusieurs serveurs Web différents.
Comment fonctionne l'équilibrage de charge NGINX
Le principe de base d'un équilibreur de charge est qu'il se situe entre l'utilisateur et un ensemble de serveurs, et qu'il transmet les requêtes pour eux. Habituellement, cela se fait avec deux serveurs ou plus, afin que le trafic puisse être réparti plus facilement entre eux.
La plupart de la configuration se produit dans la façon dont NGINX sélectionne le serveur vers lequel router. La valeur par défaut est round-robin, qui enverra les requêtes à chaque serveur dans l'ordre, garantissant une répartition de charge égale.
Cependant, ce n'est pas toujours aussi simple. De nombreuses applications Web nécessitent une certaine forme de persistance de session, ce qui signifie que l'utilisateur doit accéder au même serveur pendant toute sa session. Par exemple, un panier d'achat peut être stocké localement sur un serveur d'applications, et si l'utilisateur change de serveur en cours de session, l'application peut tomber en panne. Bien sûr, bon nombre de ces scénarios peuvent être résolus avec une meilleure infrastructure d'applications et des magasins de données centralisés, mais la persistance de session est requise par de nombreuses personnes.
Dans NGINX, l'ensemble de serveurs vers lesquels vous acheminez est appelé en amont , et est configuré comme une liste énumérée d'adresses :
backend amont { server backend1.example.com weight=5; serveur backend2.example.com ; } Publicité
Ces amonts ont beaucoup d'options ; ici, nous avons défini un poids, qui priorisera ce serveur plus souvent (particulièrement utile si vous avez des tailles différentes). Vous pouvez également définir les connexions maximales et divers délais d'attente. Si vous utilisez NGINX Plus, vous pouvez également configurer des contrôles d'intégrité afin que les connexions ne soient pas acheminées vers des serveurs défectueux.
La forme la plus basique de persistance de session consiste à utiliser un hachage IP. . NGINX utilisera l'adresse IP pour identifier les utilisateurs, puis s'assurera que ces utilisateurs ne changent pas de serveur en cours de session :
backend en amont { ip_hash; serveur backend1.example.com ; serveur backend2.example.com ; }
Le hachage IP est requis pour les applications basées sur des sockets et tout ce qui nécessite de la persistance. Si vous ne souhaitez pas utiliser l'adresse IP, vous pouvez personnaliser ce hachage :
backend amont { hash $scheme$request_uri cohérente; serveur backend1.example.com ; serveur backend2.example.com ; }
Si vous n'avez besoin d'aucune sorte de persistance de session, vous pouvez rendre la sélection à tour de rôle un peu plus intelligente en sélectionnant le serveur qui a le moins de connexions :
backend en amont { least_conn; serveur backend1.example.com ; serveur backend2.example.com ; }
Ou, en fonction de celui qui répond actuellement le plus rapidement :
backend en amont { east_time (header | last_byte) ; serveur backend1.example.com ; serveur backend2.example.com ; }
NGINX Plus a quelques autres formes de persistance de session, mais le hachage IP fonctionnera pour la plupart des applications.
Procuration vers le backend
Une fois votre backend configuré, vous pouvez lui envoyer des requêtes depuis vos blocs de localisation, en utilisant proxy_pass avec un URI vers le backend.
server { listen 80; nom_serveur exemple.com ; emplacement/{ proxy_pass http://backend; } } Publicité
Bien sûr, si vous utilisez HTTPS, vous devrez envoyer la requête avec HTTPS :
server { listen 443 ssl; nom_serveur exemple.com ; certificat_ssl /etc/ssl/certs/server.crt; ssl_certificate_key /etc/ssl/certs/server.key ; certificat_client_ssl /etc/ssl/certs/ca.crt; emplacement /{ proxy_pass https://backend; } }