In today's session, we learned about the concept of heartbeat and how it is used to network systems and services. We were assigned to setup a High Availability Heartbeat. (HA-HB).
The steps are the following:
1.) Step 1: Installing Heartbeat
I have installed heartbeat by typing in the following command in a terminal:
$ sudo apt-get install heartbeat
The result are as follows:
After installing heartbeat the next step is:
2.) Step 2: Configuration of the 3 files:
- ha.cf
- haresources
- authkeys
The first file that I configured was the ha.cf file, the following shows the contents of the ha.cf file:
The following lines have meaning and you can configure it according to what you prescribe.
Note: node server1 is the first node, whilst the second node is named node server2
bcast eth0
Specifies to use a broadcast heartbeat over the eth0 interface.
keepalive 2
Sets the time between heartbeats to 2 seconds.
warntime 10
Time in seconds before issuing a “late heartbeat” warning in the logs.
deadtime 30
Node is pronounced dead after 30 seconds.
initdead 120
With some configurations, the network takes some time to start working after a reboot. This is a separate “deadtime” to handle that case. It should be at least twice the normal deadtime.
udpport 694
Use port number 694 for bcast or ucast communication. This is the default, and the official IANA registered port number.
auto_failback on
The master listed in the haresources file holds all the resources until a failover, at which time the slave takes over. When auto_failback is set to on once the master comes back online, it will take everything back from the slave. When set to off this option will prevent the master node from re-acquiring cluster resources after a failover.
node ics user
Mandatory. Hostname of Primary machine in cluster.
node ics user
Mandatory. Hostname of Secondary machine in cluster.
debugfile /var/log/ha-debug
This is used to specify the path where Heartbeat’s debug logs will be stored.
logfile /var/log/ha-log
This is used to specify the path where Heartbeat’s general logs will be stored.
[Reference: http://theitaxis.wordpress.com/2009/11/14/heartbeat-a-step-by-step-configuration-guide-to-high-availability-linux-clusters/ ]
Since, other matters like deadtime, initdead, keepalive and warntime are not specified for us, I just used the default values for them.
Configuring haresources file:
The syntax are as follows:
[node-name] [ip address]/[subnet]/[interface]
You can configure this file, according to the preferences enlisted above.
Configuring authkeys:
After the configuration of the two files, the last file to be configured is authkeys.
To begin configuring authkeys, you must first be in the root for you to be permitted to edit the authkeys file. You could do this simply by typing in the command:
sudo -s
cd etc/ha.d
vi authkeys
These set of commands will let you edit the authkeys file, basically it just contains two lines which are as follows:
auth 1 --> 1 is the authentication method ID.
1 sha1 <password> none --> sha1 is the authentication method used, other methods include mdb5, and crc. none is the password that is set for authentication.
Note: If your heartbeat runs over a secure network, such as the crossover cable in our example, you’ll want to use crc. This is the cheapest method from a resources perspective. If the network is insecure, but you’re either not very paranoid or concerned about minimizing CPU resources, use md5. Finally, if you want the best authentication without regard for CPU resources, use sha1. It’s the hardest to crack.
4.) Step 4: Starting heartbeat services:
You could do this by typing in the following command:
$ /etc/init.d/heartbeat start
$ /etc/init.d/heartbeat stop
$ /etc/init.d/heartbeat restart
These other commands can also be used to stop or restart heartbeat services.
5.) Step 5: Testing Heartbeat
After Heartbeat services are running on both machines, both the machines will monitor to each other.
To test if the services are actually working, we did the following test runs:
Primary machine and secondary machine are allowed to run their heartbeat services for a while.
A third machine (having an IP in the same range and same subnet mask) is made to ping the IP address of Primary machine. After a while, the Primary machine is physically isolated from the given network. (We did this by pulling off the Ethernet cord). As soon as the Primary machine is taken out, the ping windows displays ‘Request timed out..’ in reply to its requests.
After a given interval of time (defined by warntime, deadtime, initdead) the ping window starts getting replies from the Primary machine’s IP again. What actually happened was, in the time interval, the Secondary machine got to know that its Primary machine is not sending heartbeats and therefore concludes that Primary is down. So the secondary acquires the resources of the Primary and starts serving any requests to the Primary’s IP.
Note: If it weren’t for Heartbeat, the ping window would have shown ‘Destination Host Unreachable’ when the primary was taken off.
[Reference: http://theitaxis.wordpress.com/2009/11/14/heartbeat-a-step-by-step-configuration-guide-to-high-availability-linux-clusters/ ]
Since this result, we confirmed that the heartbeat services made it possible for the both servers accessing one another.
Additional Blog entries:
1. What are the problems encountered?
Problems encountered: Installing and setting up heartbeat without any knowledge of it at all, The only resource was the Internet and inability to understand the steps provided and how they work became a problem too while configuring the files for heartbeat. For the first two weeks, we were unguided and we didn't know what to do. We didn't know if what we're doing is right or wrong therefore we haven't accomplished the exercise well. When we were given instructions to do what it is to do, things became quite clear for us and has manage to somehow make it work.
2. What are your insights about HA-HB?
HA-HB is a practical tool for web services that needs to have a 24/7 service. With HA-HB, Even though the primary server is down and couldn't reply to the request of the client, a secondary server can easily reply to that request while listening to the primary server's "heartbeat"
3. State your ideas about the (possible) real world application of HA-HB? (Specific)
For web servers that wants to continue services even though the primary server is down. A secondary server or back-up server is needed for seamlessly requesting web services. Example of the real-world application that can use this or is already using this would be: UPLB's SystemOne, UP Diliman's CRS and the likes. Since during registration time, the servers would be up and running, it is better to have a back up or secondary server and an HA-HB service. This will guarantee developers and users to a seamless connection between clients and servers. which is crucial especially in registration time.
4. What can you say about the mode of "discussion", allowing yourself to discover firsthand the configuration for HA-HB?
Although I do understand that this mode of discussion will let the instructors gauge as to how independent we are in terms of learning new things on our own, It is still quite an issue for us since we cannot fully grasp the meaning of the things we are doing. We may have successfully done what it is to be done in a certain exercise but most parts of it, we cannot understand how it happened. I still prefer an in-depth discussion on each exercise and how things should be done properly. The mode of discussion that is most preferable for me is that the instructor will give us steps on how to do it properly, and we will follow. As we follow, we will discover things we cannot understand. And then, the instructor will interrupt us and discuss the matter comprehensively. it would be much fun also if the activity would be done by partners, groups or as a class and all of us would give out our opinions on the subject matter. For me, It is difficult to understand the topic when we are left by ourselves. There are different interpretations and ways of installations and configurations in the Internet and it's quite hard for us to determine what was really the right configuration to be done. Nonetheless, I still learn by myself; but I do hope that this topic would further be explained by our Instructor or Lecturer.
References:
http://theitaxis.wordpress.com/2009/11/14/heartbeat-a-step-by-step-configuration-guide-to-high-availability-linux-clusters/



























