0

I have the following setup in my datacenter.

Global LB --> HA proxy (2 instances on different servers via VRRP, performs HTTPS termination, acts as reverse proxy) ---> Nginx(2 instances on different server, load balanced by HA proxy in round robin, acts as reverse proxy and load balances between tomcat) ---> tomcat( 2 instances, load balanced by each Nginx)

The scenario is as follows:

Global Load balancer receives 100 HTTPS requests/sec. It forwards those 100 requests to HA Proxy. HA proxy performs HTTPS termination and load balances 50 http requests/sec to each nginx. Each Nginx forwards 25 requests/sec to two tomcat instances.

My question has 3 parts regarding to in-flight requests:

  1. Recover from failure of Nginx: in the above scenario, nginx acting as reverse proxy, load balanced requests to two tomcat servers. Say the machine on which nginx goes down, will it result in failure of 50 requests? As the two tomcat servers can only forward response to nginx, but that nginx is down.
  2. Recover from failure of HAProxy: HAProxy that had terminated 100 https connection dies. The passive HAProxy will become active, but the https connections will not migrate to the new active HAProxy. what happens in this case? will it result in loss of all 100 requests
  3. Recover from tomcat failure: If tomcat fails with 25 requests per second, will those 25 requests be transferred to second tomcat instance?

Is there a way to configure stack so that failure in pts 1 and 2 will not result in requests failure?

0

Most sane way to do this is to make your application aware of the stack and let it handle any failures.

0

In all instances, the connections that are balanced during the timeout period will be lost (note that the number of lost connections will vary depending on at which point within the check period the failure actually occurred)

The browser (or your client app) is expected to reestablish https and/or retry the dropped connections. (don't forget that connections can be interrupted at any point between the client and the server, or even the user shutting down the browser/PC)

On the whole this should be transparent to the user but the webserver app should avoid repeating the same transaction when a given URL is rerequested, which is trivial, for example by passing a unique tranaction ID. This is good practice anyway.

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.