Comment configurer l'équilibrage de charge pour TCP sur le serveur Nginx

1. Installez nginx
1. Téléchargez nginx

# wget http://nginx.org/download/nginx-1.2.4.tar.gz

2. Téléchargez le patch du module TCP

# wget https://github.com/yaoweibin/nginx_tcp_proxy_module/tarball/master

Page d'accueil du code source : https://github.com/yaoweibin/nginx_tcp_proxy_module

3.

# tar xvf nginx-1.2.4.tar.gz
# tar xvf yaoweibin-nginx_tcp_proxy_module-v0.4-45-ga40c99a.tar.gz
# cd nginx-1.2.4
# patch -p1 < ../yaoweibin-nginx_tcp_proxy_module-a40c99a/tcp.patch
#./configure --prefix=/usr/local/nginx --with-pcre=../pcre-8.30 --add-module=../yaoweibin-nginx_tcp_proxy_module-ae321fd/
# make
# make install

2. Modifiez le fichier de configuration
Modifiez le fichier de configuration nginx.conf

# cd /usr/local/nginx/conf
# vim nginx.conf

worker_processes 1;
events {
worker_connections 1024;
}

tcp {
upstream mssql {
server 10.0.1.201:1433;
server 10.0.1.202:1433;
check interval=3000 rise=2 fall=5 timeout=1000;
}
server {
listen 1433;
server_name 10.0.1.212;
proxy_pass mssql;
}
}

3. Démarrez nginx

# cd /usr/local/nginx/sbin/
# ./nginx

Affichez le port 1433 :

#lsof :1433

4. Test

# telnet 10.0.1.201 1433

5. Utilisez le test de l'outil client SQL Server

6. Principe d'exécution de l'équilibrage de charge TCP
Lorsque nginx reçoit un nouveau lien client du port d'écoute, il exécute immédiatement l'algorithme de planification de routage et obtient le spécifié. IP du service qui doit être connecté, puis créez une nouvelle connexion en amont au serveur spécifié.

l'équilibrage de charge TCP prend en charge l'algorithme de planification d'origine de nginx, y compris le round robin (par défaut, planification d'interrogation), le hachage (sélection cohérente), etc. Dans le même temps, les données d'informations de planification fonctionneront également avec le module de détection de robustesse pour sélectionner le serveur cible en amont approprié pour chaque connexion. Si vous utilisez la méthode de planification d'équilibrage de charge de hachage, vous pouvez utiliser $remote_addr (IP client) pour obtenir une session persistante simple (les connexions avec la même IP client tombent toujours sur le même serveur de service).

Comme les autres modules en amont, le module de flux TCP prend également en charge le poids de transfert d'équilibrage de charge personnalisé (configuration "weight=2"), ainsi que les paramètres de sauvegarde et d'arrêt, qui sont utilisés pour expulser les serveurs en amont défaillants. Le paramètre max_conns peut limiter le nombre de connexions TCP d'un serveur et définir la valeur de configuration appropriée en fonction de la capacité du serveur. En particulier dans les scénarios à forte concurrence, il peut atteindre l'objectif de protection contre les surcharges.

nginx surveille la connexion client et la connexion en amont. Une fois les données reçues, nginx les lira et les transmettra immédiatement à la connexion en amont sans effectuer de détection de données dans la connexion TCP. nginx maintient une mémoire tampon pour l'écriture des données client et en amont. Si le client ou le serveur transmet une grande quantité de données, le tampon augmentera la taille de la mémoire en conséquence.

Lorsque nginx reçoit une notification de fermeture de connexion d'une partie ou que la connexion TCP est inactive pendant plus longtemps que la durée configurée par proxy_timeout, la connexion sera fermée. Pour les connexions TCP longues, nous devons choisir un délai proxy_timeout approprié et, en même temps, faire attention au paramètre so_keepalive du socket de surveillance pour éviter une déconnexion prématurée.

ps : Surveillance de la robustesse du service

Le module d'équilibrage de charge TCP prend en charge la détection de robustesse intégrée. Si un serveur en amont refuse une connexion TCP pendant plus que le temps configuré proxy_connect_timeout, il sera considéré comme ayant échoué. Dans ce cas, nginx essaie immédiatement de se connecter à un autre serveur normal du groupe en amont. Les informations sur l'échec de la connexion seront enregistrées dans le journal des erreurs nginx.

Si un serveur échoue à plusieurs reprises (dépassant les paramètres configurés par max_fails ou fail_timeout), nginx kickera également le serveur. 60 secondes après le démarrage du serveur, nginx tentera occasionnellement de s'y reconnecter pour vérifier s'il est revenu à la normale. Si le serveur revient à la normale, nginx le rajoutera au groupe en amont et augmentera lentement la proportion de demandes de connexion.

La raison de "l'augmentation lente" est que généralement un service a des "données chaudes", c'est-à-dire que plus de 80%, voire plus, des requêtes seront en fait bloquées dans le "cache de données chaudes", et le réel le traitement ne sera pas effectué. Il n’y a que quelques demandes. Lorsque la machine vient de démarrer, le « cache de données chaudes » n'a pas réellement été établi. À ce moment-là, un grand nombre de requêtes sont transmises de manière explosive, ce qui est susceptible d'empêcher la machine de « supporter » et de raccrocher à nouveau. . En prenant MySQL comme exemple, plus de 95 % de nos requêtes MySQL tombent généralement dans le cache mémoire, et peu de requêtes sont réellement exécutées.

En fait, qu'il s'agisse d'une seule machine ou d'un cluster, le redémarrage ou la commutation dans un scénario de requêtes simultanées élevées comportera ce risque. Il existe deux manières principales de le résoudre :

(1) Augmenter progressivement le nombre de requêtes, de moins en plus, accumulez progressivement des données de point d'accès et atteignez enfin l'état de service normal.

(2) Préparez à l'avance les données « couramment utilisées », « préchauffez » le service de manière proactive, puis ouvrez l'accès au serveur une fois le préchauffage terminé.

Le principe de l'équilibrage de charge TCP est le même que celui de lvs, etc. Il fonctionne à un niveau inférieur et ses performances seront bien supérieures à l'équilibrage de charge http d'origine. Cependant, ce ne sera pas mieux que lvs soit placé dans le module du noyau, alors que nginx fonctionne en mode utilisateur et que nginx est relativement lourd. Un autre point, très regrettable, est que ce module est une fonction payante.

Le module d'équilibrage de charge TCP prend en charge la détection de robustesse intégrée. Si un serveur en amont refuse une connexion TCP pendant plus que la durée configurée proxy_connect_timeout, il sera considéré comme ayant échoué. Dans ce cas, nginx essaie immédiatement de se connecter à un autre serveur normal du groupe en amont. Les informations sur l'échec de la connexion seront enregistrées dans le journal des erreurs nginx.

Si un serveur échoue à plusieurs reprises (dépassant les paramètres configurés par max_fails ou fail_timeout), nginx kickera également le serveur. 60 secondes après le démarrage du serveur, nginx tentera occasionnellement de s'y reconnecter pour vérifier s'il est revenu à la normale. Si le serveur revient à la normale, nginx le rajoutera au groupe en amont et augmentera lentement la proportion de demandes de connexion.

La raison de "l'augmentation lente" est que généralement un service a des "données chaudes", c'est-à-dire que plus de 80 %, voire plus, des requêtes seront en fait bloquées dans le "cache de données chaudes" avant que le traitement réel ne soit effectué. . Il n'y a que quelques demandes. Lorsque la machine vient de démarrer, le « cache de données chaudes » n'a pas réellement été établi. À ce moment-là, un grand nombre de requêtes sont transmises de manière explosive, ce qui est susceptible d'empêcher la machine de « supporter » et de raccrocher à nouveau. . En prenant MySQL comme exemple, plus de 95 % de nos requêtes MySQL tombent généralement dans le cache mémoire, et peu de requêtes sont réellement exécutées.

En fait, qu'il s'agisse d'une seule machine ou d'un cluster, le redémarrage ou la commutation dans un scénario de requêtes simultanées élevées comportera ce risque. Il existe deux manières principales de le résoudre :

(1) Augmenter progressivement le nombre de requêtes, de moins en plus, accumulez progressivement des données de point d'accès et atteignez enfin l'état de service normal.
(2) Préparez à l'avance les données « couramment utilisées », « préchauffez » le service de manière proactive, puis ouvrez l'accès au serveur une fois le préchauffage terminé.

Le principe de l'équilibrage de charge TCP est le même que celui de lvs, etc. Il fonctionne à un niveau inférieur et ses performances seront bien supérieures à l'équilibrage de charge http d'origine. Cependant, ce ne sera pas mieux que lvs soit placé dans le module du noyau, alors que nginx fonctionne en mode utilisateur et que nginx est relativement lourd. Un autre point, très regrettable, est que ce module est une fonction payante.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!