1

I have NGINX as reverse proxy and two Apache as an upstream servers.

Whenever I visit example.com ( directed to NGINX ), both the Apache Servers are getting the GET request. It seems strange as NGINX by default works based on Round Robin method

Here is my configuration :-

upstream apache {
         server 172.18.0.164;
         server 172.18.8.18;
        }


location / {
       proxy_pass http://apache;
    }

Logs in Apache 1 machine :-

192.168.10.236 - - [05/Oct/2015:07:59:21 -0400] "GET / HTTP/1.0" 200

Logs in Apache 2 machine :-

172.18.8.97 - - [05/Oct/2015:11:59:27 +0000] "GET /wordpress/ HTTP/1.0"

  • The log excerpts you posted seem to show requests from two different sources, and they are being load-balanced (round-robin by default as you stated) to your two web servers. Am I seeing something wrong? – bentek Oct 5 '15 at 12:35
  • Actually they are the same source. I did not configure the mod_remoteip plugin for one of the machines so Apache 2 is actually giving the NGINX IP instead of client IP. – zealvora Oct 5 '15 at 12:47
  • 2
    They still appear to be a different request (/ versus /wordpress) and the timestamp is different. If you're expecting the same source to go to the same server, you need something to provide session affinity (which could be based on things like source ip (+ port) or a cookie... – Cameron Kerr Oct 5 '15 at 12:54
  • See answer below for enabling session persistence. – bentek Oct 5 '15 at 13:12
2

Straight from the Nginx Admin Guide:


Enabling Session Persistence

NGINX Plus supports three session persistence methods. The methods are set with the sticky directive.

The sticky cookie method. With this method, NGINX Plus adds a session cookie to the first response from the upstream group and identifies the server which has sent the response. When a client issues next request, it will contain the cookie value and NGINX Plus will route the request to the same upstream server:

upstream backend {
    server backend1.example.com;
    server backend2.example.com;

  sticky cookie srv_id expires=1h domain=.example.com path=/;
}

In the example, the srv_id parameter sets the name of the cookie which will be set or inspected. The optional expires parameter sets the time for the browser to keep the cookie. The optional domain parameter defines a domain for which the cookie is set. The optional path parameter defines the path for which the cookie is set. This is the simplest session persistence method.

The sticky route method. With this method, NGINX Plus will assign a “route” to the client when it receives the first request. All subsequent requests will be compared with the route parameter of the server directive to identify the server where requests will be proxied. The route information is taken from either cookie, or URI.

upstream backend {
    server backend1.example.com route=a;
    server backend2.example.com route=b;

    sticky route $route_cookie $route_uri;
}

The cookie learn method. With this method, NGINX Plus first finds session identifiers by inspecting requests and responses. Then NGINX Plus “learns” which upstream server corresponds to which session identifier. Generally, these identifiers are passed in a HTTP cookie. If a request contains a session identifier already “learned”, NGINX Plus will forward the request to the corresponding server:

upstream backend {
   server backend1.example.com;
   server backend2.example.com;

   sticky learn 
       create=$upstream_cookie_examplecookie
       lookup=$cookie_examplecookie
       zone=client_sessions:1m
       timeout=1h;
}

In the example, one of the upstream servers creates a session by setting the cookie “EXAMPLECOOKIE” in the response.

The obligatory parameter create specifies a variable that indicates how a new session is created. In our example, new sessions are created from the cookie “EXAMPLECOOKIE” sent by the upstream server.

The obligatory parameter lookup specifies how to search for existing sessions. In our example, existing sessions are searched in the cookie “EXAMPLECOOKIE” sent by the client.

The obligatory parameter zone specifies a shared memory zone where all information about sticky sessions is kept. In our example, the zone is named client_sessions and has the size of 1 megabyte.

This is a more sophisticated session persistence method as it does not require keeping any cookies on the client side: all info is kept server-side in the shared memory zone.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.