1. Basic knowledge of Keepalived dual-machine warm-up
Official keepalived website: www.keepalived.org/ Ke keepalived can also be used as a hot standby software in non-LVS environments.
1. Keepalived role
Kekeepalived was originally designed as a powerful assistive tool for LVS, primarily to provide failover and health check functions - to determine the availability of LVS load dispatchers, node servers, to isolate and replace new servers in a timely manner, and to rejoin the cluster when the failing host replies.If the LVS environment is deployed separately, the entire cluster will fail if the dispatcher goes down. When a web node goes down, clients will always encounter the situation that they cannot access the web page when they visit it. Therefore, combining keepalived with LVS will form a truly highly available cluster. Of course, shared storage on the back-end must also set up a highly available storage server.One of the three is unsatisfactory and cannot be called a highly available cluster environment.
2. How Keepalived prepares
keepalived uses the VRRP (Virtual Routing Redundancy Protocol) hot backup protocol to implement the hot standby function of Linux servers in a software way.VRRP is a backup solution for routers, which consists of multiple routers in a hot standby group to provide services through shared virtual IP (VIP) addresses; there is only one master router in each hot backup group to provide services at the same time, and other routers are redundant. If the current online router fails, other routers will automatically take over (priority decision)Fixed Substitution Order) Virtual IP Address to continue servicing.
Each router in the hot standby group may become the master router, and the IP address (VIP) of a virtual router can be transferred to the router in the hot standby group, so it is also called a drift IP address.With keepalived, the implementation of drift addresses does not need to manually create a virtual interface profile (such as ens32:0), but is managed automatically by keepalived based on the profile.
2. Using Keepalived to achieve dual-machine hot-reserve
Based on the VRRP hot standby method, keepalived can be used as a failover for servers, and each hot standby group can have multiple servers - most commonly multi-machine hot standby.In this multi-machine hot-standby scenario, failover is mainly implemented for virtual IP address drift.It can therefore be used on a variety of application servers (whether Web, FTP, Mail, SSH, DNS....).
The topology diagram is as follows:
1. Configure the master server
The configuration directory for the Keepalived service is located at/etc/keepalived/.keepalived.conf is the primary configuration file; it also includes a subdirectory samples/, which provides many configuration samples for reference.In the Keepalived configuration file, use the "global_defs {...}" section to specify global parameters, the "vrrp_instance instance instance name {...}" section to specify VRRP hot standby parameters, and the comment text to "!"The beginning of the symbol.
[root@centos04 ~]# Systemctl stop firewalld <!--Close firewall--> [root@centos04 ~]# Yum-y install ipvsadm keepalived <!--Install keeplive service--> [root@centos04 ~]# cp /etc/keepalived/keepalived.conf /etc/keepalived/keepalived.conf.bak <!--backups keepalived Main Profile--> [root@centos04 ~]# Systemctl start keepalived <!--Start keepalived service--> [root@centos04 ~]# Chkconfig --level 35 keepalived on <!--Set boot-up autostart--> [root@centos04 ~]# Vim/etc/keepalived/keepalived.conf <!--Edit keepalived main profile--> ! Configuration File for keepalived global_defs { router_id LVS_HA_Master <!--Modify the server name here--> } vrrp_instance VI_1 { <!--Definition VRRP Hot standby instance--> state MASTER <!--Hot-up status, MASTER Represents the primary server (case sensitive)--> interface ens32 <!--Load bearing VIP Physical interface of address--> virtual_router_id 51 <!--Virtual router ID No, each hot standby group remains the same--> priority 100 <!--Priority 0-100,Larger values take precedence--> advert_int 1 <!--Number of seconds between announcements (heart rate)--> authentication { <!--Authentication information, consistent for each hot standby group--> auth_type PASS <!--Authentication type--> auth_pass 1111 <!--Password String--> } virtual_ipaddress { <!--Specify a drift address, which can have multiple--> 192.168.100.253 } } ............ <!--Omit some content here-->
Confirm that the above configuration is correct, and then start the keepalived service. The master server with the actual state of MASTER will automatically add the VIP address for the ens32 interface, which can be viewed through the ip command (note: the ifconfig command is not visible).
[root@centos04 ~]# Systemctl restart keepalived <!--Restart keepalived service--> [root@centos04 ~]# IP a show dev ens32 <!--View ens32 interface--> ens32: <BROADCAST,MULTICAST,UP,LOWER_UPUt qlen 1000 link/ether 00:0c:29:77:2c:03 brd ff:ff:ff:ff:ff:ff inet 192.168.100.40/24 brd 192.168.1.255 scope global noprefixroute ens32 valid_lft forever preferred_lft forever inet 192.168.100.253/32 scope global ens32 <!--You can see VIP Already configured in ens32 upper--> valid_lft forever preferred_lft forever inet6 fe80::95f8:eeb7:2ed2:d13c/64 scope link noprefixroute valid_lft forever preferred_lft forever
2. Configure slave nodes
Within the same keepalived hot standby group, the keepalived configuration files of all servers are basically the same, including the ID number of the virtual router, authentication information, drift address, heart rate, and so on.The main differences are router name, hot standby status, priority.
-
Router name (route_id): It is recommended that you specify a different name for each server participating in the hot standby.
-
state: There should be at least one primary server with status set to MASTER; there can be multiple standby servers with status set to BACKUP.
- Priority: The higher the number, the higher the priority to get VIP control, so the priority of the primary service should be set to the highest; other standby servers can descend in turn, but not the same, to avoid conflicts when competing for VIP control.
When configuring a standby server (there can be more than one), you can refer to the keepa.conf text configuration file of the primary server as long as you modify the router name, standby status, and priority.
[root@centos05 ~]# Systemctl stop firewalld <!--Close firewall--> [root@centos05 ~]# Yum-y install keepalived ipvsadm<!--Install related tools--> [root@centos05 ~]# scp root@192.168.100.40:/etc/keepalived/keepalived.conf /etc/keepalived/ <!--Use slave server root User will host the server's keepalived Copy the configuration file over--> root@192.168.100.40 s password: <!--Input Primary Node root User's password--> keepalived.conf 100% 3549 3.5MB/s 00:00 [root@centos05 ~]# vim /etc/keepalived/keepalived.conf <!--edit keepalived Main Profile--> global_defs { ............... router_id LVS_DEVEL2 <!--Modify the server name here--> ..................... } .............. vrrp_instance VI_1 { state BACKUP <!--Modify the status here to BACKUP--> interface ens32 <!--If the server hosts VIP If the physical interface has changed, it should also be modified here--> virtual_router_id 51 priority 90 <!--Modify priority lower than primary server--> advert_int 1 authentication { auth_type PASS auth_pass 1111 } virtual_ipaddress { 192.168.100.253 } } ................. <!--After changing the above lines, save and exit--> [root@centos05 ~]# Systemctl start keepalived <!--Start the service--> [root@centos05 ~]# Systemctl enable keepalived<!--Set boot-up self-start-->
Confirm that the configuration is correct and you also need to start the keepalived service.At this point, the primary server is still online, the VIP address is still actually controlled by the primary server, and the other servers are backed up, so VIP addresses will not be added to the ens32 interface in the standby server.
[root@centos05 ~]# IP a show dev ens33 <!--Look at the ens33 interface and don't see VIP--> ens32: <BROADCAST,MULTICAST,Udel state UP group default qlen 1000 link/ether 00:0c:29:9a:09:98 brd ff:ff:ff:ff:ff:ff inet 192.168.100.50/24 brd 192.168.1.255 scope global noprefixroute ens32 valid_lft forever preferred_lft forever inet6 fe80::3050:1a9b:5956:5297/64 scope link noprefixroute valid_lft forever preferred_lft forever
3. Testing dual-machine hot-standby function
Shut down the main server or stop the keepalived service. After waiting for about 15 seconds, check the ens32 network card of the backup server and you will find that the drift address has been transferred, indicating that the dual-machine hot standby function is in effect.When the primary server is powered on, the drift address is automatically transferred back to the primary server.
[root@centos05 ~]# IP a show dev ens32 <!--View network card information of backup server after primary server shuts down--> ens32: <BROADCAST,MULTICAST,UP state UP group default qlen 1000 link/ether 00:0c:29:9a:09:98 brd ff:ff:ff:ff:ff:ff inet 192.168.100.50/24 brd 192.168.1.255 scope global noprefixroute ens32 valid_lft forever preferred_lft forever inet 192.168.100.253/32 scope global ens32 <!--The drift address has been moved over--> valid_lft forever preferred_lft forever inet6 fe80::3050:1a9b:5956:5297/64 scope link noprefixroute valid_lft forever preferred_lft forever
Turn the primary server on again, and you will find that the VIP has been transferred back to the primary server, and the backup server cannot find the VIP:
[root@centos04 ~]# IP a show dev ens32 <!--View on primary server--> ens32: <BROADCAST,MULTICAST,UP,Lefault qlen 1000 link/ether 00:0c:29:77:2c:03 brd ff:ff:ff:ff:ff:ff inet 192.168.100.40/24 brd 192.168.1.255 scope global noprefixroute ens32 valid_lft forever preferred_lft forever inet 192.168.100.253/32 scope global ens32 <!--VIP The address is here--> valid_lft forever preferred_lft forever inet6 fe80::95f8:eeb7:2ed2:d13c/64 scope link noprefixroute valid_lft forever preferred_lft forever [root@centos05 ~]# IP a show dev ens32 <!--View on backup server--> ens32: <BROADCAST,MULTICAST,UP,P grou00 link/ether 00:0c:29:9a:09:98 brd ff:ff:ff:ff:ff:ff inet 192.168.100.50/24 brd 192.168.1.255 scope goute ens32 valid_lft forever preferred_lft forever inet6 fe80::3050:1a9b:5956:5297/64 scope link noprefixroute valid_lft forever preferred_lft forever
- This is the end of the article. Thank you for reading ---