Ngnix as Load Balancer

Répartir les requêtes sur plusieurs serveurs backend:

upstream backend {
  server 172.17.0.2;
  server 172.17.0.3;
}

server {
 listen 80;
 server_name example.com
  location {
   proxy_pass http:// backend;
   proxy_set_header ...;
  }
}

la première requête sera transmise à 172.17.0.2
la seconde à 172.17.0.3

Health care:
the load balancer has to know when a backend server is up or down
there are 2 types of Heath check: Active Heath checks (only in Ngnix X paid version) and Passive heath check

If the upstream server is not responding or rejecting connexions, the passive health check will consider the server to be unhealthy.
si l'un des 2 serveur est down, ngnix attend 30 secondes durant lesquelles le traffic est envoyé aux autres serveurs, puis ré essaye de renvoyer le traffic au server down.

upstream backend {
  server 172.17.0.2;
  server 172.17.0.3 max_fails=2 fail_timeout=30s;
# ngnix will consider 172.17.0.3  down if more than 2 requests fail during 30s period of time
}

server {
 listen 80;
 server_name example.com
  location {
   proxy_pass http:// backend;
   proxy_set_header ...;
  }
}

Poids des backend servers:
When the weight parameter is specified for a server, the weight is accounted as part of the load balancing decision.

        upstream myapp1 {
            server srv1.example.com weight=3;
            server srv2.example.com;
            server srv3.example.com;
        }

With this configuration, every 5 new requests will be distributed across the application instances as the following: 3 requests will be directed to srv1, one request will go to srv2, and another one — to srv3.

pour envoyer les requêtes prioritairement au serveur qui a le moins de connexions:

        upstream myapp1 {
            least_conn;
            server srv1.example.com weight=3;
            server srv2.example.com;
            server srv3.example.com;
        }

# outils de test A/B
#https://www.nginx.com/blog/performing-a-b-testing-nginx-plus/