基于Haproxy+Keepalived负载均衡高可用架构实现

1.项目介绍:

前面我们实现了keepalived主从高可用集群网站架构,随着公司业务的发展,公司负载均衡服务已经实现四层负载均衡,但业务的复杂程度提升,公司要求把mobile手机站点作为单独的服务提供,不在和pc站点一起提供服务,此时需要做7层规则负载均衡,运维总监要求,能否用一种服务同既能实现七层负载均衡,又能实现四层负载均衡,并且性能高效,配置管理容易,而且还是开源。

四层和七层负载均衡的区别:

四层:

通过分析IP层及TCP/UDP层的流量实现的基于"IP+端口"的负载均衡。

七层:

可以根据内容,再配合负载均衡算法来选择后端服务器,不但可以根据"ip+端口"方式进行负载分流,还可以根据网站的URL,访问域名,浏览器类别,语言等决定负载均衡的策略。

七层负载均衡模式下,负载均衡与客户端及后端的服务器会分别建立一次TCP连接,而在四层负载均衡模式下(DR),仅建立一次TCP连接;七层负载均衡对负载均衡设备的要求更高,处理能力也低于四层负载均衡。

场景说明

在企业生产环境中,每天会有很多的需求变更,比如增加服务器、新业务上线、url路由修改、域名配置等等,对于前端负载均衡设备来说,容易维护,复杂度低,是首选指标。在企业中,稳定压倒一切,与其搞得很复杂,经常出问题,不如做的简单和稳定。

在企业中,90%以上的故障,来源于需求变更。可能是程序bug,也可能是人为故障,也可能是架构设计问题等等。

前端负载均衡设备为重中之重,在软件选型上一定充分考虑,能满足业务的前提下,尽可能降低复杂度,提高易维护性。

 

2.模块讲解:

Haproxy是什么

HAProxy是一个使用C语言编写的自由及开放源代码软件,其提供高性能性、负载均衡,以及基于TCP和HTTP的应用程序代理。相较与 Nginx,HAProxy 更专注与反向代理,因此它可以支持更多的选项,更精细的控制,更多的健康状态检测机制和负载均衡算法。

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

包括 GitHub、Bitbucket、Stack Overflow、Reddit、Tumblr、Twitter在内众多知名网站,及亚马逊网络服务系统都使用了HAProxy。

Haproxy的特性

1、可靠性与稳定性都非常出色,可与硬件级设备媲美。

2、支持连接拒绝,可以用于防止DDoS攻击

3、支持长连接、短连接和日志功能,可根据需要灵活配置

4、路由HTTP请求到后端服务器,基于cookie作会话绑定;同时支持通过获取指定

的url来检测后端服务器的状态

5、HAProxy还拥有功能强大的ACL支持,可灵活配置路由功能,实现动静分离,

在架构设计与实现上带来很大方便

6、可支持四层和七层负载均衡,几乎能为所有常见的服务提供负载均衡功能

7、拥有功能强大的后端服务器的状态监控web页面,可以实时了解设备的运行状态,还可实现设备上下线等简单操作。

8、支持多种负载均衡调度算法,并且也支持session保持

 

3.实战演练

实验:实现基于Haproxy+Keepalived负载均衡高可用架构

基于Haproxy+Keepalived负载均衡高可用架构实现

一、环境准备:

CentOS系统服务器4台、两台用于做haproxy主从架构,两台作为后端server,服务器配置好

yum源、防火墙关闭、各节点时钟服务同步、各节点之间可以通过主机名互相通信

 

机器名称

IP配置

服务角色

备注

haproxy-server-master

VIP:172.17.253.100

DIP:172.17.253.132

负载均衡器

开启路由功能

配置keepalived

haproxy-server-master

VIP:172.17.253.100

DIP:172.17.252.162

负载均衡器

开启路由功能

配置keepalived

rs1

RIP:172.17.251.236

后端服务器

网关指向DIP(桥接)

rs2

RIP:172.17.251.237

后端服务器

网关指向DIP(桥接)

 

二、安装步骤:

1、iptables -F && setenforing 清空防火墙策略,关闭selinux

2、拿两台服务器都使用yum方式安装haproxy、keepalived服务

3、后端服务器配置好基于LNMP架构的web服务

三、修改配置文件:

1.修改/etc/keepalived/keepalived.conf配置文件内容

在haproxy-server-master上

vim /etc/keepalived/keepalived.conf

global_defs {

notification_email {

root@localhost

}

notification_email_from [email protected]

smtp_server 127.0.0.1

smtp_connect_timeout 30

router_id keepalived_lvs

}

vrrp_instance VI_1 {

state MASTER

interface ens33

virtual_router_id 55

priority 100

advert_int 1

authentication {

auth_type PASS

auth_pass mingming

}

virtual_ipaddress {

172.17.253.100

}

}

 

在haproxy-server-backup上

global_defs {

notification_email {

root@localhost

}

notification_email_from [email protected]

smtp_server 127.0.0.1

smtp_connect_timeout 30

router_id keepalived_lvs

}

vrrp_instance VI_1 {

state BACKUP

interface eth1

virtual_router_id 55

priority 98

advert_int 1

authentication {

auth_type PASS

auth_pass mingming

}

virtual_ipaddress {

172.17.253.100

}

}

 

2.修改主haproxy配置文件主要是listen,frontend和backend段

在haproxy-server-master上

vim /etc/haproxy/haproxy.cfg

listsen段

listen stats

bind 0.0.0.0:1080

stats enable

stats uri /haproxyadmin

stats auth admin:admin

stats admin if TRUE

frontend段

frontend web

bind *:80

default_backend lnmp-server

backend段

backend lnmp-server

balance roundrobin

option httpchk GET /index.html

server webserver1 172.17.251.236:80 check inter 3000 rise 3 fall 5

server webserver1 172.17.251.237:80 check inter 3000 rise 3 fall 5

在haproxy-server-backup上和在haproxy-server-master上haproxy配置文件的配置是一样的

然后在haproxy-server-master上和在haproxy-server-backup上都开启keepalived和haproxy服务,会发现vip漂移到haproxy-server-backup上(因为haproxy-server-master上keepalived的配置文件中优先级高),而且haproxy-server-master和haproxy-server-backup上haproxy服务都监听了1080端口和80端口

基于Haproxy+Keepalived负载均衡高可用架构实现

 

四,检验高可用效果

1.客户端先访问一下vip,成功访问小米网站

基于Haproxy+Keepalived负载均衡高可用架构实现

2.在haproxy-server-master上停掉keepalived服务,会发现vip漂移到haproxy-server-backup上,客户端依旧能够访问vip,访问小米网站,实现了高可用

3.关闭后端一台服务器的web服务,观察haproxy健康状态监测

 

4.企业级应用

Haproxy访问控制ACL应用

haproxy的ACL用于实现基于请求报文的首部、响应报文的内容或其它的环境状态信息来做出转发决策,这大大增强了其配置弹性。其配置法则通常分为两步,首先去定义ACL,即定义一个测试条件,而后在条件得到满足时执行某特定的动作,如阻止请求或转发至某特定的后端。

定义ACL的语法格式如下:

acl <aclname> <criterion> [flags] [operator] <value> ...

<aclname>:ACL名称,区分字符大小写,且其只能包含大小写字母、数字、-(连接线)、_(下划线)、.(点号)和:(冒号);haproxy中,acl可以重名,这可以把多个测试条件定义为一个共同的acl;

<criterion>:测试标准,即对什么信息发起测试;测试方式可以由[flags]指定的标志进行调整;而有些测试标准也可以需要为其在<value>之前指定一个操作符[operator];

[flags]:常见haproxy的acl支持的标志位有3个:

-i:不区分<value>中模式字符的大小写;

-f:从指定的文件中加载模式;

--:标志符的强制结束标记,在模式中的字符串像标记符时使用;

<value>:acl测试条件常见的值有以下四类:

整数或整数范围:如1024:65535表示从1024至65535;仅支持使用正整数(如果出现类似小数的标识,其为通常为版本测试),且支持使用的操作符有5个,分别为eq、ge、gt、le和lt;

字符串:支持使用"-i"以忽略字符大小写,支持使用"\"进行转义;如果在模式首部出现了-i,可以在其之前使用"--"标志位;

正则表达式:其机制类同字符串匹配;

IP地址及网络地址

同一个acl中可以指定多个测试条件,这些测试条件需要由逻辑操作符指定其关系。条件间的组合测试关系有三种:"与"(默认即为与操作)、"或"(使用"||"操作符)以及"非"(使用"!"操作符)。

基于Haproxy+Keepalived负载均衡高可用架构实现

 

Haproxy进行安全加固

通过ACL限制用户请求速率

be_sess_rate(backend) <integer>

be_sess_rate 测试标准

用于测试指定的backend上会话创建的速率(即每秒创建的会话数)是否满足指定的条件;常用于在指定backend上的会话速率过高时将用户请求转发至另外的backend,或用于阻止攻击行为。例如:

backend dynamic

mode http

acl being_scanned be_sess_rate gt 100

redirect location /denied.html if being_scanned

 

通过ACL指定可访问的用户(定义到frontend段中)

阻断非指定请求

在传输层获取样本,通常是TCP/IP 协议的IP和端口,以及建立连接速率等等。而且此部分样本通常用于

"tcp-request connection"指令中的规则之中。

 

dst : ip #目标地址

dst_port : integer

src : ip #源地址

src_port : integer

 

#阻断来自非指定IP的访问80端口的请求

acl myhost src 172.16.100.1

acl myport dst_port 80

tcp-request connection reject if !myhost myport

#还可以用block

block if ! myhost myport

 

Haproxy实现动静分离功能(在frontend段中定义)

根据用户访问内容实现动静分离

path_beg <string>

用于测试请求的URL是否以<string>指定的模式开头。下面的例子用于测试URL是否以/static、

/images、/javascript或/stylesheets头。

acl url_static path_beg -i /static /images /javascript /stylesheets

 

path_end <string>

用于测试请求的URL是否以<string>指定的模式结尾。例如,下面的例子用户测试URL是否以jpg、gif、png、css或js结尾。

acl url_static path_end -i .jpg .gif .png .css .js

 

根据用户访问内容实现动静分离配置实例

frontend http-in

bind *:80

log global

option httpclose

acl url_static path_beg -i /static /images /javascript /stylesheets

acl url_static path_end -i .jpg .jpeg .gif .png .css .js

use_backend static_servers if url_static

default_backend dynamic_servers

 

backend static_servers

balance roundrobin

server imgsrv1 172.16.200.7:80 check maxconn 6000

server imgsrv2 172.16.200.8:80 check maxconn 6000

backend dynamic_servers

balance source

server websrv1 172.16.200.7:80 check maxconn 1000

server websrv2 172.16.200.8:80 check maxconn 1000

 

Haproxy实现浏览器控制(在frontend段中定义)

hdr_reg <string>正则匹配请求内容,匹配后可做对应的操作

#阻断火狐浏览器发送的请求

acl firefox hdr_reg(User-Agent) -i .*firefox.*

block if firefox

#将IE用户请求分配到静态服务器

acl ie_useragent hdr_reg(User-Agent) -i .*ie.*

use_backend static_servers if ie_useragent

 

Haproxy实现真实日志记录

option forwardfor

option forwardfor [ except <network> ] [ header <name> ] [ if-none ]

允许在发往服务器的请求首部中插入"X-Forwarded-For"首部。

<network>:可选参数,当指定时,源地址为匹配至此网络中的请求都禁用此功能。

<name>:可选参数,可使用一个自定义的首部,如"X-Client"来替代"X-Forwarded-For"。有些独特的web服务

器的确需要用于一个独特的首部。

if-none:仅在此首部不存在时才将其添加至请求报文问道中。

HAProxy工作于反向代理模式,其发往服务器的请求中的客户端IP均为HAProxy主机的地址而非真正客户端的地址,这会使得服务器端的日志信息记录不了真正的请求来源,"X-Forwarded-For"首部则可用于解决此问题。HAProxy可以向每个发往服务器的请求上添加此首部,并以客户端IP为其value。

需要注意的是,HAProxy工作于隧道模式,其仅检查每一个连接的第一个请求,因此,仅第一个请求报文被附加此首部。

下面是一个例子。

frontend www

mode http

option forwardfor except 127.0.0.1

在haproxy的配置文件中默认就有此选项

基于Haproxy+Keepalived负载均衡高可用架构实现

在nginx的主配置文件中也默认有此选项

基于Haproxy+Keepalived负载均衡高可用架构实现

 

Haproxy实现会话保持

一、源地址hash(用户IP识别)

Haroxy 将用户IP经过hash计算后 指定到固定的真实服务器上(类似于nginx 的IP hash 指令)。

缺点:当后端一台服务器挂了以后会造成部分session丢失

示例:

backend SOURCE_srv

mode http

balance source

server app-node1 10.31.1.179:80 check port 80 inter 3000 rise 3 fall 3

server app-node2 10.31.1.191:80 check port 80 inter 3000 rise 3 fall 3

server app-node3 10.31.0.35:80 check port 80 inter 3000 rise 3 fall 3

二、cookie 识别

haproxy 将WEB服务端返回给客户端的cookie中插入haproxy中特定的字符串(或添加前缀)在后端的服

务器COOKIE ID。

backend COOKIE_srv

mode http

cookie SERVERID insert indirect nocache

server app-node1 10.31.1.179:80 check port 80 cookie a inter 3000 rise 3 fall 3

server app-node2 10.31.1.191:80 check port 80 cookie b inter 3000 rise 3 fall 3

server app-node3 10.31.0.251:80 check port 80 cookie c inter 3000 rise 3 fall 3

在LB1上配置好HAProxy后,LB1将接受用户的所有请求。如果一个用户请求不包含任何cookie,那这个请求将被HAProxy转发到一台可用的WEB服务器。可能是webA,webB,webC。然后HAProxy将把处理这个请求的WEB服务器的cookie值插入到请求响应中。如SERVERID=A。当这个客户端再次访问并在HTTP请求头中带有SERVERID=A,HAProxy将会把它的请求直接转发给webA处理。在请求到达webA之前,cookie将被移除,webA将不会看到这个cookie。如果webA不可用,对应的请求将被转发到其他可用的WEB服务器,相应的cookie值也将被重新设置。

Haproxy性能优化参数

option redispatch:当server对应的服务器挂掉后,强制定向到其他健康的服务器

option dontlognull :保证HAProxy不记录上级负载均衡发送过来的用于检测状态没有数据的心跳包。

retries 3 : //3次连接失败就认为服务器不可用,主要通过后面的check检查

maxconn 30000 : //代理时所能接受的最大并发连接数,应该要比后端主机的并发总和要小

好了,今天的内容就到这里,下期再见。

HAproxy 的详细介绍:请点这里
HAproxy 的下载地址:请点这里

相关推荐