架构扩展ha-proxy

本文涉及的产品
传统型负载均衡 CLB,每月750个小时 15LCU
应用型负载均衡 ALB,每月750个小时 15LCU
日志服务 SLS,月写入数据量 50GB 1个月
简介: ha-proxy是一款高性能的负载均衡软件。因为其专注于负载均衡这一些事情,因此与nginx比起来在负载均衡这件事情上做更好。

前言

ha-proxy是一款高性能的负载均衡软件。因为其专注于负载均衡这一些事情,因此与nginx比起来在负载均衡这件事情上做更好。


具有如下功能:


根据静态分配的cookies完成HTTP请求转发

在多个服务器间实现负载均衡,并且根据HTTP cookies 实现会话粘性

主备服务器切换

接受访问特定端口实现服务监控

实现平滑关闭服务,不中断已建立连接的请求响应,拒绝新的请求

在请求或响应HTTP报文中添加,修改,或删除首部信息

根据正则规则阻断请求

提供带有用户认证机制的服务状态报告页面

链接:https://www.jianshu.com/p/8af373981cfe

来源:简书


1、下载安装Haproxy

1.1、下载

下载地址:https://src.fedoraproject.org/repo/pkgs/haproxy/


1.2、安装

将下载的安装包上传至服务器。

tar -xvf haproxy-2.6.6.tar.gz

cd haproxy-2.6.6

make TARGET=linux31                         # centos7.x是linux31、centos6.x是linux26

sudo make install PREFIX=/usr/local/haproxy # 安装到指定路径

cd /usr/local/haproxy/

mkdir conf pid                                 # 分别用来存放配置、进程文件



2、配置Haproxy

2.1、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 规则直接

指定要使用的后端。


4、backend 部分

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

似于 LVS 中的 real server 节点。


5、listen 部分

此部分是 frontend 部分和 backend 部分的结合体。在 Haproxy1.3 版本之前,Haproxy 的所有配置选项都在这个部分中设置。

为了保持兼容性,Haproxy 新的版本仍然保留了 listen 组件的配置方式。目前在 Haproxy 中,两种配置方式任选其一即可。


2.2、Haproxy配置文件示例

vim /usr/local/haproxy/haproxy.cfg

global

   log 127.0.0.1 local0 debug

   maxconn 4096

   daemon

   nbproc 1 # 进程数,创建多个进程,能够减少每个进程的任务队列,但是过多的进程可能会导致进程的崩溃

   pidfile /usr/local/haproxy/pid/haproxy.pid

defaults

   mode http

   retries 3 # 连接后端服务器失败的次数如果超过这里设置的值,haproxy会将对应的后端服务器标记为不可用

   timeout connect 10s

   timeout client 20s

   timeout server 30s

   timeout check 5s

# 接入配置

frontend http_in

   bind *:11000

   mode http

   option httpclose # 此选项表示在客户端和服务器端完成一次连接请求后,haproxy将主动关闭此TCP连接

   default_backend http_in_forward

# 接出配置

backend http_in_forward

   mode http

   balance roundrobin

   option abortonclose # 在服务器负载很高的情况下,自动结束掉当前队列中处理时间比较长的链接

   server real_server1 192.168.8.20:80 check inter 10000 rise 1 fall 3 weight 1

   server real_server2 192.168.8.30:80 check inter 10000 rise 1 fall 3 weight 1



# 接入接出一起配置,相当于frontend和backend同时配置

listen http_in_config

   bind *:12000

   mode http

   balance roundrobin

   option httpclose # 此选项表示在客户端和服务器端完成一次连接请求后,haproxy将主动关闭此TCP连接

   option abortonclose # 在服务器负载很高的情况下,自动结束掉当前队列中处理时间比较长的链接

   server real_server1 192.168.8.20:80 check inter 10000 rise 1 fall 3 weight 1

   server real_server2 192.168.8.30:80 check inter 10000 rise 1 fall 3 weight 1

 

# 监控页面

listen admin_stats

   bind *:11001

   mode http

   stats refresh 30s

   stats uri /admin

   stats realm welcome login\ Haproxy

   stats auth admin:admin123

   stats admin if TRUE # 通过设置此选项,可以在监控页面上手工启用或禁用后端真实服务器



===================================================


配置文件详解:

global配置

log:全局的日志配置,local0是日志设备,debug表示日志级别。其中日志级别有err、warning、info、debug四种可选。

   这个配置表示使用127.0.0.1上的rsyslog服务中的local0日志设备,记录日志等级为debug。


maxconn:设定每个haproxy进程可接受的最大并发连接数,此选项等同于Linux命令行选项"ulimit -n"。


daemon:设置haproxy进程进入后台运行。这是推荐的运行模式。


nbproc:设置haproxy启动时可创建的进程数,此参数要求将haproxy运行模式设置为daemon,默认只启动一个进程。根据使用

经验,该值的设置应该小于服务器的CPU核数。创建多个进程,能够减少每个进程的任务队列,但是过多的进程可能会导致进程

的崩溃。


pidfile:指定haproxy进程的pid文件。启动进程的用户必须有访问此文件的权限。


-------------


defaults配置

mode:设置haproxy实例默认的运行模式,有tcp、http、health三个可选值。

   tcp模式:客户端和服务器端之间将建立一个全双工的连接,不会对七层报文做任何类型的检查,默认为 tcp 模式,经常用于 SSL、SSH、SMTP 等应用。

   http模式:在此模式下,客户端请求在转发至后端服务器之前将会被深度分析,所有不与 RFC 格式兼容的请求都会被拒绝。

   health模式:目前此模式基本已经废弃,不在多说。


retries:设置连接后端服务器的失败重试次数,连接失败的次数如果超过这里设置的值,haproxy会将对应的后端服务器标记为

不可用。此参数也可在后面部分进行设置。


timeout connect:设置成功连接到一台服务器的最长等待时间,默认单位是毫秒,但也可以使用其他的时间单位后缀。


timeout client:设置连接客户端发送数据时最长等待时间,默认单位是毫秒,也可以使用其他的时间单位后缀。


timeout server:设置服务器端回应客户度数据发送的最长等待时间,默认单位是毫秒,也可以使用其他的时间单位后缀。


timeout check:设置对后端服务器的检测超时时间,默认单位是毫秒,也可以使用其他的时间单位后缀。


-----------------


frontend配置

bind:此选项只能在frontend和listen部分进行定义,用于定义一个或几个监听的套接字。


option httpclose:此选项表示在客户端和服务器端完成一次连接请求后,haproxy将主动关闭此TCP连接。这是对性能非常有

帮助的一个参数。


default_backend:指定默认的后端服务器池,也就是指定一组后端真实服务器,而这些真实服务器组将在backend段进行定义。

这里的http_in_forward就是一个后端服务器组。


----------------


backend配置

balance:此关键字用来定义负载均衡算法。目前haproxy支持多种负载均衡算法,常用的有如下几种。


roundrobin:

   是基于权重进行轮询调度的算法,在服务器的性能分布比较均匀的时候,这是一种最公平、最合理的算法。此算法经常使用。


static-rr:

   也是基于权重进行轮询的调度算法,不过此算法为静态方法,在运行时调整其服务器权重不会生效。


source:

   是基于请求源 IP 的算法。此算法先对请求的源 IP 进行 hash 运算, 然后将结果与后端服务器的权重总数相除后转发至

   某个匹配的后端服务器。这种方式可以使同一个客户端 IP 的请求始终被转发到某特定的后端服务器。


leastconn:

   此算法会将新的连接请求转发到具有最少连接数目的后端服务器。在会话时间较长的场景中推荐使用此算法,例如数据库

   负载均衡等。此算法不适合会话较短的环境中,例如基于 HTTP 的应用。


uri:

   此算法会对部分或整个 URI 进行 hash 运算,再经过与服务器的总权重相除,最后转发到某台匹配的后端服务器上。


uri_param:

   此算法会根据 URL 路径中的参数进行转发,这样可保证在后端真实服务器数量不变时,同一个用户的请求始终分发到同一

   台机器上。


hdr(<name>):

   此算法根据 http 头进行转发,如果指定的 http 头名称不存在,则使用 roundrobin 算法进行策略转发。

 


option abortonclose:如果设置了此参数,可以在服务器负载很高的情况下,自动结束掉当前队列中处理时间比较长的链接。


server:这个关键字用来定义多个后端真实服务器,不能用于 defaults 和frontend部分。

   使用格式为:server <name> <address>[:port] [param*] 其中,每个param参数含义如下:

       check:表示启用对此后端服务器执行健康状态检查。

       inter:设置健康状态检查的时间间隔,单位为毫秒。

       rise:设置从故障状态转换至正常状态需要成功检查的次数,例如。“rise 2”表示 2 次检查正确就认为此服务器可用。

       fall:设置后端服务器从正常状态转换为不可用状态需要检查的次数,例如,“fall 3”表示3次检查失败就认为此服务器不可用。

       weight:设置后端真实服务器的权重,默认为 1,最大值为 256。设置为 0 表示不参与负载均衡。


-------------


listen配置

stats refresh:设置haproxy监控统计页面自动刷新的时间。


stats uri:设置haproxy监控统计页面的URL路径,可随意指定。例如、指定stats uri /admin,就可以通过http://ip:port/admin查看。


stats realm:设置登录haproxy统计页面时密码框上的文本提示信息。


stats auth:设置登录haproxy统计页面的用户名和密码。用户名和密码通过冒号分割。可为监控页面设置多个用户名和密码,每行一个。


stats admin if TRUE:通过设置此选项,可以在监控页面上手工启用或禁用后端真实服务器,仅在haproxy1.4.9以后版本有效。


===========================


3、启动Haproxy

3.1、启动

执行以下命令,就可以启动Haproxy

/usr/local/haproxy/sbin/haproxy -f /usr/local/haproxy/conf/haproxy.cfg

注:如果报FD limit错误,添加ulimit -n 65536 到/etc/profile


3.2、查看监控页面

浏览器打开http://192.168.8.10:11001/admin输入前面listen部分配置的账号密码登录。

=============================


4.配置haproxy session保持(会话保持)

第一种方法:

backend app

   mode http

   option redispatch

   option abortonclose

   balance     source

   cookie      SERVERID

   option  httpchk GET /index.html

   server  app1 192.168.8.20:80 cookie server1 check

   server  app2 192.168.8.30:80 cookie server2 check


第二种方法:

backend app

   mode http

   option redispatch

   option abortonclose

   balance     source

   cookie      SESSION_COOKIE insert indirect nocache

   option  httpchk GET /index.html

   server  app1 192.168.8.20:80 cookie server1 check

   server  app2 192.168.8.30:80 cookie server2 check


相关实践学习
SLB负载均衡实践
本场景通过使用阿里云负载均衡 SLB 以及对负载均衡 SLB 后端服务器 ECS 的权重进行修改,快速解决服务器响应速度慢的问题
负载均衡入门与产品使用指南
负载均衡(Server Load Balancer)是对多台云服务器进行流量分发的负载均衡服务,可以通过流量分发扩展应用系统对外的服务能力,通过消除单点故障提升应用系统的可用性。 本课程主要介绍负载均衡的相关技术以及阿里云负载均衡产品的使用方法。
相关文章
|
7天前
|
Cloud Native Devops 持续交付
探索云原生架构:构建高效、灵活和可扩展的系统
本文将深入探讨云原生架构的核心概念、主要技术以及其带来的优势。我们将从云原生的定义开始,了解其设计理念和技术原则;接着分析容器化、微服务等关键技术在云原生中的应用;最后总结云原生架构如何助力企业实现数字化转型,提升业务敏捷性和创新能力。通过这篇文章,读者可以全面了解云原生架构的价值和应用前景。
|
7天前
|
运维 Cloud Native Devops
云原生架构的崛起与实践云原生架构是一种通过容器化、微服务和DevOps等技术手段,帮助应用系统实现敏捷部署、弹性扩展和高效运维的技术理念。本文将探讨云原生的概念、核心技术以及其在企业中的应用实践,揭示云原生如何成为现代软件开发和运营的主流方式。##
云原生架构是现代IT领域的一场革命,它依托于容器化、微服务和DevOps等核心技术,旨在解决传统架构在应对复杂业务需求时的不足。通过采用云原生方法,企业可以实现敏捷部署、弹性扩展和高效运维,从而大幅提升开发效率和系统可靠性。本文详细阐述了云原生的核心概念、主要技术和实际应用案例,并探讨了企业在实施云原生过程中的挑战与解决方案。无论是正在转型的传统企业,还是寻求创新的互联网企业,云原生都提供了一条实现高效能、高灵活性和高可靠性的技术路径。 ##
18 3
|
19天前
|
设计模式 存储 人工智能
深度解析Unity游戏开发:从零构建可扩展与可维护的游戏架构,让你的游戏项目在模块化设计、脚本对象运用及状态模式处理中焕发新生,实现高效迭代与团队协作的完美平衡之路
【9月更文挑战第1天】游戏开发中的架构设计是项目成功的关键。良好的架构能提升开发效率并确保项目的长期可维护性和可扩展性。在使用Unity引擎时,合理的架构尤为重要。本文探讨了如何在Unity中实现可扩展且易维护的游戏架构,包括模块化设计、使用脚本对象管理数据、应用设计模式(如状态模式)及采用MVC/MVVM架构模式。通过这些方法,可以显著提高开发效率和游戏质量。例如,模块化设计将游戏拆分为独立模块。
44 3
|
26天前
|
存储 API 持续交付
探索微服务架构:构建灵活、可扩展的后端系统
【8月更文挑战第25天】 本文将引导您理解微服务架构的核心概念,探讨其对现代后端系统设计的影响。我们将从基础讲起,逐步深入到微服务的高级应用,旨在启发读者思考如何利用微服务原则优化后端开发实践。
38 4
|
28天前
|
消息中间件 负载均衡 持续交付
构建可扩展的微服务架构:从设计到实现
在微服务架构的世界里,设计和实现可扩展性是至关重要的。然而,开发者往往面临着如何在系统复杂性和性能之间取得平衡的问题。本文通过深入探讨微服务架构的关键设计原则和实践,展示了如何从初期设计到最终实现,构建一个既高效又可扩展的系统架构。
|
28天前
|
存储 监控 安全
大数据架构设计原则:构建高效、可扩展与安全的数据生态系统
【8月更文挑战第23天】大数据架构设计是一个复杂而系统的工程,需要综合考虑业务需求、技术选型、安全合规等多个方面。遵循上述设计原则,可以帮助企业构建出既高效又安全的大数据生态系统,为业务创新和决策支持提供强有力的支撑。随着技术的不断发展和业务需求的不断变化,持续优化和调整大数据架构也将成为一项持续的工作。
|
29天前
|
监控 持续交付 开发者
资源紧张下的创新之道:揭秘高效可扩展架构的设计秘诀,让技术与成本达到完美平衡!
【8月更文挑战第22天】在科技行业的快节奏发展中,设计出经济高效且可扩展的架构是每位工程师面临的挑战。本文提出五大策略:精准需求分析确保目标清晰;模块化设计如微服务架构促进独立开发与扩展;选择成熟技术栈及利用云服务提升系统效能;实施自动化流程如CI/CD加速开发周期;建立全面监控体系保障系统健康。遵循设计原则如SOLID,结合这些策略,即便资源有限也能构建出高质量、灵活应变的系统。
35 0
|
20天前
|
C# 微服务 Windows
模块化革命:揭秘WPF与微服务架构的完美融合——从单一职责原则到事件聚合器模式,构建高度解耦与可扩展的应用程序
【8月更文挑战第31天】本文探讨了如何在Windows Presentation Foundation(WPF)应用中借鉴微服务架构思想,实现模块化设计。通过将WPF应用分解为独立的功能模块,并利用事件聚合器实现模块间解耦通信,可以有效提升开发效率和系统可维护性。文中还提供了具体示例代码,展示了如何使用事件聚合器进行模块间通信,以及如何利用依赖注入进一步提高模块解耦程度。此方法不仅有助于简化复杂度,还能使应用更加灵活易扩展。
41 0
|
20天前
|
Kubernetes Cloud Native 调度
云原生技术实践:构建高效、可扩展的微服务架构
本文深入探讨了云原生技术在现代软件架构中的应用,特别是如何利用这些技术构建高效、可扩展的微服务架构。文章首先介绍了云原生的基本概念和优势,然后通过一个实际案例,展示了如何使用Kubernetes和Docker等工具来部署和管理微服务。最后,文章还讨论了云原生技术面临的挑战和未来的发展趋势。 【8月更文挑战第31天】

热门文章

最新文章