haproxy 基本搭建 + 高可用集群的搭建_rpm build 编译haproxy

1.首先对haproxy的源码包进行编译,获得haproxy的方式有多种：直接下在rpm,官网的源码包
  在本次的实验中使用的是haproxy-1.6.11.tar.gz 
haproxy被内置到红帽中 在本次的源中查看haproxy的版本

使用rpmbuild -tb 源码包 用来构建haproxy的rpm包 便于安装就不用编译,创建连接了
[root@server1 ~]# rpmbuild -tb haproxy-1.6.11.tar.gz 
[root@server1 ~]# cd rpmbuild/
[root@server1 rpmbuild]# ls
BUILD  BUILDROOT  RPMS  SOURCES  SPECS  SRPMS
[root@server1 rpmbuild]# cd RPMS/
[root@server1 RPMS]# ls
x86_64
[root@server1 RPMS]# cd x86_64/
[root@server1 x86_64]# ls
haproxy-1.6.11-1.x86_64.rpm
[root@server1 x86_64]# 
得到了haproxy-1.6.11-1.x86_64.rpm 直接进行安装,环境不用进行重新的连接
[root@server1 x86_64]# rpm -ivh haproxy-1.6.11-1.x86_64.rpm 
Preparing...                                           ########################################### [100%]
   1:haproxy                                           ########################################### [100%]
rpm安装完成后的环境中并没有脚本,启动的脚,配置文件等
[root@server1 ~]# cd /etc/haproxy/
[root@server1 haproxy]# ls
[root@server1 haproxy]# ls
[root@server1 haproxy]# 
需要将源码的包解压进行配置
[root@server1 ~]# tar zxf haproxy-1.6.11.tar.gz 
[root@server1 examples]# pwd 
/root/haproxy-1.6.11/examples
[root@server1 examples]# cp content-sw-sample.cfg /etc/haproxy/
这个content-sw-sample.cfg就是haproxy的主配置文件 为了方便可以将文件名更名
[root@server1 haproxy]# mv content-sw-sample.cfg haproxy.cfg
下来我们对配置文件进行详细的了解
 
配置文件中全局的变量中 使用haproxy用户对haproxy服务进行调动,
但在启动服务的时候系统并没有直接的创建这样的一个用户为使用
在进行下一步的配置首先为进程创建一个用户,在配置中默认的uid=200 如下图所示

[root@server1 haproxy]# groupadd -g 200 haproxy
[root@server1 haproxy]# useradd -g 200 -u 200 haproxy 
 
等同于nginx 我们改变haproxy所接收处理的最大的连接数
 1.查看内核是否支持指定的数 2.修改配置参数的最大数目 3.系统识别最大的文件连接数
[root@server1 haproxy]# vim /etc/security/limits.conf 
haproxy         -       nofile          10000
修改配置文件中的参数
更改配置文件 了解配置文件中的参数的意义[root@server1 ~]# vim /etc/haproxy/haproxy.cfg
用于设置全局配置参数global
log       127.0.0.1 local2  全局的日志的配置,指定使用 127.0.0.1 上的syslog 服务中的local2 日志设备,记录等级为info 的日志
 
chroot	/var/lib/haproxy	chroot 运行路径pidfile	/var/run/haproxy.pid	进行 pid 用于
存放 pid
maxconn	4000	默认最大连接数user	haproxy		启动程序所用用户group	haproxy		启动程序所用组Daemon	以后台的形式运行 haproxy
 
# turn on stats unix socket
stats socket /var/lib/haproxy/stats
默认全局配置，这些参数会被利用 frontend ,backend ,listen 组件中
defaults
mode	http	所处理的类别（7 层http, 4 层代理tcp)
log	global	应用全局的日志配
置
option	httplog	启用日志记录
HTTP 请求，默认 haproxy 日志记录是不记录 HTTP 请求日志option	dontlognull	启用该项，日
 
志中将不会记录空连接。所谓空连接就是在上游的负载均衡器或者监控系统为了探测该 服务是否存活可用时，需要定期的连接或者获取某一固定的组件或页面，或者探测扫描端口是否在监听或开放等动作被称为空连接；
 
option http-server-close	每次请求完毕后主动关闭http 通道
option forwardfor	except 127.0.0.0/8
如果服务器上的应用程序想记录发起请求的客户端的 IP 地址，需要在 HAProxy 上 配置此选项， 这样 HAProxy 会把客户端的IP 信息发送给服务器，在HTTP 请求中添加
"X-Forwarded-For"字段。 启用	X-Forwarded-For，在requests 头部插入客户端 IP 发送给后端的server，使后端server 获取到客户端的真实IP。
option	redispatch	serverID 对应的服务挂掉以后,强制定向到其他的健康的服务
retries	3	3 次连接失败就认为服务不可用
timeout http-request	10s
timeout queue	1m	一个请求在队列里的超时时间
timeout connect	10s	设置默认的连接超时的
时间
timeout client	1m	设置客户端连接超时的
时间
timeout server	1m	设置服务器连接超时的
时间
timeout http-keep-alive 10s	设置 http-keep-alive
 
的超时时间
timeout	check	10s	检测超时
maxconn		3000	
backend	static		
balance	roundrobin	使用的算法为轮询
server	static 127.0.0.1:4331 check	健康检查backend app
balance		roundrobin	轮询的算法server	app1 127.0.0.1:5001 check server	app2 127.0.0.1:5002 check server	app3 127.0.0.1:5003 check server	app4 127.0.0.1:5004 check
<3>基于负载均衡的 haproxy 中配置文件的改写[root@server1 ~]# vim /etc/haproxy/haproxy.cfg 以上的设置默认不改变 将舰艇端口修改为 80 frontend	main *:80
default_backend	my_webserver
backend static	静态文件部署在本机（也可以部署在其他机器或者squid 缓存服务器）
balance	roundrobin
server	static 127.0.0.1:80 check
backend my_webserver	定义一个名为my_webserver 后端部分。PS：此处 my_webserver 只是一个自定义名字而已，但是需要与 frontend 里面配置项 default_backend 值相一致
balance	roundrobin	算法
server	web1 172.25.254.2:80 check inter 2000 fall 3
weight 30
server	web2 172.25.254.3:80 check inter 2000 fall 3
 
weight 30

配置完成后启动服务
[root@server1 ~]# /etc/init.d/haproxy start 
Starting haproxy:                                    [  OK  ]
在物理机上进行测试负载均衡的页面 页面如下图所示
 

以下的情况表示后台的服务器不可用
开启RS的http服务重新进行测试

在以上的设置中 haproxy只是最基本的负载均衡 将客户的请求的分发给真正的服务器,
服务器处理请求完成以后将数据返回给客户,
cookie的参数决定了,在测试时不会出现轮询,在cookie中会保持长连接,除非当前的RS挂掉以后
会寻找存活的RS进行下次的数据处理
   server          dynsrv1 172.25.254.2:80 minconn 50 maxconn 500 cookie s1 check inter 1000
 
minconn 50 最小连接 maxconn 500 最大连接 cookie s1 保持长链接
check inter 1000 健康检查 自动的对后端的服务进行检查,在调度时不会对挂掉的服务进行受理
在参数中去掉 cookie就可以正常的看到轮询的页面 
        server          dynsrv1 172.25.254.2:80  check inter 1000
        server          dynsrv2 172.25.254.3:80  check inter 1000
对haproxy进行重启 [root@server1 haproxy]# /etc/init.d/haproxy restart 
在物理机上对轮询的页面测试如下图   
页面不能轮询 ： 1.参数中有没有关闭 cookie 设置轮询的算法 2.后台的RS是否在线 

http://172.25.254.1/admin/stats 查看负载的web界面 在配置的参数中这个位置是可以改变的

down 掉RS后 在web界面上 server2 会变颜色
具有健康检查 在server2在线以后 会自动加入负载中

查看返回的状态码  参数设置         monitor-uri     /monitoruri

haproxy 的8种负载均衡算法 ：
    1.balance roundrobin  #轮询 软负载均衡基本都具备这种算法
    2.balance static-rr   #根据权重,建议使用
    3.balance leastconn   #最少连接者先处理,建议使用
    4.balance sourc       #根据请求源IP,建议使用
    5.balance uri         #根据请求的URI
    6.balance url_param   #根据请求的URI参数 
    7.balance hdr(name)   #根据请求的HTTP请求头来锁定每次的HTTP请求
    8.balance rdp-cookie(name) #根据cookie(name)来锁定并哈希每一次TCP请求

根据请求的源IP 来进行测试 balance source'
[root@server1 haproxy]# /etc/init.d/haproxy reload
测试结果如下  根据请求的源IP进行锁定  持续一个连接不变 

将负载均衡的日志添加到系统中
[root@server1 haproxy]# vim /etc/rsyslog.conf 
$ModLoad imudp
$UDPServerRun 514
local0.*                   /var/log/haproxy.log
*.info;mail.none;authpriv.none;cron.none;local0.none                /var/log/messages
[root@server1 haproxy]# /etc/init.d/rsyslog restart
 
修改haproxy中的轮询的算法 对haproxy进行重读 查看haproxy的日志记录的文件

在haproxy中设置允许拒绝的客户请求
frontend public
        bind            172.25.254.1:80 name clear
        acl blacklist src 172.25.254.151
        http-request deny if blacklist
[root@server1 haproxy]# /etc/init.d/haproxy reload
在物理机上进行测试 会收到拒绝的页面如下

在Haproxy收到拒绝的请求以后 可以将拒绝的请求定向到一个正在维护的页面上去
 
haproxy 的端口是 80 因此在负载上进行定向的时候 可以将http的端口修改为8080
[root@server1 haproxy]# vim /etc/httpd/conf/httpd.conf 
Listen 8080
[root@server1 haproxy]# cat /var/www/html/index.html 
<h1>网站正在维护中...</h1>
[root@server1 haproxy]# /etc/init.d/httpd restart
[root@server1 haproxy]# vim haproxy.cfg 
frontend public
        bind            172.25.254.1:80 name clear
 
        acl blacklist src 172.25.254.151
 
        http-request deny if blacklist
        errorloc 403 http://172.25.254.1:8080
 
[root@server1 haproxy]# /etc/init.d/haproxy reload
在物理机上进行测试 重定向的页面 如下图 使用命令进行测试发现永久重定向
[root@loaclhost ~]# curl -I 172.25.254.1
HTTP/1.1 302 Found
Cache-Control: no-cache
Content-length: 0
Location: http://172.25.254.1:8080

采用另一种策率进行重定向
frontend public
        bind            172.25.254.1:80 name clear
 
        acl blacklist src 172.25.254.151
 
        redirect location http://172.25.254.1:8080
[root@server1 haproxy]# /etc/init.d/haproxy reload
在页面上进行测试  如下图

访问的是 blacklist  使用直接连接的方式重定向到 某一固定的页面
frontend public
        bind            172.25.254.1:80 name clear
 
        acl blacklist src 172.25.254.151
 
        redirect location http://172.25.254.1:8080 if blacklist
[root@server1 haproxy]# /etc/init.d/haproxy reload
在物理机上进行命令的询问 依旧会出现重定向的方式
[root@loaclhost ~]# curl -I 172.25.254.1
HTTP/1.1 302 Found
Cache-Control: no-cache
Content-length: 0
Location: http://172.25.254.1:8080
Connection: close

动静分离的访问 修改haproxy的参数 
按照客户的需求,将不同的RS具有的页面调度给客户,
        default_backend static
 
backend dynamic
        balance         roundrobin
        #balance                source
        #cookie          DYNSRV insert indirect nocache
        #fullconn        4000 # the servers will be used at full load above this number of connections
#172.25.254.2上面是动态页面的访问
        server          dynsrv1 172.25.254.2:80  check inter 1000
backend static
        balance         roundrobin
#172.25.254.3上面是静态页面的访问
        server          dynsrv2 172.25.254.3:80  check inter 1000
因此在server2上进行动态页面的搭建
[root@server2 ~]# yum install -y php
[root@server2 html]# vim index.php
<?php
    phpinfo();
?>
[root@server2 html]# /etc/init.d/httpd restart
[root@server1 haproxy]# vim haproxy.cfg
           use_backend     dynamic if { path_end -i .php }
[root@server1 haproxy]# /etc/init.d/haproxy reload
在物理机的web上进行访问 是否可以动静分离的请求到想要请求的页面
将上一步做访问的重定向 注释掉 让物理机可以访问到做动静分离的页面
以.php 结尾的动态页面的访问 会直接调度到动态状态下的动态RS server2进行受理
当没有结尾时  默认的处理规则以静态页面为首下的server3 以静态页面进行处理 访问普通的html页面

对haproxy的参数进行修改 对后台的服务器可写
frontend public
        bind            172.25.254.1:80 name clear
 
#       acl blacklist src 172.25.254.151
        acl write method POST
        acl write method PUT
       use_backend     dynamic if write
[root@server1 haproxy]# /etc/init.d/haproxy reload
[root@server2 html]# ls
index.html  index.php
[root@server2 html]# rm -rf * 
[root@server2 html]# ls
upload
[root@server2 html]# cd upload/
[root@server2 upload]# ls
index.php  upload_file.php
[root@server2 upload]# mv * ..
[root@server2 html]# chmod 777 upload
[root@server2 html]# ls
index.php  upload  upload_file.php
[root@server2 html]# vim upload_file.php 
[root@server2 html]# scp -r * server3:/var/www/html/
[root@server3 ~]# yum install -y php
[root@server3 html]# /etc/init.d/httpd restart 
在物理机上进行测试访问 172.25.254.1/upload_file.php

Haproxy的高可用套件的搭建  pacemaker+ corosync + haproxy

[root@server1 haproxy]# yum install -y pacemaker corosync
[root@server4 ~]# yum install -y pacemaker corosync 
[root@server1 haproxy]# cd /etc/corosync/
[root@server1 corosync]# cp corosync.conf.example corosync.conf
[root@server1 corosync]# vim corosync.conf
此处我只列出修改的参数,没有特别的说明,参数不必修改
                bindnetaddr: 172.25.254.0
service {
        name: pacemaker
        ver:0
}
[root@server1 corosync]# scp corosync.conf server4:/etc/corosync/
[root@server1 corosync]# /etc/init.d/corosync start
[root@server4 ~]# /etc/init.d/corosync start
pacemaker的交互并没有向ricci的套件那样的web界面,在进行交互的时候要安装交互式的软件crmsh 才能对集群进行控制
[root@server1 corosync]# yum provides */crmsh
Loaded plugins: product-id, subscription-manager
This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.
No Matches found
crmsh的交互软件并没有被内置到红帽中 因此要在官网上下载
crmsh-1.2.6-0.rc2.2.1.x86_64.rpm 这个包具有依赖性 找到pssh的相同版本的包进行安装
pssh-2.3.1-2.1.x86_64.rpm
先安装pssh 再安装crmsh 否则会有依赖性
[root@server1 ~]# rpm -q crmsh 
crmsh-1.2.6-0.rc2.2.1.x86_64
直接使用crm 命令进入到交互式的页面 无须启动服务
[root@server1 ~]# crm
crm(live)# 

出现了一个小问题  再我进入crm 查看的时候不听的出现以下的错误 
再网上寻求无果 
[root@server1 ~]# crm 
crm(live)# configure 
ERROR: running cibadmin -Ql: Could not establish cib_rw connection: Connection refused (111)
Signon to CIB failed: Transport endpoint is not connected
Init failed, could not perform requested operations
解决： 打开了pacemaker 的服务接口就可以进行正常使用了

正常的进入到交互的界面
[root@server1 ~]# crm 
crm(live)# configure 
crm(live)configure# show 
node server1
node server4
property $id="cib-bootstrap-options" \
	dc-version="1.1.10-14.el6-368c726" \
	cluster-infrastructure="cman"
crm(live)configure# 
在 crmsh的界面中可以使用tab键进行补齐 不用完全的记住其中命令的全称
crm(live)configure# property stonith-enabled=false 关闭fence的接口
crmsh在进行交互的时候记得要提交
crm(live)configure# commit
#########################
测试的时候发现没有问题
[root@server1 ~]# crm_verify -LV
[root@server1 ~]# 
########################
使用show查看的时候规则就添加进去了
crm(live)configure# show 
node server1
node server4
property $id="cib-bootstrap-options" \
	dc-version="1.1.10-14.el6-368c726" \
	cluster-infrastructure="cman" \
	stonith-enabled="false"
#########################
在规则中添加VIP集群的统一调度接口
crm(live)configure# primitive vip ocf:heartbeat:IPaddr2 params ip=172.25.254.100 cidr_netmask=32 op monitor interval=1min 
crm(live)configure# commit 
在server4中使用crm_mon进行对集群的监控 如图

对集群的节点进行测试 将server1上的资源转移到server4上去
有意的使server1集群的节点进行毁坏,将资源转移到server4上,集群的搭建就成功了
[root@server1 ~]# crm node standby
在后端的监测 就会发现server1上的资源转移到server4上面去了 如下图所示

 

在server1上可以使得另一个节点在线
[root@server1 corosync]# crm node online
 
注意：当另一个节点在线的时候,节点间不要回切,避免 因资源的接管而导致资源的丢失

测试：当其中的一个节点 /etc/init.d/corosync stop 
由于corosync 默认器用stonith功能但是没有stonith的设备 如果直接配资源的化 没有这个功能 资源的切换 并不会完成 
所以要禁止stonith功能 设置no-quorum-policy 为ignore 就可以解决 当其中的一个节点down 掉以后 
集群还可以正常的工作 对集群含有健康检查 节点数小与2 就认为无法组成集群 集群也就无法工作
 
crm(live)configure# property no-quorum-policy=ignore
crm(live)configure# commit

haproxy的高可用  将原来的haproxy的配置文件 还原到原来的静态页面的轮询的界面
把server1上的haproxy的rpm包利用scp传到server4上
[root@server1 x86_64]# pwd 
/root/rpmbuild/RPMS/x86_64
[root@server1 x86_64]# scp * server4:/root/
[root@server1 haproxy]# scp haproxy.cfg server4:/etc/haproxy/
启动haproxy的服务,相应的也可以将日志配置到本地系统中,便于查看和管理
回到含有crmshell的节点上对haproxy的资源进行配置 我们首先查看应有的配置如图

添加haproxy的资源到pacemaker中去
crm(live)configure# primitive haproxy lsb:haproxy op monitor interval=30s 
crm(live)configure# commit 
添加资源组
crm(live)configure# group hagroup vip haproxy
crm(live)configure# commit 
尝试让其中的一台节点down 集群的高可用就会将该节点上的业务转移到正常节点上去
在crm中的resource中可以查看到当前的资源的资源组的状态
crm(live)resource# show 
 Resource Group: hagroup
     vip	(ocf::heartbeat:IPaddr2):	Started 
     haproxy	(lsb:haproxy):	Started 

集群中的fence的搭建

首先我们在server4上查询相关的fence-virt的配置
[root@server4 haproxy]# rpm -q fence-virt
fence-virt-0.2.3-15.el6.x86_64
[root@server1 haproxy]# rpm -q fence-virt
fence-virt-0.2.3-15.el6.x86_64
查看相关的配置
[root@server4 haproxy]# stonith_admin -M -a fence_xvm
在物理机上打开支配fence的服务
[root@loaclhost kiosk]# systemctl start fence_virtd
在/etc/fence_virt.conf查看fence的主配置文件
使用桥接,确保虚拟机桥接到物理机真实的网卡上 使用命令 btctl show 
其次要注意在节点上的fence的密钥,如果没有密钥无法支配虚拟机进行重启
下来进入到节点的crmshell模式,对集群的资源进行fence的配置
[root@server1 ~]# crm 
crm(live)# 
crm(live)configure# 
crm(live)configure# primitive vmfence stonith:fence_xvm params pcmk_host_map="server1:server1;server4:server4" op monitor interval=1min
server1:server1  虚拟主机名称（在创建的时候虚拟机的名称：主机名）
开启fence的功能
crm(live)configure# property stonith-enabled=true
crm(live)configure# commit 
开启之后可以在另外的节点上进行crm_mon的监控 如图

也就是说在进行fence的调用的时候,corosync调用fence对在线的节点进行监控,
当节点不堪重负,或者人为宕机,启动fence功能,将节点重启,节点上的资源转移到在线的节点上
 
为什么要创建资源组对节点进行管理？
在创建的资源组中,会由很多的资源
 Resource Group: hagroup
     vip        (ocf::heartbeat:IPaddr2):	Started server4
     haproxy    (lsb:haproxy):  Started server4
vmfence (stonith:fence_xvm):    Started server4
随着节点的转移而集体的迁移,当然可以创建很多的资源组对不同的vip进行管控,
在一个组中的vip,haproxy,vmfece相当于配套的组件,成对的使用,在不同的组中可以分别相应客户的不同请求
haproxy的高可用就到此结束了,但是其中的原理和一个参数的常用的理解需要下来慢慢的融汇贯通,
 
总结：
这篇博客主要就是haproxy 以及corosync+ pacemaker + haproxy的高可用
haproxy：实现了利用源码包创建rpm ->安装,寻找haproxy的主配置文件->配置文件中的参数的功能：
    1.创建haproxy的用户去调动这个进程
    2.haproxy 自带cookie chek健康检查 要实现轮询的算法,对cookie进行注释
    3.实现对访问控制的重定向,以及重定向页面的处理 
    4.将haproxy的日志加入到系统的日志中去,在配置文件中查看日志的位置,及日志的类型
    在/etc/rsyslog.conf中加入local0的类型,并将其加入到/var/log/messages中全局日志,haproxy.none
    5.实现页面访问的动静分离,在以path_end -i .php 区别动态页面和静态页面 在底下分别对不同的页面调度到不同的RS上
    6.实现读写分离,在默认的写和读可以在两台机器上实现
corosync + pacemaker + haproxy 高可用：
    pacemaker是资源管理器,对集群进行管理和监测的,但其本身并不具备心跳的功能,
现在corosync集成了心跳和集群的组件,对集群间的心跳有测试,具备平滑的切换,利用组资源,将套件快速整合切换,
    但是corosync的组件,本身并不具备web的页面,在进行交互的时候,要使用crmshell的插件对集群进行配置,具体的crm具有依赖性,pssh的安装,注意版本
    1.在crm中crm(live)#并不能进行配置 首先进入configure界面 进行show 就可以看见其中的参数
    2.创建统一的接口VIP的搭建,
    3.因为pacemaker的集群中少于2个节点,就认为集群是坏的,因此必须要让集群忽视这个功能
    4.haproxy的集群高可用,将haproxy加入集群中带入
    5.将VIP和haproxy绑定在同一个资源组,当节点转移的时候,所有的资源都会转移,
    6.fence的加入,使得集群中的单点可调节,根据状态变化,进行重启