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

简介:

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

所谓的四层就是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,如需转载请自行联系原作者




相关实践学习
基于函数计算快速搭建Hexo博客系统
本场景介绍如何使用阿里云函数计算服务命令行工具快速搭建一个Hexo博客。
相关文章
|
5天前
|
机器学习/深度学习 API 语音技术
|
25天前
|
Cloud Native Devops 持续交付
构建未来:云原生架构在现代企业中的应用与挑战
【2月更文挑战第31天】 随着数字化转型的加速,云原生技术已经成为推动企业IT架构现代化的关键力量。本文深入探讨了云原生架构的核心组件、实施策略以及面临的主要挑战。通过分析容器化、微服务、DevOps和持续集成/持续部署(CI/CD)等关键技术,揭示了如何利用这些技术实现敏捷性、可扩展性和弹性。同时,文章还讨论了企业在采纳云原生实践中可能遇到的安全性、复杂性和文化适应性问题,并提供了解决这些问题的策略和建议。
|
1月前
|
数据库 Android开发 开发者
构建高性能微服务架构:从理论到实践构建高效Android应用:探究Kotlin协程的优势
【2月更文挑战第16天】 在当今快速迭代和竞争激烈的软件市场中,微服务架构以其灵活性、可扩展性和独立部署能力而受到企业的青睐。本文将深入探讨如何构建一个高性能的微服务系统,涵盖从理论基础到具体实现的各个方面。我们将重点讨论服务拆分策略、通信机制、数据一致性以及性能优化等关键主题,为读者提供一个清晰、实用的指南,以便在复杂多变的业务环境中构建和维护健壮的微服务体系结构。 【2月更文挑战第16天】 在移动开发领域,性能优化和流畅的用户体验是至关重要的。随着技术的不断进步,Kotlin作为一种现代编程语言,在Android开发中被广泛采用,尤其是其协程特性为异步编程带来了革命性的改进。本文旨在深入
238 5
|
1月前
|
SQL NoSQL 前端开发
基于BS架构的饰品购物平台设计与实现(程序+文档+数据库)
基于BS架构的饰品购物平台设计与实现(程序+文档+数据库)
|
1月前
Web应用基本架构
Web应用基本架构。
37 6
|
2月前
|
存储 监控 安全
360 企业安全浏览器基于阿里云数据库 SelectDB 版内核 Apache Doris 的数据架构升级实践
为了提供更好的日志数据服务,360 企业安全浏览器设计了统一运维管理平台,并引入 Apache Doris 替代了 Elasticsearch,实现日志检索与报表分析架构的统一,同时依赖 Doris 优异性能,聚合分析效率呈数量级提升、存储成本下降 60%....为日志数据的可视化和价值发挥提供了坚实的基础。
360 企业安全浏览器基于阿里云数据库 SelectDB 版内核 Apache Doris 的数据架构升级实践
|
21天前
|
运维 Cloud Native 持续交付
云原生架构的未来演进:打造灵活、高效的企业IT基础
随着数字化转型的不断深入,企业的IT基础设施正经历着从传统架构向云原生架构的根本转变。本文将探讨云原生技术的最新发展趋势,分析其在提高业务敏捷性、降低运维成本以及促进技术创新方面的关键作用。我们将重点讨论如何借助容器化、微服务、DevOps和持续交付等核心技术,构建一个能够适应快速变化市场需求的云原生生态系统。通过实际案例分析,揭示企业在迁移到云原生架构过程中面临的挑战与解决策略,为读者呈现一幅云原生技术赋能企业未来的蓝图。
|
4天前
|
运维 监控 自动驾驶
构建可扩展的应用程序:Apollo与微服务架构的完美结合
构建可扩展的应用程序:Apollo与微服务架构的完美结合
27 10
|
5天前
|
机器学习/深度学习 PyTorch API
|
5天前
|
机器学习/深度学习 语音技术 算法框架/工具