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

本文涉及的产品
网络型负载均衡 NLB,每月750个小时 15LCU
传统型负载均衡 CLB,每月750个小时 15LCU
应用型负载均衡 ALB,每月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,如需转载请自行联系原作者




相关文章
|
1月前
|
运维 Prometheus 监控
别再“亡羊补牢”了!——聊聊如何优化企业的IT运维监控架构
别再“亡羊补牢”了!——聊聊如何优化企业的IT运维监控架构
103 8
|
1月前
|
Cloud Native Serverless API
微服务架构实战指南:从单体应用到云原生的蜕变之路
🌟蒋星熠Jaxonic,代码为舟的星际旅人。深耕微服务架构,擅以DDD拆分服务、构建高可用通信与治理体系。分享从单体到云原生的实战经验,探索技术演进的无限可能。
微服务架构实战指南:从单体应用到云原生的蜕变之路
|
1月前
|
监控 Cloud Native Java
Spring Boot 3.x 微服务架构实战指南
🌟蒋星熠Jaxonic,技术宇宙中的星际旅人。深耕Spring Boot 3.x与微服务架构,探索云原生、性能优化与高可用系统设计。以代码为笔,在二进制星河中谱写极客诗篇。关注我,共赴技术星辰大海!(238字)
Spring Boot 3.x 微服务架构实战指南
|
2月前
|
消息中间件 数据采集 NoSQL
秒级行情推送系统实战:从触发、采集到入库的端到端架构
本文设计了一套秒级实时行情推送系统,涵盖触发、采集、缓冲、入库与推送五层架构,结合动态代理IP、Kafka/Redis缓冲及WebSocket推送,实现金融数据低延迟、高并发处理,适用于股票、数字货币等实时行情场景。
294 3
秒级行情推送系统实战:从触发、采集到入库的端到端架构
|
1月前
|
人工智能 JavaScript 前端开发
GenSX (不一样的AI应用框架)架构学习指南
GenSX 是一个基于 TypeScript 的函数式 AI 工作流框架,以“函数组合替代图编排”为核心理念。它通过纯函数组件、自动追踪与断点恢复等特性,让开发者用自然代码构建可追溯、易测试的 LLM 应用。支持多模型集成与插件化扩展,兼具灵活性与工程化优势。
194 6
|
2月前
|
设计模式 人工智能 API
AI智能体开发实战:17种核心架构模式详解与Python代码实现
本文系统解析17种智能体架构设计模式,涵盖多智能体协作、思维树、反思优化与工具调用等核心范式,结合LangChain与LangGraph实现代码工作流,并通过真实案例验证效果,助力构建高效AI系统。
421 7
|
2月前
|
人工智能 Cloud Native 中间件
划重点|云栖大会「AI 原生应用架构论坛」看点梳理
本场论坛将系统性阐述 AI 原生应用架构的新范式、演进趋势与技术突破,并分享来自真实生产环境下的一线实践经验与思考。
|
2月前
|
存储 监控 NoSQL
Redis高可用架构全解析:从主从复制到集群方案
Redis高可用确保服务持续稳定,避免单点故障导致数据丢失或业务中断。通过主从复制实现数据冗余,哨兵模式支持自动故障转移,Cluster集群则提供分布式数据分片与水平扩展,三者层层递进,保障读写分离、容灾切换与大规模数据存储,构建高性能、高可靠的Redis架构体系。
|
1月前
|
机器学习/深度学习 自然语言处理 算法
48_动态架构模型:NAS在LLM中的应用
大型语言模型(LLM)在自然语言处理领域的突破性进展,很大程度上归功于其庞大的参数量和复杂的网络架构。然而,随着模型规模的不断增长,计算资源消耗、推理延迟和部署成本等问题日益凸显。如何在保持模型性能的同时,优化模型架构以提高效率,成为2025年大模型研究的核心方向之一。神经架构搜索(Neural Architecture Search, NAS)作为一种自动化的网络设计方法,正在为这一挑战提供创新性解决方案。本文将深入探讨NAS技术如何应用于LLM的架构优化,特别是在层数与维度调整方面的最新进展,并通过代码实现展示简单的NAS实验。

热门文章

最新文章