服务器的高可用性——HA篇

简介:
 今天小编要和读者聊聊有关服务器的高可用性的问题,当前读者应该知道,国内一些从事电子商务行业的服务器性能是相当的强大的(淘宝、阿里巴巴等等),这些电子商务的主站每秒钟的访问量可是相当的可观,读者试着想想如果服务器当掉了咋办,回答可能是肯定还有其他服务器替代啦,对,可是如何迅速替代让用户感觉不到已经有服务器当掉了呢,那便引出小编今天要谈的HA。

      HA是啥?High-Availability Linux 的开源项目的目标是,通过社区开发努力提供一个提升 Linux 可靠性(reliability)、可用性(availability)和可服务性(serviceability)(RAS)的群集解决方案。Linux-HA 项目得到了广泛的应用,是很多有趣的高可用性解决方案的重要组成部分。

      高可用性集群一般是指当集群中有某个节点失效的情况下,其上的任务会自动转移到其他正常的节点上。还指可以将集群中的某节点进行离线维护再上线,该过程并不影响整个集群的运行。

今天小编的主要任务就是来实现HA群集。

Project 1:了解高可用性群集的架构

如图1-1所示,高可用性群集的几个重要部分

clip_image002

图1-1

1)共享信息层

在基础架构上实现心跳信息探测。双方节点可以随时探测到对方的心跳信息,以实现对对方主机工作状态的探测。三类控制信息:心跳(Heartbeats),集群事务信息(Cluster Transition Messages),重传信息(Retransmission Request)。 配置文件:/etc/ha.d/ha.cf。各节点间域共享密钥,实现节点间互相通信的认证。加密方式:MD5、HMAC-SHA1 。常用实现软件:HeartBeat(小编这里就是使用的这个)、keepalived、ultramonkey、openais/corosync。红帽官方提供的集群套件RHCS底层使用的通信机制就是openais/corosync。

2)资源分配子层

在资源分配上定义资源种类,界定资源归属,每个服务需要哪些资源及这些资源之间的前后次序。

集群资源管理器(CRM,常用软件pacemaker),管理双方向外提供服务所需用到的资源,包括IP地址、Web服务、共享存储等等。而这些资源需要依靠集群信息库CIB(XML文件)来定义,同时还必须保证一旦某个节点上的XML文件更新,即刻通知其他节点上的XML也要及时更新。

策略引擎(PE Policy Engine):定义法定人数以及根据法定人数所做出的动作等等。

本地资源管理器(LRM Local Resource Manager):监控本地某个资源的工作状况。

3)资源层

本地资源代理(Resource Agent),脚本文件,一旦集群资源管理器发现某个资源工作异常,立即通知本地资源代理重启服务。常用方法:

(1)Heartbeat v1(小编这里使用的);

(2)使用脚本LSB scripts (Linux Standards Base );

(3)OCF Open Cluster Format 开放集

Project 2:常用的架构模型

1)主从架构:正常情况下只有主服务器工作,当主服务器当掉从服务器立即启用

2)互为主从架构:两台服务器提供不同的服务,相互为主从架构,两台服务器同时工作

3)多主机架构

N台主机组成一个集群,分别提供不同的服务,一台服务器空闲做备节点。或者全部处于工作状态,一台服务器出故障,立刻将服务转移到其他主机上。各节点之间需要以多播的形式将自己的健康情况发送给其他主机。

Project 3:高可用性集群的实现

1)主从架构

step 1:实验拓扑规划,如图3-1-1所示

clip_image004

图3-1-1

Primary eth0 192.168.1.100

           eth1 192.168.2.10 //心跳测试

Standby eth0 192.168.1.200

             eth1 192.168.2.20 //心跳测试

向外提供Web服务IP:192.168.1.150

step 2:系统与软件资源需求安装

小编的系统是Red Hat EnterPrise Linux 5.4

小编的系统上已经安装了apache2.2.3和php环境,如果读者不会安装的话可以参见小编的博客http://wnqcmq.blog.51cto.com/5200614/1177203

小编将这些软件包放在/root/heart目录下了,然后使用不加gpg验证的本地yum安装完成

heartbeat-2.1.4-11.el5.i386.rpm

openhpi-libs-2.14.0-5.el5.i386.rpm

heartbeat-pils-2.1.4-11.el5.i386.rpm perl-MailTools-2.04-1.el5.rf.noarch.rpm

heartbeat-stonith-2.1.4-11.el5.i386.rpm perl-TimeDate-1.16-5.el5.noarch.rpm

libnet-1.1.5-1.el5.i386.rpm

primary服务器的安装配置

# cd heart/

# yum localinstall ./* --nogpgcheck

这样安装省了很多事,系统会自动解决依赖关系,但是读者还要记着安装完成之后查询一下heartbeat到底产生了哪些文件

# rpm -ql heartbeat

其中/usr/share/doc/heartbeat-2.1.4/目录下就存放了heartbeat的样例配置文件

接下来的工作是修改主机名,Heartbeat依靠服务器的主机名来识别服务器,因此使用hostname命令得到的结果必须与uname -n 结果保持一致。

# vim /etc/sysconfig/network //修改主机名称;

HOSTNAME=primary.a.com

# hostname primary.a.com

# vim /etc/hosts //修改主机地址映射;

192.168.1.100 primary.a.com primary

192.168.1.200 standby.a.com standby

# cd /etc/ha.d/

# cp /usr/share/doc/heartbeat-2.1.4/ha.cf ./

# cp /usr/share/doc/heartbeat-2.1.4/authkeys ./

# cp /usr/share/doc/heartbeat-2.1.4/haresources ./

# vim ha.cf //定义各节点之间Heartbeat进程如何通信;

debugfile /var/log/ha-debug //设置调试日志文件名

logfile /var/log/ha-log //设置其他日志文件名

keepalive 2 //设定heartbeat之间的时间间隔为2秒;

deadtime 30 //在30秒后宣布节点死亡;

warntime 10 //在日志中发出late heartbeat警告之前等待的时间,单位为秒;

udpport 694 // 使用端口694进行bcast和ucast通信,默认参数;

bcast eth1 //在eth1接口上使用广播heartbeat-”心跳”;

node primary.a.com //定义节点;

node standby.a.com //定义节点;

# dd if=/dev/urandom bs=512 count=1 | openssl md5 //生成节点间域共享密钥;

14df2a6b5b26b510e7d5d5b16b7cc10b

# vim authkeys //定义心跳探测包使用哪种加密方式;

auth 1

1 sha1 14df2a6b5b26b510e7d5d5b16b7cc10b

# chmod 600 authkeys //仅允许管理员修改文件;

# cp /etc/init.d/httpd /etc/ha.d/resource.d/

# vim haresources //定义资源;文件给出了相应的格式

primary.a.com 192.168.1.100/24/eth0/192.168.1.255 httpd

standby 服务器的配置

从服务器的主机名称为standby.a.com,安装heartbeat的方法同主服务器一致。/etc/hosts文件、Heartbeat的配置文件也必须与主机保持一致。因此这里采用将primary上的配置文件直接远程复制过来的方法:

# cd /etc/ha.d/

# scp 192.168.1.100:/etc/ha.d/ha.cf ./

# scp 192.168.1.100:/etc/ha.d/authkeys ./

# scp 192.168.1.100:/etc/ha.d/haresources ./

# cp /etc/init.d/httpd /etc/ha.d/resource.d/

# chmod 600 authkeys

step 3:集中测试

分别重新启动primary和standy服务器的heartbeat服务,如图3-1-2、3-1-3所示

clip_image006

图3-1-2

clip_image008图3-1-3

这样就启动成功了,接下来编写测试网页,小编这里为了让读者看的清楚两台服务器的工作,所以两个测试网页的内容是不同的,而在实际的应用中两台服务器上的内容肯定是一致的啦。

primary服务器的/var/www/html/index.php内容

<?php

for($i=0;$i<9;$i++)

echo $i."web1"."<br/>";

?>

standby服务器的/var/www/html/index.php内容

<?php

for($i=0;$i<9;$i++)

echo $i."web2"."<br/>";

?>

在客户PC的浏览器上输入http://192.168.1.150试试看,结果如图3-1-4所示

clip_image010

图3-1-4

以上结果是在primary服务器为主服务器的情况才会出现的,那么现在小编就来模拟以下主服务器成为备份服务器的情况再来看看,这里heartbeat提供了一个工具来切换服务器状态,在/usr/lib/heartbeat/目录下,这里小编在切换服务器状态的同时,来监控一下两台服务器的日志,让读者清楚两台服务器之间是如何切换主从关系的

在primary服务器上执行

# cd /usr/lib/heartbeat/

# ./hb_standby //请求成为辅助服务器

主服务器的日志情况如图3-1-5所示:

clip_image012

图3-1-5

从服务器的日志情况如图3-1-6所示:

clip_image014

图3-1-6

小编现在来说明一下切换流程

1.primary服务器发出申请说自己想成为standby服务器,并且说明standby服务器可以拿走资源

2.”心跳“(广播)被standby服务器抓到,知道primary要变为standby服务器

3.primary开始释放资源,可以看到主服务器关闭了httpd服务器,当掉了192.168.1.150

4.standby开始申请资源,可以看到standby服务器开始启动httpd服务器,并且启用对外IP192.168.1.150

5.双方工作都完成显示success

此时在刷新一下PC机的浏览器看看,结果如图3-1-7所示

clip_image016

图3-1-7

看到了吧,成功转到standby服务器了

刚刚不是standby服务器成为了主服务器么,那么下面小编就来模拟一下主服务器当掉的情况,这里小编将监控“心跳”的eth1端口当掉

# ifconfig eth1 down

可以在primary服务器的日志上看到如图3-1-8所示的信息

clip_image018

图3-1-8

此时再次刷新一下PC的浏览器看看,结果如图3-1-9所示

clip_image020

图3-1-9

primary服务器成功切换成为主服务器啦

到这里主从架构的配置以及测试小编就完全演示完了,接下来的工作交个读者你去动手操作啦,接下来的工作是完成互为主从架构的案例啦

2)互为主从架构

step 1:实验拓扑规划,如图3-2-1所示:

clip_image022

图3-2-1

这里小编仍然使用主从架构的环境,稍作修改即可

step 2:

primary服务器的资源配置修改

# vim /etc/ha.d/haresources

primary.a.com 192.168.1.150/24/eth0/192.168.1.255 httpd

standby.a.com 192.168.1.151/24/eth0/192.168.1.255 vsftpd //添加ftp

# touch /var/ftp/primary //作为区分用

standby服务器的资源配置修改

# vim /etc/ha.d/haresources

primary.a.com 192.168.1.150/24/eth0/192.168.1.255 httpd

standby.a.com 192.168.1.151/24/eth0/192.168.1.255 vsftpd

# touch /var/ftp/standby

step 3:重新启动两台服务器的heartbeat服务

# service heartbeat restart

step 4:集中测试

仍然在PC机的浏览器输入http://192.168.1.150,结果如图3-2-2所示

clip_image024

图3-2-2

PC浏览器输入ftp://192.168.1.151试试,结果如图3-2-3所示:

clip_image026图3-2-3

看见了吧,两台服务器相互备份,都运行有应用服务,读者可以自己测试一下将其中一台服务器当掉,看看结果,小编这里就不掩饰了,有啥问题请联系小编哈,至于第三种模式,由于小编的主机有限就没做了,如果读者能把上面两种模式理解透彻,第三种很容易实现啦。

编后语:HA集群一般都是以两个节点的形式出现的,单机处理能力有限,所以当服务器压力较大时,想扩容服务器的处理能力往往得把以前的服务器淘汰掉,浪费了以前的投资;因此对于高访问性需求的商业性网站单纯想使用HA群集来解决问题是不可行的,如果再结合LVS来使用,那便是极好的了,至于LVS的实现小编会在后续的博客中道来,敬请关注哈。。。。。


本文转自 chenming421  51CTO博客,原文链接:http://blog.51cto.com/wnqcmq/1179525


相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
Kubernetes 网络协议 网络安全
安装k8s Master高可用集群
安装k8s Master高可用集群 主机 角色 组件 172.18.6.101 K8S Master Kubelet,kubectl,cni,etcd 172.18.6.102 K8S Master Kubelet,kubectl,cni,etcd 172.
3542 0
|
应用服务中间件 nginx 网络安全
|
关系型数据库 MySQL 开发工具
|
监控 网络性能优化 负载均衡
|
应用服务中间件 nginx 开发工具
|
Web App开发 监控 应用服务中间件

热门文章

最新文章