keepalived+haproxy高可用

一、keepalived+haproxy

1、为什么需要这个呢？

我们知道haproxy集群就是一个接收客户端的请求的haproxy节点，反向代理到后端服务器上面

有一个问题，就是如果这个接收客户端请求的节点挂掉的话，那么就访问不到业务了，整个业务就挂掉了
因此的话就有这个keepalived发挥作用了，有一个主备节点，当主模式挂掉的话，备用节点接收客户端的请求，业务没有中断

• 这有一个缺点，那就是这个备用节点一直是空闲的状态，资源的利用率只有50%，后面将介绍和这个主主模式

2、核心原理

1、工作流程

• 客户端访问这个虚拟vip，haproxy监听到客户端的请求了

• haproxy节点与后端服务器进行连接

• 后端服务器接收请求后返回给haproxy节点

• 最后返回给客户端

• 整个流程结束

• 如果主节点故障的话，自动的切换到备用节点上面(可以写一个脚本来进行检测，主要判断keepalived)

2、为什么虚拟vip会转移了

因为这个keepalived的核心协议VRRP协议
VRRP协议通过多播心跳，优先级竞选和免费的ARP机制，选举出master

• 主要就是有一个vip地址，能够实现漂移，从而实现

3、实验操作

• 有一个虚拟vip，客户端访问这个虚拟ip

1、master配置

# keepalived配置
[root@master keepalived]# cat keepalived.conf
! Configuration File for keepalived

global_defs {
   router_id lvs1
}

vrrp_instance lvs_m {
    state MASTER
    interface ens160
    virtual_router_id 10
    priority 254
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.50.88/24
    }
}


# haproxy配置
frontend default
    bind *:80
    default_backend http_back

backend http_back
    balance     roundrobin
    server node1 192.168.50.11:80 check
    server node2 192.168.50.12:80 check

2、backup节点配置

# 备用节点keepalived配置
[root@node1 keepalived]# cat keepalived.conf
! Configuration File for keepalived

global_defs {
   router_id lvs2
}

vrrp_instance lvs_b {
    state BACKUP
    interface ens33
    virtual_router_id 10
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        192.168.50.88/24
    }
}


# haproxy配置
frontend default
    bind *:80
    default_backend http_back

backend http_back
    balance     roundrobin
    server node1 192.168.50.11:80 check
    server node2 192.168.50.12:80 check

3、后端服务器配置

• 配置网页即可

主主模式

• 2个vip