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

Shared Load Balancer

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, BitssCloud 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 your dev and test environments. As for productionenvironments, which are intended to handle high traffic, it is more appropriate to use your own Public IP for getting and processing the requests. Also, it allows you to apply a number of additional options to your application, which may help to make it more secure (e.g. with Custom SSL) and responsive (through attaching Custom Domain).

Backend Health Check with Shared Load Balancer

BitssCloud 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). BitssCloud PaaS provides 4 load balancer stacks you 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 your needs (through either BitssCloud 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.