The reverse-proxy features load balancing capability enabling connections to be transferred to the available web server.
- In a reverse-proxy rule, you can setup multiple
backends.
By default, the method isRound-Robinusing theweightpolicy to distribute the load.
¶ Load-balancing method
- Click on the small button representing the balancing method
You have 4 available method on the drop-down Method list:
- Round Robin – Requests are transfered evenly across the backends, with backend weights taken into consideration
- Least Connections - The smallest number of active connections, using the weight of the backends.
If there are several such backends, they are tried in turn using a weighted round-robin balancing method. - Strict hashed IP - Requests are distributed between the backends according to the client 's IP address.
The first three bytes of the customer's IPv4 address, or the entire IPv6 address, are used as the hash key.
This method ensures that requests from the same client will always be forwarded to the same server, unless the latter is unavailable.
In the latter case, client requests will be forwarded to another server.
In all likelihood, this will always be the same server. - Cookie - Client-server mapping is based on the value of the hashed key.
The key used is a cookie generated by the reverse proxy.
This cookie has a lifetime defined by the "Cookie (Seconds)" field.
This method ensures that requests from the same browser will always be forwarded to the same backend, unless the latter is unavailable.
In all likelihood, this will always be the same server.
Note: Adding or removing a server from the group may result in most keys being reassigned to different servers.
When backends provide a Web application that uses a session system stored by the Web application, it's imperative to use Strict hashed IP or Cookie method
The difference between strictly hashed IP and the Cookie method is that session keeping for the first option is based on the client's public IP, whereas the Cookie method is browser-based.
So, if you want to keep a session in a world where DHCP changes regularly, or where the reverse-proxy is behind equipment that masks source IP addresses (NAT, Load-balancer), the cookie method will be preferred.
¶ Zone:
Is the size of the shared memory area that holds the backend selection configuration and execution state that are shared between work processes.
It is not possible to recommend an ideal memory zone size, as usage patterns vary considerably.
The amount of memory required is determined by which features (such as session persistence, health checks or DNS reset) are enabled and how upstream servers are identified.
¶ Adding a backend
When you add or edit a backend rule, you have several options:
¶ Hostname or IP address / port
You can set a fully hostname ( www.domain.tld ) or a IP address.
When you specify a host name, the reverse proxy will resolve the name to retrieve the IP address.
An additional trick is to provide specific DNS servers that would be in charge of giving it a different backend IP address with an algorythm that better meets your expectations.
¶ Use the SSL encryption
If the backend only wants to receive SSL connections, you can specify that the reverse-proxy must use the SSL protocol to transfer requests.
Usually, it's preferable to use HTTP only, as SSL and certificates are handled by the reverse-proxy.
If you mix SSL backends with HTTP backends, Artica will have to separate the flows into two distinct groups.
One for the HTTP flow and the other for the SSL flow.
Using two separate backends for each protocol will not balance the flows.
4 backends, two HTTP and two SSL, will then offer the balancing mode
¶ The Weight value:
By default, the reverse-proxy distributes requests among the servers in according to their weights using the Round Robin method.
The weight parameter to the server directive sets the weight of a server (the default weight is 1).
Basically, the weight indicates the number of requests the web server will receive before switching to the next server:
let's say we have 3 backends:
- 1.2.3.4:80 with a weight of 10
- 1.2.3.5:80 with a weight of 5
- 1.2.3.6:80 with a weight of 1
Out of 16 requests, 1.2.3.4 will receive 10 requests, then 1.2.3.5 with 5 requests and 1.2.3.6 with 1 request
¶ Failure Timeout:
set the duration during which the specified number of unsuccessful attempts to communicate with the backend must occur for the server to be considered unavailable and the period during which the backend will be considered unavailable.
¶ Max Failure:
Defines the number of unsuccessful attempts to communicate with the server that must occur within the duration defined by the Failure timeout parameter before the server is considered unavailable for a duration also defined by the Failure timeout parameter.
¶ Backup:
marks the backend as a backup.
It will receive requests when the primary backends are unavailable.
It is like a Fail-Over method
¶ Down:
Marks the server as permanently unavailable.