HAProxy & Keepalived L4-L7 高可用负载均衡解决方案

HAProxy 负载均衡器

**HAProxy（High Availability Proxy）**是由法国人 Willy Tarreau 个人开发的基于 TCP、HTTP 协议实现的开源 L4-L7 软件负载均衡器，采用单进程和事件驱动模型实现，具有高可用和反向代理特性，支持双机热备与虚拟主机。目标是支持 10000+ 请求连接，为后端业务服务器集群提供高性能的负载均衡服务。适用于大连接数，要求会话保持，分发复杂的流量负载均衡场景。

四层代理：HAProxy 采用 NAT 模式，在客户端和 Real Server 之间双向转发流量
七层代理：HAProxy 通过分析、理解、修改应用层协议来实现更加 “智能” 的流量分发。

注：Real Server，实际处理客户端请求的业务服务器。

应用特性

客户端侧长连接（Client-side Keep-alive）
TCP 加速（TCP Speedups）
响应池（Response Buffering）
RDP 协议
基于源的粘性（Source-based Stickiness）
更好的统计数据接口（A much better stats interfaces）
更详细的健康状态检测机制（More verbose health checks）
基于流量的健康评估机制（Traffic-based Health）
支持 HTTP 认证
服务器管理命令行接口（Server management from the CLI）
基于 ACL 的持久性（ACL-based Persistence）
日志分析器

性能优势

HAProxy 基于事件驱动（Event-Driven）、单一进程模型和 Ebtree 弹性二叉树机制，显著降低了上下文切换的开销及内存占用，根据官方文档，HAProxy 可以跑满 10Gbps-New benchmark of HAProxy at 10 Gbps using Myricom’s 10GbE NICs (Myri-10G PCI-Express)，作为软件级负载均衡是比较惊人的。多进程或多线程模型受内存限制、系统调度器限制以及无处不在的锁限制，很少能处理数千量级的并发连接。

基于事件驱动（Event-Driven）：事务不会长时间占用 CPU，直到事件来临时，操作系统才会将事务唤醒。
单一进程模型：避免了多线程、多进程的上下文切换、模式切换以及调度器负载的性能开销。
Ebtree（Elastic Binary Tree，弹性二叉树机制）树形存储：是由 Willy Tarreau 自己发明的一种不平衡二叉搜索树数据结构，实现了以 O(log(N)) 的低开销来保持计时器命令、保持运行队列命令及管理轮询及最少连接队列，还实现了删除叶节点时保持 O(1) 的时间复杂度，但同时也放弃了树的平衡。
O(1) 事件检查器（Event Checker）：允许其在高并发连接中对任何连接的任何事件实现即时探测。
单缓冲（Single Buffering）机制：能以不复制任何数据的方式完成读写操作，这会节约大量的 CPU 时钟周期及内存带宽。
借助于 Linux 2.6（>=2.6.27.19）上的 splice() 系统调用，HAProxy 可以实现零复制转发（Zero-copy Forwarding），在 Linux 3.5 及以上的操作系统中还可以实现零复制启动（Zero-Starting）。
内存分配器在固定大小的内存池中可实现即时内存分配，这能够显著减少创建一个会话的时长。
优化的 HTTP Header 分析：优化协议头分析功能避免了在 HTTP Header 分析过程中重复读取任何内存区域。
精心地降低了昂贵的 Linux 系统调用，减少模式切换开销，大部分工作都在用户空间完成，如时间读取、缓冲聚合及文件描述符的启用和禁用等。

会话保持

HAProxy 为来自同一客户端的请求访问实现了三种会话保持方案：

SOURCE_IP：HAProxy 将客户端的 SOURCE IP 进行 Hash 计算并保存，由此确保相同 IP 访问时被转发到同一台 Real Server 上。
Cookie：HAProxy 依靠 Real Server 发送给客户端的 Cookie 信息进行会话保持
Session：HAProxy 保存 Real Server 的 Session 及服务器标识

健康检查

HAProxy 使用 Health Check 来确定 Backend Real Server 能不能处理分发的客户端请求，这避免了运维人员在 Real Server 不可用时需要人工移除。默认的 Health Check 方法是尝试和 Real Server 建立 TCP 连接，比如：检查 Real Server 是否在预设的 IP:Port 上进行监听。HAProxy 允许手动配置 Health Check 方法，有 TCP，HTTP，PING 三种方式。

当 Real Server 被检查失败时，HAProxy 会自动禁用它，客户端请求不会分发到该 Real Server，直到它重新激活位置。

配置文件

HAProxy 的配置文件为 /etc/haproxy.cfg，主要由 5 部分组成：

global：全局配置参数，属于进程级配置，通常与操作系统配置相关。
defaults：默认配置参数，此部分的设置参数值默认会自动被引用到 frontend、backend 和 listen，属于公用的配置参数部分。如果 default 的配置参数与后面几个部分的私有配置参数冲突，则优先私有配置参数。
frontend（前端）：设置接收客户端请求的前端虚拟节点（LB 服务器），允许根据 ACL 规则直接指定 backend。
backend（后端）：配置后端服务器集群，也就是一组处理客户端请求的 Real Server。
listen：是 frontend 部分和 backend 部分的结合体，在较新版本的版本中 listen section 是可选的。

负载均衡策略

roundrobin：简单轮询
static-rr：权重轮询
leastconn：最少连接数优先
source：请求源主机 IP 地址
uri：请求 URI
url_param：请求 URl 的参数
hdr(name)：根据 HTTP Request Hander 锁定每一次 HTTP 请求
rdp-cookie(name)：根据据 Cookie 锁定并哈希每一次 TCP 请求

ACL 规则

HAProxy 支持基于 ACL 规则的分发策略：

通过 ACL 规则检查客户端请求是否合法
符合 ACL 规则的客户端请求被提交到指定 backend

ACL 规则经常被用到 frontend section，使用方式：

acl <acl_name> <acl_method> -i [匹配的路径或文件]

acl_name：自定义名称
<acl_method>：hdr_reg(host)、hdr_dom(host)、hdr_beg(host)、url_sub、url_dir、path_beg、path_end etc.
[匹配的路径或文件]：支持使用正则表达式，e.g. .html .jpg .gif

EXAMPLE：

acl www_policy hdr_reg(host) -i ^(www.z.cn|z.cn)
acl bbs_policy hdr_dom(host) -i bbs.z.cn
acl url_policy url_sub -i buy_sid=
use_backend server_www if www_policy
use_backend server_app if url_policy
use_backend server_bbs if bbs_policy
default_backend server_cache

常与 ACL 规则一起使用配置参数有 use_backend 和 default_backend，两者均用于指定 backend。

use_backend：满足 ACL 规则的客户端请求就转发至该 backend
default_backend：没有满足 ACL 规则的客户端请求转发至该 backend

Web 监控平台

HAProxy 支持基于 Web 的监控平台，可以查看 frontend 和 backend 的运行状态，当出现故障时，会通过不同颜色来展示故障信息，解决了故障报警问题。

Keepalived 虚拟路由器

KeepAlived 是一个使用 C 编写的，基于 VRRP 协议的高可用解决方案。通过 VIP 地址和心跳检测支持高可用功能，避免发生单点故障。

核心组件

VRRP Stack：VRRP 协议的实现
IPVS Wrapper：为 RS 集群中的服务器都生成 IPVS 规则
Checkers：对 IPVS 集群的 RS 做健康检查
控制组件：配置文件分析器，用来实现配置文件的分析和加载
I/O 复用器：管理 I/O 复用功能
内存管理组件：用来管理 Keepalived 高可用的内存管理

VRRP 虚拟路由冗余协议

在现实网络环境，经常需要使用路由协议来完成主机定位，使用路由协议的方法常见有两种：

动态路由协议（e.g. RIP、OSPF）
在主机上配置静态路由

显然，在主机上配置静态路由是更多用户可以使用的方式，用户可以在自己的机器上配置一个或多个网关条目。不过使用静态路由存在一个问题，因为大家都依赖于路由器的动态路由协议，所以当路由器处于单点状态并发生故障时，所有人的网络都会受到牵连。VRRP 协议的目的就是为了解决静态路由单点故障问题。

VRRP（Virtual Router Redundancy Protocol，虚拟路由冗余协议），该协议会对共享多存取访问介质（e.g. 以太网）上的主机设备的默认网关（Default Gateway）进行冗余备份，从而当其中一台路由设备宕机时，备份路由设备也能够及时接管路由转发任务。为用户提供了透明、可靠的网络服务质量。

VRRP 的工作机制

VRRP 协议的基本对象概念：VRRP 路由器和虚拟路由器，Master 路由器和 Backup 路由器。

VRRP 路由器：指运行 VRRP 协议的路由器，是物理实体
虚拟路由器：指由 VRRP 协议创建的、虚拟的逻辑路由器，一组 VRRP 路由器协同工作，共同构成一台虚拟路由器。虚拟路由器对外表现为一个固定的 VIP 和 MAC 地址，
Backup 路由器：VRRP 路由器组中起到备份作用的路由器，可以存在任意个 Backup。
Master 路由器：为了保证高可用，VRRP 路由器通常存在多个，其中有且仅有一个是实际工作的，称为 Master 路由器。主要负责转发网关上的 IP 数据包以及响应 ARP 请求等路由工作，Master 并非是一成不变的，VRRP 通过竞选（Election）协议来动态的从 VRRP 路由器组中决策出 Master。Master 拥有一些特权，比如：拥有虚拟路由器的 VIP 和 MAC，客户端都是使用这个 VIP 地址来配置静态路由。
Backup 路由器：作为 Master 路由器的冗余，当 Master 出现故障或需要切换时替换成为新的 Master。

高可用原理

每个 VRRP 路由器至少有一个 vrrp_instance，每个 vrrp_instance 都拥有 VRID 作为唯一标识。VRID 范围在 [0—255] 之间。VRRP 路由器的虚拟 MAC 地址由 VRID 组成，格式为 00-00-5E-00-01-[VRID]。

当 Master 激活时，由 Master 负责使用自己的 MAC 来应答 ARP 请求；当 Master 失效时，选举出一个 Backup 负责响应 ARP 请求（把 VIP 绑定到自己的网卡上）并暂时升级为 Master。当 Master 恢复激活时又会重新接管 VIP，实现了自动化的故障转移。这样的话，无论 Master 如何在 VRRP 路由器中切换，都能保证 ARP 响应给客户端的 VIP 地址对应的 MAC 地址的拥有者始终是激活的。而且客户端不需要因为 Master 的切换而修改自己的静态路由配置，对于客户端主机而言，这种主从切换是透明的。

VRRP 控制报文只有 VRRP 通告（Advertisement）一种。它使用 IP 多播数据包进行封装，组地址为 224.0.0.18，只限于同一 LAN 内发布，保证 VRID 在不同 LAN 中可以重用。为了减少网络带宽消耗，所以只有 Master 可以周期性的发送 VRRP 通告报文。如果 Backup 在连续三个通告间隔内依旧收不到 VRRP 通告，或者收到优先级为 0 的通告后，就是启动新的一轮 Master 选举。

高可用模式

主从模式：单虚拟路由器，只有一个 VIP，当 Master 出现故障时，VIP 漂移到 Backup 上。e.g. 192.168.0.7 是一个 VIP 在两台服务器之间漂移。

这里写图片描述

主主模式：多虚拟路由器，两个 VIP，一个 VRRP 路由器拥有两个 vrrp_instance。当其中一个 Master 故障时，它的 VIP 就漂移到另一台 Master 上（此时有两个 VIP）。当故障恢复后，再将 VIP 重新漂移过来。e.g. 192.168.10.141 和 192.168.10.142 是两个 VIP，可以在两台 Master 之间漂移。

这里写图片描述

健康检查原理

Keepalived 同样支持后端服务器集群的健康状态，如果有 Real Server 出现故障，Keepalived 会及时的检测到并将其从集群剔除。当故障的 Real Server 恢复后，Keepalived 又会自动将其加入集群。这些工作由 Keepalived 自动完成，无需人工干涉，运维人员需要做的只是修复发生故障的 Real Server。

Keepalived 支持 L3, L4 及 L5 层网络的健康检查：

L3：Keepalived 定期向 backend 发送 ICMP 数据包（PING）如果发现某台 Real Server 的 IP 地址没有激活，Keepalived 就会报告该 Server 失效，并将它从 backend 中剔除。L3 的工作就是通过 IP 地址是否有效来判断 Real Server 是否正常工作。
L4：主要以 TCP 端口状态来判断 Real Server 是否正常工作。例如：apache service 的端口一般是 80，如果 Keepalived 检测到 80 端口没有启用，则判断该 Real Server 失效，将其从 backend 中剔除。
L5：工作在应用层，比 L3、L4 要复杂一些，占用的带宽也更大。Keepalived 根据用户预设的业务服务应用程序运行是否正常判断 Real Server 是否正常工作，如果应用程序的运行状态与预设的不符，则将其从 backend 中剔除。

HAProxy & Keepalived

这里写图片描述

HAProxy & Keepalived 组合成为高可用负载均衡解决方案。由 HAProxy 提供 backend 划分和负载均衡；由 Keepalived 提供负载均衡服务器的高可用以及 Real Server 集群的健康检查。

HA1 配置文件（HA2 类似）：

# 全局配置，与操作系统相关
global                                           
    log         127.0.0.1 local2
    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     4000
    user        haproxy
    group       haproxy
    nbproc      1
    daemon
    stats socket /var/lib/haproxy/stats
    
# 默认配置，超时、日志等 
defaults                                        
    mode                    http
    log                     global
    option                  httplog
    option                  dontlognull
    option http-server-close
    option forwardfor       except 127.0.0.0/8
    option                  redispatch
    retries                 3
    timeout http-request    10s
    timeout queue           1m
    timeout connect         10s
    timeout client          1m
    timeout server          1m
    timeout http-keep-alive 10s
    timeout check           10s
    maxconn                 3000

# 设定前端服务器，LB 反向代理服务器
frontend allen                                 
    bind *:80
    mode http
    option httpclose
    # 在 HTTP 头部添加 X-Forwarded-For，使得后端服务器可以获取原始请求的 Source IP   
    option forwardfor
    
    # 在 HTTP 头部添加 X-Forwarded-Port，使得后端服务器可以知道原始请求的 Source Port
    http-request set-header X-Forwarded-Port %[dst_port]
    
    # 在使用 SSL 时添加 X-Forwarded-Proto
    http-request add-header X-Forwarded-Proto https if { ssl_fc } 
    
    # ACL 匹配域，结果为 True or False
    acl url_static  path_end -i .html .jpg .gif
    acl url_dynamic path_end -i .php

    # 根据 acls 规则得到的布尔值来决定分发的 backend
    use_backend     lamp        if url_dynamic
    default_backend webservers

# 设定后端服务器组，业务服务器组
backend webservers
    balance roundrobin
    # 后端业务服务器清单
    server web1 192.168.1.8:80 check rise 2 fall 1 weight 2
    server web2 192.168.1.9:80 check rise 2 fall 1 weight 2
    server web3 192.168.1.10:80 check rise 2 fall 1 weight 2     

# 设定后端服务器组，业务服务器组
backend lamp
    balance source
    # 后端业务服务器清单
    server  lamp 192.168.1.3:80 check rise 2 fall 1            


listen stats
    mode http
    bind 0.0.0.0:8090                # 监控网站地址
    option httpchk GET /info.txt     # 后端真实主机监控检查方式
    stats enable
    stats refresh 3s
    stats hide-version
    stats uri   /allen               # 监控网站 URI
    stats realm Haproxy allen
    stats auth  admin:admin
    stats admin if TRUE

主从模式的 Keepalived 配置

HA1 Keepalived 配置文件：

global_defs {
  notification_email {
    root@localhost
    }
  
  notification_email_from keepalived@localhost
  smtp_server 127.0.0.1
  smtp_connect_timeout 30
  router_id HAproxy237
}
  
vrrp_script chk_haproxy {                           
  script "/etc/keepalived/check_haproxy.sh"
  interval 2
  weight 2
}
  
vrrp_instance VI_1 {    # 配置两台机器配置同一个 VRRP 实例，所以使用同一个 VRID
  state MASTER          # 配置 HA1 为 Master
  interface eth0
  virtual_router_id 51  # 配置同一个 VRID，范围在 [0-255] 之间
  priority 100          # Master 的优先级更高
  advert_int 1
  authentication {
    auth_type PASS
    auth_pass 1111
}
  track_script {
    chk_haproxy
}
virtual_ipaddress {
    182.148.15.239       # 配置同一个 VIP
}
notify_master "/etc/keepalived/clean_arp.sh 182.148.15.239"
}

HA2 Keepalived 配置文件：

global_defs {
  notification_email {
    root@localhost
    }
  
notification_email_from keepalived@localhost
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id HAproxy236
}
  
vrrp_script chk_haproxy {                           
  script "/etc/keepalived/check_haproxy.sh"
  interval 2
  weight 2
}
   
vrrp_instance VI_1 {       # 配置两台机器配置同一个 VRRP 实例，所以使用同一个 VRID
  state BACKUP             # 设置 HA2 为 Backup
  interface eth0
  virtual_router_id 51     # 使用同一个 VRID
  priority 99              # Backup 的优先级更低
  advert_int 1
  authentication {
    auth_type PASS
    auth_pass 1111
}
  track_script {
    chk_haproxy
}
virtual_ipaddress {
    182.148.15.239         # 配置同一个 VIP
}
notify_master "/etc/keepalived/clean_arp.sh 182.148.15.239"
}

主从模式下 Master 和 Backup 配置了同一个 vrrp_instance、同一个 VRID、同一个 VIP。

双活模式的 Keepalived 配置

双活模式，HA1 和 HA2 互为 Master 和 Backup，所以需要配置两个 vrrp_instance，使用两个不同的 VRID，两个 VIP。

HA1 Keepalived 的配置文件：

# 全局配置，设置通知邮件等
global_defs {
   notification_email {
    root@localhost
   }
   notification_email_from admin@allen.com
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id LVS_ALLEN
}

# 异常触发的自动脚本
vrrp_script chk_proess {
    script "killall -0 haproxy"
    interval 1
    weight -2
}

# 配置 VRRP 路由器，HA1 本机充当 Master
vrrp_instance ha_1 {
    state MASTER
    interface eth0
    virtual_router_id 56   # VRID，VRRP 的唯一标识，组成 VRRP 的虚拟 MAC 地址，确保当 HA1 是 Master 时，客户端的 ARP 请求能够接收到 HA1 的 IP 和 MAC 地址
    priority 100           # VRRP 路由器优先级，[0, 255]
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1056
    }
    virtual_ipaddress {
        192.168.1.100/24            # 设定 VIP
    }
    track_script {
        chk_proess
    }
}

#
vrrp_instance ha_2 {
    state BACKUP
    interface eth0
    virtual_router_id 58
    priority 92
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1058
    }
    virtual_ipaddress {
        192.168.1.101/24
    }
}

HA2 Keepalived 的配置文件：

global_defs {
   notification_email {
    root@localhost
   }
   notification_email_from admin@allen.com
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id LVS_ALLEN
}

vrrp_script chk_proess {
    script "killall -0 haproxy"
    interval 1
    weight -2
}

vrrp_instance ha_1 {
    state BACKUP
    interface eth0
    virtual_router_id 56
    priority 99
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1056
    }
    virtual_ipaddress {
        192.168.1.100/24
    }
}

vrrp_instance ha_2 {
    state MASTER
    interface eth0
    virtual_router_id 58
    priority 93
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1058
    }
    virtual_ipaddress {
        192.168.1.101/24
    }
    track_script {
        chk_proess
    }
}

OpenStack 官方的 Controller Node HAProxy 负载均衡示例

global
  chroot  /var/lib/haproxy
  daemon
  group  haproxy
  maxconn  4000
  pidfile  /var/run/haproxy.pid
  user  haproxy

defaults
  log  global
  maxconn  4000
  option  redispatch
  retries  3
  timeout  http-request 10s
  timeout  queue 1m
  timeout  connect 10s
  timeout  client 1m
  timeout  server 1m
  timeout  check 10s

listen dashboard_cluster
  bind <Virtual IP>:443
  balance  source
  option  tcpka
  option  httpchk
  option  tcplog
  server controller1 10.0.0.12:443 check inter 2000 rise 2 fall 5
  server controller2 10.0.0.13:443 check inter 2000 rise 2 fall 5
  server controller3 10.0.0.14:443 check inter 2000 rise 2 fall 5

listen galera_cluster
  bind <Virtual IP>:3306
  balance  source
  option  mysql-check
  server controller1 10.0.0.12:3306 check port 9200 inter 2000 rise 2 fall 5
  server controller2 10.0.0.13:3306 backup check port 9200 inter 2000 rise 2 fall 5
  server controller3 10.0.0.14:3306 backup check port 9200 inter 2000 rise 2 fall 5

listen glance_api_cluster
  bind <Virtual IP>:9292
  balance  source
  option  tcpka
  option  httpchk
  option  tcplog
  server controller1 10.0.0.12:9292 check inter 2000 rise 2 fall 5
  server controller2 10.0.0.13:9292 check inter 2000 rise 2 fall 5
  server controller3 10.0.0.14:9292 check inter 2000 rise 2 fall 5

listen glance_registry_cluster
  bind <Virtual IP>:9191
  balance  source
  option  tcpka
  option  tcplog
  server controller1 10.0.0.12:9191 check inter 2000 rise 2 fall 5
  server controller2 10.0.0.13:9191 check inter 2000 rise 2 fall 5
  server controller3 10.0.0.14:9191 check inter 2000 rise 2 fall 5

listen keystone_admin_cluster
  bind <Virtual IP>:35357
  balance  source
  option  tcpka
  option  httpchk
  option  tcplog
  server controller1 10.0.0.12:35357 check inter 2000 rise 2 fall 5
  server controller2 10.0.0.13:35357 check inter 2000 rise 2 fall 5
  server controller3 10.0.0.14:35357 check inter 2000 rise 2 fall 5

listen keystone_public_internal_cluster
  bind <Virtual IP>:5000
  balance  source
  option  tcpka
  option  httpchk
  option  tcplog
  server controller1 10.0.0.12:5000 check inter 2000 rise 2 fall 5
  server controller2 10.0.0.13:5000 check inter 2000 rise 2 fall 5
  server controller3 10.0.0.14:5000 check inter 2000 rise 2 fall 5

listen nova_ec2_api_cluster
  bind <Virtual IP>:8773
  balance  source
  option  tcpka
  option  tcplog
  server controller1 10.0.0.12:8773 check inter 2000 rise 2 fall 5
  server controller2 10.0.0.13:8773 check inter 2000 rise 2 fall 5
  server controller3 10.0.0.14:8773 check inter 2000 rise 2 fall 5

listen nova_compute_api_cluster
  bind <Virtual IP>:8774
  balance  source
  option  tcpka
  option  httpchk
  option  tcplog
  server controller1 10.0.0.12:8774 check inter 2000 rise 2 fall 5
  server controller2 10.0.0.13:8774 check inter 2000 rise 2 fall 5
  server controller3 10.0.0.14:8774 check inter 2000 rise 2 fall 5

listen nova_metadata_api_cluster
  bind <Virtual IP>:8775
  balance  source
  option  tcpka
  option  tcplog
  server controller1 10.0.0.12:8775 check inter 2000 rise 2 fall 5
  server controller2 10.0.0.13:8775 check inter 2000 rise 2 fall 5
  server controller3 10.0.0.14:8775 check inter 2000 rise 2 fall 5

listen cinder_api_cluster
  bind <Virtual IP>:8776
  balance  source
  option  tcpka
  option  httpchk
  option  tcplog
  server controller1 10.0.0.12:8776 check inter 2000 rise 2 fall 5
  server controller2 10.0.0.13:8776 check inter 2000 rise 2 fall 5
  server controller3 10.0.0.14:8776 check inter 2000 rise 2 fall 5

listen ceilometer_api_cluster
  bind <Virtual IP>:8777
  balance  source
  option  tcpka
  option  tcplog
  server controller1 10.0.0.12:8777 check inter 2000 rise 2 fall 5
  server controller2 10.0.0.13:8777 check inter 2000 rise 2 fall 5
  server controller3 10.0.0.14:8777 check inter 2000 rise 2 fall 5

listen nova_vncproxy_cluster
  bind <Virtual IP>:6080
  balance  source
  option  tcpka
  option  tcplog
  server controller1 10.0.0.12:6080 check inter 2000 rise 2 fall 5
  server controller2 10.0.0.13:6080 check inter 2000 rise 2 fall 5
  server controller3 10.0.0.14:6080 check inter 2000 rise 2 fall 5

listen neutron_api_cluster
  bind <Virtual IP>:9696
  balance  source
  option  tcpka
  option  httpchk
  option  tcplog
  server controller1 10.0.0.12:9696 check inter 2000 rise 2 fall 5
  server controller2 10.0.0.13:9696 check inter 2000 rise 2 fall 5
  server controller3 10.0.0.14:9696 check inter 2000 rise 2 fall 5

listen swift_proxy_cluster
  bind <Virtual IP>:8080
  balance  source
  option  tcplog
  option  tcpka
  server controller1 10.0.0.12:8080 check inter 2000 rise 2 fall 5
  server controller2 10.0.0.13:8080 check inter 2000 rise 2 fall 5
  server controller3 10.0.0.14:8080 check inter 2000 rise 2 fall 5

相关阅读：

抖音音浪10000提现多少「干货详解」

32

如何低成本做抖音高点赞视频

40

抖音运营初期组建团队这几个职位缺一不可

98

HAProxy & Keepalived L4-L7 高可用负载均衡解决方案

目录

文章目录

HAProxy 负载均衡器

应用特性

性能优势

会话保持

健康检查

配置文件

负载均衡策略

ACL 规则

Web 监控平台

Keepalived 虚拟路由器

核心组件

VRRP 虚拟路由冗余协议

VRRP 的工作机制

高可用原理

高可用模式

健康检查原理

HAProxy & Keepalived

主从模式的 Keepalived 配置

双活模式的 Keepalived 配置

OpenStack 官方的 Controller Node HAProxy 负载均衡示例