Installation configuration of high-performance cluster software keepalived

First, the installation process of keepalived

Keepalived installation is very simple, the following through the source code compiled to introduce the next keepalived installation process. First open the official website of Keepalived http://www.keepalived.org, which can be downloaded to various versions of keepalived, which is downloaded keepalived-1.2.12.tar.gz. Take the operating system environment Centos6.3 as an example, the keepalived installation steps are as follows:

[[email protected] app] #tar zxvf keepalived-1.2.12.tar.gz

[[email protected] app] #cd keepalived-1.2.12

[Email protected] keepalived-1.2.12]#./configure--sysconf=/etc \

>--with-kernel-dir=/usr/src/kernels/2.6.32-431.5.1.el6.x86_64

[[email protected] keepalived-1.2.12] #make

[[email protected] keepalived-1.2.12] #make Install

[[email protected] keepalived-1.2.12] #ln-S/usr/local/sbin/keepalived/sbin/

[Email protected] keepalived-1.2.12]# chkconfig--add keepalived

[Email protected] keepalived-1.2.12]# chkconfig--level keepalived on

In the compile option, "--sysconf" specifies the installation path of the keepalived profile, which is the path to/etc/keepalived/keepalived.conf; --with-kernel-dir "is a very important parameter, but this parameter is not to compile the keepalived into the kernel, but to specify the use of the kernel source of the header files, namely the Include directory. The "--with-kernel-dir" parameter is required only when using LVS, which is not required at other times.

The load module information in the keepalived output, where:

The use IPVS framework means using the IPVS framework, which is the Load Balancer module, followed by "Yes" to enable the IPVS feature. The Ipvs feature is typically enabled when building a high-availability load-balancing cluster, and if you are using only Keepalived's high-availability features, you do not need to enable the Ipvs module, and you can turn--disable-lvs off by "Ipvs" when compiling keepalived.

IPVS Sync Daemon Support means that the IPVS synchronization feature is enabled, which is typically used with the IPVS module and can be implemented with the "keepalived" parameter when compiling--DISABLE-LVS-SYNCD when it needs to be closed.

The IPVS use LIBNL represents a new version of the LIBNL. LIBNL is an implementation of NetLink, if you want to use the new version of LIBNL, you need to install LIBNL and Libnl-devel packages in your system.

The use VRRP framework indicates that the VRRP framework is used, which is a necessary module to implement keepalived high availability features.

Use VRRP Vmac represents the XMit VRRP package that uses the underlying VMAC interface, which is a new feature that is keepalived in the 1.2.10 version and later.

At this point, the installation of keepalived is complete. Below begins the explanation of the keepalived configuration.

Second,the global configuration of keepalived

During the installation of keepalived in the previous section, all configurations that specified the path of the keepalived configuration file to/etc/keepalived/keepalived.conf,keepalived are completed in this configuration file. Because of the many options that can be configured in the keepalived.conf file, the keepalived configuration is divided into three categories based on the functionality implemented by the configuration file: Global configuration, VRRPD configuration, and LVs configuration. Below you will mainly describe the meanings and usages of some of the common configuration options in the keepalived configuration file.

keepalived configuration files are organized in blocks (block), and each block's contents are contained in {}, with "#" and "!" The lines that begin are all comments. The global configuration is the configuration that takes effect for the entire keepalived, the basic content is as follows:

! Configuration File for Keepalived

Global_defs {

Notification_email {

[Email protected]

[Email protected]

}

Notification_email_from [email protected]

Smtp_server 192.168.200.1

Smtp_connect_timeout 30

router_id Lvs_devel

}

The global configuration is identified as "Global_defs", and in the "Global_defs" area are global configuration options, where:

Notification_email is used to set the alarm email address, you can set multiple, one per line. Note that if you want to turn on mail alerts, you need to turn on the SendMail service on this computer.

The notification_email_from is used to set the sending address of the message.

The smtp_server is used to set the SMTP server address of the message.

The smtp_connect_timeout is used to set the time-out for connecting to the SMTP server.

ROUTER_ID represents an identity that runs the keepalived server and is the information that is displayed in the subject of the message when the message is sent.

Third,the VRRPD configuration of keepalived

The VRRPD configuration is the core of all keepalived configurations and is used primarily to implement Keepalived's high-availability capabilities. Structurally, the VRRPD configuration can be divided into VRRP synchronization group configuration and VRRP instance configuration.

This first describes the main functions of the synchronization group implementation. The synchronization group is relative to multiple VRRP instances, in the context of multiple VRRP instances, the network environment for each VRRP instance is different, assuming that one instance is in segment A, the other instance is in Network segment B, and if VRRPD only configures the detection of a network segment, then when the B segment host fails , VRRPD will assume that it is still in a normal state and will not switch the main and standby nodes, so the problem arises. Synchronization groups are used to solve this problem, all VRRP instances are added to the synchronization group, so that any one instance of the problem, will cause the keepalived to make a primary standby switch.

The following is a sample configuration of two synchronization groups:

Vrrp_sync_group G1 {

Group {

Vi_1

Vi_2

Vi_5

}

Notify_backup "/usr/local/bin/vrrp.back arg1 arg2"

Notify_master "/usr/local/bin/vrrp.mast arg1 arg2"

Notify_fault "/usr/local/bin/vrrp.fault arg1 arg2"

}

Vrrp_sync_group G2 {

Group {

Vi_3

Vi_4

}

}

Among them, G1 synchronization group contains vi_1, Vi_2, vi_5 three VRRP instances, G2 Synchronization group contains vi_3, vi_4 two VRRP instances. These five instances will be defined in the Vrrp_instance segment. In addition, there are four options for Notify_master, Notify_backup, Notify_fault, and Notify_stop in the Vrrp_sync_group segment, which is a notification mechanism in the keepalived configuration. It is also the four states that keepalived contains. The meanings of each option are described below.

Notify_master: Specifies the script to be executed when Keepalived enters the master state, either as a status alert script or as a service management script. Keepalived allows the script to pass in parameters, so it is flexible.

Notify_backup: Specifies the script to be executed when keepalived enters the backup state, similarly, the script can be a status alarm script or a service management script.

Notify_fault: Specifies the script to execute when Keepalived enters the fault state, similar to the first two script functions.

Notify_stop: Specifies the script that needs to be executed when the Keepalived program terminates.

The following formally enters the configuration of the VRRP instance, which is the highly available feature of the configuration keepalived. VRRP instance segment is mainly used to configure the node role (master or slave), instance binding network interface, inter-node authentication mechanism, Cluster service IP, etc. Here is a sample configuration for instance vi_1.

Vrrp_instance Vi_1 {

State MASTER

Interface eth0

VIRTUAL_ROUTER_ID 51

Priority 100

Advert_int 1

Mcast_src_ip <IPADDR>

Garp_master_delay 10

Track_interface {

Eth0

Eth1

}

Authentication {

Auth_type PASS

Auth_pass QWASZX

}

virtual_ipaddress {

#<ipaddr>/<mask> brd <IPADDR> Dev <STRING> scope <SCOPT> label <LABEL>

192.168.200.16

192.168.200.17 Dev eth1

192.168.200.18 Dev eth2

}

virtual_routes {

#src <IPADDR> [to] <IPADDR>/<MASK> via|gw <IPADDR> Dev <STRING> scope <SCOPE>

SRC 192.168.100.1 to 192.168.109.0/24 via 192.168.200.254 Dev eth1

192.168.110.0/24 via 192.168.200.254 Dev eth1

192.168.111.0/24 Dev eth2

192.168.112.0/24 via 192.168.100.254

192.168.113.0/24 via 192.168.100.252 or 192.168.100.253

}

Nopreempt

Preemtp_delay 300

}

The above VRRP configuration with "Vrrp_instance" as the identity, in this instance contains several configuration options, respectively, described as follows:

Vrrp_instance is the identity at which the VRRP instance begins, followed by the VRRP instance name.

State is used to specify the role of keepalived, master indicates that this host is the primary server, and backup indicates that the host is a standby server.

The interface is used to specify an interface for the HA monitoring network.

VIRTUAL_ROUTER_ID is a virtual route identifier, which is a number that uses a unique identifier for the same VRRP instance, that is, master and backup must be consistent under the same vrrp_instance.

Priority is used to define node precedence, and the larger the number, the higher the priority of the node. Under a vrrp_instance, the priority of master must be greater than the priority of backup.

The advert_int is used to set the time interval between master and the backup host for synchronization checks, in seconds.

The MCAST_SRC_IP is used to set the address of the sending multicast packet, and if not set, the IP address corresponding to the bundled NIC will be used.

The garp_master_delay is used to set the time to delay the gratuitous ARP request after switching to the master state.

Track_interface is used to set up some additional network monitoring interfaces where any one of the network interfaces fails and keepalived enters the fault state.

Authentication is used to set communication authentication type and password between nodes, authentication type mainly has pass and AH two kinds, under one vrrp_instance, master and backup must use the same password to communicate properly.

The virtual_ipaddress is used to set the virtual IP address (VIP), also known as the Drift IP address. You can set multiple virtual IP addresses, one per line. This is called a drift IP address because the IP address is automatically added to the system when keepalived switches to the master state, and these IPs are automatically removed from the system when you switch to the backup state. Keepalived the VIP into the system in the form of an IP address add command. To view the VIP addresses added to the system, you can do so through the "IP Add" command. The IP form added in the "virtual_ipaddress" section can be a variety of forms, such as "192.168.16.189/24 Dev eth1", and keepalived uses the IP command "IP addr add 192.168.16.189/24 Dev eth1 "adds IP information to the system. Therefore, the rules for the configuration and the use of IP commands are consistent.

The Virtual_routes and virtual_ipaddress sections are used to set up or remove related routing information when switching. Use methods and examples to refer to the example above. The IP route command allows you to see if the routing information has been added successfully, and you can implement the same functionality in lieu of virtual_routes by the Notify_master option described above.

Nopreempt sets the non-preemption feature in a highly available cluster. In an HA cluster, if the primary node freezes, the standby node takes over, and the primary node normally automatically takes over the service when it starts again. This back-and-forth operation, for real-time and stability requirements of the business system is acceptable, and for stability and real-time requirements of high-performance business systems, not recommended to switch back and forth, after all, service switching there is a certain risk and instability, in this case, You need to set nopreempt this option. Setting the nopreempt allows the primary node to fail back to the primary node, allowing the service to work on the standby node until the backup node fails. When using no preemption, it can only be set on a node with the state status of "BACKUP", and the node must have a higher priority than the other nodes.

The preemtp_delay is used to set the preemption delay time, in seconds. Sometimes it takes some time for the network to work after the system starts or restarts, in which case the primary and standby switchover is not necessary, and this option is used to set the time interval for this to occur. Failures that occur during this time will not be toggled, and if the time specified by "Preemtp_delay" is exceeded and the network status is abnormal, the primary and standby switchover is initiated.

Four,keepalived of the LVS configuration

Because Keepalived is an extended project for LVS, Keepalived can seamlessly integrate with LVS to easily build a high-performance, load-balanced cluster system. The following describes the configuration method for the LVS configuration section in the next keepalived configuration file.

The LVS section is configured with "Virtual_server" as the starting mark, which consists of two parts, namely the Real_server segment and the Health detection section. Here is a sample configuration of the common options for the Virtual_server segment:

Virtual_server 192.168.12.200 80 {

Delay_loop 6

Lb_algo RR

Lb_kind DR

Persistence_timeout 50

Persistence_granularity <NETMASK>

Protocol TCP

Ha_suspend

VirtualHost <string>

Sorry_server <IPADDR> <PORT>

The meanings of each option are described below.

Virtual_server: Set the start of the virtual server, followed by the virtual IP address and the service port, between the IP and the port separated by a space.

Delay_loop: Sets the time interval for the health check, in seconds.

Lb_algo: Set the Load scheduling algorithm, the available scheduling algorithms are RR, WRR, LC, WLC, LBLC, sh, DH, etc., commonly used algorithms have RR and WLC.

Lb_kind: Set the LVS to achieve load balancing mechanism, with NAT, Tun and Dr three mode optional.

Persistence_timeout: Session hold time, unit is seconds. This option is useful for dynamic Web pages and provides a good solution for session sharing in a clustered system. With this session hold feature, the user's request is distributed to a service node until the session's hold time is exceeded. It is important to note that this session hold time is the maximum no response timeout, that is, when the user is working on a dynamic page, if no action is taken within 50 seconds, then the next operation is distributed to the other node, but if the user has been working on the dynamic page, it is not subject to a 50-second time limit.

Persistence_granularity: This option is mated to Persistence_timeout, followed by a subnet mask that represents the granularity of the persistent connection. The default is 255.255.255.255, which is a separate client IP. If you modify the mask to 255.255.255.0, requests for the entire network segment where the client IP resides will be assigned to the same real server.

Protocol: Specifies the type of forwarding protocol, with TCP and UDP two selectable.

Ha_suspend: The health check of the real server node is not enabled when the node state is switched from master to backup.

VirtualHost: The virtual host address of the specified Web server when health detection is done through http_get/ssl_get.

Sorry_server: The equivalent of an alternate node, which is enabled after all real servers fail.

Here is a sample configuration for the Real_server segment:

Real_server 192.168.12.132 80 {

Weight 3

Inhibit_on_failure

Notify_up <STRING> | <QUOTED-STRING>

Notify_down <STRING> | <QUOTED-STRING>

}

The meanings of each option are described below.

Real_server: Is the identity of the Real_server segment that specifies the real server node followed by the real server's true IP address and port, separated by a space between the IP and the port.

Weight: The weight used to configure the real server node. Weights are represented by numbers, and the higher the number, the greater the weight value. The size of the weights can be used to assign different loads to servers of different performance, to set higher weights for high performance servers, and to set relatively low weights for lower performance servers so that system resources can be utilized and allocated reasonably.

Inhibit_on_failure: Indicates that after the real server node is detected as invalid, its "weight" value is set to 0 instead of being removed from Ipvs.

NOTIFY_UP: This option has the same functionality as the notify_maser described above, followed by a script that represents a script that executes when the real server node service is detected in the up state.

Notify_down: Represents a script that executes after detecting that the real server node service is down.

Health Detection section allows a variety of inspection methods, common with Http_get, Ssl_get, Tcp_check, Smtp_check, Misc_check. First look at the Tcp_check detection Method Example:

Tcp_check {

Connect_port 80

Connect_timeout 3

Nb_get_retry 3

Delay_before_retry 3

}

The meaning of each option is described below.

Connect_port: The port of the health check, if none is specified, the default is the port specified by Real_server.

Connect_timeout: Indicates an unresponsive timeout, in seconds, which is a 3-second time-out.

Nb_get_retry: Indicates the number of retries, here is 3 times.

Delay_before_retry: Indicates the retry interval, here is the interval of 3 seconds.

The following are examples of http_get and Ssl_get detection methods:

Http_get | Ssl_get

{

URL {

Path/index.html

Digest e6c271eb5f017f280cf97ec2f51b02d3

Status_code 200

}

Connect_port 80

BindTo 192.168.12.80

Connect_timeout 3

Nb_get_retry 3

Delay_before_retry 2

}

The meanings of each option are described below.

URL: Used to specify URL information for the Http/ssl check, you can specify multiple URLs.

Path: followed by a detailed URL path.

Digest:ssl The summary information after the check, these summary information can be obtained through the Genhash command tool. For example: Genhash-s 192.168.12.80-p 80-u/index.html.

Status_code: Specifies that the HTTP check returns the type of normal status code, typically 200.

BindTo: Indicates that the server is being checked for health by sending a request through this address.

The following is an example of the Misc_check detection method:

Misc_check

{

misc_path/usr/local/bin/script.sh

Misc_timeout 5

! Misc_dynamic

}

Misc Health Check method you can use an external program to determine the service status of a real server node, which is very flexible. The following are the meanings of several commonly used options.

Misc_path: Used to specify an external program or a script path.

Misc_timeout: Sets the time-out for executing the script.

Misc_dynamic: Indicates whether to enable dynamic adjustment of the real server node weights, "!misc_dynamic" means not enabled, instead it means enable. When this feature is enabled, the keepalived healthchecker process will dynamically adjust the "weight" value of the real server node by exiting the status code, if the return status code is 0, indicating that the health check is normal and that the real server node weights remain unchanged If the return status code is 1, indicating that the health check failed, then the real server node weight is set to 0, if the return status code of any number between 2~255, indicating that the health check is normal, but the real server node weight will be set to return the status code minus 2, For example, the return status code for the 10,real server node weight will be set to 8 (10-2).

Up to this point, the options commonly used in the keepalived configuration file have been described, and by default, Keepalived will find the/etc/keepalived/keepalived.conf profile at startup, if the configuration file is placed under a different path, through the Keepalived-f "parameter specifies the path to the configuration file.

When configuring keepalived.conf, pay special attention to the syntax format of the configuration file, because Keepalived does not detect the correctness of the configuration file at startup, even if there is no configuration file, keepalived can still start, so make sure the configuration file is correct.

This article is from the "Technical Achievement Dream" blog, please be sure to keep this source http://ixdba.blog.51cto.com/2895551/1650308

Installation configuration of high-performance cluster software keepalived