负载均衡之haproxy-----haproxy负载均衡+pcs高可用+fence
Posted S4061222
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了负载均衡之haproxy-----haproxy负载均衡+pcs高可用+fence相关的知识,希望对你有一定的参考价值。
目录
前言
负载均衡(Load Balance):
lvs
是工作在四层、仅负责分发请求作用的负载均衡,负载均衡性能最强。Lvs实现负载均衡可结合keepalived进行后端健康检测。
nginx
工作在7层,针对http应用做一些策略配置,可以检测后端端口故障,最大的优点是并发量高,且支持二次开发,商用价值高。
haproxy
是工作在4/7层,提供高可用性和负载均衡。本文将通过配置haproxy的负载均衡、结合pacemaker实现haproxy双机热备、fence介绍haproxy。haproxy具有健康检测
7层负载平衡是更复杂的负载均衡网络流量的方法是使用第7层(应用层)负载均衡。使用第7层允许负载均衡器根据用户请求的内容将请求转发到不同的后端服务器。这种负载平衡模式允许您在同一域和端口下运行多个Web应用程序服务器。
一、haproxy负载均衡
HAProxy提供高可用性、负载均衡以及基于TCP和HTTP应用的代理,支持虚拟主机,它是免费、快速并且可靠的一种解决方案。HAProxy特别适用于那些负载特大的web站点,这些站点通常又需要会话保持或七层处理。
实验环境:
server1为haproxy主机, server2和server3为haproxy后端负载均衡主机
实验步骤:
server1安装 haproxy
[root@server1 ~]# yum install haproxy -y
编写配置文件vim /etc/haproxy/haproxy.cfg
gloabal是全局,defaluts是4/7层,使用7层,defaluts会覆盖global
# 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
# turn on stats unix socket
stats socket /var/lib/haproxy/stats
#---------------------------------------------------------------------
# common defaults that all the 'listen' and 'backend' sections will
# use if not designated in their block
#---------------------------------------------------------------------
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 3000
stats uri /status #haproxy 监控页面
#---------------------------------------------------------------------
# main frontend which proxys to the backends
#---------------------------------------------------------------------
frontend main *:80
#acl url_static path_beg -i /static /images /javascript /stylesheets
#acl url_static path_end -i .jpg .gif .png .css .js
#iuse_backend static if url_static
default_backend app
#---------------------------------------------------------------------
# static backend for serving up images, stylesheets and such
#---------------------------------------------------------------------
#backend static
# balance roundrobin
# server static 127.0.0.1:4331 check
#---------------------------------------------------------------------
# round robin balancing between the various backends
#---------------------------------------------------------------------
backend app
balance roundrobin
server app1 172.25.28.2:80 check
server app2 172.25.28.3:80 check
sysctl -a #查看所有的可配置内核参数,
sysctl可以设置查看的内核参数都在目录/proc/sys
中
free -m #查看系统内存使用情况(宿主机)
Mem:表示物理内存,Swap:表示硬盘交换分区
编写 /etc/security/limits.conf
配置文件,修改限制文件打开数为4096,
最大4000,不改系统限制超出会有预警日志
启动服务,查看日志,查看haproxy服务的默认端口为80
测试:
firefox:http://172.25.28.1/status
开启两个后端服务,重新测试:
firefox:http://172.25.28.1/status
二、haproxy 配置
确保关闭 lvs,ipvsadmin - L
检查
以下设置都是修改配置文件/etc/haproxy/haproxy.cfg,并重启服务
1. 图片访问锁定
测试
firefox:http://172.25.28.1/status 网页查看后端状态, status 为监控目录
2.haproxy的八种负载均衡算法---- 之source算法
roundrobin
基于权重进行轮询,在服务器的处理时间保持均匀分布时,这是最平衡,最公平的算法.此算法是动态的,这表示其权重可以在运行时进行调整.不过在设计上,每个后端服务器仅能最多接受4128个连接
static-rr
基于权重进行轮叫,与roundrobin类似,但是为静态方法,在运行时调整其服务器权重不会生效.不过,其在后端服务器连接数上没有限制
leastconn
新的连接请求被派发至具有最少连接数目的后端服务器.在有着较长时间会话的场景中推荐使用此算法,如LDAP、SQL等;其并不太适用于较短会话的应用层协议,如HTTP.此算法是动态的,可以在运行时调整其权重
first
第一个具有可用连接槽的服务器得到连接.这些服务器将从最小到最大的id选择.一旦一个服务器到达它的最大连接数,下一个服务器将被使用.如果不定义每个服务器的maxconn参数,这个算法是无意义的.使用这个算法的目的是尽量使用最小数量的服务器以便于其他服务器可以在非密集时段待机.这个算法将忽略服务器权重
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.baidu.com来说,仅计算”baidu”字符串的hash值)以降低hash算法的运算量.此算法默认为静态的,不过其也可以使用hash-type修改此特性
系统默认的算法为roundrobin,此处修改为source算法,访问一个ip锁定一个server
当down掉某台后端的httpd服务时,后端有健康检查功能
当up掉某台后端的httpd服务时,会恢复
roundrobin基于权重进行轮询,系统默认权重为1,server2和server3两台后端都正常工作时候,会轮询,即负载均衡,修改server2的权重为2
3.备用机使用
172.25.28.1:8080端口为备机
修改172.25.28.1:8080端口为httpd服务,默认是80端口,172.25.28.1:80端口为haproxy服务使用
测试:
server2的httpd关掉
server2,3的httpd关掉,只留下备机server1
4.用户认证
5.日志配置
编写/etc/rsyslog.log
文件,重启rsyslog服务,/var/log/haproxy.log
查看产生的日志
6. 黑名单
此处的黑名单为宿主机28.250
访问后返回代码 403 Forbidden,访问被拒绝
错误重定向
若访问出现错误,则定向到访问172.25.28.1:8080端口backup主机服务上
重定向
将所有访问转到访问百度,也可后跟条件
7. 读写分离
后端server3安装php,编写php默认发布文件,重启apache服务读取php模块
修改配置文件内容:
以.php结尾的转到访问static,即server3后端
测试:
访问172.25.28.1/index.php 跳转到172.25.28.3下的index.php
后端server2安装php,重启apache服务读取php模块,测试文件包括:
index.php 和 upload_file.php
server3读,server2写(存),需要修改server2中的upload权限
上传图片,点击submit提交,server3读取
日志显示POST写入时,锁定static进行写入。进入static下的server2查看已经上传的图片在server2中。
server2读,server3写(存),需要修改server3中的upload权限
三、pacemaker实现haproxy双机热备,高可用部署
Pacemaker是一个集群资源管理器。它利用集群基础构件(OpenAIS、heartbeat或corosync)提供的消息和成员管理能力来探测并从节点或资源级别的故障中恢复,以实现群集服务(亦称资源)的最大可用性。
1. server1和server4为高可用节点
(1)server1修改软件仓库( 添加高可用软件仓库
),安装高可用插件,必须编写,否则packmaker和pcs没有包
(2)server1和server4之间节点免密设定
(3)server4也修改软件仓库,安装高可用插件
(4) server1,4的selinux和selinux,封装母景象中已经做过selinux和firewall
(5)server1,4开启pcsd服务
(6)server1,server4修改hacluster认证用户密码并用于认证,设定集群名为mycluster,包含server1 server4节点
(7) 启动所有节点,此处为server1,server4
(8)查看所有节点状态,此处为server1,server4
(9)取消警告
(9)server1,4确保都安装haproxy,启动服务,将haproxy.cfg配置文件scp给server4
测试:
添加资源
查看pcs支持的脚本和提供者
设定vip
查看vip是否设定成功,也可以在server1中ip addr查看
将server1节点暂停,停止暂停使用参数unstandby
将haproxy服务交给集群之前,需要关闭服务并且关闭开机自启disable
。将haproxy添加到resources中
将vip和haproxy放到一个组中并运用于一个节点中(解决资源不同步),hagroup为组名称,后面为资源启动顺序,添加同一个组中,方便同一管理
测试:
创建资源管理组完成后即可成功访问:
一直是server2
2.高可用测试:server1服务关闭
haproxy服务没有运行
服务自启动成功(server1一直接管资源)
若脚本无法启动才会转移集群节点到server4
3.高可用测试:server1内核崩溃
echo c > /proc/sysrq-trigger
server1下线,资源自动从server1转到server4
内核崩溃后,需要重启才能连接
资源转移server4后自动添加vip
四、配置 (stonith) fence防止文件系统脑裂
每个节点之间互相发送探测包进行判断节点的存活性。一般会有专门的线路进行探测,这条线路称为“心跳线”。假设node1的心跳线出问题,则node2认为node1出问题,然后就会把资源调度在node2上运行,node1会认为自己没问题不让node2抢占资源,此时就出现了脑裂。此时如果在整个环境里有一种设备直接把node1断电,则可以避免脑裂的发生,这种设备叫做fence或者stonith
网卡坏了,内核坏了也不可能手动去重启网卡,重启电脑。所以需要设置stonith。
- stonith相当于电源交换机,插排,可以发信息告诉stonith需要断开哪个电源(直接断电),开启哪个电源,实现了远程自动开关机。
实验环境:
真实主机安装fence(4个),server1、4 安装fence客户端: fence-virtd
真机的虚拟接口服务为libvirtd
1.配置
(一)fence_virtd -c #-c配置fence设备,需要配置br0桥接
(二)密钥文件不存在,需要手动创建,文件存放地址默认为/etc/cluster(需创建),密钥文件用来访问端口,需要拷贝到虚拟机server1,4上
重启服务可以看到1229端口
虚拟机中的fence设备是fence_xvm
(三)复制密钥文件到server1,4
(四)开始配置stonith,将fence设备添加到集群:
server1主机名:server1虚拟机名
(五)启动stonish
(六)检测认证是否有误
2.检测配置了stonith后的效果
内核崩溃
echo c > /proc/sysrq-trigger
服务会切换到另一台server上,且断电主机会强制重启,重启成功后不会回退。
模拟网卡失效
ip link set down eth0
以上是关于负载均衡之haproxy-----haproxy负载均衡+pcs高可用+fence的主要内容,如果未能解决你的问题,请参考以下文章