Puncte:1

Detectarea a 502 de răspunsuri în Nginx Load Balancer

drapel jm

Am următoarea configurație - Nginx load balancer care primește trafic https și trece la noduri. Pe fiecare nod există un proxy invers care gestionează traficul https și transmite date către App1, App2 în text simplu.

--> LB --> RP -> App1, App2
       `-> RP -> App1, App2

Acum problema este că, dacă App1 este în jos pe un nod, load balancer nu detectează acest lucru și servește cu bucurie 502 înapoi clientului. Bănuiesc că se datorează faptului că proxy-ul invers este încă activ și criptează traficul și, prin urmare, echilibrerul de încărcare pur și simplu trece prin date. Cum pot informa echilibrul de încărcare că App1 de pe nodul 1 este oprit și merg la celălalt nod?

LB simplificat nginx.conf:

curent {
    harta „$ssl_preread_server_name:$server_port” $namehttps {
        nume de gazdă;
        some-address.io:8443 test_site;
    }

    amonte test_site {
        server 192.168.1.10;
        server 192.168.1.11
    }
    Server {
        proxy_pass $numehttps;
        ssl_preread on;
    }
}

Proxy invers nginx.conf acționează ca un proxy invers standard, care termină traficul ssl și transmite trafic necriptat către o aplicație.

Puncte:0
drapel cz

Problema este că folosești curent și nu ar trebui să fie.

nginx nu are vizibilitate la sarcina utilă a conexiunii atunci când este utilizat curent proxy. Nici măcar nu are de unde să știe că există HTTP acolo și nici nu are curent îi pasă nimic de sarcina utilă.

Va trebui să utilizați „un proxy invers standard care încheie traficul ssl”.

Rapolas K. avatar
drapel jm
Nu pot evita utilizarea fluxului, deoarece este un echilibrator de încărcare generic. În plus, nu pot termina traficul ssl pe loadbalancer, deoarece există o cerință ca niciun trafic necriptat să nu treacă prin rețea (chiar dacă este intern).
Michael Hampton avatar
drapel cz
@RapolasK. Atunci nu poți detecta 502 răspunsuri. Va trebui să faci altceva. Dar de ce nu poți recripta traficul?
Puncte:0
drapel my

Dacă am înțeles corect ce vrei să spui, poți folosi verificări active de sănătate, care sunt practic solicitări HTTP periodice.

Conform documentației NGINX (https://docs.nginx.com/nginx/admin-guide/load-balancer/http-health-check/), pe care o voi rezuma aici în cazul în care pagina trece 404, trebuie să:

  • definiți în Server porțiune din configurație a Locație / (sau cale similară) secțiune;

  • includ proxy_pass și control medical directivă în secțiunea locație/(sau similară);

  • în http în amonte grup de servere, definiți o memorie partajată prin adăugare zona backend 64k (sau valoare similară).

Cu toate acestea, acest lucru nu funcționează dacă utilizați un curent bloc, deoarece fluxurile funcționează la nivelul TCP/UDP. Fluxul în amonte trebuie să fie cuprins în a http bloc, astfel încât să puteți beneficia de caracteristicile de nivel superior ale http modul.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.