Mecanismo de detecção de pulsação de manutenção da arquitetura de computação em nuvem Linux (LVS ativo e em espera, LVS ativo e ativo)

Mecanismo de detecção de pulsação de manutenção da arquitetura de computação em nuvem Linux (LVS ativo e em espera, LVS ativo e ativo)

1. Introdução ao keepalived

keepalivedÉ um software com mecanismo de detecção de 3 camadas. Pode detectar o status do servidor web. Se o keepalived detectar que o servidor web está indisponível, ele removerá o servidor do cluster. Depois de esperar pelo reparo manual do servidor, o keepalived adicionará automaticamente o servidor ao cluster.

Nível	Local de trabalho	efeito
camada 3	Camada de rede IP	O Keepalived envia periodicamente um pacote ICMP, ou seja, um pacote de ping, para os servidores do grupo de servidores.Se não estiver disponível, o servidor é considerado inválido e o servidor é removido do grupo de servidores.
camada 4	Camada de transporte TCP	Keepalived detecta se uma determinada porta do servidor é iniciada para determinar se o servidor está normal. Por exemplo, o serviço da web detecta se a porta 80 está ativada e, se não estiver ativada, o servidor é removido.
camada 5	Camada de aplicação	Regras de detecção de operação do programa do servidor definidas pelo usuário. Keepalived verifica se o programa do servidor está funcionando normalmente de acordo com as regras definidas pelo usuário. Se não for normal, o servidor será removido.

A função do keepalived:
1. Gerenciar VIP: ou seja, há distribuidores ativos e standby. Quando o distribuidor principal desliga, o VIP é automaticamente transferido para o distribuidor standby e, em seguida, o distribuidor standby atua como o novo distribuidor principal. Quando o distribuidor principal é reparado, uma vez que o distribuidor principal tem uma prioridade mais alta do que o distribuidor reserva, o VIP será transferido do distribuidor reserva para o distribuidor principal original.

2. Monitore o distribuidor LVS: Para gerenciar o VIP, é necessário monitorar se o distribuidor LVS está inativo. Keepalived no distribuidor principal anunciará ao distribuidor em espera na forma de multicast que está ativo. Se o distribuidor em espera não receber uma mensagem do distribuidor principal dentro de um tempo especificado, ele pensará que o distribuidor principal está inativo. E começou a transferir o VIP para o distribuidor de backup.

3. Gerenciar RS: Keepalived visitará periodicamente (elinks) o servidor back-end real para ver se está normal. Se não estiver normal, remova o servidor. Ou seja, um determinado nó está inativo.

Arquitetura da web clássica de alta disponibilidade: LVS + keepalived + nginx + apache + php + eaccelerator (+ nfs opcional)

Site oficial Keepalived :https://www.keepalived.org/

A versão mais recente atual é a 2.1.5 lançada em 13 de julho de 2020.

2. Implantação Keepalived

2.1 Introdução ao ambiente de cluster

Diagrama de topologia de rede:

Na produção, todos os endereços IP devem ser endereços IP do mesmo segmento de rede física.
Os distribuidores LVS ativos e em espera percebem a alta disponibilidade dos distribuidores. Ele também pode ser configurado como LVS mestre para realizar o LVS mestre mútuo e backup.

2.2 Configuração keepalived ativa e em espera

2.2.1 Introdução aos ambientes ativo e de espera

Nome da CPU	IP / máscara de sub-rede	Porta de entrada	efeito
mlvs	DIP ： 192.168.10.10/24 VIP ： 192.168.10.30/32	192.168.10.1	LVS principal
slvs	DIP ： 192.168.10.20/24 VIP ： 192.168.10.30/32	192.168.10.1	Prepare LVS
rs1	192.168.10.40/24	192.168.10.1	servidor real back-end rs1
rs2	1921.68.10.50/24	192.168.10.1	servidor real de backend rs2

# 主备lvs上都要安装ipvsadm和keepalived
# 使用命令ipvsadm -L -n 可以看到，两个分发器都是做负载均衡的，毕竟都没有配后端真实服务器。
# 这不是本文的重点，本文是要测试keepalived的心跳检测机制。
[root@mlvs ~]# yum install ipvsadm keepalived -y
[root@slvs ~]# yum install ipvsadm keepalived -y
[root@mlvs ~]# ipvsadm -L -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
[root@slvs ~]# ipvsadm -L -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn

2.2.2 Configurar o LVS principal

Modifique o arquivo de configuração keepalived principal:

# 可以使用以下命令查看yum安装的软件包的位置
[root@mlvs ~]# rpm -ql keepalived 
/etc/keepalived/keepalived.conf

# 在复制进配置文件的时候，要把注释信息去掉。
[root@mlvs ~]# vim /etc/keepalived/keepalived.conf 
! Configuration File for keepalived

global_defs {
    
                       # 全局配置
   notification_email {
    
    
     root@localhost          # 当VIP发生切换时，发送邮件给以下邮箱，一行一个。
   }
   notification_email_from root@localhost          # 发件人
   smtp_server localhost                   # smtp发件服务器地址
   smtp_connect_timeout 30            # smtp连接超时时间
   router_id mlvs                               # 标识当前节点的名字，与备lvs不同。
}

vrrp_instance M1 {
    
                               #定义一个实例
    state MASTER                              # 主LVS,备LVS应设置为BACKUP
    interface ens32                            # 指定检测网络的接口
    virtual_router_id 51                      # vrrp组名，备lvs要与主lvs在同一组。
    priority 100                                   # 优先级(1-254)
    advert_int 1                                   # 组播发送消息时间间隔
    authentication {
    
                                # 设置验证信息，两个LVS必须一致
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
    
    
        192.168.10.30                            # 指定VIP,两个LVS必须一致
    }
}

virtual_server 192.168.10.30 80 {
    
          # 添加虚拟服务器VIP
    delay_loop 6                                  # keepalived检测RS的时间间隔
    lb_algo rr                                       # 分发算法，rr指轮询
    lb_kind DR                                     # lvs模式，这里用DR
    nat_mask 255.255.255.0
    persistence_timeout 50                # 长连接保持时间，50s内同一IP的请求会发送给同一RS
    protocol TCP

    real_server 192.168.10.40 80 {
    
           # RS设置
        weight 1                                      # 真实服务器节点的权重，数值越大权重越高
        TCP_CHECK {
    
                                   # 检查TCP的80端口号，即layer4
            connect_timeout 3                 # 3s RS无响应则超时
            nb_get_retry 3                         # 超时重试次数
            delay_before_retry 3               # 3s重试一次，即重试间隔
            connect_port 80                      # 检测端口
         }
    }
    real_server 192.168.10.50 80 {
    
    
        weight 1
        TCP_CHECK {
    
    
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
            connect_port 80
        }
    }
}

# 启动主lvs上的keepalived，并设置开机自启。
[root@mlvs ~]# systemctl start keepalived
[root@mlvs ~]# systemctl enable keepalived

Uma virtual_serverinstância é um cluster LVS. Se você deseja configurar vários clusters LVS em um host, é necessário configurar várias instâncias.

# 清空iptables防火墙规则
[root@mlvs ~]# iptables -F
# 使用ipvsadm查看负载均衡的情况
[root@mlvs ~]# ipvsadm -L -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.10.30:80 rr persistent 50
# 使用ip a命令查看ens32绑定的所有IP地址
[root@mlvs ~]# ip a | grep ens32
2: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 192.168.8.118/24 brd 192.168.8.255 scope global noprefixroute dynamic ens32
    inet 192.168.10.30/32 scope global ens32

2.2.3 Configurar LVS em espera

# 发送主lvs的keepalived配置文件给备lvs主机。
[root@mlvs ~]# scp /etc/keepalived/keepalived.conf [email protected]:/etc/keepalived/
[root@slvs keepalived]# vim keepalived.conf 
! Configuration File for keepalived

global_defs {
    
    
   notification_email {
    
    
     root@localhost
   }
   notification_email_from root@localhost
   smtp_server localhost
   smtp_connect_timeout 30
   router_id slvs    # 从lvs标识
}

vrrp_instance M1 {
    
    
    state BACKUP     # 设置该实例为从LVS
    interface ens32
    virtual_router_id 51
    priority 90     # 优先级调低，主为100，从为90
    advert_int 1
    authentication {
    
    
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
    
    
        192.168.10.30
    }
}

virtual_server 192.168.10.30 80 {
    
    
    delay_loop 6
    lb_algo rr
    lb_kind DR
    nat_mask 255.255.255.0
    persistence_timeout 50
    protocol TCP

    real_server 192.168.10.40 80 {
    
    
        weight 1
        TCP_CHECK {
    
    
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
            connect_port 80
         }
    }
    real_server 192.168.10.50 80 {
    
    
        weight 1
        TCP_CHECK {
    
    
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
            connect_port 80
        }
    }
}

# 启动从lvs上的keepalived，并设置开机自启。
[root@slvs ~]# systemctl start keepalived.service
[root@slvs ~]# systemctl enable keepalived.service

# 清空iptables防火墙规则
[root@slvs ~]# iptables -F 

# 验证下VIP绑定情况，可以看到VIP是没有绑定到从LVS上的。
[root@slvs ~]# ipvsadm -L -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.10.30:80 rr persistent 50

[root@slvs ~]# ip a | grep ens32
2: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 192.168.8.120/24 brd 192.168.8.255 scope global noprefixroute dynamic ens32

2.2.4 Teste VIP master / switch de backup

Pare o serviço keepalived do LVS mestre, você pode ver que o VIP foi desviado do LVS mestre para o LVS escravo.



Reinicie o serviço keepalived no LVS principal, você pode ver que o VIP desvia do LVS de volta para o LVS principal.
Pode-se ver no log do LVS que após o LVS principal ser restaurado, a ação do LVS escravo é verificar a prioridade primeiro, em seguida, alternar para o modo BACKUP e, finalmente, remover o VIP.

2.3 Configuração mestre mestre keepalived

2.3.1 Introdução ao ambiente principal principal

Nome da CPU	IP / máscara de sub-rede	Porta de entrada	efeito
mlvs1	DIP ： 192.168.10.10/24 VIP1 ： 192.168.10.30/32	192.168.10.1	LVS principal, também LVS de espera
mlvs2	DIP ： 192.168.10.20/24 VIP2 ： 192.168.10.60/32	192.168.10.1	LVS principal, também LVS de espera
rs1	192.168.10.40/24	192.168.10.1	servidor real back-end rs1
rs2	1921.68.10.50/24	192.168.10.1	servidor real de backend rs2

2.3.2 Configuração mestre-escravo duas vezes

Visto que o mestre-escravo foi configurado uma vez, o mestre-escravo pode ser configurado novamente.

# 配置为M1实例的主，M2实例的从。一个实例可以看作是一个集群。
[root@mlvs2 ~]# vim /etc/keepalived/keepalived.conf 
! Configuration File for keepalived

global_defs {
    
    
   notification_email {
    
    
     root@localhost
   }
   notification_email_from root@localhost
   smtp_server localhost
   smtp_connect_timeout 30
   router_id mlvs
}

vrrp_instance M1 {
    
    
    state MASTER
    interface ens32
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
    
    
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
    
    
        192.168.10.30
    }
}

vrrp_instance M2 {
    
    
    state BACKUP
    interface ens32
    virtual_router_id 52
    priority 90
    advert_int 1
    authentication {
    
    
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
    
    
        192.168.10.60
    }
}

virtual_server 192.168.10.30 80 {
    
    
    delay_loop 6
    lb_algo rr
    lb_kind DR
    nat_mask 255.255.255.0
    persistence_timeout 50
    protocol TCP

    real_server 192.168.10.40 80 {
    
    
        weight 1
        TCP_CHECK {
    
    
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
            connect_port 80
         }
    }
    real_server 192.168.10.50 80 {
    
    
        weight 1
        TCP_CHECK {
    
    
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
            connect_port 80
        }
    }
}

virtual_server 192.168.10.60 80 {
    
    
    delay_loop 6
    lb_algo rr
    lb_kind DR
    nat_mask 255.255.255.0
    persistence_timeout 50
    protocol TCP

    real_server 192.168.10.40 80 {
    
    
        weight 1
        TCP_CHECK {
    
    
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
            connect_port 80
         }
    }
    real_server 192.168.10.50 80 {
    
    
        weight 1
        TCP_CHECK {
    
    
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
            connect_port 80
        }
    }
}

# 检测主1上的VIP情况，可以看到只绑定了一个VIP。因为主1只是实例M1的主LVS。
[root@mlvs1 ~]# systemctl restart keepalived.service 
[root@mlvs1 ~]# iptables -F
[root@mlvs1 ~]# ip a |grep ens32
2: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 192.168.8.118/24 brd 192.168.8.255 scope global noprefixroute dynamic ens32
    inet 192.168.10.30/32 scope global ens32
[root@mlvs1 ~]# ipvsadm -L -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.10.30:80 rr persistent 50
TCP  192.168.10.60:80 rr persistent 50

# 配置为M2实例的主，M1实例的从。
[root@mlvs2 ~]# cat /etc/keepalived/keepalived.conf 
! Configuration File for keepalived

global_defs {
    
    
   notification_email {
    
    
     root@localhost
   }
   notification_email_from root@localhost
   smtp_server localhost
   smtp_connect_timeout 30
   router_id slvs
}

vrrp_instance M1 {
    
    
    state BACKUP
    interface ens32
    virtual_router_id 51
    priority 90
    advert_int 1
    authentication {
    
    
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
    
    
        192.168.10.30
    }
}

vrrp_instance M2 {
    
    
    state MASTER
    interface ens32
    virtual_router_id 52
    priority 100
    advert_int 1
    authentication {
    
    
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
    
    
        192.168.10.60
    }
}

virtual_server 192.168.10.30 80 {
    
    
    delay_loop 6
    lb_algo rr
    lb_kind DR
    nat_mask 255.255.255.0
    persistence_timeout 50
    protocol TCP

    real_server 192.168.10.40 80 {
    
    
        weight 1
        TCP_CHECK {
    
    
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
            connect_port 80
         }
    }
    real_server 192.168.10.50 80 {
    
    
        weight 1
        TCP_CHECK {
    
    
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
            connect_port 80
        }
    }
}

virtual_server 192.168.10.60 80 {
    
    
    delay_loop 6
    lb_algo rr
    lb_kind DR
    nat_mask 255.255.255.0
    persistence_timeout 50
    protocol TCP

    real_server 192.168.10.40 80 {
    
    
        weight 1
        TCP_CHECK {
    
    
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
            connect_port 80
         }
    }
    real_server 192.168.10.50 80 {
    
    
        weight 1
        TCP_CHECK {
    
    
            connect_timeout 3
            nb_get_retry 3
            delay_before_retry 3
            connect_port 80
        }
    }
}

# 检测主2上的VIP情况，可以看到只绑定了一个VIP。因为主2只是实例M2的主LVS。
[root@mlvs2 ~]# systemctl restart keepalived.service 
[root@mlvs2 ~]# iptables -F
[root@mlvs2 ~]# ip a | grep ens32
2: ens32: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    inet 192.168.8.120/24 brd 192.168.8.255 scope global noprefixroute dynamic ens32
    inet 192.168.10.60/32 scope global ens32
[root@mlvs2 ~]# ipvsadm -L -n
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn
TCP  192.168.10.30:80 rr persistent 50
TCP  192.168.10.60:80 rr persistent 50

2.3.3 Teste de interruptor mestre VIP

Como você pode ver, após a conclusão da configuração, um host LVS é vinculado a um VIP. mlvs1A ligação é 192.168.10.30, mlvs2a ligação é 192.168.10.60.
Pare o serviço keepalived em mlvs1 e você poderá ver que o VIP mudou.


Inicie o serviço keepalived em mlvs1, você pode ver o VIP voltando.


Pare o serviço keepalived em mlvs2, você pode ver que o VIP mudou.


Inicie o serviço keepalived em mlvs2, você pode ver o VIP voltando.

3. Resumo do Keepalived

①Pode-se saber, a partir do princípio de funcionamento do keepalived, que ele realiza a detecção do servidor nos três níveis da camada de rede IP, a camada de transporte TCP e a camada de aplicação. Se o servidor não estiver disponível, ele será removido do cluster. Se o servidor for reparado, o servidor será adicionado ao cluster.

②Keepalived tem três funções principais: gerenciamento de VIP, monitoramento de distribuidor LVS e gerenciamento de RS.

③Nesse cluster, o LVS primário e o LVS em espera pertencem ao mesmo grupo vrrp, e o LVS primário anuncia periodicamente que está ativo para o LVS em espera de uma maneira multicast. Neste momento, o LVS em espera não sobrecarregará o mestre. Mas quando o LVS de reserva não recebe o anúncio do LVS principal dentro de um ciclo, o LVS de reserva irá se promover automaticamente para o LVS principal e o VIP irá automaticamente desviar do LVS principal para o LVS de reserva.

④ Keepalived freqüentemente constrói clusters com servidores web e servidores mysql. Este artigo é a arquitetura keepalived + lvs + DR + http. Se o back-end real_server monitora a porta 3306, a arquitetura será convertida para keepalived + lvs + DR + mysql.

⑤ Cada vrrp_instance é um cluster, a configuração do LVS primário e o LVS de backup pertencem ao mesmo cluster, portanto, o nome da instância vrrp_instance deve ser o mesmo. Para que o LVS primário se declare ativo por multicast, o ID do grupo virtual_route_id VRRP deve ser o mesmo. Cada keepalived pertence a si mesmo, portanto, tem um route_id diferente. A distinção entre ativo e em espera pode ser definida por estado. Quando o LVS principal falhar, o VIP executará o deslocamento de VIP de acordo com o estado e a prioridade dos nós no cluster. Geralmente, ele irá desviar para o nó onde o estado é BACKUP e a prioridade é a mais alta no LVS de espera. Por meio da configuração acima, ele pode ser expandido em um mestre e vários backups, e vários mestres e vários backups.

⑥ Dois servidores podem realizar backup ativo e mestre ativo. O ativo e em espera pertencem ao mesmo cluster, e o ativo e o ativo podem ser considerados dois ativos e em espera. Três servidores podem ser um mestre, dois backup e três mestres. Um mestre e dois backups pertencem ao mesmo cluster, e três mestres podem ser considerados três, um mestre e dois backups. Desta forma, quando o LVS principal desligar, haverá um LVS em espera para receber VIP, e quando o LVS em espera desligar, haverá outro LVS em espera para receber. Obtenha uma arquitetura altamente disponível que não interrompa o serviço no ambiente de produção.