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

时间:2022-09-21 00:26:21

目录

HAProxy 负载均衡器

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

  1. 四层代理:HAProxy 采用 NAT 模式,在客户端和 Real Server 之间双向转发流量
  2. 七层代理: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 为来自同一客户端的请求访问实现了三种会话保持方案:

  1. SOURCE_IP:HAProxy 将客户端的 SOURCE IP 进行 Hash 计算并保存,由此确保相同 IP 访问时被转发到同一台 Real Server 上。
  2. Cookie:HAProxy 依靠 Real Server 发送给客户端的 Cookie 信息进行会话保持
  3. 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_backenddefault_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 虚拟路由冗余协议

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

  1. 动态路由协议(e.g. RIP、OSPF)
  2. 在主机上配置静态路由

显然,在主机上配置静态路由是更多用户可以使用的方式,用户可以在自己的机器上配置一个或多个网关条目。不过使用静态路由存在一个问题,因为大家都依赖于路由器的动态路由协议,所以当路由器处于单点状态并发生故障时,所有人的网络都会受到牵连。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 在两台服务器之间漂移。

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

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

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

健康检查原理

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 L4-L7 高可用负载均衡解决方案

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

HAProxy & Keepalived L4-L7 高可用负载均衡解决方案的更多相关文章

  1. Haproxy&plus;Keepalived搭建Weblogic高可用负载均衡集群

    配置环境说明: KVM虚拟机配置 用途 数量 IP地址 机器名 虚拟IP地址 硬件 内存3G  系统盘20G cpu 4核 Haproxy keepalived 2台 192.168.1.10 192 ...

  2. Dubbo入门到精通学习笔记(二十):MyCat在MySQL主从复制的基础上实现读写分离、MyCat 集群部署&lpar;HAProxy &plus; MyCat&rpar;、MyCat 高可用负载均衡集群Keepalived

    文章目录 MyCat在MySQL主从复制的基础上实现读写分离 一.环境 二.依赖课程 三.MyCat 介绍 ( MyCat 官网:http://mycat.org.cn/ ) 四.MyCat 的安装 ...

  3. LVS&plus;Keepalived搭建MyCAT高可用负载均衡集群

    LVS+Keepalived 介绍 LVS LVS是Linux Virtual Server的简写,意即Linux虚拟服务器,是一个虚拟的服务器集群系统.本项目在1998年5月由章文嵩博士成立,是中国 ...

  4. CentOS 6&period;3下部署LVS&lpar;NAT&rpar;&plus;keepalived实现高性能高可用负载均衡

    一.简介 VS/NAT原理图: 二.系统环境 实验拓扑: 系统平台:CentOS 6.3 Kernel:2.6.32-279.el6.i686 LVS版本:ipvsadm-1.26 keepalive ...

  5. 转载--CentOS 6&period;3下部署LVS&lpar;NAT&rpar;&plus;keepalived实现高性能高可用负载均衡

    源地址:http://www.cnblogs.com/mchina/archive/2012/08/27/2644391.html 一.简介 VS/NAT原理图: 二.系统环境 实验拓扑: 系统平台: ...

  6. RHEL 5&period;4下部署LVS&lpar;DR&rpar;&plus;keepalived实现高性能高可用负载均衡

    原文地址:http://www.cnblogs.com/mchina/archive/2012/05/23/2514728.html 一.简介 LVS是Linux Virtual Server的简写, ...

  7. CentOS 6&period;3下部署LVS&lpar;NAT&rpar;&plus;keepalived实现高性能高可用负载均衡【转】

    CentOS 6.3下部署LVS(NAT)+keepalived实现高性能高可用负载均衡   一.简介 VS/NAT原理图: 二.系统环境 实验拓扑: 系统平台:CentOS 6.3 Kernel:2 ...

  8. CentOS 6&period;3下部署LVS&lpar;NAT模式&rpar;&plus;keepalived实现高性能高可用负载均衡

    一.简介 VS/NAT原理图: 二.系统环境 实验拓扑: 系统平台:CentOS 6.3 Kernel:2.6.32-279.el6.i686 LVS版本:ipvsadm-1.26 keepalive ...

  9. CentOS 6&period;3下部署LVS&lpar;NAT&rpar;&plus;keepalived实现高性能高可用负载均衡&lpar;转&rpar;

    一.简介 VS/NAT原理图: 二.系统环境 实验拓扑: 系统平台:CentOS 6.3 Kernel:2.6.32-279.el6.i686 LVS版本:ipvsadm-1.26 keepalive ...

随机推荐

  1. JS 删除对象属性

    updateNode: function(data) { if(data) { this.root[data.id] = data; } }, removeNodes: function(idsArr ...

  2. oracle应该安装在什么版本的linux下

    今天想在我的ubuntu上安装oracle 11g r2,在网上所有了一些教程,然后找到了oracle官网网站的Operating System Requirements,内容如下: Operatin ...

  3. Android Studio常用插件续

    这个月因为各种事情在忙,包括赶项目,回老家,还有准备旅游的事,所以应该写不了四篇博客了.今天介绍一下关于Android Studio 的几个好用的插件,都是我在用的,它们或能帮你节省时间,或者让你心情 ...

  4. 【Android UI设计与开发】第17期:滑动菜单栏(二)开源项目SlidingMenu的示例

    通过上一篇文章的讲解,相信大家对于开源项目SlidingMenu都有了一个比较初步的了解(不了解的可以参考上 一篇文章),那么从这一章开始,博主将会以SlidingMenu为重心,给大家带来非常丰富的 ...

  5. CSS3 2D、3D转换

    2D转换方法:transform().rotate().scale().skew().matrix() 3D转换方法:rotateX().rotateY() 1.示例代码 <!DOCTYPE h ...

  6. 什么是BFC

    对css有了解的朋友肯定都知道盒式模型这个概念,对一个元素设置css,首先需要知道这个元素是block还是inline类型.而BFC就是用来格式化块级盒子,同样管理inline类型的盒子还有IFC,以 ...

  7. 开源&period;NET界面库

    一.十大开源的.NET用户界面框架 选择一款合适的GUI框架是.NET开发中比较重要但又很棘手的问题,因为用户界面相当于一款应用的"门面",直接面向用户.好的UI更能吸引用户,有时 ...

  8. C&num;------Aspose&period;cells使用方法

    转载: http://www.cnblogs.com/muer/p/yaxle.html 代码: public ActionResult ImportData(HttpPostedFileBase f ...

  9. 移动平台的meta标签

    这个meta在移动平台上有非常神奇的地方. 1. <meta name="viewport" content="width=device-width; initia ...

  10. Ping用法大全

              Ping是典型的网络工具.Ping可以辨别网络功能的某些状态. 这些网络功能的状态是日常网络故障诊断的基础.特别是Ping可以识别连接的二进制状态(也就是是否连通).可是,这仅仅是 ...