Location>code7788 >text

keepalived

Popularity：830 ℃/2024-07-21 01:33:50

IV. Keepalived

1], keepalived operation principle

image-20240629233008687

  • Keepalived detects the state of each server connection node
  • The server node is abnormal or has a working fault, keepalived removes the faulty node from the cluster system
  • After the failed node is recovered, Keepalived then adds it to the cluster system
  • All work is automated without human intervention

keepalived for highly available clusters

It works on the principle of VRRP (Virtual Redundant Routing Protocol)

2】、Configuration of highly available clusters

1. Install keepalived

# Installation via script
---
- name: install ipvsadm
  hosts: webservers
  hosts: webservers
    pkg: keepalived
  pkg: keepalived
    - pkgs


# Or install without the script
yum install -y keepalived

Configuring keepalived

Simply modify the following to add a comment

! Configuration File for keepalived

global_defs {
   notification_email {
     acassen@
     failover@
     sysadmin@
   }
   notification_email_from @
   smtp_server 192.168.200.1
   smtp_connect_timeout 30
   router_id web1 # modificationsrouter_id
   vrrp_iptables # have sb do sthkeepalivedauto-addiptablesrules and regulations
   vrrp_skip_check_adv_addr
   vrrp_strict
   vrrp_garp_interval 0
   vrrp_gna_interval 0
}

vrrp_instance VI_1 {
    state MASTER # web1is the main，statebemaster，web2be备份，statebeBACKUP
    interface eth0
    virtual_router_id 51
    priority 100 # prioritization，web1rely mainly on，prioritization高。web2be备份，prioritization要比web1lower (one's head)
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111

Restart keepalived

[root@web1:192.168.4.110 ~]$systemctl start  
[root@web1:192.168.4.110 ~]$systemctl enable

2、Check IP

The correct result should be

Virtual IP on web1: 192.168.4.80

Not on web2.

After web1 hangs, a virtual IP address appears on web2

[root@web1:192.168.4.110 ~]$ip a s eth0 | grep 80
    inet 192.168.4.80/24 scope global secondary eth0
# After web1 hangs
[root@web2:192.168.4.120 ~]$ip a s eth0 | grep 80
    inet 192.168.4.80/24 scope global secondary eth0

3. Testing

[root@ansible:192.168.4.66 ~]$curl http://192.168.4.80
Welcome to web1 on 192.168.4.110
# Hang up web1 and the virtual IP will go back to web2
[root@ansible:192.168.4.66 ~]$curl http://192.168.4.80
Welcome to web2 on 192.168.4.120

3】、Write monitoring scripts

Although the above configuration can realize the main backup switchover function, but there is a bug, the above configuration to realize the premise of the main backup switchover is the web1 (MASTER) shutdown, hang up before you can realize the switchover

If you just turn off the web service on web1, it won't enable the switchover between master and standby

Therefore, we need to write a monitoring script to realize that when the web service is down, we can also realize the master-standby switchover.

We can have keepalived monitor port 80 and switch the master and backup if port 80 is no longer available

  • When configuring a high-availability cluster, keepalived only provides VIPs for the servers
  • keepalived doesn't know what services are running on the server
  • The MASTER server can monitor the local port 80 through a trace script and switch the VIP to the BACKUP server once the local port 80 is disabled
  • The keepalived requirement for scripts is that an exit code of 0 indicates a successful access and an exit code of 1 indicates a failure of the
# shell script that returns 0 if the port is open and 1 if the port is not.
#! /bin/bash
# Check if port 80 is open
if netstat -tuln | grep -q :80; then
    exit 0 # Return 0 if port is open
then exit 0 # port is open, return 0
    exit 1 # port not open, return 1
return 1

# Modify the keepalived configuration file with the following changes
vrrp_script chk_http_port
{
    script "/home/"
    interval 3
    weight -20
}

vrrp_instance VI_1
VI_1
    ...

    track_script
    chk_http_port
        chk_http_port
    }

    ...
}

1. Strategies for prioritizing updates

keepalived willTimed script executionfurthermoreAnalyze the results of script execution, dynamically adjust the priority of vrrp_instance.

If the script execution results into 0furthermoreweightConfigured valuesgreater than 0If the priority is not the same as that of therise

If the script execution results innon-zerofurthermoreweightConfigured valuesLess than 0If the priority is not the same as that of theminimize

In all other cases, the originally configured priority is maintained, i.e. the value corresponding to priority in the configuration file.

Here's something to keep in mind:

1) Priorities don't keep going up or down

2） Multiple test legs can be writtenThis and for each detection script set theDifferent weights

3) Whether the priority is raised or lowered, the final priority of theThe range is in [1,254]., there will be no priority less than or equal to 0 or priority greater than or equal to 255

2. node weight change algorithm in vrrp_script

In a Keepalived cluster, there are actually no strictly speaking master and standby nodes

Although you can set the "state" option to "MASTER" in the Keepalived configuration file, this does not mean that the node is always in the Master role.

The role of a node is controlled by the "priority" value in the Keepalived configuration file, but it does not control the role of all nodes. Another option that can change the role of a node is the "weight" value set in the vrrp_script module. Another way to change the role of a node is to set the "weight" value in the vrrp_script module, which is an integer value.

The "weight" value can be a negative integer, and the role of a node in the cluster is determined by the size of these two values.

No weight

In the vrrp_script module, if theDo not set the "weight" option value.The cluster priority is determined by the "priority" value in the Keepalived configuration file, while the cluster priority can be flexibly controlled by setting the "weight" value in the vrrp_script module. "value in the vrrp_script module.

Setting the weight

A return value of 0 for script in vrrp_script is considered a success, while any other value is considered a failure;

  1. weight is positive.，This weight is added to the priority when the script detects success., not added when the detection fails;
    1. Master Failure.
      1. Toggles between master priority < and priority + weight.
    2. The Lord succeeded:
      1. master priority + weight > slave priority + weight, master is still master
  2. When weight is negativeThis weight does not affect priority when the script detects success.Priority on detection failure - abs(weight)
    1. Master Failure.
      1. master priority - abs(weight) < switches master-slave from priority
    2. Main Success.
      1. master priority > slave priority Master remains the master.
<Previous Next>