Kāda ir jūsu pieredze ar Nginx slodzes…

Zinu Nginx kā augstas veiktspējas atpakaļējo proxy un tīmekļa serveri, aktīvi to izmantoju slodzes sadalīšanas konfigurācijai.

Slodzes sadalīšanas veidi, ar kuriem esmu strādājis:

Round Robin: sadala pieprasījumus vienmērīgi starp serveriem pulkā. Vienkārši, bet neņem vērā serveru slodzi.

upstream backend {
    server 192.168.1.100;
    server 192.168.1.101;
    server 192.168.1.102;
}

server {
    listen 80;

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

Least Conn (Mazākās savienojumu skaits): nosūta pieprasījumu serverim ar mazāko aktīvo savienojumu skaitu. Efektīvāk, ja slodze ir nevienmērīga.
```
upstream backend {
    least_conn;
    server 192.168.1.100;
    server 192.168.1.101;
    server 192.168.1.102;
}

// ... cita servera konfigurācija
```
IP Hash: sadala pieprasījumus, pamatojoties uz klienta IP adresi. Garantē, ka viena klienta pieprasījumi tiks nosūtīti uz to pašu serveri, kas ir noderīgi stāvokļa atkarīgām lietojumprogrammām.
```
upstream backend {
    ip_hash;
    server 192.168.1.100;
    server 192.168.1.101;
    server 192.168.1.102;
}

// ... cita servera konfigurācija
```

Generic Hash: sadala pieprasījumus, pamatojoties uz nejaušu tekstu, atslēgu vai mainīgo, kas ir definēts ar hash funkciju.

upstream backend {
    hash $request_uri consistent; # Izmantojot pieprasījuma URI
    server 192.168.1.100;
    server 192.168.1.101;
    server 192.168.1.102;
}

// ... cita servera konfigurācija

Random: nejauši izvēlas serveri. Var izmantot two least_conn, kas izvēlas starp diviem nejauši izvēlētiem serveriem, priekšroku dodot tam ar mazāku savienojumu skaitu.
```
upstream backend {
    random two least_conn;
    server 192.168.1.100;
    server 192.168.1.101;
    server 192.168.1.102;
}

// ... cita servera konfigurācija
```

Es izmantoju proxy_next_upstream direktīvas, lai noteiktu nosacījumus, kad pieprasījums tiks pāradresēts uz nākamo serveri pulkā (piem., kļūdas 502, 503 vai laika ierobežojuma gadījumā). Tāpat esmu konfigurējis veselības pārbaudes ar health_check (pieejams Nginx Plus) vai ar ārējiem rīkiem, kas pārbauda serveru pieejamību un dinamiski atjauno Nginx konfigurāciju.

Es izmantoju keepalive savienojumus ar backend serveriem, lai samazinātu savienojuma uzstādīšanas izmaksas. Darbojos ar SSL/TLS termināciju Nginx, lai samazinātu slodzi uz backend.

Lai uzraudzītu stāvokli, es izmantoju Nginx statusa lapu, kas pieejama caur ngx_http_stub_status_module vai ngx_http_api_module (Nginx Plus). Integrēju uzraudzību ar Prometheus un Grafana, lai vizualizētu metriku un saņemtu brīdinājumus.

Es izmantoju Nginx Docker konteineros un Kubernetes orkestratoros, bieži kā Ingress kontrolieri trafika sadalei uz pakalpojumiem.

Strādāju ar dažādiem scenārijiem, tostarp:

HTTP/S trafika sadale web lietojumprogrammām.
TCP trafika sadale datu bāzēm vai citām pakalpojumiem.
Nginx kā kešojamu proxy priekš backend serveriem.

Es varu optimizēt Nginx konfigurāciju augstas veiktspējas sasniegšanai, ieskaitot worker procesus, worker savienojumus un buferizāciju. Es izmantoju nginx -t sintakses pārbaudei un nginx -s reload izmaiņu piemērošanai bez pakalpojuma pārtraukšanas.

Kopumā es pārliecināti pārvaldu Nginx konfigurāciju, lai īstenotu dažādas slodzes sadalīšanas stratēģijas ražošanas vidēs.

Kāda ir jūsu pieredze ar Nginx slodzes līdzsvarošanai?