haproxy+keepalived achieve high Availability load balancing (theory) _linux

Haproxy compared to the use of LVS is much simpler, functional aspects are also very rich. Currently, Haproxy supports two main proxy modes: "TCP" is also 4 layers (mostly for mail servers, internal protocol communications Servers, etc.), and 7 tiers (HTTP). In 4-tier mode, Haproxy only forwards bidirectional traffic between the client and the server. In 7-tier mode, the Haproxy analyzes the protocol and can control the protocol by allowing, rejecting, exchanging, adding, modifying, or deleting requests or responding to the specified content (response), based on specific rules.

I now use haproxy mainly because it has the following advantages, here I conclude:

First, free open source, stability is also very good, this can be done by some of my small projects can be seen, single haproxy also run well, stability can be comparable with LVS;
Second, according to the official documents, Haproxy can run full 10gbps-new benchmark of haproxy at a Gbps using myricom ' s 10GbE NICs (myri-10g pci-express), which as a software-level load Balanced, but also more astonishing;
Third, Haproxy can be used as MySQL, mail or other non-web load balancing, we often use it as a MySQL (read) load balancing;
Four, with a strong monitoring server status of the page, the actual environment we combine Nagios Mail or SMS alarm, this is also I like it one of the reasons;
Five, Haproxy support virtual host.

When doing a load balancing of a reverse proxy server, we usually use a nginx balanced configuration. In fact, the load balance of haproxy also belongs to this kind of. So let's take a look at the configuration process in this area now. First of all, a simple introduction to the Haproxy, followed by the installation and configuration links.

Haproxy Introduction

Reverse proxy server, support dual-machine hot standby support virtual host, but its simple configuration, has a very good server health check function, when its proxy back-end server failure, Haproxy will automatically remove the server, failback and then automatically join the server ｡ The new 1.3 introduced frontend,backend;frontend to make a rule match based on the contents of any HTTP request headers, and then directed the request to the relevant backend.
HTTP://BLOG.LIUTS.COM/POST/223/(build four-layer load balancer)
http://rfyimcool.blog.51cto.com/1030776/413187 (build seven-layer load balancer)

keepalived Introduction　　

http://www.keepalived.org
Keepalived is a software similar to the Layer3, 4 & 5 switch system, which is the 3rd, 4th, and 5th Exchange that we normally say. The role of keepalived is to detect the state of the Web server, if a Web server crashes, or if work fails, keepalived detects and removes the failed Web server from the system. When the Web server is working properly, Keepalived automatically joins the Web server into the server farm, all of which are done automatically, without human intervention, and only the Web server that repairs the failure needs to be done manually.

Similar HA tools and Heatbeat, DRBD, heatbeat, DRBD configuration are more complex.

keepalived Theory of working principle

Keepalived can provide VRRP and Health-check functions, can only use it to provide dual-machine floating VIP (VRRP virtual routing function), this can be simple to achieve a dual-machine hot standby high availability features.
Keepalived is a software similar to the Layer3, 4 & 5 switch system, which is the 3rd, 4th, and 5th Exchange that we normally say. The role of keepalived is to detect the state of the Web server. Layer3,4&5 work in the IP/TCP protocol stack IP layer, TCP layer, and application layer, the principle is as follows:

Layer3:keepalived when working with Layer3, keepalived periodically to servers in the server farm

Sending an ICMP packet (a ping program that we normally use), and if we find that the IP address of a service is not activated, keepalived reports that the server is invalidated and removes it from the server farm, a typical example of which is a server being shut down illegally. The LAYER3 approach is to use the server's IP address as a standard for whether the server is working properly or not. This approach will be used in this article.

Layer4: If you understand the Layer3 way, Layer4 is easy. The Layer4 mainly determines whether the server is working properly or not in the state of the TCP port. A Web server's service port is typically 80, and if Keepalived detects that 80 ports are not booting, keepalived will remove the server from the server farm.

LAYER5:LAYER5 is working in the specific application layer, more complex than layer3,layer4, the bandwidth used on the network is also larger. Keepalived will be based on user settings to check whether the server program is operating normally, if the user's settings do not match, then keepalived will remove the server from the server group.

VIP is the virtual IP, is attached to the host network card, that is, the host network card virtual, this IP is still occupied by this network segment of an IP.

keepalived function

With the increase in your website's business volume, the pressure on your site's servers is getting bigger? Need load Balancing Solution! Business hardware such as F5 and too expensive, you are entrepreneurial interconnected companies how to effectively save costs, save unnecessary waste? To achieve the same high performance and highly available functionality as commercial hardware? Is there any good load balancing to deliver scalable solutions? The answer is YES! Yes! We use Lvs+keepalived's architecture based on full open source software to provide you with a load-balanced and highly available server.

lvs+keepalived Introduction

Lvs

LVS is a short version of Linux virtual Server, which means the Linux VM, is a virtual server cluster system. Founded in May 1998 by Dr. Zhangwensong, this project is one of the earliest free software projects in China. There are currently three IP load Balancing technologies (Vs/nat, Vs/tun and VS/DR) eight scheduling algorithms (RR,WRR,LC,WLC,LBLC,LBLCR,DH, SH).

Keepalvied

Keepalived is used here primarily as a realserver health check and a failover implementation between the LoadBalance host and the backup host. keepalived Introduction Keepalived is a similar to Layer3, 4 & 5 switch system software, that is, we usually say the 3rd layer, the 4th and the 5th layer Exchange. The role of keepalived is to detect the state of the Web server, if a Web server crashes, or if work fails, keepalived detects and removes the failed Web server from the system. When the Web server is working properly, Keepalived automatically joins the Web server into the server farm, all of which are done automatically, without human intervention, and only the Web server that repairs the failure needs to be done manually.

keepalived Introduction

Keepalived is a highly available Web services solution based on the VRRP protocol that can be used to avoid a single point of failure. A Web service will have at least 2 servers running keepalived, one primary server (MASTER), one for backup server (backup), but externally represented as a virtual IP, the primary server will send a specific message 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.

1 +-------------VIP (192.168.0.7)------------------+

2 |                           | |

3 |                           | |

4 Server (MASTER) <----keepalived----> Server (BACKUP)

5 (192.168.0.1) (192.168.0.2)

Keepalived is the perfect implementation of VRRP, so before introducing keepalived, introduce the principle of VRRP first.

Introduction to VRRP protocol

In a real-world network environment, two hosts that need to communicate do not have a direct physical connection in most cases. In such cases, how do they choose between routes? 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

It is obvious that it is impractical to configure a routing route on the host because of the problems of management, maintenance costs, and support. It becomes very popular to configure static routes, but routers (or default gateways) often become single points.

The purpose of VRRP is to solve the problem of single point fault in static routing.

VRRP through a campaign (election) protocol to dynamically give routing tasks to a VRRP router in a virtual router in the LAN.

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). Client hosts do not need to modify their routing configuration because master changes, and for them this master-slave switch is transparent.

In a virtual router, only the VRRP router as master will always send the VRRP ad packet (vrrpadvertisement message), and backup will not preempt master unless its priority (priority) is higher. When Master is unavailable (backup does not receive the ad package), 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.

VRRP Introduction
With the rapid development of Internet, the application of network is increasing gradually. This puts more and more demands on the reliability of the network. The cost of updating all network devices is certainly a good reliability solution; But in the context of protecting existing investments, the idea of cheap redundancy can be used to find a balance between reliability and economics.

Virtual Routing Redundancy Protocol is a very good solution. In the agreement, a redundant backup of a terminal IP device (default gateway) on a shared, multiple access media (such as Ethernet), so that when one of the routed devices is down, the backup routing device takes over the forwarding work in time, providing transparent switching to the user and improving the quality of the network service.

I. Overview of the Agreement

In a TCP/IP protocol based network, routing must be specified in order to ensure communication between devices that are not physically connected. There are two common ways to specify routes: Dynamic learning via routing protocols (e.g., internal routing protocol RIP and OSPF), and static configuration. It is unrealistic to run dynamic routing protocols at every terminal, and most client operating system platforms do not support dynamic routing protocols, even though support is limited by many problems such as management overhead, convergence, security, and so on. Therefore, the general use of the terminal IP device static routing configuration, is generally to the terminal device to specify one or more default gateway (Defaults gateway). Static routing simplifies the complexity of network management and reduces the communication overhead of terminal equipment, but it still has one drawback: if the router that is the default gateway is corrupted, all traffic using the gateway for the next hop host must be interrupted. Even if you have more than one default gateway configured, you cannot switch to a new gateway without restarting the terminal device. Virtual Router Redundancy Protocol, short VRRP, is a good method to avoid the defect of static designation Gateway.

In the VRRP protocol, there are two important sets of concepts: the VRRP router and the virtual router, the master router, and the backup router. VRRP router refers to the router that runs VRRP, is the physical entity, the virtual router refers to the VRRP protocol creation, is the logical concept. A group of VRRP routers work together to form a virtual router. The virtual router is externally represented as a logical router with a unique fixed IP address and MAC address. Routers in the same VRRP group have two mutually exclusive roles: The master router and the backup router, a router in the VRRP group with only one master role, and one or more routers in the backup role. The VRRP protocol uses the selection policy to select one of the router groups as the master, responsible for ARP corresponding and forwarding IP packets, and other routers in the group as backup roles on standby. When the host router fails for some reason, the backup router can upgrade to the main router after a few seconds of delay. Because this switch is very fast and does not change the IP address and MAC address, it is transparent to the end-user system.

Second, the principle of work

A VRRP router has a unique identifier: Vrid, with a range of 0-255. The router behaves as a unique virtual MAC address, and the address is formatted as 00-00-5e-00-01-[vrid]. The master router is responsible for responding to ARP requests with this MAC address. In this way, regardless of switching, to ensure that the terminal equipment is the only consistent IP and MAC address, reducing the impact of switching on terminal equipment.

There is only one VRRP control message: VRRP notice (advertisement). It uses IP multicast packets for encapsulation, with a group address of 224.0.0.18, and the publication scope is limited to the same LAN. This ensures that Vrid can be reused in different networks. In order to reduce network bandwidth consumption, only the main control router can periodically send VRRP notification packets. The backup router launches a new round of VRRP elections after a three consecutive notification interval without VRRP or a notification of priority 0.

In the VRRP router group, the primary router is elected by priority, with a priority range of 0-255 in the VRRP protocol. If the IP address of the VRRP router is the same as the interface IP address of the virtual router, the virtual router is said to be the owner of the IP address in the VRRP group, and the IP address owner automatically has the highest priority: 255. Priority 0 is typically used when the IP address owner voluntarily abandons the master role. The configurable priority range is 1-254. Priority configuration principles can be set based on the speed and cost of the link, router performance and reliability, and other management policies. In the election of the master router, the high priority virtual router wins, so if you have an IP address owner in the VRRP group, it always appears as a master route role. For the candidate routers of the same priority, they are elected according to the IP address size order. VRRP also provides a preemptive preemption policy, and if configured, a High-priority backup router robs the current low-priority master router and becomes the new master router.

In order to guarantee the security of VRRP protocol, two kinds of security authentication measures are provided: PlainText authentication and IP header authentication. PlainText authentication requirements: When joining a VRRP router group, you must also provide the same vrid and plaintext password. It is suitable for avoiding configuration errors in the LAN, but it does not prevent access to the password through the network listening mode. IP header authentication provides a higher level of security and can prevent attacks such as message replay and modification.

Iii. Examples of application

The most typical VRRP applications: RTA, RTB composed of a VRRP router group, assuming that the RTB processing capacity is higher than RTA, then the RTB configured as the IP address owner, H1, H2, H3 default gateway set to RTB. Then RTB becomes the main control router, which is responsible for ICMP redirect, ARP reply and IP message forwarding. Once the RTB fails, RTA immediately initiates the switch and becomes the master, thus ensuring a transparent security switch to the customer.

In VRRP application, RTA online RTB only as back-up, not participate in forwarding work, idle router RTA and link L1. Through reasonable network design, can reach the double effect of backup and load sharing. Let RTA and RTB belong to two VRRP groups that are mutually backed up: The RTA is the IP address owner in Group 1, and the IP address owner in Group 2 RTB. Set the default gateway for the H1 to Rta;h2, H3, and RTB. In this way, both the equipment load and network traffic are shared, and the network reliability is improved.

The working mechanism of the VRRP protocol has much in common with Cisco's HSRP (Hot Standby Routing Protocol). But the main difference is that in Cisco's HSRP, you need to configure an IP address as the external address of the virtual router, which cannot be the interface address of any member of the group.

Using the VRRP protocol, it is not necessary to transform the current network structure, to maximize the protection of current investment, only the minimum management costs, but greatly enhance the network performance, has great application value.

===================================================================================
Simple application of keepalive--managing VIP's fluttering
From:http://www.cnblogs.com/killkill/archive/2010/12/31/1922360.html

VIP fluttering can solve a lot of problems for us, before I tried to use Ifup/ifdown way to control the network card Up/down to achieve, this way there is a small problem, is every time after the VIP flap to wait for a few 10 seconds to take effect, feeling longer, And with some logical scripts to work well, is there a better way? Of course, this is the protagonist of this article--keepalived.

The installation is simple:

Copy Code code as follows:

Tar zxvf keepalived-1.1.20.tar.gz
CD keepalived-1.1.20
./configure--prefix=/
Make
Make install

Modify/etc/keepalived/keepalived.conf This configuration file can be used, the following is my environment, 192.168.10.141 and 192.168.10.142 are two VIP, can be between two servers fluttering:

Configuration of Host:

Copy Code code as follows:

Global_defs {
Notification_email {
Failover@firewall.loc
}
Notification_email_from Alexandre.Cassen@firewall.loc
Smtp_server 192.168.0.48
Smtp_connect_timeout 10
router_id Nginx
}

Vrrp_instance vi_141 {
State BACKUP
Interface eth0
VIRTUAL_ROUTER_ID 141
Priority 50
Advert_int 1
Authentication {
Auth_type Pass
Auth_pass 141
}
virtual_ipaddress {
192.168.10.141/26 Dev eth0
}
}

Vrrp_instance vi_142 {
State BACKUP
Interface eth0
VIRTUAL_ROUTER_ID 142
Priority 100
Advert_int 1
Authentication {
Auth_type Pass
Auth_pass 142
}
virtual_ipaddress {
192.168.10.142/26 Dev eth0
}
}

Configuration of Standby machine:

Copy Code code as follows:

Global_defs {
Notification_email {
Failover@firewall.loc
}
Notification_email_from Alexandre.Cassen@firewall.loc
Smtp_server 10.168.0.48
Smtp_connect_timeout 10
router_id Nginx
}

Vrrp_instance vi_141 {
State BACKUP
Interface eth0
VIRTUAL_ROUTER_ID 141
Priority 100
Advert_int 1
Authentication {
Auth_type Pass
Auth_pass 141
}
virtual_ipaddress {
192.168.10.141/26 Dev eth0
}
}

Vrrp_instance vi_142 {
State BACKUP
Interface eth0
VIRTUAL_ROUTER_ID 142
Priority 50
Advert_int 1
Authentication {
Auth_type Pass
Auth_pass 142
}
virtual_ipaddress {
192.168.10.142/26 Dev eth0
}
}

At first glance, the host and standby configuration file is the same, carefully look at the value of priority, use the following command to join the keepalived Linux services:

Copy Code code as follows:

Chkconfig--add keepalived;

Through the opening, stop keepalived This service can observe the VIP's fluttering, as to why the VIP after the fluttering can quickly come into effect, still need to study.

Haproxy+keepalived to achieve high availability load balancing
My environment:
Haproxy keepalived Master: 192.168.1.192
Haproxy keepalived Preparation: 192.168.1.193
vip:192.168.1.200
Web:192.168.1.187:80 192.168.1.187:8000

One: Installation process, on the 192.168.1.192:

Installation of keepalived:

Copy Code code as follows:

#tar-ZXVF keepalived-1.1.17.tar.gz
#ln-S/usr/src/kernels/2.6.18-128.el5-i686//usr/src/linux
#cd keepalived-1.1.17
#./configure--prefix=/--mandir=/usr/local/share/man/--with-kernel-dir=/usr/src/kernels/2.6.18-128.el5-i686/
#make && make Install
#cd/etc/keepalived/
#mv keepalived.conf Keepalived.conf.default
#vi keepalived.conf
! Configuration File for Keepalived

Vrrp_script Chk_http_port {
Script "/etc/keepalived/check_haproxy.sh"
Interval 2
Weight 2

Global_defs {
router_id Lvs_devel
}
Vrrp_instance Vi_1 {
Change state MASTER #192.168.1.193 to Backup
Interface eth0
VIRTUAL_ROUTER_ID 51
Priority #192.168.1.193 to 120
Advert_int 1
Authentication {
Auth_type Pass
Auth_pass 1111
}

Track_script {
Chk_http_port
}

virtual_ipaddress {
192.168.1.200
}
}
}

#vi/etc/keepalived/check_haproxy.sh
#!/bin/bash
A= ' ps-c haproxy--no-header |wc-l '
If [$A-eq 0];then
/usr/local/haproxy/sbin/haproxy-f/usr/local/haproxy/conf/haproxy.cfg
Sleep 3
If [' Ps-c haproxy--no-header |wc-l '-eq 0];then
/etc/init.d/keepalived stop
Fi
Fi
#chmod 755/etc/keepalived/check_haproxy.sh

Haproxy installation (same as Master):

Copy Code code as follows:

#tar-ZXVF haproxy-1.4.9.tar.gz
#cd haproxy-1.4.9
#make target=linux26 prefix=/usr/local/haproxy Install
#cd/usr/local/haproxy/
#mkdir conf Logs
#cd conf
#vi haproxy.cfg
Global
Log 127.0.0.1 Local3 Info
Maxconn 4096
User Nobody
Group Nobody
Daemon
Nbproc 1
Pidfile/usr/local/haproxy/logs/haproxy.pid

Defaults
Maxconn 2000
Contimeout 5000
Clitimeout 30000
Srvtimeout 30000
Mode http
Log Global
Log 127.0.0.1 Local3 Info
Stats Uri/admin?stats
Option Forwardfor

Frontend Http_server
Bind:80
Log Global
Default_backend Info_cache
ACL Test Hdr_dom (host)-I test.domain.com
Use_backend cache_test if test

Backend Info_cache
#balance Roundrobin
Balance Source
Option Httpchk Head/haproxy.txt http/1.1\r\nhost:192.168.1.187
Server Inst2 192.168.1.187:80 check Inter 5000 fall 3

Backend Cache_test
Balance Roundrobin
#balance Source
Option Httpchk Head/haproxy.txt http/1.1\r\nhost:test.domain.com
Server Inst1 192.168.1.187:8000 check Inter 5000 fall 3

Two: On both machines are started separately:

/etc/init.d/keepalived start (This command will automatically start the Haproxy)

Third: Test:

1. Execute IP add separately on two machines
Main: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> MTU 1500 Qdisc pfifo_fast Qlen 1000
Link/ether 00:0c:29:98:cd:c0 BRD FF:FF:FF:FF:FF:FF
inet 192.168.1.192/24 BRD 192.168.1.255 Scope Global eth0
inet 192.168.1.200/32 Scope Global eth0
Inet6 FE80::20C:29FF:FE98:CDC0/64 Scope link
Valid_lft Forever Preferred_lft Forever

Preparation: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> MTU 1500 Qdisc pfifo_fast Qlen 1000
Link/ether 00:0c:29:a6:0c:7e BRD FF:FF:FF:FF:FF:FF
inet 192.168.1.193/24 BRD 255.255.255.254 Scope Global eth0
Inet6 FE80::20C:29FF:FEA6:C7E/64 Scope link
Valid_lft Forever Preferred_lft Forever

2. After haproxy,3 seconds, keepalived will automatically start it again.
3. Stop the main keepalived, standby machine immediately take over the service
Preparation: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> MTU 1500 Qdisc pfifo_fast Qlen 1000
Link/ether 00:0c:29:a6:0c:7e BRD FF:FF:FF:FF:FF:FF
inet 192.168.1.193/24 BRD 255.255.255.254 Scope Global eth0
inet 192.168.1.200/32 Scope Global eth0
Inet6 FE80::20C:29FF:FEA6:C7E/64 Scope link
Valid_lft Forever Preferred_lft Forever

4. Change of hosts
192.168.1.200 test.com
192.168.1.200 test.domain.com
Through IE testing, you can find
Test.com's request was sent to 192.168.1.187:80.
Test.domain.com's request was sent to 192.168.1.187:8000.