HAProxy原理和基本概念（基础）
HAProxy原理和基本概念（基础）
-
- 一、负载均衡简介
-
- 1.1：为什么使用负载均衡：
- 1.2：负载均衡类型：
- 二、HAProxy简介
- 三、配置HAProxy
-
- 3.1：配置文件格式
- 3.2：配置案例：http服务器配置示例
- 3.3：global配置参数：
- 3.4：Proxies代理配置段：
- 四、HAProxy调度算法
-
- 4.1 roundrobin：
- 4.2 leastconn：
- 4.3 source：
- 4.4 uri：
- 4.5 url_param：
- 4.6 hdr：
- 4.7 rdp-cookie
- 五、实践：ACL示例-基于ACL的HTTP访问控制
- 六、引用
一、负载均衡简介
负载均衡(Load Balance，简称LB)是一种服务或基于硬件设备等实现的高可用反向代理技术，负载均衡将特定的业务(web服务、网络流量等)分担给指定的一个或多个后端特定的服务器或设备，从而提高了公司业务的并发处理能力、保证了业务的高可用性、方便了业务后期的水平动态扩展。
https://yq.aliyun.com/articles/1803 #阿里云SLB介绍
1.1：为什么使用负载均衡：
Web服务器的动态水平扩展–>对用户无感知
增加业务并发访问及处理能力–>解决单服务器瓶颈问题
节约公网IP地址–>降低IT支出成本
隐藏内部服务器IP–>提高内部服务器安全性
配置简单–>固定格式的配置文件
功能丰富–>支持四层和七层，支持动态下线主机
性能较强–>并发数万甚至数十万
1.2：负载均衡类型：
四层：
LVS(Linux Virtual Server)
HAProxy(High Availability Proxy)
Nginx(1.9)
七层：
HAProxy
Nginx
硬件：
F5 #https://f5.com/zh
Netscaler #https://www.citrix.com.cn/products/citrix-adc/
Array #https://www.arraynetworks.com.cn/
深信服 #http://www.sangfor.com.cn/
北京灵州 #http://www.lingzhou.com.cn/cpzx/llfzjh/
二、HAProxy简介
HAProxy提供高可用性、负载均衡以及基于TCP和HTTP应用的代理，支持虚拟主机，它是免费、快速并且可靠的一种解决方案。HAProxy特别适用于那些负载特大的web站点，这些站点通常又需要会话保持或七层处理。HAProxy运行在时下的硬件上，完全可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中， 同时可以保护你的web服务器不被暴露到网络上。
HAProxy实现了一种事件驱动、单一进程模型，此模型支持非常大的并发连接数。多进程或多线程模型受内存限制 、系统调度器限制以及无处不在的锁限制，很少能处理数千并发连接。事件驱动模型因为在有更好的资源和时间管理的用户端(User-Space) 实现所有这些任务，所以没有这些问题。此模型的弊端是，在多核系统上，这些程序通常扩展性较差。这就是为什么他们必须进行优化以 使每个CPU时间片(Cycle)做更多的工作。
————百度百科
三、配置HAProxy
3.1：配置文件格式
HAProxy的配置处理3类来主要参数来源：
——最优先处理的命令行参数，
——“global”配置段，用于设定全局配置参数；
——proxy相关配置段，如“defaults”、“listen”、“frontend”和“backend”；
3.2：配置案例：http服务器配置示例
# http服务器配置示例
#---------------------------------------------------------------------
# Global settings
#---------------------------------------------------------------------
global
# to have these messages end up in /var/log/haproxy.log you will
# need to:
#
# 1) configure syslog to accept network log events. This is done
# by adding the '-r' option to the SYSLOGD_OPTIONS in
# /etc/sysconfig/syslog
#
# 2) configure local2 events to go to the /var/log/haproxy.log
# file. A line like the following can be added to
# /etc/sysconfig/syslog
#
# local2.* /var/log/haproxy.log
#
log 127.0.0.1 local2
chroot /var/lib/haproxy
pidfile /var/run/haproxy.pid
maxconn 4000
user haproxy
group haproxy
daemon
defaults
mode http
log global
option httplog
option dontlognull
option http-server-close
option forwardfor except 127.0.0.0/8
option redispatch
retries 3
timeout http-request 10s
timeout queue 1m
timeout connect 10s
timeout client 1m
timeout server 1m
timeout http-keep-alive 10s
timeout check 10s
maxconn 30000
listen stats
mode http
bind 0.0.0.0:1080
stats enable
stats hide-version
stats uri /haproxyadmin?stats
stats realm Haproxy\ Statistics
stats auth admin:admin
stats admin if TRUE
frontend http-in
bind *:80
mode http
log global
option httpclose
option logasap
option dontlognull
capture request header Host len 20
capture request header Referer len 60
default_backend servers
frontend healthcheck
bind :1099
mode http
option httpclose
option forwardfor
default_backend servers
backend servers
balance roundrobin
server websrv1 192.168.10.11:80 check maxconn 2000
server websrv2 192.168.10.12:80 check maxconn 2000
3.3：global配置参数：
官方文档：global配置参数
chroot #锁定运行目录
deamon #以守护进程运行
#stats socket /var/lib/haproxy/haproxy.sock mode 600 level admin #socket文件
user, group, uid, gid #运行haproxy的用户身份
nbproc #开启的haproxy进程数，与CPU保持一致
nbthread #指定每个haproxy进程开启的线程数，默认为每个进程一个线程
cpu-map 1 0 #绑定haproxy 进程至指定CPU
maxconn #每个haproxy进程的最大并发连接数
maxsslconn #每个haproxy进程ssl最大连接数,用于haproxy配置了证书的场景下
maxconnrate #每个进程每秒创建的最大连接数量
spread-checks #后端server状态check随机提前或延迟百分比时间，建议2-5(20%-50%)之间
pidfile #指定pid文件路径
log 127.0.0.1 local3 info #定义全局的syslog服务器；最多可以定义两个
3.4：Proxies代理配置段：
defaults [<name>] #默认配置项，针对以下的frontend、backend和lsiten生效，可以多个name也可以没有name
frontend <name> #前端servername，类似于Nginx的一个虚拟主机 server。
backend <name> #后端服务器组，等于nginx的upstream
listen <name> #将frontend和backend合并在一起配置
•注：name字段只能使用”-”、”_”、”.”、和”:”，并且严格区分大小写。
四、HAProxy调度算法
定义负载均衡算法，可用于“defaults”、“listen”和“backend”。用于在负载均衡场景中挑选一个server，其仅应用于持久信息不可用的条件下或需要将一个连接重新派发至另一个服务器时。支持的算法有：
4.1 roundrobin：
roundrobin：基于权重进行轮叫，在服务器的处理时间保持均匀分布时，这是最平衡、最公平的算法。此算法是动态的，这表示其权重可以在运行时进行调整，不过，在设计上，每个后端服务器仅能最多接受4128个连接；
static-rr：基于权重进行轮叫，与roundrobin类似，但是为静态方法，在运行时调整其服务器权重不会生效；不过，其在后端服务器连接数上没有限制；
4.2 leastconn：
leastconn：新的连接请求被派发至具有最少连接数目的后端服务器；在有着较长时间会话的场景中推荐使用此算法，如LDAP、SQL等，其并不太适用于较短会话的应用层协议，如HTTP；此算法是动态的，可以在运行时调整其权重；
4.3 source：
source：将请求的源地址进行hash运算，并由后端服务器的权重总数相除后派发至某匹配的服务器；这可以使得同一个客户端IP的请求始终被派发至某特定的服务器；不过，当服务器权重总数发生变化时，如某服务器宕机或添加了新的服务器，许多客户端的请求可能会被派发至与此前请求不同的服务器；常用于负载均衡无cookie功能的基于TCP的协议；其默认为静态，不过也可以使用hash-type修改此特性；
4.4 uri：
uri：对URI的左半部分(“问题”标记之前的部分)或整个URI进行hash运算，并由服务器的总权重相除后派发至某匹配的服务器；这可以使得对同一个URI的请求总是被派发至某特定的服务器，除非服务器的权重总数发生了变化；此算法常用于代理缓存或反病毒代理以提高缓存的命中率；需要注意的是，此算法仅应用于HTTP后端服务器场景；其默认为静态算法，不过也可以使用hash-type修改此特性；
4.5 url_param：
url_param：通过为URL指定的参数在每个HTTP GET请求中将会被检索；如果找到了指定的参数且其通过等于号“=”被赋予了一个值，那么此值将被执行hash运算并被服务器的总权重相除后派发至某匹配的服务器；此算法可以通过追踪请求中的用户标识进而确保同一个用户ID的请求将被送往同一个特定的服务器，除非服务器的总权重发生了变化；如果某请求中没有出现指定的参数或其没有有效值，则使用轮叫算法对相应请求进行调度；此算法默认为静态的，不过其也可以使用hash-type修改此特性；
4.6 hdr：
hdr()：对于每个HTTP请求，通过指定的HTTP首部将会被检索；如果相应的首部没有出现或其没有有效值，则使用轮叫算法对相应请求进行调度；其有一个可选选项“use_domain_only”，可在指定检索类似Host类的首部时仅计算域名部分(比如通过www.magedu.com来说，仅计算magedu字符串的hash值)以降低hash算法的运算量；此算法默认为静态的，不过其也可以使用hash-type修改此特性；
4.7 rdp-cookie
rdp-cookie：对远windows程桌面的负载，使用cookie保持会话
五、实践：ACL示例-基于ACL的HTTP访问控制
listen web_host
bind 192.168.7.101:80
mode http
balance roundrobin
log global
option httplog
acl static_path path_beg -i /static /images /javascript
use_backend static_path_host if static_path
acl badguy_deny src 192.168.7.102
http-request deny if badguy_deny
http-request allow
default_backend default_web
backend static_path_host
mode http
server web1 192.168.7.104 check inter 2000 fall 3 rise 5
backend default_web
mode http
server web1 192.168.7.102:80 check inter 2000 fall 3 rise 5
测试：
[root@server2 ~]# curl --head http://192.168.7.101/static/1.jpg
HTTP/1.1 403 Forbidden
Content-length: 93
Cache-Control: no-cache
Connection: close
Content-Type: text/html
六、引用
Kaushal V, Bala A G. Autonomic Fault Tolerance Using HAProxy in Cloud Enviorment[D]. , 2011.