Using a Load Balancing Server

What Is Load Balancing?

Load balancing spreads incoming network traffic across a group of backend servers to ensure satisfactory speed and optimized functioning. The group of backend servers is commonly called a server farm or server pool. The larger the server farm and the more optimized the load balancing, the less clients experience slowdown when one of the servers is down or overloaded.

High‑traffic websites serve thousands or even millions of people each day. Part of the service is displaying content, such as text, image, and video. Servers need to identify the data needed and deliver it reliably every single time.

Load balancing prevents a website from becoming crippled when there’s an overflow of requests. A load balancer sends requests to servers that can efficiently handle them to maximize speed and performance.

Load balancing is a fundamental tool for boosting app performance, delivering apps at scale, and deploying containers and microservices.

IP Hash

IP Hash (available for HTTP only) is a predefined variant of the Hash method, in which the hash is based on the client’s IP address. You set it with the ip_hash directive.

If the client has an IPv6 address, the hash is based on the entire address. If it has an IPv4 address, the hash is based on just the first three octets of the address. This is designed to optimize for ISP clients that are assigned IP addresses dynamically from a subnetwork (/24) range. In case of reboot or reconnection, the client’s address often changes to a different one in the /24 network range, but the connection still represents the same client, so there’s no reason to change the mapping to the server.

If, however, the majority of the traffic to your site is coming from clients on the same /24 network, IP Hash doesn’t make sense because it maps all clients to the same server. In that case (or if you want to hash on all four octets for another reason), instead use the Hash method with the $remote_addr variable.

Pros, Cons, and Use Cases IP Hash

The biggest drawback of these methods is that they are not guaranteed to distribute requests in equal numbers across servers, let alone balance load evenly. The hashing algorithm evenly divides the set of all possible hash values into “buckets”, one for each server in the upstream group, but there’s no way to predict whether the requests that actually occur will have hashes that are evenly distributed. Suppose, for example, that ten clients are accessing a site, and the IP Hash algorithm happens to associate the hash for seven of the IP addresses with web1, one with web2, and two with web3. The web1 server ends up receiving more than twice as many requests as the other servers combined.

So it makes sense to use IP Hash when the benefit of maintaining sessions outweighs the possibly bad effects of unbalanced load. They are the only form of session persistence available in NGINX.

There are a couple cases where IP Hash – and Hash when the client IP address is in the key – don’t work:

• When the client’s IP address can change during the session, for example when a mobile client switches from a WiFi network to a cellular one.
• When the requests from a large number of clients are passing through a forward proxy, because the proxy’s IP address is used for all of them.

Hashes are deterministic (the hashing algorithm yields the same results every time). This has a couple of positive side effects: all NGINX Plus or NGINX instances in a deployment load balance requests in exactly the same way, and the hash‑to‑server mapping persists across restarts of the load balancer. (It’s actually recalculated after the restart, but because the result is always the same it effectively persists.)

On the other hand, changing the set of upstream servers usually forces recalculation of at least some of the mappings, breaking session persistence. You can reduce the number of recalculated mappings somewhat:

• For the Hash method, include the consistent parameter to the hash directive; NGINX Plus uses the ketama hashing algorithm, which results in less remapping.
• For the IP Hash method, before removing a server from the upstream group temporarily, add the down parameter to its server directive, as for web2 in the following example. The mappings are not recalculated, on the assumption that the server will soon return to service.

Conclusions on the advantages of load balancing

If you wish to improve your web application performance and availability, a load balancer is definitely something to consider. Nginx is powerful yet relatively simple to set up to load balance web server. Together with an easy encryption solution, such as Let’s Encrypt client, it makes for a great front-end to your web farm.

Using a Database Server

Check mysql status and ensure it is working.

Finding database config file

Go to the document root of the website

check config file by,

# grep -Rl database_name ./*

check the output for php file where the database connection is configured.

Here ./common/config/main-local.php is the file.Open it with the editor.

check the line for dsn and configure mysql:host with the ip address.

‘dsn’ => ‘mysql:host=ip_address;

Using webservers

Copy the contents from the initial webserver(events-node-dev-1.media.mit.edu) where websites files were configured using rsync.

create a sync.sh script for rsync as follows in second and third webserver (events-node-dev-2.media.mit.edu) and add it to their crontabs.

#!/bin/sh

cd /var/www/html

rsync -av –delete rsync://18.27.79.207/backup//var/www/html/ ./
chown -R www-data:www-data /var/www/html