KeepAlive configuration file Detailed

Global_defs {notification_email {#指定keepalived在发生切换时需要发送email到的对象, one line [email protected]} Notification_em Ail_from [email protected] #指定发件人 smtp_server localhost #指定smtp服务器地址 smtp_connect_timeout -#指定smtp连接超时时间 router_id lvs_devel #运行keepalived机器的一个标识}vrrp_sync_group vg_1{#监控多个网段的实例group {inside_network # Instance Name Outside_network}notify_master/path/xx.SH#指定当切换到master时, execute the script netify_backup/path/xx.SH#指定当切换到backup时, execute the script Notify_fault"path/xx.sh vg_1"#故障时执行的脚本notify/path/xx.SHSmtp_alert #使用global_defs中提供的邮件地址和smtp服务器发送邮件通知}vrrp_instance inside_network {State BACKUP #指定那个为master, For backup, if this value is set to Nopreempt, the master preparation priority determines interface eth0 #设置实例绑定的网卡 dont_track_primary #忽略vrrp的interface错误 (default    track_interface{#设置额外的监控, the network card inside the problem will switch eth0 eth1} mcast_src_ip #发送多播包的地址, if you do not set the default use of the binding network card primary IP Garp_master_delay #在切换到master状态后, delay gratuitous ARP request virtual_router_id -#VPID标记Priority About#优先级, high-priority campaign for master Advert_int1#检查间隔, default 1 seconds nopreempt #设置为不抢占 Note: This configuration can only be set on the backup host, and this host priority is higher than the other high Preempt_delay #抢占延时, the default 5 minutes debug #debug级别 Authentication {#设置认证 Auth_type PASS #认证方式 auth_pass111111#认证密码} virtual_ipaddress {#设置vip192.168.202.200}}virtual_server192.168.202.200  at{Delay_loop6#健康检查时间间隔 Lb_algo RR #lvs调度算法rr|wrr|lc|wlc|lblc|SH|dh lb_kind DR #负载均衡转发规则NAT| dr|RUN persistence_timeout5#会话保持时间 Protocol TCP #使用的协议 persistence_granularity<NETMASK>#lvs会话保持粒度 VirtualHost<string>#检查的web服务器的虚拟主机 (Host: Head) Sorry_server<IPADDR> <port>#备用机, all realserver are disabled after Real_server192.168.200.5  at{weight1#默认为1, 0 is the failed inhibit_on_failure #在服务器健康检查失效时 and is set to 0 instead of being removed directly from Ipvs notify_up<string> | <quoted-string>Execute script notify_down after #在检测到server up<string> | <quoted-string>Execute script tcp_check after #在检测到server down {connect_timeout3#连接超时时间 nb_get_retry3#重连次数 delay_before_retry3#重连间隔时间 Connect_port atPort of the Health check port BindTo<ip>}http_get|ssl_get{url{#检查url, you can specify more than one path/Digest<string>#检查后的摘要信息 Status_code $#检查的返回状态码} connect_port<port>bindto<IPADD>Connect_timeout5Nb_get_retry3Delay_before_retry2}smtp_check{host{connect_ip<ip address>Connect_port<port>#默认检查25端口 bindto<ip address>} connect_timeout5Retry3Delay_before_retry2Helo_name<string> | <quoted-string>#smtp helo request command parameter, optional} misc_check{Misc_path<string> | <quoted-string>#外部脚本路径 misc_timeout #脚本执行超时时间 misc_dynamic #如设置该项, the exit status code will be used to dynamically adjust the weight of the server, return 0 normal, not modify; return 1, check failed, weight changed to 0; return 2-255, normal, weight set to: Return status code-2}    }

The keepalived.conf content describes the following global definition blocks1, email notification.  Function: There is a malfunction, send an email alarm. 2, and the LVS load Balancer identifier (LVS_ID).  Within a network, it should be unique. 3, curly braces "{}". Used to separate the definition block, so it must appear in pairs. If the write leaks, the keepalived run, will not get the expected results.  Because of the nested relationships within the definition block, it is easy to omit the curly braces at the end, which is especially important. VRRP Defining Blocks1, synchronizing VRRP group Vrrp_sync_group. Role: Determines the number of routing instances that failed switchover (FailOver) contains.  That is, in a scenario with 2 load balancers, once a load balancer fails, what are the instances that need to be automatically switched to another load balancer? 2, instance groups group.  Contains at least one instance of VRRP. 3, VRRP instance vrrp_instance.  The instance name is derived from the name of the instance Group group. (1) Instance status state. Only master and backup two states, and these words need to be capitalized. Where Master is the working state, backup is the standby state.  When Master's server fails, the backup system automatically transforms its status to master, and when the failed Master System resumes, backup resumes from master to the backup state. (2) Communication interface interface.  A network interface that provides services externally, such as eth0,eth1. The current mainstream server has 2 or more than 2 interfaces, when selecting the service interface, it must be verified clearly. (3) Lvs_sync_daemon_inteface. A monitoring interface between the load balancers, similar to the heartbeat line of the HA Heartbeat. But its mechanism is better than heartbeat, because it does not have the problem of "splitting the brain", it is the mechanism of priority to avoid this trouble.  In Dr Mode, the Lvs_sync_daemon_inteface uses the same network interface as the service interface interface. (4) virtual route identity virtual_router_id. This identifier is a number, and the same VRRP instance uses a unique identity.  That is, the same vrrp_stance,master and backup virtual_router_id are consistent and unique throughout the VRRP. (5) Precedence priority. This is a number, the larger the value, the higher the priority. In the same vrrp_instance, MASTER has a higher priority than backup.  If Master has a priority value of 150, then the priority of backup is only 140 or smaller. (6) Synchronize the notification interval advert_int.  The time interval, in seconds, between master and the backup load balancer for synchronization checks. (7) to verify the authentication. Contains the authentication type and the authentication password. The type is mainly pass, ah two kinds, usually use the type of pass, it is said AH use problems.  Verify that the password is plaintext and that the same VRRP instance master uses the same password as backup to communicate properly. 4, virtual IP address virtual_ipaddress. There can be multiple addresses, one row per address, and no subnet mask to be specified.  Note: This IP must match the VIP we set in the LVS client!  Virtual Server Virtual_server definition block Virtual server definition is the most important project of the keepalived framework and is an essential part of keepalived.conf. 1, Virtual server virtual_server. This IP is derived from the VRRP definition block "4"Step, followed by a space, then add the port number.  Defines a VIP that can implement load balancing on multiple TCP ports. (1) Delay_loop.  The health check interval, in seconds. (2) Lb_algo.  Load balancing scheduling algorithm, the use of the WLC or RR is often used in Internet applications. (3) Lb_kind. Load-balanced forwarding rules.  Generally includes Dr, NAT, TUN3, and in my scenario, Dr is used. (4) Persistence_timeout. The session hold time, in seconds. This option is useful for dynamic sites: When a user logs on to a website from a remote account, the session hold function is used to forward the user's request to the same application server. Here, let's assume that there is now an LVS environment, using the DR Forwarding mode, there are 3 real servers, and the load balancer does not enable session hold functionality. When the user first visited, his access request was transferred to a real server by the load balancer, so he saw a landing page, the first access is complete, then he filled in the Login box user name and password, and then submit; At this point, the problem may arise---landing cannot be successful.  Because there is no session hold, the load balancer may forward the 2nd request to the other server. (5) forwarding Protocol protocol. Generally there are two kinds of TCP and UDP.  To tell you the truth, I haven't tried forwarding the UDP protocol class. 2, the real server real_server, or the server pool.  The value of the real_server includes the IP address and port number, and multiple consecutive real IPs. (1Weight weight, the weight value is a number, the larger the value, the higher the weight.  The purpose of using different weights is to assign different loads to different performance machines, and to load the machines with better performance, and the lower the performance of the machines, the less load is shared, so that the machine resources of different performance can be rationally utilized. (2) TCP Check Tcp_check.  The ③ version of the update is as follows: Each server has two network cards, respectively connected to internal and external network, the back-end MySQL database and Web Connection using intranet, the entire network environment using the intranet, adding keepalived.conf syntax content;    Deleted the lvs.sh script content, directly let the keepalived content directly clear; LVs master and slave keepalived.conf files I directly from the production server download down, can be convenient for everyone to use. ※ It is worth noting that:1, you must apply to your server's computer room IDC more than one IP for VIP use; pay more attention to/var/log/messages and Ipvsadm-LN, using its valid information to debug the error. 2, server iptables, SELinux are closed, in the production environment, I encountered the iptables NAT forwarding problem, resulting in LVS failure. 3, keepalived boot process does not check the configuration file syntax, even if there is no configuration file, the keepalived daemon can still be run. In the default state, that is, the location of the configuration file is not specified--keepalived first find the file/etc/keepalived/keepalived.conf. 4, the process of the session by default is in the form of a file, deleted when the browser is closed or restarted, the session remains my recommendation to write for 120 seconds, if the value is set unreasonable, the user will get very bad access effect. 5, keepalived is the LVS extension project, so they have good compatibility, this should be keepalived deployment than other similar tools can be more concise reason for it, lvs+keepalived is currently a mature architecture applied to the production environment, achieving a true sense of load balancing is highly available, especially for BBS and blog (they are frequently accessed, the user volume of large objects), recommended proficiency. The LVS algorithm illustrates eight common scheduling algorithms for LVS: one: Round call scheduling (Round-Robin scheduling) The call scheduling (Round Robin scheduling) algorithm is called in turn to dispatch the request to different servers, that is, each time the execution of the dispatch I= (i +1mod n, and select the I server.    The advantage of the algorithm is its simplicity, which does not need to record the state of all current connections, so it is a stateless dispatch. Two: Weighted round call scheduling (Weighted Round-Robin scheduling) weighted round call scheduling (Weighted Round-Robin scheduling) algorithm can solve the performance of the server between the situation, it uses the corresponding weights to represent the server's processing performance, the server default weight of 1. Assuming server A has a weight of 1,b of 2, it means that Server B's processing performance is twice times the value of a. Weighted round call scheduling algorithm is based on the weight of the high and low and round-robin allocation request to each server.    A server that has a high weight value receives a connection that has a higher weight than a server that has a lower weight value and handles more connections than a server with the same number of weights. Three: Minimum connection scheduling (Least-Connection scheduling) Minimum connection scheduling (Least-Connection scheduling) algorithm is the server that assigns new connection requests to the least current number of connections. Minimum connection scheduling is a dynamic scheduling algorithm that estimates the server's load by the number of connections currently active on the server.  The scheduler needs to record the number of connections that each server has established, and when a request is dispatched to a server, its number of connections increases by 1, and its number of connections is reduced by one when the connection is aborted or timed out. Four: Weighted minimum connection scheduling (Weighted Least-Connection scheduling) weighted minimum connection schedule (Weighted Least-Connection scheduling) algorithm is a superset of minimum connection scheduling, and each server uses corresponding weights to represent its processing performance. The default weight of the server is 1, and the system administrator can set the server's weights dynamically.    Weighted minimum connection scheduling makes the server's established connections and their weights proportional as much as possible when scheduling a new connection. V: Minimum link based on locality (Locality-Based Least Connections scheduling) Minimal link scheduling based on locality (Locality-Based Least Connections Scheduling, hereinafter referred to as LBLC) algorithm is the target IP address of the request packet load balancing scheduling, is mainly used in the cache cluster system, Because the destination IP address of the client request message in the cache cluster is variable. This assumes that any back-end server can handle any request, the algorithm is designed to load the server under the basic balance of the same target IP address requests to the same server, to improve the access of each server and main memory cache hit rate, thus the entire cluster system processing capacity. LBLC scheduling algorithm first based on the target IP address of the target IP address to find the most recently used server, if the server is available and not overloaded, send the request to the server, if the server does not exist, or if the server is overloaded and the server is in half of its workload, then use "least link"    The principle of selecting an available server and sending the request to that server. VI: Local-based least-link with replication (Locality-Based Least Connections with Replication scheduling) Local least-Link scheduling with replication (Locality- Based Least Connections with Replication scheduling, hereinafter referred to as the LBLCR) algorithm is also for the target IP address load balancing, is mainly used in the cache cluster system. It differs from the LBLC algorithm in that it maintains a mapping from a destination IP address to a set of servers, while the LBLC algorithm maintains a mapping from a destination IP address to a server. For a service request from a "hot" site, a cache server may be too busy to process these requests. At this time, the LBLC scheduling algorithm from all the cache server by the "minimum connection" principle to select a cache server, mapping the "hot" site to the cache server, and soon this cache server will be overloaded, will repeat the process to select a new cache server. This may cause the image of the "hot" site to appear on all cache servers, reducing the efficiency of the cache server. The LBLCR scheduling algorithm maps a "hot" site to a set of cache servers (a collection of servers) that, when the load on the "hot" site increases, increases the cache server in the collection to handle the growing load, and when the request load on the "hot" site is reduced, Will reduce the number of cache servers in the collection. In this way, the image of the "hot" site is unlikely to appear on all cache servers, providing efficient use of the cache cluster system. The LBLCR algorithm first finds the server group corresponding to the target IP address according to the target IP address of the request, selects a server from the server group according to the "minimum connection" principle, and sends the request to the server if it is not overloaded, and if the server is overloaded, select a server from the whole cluster according to the "minimum connection" principle. , join the server to the server group and send the request to the server.    Also, when the server group has not been modified for some time, the busiest server is removed from the server group to reduce the degree of replication. Seven: Destination address hash dispatch (Destination Hashing scheduling) The target Address hash schedule (Destination Hashing scheduling) algorithm is also a load balancer for the destination IP address, but it is a static mapping algorithm, A hash function maps a destination IP address to a single server.    The target address hash scheduling algorithm first finds the corresponding server from the statically allocated hash list according to the destination IP address of the request, as hash key (hash key), if the server is available and not overloaded, sends the request to the server, otherwise returns NULL. Eight: Source address hash dispatch (source Hashing Scheduling) Source Address hash dispatch (source Hashing scheduling) algorithm is exactly the same as the target address hash scheduling algorithm, it is based on the requested source IP address, as a hash key (hash key) from the static distribution of the hash list to find the corresponding server, if the server is available and is not overloaded, the request is sent to the server, otherwise null is returned. It uses the same hash function as the target address hash scheduling algorithm. Its algorithm flow and the target address hash scheduling algorithm basically similar, in addition to the request of the destination IP address for the requested source IP address, so this is not described here.    In the actual application, the source address hash schedule and the target address hash schedule can be used together in the firewall cluster, they can guarantee the unique entrance of the whole system.    This article from the source of the Fuqin cooking wine Baidu Blog

! Configuration File forKeepalivedglobal_defs {notification_email {49000448@qq. com} notification_email_from [email protected] smtp_server10.0.0.1Smtp_connect_timeout -router_id lvs_7}vrrp_instance vi_1 {State MASTER interface eth0 virtual_router_id - Priority MaxAdvert_int1Authentication {auth_type PASS auth_pass1111} virtual_ipaddress {10.0.0.143/ -    }}

KeepAlive configuration file Detailed