Articles with tag 'Hardware'

Why Load Balance Network Services?

Most network installations have their current network services such as  DNS, NIS, NTPD, CUPSD, and multiple APACHE servers  all running on seperate  physical servers.  Natural balancing of all of these services is difficult, if not impossible due to the nature of how  often these services are accessed and the resources each service require to perform their function. You quickly notice that while some servers may be overloaded at some regular points of each day; most of your infrastructure servers are hardly utilized at all.  It is nice to see that the load on any specific server is low (around 0.01), but what that actually means; is that server is not doing anything most of the time. This means that your servers are wasting resources like electricity and cooling as well as valuable space in your server room. You need all of theses services available all the time so your facility can function. But how can can we even out the load across servers to maintain a consistent load and reduce slowdowns during peak periods?

Many people have been using ro investigating a VMWare solution to consolidate these services on a single machine, however; you usually need fsufficient funds tn order to purchase a large server that has more power than you will ever need to compensate for the overhead of all the individual VMWare instances you will need to load. Then, to be safe, you will need a second one of these overpowered machines for protection in the event your main VMWare fsrver fails. This secondary machine needs to be just as powerful to load all the instances you had running on your primary server. So, you end up having a very powerfull and expensive machines sitting 100% idle all the time which again is a total waste of production (most of the time).

In our case, we didn't have the luxury of purchasing new servers for all our aging infrastructure.  We did have some old render nodes that (individually) were not powerfull enough to run all the services we require with everyone accessing them all day, (as well as the additional load required to server our renderfarm) but we had a lot of them. We could go back and just upgrade each of our existing servers, but we would still be stuck with an unbalanced infrastructure. Load Balancing Network Services is what we decided to do.

Benefits of Load Balancing

• Load Balancing hardware is cheap, less than cost of a regular server (approximately $2,000)
• Automatically detemines which nodes are available to balance users evenly amongst servers
• Each server is accessed by the same number of users at any given time (evenly distributed load)
• All servers are set up exactly the same and can be scripted so you can easily add new nodes as required
• If a server fails, all your services are still up and running (just a little slower until machine rebuilt/replaced)
• All servers don't need to have the same amount of power (Load Balancer lets you set % between machines)
• You can use older available servers to increase your cluster load potential without additional costs
• You can upgrade machines in the cluster without having to switch or take services off-line

How-To Setup A Load Balanced Network Services

In our studio, we simply created a master server for services like DNS and NIS that only talks to the cluster of servers that will be behind the Load Balancer.  This server is only accessed by a couple of people on our Systems team and the slave servers in the Load Balanced cluster. All the other machines and render nodes in our facility access the Load Balance cluster machines to talk to the services. We also created an installation script for all the Load Balanced Servers using XCAT (eXtreme Cluster Administration Tools) the same way we do for all of our render nodes. The Load Balanced servers are set up as slaves for both DNS and NIS so they keep up to date automatically whenever the master is changed.  Configuring the Load Balancer itself was quite simple, we didn't have to change any IP's for the servers in the cluster, create additional VLANs, we practically just plugged the Load Balancer hardware into our CORE switch and configure it to point to the machines we wanted in the cluster (this took about 15 minutes). For APACHE services, instead of running all the web code in /srv/www/ on the local machines as we have always done in the past, we created soft links to a network share, this way all code can be updated in one location (our network share also gives us the benefits of snapshots and being backed up), but all servers in the cluster are automatically updated. These features of the installation setup also add to the simplicity of adding or rebuilding servers in the cluster as most of the configuration is static. Just make sure that whenever you do make a change to any of the services, make sure you also update your installation script.

Basically, all the servers are set up from the same script and installed exactly the same way, we use DHCP on all of these machines so they get different names and IP's (hardcodes in DHCP so they always get the same IP). The Load Balancer then checks to see which nodes are available and all services are evenly distributed to one of them. The clients all point to the load balancer for all their requests and it just forward them to the machine it decides they should use. This way all servers are relatively working at the same load as one another all of the time they are being used.

If one of your servers is having a problem, just re-install it from the scripts, or take it off-line. Your services will still be running, just on less machines. As a bonus feature since all servers are the same and installed using a script, there is no need to back up any of the individual servers on the cluster.

If your servers are getting overloaded, just add more machines to the cluster. Your Load Balancer will allow you to control the percentage a certain server so if you have more powerful machines, you can keep the load evenly distributed for future growth.

One last thing to note, this will only work if the services that are capable of load balancing. You database server and your render manager for instance won't work in this situation, these services have enough load on them individually to keep them on their own server as we have always done in the past. Some of your Apache services might have to be changed a little depending on how you control authentication and session management.

Happy Load Balancing.