Shared Load Balancer

Objective

This guide explains how to use Shared Load Balancer on Ruk-Com Cloud PaaS, with ordered procedures and practical verification points.

Before you begin

• Sign in with an account permitted to manage the relevant environment.
• Confirm the target environment, region and resources before saving changes.
• Create a backup or rollback plan before changing a production system.

Ruk-Com Cloud Platform provides you with a Shared Load Balancer (resolver) representingNGINX proxy serverBetween the client side (e.g. browser) and your applications deployed to Ruk-Com Cloud.

The Shared LB process processes all incoming requests to the environment's domain name. The environment's domain. ({user_domain}.{hoster_domain}) where the entry point (balancer, application server, or even database) is not attached.public IPaddress

A shared LB processes requests to all applications residing on the same hardware node to protect against malicious attacks.DDoSShared Load Balancers are limited to 50 concurrent connections per requested source address.

Increasing High Availability of the system using a load-balancer Multiple simultaneous requests placed on different nodes to handle concurrent requests all store the data in the same place. This makes them fully interchangeable in case a problem occurs in one of the instances.

This allows multiple entry points for a user's environment to be deployed simultaneously, in this way the incoming load is efficiently distributed.

Note:We recommend using Shared Resolver for dev and test environments, and for production environments intended to handle high traffic use your own public IP to receive and process requests. It also allows for a number of additional options to your application that may help make it more secure (such as Custom SSL) and responsive (via custom domain attachments).

Monitoring Backend Health with Shared Load Balancer

Jelastic Shared Load Balancer continuously monitors server health. By checking the moduleNGINX upstreamWith the following settings:

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

This way all containers are "up" from the start. The system checks for availability every 15 seconds. If the container does not respond within 2 seconds, it is considered a failed check, and if it fails 3 times in a row, it changes the marker on the node to "down", while it checks successfully two times in a row - to "up".

For distributing traffic within a separate environment, a load balancer node is automatically added to topolopy when the number of application server instances is set to more than one (expandable).horizontal) Ruk-Com Cloud PaaS provides 4 load balancer stacks you can choose from, each with a specific health check configuration:

• NGINX- Check by running a simple tcp (e.g. checking the availability of required server ports) before routing user requests. If verification fails Will try the next node within the layer.
• HAProxy- Performs regular tcp checks (every 2 seconds by default), stores results in table of backend status and keeps them up to date.
• Apache Balancer- There is no health inspection procedure by default.
• Varnish- All backends are defined with the following parameters to configure the balancer (so it only checks health once per minute with a 30 second wait timeout):

probe = { .url = "/"; .timeout = 30s; .interval = 60s; .window = 5; .threshold = 2; } }

As you can see, the default health check settings can be manually adjusted to your needs (via the File Manager GUI or via SSH) according to the appropriate load balancer stack requirements - refer to the NGINX, HAProxy, Apache Balancer or Varnish documentation for details on the possible settings.

Deny Access via Shared Load Balancer

Ruk-Com Cloud PaaS provides a predefined option to disable access to environment nodes from the SLB, prohibiting access to containers on the default domain name with a single click. (without adding a public IP and modifying the firewall) just toggle the Access via SLB button in the topology wizard.

Note:When adding a Public IP, the platform automatically disables access through SLB for the same layer. We recommend using this configuration because it provides high security for your application. However, if necessary, you can re-enable access via SLB to use the two options simultaneously.

This option willActivatefor each layer by default This ensures the following functionality:

• Nodes can be accessed from the Shared Load Balancer through the environment domain name using the default ports (80, 8080, 8686, 8443, 4848, 4949, 7979).
• The appropriate Open Browser button will launch the service (e.g. database admin panel).
• The node link will be displayed in the email (if required).

you canDisabledSelf-service SLB access features:

• The node is not accessible from the Shared Load Balancer - the layer is separated from the SLB.
• Pages accessible through the Open in Browser button in the dashboard return the 403 Forbidden error instead of the intended page.
• Node links are not included in emails.
• access throughSSHand passendpointswill not be affected

For better visibility, the Access via SLB disabled layer is labeled on the dashboard.

Connecting to that node via the default URL returns the following error:

In this section below We have prepared some common usage examples for this feature:

• Turn off public access via SLB to nodes intended for internal access only (such as a database).
• Prohibit access via SLB to nodes with attached public IP addresses and custom domains.
• Define a topology that allows connections through the environment's load balancer but prohibits direct URL access to the container.

You can generally use Access via SLB for development and testing. However, we recommend disabling this feature for production applications.productionand use public IP with custom domain instead