环境说明:Vmware11+Centos6.6
A | 172.16.44.10 | Haproxy |
B | 172.16.44.2 | Httpd |
C | 172.16.44.3 | Httpd |
一、HAProxy简介
HAProxy提供高可用性、负载均衡以及基于TCP和HTTP应用的代理,支持虚拟主机,它是免费、快速并且可靠的一种解决方案。HAProxy特别适用于那些负载特大的web站点,这些站点通常又需要会话保持或七层处理。HAProxy运行在时下的硬件上,完全可以支持数以万计的并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中, 同时可以保护你的web服务器不被暴露到网络上。
HAProxy实现了一种事件驱动、单一进程模型,此模型支持非常大的并发连接数。多进程或多线程模型受内存限制 、系统调度器限制以及无处不在的锁限制,很少能处理数千并发连接。事件驱动模型因为在有更好的资源和时间管理的用户端(User-Space) 实现所有这些任务,所以没有这些问题。此模型的弊端是,在多核系统上,这些程序通常扩展性较差。这就是为什么他们必须进行优化以 使每个CPU时间片(Cycle)做更多的工作。
二、安装说明
在A主机上安装haproxy
#yum install –y haproxy
在B、C主机上分别安装httpd、为各主机添加访问页面、并启动httpd服务
B主机
#yum install –y httpd
#vim /var/www/html/index.html
<h1>web1</h1>
#service httpd start
C主机
#yum install –y httpd
#vim /var/www/html/index.html
<h1>web2</h1>
#service httpd start
三、haproxy配置文件的相关说明
在Centos6.4以后的版本可以直接使用yum命令安装,生成的相关文件如下
配置文件:/etc/haprox/haproxy.cfg
服务脚本:/etc/rc.d/init.d/haproxy
主程序:/usr/sbin/haproxy
状态目录:/var/lib/haproxy
haproxy配置组成部分(全局配置和代理配置)
全局配置:global
代理配置:defaults、frontend、backend、listen
1.启动日志功能
在haproxy全局配置中有日志功能,但此功能是未开启的。
编辑/etc/rsyslog.conf开启此功能,开启udp的514端口,并添加日志保存位置。
#vim/etc/rsyslog.conf
重启日志服务
#service rsyslog restart
2.将B主机和C主机添加到A主机中,实现反向代理
#vim/etc/haproxy
重启haproxy服务,使用浏览器访问http://172.16.44.10
#service haproxyrestart
配置项说明:
frontend:段用于定义一系列监听的套接字,这些套接字可接受客户端请求并与之建立连接。
backend:段用于定义一系列“后端”服务器,代理将会将对应客户端的请求转发至这些服务器。
balance:定义负载均衡算法
server: 为后端声明一个server
check:健康状态检测
3.开启状态页功能
通过状态页,可以查看相关状态信息。为了提高安全性能,可以使用其它listen端口进行。
#vim/etc/haproxy
配置说明:
bind:绑定监听端口
stats enable:启用状态页
stats uri:状态页访问路径
stats auth:状态页基于认证进行访问
stats realm:状态页显示的标题
stats hide-version:隐藏版本信息
stats admin if TRUE:以admin用户登录后才能显示其它关键信息
重启haproxy服务,浏览器访问http://172.16.44.10:9090/haproxyadmin?stats
1.balance负载均衡的的算法,balance各算法的说明如下
roundrobin:基于权重进行轮叫,在服务器的处理时间保持均匀分布时,这是最平衡、最公平的算法。此算法是动态的,这表示其权重可以在运行时进行调整,不过,在设计上,每个后端服务器仅能最多接受4128个连接;
static-rr:基于权重进行轮叫,与roundrobin类似,但是为静态方法,在运行时调整其服务器权重不会生效;不过,其在后端服务器连接数上没有限制;
leastconn:新的连接请求被派发至具有最少连接数目的后端服务器;在有着较长时间会话的场景中推荐使用此算法,如LDAP、SQL等,其并不太适用于较短会话的应用层协议,如HTTP;此算法是动态的,可以在运行时调整其权重;
source:将请求的源地址进行hash运算,并由后端服务器的权重总数相除后派发至某匹配的服务器;这可以使得同一个客户端IP的请求始终被派发至某特定的服务器;不过,当服务器权重总数发生变化时,如某服务器宕机或添加了新的服务器,许多客户端的请求可能会被派发至与此前请求不同的服务器;常用于负载均衡无cookie功能的基于TCP的协议;其默认为静态,不过也可以使用hash-type修改此特性;
uri:对URI的左半部分(“问题”标记之前的部分)或整个URI进行hash运算,并由服务器的总权重相除后派发至某匹配的服务器;这可以使得对同一个URI的请求总是被派发至某特定的服务器,除非服务器的权重总数发生了变化;此算法常用于代理缓存或反病毒代理以提高缓存的命中率;需要注意的是,此算法仅应用于HTTP后端服务器场景;其默认为静态算法,不过也可以使用hash-type修改此特性;
url_param:通过<argument>为URL指定的参数在每个HTTP GET请求中将会被检索;如果找到了指定的参数且其通过等于号“=”被赋予了一个值,那么此值将被执行hash运算并被服务器的总权重相除后派发至某匹配的服务器;此算法可以通过追踪请求中的用户标识进而确保同一个用户ID的请求将被送往同一个特定的服务器,除非服务器的总权重发生了变化;如果某请求中没有出现指定的参数或其没有有效值,则使用轮叫算法对相应请求进行调度;此算法默认为静态的,不过其也可以使用hash-type修改此特性;
hdr(<name>):对于每个HTTP请求,通过<name>指定的HTTP首部将会被检索;如果相应的首部没有出现或其没有有效值,则使用轮叫算法对相应请求进行调度;其有一个可选选项“use_domain_only”,可在指定检索类似Host类的首部时仅计算域名部分(比如通过www.magedu.com来说,仅计算magedu字符串的hash值)以降低hash算法的运算量;此算法默认为静态的,不过其也可以使用hash-type修改此特性;
2.bind:此指令仅能用于frontend和listen区段,用于定义一个或几个监听的套接字。
3.mode: 设定实例的运行模式或协议。当实现内容交换时,前端和后端必须工作于同一种模式(一般说来都是HTTP模式),否则将无法启动实例。
4.hash-type: 定义用于将hash码映射至后端服务器的方法;其不能用于frontend区段;可用方法有map-based和consistent,在大多数场景下推荐使用默认的map-based方法。
map-based:hash表是一个包含了所有在线服务器的静态数组。其hash值将会非常平滑,会将权重考虑在列,但其为静态方法,对在线服务器的权重进行调整将不会生效,这意味着其不支持慢速启动。此外,挑选服务器是根据其在数组中的位置进行的,因此,当一台服务器宕机或添加了一台新的服务器时,大多数连接将会被重新派发至一个与此前不同的服务器上,对于缓存服务器的工作场景来说,此方法不甚适用。
consistent:hash表是一个由各服务器填充而成的树状结构;基于hash键在hash树中查找相应的服务器时,最近的服务器将被选中。此方法是动态的,支持在运行时修改服务器权重,因此兼容慢速启动的特性。添加一个新的服务器时,仅会对一小部分请求产生影响,因此,尤其适用于后端服务器为cache的场景。不过,此算法不甚平滑,派发至各服务器的请求未必能达到理想的均衡效果,因此,可能需要不时的调整服务器的权重以获得更好的均衡性。
本文对haproxy进行了基本的基础的讲解。
转载于:https://blog.51cto.com/xwywmz/1659367