Kokia jūsų patirtis dirbant su Nginx apkrovos…

Žinau Nginx kaip aukštos našumo atvirkštinio proxy ir žiniatinklio serverio, aktyviai naudoju jį apkrovos paskirstymo konfigūracijai.

Paskirstymo tipai, su kuriais dirbau:

Round Robin: paskirsto užklausas tolygiai tarp serverių pulke. Paprasta, bet neatsižvelgia į serverių apkrovą.

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 (Mažiausiai jungčių): siunčia užklausą serveriui su mažiausiu aktyvių jungčių skaičiumi. Efektyviau esant nelygiam apkrovimui.

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

// ... kita serverio konfigūracija

IP Hash: paskirsto užklausas pagal kliento IP adresą. Garantuoja, kad užklausos iš vieno kliento nueis į tą patį serverį, kas naudinga būsenos priklausomoms programoms.
```
upstream backend {
    ip_hash;
    server 192.168.1.100;
    server 192.168.1.101;
    server 192.168.1.102;
}

// ... kita serverio konfigūracija
```

Generic Hash: paskirsto užklausas pagal atsitiktinį tekstą, raktą ar kintamąjį, nustatytą hash funkcija.

upstream backend {
    hash $request_uri consistent; # Naudojant užklausos URI
    server 192.168.1.100;
    server 192.168.1.101;
    server 192.168.1.102;
}

// ... kita serverio konfigūracija

Random: atsitiktinai pasirenka serverį. Galima naudoti two least_conn, kuris pasirenka tarp dviejų atsitiktinai pasirinkto serverio, pirmenybė teikiama tam, kuriame mažiau jungčių.
```
upstream backend {
    random two least_conn;
    server 192.168.1.100;
    server 192.168.1.101;
    server 192.168.1.102;
}

// ... kita serverio konfigūracija
```

Naudoju proxy_next_upstream direktyvas, kad apibrėžčiau sąlygas, kada užklausa bus peradresuota į kitą serverį pulke (pvz., klaidos 502, 503 ar laiko limitas). Taip pat diegiau sveikatos patikrinimus su health_check (pasiekiama Nginx Plus) arba išoriniais įrankiais, kurie tikrina serverių prieinamumą ir dinamiškai atnaujina Nginx konfigūraciją.

Naudoju keepalive jungtis prie backend serverių, siekiant sumažinti ryšio nustatymo išlaidas. Dirbu su SSL/TLS terminacija Nginx, kad sumažinčiau apkrovą backend.

Stebėjimui naudoju Nginx statuso puslapį, prieinamą per ngx_http_stub_status_module arba ngx_http_api_module (Nginx Plus). Integruoju stebėjimą su Prometheus ir Grafana metrikų vizualizacijai ir įspėjimams.

Naudoju Nginx Docker konteineriuose ir Kubernetes orkestratoriuose, dažnai kaip Ingress kontrolierių tinklo srautui paskirstyti.

Dirbau su įvairiomis scenarijais, įskaitant:

HTTP/S srauto paskirstymą interneto programoms.
TCP srauto paskirstymą duomenų bazėms ar kitoms paslaugoms.
Naudojant Nginx kaip talpyklos proxy prieš backend serverius.

Galiu optimizuoti Nginx konfigūraciją aukštos našumo pasiekimui, įskaitant worker procesų, worker jungčių ir buferizacijos nustatymus. Naudoju nginx -t sintaksės patikrinimui ir nginx -s reload pakeitimų taikymui be paslaugos sustabdymo.

Apskritai, užtikrintai valdau Nginx konfigūraciją, kad įgyvendinčiau įvairias apkrovos paskirstymo strategijas gamybos aplinkose.

Kokia jūsų patirtis dirbant su Nginx apkrovos balansavimui?