原创作品,允许转载,转载时请务必以超链接形式标明文章原始出处、作者信息和本声明。否则将追究法律责任。http://xz159065974./8618592/1405812
1、本文的架构图:
阐述各服务器用途:
1、haproxy在本构架中实现的是:负载均衡
2、keepalived实现对haproxy的高可用
3、apache static 实现静态页面的访问
4、aoache dynamic实现动态页面的访问,图中有两个是实现负载均衡的
配置各功能模块:
一、配置haproxy和keepalived
验证:
1、当一台keepalived宕机后,VIP会不会转移到另外一台服务器
2、当一台haproxy服务出故障,VIP会不会转移到另外一台服务器
注意:
那如果keepalived宕机了,haproxy服务还正常运行,我们要不要让另外一台服务器把VIP夺过去呢?
理论上来讲:最好不要,但是我们的keepalived中的脚本监控着haproxy的进程,keepalived宕机之后,就无从得知haproxy的健康状态,也不能决定自己的优先权priority降不降低了。所以,理论上来讲最好不要,但是实际中光靠keepalived是做不到的。
配置:
1、给两台服务器分别安装上keepalived
2、配置keepalived
3、写keepalived处在不同状态下所运行的脚本
4、配置haproxy
因为要实现动静分离,那么我们在配置文件中,就要定义动态资源静态资源转移到不同的服务上去
5、配置另外一台haproxy服务器
因为两台服务器的配置大体相同,我们就直接讲以上配置好的复制文件和脚本文件都传到这台haproxy服务器上,做下修就可以了
传输完成,接着来配置 /etc/keepalived/keepalived.conf 因为两个节点上的/etc/haproxy/haproxy.cfg相同不用更改
注意:
notify_master
"/etc/keepalived/notify.sh master"
notify_backup
"/etc/keepalived/notify.sh backup"
notify_fault
"/etc/keepalived/notify.sh fault"
3个状态分别要执行的脚本,只能放在 MASTER中,原因是:因为是互为主从,每个主的都会有个另外一个主的从,如果
把这 “3个状态执行脚本” 写入到从的区域中,那么另外一个主的从状态就会执行这个脚本,因为就会停掉所要高可用的
程序,这就造成了,两个VIP全部转移到其中一个服务器上去。
我们来验证下,如果keepalived和haproxy分别宕机,vip会不会转移:
在两个节点上都启动 keepalived和haproxy服务
以下为正常情况:
keepalived 1:
keepalived 2:
我们来模拟让第一个haproxy停止掉,再看下,VIP会不会全到 keepalived 2上面去:
查看keepalived 1 和 keepalived 2
看,都过来了。。。。
验证负载均衡很动静分离
我们给3个web服务不同的网页
1、给apache static一个静态页面,来验证如果请求的不是以 .php结尾的网页文件都定向到这太服务器上来
2、给apache dynamic 1 、2 分别两个 index.php ,实现对动态网页的负载均衡
我们给apache static 一个符合-i .jpg .gif .png .css .js的网页,就给个图片网页吧
apache static
apache dynamic 1
apache dynamic 2
1、我们来请求 1.png 结尾的静态文件
2、我们来请求 .php结尾的页面
如此看来,已经对以.php的动态页面做了负载均衡了
我们再通过 192.168.1.201 这个虚拟 ip 访问试试:
由此看来,也实现了双主模型了,两个haproxy同时可以服务了。。。
3、我们来看看状态页面
本文出自 “linux运维” 博客,请务必保留此出处http://xz159065974./8618592/1405812