【大数据HA】keepalived结合haproxy实现高可用的HMS

背景

上一篇实现了haproxy代理后端HMS服务实现高可用。但是对于haproxy还是单点故障，所以需要对haproxy进一步做HA，实现真正的后端服务的HA。

要实现haproxy的HA，需要使用到keepalived，使用keepalived是VIP虚拟IP服务，实现故障转移。

一：环境介绍

虚机一：wuxdihadl03b，IP 10.40.8.44，部署了HMS服务

虚机二：wuxdihadl04b，IP 10.40.8.45，部署了HMS服务

二：大体流程：

1.两台机器分别部署HMS服务

2.两台机器分别部署HAProxy，并配置指向两个HMS服务

3.两台机器分别部署Keepalived，设置统一虚拟IP

4.trino配置虚拟IP的HAProxy地址，指向后端的HMS服务

5.测试HA功能

HMS和HAProxy的安装配置不再介绍，参考上一篇。

三：安装keepalived

两台机器分别安装

yum install keepalived -y

四：配置keepalived

找到/etc/keepalived/keepalived.conf，主节点如下配置

! Configuration File for keepalived

global_defs {
   notification_email {
     # 发送通知邮件的地址，可选
     acassen@firewall.loc
     failover@firewall.loc
     sysadmin@firewall.loc
   }
   notification_email_from Alexandre.Cassen@firewall.loc  # 发送通知邮件的发件人地址，可选
   smtp_server 127.0.0.1 # 发送邮件所使用的SMTP服务器，可选
   smtp_connect_timeout 30 # 发送邮件的连接超时时间，可选
   router_id 10.40.8.44     #每个keepalived主机唯一标识，建议使用当前主机名或IP
   vrrp_skip_check_adv_addr 
   vrrp_strict 
   vrrp_garp_interval 0 
   vrrp_gna_interval 0
}

#检测haproxy服务是否正常，如果不正常或未运行，则keepalived会进行漂移，放弃当前节点为主节点，降为备用节点
vrrp_script haproxy-check {
    script "killall -0 haproxy"  #这个命令是用来检查是否有名为 "haproxy" 的进程在运行
    interval 2 #两秒检查一次
    weight 20 #如果检查失败每次扣除优先级20分
}

vrrp_instance VI_1 {
    state MASTER #当前节点在此虚拟路由器上的初始状态，状态为MASTER或者BACKUP
    interface ens192 #绑定为当前虚拟路由器使用的物理接口，网卡名称
    virtual_router_id 51 #每个虚拟路由器惟一标识，范围：0-255，每个虚拟路由器此值必须唯一，否则服务无法启动，同属一个虚拟路由器的多个keepalived节点必须相同,务必要确认在同一网络中此值必须唯一
    priority 100 #当前物理节点在此虚拟路由器的优先级，范围：1-254，值越大优先级越高
    advert_int 1
    authentication { ##认证机制
        auth_type PASS
        auth_pass 1111
    }

    #重点！！！虚拟IP，可以指定多个，建议指定当前网段未被使用的IP
    virtual_ipaddress {
        10.40.8.200
    }

    #配置监控脚本，一旦出现故障，根据脚本结果决定是否实行故障转移
    track_script {
        haproxy-check weight 20
    }
}

备用节点配置，只需要改三处

! Configuration File for keepalived

global_defs {
   notification_email {
     acassen@firewall.loc
     failover@firewall.loc
     sysadmin@firewall.loc
   }
   notification_email_from Alexandre.Cassen@firewall.loc 
   smtp_server 127.0.0.1 
   smtp_connect_timeout 30 
   router_id 10.40.8.45 #修改标志     
   vrrp_skip_check_adv_addr 
   vrrp_strict 
   vrrp_garp_interval 0 
   vrrp_gna_interval 0
}


vrrp_script haproxy-check {
    script "killall -0 haproxy"  
    interval 2 
    weight 20 
}

vrrp_instance VI_1 {
    state BACKUP #改为BACKUP
    interface ens192 
    virtual_router_id 51 
    priority 99 #优先级降低
    advert_int 1
    authentication { 
        auth_type PASS
        auth_pass 1111
    }

    virtual_ipaddress {
        10.40.8.200
    }

    track_script {
        haproxy-check weight 20
    }
}

五.启动keepalived

使用systemctl status keepalived 命令可以查看keepalived状态，在备用节点可以发现如下标识，主节点没有该信息。

六.测试

修改trino的catalog的HMS地址为 10.40.8.200:5000， 重启trino，访问数据，测试场景

1.停掉两个HMS服务，trino无法访问数据

2.启动任意一个HMS服务，trino成功访问数据

3.启动另一个HMS服务，trino成功访问数据

4.停掉两个HAProxy服务，trino无法访问数据

5.启动任意一个HAProxy服务，trino成功访问数据

6.启动另一个HAProxy服务，trino成功访问数据

七:keepalived实现故障转移的理解

keepalived实现故障转移的原理：

1.在wuxdihadl03b和wuxdihadl04b上分别启动了haproxy1和haproxy2，并且启动了keepalived1和keepalived2，并且keepalived1为主节点。此时访问虚拟IP 10.40.8.200:5000 ，实际上访问的是wuxdihadl03b的keepalived1，keepalived1访问的是本机的haproxy1，haproxy1再分发到后台的HMS。

2.当haproxy1宕机时，keepalived1会立即检测到，同属一个路由的keepalived1和keepalived2会迅速切换，keepalived2变成主节点，keepalived1变成备用节点，此时访问虚拟IP 10.40.8.200:5000 ，实际上访问的是wuxdihadl04b的keepalived2，keepalived2访问的是本机的haproxy2，haproxy2再分发到后台的HMS。

因此与我原来的理解不同，keepalived是通过自身的主备节点切换，再根据主节点去访问本机的代理服务，而不是由同一个keepalived去访问到多个haproxy服务，从keepalived配置中没有关于hadproxy的配置佐证了这点，此点刷新了我的认知。