nginx load balancing: upstream, methoden en health checks
nginx load balancing
nginx load balancer: upstream, methoden, weights, health | We.Inc
Stel nginx in als load balancer: het upstream-blok, round robin, least_conn, ip_hash en hash, weights, max_fails en fail_timeout, backups, plus een configbouwer.
Om met nginx te load balancen, zet u uw app-servers in een upstream-blok en laat u proxy_pass naar de naam ervan wijzen. Verzoeken rouleren via round robin, tenzij u least_conn, ip_hash, hash of random toevoegt. Elke server-regel kan een weight, max_fails en fail_timeout voor passieve health checks hebben, en de flags backup of down.
Load balancing-methoden van nginx
Directive
Hoe er een server wordt gekozen
Geschikt voor
(geen)
Gewogen round robin, de standaard
Vergelijkbare servers en korte verzoeken
Minste actieve verbindingen, rekening houdend met weights
Verzoeken van sterk wisselende duur
Hash van het clientadres (eerste drie octetten van IPv4, het hele IPv6-adres)
Een bezoeker op één server houden
hash key
Hash van elke waarde, zoals $request_uri
Cache-affiniteit; voeg consistent toe om herschikken te beperken
Willekeurige server, of de beste van twee met random two
Meerdere load balancers die één pool delen
Verkeer verdelen over meerdere kopieën van een app is een van de oudste taken van nginx, en de hele opzet past in een tiental regels. De bouwer hieronder schrijft het upstream-blok op basis van een lijst servers, waarschuwt voor combinaties die nginx weigert en toont het aandeel verzoeken per server als er weights gelden. Het naslagdeel daarna behandelt elke serverparameter met zijn standaardwaarde.
Voeg in de bouwer het adres en de poort van elke app-server toe, met een weight als sommige machines groter zijn dan andere.
Kies een methode. Laat het op round robin staan, tenzij verzoeken sterk in duur verschillen of bezoekers bij één server moeten blijven.
Kopieer het resultaat naar de http-context, bijvoorbeeld een bestand in conf.d, en voer nginx -t uit.
Herlaad met nginx -s reload, stop dan één app-server en kijk hoe verzoeken naar de andere gaan.
Een enkele server in een upstream negeert max_fails en fail_timeout, dus passieve checks tellen pas mee vanaf twee servers.
Markeer een server als down in plaats van de regel te verwijderen bij gebruik van ip_hash. Zo blijft de hash van het adres van elke andere client wijzen naar waar hij eerst naartoe wees.
backup-servers krijgen alleen verkeer als alle primaire servers onbereikbaar zijn, en kunnen niet worden gecombineerd met hash, ip_hash of random.
Welke fouten meetellen voor max_fails, bepaalt proxy_next_upstream. Standaard tellen fouten en timeouts; een HTTP 500 telt niet, tenzij u die opneemt.
Voeg keepalive toe met proxy_http_version 1.1 en een lege Connection-header om verbindingen met de backends te hergebruiken in plaats van er per verzoek één te openen.
Veelgestelde vragen
Heeft open source nginx actieve health checks?
Nee. De directive health_check hoort bij het commerciële NGINX Plus. Open source nginx vertrouwt op passieve checks: als een verzoek naar een server max_fails keer mislukt binnen fail_timeout, wordt de server voor fail_timeout overgeslagen en daarna opnieuw geprobeerd met echt verkeer.
Wat zijn de standaardwaarden voor max_fails en fail_timeout?
max_fails is standaard 1 en fail_timeout 10 seconden. Eén mislukte poging haalt een server dus tien seconden uit roulatie. Met max_fails=0 zet u de telling voor die server uit.
Hoe maak ik sessies sticky in nginx?
Gebruik ip_hash om elk clientadres op één server te houden, of hash met een cookievariabele zoals $cookie_session voor fijnere controle. Sticky-directives op basis van cookies bestaan alleen in de commerciële editie.
Wat doet de parameter weight?
Hij verandert hoeveel verzoeken een server krijgt ten opzichte van de andere. Met weights 3, 1 en 1 krijgt de eerste server bij round robin ongeveer drie van elke vijf verzoeken. De standaard-weight is 1.
Kan nginx WebSocket-verbindingen load balancen?
Ja. Laat proxy_pass naar de upstream wijzen en stuur de headers Upgrade en Connection door. least_conn past beter bij langlevende sockets dan round robin, omdat het telt hoeveel verbindingen elke server al heeft.
Waar de onderdelen komen
Het upstream-blok staat in de http-context, naast uw server-blokken. Het geeft alleen een pool een naam; er gebeurt niets tot een location proxy_pass http://name zegt. Dezelfde pool kan door veel locations en veel server-blokken worden gebruikt.
Passieve health checks, stap voor stap
Als een verzoek naar een server mislukt op een manier die proxy_next_upstream meetelt, probeert nginx het opnieuw op de volgende server en noteert het de fout. Zodra een server max_fails fouten bereikt binnen het fail_timeout-venster, kiest nginx hem niet meer. Na fail_timeout stuurt het voorzichtig weer echte clientverzoeken, en bij succes komt de server terug in roulatie.
Omdat de checks meeliften op echt verkeer, kan een bezoeker de eerste mislukte poging treffen. Korte timeouts op proxy_connect_timeout houden die vertraging klein.
server-parameters en hun standaardwaarden
Parameters op een server-regel binnen upstream
Parameter
Standaard
Effect
weight=n
Relatief aandeel van de verzoeken
max_fails=n
Mislukte pogingen binnen fail_timeout voordat de server wordt overgeslagen; 0 schakelt uit
fail_timeout=time
Venster voor het tellen van fouten en hoe lang de server wordt overgeslagen
max_conns=n
0 (geen limiet)
Maximum aantal gelijktijdige actieve verbindingen met deze server
Alleen gebruikt als alle primaire servers onbereikbaar zijn
Markeert de server als permanent onbereikbaar
Complete voorbeelden
Round robin met een reserve
Twee primaire servers delen de last; de derde antwoordt alleen als beide uitvallen.
least_conn met hergebruikte verbindingen
keepalive bewaart inactieve verbindingen met de backends; de twee proxy-regels laten dat werken.
Cache-affiniteit op URL
Elke URL komt steeds op dezelfde cacheserver terecht; consistent houdt de meeste koppelingen intact als er een server bijkomt of wegvalt.
Naam van de upstream
Methode
Round robin (standaard)
Hash-sleutel
Inactieve keepalive-verbindingen (0 voor geen)
Servers
Adres en poort
Weight
fail_timeout (s)
Aandeel
Server {n} verwijderen
Server toevoegen
nginx weigert backup-servers bij hash, ip_hash en random. Verwijder de backup-flag of kies een andere methode.
Elke primaire server is als down gemarkeerd, dus niets kan verkeer ontvangen.