企业集群平台架构实现与应用实战(HAproxy+keepalived篇)

本文涉及的产品
.cn 域名,1个 12个月
应用型负载均衡 ALB,每月750个小时 15LCU
网络型负载均衡 NLB,每月750个小时 15LCU
简介:

一、四层和七层负载均衡的区别

所谓的四层就是ISO参考模型中的第四层。四层负载均衡也称为四层交换机,它主要是通过分析IP层及TCP/UDP层的流量实现的基于IP加端口的负载均衡。常见的基于四层的负载均衡器有LVS、F5等。

以常见的TCP应用为例,负载均衡器在接收到第一个来自客户端的SYN请求时,会通过设定的负载均衡算法选择一个最佳的后端服务器,同时将报文中目标IP地址修改为后端服务器IP,然后直接转发给该后端服务器,这样一个负载均衡请求就完成了。从这个过程来看,一个TCP连接是客户端和服务器直接建立的,而负载均衡器只不过完成了一个类似路由器的转发动作。在某些负载均衡策略中,为保证后端服务器返回的报文可以正确传递给负载均衡器,在转发报文的同时可能还会对报文原来的源地址进行修改。整个过程下图所示。

wKioL1dfXEiy30hCAABEn10fvd8185.png



同理,七层负载均衡器也称为七层交换机,位于OSI的最高层,即应用层,此时负载均衡器支持多种应用协议,常见的有HTTP、FTP、SMTP等。七层负载均衡器可以根据报文内容,再配合负载均衡算法来选择后端服务器,因此也称为“内容交换器”。比如,对于Web服务器的负载均衡,七层负载均衡器不但可以根据“IP+端口”的方式进行负载分流,还可以根据网站的URL、访问域名、浏览器类别、语言等决定负载均衡的策略。例如,有两台Web服务器分别对应中英文两个网站,两个域名分别是A、B,要实现访问A域名时进入中文网站,访问B域名时进入英文网站,这在四层负载均衡器中几乎是无法实现的,而七层负载均衡可以根据客户端访问域名的不同选择对应的网页进行负载均衡处理。常见的七层负载均衡器有HAproxy、Nginx等。


这里仍以常见的TCP应用为例,由于负载均衡器要获取到报文的内容,因此只能先代替后端服务器和客户端建立连接,接着,才能收到客户端发送过来的报文内容,然后再根据该报文中特定字段加上负载均衡器中设置的负载均衡算法来决定最终选择的内部服务器。纵观整个过程,七层负载均衡器在这种情况下类似于一个代理服务器。整个过程如下图所示。

wKiom1dfW06APOX2AABGWCtgsH0727.png


对比四层负载均衡和七层负载均衡运行的整个过程,可以看出,在七层负载均衡模式下,负载均衡器与客户端及后端的服务器会分别建立一次TCP连接,而在四层负载均衡模式下,仅建立一次TCP连接。由此可知,七层负载均衡对负载均衡设备的要求更高,而七层负载均衡的处理能力也必然低于四层模式的负载均衡。

二、HAProxy与LVS的异同

通过之前文章的介绍,大家应该基本清楚了HAProxy负载均衡与LVS负载均衡的优缺点和异同了。下面就这两种负载均衡软件的异同做一个简单总结:

1)两者都是软件负载均衡产品,但是LVS是基于Linux操作系统实现的一种软负载均衡,而HAProxy是基于第三应用实现的软负载均衡。

2)LVS是基于四层的IP负载均衡技术,而HAProxy是基于四层和七层技术、可提供TCP和HTTP应用的负载均衡综合解决方案。

3)LVS工作在ISO模型的第四层,因此其状态监测功能单一,而HAProxy在状态监测方面功能强大,可支持端口、URL、脚本等多种状态检测方式。

4)HAProxy虽然功能强大,但是整体处理性能低于四层模式的LVS负载均衡,而LVS拥有接近硬件设备的网络吞吐和连接负载能力。

综上所述,HAProxy和LVS各有优缺点,没有好坏之分,要选择哪个作为负载均衡器,要以实际的应用环境来决定。

三、快速安装HAProxy集群软件


可以在HAProxy的官网http:// www.haproxy.org/下载HAProxy的源码包,这里以操作系统Centos6.5版本为例,下载的HAProxy是目前的稳定版本haproxy-1.6.4.tar.gz,安装过程如下:

1
2
3
4
5
6
7
8
9
[root@haproxy-server app] # tar zcvf haproxy-1.6.4.tar.gz
[root@haproxy-server app] #cd haproxy-1.6.4
[root@haproxy-server haproxy-1.6.4] #make TARGET=linux26 PREFIX=/usr/local/haproxy    
[root@haproxy-server haproxy-1.6.4] #make install PREFIX=/usr/local/haproxy
  #将haproxy安装到/usr/local/haproxy下
[root@haproxy-server haproxy-1.6.4] #mkdir  /usr/local/haproxy/conf
#haproxy默认不创建配置文件目录,这里是创建haproxy配置文件目录
[root@haproxy-server haproxy-1.6.4] # cp examples/ option-http_proxy.cfg \
/usr/local/haproxy/conf/haproxy .cfg #haproxy


安装完成后,默认安装目录中没有配置文件,这里是将源码包里面的示例配置文件拷贝到配置文件目录

这样,HAProxy就安装完成了。


四、HAProxy基础配置文件详解

HAProxy配置文件根据功能和用途,主要有5个部分组成,但有些部分并不是必须的,可以根据需要选择相应的部分进行配置。

(1)global部分

用来设定全局配置参数,属于进程级的配置,通常和操作系统配置有关。

(2)defaults部分

默认参数的配置部分。在此部分设置的参数值,默认会自动被引用到下面的frontend、backend和listen部分中,因此,如果某些参数属于公用的配置,只需在defaults部分添加一次即可。而如果在frontend、backend和listen部分中也配置了与defaults部分一样的参数,那么defaults部分参数对应的值自动被覆盖。

(3)frontend部分

此部分用于设置接收用户请求的前端虚拟节点。frontend是在HAProxy1.3版本之后才引入的一个组件,同时引入的还有backend组件。通过引入这些组件,在很大程度上简化了HAProxy配置文件的复杂性。frontend可以根据ACL规则直接指定要使用的后端backend。

(4)backend部分

此部分用于设置集群后端服务集群的配置,也就是用来添加一组真实服务器,以处理前端用户的请求。添加的真实服务器类似于LVS中的real server节点。

(5)listen部分

此部分是frontend部分和backend部分的结合体。在HAProxy1.3版本之前,HAProxy的所有配置选项都在这个部分中设置。为了保持兼容性,HAProxy新的版本仍然保留了listen组件的配置方式。目前在HAProxy中,两种配置方式任选其一即可。


下面是一个完整的HAProxy配置文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
global
         log 127.0.0.1 local0 info
         maxconn 4096
         user nobody
         group nobody
         daemon
         nbproc 1
         pidfile  /usr/local/haproxy/logs/haproxy .pid
defaults
         mode http
         retries 3
         timeout connect 10s
         timeout client 20s
         timeout server 30s
         timeout check 5s
frontend www
          bind *:80
          mode   http
          option  httplog
          option  forwardfor
          option  httpclose
          log     global
         #acl host_www           hdr_dom(host)   -i      www.zb.com
         #acl host_img            hdr_dom(host)   -i      img.zb.com
         #use_backend htmpool    if      host_www
         #use_backend imgpool    if      host_img
         default_backend  htmpool
backend htmpool
         mode    http
         option   redispatch
         option   abortonclose
         balance  static-rr
         cookie   SERVERID
         option   httpchk GET  /index .jsp
         server  237server 192.168.81.237:8080 cookie server1 weight 6 check inter 2000 rise 2 fall 3
         server  iivey234 192.168.81.234:8080 cookie server2 weight 3 check inter 2000 rise 2 fall 3
backend imgpool
         mode    http
         option   redispatch
         option   abortonclose
         balance  static-rr
         cookie   SERVERID
         option   httpchk GET  /index .jsp
         server  host236 192.168.81.236:8080 cookie server1 weight 6 check inter 2000 rise 2 fall 3
listen admin_stats
         bind 0.0.0.0:9188
         mode http
         log 127.0.0.1 local0 err
         stats refresh 30s
         stats uri  /haproxy-status
         stats realm welcome login\ Haproxy
         stats auth admin:admin~!@
         stats hide-version
         stats admin  if  TRUE

五、启动与测试haproxy的负载均衡功能

1
2
3
4
5
6
7
8
1、启动与管理haproxy
启动服务:
# /usr/local/haproxy/sbin/haproxy -f  /usr/local/haproxy/conf/haproxy.cfg
重启服务:
# /usr/local/haproxy /sbin/haproxy -f /usr/local/haproxy/conf/haproxy.cfg  \
-st ` cat  /usr/local/haproxy/logs/haproxy .pid`
停止服务:
# killall haproxy


六、HAProxy负载均衡器算法与使用技巧


1、HAProxy支持的负载均衡算法

(1)、roundrobin,表示简单的轮询,负载均衡基础算法

(2)、static-rr,表示根据权重

(3)、leastconn,表示最少连接者先处理

(4)、source,表示根据请求源IP

(5)、uri,表示根据请求的URI;

(6)、url_param,表示根据请求的URl参数来进行调度

(7)、hdr(name),表示根据HTTP请求头来锁定每一次HTTP请求;

(8)、rdp-cookie(name),表示根据据cookie(name)来锁定并哈希每一次TCP请求。


2、常用的负载均衡算法


(1)轮询算法:roundrobin   

(2)根据请求源IP算法:source

(3)最少连接者先处理算法:lestconn


七、通过HAProxy的ACL规则实现智能负载均衡


由于HAProxy可以工作在七层模型下, 因此,要实现HAProxy的强大功能,一定要使用强大灵活的ACL规则,通过ACL规则可以实现基于HAProxy的智能负载均衡系统。HAProxy通过ACL规则完成两种主要的功能,分别是:

1)通过设置的ACL规则检查客户端请求是否合法。如果符合ACL规则要求,那么就将放行,反正,如果不符合规则,则直接中断请求。

2)符合ACL规则要求的请求将被提交到后端的backend服务器集群,进而实现基于ACL规则的负载均衡。


HAProxy中的ACL规则经常使用在frontend段中,使用方法如下:

1
acl  自定义的acl名称  acl方法  -i  [匹配的路径或文件]

其中:

acl:是一个关键字,表示定义ACL规则的开始。后面需要跟上自定义的ACL名称 。

acl方法:这个字段用来定义实现ACL的方法,HAProxy定义了很多ACL方法,经常使用的方法有hdr_reg(host)、hdr_dom(host)、hdr_beg(host)、url_sub、url_dir、path_beg、path_end等。

-i:表示忽略大小写,后面需要跟上匹配的路径或文件或正则表达式。

与ACL规则一起使用的HAProxy参数还有use_backend,use_backend后面需要跟上一个backend实例名,表示在满足ACL规则后去请求哪个backend实例,与use_backend对应的还有default_backend参数,它表示在没有满足ACL条件的时候默认使用哪个后端backend。

下面列举几个常见的ACL规则例子:

1
2
3
4
5
6
7
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

八、使用HAProxy的Web监控平台


HAProxy虽然实现了服务的故障转移,但是在主机或者服务出现故障的时候,并不能发出通知告知运维人员,这对于及时性要求很高的业务系统来说,是非常不便的,不过,HAProxy似乎也考虑到了这一点,在新的版本中HAProxy推出了一个基于Web的监控平台,通过这个平台可以查看此集群系统所有后端服务器的运行状态,在后端服务或服务器出现故障时,监控页面会通过不同的颜色来展示故障信息,这在很大程度上解决了后端服务器故障报警的问题,运维人员可通过监控这个页面来第一时间发现节点故障,进而修复故障。

wKiom1dfW-TSuP9-AAEuBOq06VM630.png


















本文转自南非蚂蚁51CTO博客,原文链接: http://blog.51cto.com/ixdba/1788995,如需转载请自行联系原作者




相关文章
|
14天前
|
运维 Cloud Native 持续交付
深入理解云原生架构及其在现代企业中的应用
随着数字化转型的浪潮席卷全球,企业正面临着前所未有的挑战与机遇。云计算技术的迅猛发展,特别是云原生架构的兴起,正在重塑企业的IT基础设施和软件开发模式。本文将深入探讨云原生的核心概念、关键技术以及如何在企业中实施云原生策略,以实现更高效的资源利用和更快的市场响应速度。通过分析云原生架构的优势和面临的挑战,我们将揭示它如何助力企业在激烈的市场竞争中保持领先地位。
|
1天前
|
NoSQL 关系型数据库 MySQL
《docker高级篇(大厂进阶):4.Docker网络》包括:是什么、常用基本命令、能干嘛、网络模式、docker平台架构图解
《docker高级篇(大厂进阶):4.Docker网络》包括:是什么、常用基本命令、能干嘛、网络模式、docker平台架构图解
79 56
《docker高级篇(大厂进阶):4.Docker网络》包括:是什么、常用基本命令、能干嘛、网络模式、docker平台架构图解
|
19天前
|
Cloud Native 安全 持续交付
深入理解微服务架构及其在现代软件开发中的应用
深入理解微服务架构及其在现代软件开发中的应用
39 3
|
19天前
|
运维 Kubernetes Docker
深入理解容器化技术及其在微服务架构中的应用
深入理解容器化技术及其在微服务架构中的应用
40 1
|
20天前
|
监控 持续交付 API
深入理解微服务架构及其在现代应用开发中的应用
深入理解微服务架构及其在现代应用开发中的应用
24 0
|
21天前
|
边缘计算 监控 自动驾驶
揭秘云计算中的边缘计算:架构、优势及应用场景
揭秘云计算中的边缘计算:架构、优势及应用场景
|
13天前
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。
|
22天前
|
Cloud Native Devops 云计算
云计算的未来:云原生架构与微服务的革命####
【10月更文挑战第21天】 随着企业数字化转型的加速,云原生技术正迅速成为IT行业的新宠。本文深入探讨了云原生架构的核心理念、关键技术如容器化和微服务的优势,以及如何通过这些技术实现高效、灵活且可扩展的现代应用开发。我们将揭示云原生如何重塑软件开发流程,提升业务敏捷性,并探索其对企业IT架构的深远影响。 ####
35 3
|
1月前
|
Cloud Native 安全 数据安全/隐私保护
云原生架构下的微服务治理与挑战####
随着云计算技术的飞速发展,云原生架构以其高效、灵活、可扩展的特性成为现代企业IT架构的首选。本文聚焦于云原生环境下的微服务治理问题,探讨其在促进业务敏捷性的同时所面临的挑战及应对策略。通过分析微服务拆分、服务间通信、故障隔离与恢复等关键环节,本文旨在为读者提供一个关于如何在云原生环境中有效实施微服务治理的全面视角,助力企业在数字化转型的道路上稳健前行。 ####
|
12天前
|
Java 开发者 微服务
从单体到微服务:如何借助 Spring Cloud 实现架构转型
**Spring Cloud** 是一套基于 Spring 框架的**微服务架构解决方案**,它提供了一系列的工具和组件,帮助开发者快速构建分布式系统,尤其是微服务架构。
117 68
从单体到微服务:如何借助 Spring Cloud 实现架构转型