目录：
介绍
在前面和本片文章都有介绍：lvs、haproxy、nginx。
基于软件的负载均衡：软件有lvs、haproxy、nginx。
lvs是工作在四层、仅负责分发请求作用的负载均衡，负载均衡性能最强。Lvs实现负载均衡可结合keepalived进行后端健康检测。
nginx工作在7层，针对http应用做一些策略配置，可以检测后端端口故障，最大的优点是并发量高，且支持二次开发，商用价值高。
haproxy是工作在4/7层，提供高可用性和负载均衡。支持虚拟主机，它是免费、快速并且可靠的一种解决方案。HAProxy运行在时下的硬件上，完全可以支持数以万计的 并发连接。并且它的运行模式使得它可以很简单安全的整合进您当前的架构中， 同时可以保护你的web服务器不被暴露到网络上。
一.haproxy负载均衡
实验环境：
我们需要做的准备工作为：（ip自己随意使用自己）
server1 172.25.1.1 作为haproxy服务器及集群管理服务器
server2 172.25.1.2 负载均衡（后端服务器）
server3 172.25.1.3 负载均衡（后端服务器）
server4 172.25.1.4 集群管理服务器
安装配置haproxy
[root@server1 ~]# yum install haproxy -y
配置vim /etc/haproxy/haproxy.cfg
只需要修改其中的一部分，自行参考：有的需要注释掉！
stats uri /status
frontend main *:80
# acl url_static path_beg -i /static /images /javascript /stylesheets
# acl url_static path_end -i .jpg .gif .png .css .js
#
# use_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
#---------------------------------------------------------------------
backend app
balance roundrobin
server app1 172.25.1.2:80 check
server app2 172.25.1.3:80 check
vim /etc/security/limits.conf
配置完成之后开启服务并查看服务状态
80端口开启了服务
[root@server1 ~]# systemctl start haproxy.service
[root@server1 ~]# netstat -antlp
当然需要在server2,server3上开启httpd服务
之后，就可以在网页进行测试：
172.25.1.1/status
HAProxy的日志管理
编辑文件：加入haproxy的日志信息！
取消注释udp的两行！
[root@server1 ~]# vim /etc/rsyslog.conf
取消注释
最后添加
local2.* /var/log/haproxy.log
[root@server1 ~]# systemctl restart rsyslog.service
当重启服务或者有操作的时候，错误日志文件才会出现不然不会出现
之后我们在重启haproxy出现问题，失败的时候，就可以查看日志报错修复
vim /var/log/haproxy.log
status添加用户认证
若是在配置文件中添加用户认证 登陆需要用户和密码：
vim /etc/haproxy/haproxy.cfg
stats uri /status
status auth admin:westos
重启服务：
systemctl reload haproxy.service
然后访问网页：
如果访问的是 172.25.1.1不断刷新，就会出现负载均衡
刚才的配置文件中最下面添加的app下面的参数 roundrobin：
roundrobin算法（根据服务器权重轮询的算法，可以自定义权重，它支持慢启动，并能在运行时修改权重，所以是一种动态算法。
在客户端上进行负载均衡测试：
for i in {1…10}; do curl 172.25.1.1 ;done
结果如下：
权重
若是在后面加上权重：
因为默认的权重是1，若是后面协会写2已经是权重变大了！
如下如：
这样再负载均衡的时候，server2的次数会是server3的两倍！
source 调度算法（对请求的源IP地址进行hash处理，根据hash运算处理结果调度至后端服务器。可使固定IP的请求始终调度至统一服务器。）
这样会把IP锁定在一个地址：
当关闭某server3服务器的http服务时如下：说明其具有对后端服务器健康检查的功能
图片访问锁定
写入图片的格式：
static地址改为172.25.1.3:80 check
我们需要在server3上建立目录放入图片
cd /var/www/html
mkdir images/
put vim，jpd
放入什么图片都可以，只要格式符合即可！！！
我放入两张：
访问网页：172.25.1.1/images/vim.jpg
再次访问172.25.1.1/images/iso7.gif
访问黑名单
acl blacklist src 172.25.1.250/24
block if blacklist
再次访问，发现拒绝访问：403
错误403：重定向
若是不想出现访问失败的界面，而是想让客户访问另外一个网页需要重定向！
需要把错误403定向到一个网页 ：
配置如下：
再次访问网页172。25。1。1
跳转到了百度
重定向
将前面的错误403重定向注释掉
redirect location http://www,taobao.com
二.结合PHP
在server3上安装php
yum install -y php
修改php默认发布页面
cd /var/www/html
vim index.hrml
<?php
phpinfo()
?>
systemctl restart httpd
接着修改haproxy中的配置文件
vim /etc/haproxy/haproxy.cfg
以.php结尾的转到访问static
这时候，再次访问172.25.1.1/index.php 跳转到了 172.25.1.3/index.php
三.HAProxy的读写分离
vim /etc/haproxy/haproxy.cfg
acl write method POST
acl write method PUT
use_backend_static if write
当然需要在配置文件最后面修改static的地址：
server2和server3同样操作
[root@server2 html]# yum install php -y
[root@server3 html]# yum install php -y
变为完后发给server3：
scp index.php server3:/var/www/html/
[root@serve2 html]# vim index.php
<html>
<body>
<form action="upload_file.php" method="post"
enctype="multipart/form-data">
<label for="file">Filename:</label>
<input type="file" name="file" id="file" />
<br />
<input type="submit" name="submit" value="Submit" />
</form>
</body>
</html>
[root@server2 html]# vim upload_file.php
[root@server2 html]# mkdir upload
[root@server2 html]# chmod 777 upload
编辑后，把目录和文件发给server3上：
scp -r upload upload_file.php server3:/var/www/html/
<?php
if ((($_FILES["file"]["type"] == "image/gif")
|| ($_FILES["file"]["type"] == "image/jpeg")
|| ($_FILES["file"]["type"] == "image/pjpeg"))
&& ($_FILES["file"]["size"] < 2000000))
{
if ($_FILES["file"]["error"] > 0)
{
echo "Return Code: " . $_FILES["file"]["error"] . "<br />";
}
else
{
echo "Upload: " . $_FILES["file"]["name"] . "<br />";
echo "Type: " . $_FILES["file"]["type"] . "<br />";
echo "Size: " . ($_FILES["file"]["size"] / 1024) . " Kb<br />";
echo "Temp file: " . $_FILES["file"]["tmp_name"] . "<br />";
if (file_exists("upload/" . $_FILES["file"]["name"]))
{
echo $_FILES["file"]["name"] . " already exists. ";
}
else
{
move_uploaded_file($_FILES["file"]["tmp_name"],
"upload/" . $_FILES["file"]["name"]);
echo "Stored in: " . "upload/" . $_FILES["file"]["name"];
}
}
}
else
{
echo "Invalid file";
}
?>
修改完之后，重启httpd服务
测试： 读得时候，访问的是server2的php
点击choose file选择一张图片
因为刚才的php代码里面写了图片的格式可以为下面三种，找到符合的图片，或者修改代码为你的图片格式都可以！！
if ((($_FILES["file"]["type"] == "image/gif")
|| ($_FILES["file"]["type"] == "image/jpeg")
|| ($_FILES["file"]["type"] == "image/pjpeg"))
然后submit提交
可以发现提交的图片出现在server3刚才建立的uoload目录上，而server2上没有：
四.pacemaker+haproxy双机热备
corosync是集群框架引擎程序，pacemaker是高可用集群资源管理器
准备server4机子：
下载及配置，修改软件仓库，安装高可用插件
vim /etc/yum.repos.d/dvd.repo
cat /etc/yum.repos.d/dvd.repo
因为虚拟机使用的是redhat 7.6的镜像，所以镜像下本来就有高可用的包！
server1,server4都需要配置：
[dvd]
name=dvd
baseurl=http://172.25.1.254/rhel7.6
gpgcheck=0
[HighAvailability]
name=dvd HighAvailability
baseurl=http://172.25.1.254/rhel7.6/addons/HighAvailability
gpgcheck=0
在server1,server4都需要下载！！
[root@server4 ~]# yum install haproxy.x86_64
[root@server4 ~]# ssh-keygen
[root@server4 ~]# ssh-copy-id server1
[root@server4 ~]# yum install -y pacemaker pcs psmisc policycoreutils-python
[root@server4 ~]# ssh server1 yum install -y pacemaker pcs psmisc policycoreutils-python
[root@server4 yum.repos.d]# systemctl enable --now pcsd.service
[root@server4 yum.repos.d]# ssh server1 systemctl enable --now pcsd.service
把server1上前面修改的配置文件发给server4
[root@server1 haproxy]# scp /etc/haproxy/haproxy.cfg server4:/etc/haproxy/
给用户密码
[root@server4 ~]# passwd hacluster #westos
[root@server4 ~]# ssh server1 passwd hacluster
## 给用户密码##
接下来进行集群的认证：
[root@server4 ~]# pcs cluster auth server1 server4
[root@server4 ~]# pcs cluster setup --name mycluster server
##在同一个节点上使用pcs集群设置来生成和同步crosync配置##
开启集群服务，开启开机自动启动：
[root@server4 ~]# pcs cluster start --all
##启动集群##
[root@server4 ~]# pcs cluster enable --all
##开机自启动##
搞定之后，查看一下配置如下：
pcs status：看到server1,server4都在线即可！
如果查看集群状态报错
[root@server4 ~]# crm_verify -LV
如下图：
那是因为没有将stonith-enabled=false
[root@server4 ~]# pcs property set stonith-enabled=false
设置后在查看！：
刚才的pcs status的警告也消失了！
既然需要完成高可用，那么就和前面学习的lvs ,nginx的高可用一样
需要设置vip进行变化
添加的vip为自己网段的100号：172.25.1.100
[root@server4 ~]# pcs resource --help
[root@server4 ~]# pcs resource create ClusterIP ocf:heartbeat:IPaddr2 ip=172.25.1.100 op monitor interval=30s
查看状态，可以看到vip在server1上：
这个时候我们停掉server1的状态：
[root@server4 ~]# pcs cluster stop server1
因为高可用，固然会飘到server4上！
[root@server4 ~]# pcs resource agents systemd | grep haproxy
##查看资源管理器中有没有haproxy程序管理##
root@server4 ~]# pcs resource create haproxy systemd:haproxy op monitor interval=60s
##将haproxy与集群建立连接##
在查看pcs status的时候我们看到
clusterip 和haproxy分别在不同的虚拟机，server1,server4
我们需要把这两个参数所在的虚拟机固定在一个上面，这样才能实现高可用！！
建立资源管理组，约束资源，控制资源启动顺序，使其运行在统一服务器上
[root@server4 ~]# pcs resource group add hagroup ClusterIP haproxy
再次查看状态发现ok!
如果ClusterIP或者haproxy服务停掉，集群就会自动重启服务或者添加ClusterIP
比如测试一下：关掉server4的服务 haproxy.service
[root@server4 ~]# systemctl stop haproxy.service
我们会发现haproxy显示server4失败
下面也会有失败的提示：
但是等一会在查看就会发现重新启动了服务：因为高可用会先检测状态，再启动服务，若是启动失败才会切换master!!
如果将正在使用的服务器的网卡down掉，他会自动跳到集群另外一台服务器上:因为网断掉之后，无法重新启动，只能切换！
[root@server4 ~]# ip link set down eth0
而且server4已经下线了
但是这个时候，看一下server4的状态，发现卡死在那里了！！除非手动关掉server1，在重启才会重新加入集群中！！
但是这就有问题了：
若是server1也坏了，没有人发现进行手动重启，那岂不是文件系统脑裂!
，客户端就会访问出问题！那么我们需要找到办法让挂掉的机子重新自动重启！
我们接下来就需要结合fence来使用！
fence结合pacemaker防止文件系统脑裂
在server4，1上
[root@server4 ~]# yum install -y fence-virt.x86_64
[root@server4 ~]# ssh server1 yum install -y fence-virt.x86_64
查看模块
stonith_admin -I
stonith_admin -M -a fence_xvm
##在真机下载##
[root@Sun_s ~]# dnf install fence-virtd-libvirt.x86_64 fence-virtd-multicast.x86_64 fence-virtd.x86_64 -y
[root@Sun_s ~]# fence_virtd -c
出现的选项直接enter下一步：
直到Interface [virbr0]: br0手动输入br0
如下：
[root@Sun_s ~]# fence_virtd -c
Module search path [/usr/lib64/fence-virt]:
Available backends:
libvirt 0.3
Available listeners:
multicast 1.2
Listener modules are responsible for accepting requests
from fencing clients.
Listener module [multicast]:
The multicast listener module is designed for use environments
where the guests and hosts may communicate over a network using
multicast.
The multicast address is the address that a client will use to
send fencing requests to fence_virtd.
Multicast IP Address [225.0.0.12]:
Using ipv4 as family.
Multicast IP Port [1229]:
Setting a preferred interface causes fence_virtd to listen only
on that interface. Normally, it listens on all interfaces.
In environments where the virtual machines are using the host
machine as a gateway, this *must* be set (typically to virbr0).
Set to 'none' for no interface.
Interface [virbr0]: br0
The key file is the shared key information which is used to
authenticate fencing requests. The contents of this file must
be distributed to each physical host and virtual machine within
a cluster.
Key File [/etc/cluster/fence_xvm.key]:
Backend modules are responsible for routing requests to
the appropriate hypervisor or management layer.
Backend module [libvirt]:
The libvirt backend module is designed for single desktops or
servers. Do not use in environments where virtual machines
may be migrated between hosts.
Libvirt URI [qemu:///system]:
Configuration complete.
=== Begin Configuration ===
backends {
libvirt {
uri = "qemu:///system";
}
}
listeners {
multicast {
port = "1229";
family = "ipv4";
interface = "br0";
address = "225.0.0.12";
key_file = "/etc/cluster/fence_xvm.key";
}
}
fence_virtd {
module_path = "/usr/lib64/fence-virt";
backend = "libvirt";
listener = "multicast";
}
=== End Configuration ===
Replace /etc/fence_virt.conf with the above [y/N]? y
它会 生成一个密钥文件在这里：
所以我们需要建立这个目录，让密钥可以方进去
[root@Sun_s ~]# cd /etc/
[root@Sun_s etc]# mkdir cluster/
##由于这个目录没有，所以需要手动创建##
[root@Sun_s cluster]# dd if=/dev/urandom of=fence_xvm.key bs=128 count=1
##生成密钥##
之后，重启服务
[root@Sun_s cluster]# systemctl restart fence_virtd.service
在server1,4上建立目录
[root@server4 ~]# mkdir /etc/cluster
[root@server4 ~]# ssh server1 mkdir /etc/cluster
##创建目录存放密钥##
[root@server4 ~]# pcs stonith create vmfence fence_xvm pcmk_host_map="server1:sun1;server4:sun4" op monitor interval=60s
“将主机名和设备对应关系”加到集群中
把刚才生成的密钥给资源管理的服务器server1,server4
[root@Sun_s cluster]# scp fence_xvm.key root@172.25.1.4:/etc/cluster/
[root@Sun_s cluster]# scp fence_xvm.key root@172.25.1.1:/etc/cluster/
再次查看server4的pcs status
发现fence 已经加入进来因为前面stonith-enabled关闭了，记得吗？
开启它！
[root@server4 ~]# pcs property set stonith-enabled=true
##将stonith启用##
测试：
打开server1的虚拟窗口观察变化
[root@server1 ~]# echo c > /proc/sysrq-trigger
##将server1模拟系统崩溃##此时打开server1的虚拟窗口观察变化
它和前面高可用不同，这个它会自动重启，而前面需要手动重启！
我们再查看一下状态：：
因为server1前面挂掉了，vip,haprox所以转移到了server4上
而fence服务修复了server1，所以会停留在server1上！
若是把server4挂掉，那么server4就会自动重启，vip,haprox所以转移到了server1上
而fence服务修复了server4，所以会停留在server4上！