The platform utilizes several Shared Load Balancer (SLB) infrastructure components to process all incoming requests (except direct connections via public IP) sent to the hosted environments. SLB is an NGINX proxy server that connects the client-side (browser, for example) and your applications deployed to the platform.
So, Shared Load Balancers process requests from outside the platform and navigate them over the internal network to connect to the required applications. SLB is also limited to 50 simultaneous connections per the request’s source address to prevent DDoS attacks.
To ensure the platform’s high availability, it uses several synchronized Shared Load Balancers (placed at different hosts) for handling requests simultaneously. All of them work with the same data storage so that they are fully interchangeable if one of the instances goes down.
As a result, there can be several entry points for users' environments, and the incoming load can be efficiently distributed.
Note: We recommend using SLB for your dev and test environments. As for production environments, 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 several additional options to your application, making it more secure (e.g. with Custom SSL) and responsive (through attaching Custom Domain).
The platform Shared Load Balancer performs constant servers' health checkups, utilizing the NGINX upstream check module with the following settings for that:
check interval=15000 rise=2 fall=3 timeout=2000 default_down=false;
In such a way, all containers are considered “up” after SLB starts. Then the system verifies nodes' availability every 15 seconds. If no response is received from a container within 2 seconds, such checkup is regarded as failed. Three consecutive fails mark a node as “down” and two successful checks in a row - as “up”.
Tip: If an environment has several backends (application servers), the dedicated load balancer nodes are automatically added to manage traffic and perform health checks.
The platform provides a predefined option to disable external access to environment nodes from SLB. It prohibits access to containers over their default domain names with a single click (without public IP addition and firewall adjustment). An option is available as the Access via SLB toggle in the topology wizard.
Note: The platform automatically disables Access via SLB for the layer after adding a Public IP. Such configs are recommended to provide the highest security level for your application. However, in case of necessity, you can re-enable Access via SLB to use both options simultaneously.
The option is enabled for each layer by default, which ensures the following behavior:
Connecting to such nodes via the default URL will return the following error page instead of the default service:
Below, we’ve prepared some of the most frequent use case examples for the feature:
In general, you can use the Access via SLB option for your development and testing environments. However, we recommend disabling the feature for the application in production and using public IP with a custom domain instead.