What is Shared Load Balancer and how it works under cloudjiffy Platform.

The CloudJiffy Platform provides me with a Shared Load Balancer (resolver). It represents an NGINX proxy serverbetween client side (browser, for example) and my application, deployed to the CloudJiffy Cloud.

Shared LB processes all incoming requests, sent to a domain name ({user_domain}.{hoster_domain}), where environment entry point (balancer, application server or even database) does not have a Public IP address attached.

The common Shared LB processes the requests, sent to all of the applications, located within the same hardware node. In order to be protected from DDoS attacks, Shared Load Balancer is limited to 50 simultaneous connections per the source address of the request.

To increase the high availability of the system, CloudJiffy uses several synchronized Load-Balancers, placed at different nodes, for handling requests simultaneously. All of them work with a single data storage, which makes them fully interchangeable in case of any issue occurs at one of the instances.

As a result, there can be several entry points for users' environments, used at the same time. In this way, the incoming load can be effectively distributed.

We recommend to use Shared Resolver for my dev and test environments. As for productionenvironments, which are intended to handle high traffic, it is more appropriate to use my own Public IP for getting and processing the requests. Also, it allows me to apply a number of additional options to my application, which may help to make it more secure (e.g. with Custom SSL) and responsive (through attaching Custom Domain).

Public IP vs Shared Load Balancer

Backend Health Check with Shared Load Balancer

CloudJiffy Shared Load Balancer performs constant servers’ health checkups, utilizing the NGINX upstream check module with the following settings for that:

interval=15000 rise=2 fall=3 timeout=2000 default_down=false;

In such a way, all containers are considered “up” from the startup, whilst the system verifies their availability each 15 seconds. If no response is received from a container within 2 seconds, such checkup is regarded as failed. Three consecutive fails will mark a node as “down”, whilst two successful checks in a row - as “up”.

As for the traffic distribution within a separate environment, a dedicated load balancer node is automatically added to its topology when the number of application server instances is set more than one (i.e. it’s scaled out horizontally). CloudJiffy PaaS provides 4 load balancer stacks I can choose between, each of which has some health check configuration specifics:

  • NGINX - runs a simple tcp check (i.e. verifies the required server port availability) right before routing a user request to it; if the check fails, the next node within a layer will be tried
  • HAProxy - performs regular tcp checks (every 2 seconds by default), storing the results in a table of backends state and keeping it constantly up-to-date
  • Apache Balancer - no implemented health check procedure by default
  • Varnish - all backends are assigned with the following parameters in balancer configs (so that the health checks are performed once per minute with a 30 seconds timeout):
    probe = { .url = "/"; .timeout = 30s; .interval = 60s; .window = 5; .threshold = 2; } }
Obviously, the default health check settings can be manually adjusted up to my needs (through either CloudJiffy File Manager GUI or via SSH) according to the appropriate load balancer stack specification - refer to the official NGINX, HAProxy, Apache Balancer or Varnish documentation to see the details on possible settings.

Was this article helpful?

mood_bad Dislike 0
mood Like 0
visibility Views: 11234