Construction d'un serveur de cache avec proxy inverse nginx

Related Tags：1.Nginx Ingress Controller
2. Parse nginx logs

Résumé : ce mécanisme sert à transmettre vers Internet les requêtes de connexion (VPN/NAT, etc.) du réseau interne.

Les services de proxy se divisent simplement en proxy direct et proxy inverse :

Proxy direct : le client spécifie le serveur proxy et lui envoie la requête HTTP initialement destinée au serveur web cible. Le serveur proxy accède ensuite au serveur web et renvoie la réponse de celui-ci au client :

Proxy inverse : à l'inverse du proxy direct, si le réseau local fournit des ressources à Internet et autorise d'autres utilisateurs d'Internet à y accéder, vous pouvez également mettre en place un serveur proxy, qui fournit alors un service de proxy inverse. Le serveur proxy inverse accepte les connexions provenant d'Internet, transmet la requête au serveur du réseau interne et renvoie la réponse à

Clients d'Internet demandant une connexion :

1. nginx proxy inverse : l'ordonnanceur du serveur web

1. Le proxy inverse signifie que le serveur proxy accepte la requête de connexion du client, puis transmet la requête au serveur web (apache, nginx, tomcat, iis, etc.) sur le réseau, et renvoie au client demandeur le résultat obtenu du serveur web. Le serveur proxy se comporte alors comme un serveur vis-à-vis de l'extérieur.

Comme le montre la figure ci-dessus : le serveur proxy inverse reçoit la requête HTTP et la transmet. De plus, en tant que serveur proxy inverse, nginx peut transmettre les requêtes à différents serveurs web backend selon le contenu de la requête utilisateur, par exemple pour séparer le statique du dynamique, ou encore créer plusieurs hôtes virtuels sur nginx afin d'accéder, depuis le navigateur, à différents serveurs web ou clusters web en backend lors de la saisie de différents noms de domaine (URL).

2. Quel est le rôle du proxy inverse ?

①Protéger la sécurité du site : toute requête provenant d'Internet doit d'abord passer par un serveur proxy ;

wKioL1jsz9yAHyulAABvTU4R-Ew435.png-wh_50

②Accélérer les requêtes web grâce à la fonction de mise en cache : certaines ressources statiques du serveur web réel peuvent être mises en cache afin de réduire la charge de celui-ci ;

wKiom1jsz-nwYDqSAABjrKK3l5E661.png-wh_50

③ Réaliser la répartition de charge : agit comme un serveur de répartition de charge afin de distribuer les requêtes de manière équilibrée, en équilibrant la charge de chaque serveur du cluster ;

wKiom1jsz__Q7RpoAAJQnYSWdA8640.png-wh_50

2. Qu'est-ce que nginx

1. Présentation de nginx

Nginx est un serveur web léger, un proxy inverse et un serveur proxy de messagerie. Il est réputé pour sa stabilité, la richesse de ses fonctionnalités, ses exemples de fichiers de configuration et sa faible consommation de ressources système. Nginx (prononcé « engine x ») a été développé par le programmeur russe Igor Sysoev. Il a d'abord été utilisé par le grand portail et moteur de recherche russe Rambler (en russe : Ð Ð°Ð¼Ð±Ð»ÐµÑ€). Ce logiciel est publié sous une licence de type BSD et peut fonctionner sous UNIX, GNU/Linux, BSD, Mac OS X, Solaris et Microsoft Windows.

État d'utilisation de Nginx

Nginx fonctionne déjà sur Rambler Media (www.rambler.ru), le plus grand portail de Russie, et plus de 20 % des plateformes d'hébergement virtuel en Russie utilisent Nginx comme serveur proxy inverse.

En Chine, de nombreux sites tels que Taobao, Sina Blog, Sina Podcast, Netease News, Liujianfang, 56.com, Discuz!, Shuimu Community, Douban, YUPOO, Domestic, Xunlei Online, etc. utilisent déjà Nginx comme serveur web ou serveur proxy inverse.

2. Les fonctionnalités clés de Nginx

(1) Multiplateforme : Nginx peut être compilé et exécuté sur la plupart des systèmes d'exploitation, et il existe également une version Windows ;

(2) Configuration très simple : la prise en main est très facile.

(3) Connexions simultanées non bloquantes et élevées : les tests officiels peuvent prendre en charge 50 000 connexions simultanées et, en environnement de production réel, on atteint 20 000 à 30 000 connexions simultanées. (Cela est dû au fait que Nginx utilise le modèle epoll le plus récent) ;

Remarque :

Pour un serveur web, examinons d'abord le processus de base d'une requête : établissement d'une connexion - réception des données - envoi des données. Au niveau du système, ce processus (établissement d'une connexion - réception des données - envoi des données) correspond à un événement de lecture et d'écriture au niveau du système.

Si la méthode d'appel bloquant est utilisée, lorsque les événements de lecture et d'écriture ne sont pas prêts, la seule option est d'attendre : le thread courant est suspendu et les événements de lecture et d'écriture ne peuvent être exécutés que lorsque les événements sont prêts.

Si vous utilisez une méthode d'appel non bloquant : l'événement retourne immédiatement, en vous indiquant que l'événement n'est pas encore prêt et qu'il faut revenir plus tard. Après un moment, vérifiez à nouveau l'événement jusqu'à ce qu'il soit prêt. Entre-temps, vous pouvez d'abord faire d'autres choses, puis revenir voir si l'événement est prêt. Bien qu'il n'y ait pas de blocage, vous devez vérifier de temps en temps l'état de l'événement. Vous pouvez faire plus de choses, mais la surcharge n'est pas négligeable. Un appel non bloquant signifie que l'appel ne bloque pas le thread courant tant que le résultat n'est pas immédiatement disponible

(4) Piloté par les événements : le mécanisme de communication adopte le modèle epoll afin de prendre en charge un plus grand nombre de connexions simultanées.

Le mode non bloquant détermine s'il faut effectuer des opérations de lecture et d'écriture en vérifiant en permanence l'état des événements, ce qui entraîne une surcharge importante. Il existe donc un mécanisme de traitement d'événements asynchrone non bloquant. Ce mécanisme permet de surveiller plusieurs événements en même temps. Leur appel est non bloquant, mais vous pouvez définir un délai d'attente. Dans ce délai, si un événement est prêt, il retourne. Ce mécanisme résout les deux problèmes des appels bloquants et non bloquants mentionnés ci-dessus.

Prenons le modèle epoll comme exemple : lorsqu'un événement n'est pas prêt, il est placé dans l'epoll (file d'attente). Si un événement est prêt, on le traite ; lorsqu'il n'est pas prêt, il attend dans l'epoll. De cette façon, nous pouvons traiter simultanément un grand nombre de requêtes concurrentes. Bien sûr, les requêtes concurrentes désignent ici les requêtes non traitées. Comme il n'y a qu'un seul thread, une seule requête peut être traitée à la fois. Il s'agit simplement d'une bascule constante entre les requêtes. La bascule est également abandonnée activement parce que l'événement asynchrone n'est pas prêt. Le changement n'a ici aucun coût ; vous pouvez le comprendre comme une boucle parcourant plusieurs événements préparés.

Comparée à la méthode multithread, cette méthode de traitement d'événements présente de grands avantages. Elle n'a pas besoin de créer de threads et chaque requête occupe très peu de mémoire. Il n'y a pas de changement de contexte. Le traitement d'événements est très léger et le nombre de connexions simultanées est élevé. Elle n'entraîne pas non plus de gaspillage inutile de ressources (changement de contexte). Pour le serveur apache, chaque requête dispose d'un thread de travail dédié et, lorsque le nombre de connexions simultanées atteint plusieurs milliers, plusieurs milliers de threads traitent les requêtes en même temps. Cela représente un défi majeur pour le système d'exploitation : la consommation de mémoire due aux threads est très importante, le coût CPU dû au changement de contexte des threads est très élevé et les performances ne peuvent naturellement pas être améliorées, ce qui entraîne une baisse importante des performances dans les scénarios de forte concurrence.

Récapitulatif : grâce au mécanisme de traitement d'événements asynchrone non bloquant, Nginx traite de manière cyclique plusieurs événements préparés par le processus, atteignant ainsi une concurrence élevée et une grande légèreté.

(5) Structure Master/Worker : un processus master génère un ou plusieurs processus worker.

Remarque : le mode de conception Master-Worker comprend principalement deux composants, Master et Worker. Le Master gère la file d'attente des Worker et envoie les requêtes à plusieurs Worker pour une exécution parallèle. Le Worker effectue principalement les calculs logiques réels et renvoie les résultats au Master.

Quels sont les avantages pour nginx d'adopter ce modèle de processus ? L'utilisation de processus indépendants empêche qu'ils s'affectent mutuellement. Après la fin d'un processus, les autres processus fonctionnent toujours et le service n'est pas interrompu. Le processus Master redémarre rapidement un nouveau processus Worker. Bien sûr, la sortie anormale du processus Worker doit être causée par un bogue du programme. La sortie anormale entraîne l'échec de toutes les requêtes du Worker courant, mais n'affecte pas l'ensemble des requêtes, ce qui réduit le risque.

(6) Faible consommation de mémoire : la consommation de mémoire pour le traitement d'un grand nombre de requêtes simultanées est très faible. Avec 30 000 connexions simultanées, 10 processus Nginx ne consomment que 150 Mo de mémoire (15 Mo*10=150 Mo).

(7) Fonction de vérification de santé intégrée : si un serveur web en backend du proxy Nginx tombe en panne, cela n'affecte pas l'accès frontal.

(8) Économie de bande passante : la compression GZIP est prise en charge et l'en-tête Header mis en cache localement par le navigateur peut être ajouté.

(9) Grande stabilité : utilisé en proxy inverse, la probabilité d'interruption est minime.

3. Nginx+apache construit la répartition de charge de clusters de serveurs web

Configurer le proxy inverse avec nginx

Configurez nginx comme proxy inverse et répartiteur de charge, et utilisez sa fonction de mise en cache pour mettre en cache les pages statiques dans nginx afin de réduire le nombre de connexions aux serveurs backend et de vérifier l'état de santé du serveur web backend.



wKiom1js0B-iFnITAACVfFt6894317.png-wh_50

1. Installer nginx

Environnement :

OS : centos7.2

nginx : 192.168.31.83

apache1 :192.168.31.141

apache2 :192.168.31.250

Installer les dépendances telles que zlib-devel et pcre-devel

[root@www ~]# yum -y install gcc gcc-c++ make libtool zlib zlib-devel pcre pcre-devel openssl openssl-devel

Remarque :

Combiner les modules proxy et upstream pour réaliser la répartition de charge web backend

Mise en cache des fichiers statiques à l'aide du module proxy

Combiné avec le module ngx_http_proxy_module et le module ngx_http_upstream_module par défaut de nginx

Pour réaliser la vérification de santé du serveur backend, vous pouvez également utiliser le module tiers nginx_upstream_check_module

Utiliser le module d'extension nginx-sticky-module pour réaliser la persistance de session par cookie (conserver la session)

Utiliser ngx_cache_purge pour réaliser une fonction de purge de cache plus puissante

Les deux modules mentionnés ci-dessus sont des modules d'extension tiers. Vous devez télécharger le code source à l'avance, puis les installer avec --add-moudle=src_path lors de la compilation.



installer nginx

[root@www ~]# groupadd www #Ajouter le groupe www

[root@www ~]# useradd -g www www -s /sbin/nologin #Créer le compte d'exécution nginx www et l'ajouter au groupe www, et interdire aux utilisateurs www de se connecter directement au système

#tar zxf nginx-1.10.2.tar.gz

#tar zxf ngx_cache_purge-2.3.tar.gz

#tar zxf master.tar.gz

# cd nginx-1.10.2/

[root@www nginx-1.10.2]# ./configure --prefix=/usr/local/nginx1.10 --user=www --group=www --with-http_stub_status_module --with-http_realip_module --with- http_ssl_module --with-http_gzip_static_module --http-client-body-temp-path=/var/tmp/nginx/client --http-proxy-temp-path=/var/tmp/nginx/proxy --http-fastcgi- temp-path=/var/tmp/nginx/fcgi --with-pcre --add-module=../ngx_cache_purge-2.3 --with-http_flv_module --add-module=../nginx-goodies-nginx-sticky -module-ng-08a395c66e42

[root@www nginx-1.10.2]# make && make install

Remarque : tous les modules de nginx doivent être ajoutés au moment de la compilation et ne peuvent pas être chargés dynamiquement à l'exécution.

4. Autres schémas d'ordonnancement pour la répartition de charge :

Voici une présentation des autres algorithmes d'ordonnancement pris en charge par le module de répartition de charge de nginx :

Polling (par défaut) : chaque requête est attribuée une à une aux différents serveurs backend dans l'ordre chronologique. Si un serveur backend tombe en panne, le système défaillant est automatiquement écarté, de sorte que l'accès des utilisateurs n'est pas affecté. Weight spécifie le poids de polling. Plus la valeur de Weight est élevée, plus la probabilité d'accès attribuée est haute. Il est principalement utilisé lorsque les performances de chaque serveur du backend sont inégales.

ip_hash : chaque requête est attribuée selon le résultat de hachage de l'IP d'accès, de sorte que les visiteurs d'une même IP puissent accéder à un même serveur backend, ce qui résout efficacement le problème de partage de session dans les pages web dynamiques. Bien sûr, si ce nœud n'est pas disponible, la requête est envoyée au nœud suivant et, s'il n'y a pas de synchronisation de session à ce moment-là, la session est déconnectée.

least_conn  : la requête est envoyée au serveur réel (realserver) ayant le moins de connexions actives. La valeur de weight est prise en compte.

url_hash  : cette méthode attribue les requêtes selon le résultat de hachage de l'URL d'accès, de sorte que chaque URL soit dirigée vers le même serveur backend, ce qui peut encore améliorer l'efficacité du serveur de cache backend. Nginx ne prend pas en charge url_hash nativement. Si vous devez utiliser cet algorithme d'ordonnancement, vous devez installer le paquet de hachage Nginx nginx_upstream_hash.

fair  : il s'agit d'un algorithme de répartition de charge plus intelligent que les deux précédents. Cet algorithme peut effectuer intelligemment la répartition de charge selon la taille de la page et le temps de chargement, c'est-à-dire attribuer les requêtes selon le temps de réponse du serveur backend, en donnant la priorité à ceux dont le temps de réponse est court. Nginx ne prend pas en charge fair nativement. Si vous devez utiliser cet algorithme d'ordonnancement, vous devez télécharger le module upstream_fair de Nginx.

5. Répartition de charge et vérification de santé :

À proprement parler, nginx ne dispose pas de vérification de santé pour les nœuds backend de la répartition de charge, mais elle peut être réalisée grâce aux directives des modules ngx_http_proxy_module et ngx_http_upstream_module par défaut. Lorsqu'un nœud backend tombe en panne, il bascule automatiquement vers le nœud suivant pour fournir l'accès.

weight  : le poids de polling peut également être utilisé dans ip_hash, la valeur par défaut est 1

max_fails  : le nombre d'échecs de requêtes autorisés, la valeur par défaut est 1. Lorsque le nombre maximal est dépassé, une erreur définie par le module proxy_next_upstream est renvoyée.

fail_timeout : il a deux significations, l'une est d'autoriser jusqu'à 2 échecs en 10 s ; l'autre est de ne pas attribuer de requêtes à ce serveur pendant 10 s après 2 échecs.

6. Utilisation du cache de proxy de nginx :

La mise en cache consiste à mettre en cache les fichiers statiques js, css, image et autres du serveur backend vers le répertoire de cache spécifié par nginx, ce qui permet non seulement de réduire la charge du serveur backend, mais aussi d'accélérer la vitesse d'accès. Cependant, nettoyer le cache à temps devient un problème ; le module ngx_cache_purge est donc nécessaire pour nettoyer manuellement le cache avant le délai d'expiration.

Les directives couramment utilisées dans le module proxy sont proxy_pass et proxy_cache.

La fonction de mise en cache web de nginx est principalement réalisée par le jeu de directives proxy_cache, fastcgi_cache et les jeux de directives associés. La directive proxy_cache est responsable de la mise en cache par proxy inverse du contenu statique du serveur backend, et fastcgi_cache est principalement utilisée pour gérer la mise en cache des processus dynamiques FastCGI.