1. heartbeat is a software package that implements the HA function (currently, heartbeat only supports dual-host ha ). The principle is very simple. Set a primary server, set a resource that requires ha, and connect other machines (called backup server) to this server, backup servers keep receiving heartbeat from the primary server. Once heartbeat is interrupted, the backup server takes over.
2. In order to place the failure for communications between the primary server and the backup server, we recommend that you use multiple physical connections to connect two machines. For example, we can connect two machines with a direct Ethernet connection network cable and a serial cable. Here is an image, Attachment 1:
3. one advantage of using a serial port to connect machines is that if our primary server is attacked by hacker, hacker cannot log on to the backup server via telnet or SSH from the primary server, this ensures the security of the backup server and the normal operation of services.
4. partitioned clusters and stonith. partitioned cluster refers to this situation: if there is only one physical connection between primary and backup server, after this physical connection fails, both primary and backup server will think that the other party is invalid. Therefore, it is very dangerous for both machines to seize control of resources. To avoid this situation, there are two solutions: (1) Establish multiple physical connections, that is, the above. (2) setting up a mechanism (either through hardware or software) allows us to quickly shut down a server, this kind of mechanism is called stonith-Chinese is "Explosive head", Hoho. The heartbeat software can implement a stonith configuration to avoid the appearance of Partitioned cluster.
5. There are currently three types of Heartbeat Control Messages: heartbeats (sometimes called status messages), cluster transition message, and retransmission requests.
Heartbeats messages can be sent through broadcast, single transmission, and multicast. Each message is only 150 bytes long. We can control how long a message is published and how long it takes to receive it.
Cluster transition message is a type of recovery message. There are two such messages: IP-request and IP-request-resp. When the primary server can work properly, it sends a message IP-request to the backup server. After the backup server obtains the message, it releases the resources it controls and returns the IP-request-resp, finally, the primary server retrieves the resource control and starts the service.
Retransmission requests is called a rexmit-Request (or ns_rexmit) message. In this case, each Heartbeat message carries a sequence number, the backup server can determine whether heartbeat messages are continuous and correct. When the backup server receives an incorrect heartbeat, it will ask the primary server to resend a message without the sequence number, to ensure that the primary server works properly (no sequence number is required at this time, because you only need to verify that the primary server works properly, NS in ns_rexmit indicates the non sequence number.
6. In the Ethernet structure, heartbeat is sent through UDP. UDP ports can be defined in the/etc/ha. d/ha. cf file, and multicast addresses can also be defined in this file.
7. Currently, heartbeat only supports dual-host ha. However, we can connect multiple-to-ha servers to a single network segment. At this time, we need to note that the UDP ports for sending heartbeat to each ha server are different.
8. How heartbeat implements dual-host switching-secondary IP address or IP alias. The two methods work almost the same, but they are not the same during configuration. They will be discussed later. This technology is called IP address takeover (ipat). The following describes in detail how to implement service migration using these two methods.
9. the principle of secondary IP address and IP alias in implementing ha is the same, but the configuration method is not the same. One is through the ip command configuration, you can only view the configuration results by using IP commands. The other (IP alias) can be configured and viewed through ifconfig.
10. Now let's take a look at the implementation principle of HA (through secondary IP and IP alias ). There are two figures here. You can see them at first glance. See Appendix 1 and Appendix 2:
We can clearly see from the figure that, under normal circumstances, four IP addresses are configured on the primary server, and 10.1.1.1 is used as heartbeat with the backup server; 209.100.100.2 is the real IP address configured on the network card; 209.100.100.3, 209.100.100.4 are two secondary IP addresses (or IP alias), which are actually bound to the network card 209.100.100.2, in this way, we can configure services such as Sendmail and HTTP on the two "fake" IP addresses respectively, so that a server is regarded as two external servers, they are Sendmail and HTTP services, but they are actually a server in the background. At this time, the backup server is configured with two IP addresses, 10.1.1.2 for heartbeat, and 209.100.100.5 is the real IP address configured on the NIC.
Now, as shown in the second figure, when the primary server is down, the backup server is immediately configured with the 209.100.100.3 and 209.100.100.4 secondary IP addresses (or IP alias, the Sendmail and HTTP services were taken over immediately. In this way, HA is implemented. In addition to the IP address takover, the backup server also notifies the router to update the ARP table through a protocol named Garp, update the MAC address of the two IP addresses to the MAC address of the backup server Nic.
11. The following describes secondary IP and IP alias respectively. Run the following command to view the secondary IP Configuration:
# Ip addr show -- View
# Ip addr add 209.100.100.3/24 broadcast 209.100.100.255 Dev eth0 -- add a secondary IP address on eth0 to 209.100.100.3/255.255.255.0
# Ip addr del 209.100.100.3/24 broadcast 209.100.100.255 Dev eth0 -- delete the secondary IP address on eth0
However, when heartbeat is actually used in the future, we do not need to manually enter these commands, because heartbeat provides a script called ipaddr2, we only need to configure the secondary IP in the heartbeat configuration file. Then, the ipaddr2 script will automatically call the following command line for us.
12. Configure the IP alias using the following command:
# Ifconfig eth0: 0 209.100.100.3 netmask 255.255.255.0 up -- configure IP alias eth0: 0
# Ifconfig -- view the configuration of eth0: 0. the MAC address, interrupt, and resource usage are the same as those of eth0.
# Ifconfig eth0: 0 down -- remove IP alias
Like secondary ip, heartbeat provides a script called ipaddr to help us set the IP address alias. in addition, note that the IP address alias must be in the same subnet as the real IP address and cannot be in a cross-network segment.
13. Note !!! Do not place the commands mentioned above in the Linux system startup, because heartbeat will help us configure the secondary IP or IP alias (Configure/etc/HD. d/haresouces file). Therefore, you only need to ensure that heartbeat can be started when Linux is started. We do not need to manually configure them when Linux is started. 10 million notes !!
14. GARP -- gratuitous arp. As mentioned above, it is useless for the backup server to take over the IP address, because the ARP table of the router also contains the information about the IP address and Mac, the MAC address corresponding to these IP addresses must also be updated. In this case, heartbeat uses Garp in a strange way. The basic principle of heartbeat is as follows: heartbeat has a program called send_arp which sends an ARP broadcast. The IP address and MAC address to be queried in this broadcast, and the IP address of the response is put in. In this way, the ARP broadcast first asks "209.100.100.3 what is the MAC address of this IP address? ", Then, the broadcast automatically asks "the MAC address of the IP address 209.100.100.3 is xxxxxx". In this way, the router will update the ARP table.
15. The book is quite good. It provides a script for Garp implementation. This script will use the send_arp program:
-
Code: select all
-
#!/bin/bash
#
# iptakeover script
#
# Simple script to take over an IP address.
#
# Usage is "iptakeover {start|stop|status}"
#
# SENDARP is the program included with the Heartbeat program that
# sends out an ARP request. Send_arp usage is:
#
#
SENDARP="/usr/lib/heartbeat/send_arp"
#
# REALIP is the IP address for this NIC on your LAN.
#
REALIP="299.100.100.2"
#
# ROUTERIP is the IP address for your router.
#
ROUTER_IP="299.100.100.1"
#
# SECONDARYIP is the first IP alias for a service/resource.
#
SECONDARYIP1="299.100.100.3"
# or
#IPALIAS1="299.100.100.3"
#
# NETMASK is the netmask of this card.
#
NETMASK="24"
# or
# NETMASK="255.255.255.0"
#
BROADCAST="299.100.100.0"
#
# MACADDR is the hardware address for the NIC card.
# (You'll find it using the command "/sbin/ifconfig")
#
MACADDR="091230910990"
case $1 in
start)
# Make sure our primary IP is up
/sbin/ifconfig eth0 $REALIP up
# Associate the virtual IP address with this NIC
/sbin/ip addr add $SECONDARYIP1/$NETMASK broadcast $BROADCAST dev eth0
# Or, to create an IP alias instead of secondary IP address, use the
command:
# /sbin/ifconfig eth0:0 $IPALIAS1 netmask $NETMASK up
# Create a new default route directly to the router
/sbin/route add default gw $ROUTER_IP
# Now send out 5 Gratuitous ARP broadcasts (ffffffffffff)
# at two second intervals to tell the local computers to update
# their ARP tables.
$SENDARP -i 2000 -r 5 eth0 $SECONDARYIP1 $MACADDR $SECONDARYIP1 ffffffffffff
;;
stop)
# Take down the secondary IP address for the service/resource.
/sbin/ip addr del $SECONDARYIP1/$NETMASK broadcast $BROADCAST dev eth0
# or
/sbin/ifconfig eth0:0 down
;;
status)
# We check to see if we own the IPALIAS.
OWN_ALIAS=`ifconfig | grep $SECONDARYIP1`
if [ "$OWN_ALIAS" != "" ]; then
echo "OK"
else
echo "DOWN"
fi
;;
# End of the case statement.
esac
The above script clearly shows the content contained in the broadcast package and how to send the broadcast. We can use this script to confirm whether our network can accept the Garp broadcast. After Garp is complete, run the ifconfig command or log on to the vro and check the content of its ARP table to check whether Garp has taken effect.
16. The previous section describes how heartbeat implements dual-host switchover-through the takeover of IP addresses. Now we can see another very important part of the heartbeat principle-resource scripts. This script is written by ourselves and has only one purpose. In this way, heartbeat can precisely know the status of our application, so that heartbeat can complete its functions. For example, if we want heartbeat to monitor our HTTP service (when the HTTP service is down, we need to write a script to monitor the HTTP service, return different keywords to let heartbeat know the running status of our HTTP service.
17. A typical resource script is as follows:
-
Code: select all
-
#!/bin/bashcase $1 in
start)
commands to start my resource
;;
stop)
commands to stop my resource
;;
status)
commands to test if I own the resource
;;
*)
echo "Syntax incorrect. You need one of {start|stop|status}"
;;
esac
18. heartbeat requires a resource script to respond to at least three inputs: start, stop, and status. Start and Stop are used to control our resource for heartbeat; status is used to determine whether our resource is active for heartbeat, and heartbeat has such a requirement in the returned information of status, that is, in the return of status, A string such as OK, running, and running must be returned. Therefore, heartbeat considers the resource to be active and heartbeat considers the resource to be inactive, do not return a string like no OK or no running. In this case, heartbeat also considers the resource to be active, because heartbeat searches for OK and running in the string. String to identify. In addition, the return code of our resource script must be 0 to tell heartbeat that the script runs normally.
19. after we write such a resource script, heartbeat can know the situation of our resource, at the same time, you can also control this resource (the logic of resource is defined by ourselves in resource script ). Put the script in/etc/init. d directory or/etc/ha. d/resource. d directory, but do not put this script into startup, because heartbeat is responsible for helping us start and close the resource handle.
20. the book is considerate and provides some suggestions for the content of the resource script. For example, what we want to do now is the sendmail service, you can use the pidof command (RedHat and Suse have this command) to check whether the Sendmail process exists. In addition, you can also use the ip command or ifconfig command to check whether secondary IP address and IP alias are working properly. All these words written in resource script can help us determine whether our resource works normally and respond to the input of the key parameter status.
21. to sum up, we need to write a resource script, which is similar to/etc/init. d. This script must be able to input parameters handle start/stop/status to allow heartbeat to control our resource/service. In addition, do not put this script in the startup process, because when heartbeat is started, it will call this script to ensure that our resource/service can be started normally.
22. OK. The principles of Heartbeat have been completed. Next we will start to configure a heartbeat. There are three configuration files for heartbeat:
/Etc/ha. d/ha. cf
Specifies how the heartbeat daemons on each system communicate with each other.
/Etc/ha. d/haresources
Specifies which server shocould normally act as the primary server for a special resource and which server shoshould own the IP address that client computers will use to access the resource.
/Etc/ha. d/authkeys
Specifies how the heartbeat packets shocould be encrypted.
In the next chapter, we will start to configure a heartbeat.