Comment Nginx utilise ngx_http_upstream_module pour implémenter la fonction d'équilibrage de charge

Introduction à l'équilibrage de charge

Qu'est-ce que l'équilibrage de charge

Load Balance (Load Balance) signifie équilibrer et allouer la charge (tâches de travail, demandes d'accès) à plusieurs unités d'exploitation (serveurs, composants) mettre en œuvre.

Pourquoi l'équilibrage de charge est nécessaire

Lorsqu'un seul serveur Web fait face directement aux utilisateurs, il peut transporter un grand nombre de requêtes simultanées et un seul serveur peut être difficile à charger. Nous devons utiliser plusieurs serveurs Web pour former un cluster et. utilisez la fonction d'équilibrage de charge Nginx. Distribuez les requêtes à différents serveurs principaux pour répartir le trafic de charge, améliorer les performances globales et les capacités de reprise après sinistre du système.

• Quelle est la différence entre l'équilibrage de charge et le proxy

Un proxy consiste à proxyer un serveur en fonction de la planification URI et à le planifier sur des nœuds d'application avec différentes fonctions

L'équilibrage de charge consiste à proxyer les requêtes des clients vers un ensemble de Pools de ressources en amont via proxy_pass

• po implémenter des scénarios d'équilibrage de charge

Deux modules sont nécessaires pour implémenter la fonction d'équilibrage de charge:

• proxy_pass: module proxy

• upstream: Pool de ressources virtuel

Exemple : un affichage officiel de l'équilibrage de charge

upstream backend {
    server backend1.example.com       weight=5;
    server backend2.example.com:8080;
    server unix:/tmp/backend3;

    server backup1.example.com:8080   backup;
    server backup2.example.com:8080   backup;
}

server {
    location / {
        proxy_pass http://backend;
    }
}

Exemple : Complétez un petit exemple par vous-même

upstream node {
    server 192.168.10.3:80;
    server 192.168.10.4:80;
}
server {
    listen 80;
    server_name www.yyang.com;
    location / {
        proxy_pass http://node;
        include prxoy_params;
    }
}

Algorithme de planification d'équilibrage de charge

Planification d'interrogation

distribuée aux différents nœuds backend un par un dans l'ordre, qui est également l'algorithme par défaut . (Pour faire simple, c'est 1:1:1)

Sondage pondéré
Compte tenu des performances différentes des différents serveurs, différents poids sont attribués aux nœuds afin qu'ils reçoivent le nombre correspondant de demandes de poids

server 192.168.10.3:80 weight=3;
server 192.168.10.4:80 weight=1;

L'exemple ci-dessus Cela signifie que toutes les quatre demandes seront allouées à trois demandes pour 10.3 et une demande pour 10.4, et le cycle continue.

ip_hash

Selon l'IP demandée par l'utilisateur, effectuez une opération de hachage sur l'IP et attribuez la demande à un nœud spécifique sur le backend pour un traitement en fonction de la valeur calculée.

La plage de valeurs correspond aux trois 8 premiers bits de l'adresse ipv4 ou à l'adresse entière d'ipv6 comme clé de hachage, garantissant que l'adresse IP d'un client est toujours transmise au même serveur, à moins que le serveur secondaire ne soit indisponible. Pour faire simple, les trois premiers ensembles de nombres de 172.16.20.1 et 172.16.20.2 sont les mêmes (tous 172.16.20)

Formule d'opération ip_hash : hash (ip)%node_counts=index

Problèmes causés par ip_hash :
Un grand nombre de requêtes provenant de la même IP entraîneront un trafic excessif sur un certain nœud. Si un nœud est temporairement hors ligne, la valeur de hachage sera recalculée. Il est recommandé d'utiliser l'état down. Exemple : Notez que ip_hash etweight ne peuvent pas être utilisés. en même temps.

ip_hash;
server 192.168.10.3:80;
server 192.168.10.4:80;

Hash cohérent

Afin d'éviter les problèmes ci-dessus, le hachage cohérent est né, en utilisant la méthode modulo, mais il ne modulo pas le nombre de nœuds du serveur, mais modulo 2 à la 32ème puissance. . La valeur de la fonction de hachage est 0~2^32-1 . (Formant un anneau virtuel, les requêtes des utilisateurs seront envoyées aux nœuds adjacents dans le sens des aiguilles d'une montre) Il y a un problème : s'il y a moins de nœuds back-end, cela peut provoquer une distorsion des données, donc un hachage cohérent introduit un mécanisme de nœud virtuel, c'est-à-dire pour each Le serveur calcule plusieurs hachages et place un nœud virtuel à chaque emplacement de résultat calculé.

Que devons-nous faire si nous voulons utiliser ip_hash, mais que la formule de calcul utilise un hachage cohérent ?

hash $remote_addr consistent;
server 192.168.10.3:80;
server 192.168.10.4:80;

url_hash

prend le modulo de hachage en fonction de l'URL de l'utilisateur et attribue la requête à un serveur backend spécifique en fonction de la valeur de l'opération.

1. L'utilisateur demande l'équilibrage de charge nginx, et via l'algorithme d'URL, la requête est planifiée pour mettre en cache1

2.cache1 n'a pas de données, il obtiendra les données du backend, renverra les données et mettra les données en cache

3. . Lorsque d'autres utilisateurs accèdent à la même URL, planifiez Le serveur sera toujours planifié sur le nœud cache1

4.cache1 renverra directement les données

hash $request_uri consistent;
server 192.168.10.3:80;
server 192.168.10.4:80;

least_conn

Quel serveur a le moins de connexions, la requête sera. programmé sur ce serveur

least_conn;
server 192.168.10.3:80;
server 192.168.10.4:80;

État du nœud backend d'équilibrage de charge

down

marque le nœud du serveur comme indisponible, généralement utilisé pour la maintenance des temps d'arrêt.

server 192.168.10.3:80 down;
server 192.168.10.4:80;

backup

Nœud de veille, ce nœud ne sera pas planifié dans des circonstances normales ; lorsque tous les nœuds de travail normaux sont indisponibles, ce nœud sera activé lors de la récupération, ce nœud continuera à restaurer l'état de veille ;

server 192.168.10.3:80;
server 192.168.10.4:80;
server 192.168.10.5:80 backup;

max_conns

est utilisé pour limiter le nombre maximum de connexions TCP reçues par chaque nœud backend si la limite est dépassée, une erreur sera générée.

server 192.168.10.3:80 max_conns=10;
server 192.168.10.4:80 max_conns=10;

Un peut connecter 10. Deux peuvent connecter 20. S'il dépasse 20, une erreur se produira.

keepalived

active la mise en cache avec le serveur backend, c'est-à-dire les liens longs, pour améliorer le débit du site Web. Cette fonction n'est pas activée par défaut. Lorsqu'il y a une demande, une connexion sera établie, maintenue et fermée, il y aura donc une consommation de réseau mais si toutes les connexions sont mises en cache, d'autres ressources système seront occupées lorsque la connexion sera établie. inactif, il peut donc être utilisé comme paramètre keepalived.

server 192.168.10.3:80;
server 192.168.10.4:80;

keepalived 32;   # 最大空闲连接数的个数
keepalived_timeout 100s; # 空闲连接的超时时间

# 需要配合以下两个参数使用

proxy_http_version 1.1;
proxy_set_header connection "";

max_fails et fail_timeout

max_fails=2：服务器通信失败两次，认为服务器不可用
fail_timeout=5s：服务器通信失败后，每5秒探测一次服务器是否恢复正常。
在fail_timeout设定时间内，与服务器连接失败次数达到max_fails数量，则认为服务器不可用。
如果不设置的话默认是探测一次，间隔10s。

server 192.168.10.3:80 max_fails=2 fail_timeout=5s;
server 192.168.10.4:80 max_fails=2 fail_timeout=5s;

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!