HAProxy（一）之常用配置介绍，ACL详解

HAProxy 是一款高性能TCP/HTTP 反向代理负载均衡服务器，具有如下功能：

HAProxy特别适用于那些负载特大的web站点，这些站点通常又需要会话保持或七层处理。HAProxy运行在时下的硬件上，完全可以支持数以万计的 并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中， 同时可以保护你的web服务器不被暴露到网络上。

HAProxy 实现了一种事件驱动、单一进程模型，此模型支持非常大的并发连接数。多进程或多线程模型受内存限制 、系统调度器限制以及无处不在的锁限制，很少能处理数千并发连接。事件驱动模型因为在有更好的资源和时间管理的用户端(User-Space) 实现所有这些任务，所以没有这些问题。此模型的弊端是，在多核系统上，这些程序通常扩展性较差。这就是为什么他们必须进行优化以 使每个CPU时间片(Cycle)做更多的工作。

HAProxy实际工作中，它占用用户空间时间要比内核运行时间少20倍，所以对系统参数调优是十分必要的一项工作。

1、session rate

2、session concurrency

3、data forwarding rate

本文环境：CentOS7, haproxy 15 通过yum 安装

harpoxy 将日志发送到指定的rsyslog服务器，在本地记录也要开启rsyslog服务；

全局端最多可配置两个log 服务器；

< address> ：日志服务器地址

[ len ] 指定记录的日志最大长度

用于对haproxy 状态监控页面的用户认证。至少要定义一个用户列表并且添加一个用户

密码可以加密或明文。

Example:

这部分配置在下列定义区域下使用

“defaults” 区域定义了frontend，backend，listen 的默认参数

“frontend" 区域描述了接收客户端请求的监听配置

"backend" 区域描述接受请求处理的后端服务器配置

"listen" 区域描述一组前端和后端直接一对一绑定的组配置

HAProxy 配置的关键字与区域限制特性，即有些关键字在某个区域不可以使用

下面开始讲解关键字的用法

仅在frontend和listen区域使用。定义服务监听端口地址等参数

[ param ] 参数根据系统而定，一般不需要指定

example：

tcp： 基于layer4实现代理，可代理大多数基于tcp的应用层协议，例如ssh/mysql/pgsql等；

http： 客户端的http请求会被深度解析；

health： 工作为健康状态检查响应模式，当请求到达时仅回应“OK”即断开连接；

在backend区域定义调度算法：

< algorithm > 如下：

Example：

指定的http首部将会被取出做hash计算。如果没有值，则降至轮询调度；

动态算法或静态算法取决于hash-type；

在balance 指令中选定与hash 有关的算法，都会受此影响。

默认采取的方法为map-based

< method > 如下：

该算法调度平滑，后端服务器能够均匀承受负载;

缺点也是明显的：当服务器的总权重发生变化时，即有服务器上线或下线，都会导致调度结果整体改变。如果想避免此种情况应采用consistent 方法；

每一个server 会在"树"中出现多次， 在树中查找hash key，并选择最近的server；

该方法的优点在于，当服务器的总权重发生变化时，对调度结果影响是局部的，不会引起大的变动。所以十分适合缓存服务器；

缺点：该算法不够平滑，很容易导致后端服务器负载不均衡。所以很有必要对服务器的权重以或者服务器ID进行调整；

为保持均匀负载，应该保证所有服务器ID保持一致；

default-server [param]

server用于在backend和listen中定义一个主机;

default-server 用于设定server的默认参数；

[param] 如下：

Examples :

基于http协议作7层健康状态检测机制，默认是基于tcp层进行检测；

TCP 模式也可以使用该检测机制

< method > < uri > < version >：请求报文的超始行；

method 默认方法为 OPTIONS；返回状态码2XX，3XX意味成功；

Examples :

定义检测有效期望值；

! 表示认定的错误值；< match > 可取值为：

Examples :

启用基于cookie的会话黏性，要结合server指定的cookie参数一起实现;

常用形式：cookie WEBSRV insert nocache indirect

Example:

当use_backend 的使用规则没有被匹配时，由default_backend 指定默认服务器组；

关于use_backend 使用后续会在acl 章节中讲解；

为 frontend 或 backend 定义日志记录机制；

< code > 指定HTTP返回的状态码。200, 400, 403, 408, 500, 502, 503, and 504 可使用；

< file > 指定一个文件代替HTTP响应；

Example：

发生错误时由haproxy重定向至指定url，以上两个命令等同，响应状态码为302

Example：

响应状态码为303，表示以GET方法重新请求页面

HAProxy把请求报文发往后端主机之前在请求报文添加“X-Forwared-For”首部

目的为使后端服务器可记录发出请求客户端的IP地址

[ except < network> ] ：选择排除的网络地址

[ header < name> ] ：不使用X-Forwared-For，自定义名称

[ if-none ]：有时请求原来带有该字段，此时不再更改

Example： option forwardfor if-none

在HTTP请求或响应首部内容尾部添加值

Example： rspadd X-Via: HAProxy/15

删除HTTP请求中正则匹配的所有首部

删除HTTP响应中正则匹配的所有首部。属于安全加强策略，删除一些服务器版本信息，防止针对攻击

Example：rspidel Server

设定客户端最大非活动时长， 默认单位是ms；最好与timeout server一致

设定服务端最大非活动时长， 默认单位是ms；

设定最大与服务端建立连接的时长

设定最大等待新请求的空闲时长，默认单位为ms；

在客户端侧设定半关闭连接非活动超时

在服务端侧设定半关闭连接非活动超时

Example：

Haproxy 能够从请求报文，响应报文，从客户端或者服务端信息，从表，环境信息等等中提取数据。提取这样的数据的动作我们称之为获取样本。进行检索时，这些样本可以用来实现各种目的，比如作为粘滞表的键，最常用的用途是，根据预定义的模式来进行匹配。

访问控制列表（ACL）提供一个灵活方案进行内容切换，或者在从请求，响应，任何环境状态中提取的数据基础之上做出决策。控制列表的原则很简单：

执行的动作通常是阻断请求，选择一个后端服务器或者添加一个HTTP首部

需要提醒的是 ，获取的样本数据不光可以使用在acl中，也可以使用别处，例如记录log中

这样一条语句建立了一个acl 测试；

这些测试应用在请求或响应中被"标准"< criterion > 部分所指定的内容，而且可以指定[ flags] 进行特性调整，有些< criterion > 支持操作符[operator] 进行运算，同时一些转换格式的关键字可以跟在< criterion >后面，使用" , "隔开。而值[< value >] 要求被

< criterion > 所支持的数据形式，多个值使用空格分隔。

< criterion > 通常是指获取样本方法的名称。使用一个获取样本方法，暗含着其输出样本的类型，类型是以下列出的一种：

ACL引擎匹配数据使用的模式类型如下：

ACL flags 可用列表如下:

如果获取样本值为整数，数值比较符可使用，：

eq : true if the tested value equals at least one value

ge : true if the tested value is greater than or equal to at least one value

gt : true if the tested value is greater than at least one value

le : true if the tested value is less than or equal to at least one value

lt : true if the tested value is less than at least one value

想必前面一堆理论性的论述已经把大家搞的晕头转向，下面结合获取样本方法和访问控制动作指令具体阐述ACL使用方法

先介绍控制动作指令

对tcp请求控制指令：

< condition > 即为ACL定义的访问控制列表

< action > 常用值有 "accept", "reject"

Example :

在传输层获取样本，通常是TCP/IP 协议的IP和端口，以及建立连接速率等等。而且此部分样本通常用于"tcp-request connection"指令中的规则之中。

Example:

/1

提取请求url的地址信息，从第一个"/"开始，不包含host，不包含参数

ACL 衍生，即包含了-m 选项中匹配模式方法 :

path : exact string match

path_beg : prefix match

path_dir : subdir match

path_dom : domain match

path_end : suffix match

path_len : length match

path_reg : regex match

path_sub : substring match

Example：

/2

提取URL的全部内容，包含host和参数

ACL 衍生类似，不再列举

/3

提取http请求的指定首部字段值，< occ >可指定出现的位置

ACL 衍生 :

Example：

/4

提取请求报文中的请求方法

Example：

HAProxy有众多内建的ACLs，这些ACLs可直接调用，例如

Example:

为了保证服务器不出现宕机，服务器主要采用了HA Cluster、UPS还有主要部件冗余三种方式。

HA(High Available), 高可用性群集，是保证业务连续性的有效解决方案，一般有两个或者两个以上的节点，节点分为活动节点和备用节点两种。活动节点就是当前正在执行的节点，备用 节点是活动节点当中的一个备份节点。服务器在运行中（活动节点）出现错误是，系统马上会启用备用节点接替当前活动节点，从而实现服务器不间断运行。

UPS是为不间断电源，其与服务器连在一起，能在服务器遭遇突然断电时继续为服务器提供电力支持，保证服务器的正常运行。

冗余是重复配置系统当中的一些部件，当服务器发生故障时，冗余部件能接替发生故障的部件继续维持服务器的正常运行。服务器主要部件冗余有：电源、存储子系统、磁盘镜像、RAID(磁盘阵列)、CPU、风扇等等。

HA高可用性群集主要应用于服务器的操作系统之中，系统出现问题是，可以让系统进行回滚，保证服务器系统的稳定性；UPS不间断电源保证了服务器电力的持续供应，服务器主要部件冗余保证服务器硬件在出现问题之后接替出现问题的部件继续工作。

服务器能长久运行的一个原因就是多方面保证，从系统到硬件都有多个预备方案，加上运维工程师的724小时不间断维护才有了服务器长期正常运行的可能。

随着网络流量的增加，服务器开始面临繁重负载，这时就需要搭配一套HTTP负载均衡系统了，那么Linux下该如何配置HTTP负载均衡系统呢？随小编一起来学习一下吧。

如今对基于互联网的应用和服务的要求越来越大，这给广大的IT管理员施加了越来越大的压力。面对突如其来的流量猛增、自生的流量增加或者是内部挑战（比如硬件故障和紧急维护），不管怎样，你的互联网应用都必须保持随时可用。连现代化的开发运营和持续交付做法也会危及互联网服务的可靠性和一贯表现。

无法预测或缺乏一贯的表现是你所无法承受的。那么，我们如何能消除这些缺点呢？在大多数情况下，一套合适的负载均衡解决方案有望满足这个要求。今天我将为各位介绍如何使用HAProxy搭建一套HTTP负载均衡系统。

HTTP负载均衡简介

HTTP负载均衡是一种网络解决方案，负责在托管相同应用内容的几台服务器之间分配进入的HTTP或HTTPS流量。由于在多台可用服务器之间均衡了应用请求，负载均衡系统就能防止任何应用服务器变成单一故障点，因而提高了整体的应用可用性和响应能力。它还让你可以随着不断变化的工作负载，轻松地缩小/扩大部署的应用系统的规模，只需添加或删除额外的应用服务器。

哪里使用负载均衡、何时使用？

由于负载均衡系统改进了服务器的利用率，最大限度地提高了可用性，只要你的服务器开始面临繁重负载，或者正为一个较庞大的项目规划架构，就应该使用它。事先规划好负载均衡系统的用途是个好习惯。那样，未来你需要扩展环境规模时，它会证明其用途。

HAProxy是什么东东？

HAProxy是一种流行的开源负载均衡和代理系统，面向GNU/Linux平台上的TCP/HTTP服务器。HAProxy采用了单一线程的事件驱动型架构而设计，它能够轻松地处理10G网卡线路速度，现广泛应用于许多生产环境中。其功能特性包括：自动检查健康状况、可定制的负载均衡算法、支持HTTPS/SSL以及会话速率限制等。

我们在本教程中要达到什么样的目的？

在本教程中，我们将逐步介绍为HTTP网站服务器配置基于HAProxy的负载均衡系统这个过程。

前提条件

你至少需要一台（最好是两台）网站服务器来证实所搭建负载均衡系统的功能。我们假设，后端HTTP网站服务器已经搭建并运行起来。

将HAProxy安装到Linux上

就大多数发行版而言，我们可以使用你所用发行版的软件包管理器来安装HAProxy。

将HAProxy安装到Debian上

在Debian中，我们需要为Wheezy添加向后移植功能。为此，请在/etc/apt/sourceslistd中创建一个名为“backportslist”的新文件，其内容如下：

deb http://cdndebiannet/debian wheezy­backports main

更新你的软件库数据，并安装HAProxy。

# apt­ get update # apt ­get install haproxy

将HAProxy安装到Ubuntu上

# apt ­get install haproxy

将HAProxy安装到CentOS和RHEL上

# yum install haproxy

配置HAProxy

在本教程中，我们假设有两台HTTP网站服务器已搭建并运行起来，其IP地址分别为1921681002和1921681003。我们还假设，负载均衡系统将在IP地址为1921681004的那台服务器处进行配置。

为了让HAProxy发挥功用，你需要更改/etc/haproxy/haproxycfg中的几个项目。这些变更在本章节中予以描述。万一某个配置对不同的GNU/Linux发行版而言有所不同，会在相应段落中加以注明。

1 配置日志功能

你首先要做的工作之一就是，为你的HAProxy建立合适的日志功能，这对将来进行调试大有用处。日志配置内容位于/etc/haproxy/haproxycfg的global部分。下面这些是针对特定发行版的指令，用于为HAProxy配置日志。

CentOS或RHEL：

要想在CentOS/RHEL上启用日志功能，把：

log 127001 local2

换成：

log 127001 local0

下一步，在/var/log中为HAProxy创建单独的日志文件。为此，我们需要改动当前的rsyslog配置。为了让配置简单而清楚，我们将在/etc/rsyslogd/中创建一个名为haproxyconf的新文件，其内容如下。

$ModLoad imudp $UDPServerRun 514 $template Haproxy，“%msg%/n” local0=info ­/var/log/haproxylog;Haproxy local0notice ­/var/log/haproxy­statuslog;Haproxy local0 ~

该配置将把基于$template的所有HAProxy消息隔离到/var/log中的日志文件。现在，重启rsyslog，让变更内容生效。

# service rsyslog restart

Debian或Ubuntu：

要想在Debian或Ubuntu上为HAProxy启用日志功能，把：

log /dev/log local0 log /dev/log local1 notice

换成：

log 127001 local0

下一步，为HAProxy配置单独的日志文件，编辑/etc/rsyslogd/中一个名为haproxyconf的文件（或者Debian中的49-haproxyconf），其内容如下。

$ModLoad imudp $UDPServerRun 514 $template Haproxy，“%msg%/n” local0=info ­/var/log/haproxylog;Haproxy local0notice ­/var/log/haproxy­statuslog;Haproxy local0 ~

该配置将把基于$template的所有HAProxy消息隔离到/var/log中的日志文件。现在，重启rsyslog，让变更内容生效。

# service rsyslog restart

2 设置默认值

下一步是为HAProxy设置默认变量。找到/etc/haproxy/haproxycfg中的defaults部分，把它换成下列配置。

log global mode http option httplog option dontlognull retries 3 option redispatch maxconn 20000 contimeout 5000 clitimeout 50000 srvtimeout 50000

上述配置推荐HTTP负载均衡器使用，但可能不是最适合你环境的解决方案。如果那样，请参阅HAProxy参考手册页，进行适当的改动和调整。

3 网站服务器集群的配置

网站服务器集群（Webfarm）的配置定义了可用的HTTP服务器集群。我们所建负载均衡系统的大部分设置都将放在这里。现在，我们将创建一些基本的配置，我们的节点将在这里加以定义。把从frontend部分到文件末尾的所有配置换成下列代码：

listen webfarm ：80 mode http stats enable stats uri /haproxy？stats stats realm Haproxy/ Statistics stats auth haproxy:stats balance roundrobin cookie LBN insert indirect nocache option httpclose option forwardfor server web01 1921681002:80 cookie node1 check server web02 1921681003:80 cookie node2 check

“listen webfarm ：80”这一行定义了我们的负载均衡系统将侦听哪些接口。出于本教程的需要，我将该值设为“”，这让负载均衡系统侦听我们的所有接口。在实际场景下，这可能不合意，应该换成可从互联网来访问的某个接口。

stats enable stats uri /haproxy？stats stats realm Haproxy/ Statistics stats auth haproxy:stats

上述设置声明，可以在http://《load-balancer-IP》/haproxy？stats处访问负载均衡系统的统计数字。这种访问由简单的HTTP验证以及登录名“haproxy”和密码“stats”来确保安全。这些设置应该换成你自己的登录信息。如果你不想让这些统计数字被人看到，那么可以完全禁用它们。

下面是HAProxy统计数字的一个例子。

“balance roundrobin”这一行定义了我们将使用哪种类型的负载均衡。在本教程中，我们将使用简单的轮叫调度算法，这对HTTP负载均衡来说完全绰绰有余。HAProxy还提供了其他类型的负载均衡：

•leastconn：连接数最少的服务器优先接收连接。

•source：对源IP地址进行哈希处理，用运行中服务器的总权重除以哈希值，即可决定哪台服务器将接收请求。

•uri：URI的左边部分（问号前面）经哈希处理，用运行中服务器的总权重除以哈希值。所得结果决定哪台服务器将接收请求。

•url_param：变量中指定的URL参数将在每个HTTP GET请求的查询串中进行查询。你基本上可以将使用蓄意制作的URL（crafted URL）的请求锁定于特定的负载均衡节点。

•hdr（name）：HTTP头《name》 将在每个HTTP请求中进行查询，被定向到特定节点。

“cookie LBN insert indirect nocache”这一行让我们的负载均衡系统存储持久性cookie，这让我们得以准确查明集群中的哪个节点用于某一个会话。这些节点cookie将与指定的名称一并存储起来。在我们这个例子中，我使用了“LBN”，但你可以指定自己喜欢的任意名称。节点将为该cookie把字符串作为一个值而存储起来。

server web01 1921681002:80 cookie node1 check server web02 1921681003:80 cookie node2 check

上述部分对网站服务器节点集群进行了定义。每台服务器都用内部名称（比如web01和web02）、IP地址和独特的cookie串来表示。cookie串可以定义为你需要的任何名称。我使用了简单的node1、node2 。。。 node（n）。

启动HAProxy

你完成了配置工作后，可以启动HAProxy，验证一切按预期运行。

在Centos/RHEL上启动HAProxy

使用下列指令，让HAProxy能够在系统启动后启动，并打开它：

# chkconfig haproxy on # service haproxy start

当然，别忘了启用防火墙中的端口80，如下所示。

CentOS/RHEL 7上的防火墙：

# firewall­cmd ­­permanent ­­zone=public ­­add­port=80/tcp # firewall­cmd ­­reload

CentOS/RHEL 6上的防火墙：

把下面这一行添加到/etc/sysconfig/iptables中的这部分“：OUTPUT ACCEPT”：

A INPUT ­m state ­­state NEW ­m tcp ­p tcp ­­dport 80 ­j ACCEPT

然后重启iptables：

# service iptables restart

在Debian上启动HAProxy

使用下列指令启动HAProxy：

# service haproxy start

别忘了启用防火墙中的端口80，为此把下面这一行添加到/etc/iptablesuprules：

A INPUT ­p tcp ­­dport 80 ­j ACCEPT

在Ubuntu上启动HAProxy

让HAProxy能够在系统启动后启动，只要在/etc/default/haproxy中将“ENABLED”选项设为“1”：

ENABLED=1

启动HAProxy：

# service haproxy start

然后启用防火墙中的端口80：

# ufw allow 80

测试HAProxy

为了检查HAproxy是否在正常工作，我们可以执行下列步骤：

首先，用下列内容准备好testphp文件：

《？php header（‘Content-Type： text/plain’）; echo “Server IP： ”。

该PHP文件将告诉我们哪台服务器（即负载均衡系统）转发请求，哪台后端网站服务器实际处理请求。

把该PHP文件放到这两台后端网站服务器的根目录下。现在，使用curl命令，从负载均衡系统（1921681004）提取这个PHP文件。

# chkconfig haproxy on # service haproxy start nbsp;curl http://1921681004/testphp

我们多次运行这个命令时，应该会看到下面两个输出交替出现（由于轮叫调度算法）。

Server IP： 1921681002

X-Forwarded-for： 1921681004

Server IP： 1921681003

X-Forwarded-for： 1921681004

如果我们停止这两台后端网站服务器中的其中一台，curl命令应该仍会执行，将请求定向到另一台可用的网站服务器。

结束语

至此，你应该有了一套完全实用的负载均衡系统，能够在轮叫循环模式下为你的网站节点提供请求。与往常一样，你可以随意更改配置，让它更适合自己的基础设施。希望本教程帮助你让自己的网站项目具有更强的抗压力和更高的可用性。

正如大家已经注意到的那样，本教程所含的设置适用于仅仅一套负载均衡系统。这意味着，我们把一个单一故障点换成了另一个单一故障点。在实际场景下，你应该部署至少两套或三套负载均衡系统，以防范可能出现的任何故障，但这不在本教程的讨论范围之内。

上面就是Linux系统下配置HTTP负载均衡系统的方法介绍了，这里主要使用的是HAProxy，且只介绍了配置一套负载均衡系统的方法，赶紧试试看吧。

1检查NAT前VRRP的那个虚拟网关和构成虚拟网关的实际网关是否都没有问题？

2ping B服务器有时候通有时候不通的现象是否有规律？能否总结一下这个规律？一般如果是规律性的，考虑一下路由、ARP之类的配置。

3HA配置是否正确，HA有两种方式，但无论哪种方式对于IP网络配置都是有一定的要求的。这些要求是否达到！

4NAT的实施方式是怎么样的？是否有有策略的约束？