A, HA cluster related terms
1. Node (node)
HA host running a separate process, called a node, the node is a core component of HA, running the operating system and high-availability software services on each node in a high availability cluster nodes have primary and secondary points, respectively termed master node / backup nodes, each node has a unique host name, and have their own set of resources, such as disks, file systems, network addresses and application services, usually on the primary node running one or more applications services, and in general to monitor the node standby state
2. Resources (resource)
A resource is an entity node can be controlled, and when a node fails, the other takes over these resources can be nodes, the HA cluster software, can be used as the resource entities are:
(1) disk partition, the file system
(2) IP address VIP
(3) Application Services
(4) NFS file system
3. Event (event)
That is something that may occur in the cluster, such as node system failure, network connectivity failure, network card failure, application failure, these things will happen resource node metastasis, HA test is carried out based on these things
4. The operation (action)
HA response mode, the action is controlled by a shell script, for example, when a node fails, the backup node will perform well in advance when an event occurs by setting script services shut down or start, and then takes over the failed node's resources
Two, keepalived Profile
keepalived under linux is a lightweight high-availability solution that achieved with HACMP similar functions, can achieve high availability service or network, but there are differences: hacmp is a professional, full-featured high availability software, it provides the basic functions needed for HA software, such as heartbeat and resources to take over the system detects the cluster service, shared ip address of the owner transferred between cluster nodes, etc., hacmp powerful, but relatively cumbersome to deploy and use, but also business software, compared with hacmp, keepalived mainly achieved through virtual routing redundancy high-availability features, although he did not hacmp powerful, but keepalived deployment using relatively simple, all configuration only needs a configuration file to complete.
Three, keepalived use
keepalived originally designed for the lvs, designed to monitor the status of each service node of the cluster system, which according to layer3,4 & 5 exchange mechanism to detect the status of each service node, if a service node is abnormal or faulty work , keepaived will be detected and removed from the service node failure cluster system appear, and after a failed node back to normal, keepalived service node and can automatically re-added to this cluster , the work all done automatically, without manual interventions need to be done manually just to repair the failed node.
keepalived later joined the VRRP function, VRRP is an acronym for Virtual Router Redundancy Protocol (Virtual Router Redundancy Protocol), the purpose of which appears to solve the problem of static routing single point of failure occurs, the network can be achieved through continuous VRRP, stable operation, therefore, on the one hand having servers keepalived condition monitoring and fault isolation functions, on the other hand also having a function of HA Cluster, the following details the procedure the VRRP
Four, VRRP protocol and working principle
In the real network environment, the communication between the host is done by configuring static routing, and the router between hosts event of failure, communication failure will occur, so in this communication mode, the router becomes a single bottleneck point, in order to solve this problem on the introduction of the VRRP
VRRP protocol is a protocol standby mode, the switching device can be transparently without affecting the data communication between the host network failures by VRRP, which involves two concepts: the physical router and virtual router
VRRP can be two or multiple physical routers into a virtual virtual router, the virtual router Virtual IP (one or more) provide services, two internal virtual router, multiple physical routers to work together, at the same time only one physical router to provide services, which physical router is called the master router (the state of master roles). It has a virtual ip provided externally, provide a variety of network functions, such as arp please, icmp, data forwarding, two other physical router does not have a virtual ip provide external nor provision of external network function, receives only vrrp state master advertisement information, these routers are collectively referred to as the backup router (in a backup role). When the primary router fails, the backup router in the backup role will be re-election, generate a new master router into the role of master of foreign service continues throughout the switching process is completely the same name for the user
In a virtual router, the router only in the master role would have been to send vrrp packet, the router is a backup role only accept master sent me a packet of information for monitoring master running, therefore, seize the master does not occur unless it is a higher priority, and when the master is unavailable, backup will not be able to receive master sent me a packet of information, so he recognized master fails, the backup will be followed by more than one election, the highest priority backup will become the new master, this election process and the role very quickly and, therefore, to ensure the continued availability of services
Five, keepalived architecture
keepaived is a highly modular software structure is simple, but highly scalable, below is keepalived architecture:
Can be seen, the architecture is divided into two layers keepalived as a whole, are user-space and kernel space layer layer. The following describes a detailed keepalived composition and functions implemented two-layer structure.
The core layer at the bottom of the space, and comprising ipvs netlink two modules. ipvs module is a third-party modules keepalived introduced, can be achieved based load balancing cluster ip through ipvs. ipvs included by default in lvs cluster software.
There is a misunderstanding, because the keepalived can work well together and ipvs, so many beginners think keepalived is a load-balancing software, this understanding is wrong
Kernel modules:
IPVS: is mainly used by IPVS integration with lvs, lvs is the core module, with a use of lvs
NETLINK: Realize the functions of some of the network
User Module: mainly used for high-availability
checker: check the service status
vrrp stack: high availability for DS
Six, keepalived installation and configuration
yum install keepalived
yum install keepalived default configuration file /etc/keepalived/keepalived.conf
Configuration files are divided into three categories:
(1) global configuration
(2) VRRP Configuration
(3) LVS Configuration
Based on availability follows mysql database or mariadb
! The Configuration File for keepalived
global_defs {
notification_email {
}
}
vrrp_script chk_mysql {#check_mysql is planned for the execution of the script from the name
script "/root/sh/check_mysql.sh" # specify the path to execute the script
interval 2 ## script execution interval, each detection time 2s
}
vrrp_instance HA_1 {
State the BACKUP
interface ens33
virtual_router_id 151
priority 100
advert_int. 1
nopreempt
authentication {
AUTH_TYPE the PASS
AUTH_PASS 1111
}
virtual_ipaddress {
192.168.254.250
}
track_script {
chk_mysql
}
}
High Availability Load Balancing configuration is based on the following web site
keepalived:
yum install keepalived
vim /etc/keepalived/keepalived.conf
! keepalived the Configuration File for
# global configuration
global_defs {
notification_email {
# recipient address
}
# mail server
}
VRRP configuration DS1
vrrp_instance VI_1 {
State MASTER # roles type MASTER | BACKUP
NIC interface ens33 # name
virtual_router_id 51 # virtual Router id (needs to be consistent with the BACKUP)
priority priority # 100
advert_int 1 # is not 1 second check once
#nopreempt # non-preemptive mode
authentication {
auth_type PASS # must be the same type of authentication between the master and slave
auth_pass # 1111 must be the same between the master and slave authentication password
}
virtual_ipaddress {
192.168.254.250 # virtual IP (VIP)
}
}
#LVS arranged
virtual_server 192.168.254.250 80 {
delay_loop health check. 3 # interval
lb_algo rr # load balance algorithm
lb_kind DR # forwarding rules load balancing
protocol tCP # protocol
ip and port real_server 192.168.254.18 80 {# real_server to monitor the
weight 1 # weights
TCP_CHECK {# tcp protocol based check
connect_timeout 3 # connection timeout
retry 3 # reconnect times
delay_before_retry 3 # reconnection interval
}
}
real_server 192.168.254.19 80 {
weight. 1
TCP_CHECK {
connect_timeout The. 3
the retry. 3
delay_before_retry. 3
}
}
}
Although the above-described configuration can prevent single points of failure of the RS, DS, but did not eliminate single points of failure, it is necessary to add a backup machine in DS
In the above-described configuration on the backup copy can scp keepalived.conf [email protected]: / etc / keepalived
We need to rewrite place:
state MASTER # roles type MASTER | BACKUP
priority 55 # priority (here you need to set a value smaller than the master machine)