Keepalived of Linux High-availability cluster--(1) __linux

Linux high Availability (HA) cluster keepalived detailed 2013-08-22 16:18:34 tags: Linux HA high available cluster keepalived Detailed original works, allow reprint, reprint, please be sure to hyperlink form to indicate the original source of the article, author information And this statement. Otherwise, legal liability will be held. http://freeloda.blog.51cto.com/2033581/1280962

Outline

First, the preface

Second, keepalived detailed

Iii. Environmental Preparedness

Four, lvs+keepalived realize the high availability front-end load balancer

First, the preface

        This article is a summary of the previous articles, we first brief summary of the content we explained earlier, we explained, LVS (Load balancer), Heartbeat, Corosync, Pacemaker, High-availability Web cluster, MySQL high availability cluster, Drdb, iSCSI, GFS2, CLVM, and so on, the only did not explain is the LVS available, that is, the front-end high availability, we this blog mainly explain the content. Before we say this we have to discuss a problem with you, but also a lot of Bo friends ask questions. Heartbeat, Corosync, keepalived these three cluster components what do we choose, first of all, I would like to state that Heartbeat, Corosync are of the same type, keepalived and Heartbeat, Corosync, are not of the same type at all. Keepalived uses VRRP protocol, virtual Routing Redundancy Protocol (fictitious Router redundancy Protocol, VRRP), Heartbeat or Corosync is a highly available way of host-based or network services , simply put, the purpose of keepalived is to simulate the high availability of routers, heartbeat or corosync to achieve high availability of service. So the general keepalived is to achieve the front-end high availability, commonly used in the front-end high availability of the combination has, is our common lvs+keepalived, nginx+keepalived, haproxy+keepalived. While Heartbeat or Corosync is a highly available service implementation, common combinations have Heartbeat v3 (Corosync) +pacemaker+nfs+httpd to achieve high availability of Web servers, Heartbeat v3 (Corosync) +pacemaker+nfs+mysql to achieve high availability of MySQL server. To sum up, lightweight, high availability in keepalived is generally used for front-end high availability and does not require shared storage, which is generally used for high availability of two nodes. Heartbeat (or corosync) are generally used for high availability of services and require shared storage, which is generally used for high availability of multiple nodes. This question we said understand, and Bo friends will ask, that Heartbaet and corosync we should choose which good ah, I would like to say we generally use corosync, because the Corosync operating mechanism is better than heartbeat, Even the pacemaker separated from Heartbeat said that in the future developmentIt's more likely to be corosync, so now Corosync+pacemaker is the best combination. But to be honest, I didn't have any inclination for the software, so I talked to everyone about the cluster software, I think that no matter what software, as long as it can survive all have its characteristics and application areas, only the specific software in a specific location to play the greatest role, then first we have to have all the knowledge of the software. The best way to learn a software is to check the official document. All right, say so much hope that we have some harvest, the following we say a keepalived.

Second, keepalived detailed

1.Keepalived definition

Keepalived is a high availability scheme for LVS services based on the VRRP protocol, which can be used to avoid single points of failure. A LVS service will have 2 servers running keepalived, one primary server (MASTER), one for backup servers (backups), but externally represented as a virtual IP, the primary server will send specific messages to the backup server, when the backup server does not receive this message, That is, when the primary server is down, the backup server takes over the virtual IP and continues to provide the service, thus ensuring high availability. Keepalived is the perfect implementation of VRRP, so before introducing keepalived, introduce the principle of VRRP first.

Introduction to 2.VRRP protocol

In a real-world network environment, two hosts that need to communicate do not have a direct physical connection in most cases. For such cases, the routing between them is a choice. How the host chooses the next hop route to reach the destination host, there are two common solutions to this problem:

Use dynamic routing protocols (RIP, OSPF, etc.) on the host

Configuring static routes on the host

Clearly, it is impractical to configure dynamic routing on the host because of the many issues of management, maintenance costs, and support. It becomes very popular to configure static routes, but routers (or default gateways) often become single points of failure. The purpose of VRRP is to solve the problem of single point of static route fault, VRRP through a campaign (election) protocol to the dynamic routing task to a LAN in the virtual router VRRP router.

3.VRRP working mechanism

In a VRRP virtual router, there are more than one physical VRRP router, but this multiple physical machines do not work at the same time, but are routed by one called Master, and the rest are backup,master not immutable, VRRP let each VRRP router to participate in the campaign, the final victory is master. Master has some privileges, such as the IP address of a virtual router, which our host uses as a static route. The privileged Master is responsible for forwarding packets sent to the gateway address and responding to ARP requests.

VRRP implements the function of the virtual router through the campaign protocol, and all protocol messages are sent in the form of IP multicast (multicast) packets (multicast address 224.0.0.18). The virtual router consists of Vrid (range 0-255) and a set of IP addresses, which are externally represented as a well-known MAC address. Therefore, in a virtual router, regardless of who is master, the external is the same Mac and IP (called VIP). The client host does not need to modify its routing configuration because of master changes, which is transparent to the client.

In a virtual router, only the VRRP router as master will always send VRRP notification information (Vrrpadvertisement message), and backup will not preempt master unless its priority (priority) is higher. When Master is unavailable (backup does not receive notification information), the highest priority in multiple backup is preempted to master. This preemption is very fast (<1s) to ensure continuity of service. Because of security considerations, the VRRP package uses the encryption protocol for encryption.

4.VRRP Work Flow

(1). Initialize:
When the router is started, if the router has a priority of 255 (the highest priority, the router has the router address), send the VRRP notification information, and send the broadcast ARP information to the router IP address of the corresponding MAC address for the routing virtual Mac, set the notification information timer ready to send VRRP notification information , or into the backup state, set the timer check to check whether to receive the notification information of master.

(2). Master

Setting timer for timing notification;

Using VRRP virtual MAC address to respond to ARP request of router IP address;

Forwarding Purpose Mac is a VRRP virtual Mac packet;

If the owner of the virtual router IP, will accept the destination address is a virtual router IP packet, otherwise discarded;

When the Shutdown event is received, the timer is deleted and the notification packet with priority level 0 is sent to initialize the state;

If timed notification timer timed out, send VRRP notification information;

When received VRRP notification information, if the priority is 0, send VRRP notice information, otherwise judge the priority of the data is higher than the local, or equal and the actual IP address is greater than the actual IP, set timer notification timer, reset the host timeout timer, to backup status; otherwise, discard the notice packet;

(3). Backup

Set the host timeout timer;

Cannot respond to ARP request information for virtual router IP;

Discard all destination MAC address is a virtual router MAC address packet;

Does not accept all packets that are intended to be a virtual router IP;

When the Shutdown event is received, the host timeout timer is deleted and the initialization state is initialized;

When the host timeout timer times out, send VRRP notification information, broadcast ARP address information, turn master State;

When receiving the VRRP notification information, if the priority is 0, to enter the master election, otherwise the priority of the data is higher than the local, if the high recognition of master effective, reset the host timeout timer, otherwise, discard the notification package;

5.ARP Query Processing

When the internal host through the ARP query virtual router IP address of the corresponding MAC address, the master router reply MAC address is virtual VRRP MAC address, rather than the actual network card MAC address, so that when the router switch so that the intranet machine is not aware; and when the router restarts, You cannot actively send the actual MAC address of the native network card. If the virtual router opens the ARP Proxy (proxy_arp) function, the proxy ARP response also responds to the VRRP virtual MAC address; OK VRRP simple explanation to here, we come down to explain the case of keepalived.

Iii. Environmental Preparedness

1. Operating system

CentOS 6.4 x86_64

2. Software version

Ipvsadm.x86_64 0:1.25-10.el6

Keepalived.x86_64 0:1.2.7-3.el6

Httpd-2.2.15-29.el6.centos.x86_64

3. Experimental topology

4. Time synchronization

Node1:

1	[Root@node1 ~] # ntpdate 202.120.2.101

Node2:

1	[Root@node2 ~] # ntpdate 202.120.2.101