This chapter is from the book
This chapter is from the book
This chapter is from the book
Quick and Dirty Clustering
As previously mentioned, clusters are made up of two or more different machines (or processors) that serve the same application. Even though it takes a little more to make a full-fledged clustered solution for most applications, it's easy to bring basic services to most networks.
All Linux actually needs to be involved in a cluster is to talk to other machines in a network, which includes most of the machines out there. Put two boxes together that talk to each other, and you have a cluster—not a very effective cluster, mind you, but one that works. It's a simple matter, really, to enable basic clustering features to existing servers.
Dial Ping for Service
A basic HA cluster can be achieved with nothing more than straight ping. If you were to set up a script that would enable a failover server to ping a primary application server every minute or so, the failover server could determine when the primary failed. As soon as the secondary couldn't find the other server, it would assume that it was down and launch scripts to enable its own services. After all, if the failover server can't reach the primary, neither can any other service or user.
You need to consider some options before you start planning for your basic HA cluster. Are you going to have the failover server in standby mode with an application already running, ready to go? Is the standby server already in production with other elements running? Here's what you need to set up a basic HA cluster:
Script that will ping the other server.
Crontab entry to call the script.
If the other server responds, then sleep.
If the other server doesn't respond, ping again.
If the other server still doesn't respond, assume failover sequence.
Take over IP address of failed server.
The first step when implementing such a cluster is to assign a virtual IP to the servers. This serves as the floating address that resolves to a DNS entry. Initially, the primary server owns the IP and then the secondary assumes it after failover.
IP aliasing has to either have been compiled in the kernel or have been loaded as a module. The kernel configuration for 2.2.x kernels is under Networking Options, IP: Aliasing Support, and is unchecked by default. Module support is only available in 2.0.x kernels. 2.2.x kernels either have support compiled in or not.
The module that you'll be looking for is ip_alias. To insert it into the 2.0.x kernel, use the insmod command.
RedHat 7.1 default install allows for an IP alias right out of the box. A stock 6.2 does as well, yet Debian 2.2 doesn't, so check your distribution.
After IP aliasing is available, an extra alias (or several) can be added with the same ease as a regular IP. The format is
/sbin/ifconfig <interface>:<virtual number> <ip> netmask <netmask> up
For example,
/sbin/ifconfig eth0:1 172.16.0.1 netmask 255.255.0.0 up
brings up virtual interface one and attaches it to adapter eth0 with an IP of 172.16.0.1 and a class B /16 netmask. Assign the virtual interface to the interface of the primary server and make sure that this entry is resolved by DNS.
The next step includes setting up the failover script. This script, placed on the failover server, initially pings the primary server and exits if a response is given. If a response is not given, the program waits for 20 seconds and pings again. If the failover server doesn't receive a ping response from the primary a second time, the server then sets the virtual IP on itself and optionally sends out a notification. Don't forget to set the script executable.
#!/bin/bash
# Poor Man's Cluster
# Script to Test for Failover
#
host="172.16.0.2"
netmask="255.255.0.0"
while true; do
/bin/ping -c 5 -i 3 $host > /dev/null 2>&1
if [ $? -ge 1 ]; then
#This doesn't look good, let's test again.
/bin/ping -c 5 -i 3 $host > /dev/null 2>$1
if [ $? -ge 1 ]; then
# We need to assume host is really down. Assume
# failover sequence
/sbin/ifconfig eth0:1 $host netmask $netmask up
echo "$host is down. Please check immediately." > /bin/mail
-s "$host is down!" user@host.com
else
#second ping returned a value. Whew.
:
else
:
fi
done
The script should be able to run in the background and mail the designated user if a connectivity problem occurs. The script can easily be adapted to ping more than one host, if you're creative enough.
Load Balancing Using DNS Records
A quick and dirty way to enable load balancing can be achieved with simple A records in DNS. Although it presents itself as a dirty hack, enabling the same name with two or more different IP addresses does offer a measure of load balancing, albeit limited in scope. The same effect does not work, however, when enabling different IP addresses in /etc/hosts.
To illustrate, we have the following zone enabled:
[root@matrix named]# cat zone.dns
;
; Zone file for zone.com
;
@ IN SOA zone.com. postmaster.zone.com. (
19990913 ; serial
10800 ; refresh
3600 ; retry
604800 ; expire, seconds
86400 ) ; minimum, seconds
IN NS ns1.zone.com.
IN NS ns2.zone.com.
host1 IN A 10.2.2.10
host1 IN A 10.2.2.11
host1 IN A 10.2.2.12
In this example, each host carries the same domain name, yet the A record points to a different address. Pings of the machine show the following:
[root@matrix named]# ping host1
PING host1.zone.com (10.2.2.10) from 10.2.2.100 : 56(84) bytes of data.
[root@matrix
named]$ ping host1
PING host1.zone.com (10.2.2.11) from 10.2.2.100 : 56(84) bytes of data.
[root@matrix
named]$ ping host1
PING host1.zone.com (10.2.2.10) from 10.2.2.100 : 56(84) bytes of data.
[root@matrix named]$ ping host1
PING host1.zone.com (10.2.2.12) from 10.2.2.100 : 56(84) bytes of data.
As you can see, it's not a foolproof situation, but it does offer some method of load balancing between hosts.