The CirrusGrid Platform provides you with a Shared Load Balancer (resolver). It represents an NGINX proxy server between client side (browser, for example) and your application, deployed to the CirrusGrid Cloud.
Shared LB processes all incoming requests, sent to an environment domain name ({user_domain}.qloud.asia), which 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, CirrusGrid 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.
Tip: We recommend to use Shared Resolver 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 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).
CirrusGrid 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” 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). CirrusGrid PaaS provides 4 load balancer stacks you can choose between, each of which has some health check configuration specifics:
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 CirrusGrid File Manager GUI) 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.
CirrusGrid PaaS 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: When adding a Public IP, the platform automatically disables Access via SLB for the same layer. Such configs are recommended as they 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 ensured the following behavior:
You can manually disable the Access via SLB feature:
For better visibility, layers with the disabled SLB access are provided with the appropriate label in the dashboard.
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 to disable the feature for the application in production and use public IP with custom domain instead.
Powered by BetterDocs
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.