【大数据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的配置佐证了这点,此点刷新了我的认知。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值