Using keepalived to realize dual machine hot standby

Source: Internet
Author: User
Tags reflector

Generally speaking, dual-machine hot standby refers to two machines are running, but not both machines are at the same time to provide services.
When one of the service providers fails, the other one will automatically take over and provide the service immediately, and the switch time is very short.
The following is a keepalived combined with Tomcat to implement a Web server's dual-machine hot standby.
The keepalived works by VRRP (virtual Router redundancy Protocol) VPN Routing Redundancy protocol.
There are two important sets of concepts in VRRP: VRRP routers and virtual routers, master routers, and backup routers.
A VRRP router is a router that runs VRRP, a physical entity, and a virtual router is a logical concept created by the VRRP protocol. A group of VRRP routers work together to form a virtual router. There is an electoral mechanism in the VRRP that selects the routing that provides the service, the master route, and the other is the backup route. When the master route fails, a master route is re-elected in the backup route to continue working to guarantee uninterrupted service.
The test environment we have in this article is as follows
Two physical servers and one virtual server (VIP):
Master:redhat 2.6.18-53.el5 192.168.8.4
Backup:redhat 2.6.18-53.el5 192.168.8.6
vip:192.168.8.100
The network topology diagram for the test environment is as follows:

Node A 192.168.8.4 (master node), Node B 192.168.8.6 (alternate node), virtual IP (IP 192.168.8.100 for external service)
In this mode, the virtual IP can only belong to one node at a time, and the other node exists as an alternate node.
When the primary node is unavailable, the standby node takes over the virtual IP (that is, the virtual IP drift to Node B) and provides normal service.
The principle of keepalived can be so simple to understand:
The keepalived is installed on two physical servers and monitors each other for normal operation.
When Node A is normal: keepalived on Node A will broadcast the following information:
192.168.8.100 the MAC address of this IP corresponds to the MAC address of the Node a network card
Other computers in the diagram, such as clients and NodeB, will update their ARP tables, corresponding to the MAC address of the 192.168.8.100 MAC address = Node A NIC.
When node A fails, the keepalived on Node B is detected and the following information is broadcast:
192.168.8.100 This IP corresponds to the MAC address of the Node B network card
The other computers in the diagram, such as the client, update their ARP table, corresponding to the MAC address of the 192.168.8.100 = Node B network card.

1, install the keepalived on the main standby machine,
The steps are as follows: Download keepalived-1.1.15.tar.gz, then unzip the installation
#tar ZXVF keepalived-1.1.15.tar.gz
#cd keepalived-1.1.15
#./configure
#make
#make Install
2, Configuration keepalived
The state master in the configuration determines the node as the primary node
Priority is prioritized, such as when there are multiple backup nodes, the priority value of the primary node after the failure of the takeover.
The master node is configured as follows:

 global_defs {router_id nodea}vrrp_instance vi_1 {State MASTER #设置为主服务器 
    interface   eth0 #监测网络接口 virtual_router_id /span>51   #主, have the same priority  100   # (master, Standby takes different priority, host value is large, the backup machine value is small, the higher the value the higher the priority) Advert_int  1   #VRRP multicast broadcast cycle seconds authentication {Auth_type PASS #VRRP认证方式, master must be consistent Auth_pass  1111   # (password)}virtual_ipaddress { 192.168 . 8.100 /24   #VRRP ha virtual address}  
View Code

The alternate node is configured as follows:

 global_defs {router_id nodeb}vrrp_instance vi_1 {State BACKUP #设置为主服务器 
    interface   eth0 #监测网络接口 virtual_router_id /span>51   #主, have the same priority  90   # (master, Standby takes different priority, host value is large, the backup machine value is small, the higher the value the higher the priority) Advert_int  1   #VRRP multicast broadcast cycle seconds authentication {Auth_type PASS #VRRP认证方式, master must be consistent Auth_pass  1111   # (password)}virtual_ipaddress { 192.168 . 8.100 /24   #VRRP ha virtual address}  
View Code

3, start keepalived:
Keepalived-d-f/usr/local/etc/keepalived/keepalived.conf
To view the log message:
Tail-f/var/log/messages
After starting master Node A, the log is: The ARP message is broadcast

[Email protected] ~]# tail-f/var/log/Messagessep -  on: $: inSrv4 keepalived_vrrp:configuration is using:34546Bytessep -  on: $: inSRV4 KEEPALIVED_VRRP:VRRP Sockpool: [IfIndex (2), Proto ( the), FD (8,9)]sep -  on: $: -srv4 keepalived_vrrp:vrrp_instance (vi_1) Transition to MASTER statesep -  on: $: tosrv4 keepalived_vrrp:vrrp_instance (vi_1) Entering MASTER statesep -  on: $: tosrv4 keepalived_vrrp:vrrp_instance (vi_1) setting protocol Vips.sep -  on: $: toSrv4 keepalived_vrrp:vrrp_instance (vi_1) sending gratuitous ARPs on eth0 for 192.168.8.100Sep -  on: $: toSRV4 Keepalived_vrrp:netlink Reflector Reports IP192.168.8.100Addedsep -  on: $: toSRV4 Keepalived_healthcheckers:netlink Reflector Reports IP192.168.8.100Addedsep -  on: $: toSrv4 avahi-daemon[4029]: RegisteringNewAddress record for 192.168.8.100On eth0. Sep -  on: $: $Srv4 keepalived_vrrp:vrrp_instance (vi_1) sending gratuitous ARPs on eth0 for 192.168.8.100
View Code

With the IP a command, you can see that 192.168.8.100/24 is bound to the eth0

[[Email protected] bin]# IP a1: Lo: <LOOPBACK,UP,LOWER_UP> MTU16436qdisc noqueue Link/loopbackxx:xx:xx:xx:xx:xxBrdxx:xx:xx:xx:xx:xxinet127.0.0.1/8Scope host lo inet6::1/ -Scope host Valid_lft forever Preferred_lft forever2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> MTU theQdisc Pfifo_fast Qlen +Link/etherxx: 0c: in: -: 2d:9d BRD ff:ff:ff:ff:ff:ff inet192.168.8.4/ -Brd192.168.8.255ScopeGlobaleth0 inet192.168.8.100/ -ScopeGlobalsecondary eth0 inet6 fe80::20c:29ff:fe50:2d9d/ -scope link Valid_lft forever Preferred_lft forever
View Code

The log after starting the alternate Node B is:

Sep -  on: -: toHadoopsrv keepalived_vrrp:configuration is using:34262Bytessep -  on: -: tohadoopsrv keepalived_vrrp:vrrp_instance (vi_1) Entering BACKUP statesep -  on: -: toHadoopsrv KEEPALIVED_VRRP:VRRP Sockpool: [IfIndex (2), Proto ( the), FD (7,8)]sep -  on: -: toHadoopsrv keepalived:starting VRRP child process, pid=20567
View Code

4. Install Tomcat on both machines, omit the installation steps
After the installation is complete, create an HTML file on Node A's machine as follows

 This  is The test page<br>from192.168. 8.4

The following URL verifies that the normal access
Http://192.168.8.4:8080/test/test.html

After the installation is complete, create an HTML file on Node B's machine as follows

 This  is The test page<br>from192.168. 8.6

The following URL verifies that the normal access
Http://192.168.8.6:8080/test/test.html
At the primary node, node A is accessed through the following URL when it is normal
192.168.8.100:8080/test/test.html
The returned content should be HTML on the master node

 This  is The test page<br>from192.168. 8.4

Stop the keepalived of Node A: Killall keepalived
Accessed through the following URL
192.168.8.100:8080/test/test.html
The content returned should be the content on the standby node

 This  is The test page<br>from192.168. 8.6

View log of Node B at the same time: Discovery Node B goes to primary node and broadcasts ARP messages

Sep -  on: -: -hadoopsrv keepalived_vrrp:vrrp_instance (vi_1) Transition to MASTER statesep -  on: -: $hadoopsrv keepalived_vrrp:vrrp_instance (vi_1) Entering MASTER statesep -  on: -: $hadoopsrv keepalived_vrrp:vrrp_instance (vi_1) setting protocol Vips.sep -  on: -: $Hadoopsrv keepalived_vrrp:vrrp_instance (vi_1) sending gratuitous ARPs on eth0 for 192.168.8.100Sep -  on: -: $Hadoopsrv avahi-daemon[3769]: RegisteringNewAddress record for 192.168.8.100On eth0. Sep -  on: -: -Hadoopsrv keepalived_vrrp:vrrp_instance (vi_1) sending gratuitous ARPs on eth0 for 192.168.8.100

Using keepalived to realize dual machine hot standby

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.