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

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介:
 今天小编要和读者聊聊有关服务器的高可用性的问题,当前读者应该知道,国内一些从事电子商务行业的服务器性能是相当的强大的(淘宝、阿里巴巴等等),这些电子商务的主站每秒钟的访问量可是相当的可观,读者试着想想如果服务器当掉了咋办,回答可能是肯定还有其他服务器替代啦,对,可是如何迅速替代让用户感觉不到已经有服务器当掉了呢,那便引出小编今天要谈的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日志并进行多维度分析。
相关文章
|
6月前
|
负载均衡 应用服务中间件 nginx
服务器架构、分布式系统、负载均衡、微服务、高可用性
**分布式系统取代单体架构,以微服务实现高扩展性和灵活性。通过负载均衡技术增强性能,防止单点故障,结合冗余备份与故障切换保障高可用性,这种架构是支撑大规模在线业务的关键。**
146 3
|
弹性计算 容灾 定位技术
构建弹性高可用的云计算环境:ECS的扩展与高可用性设计
本文深入研究了云服务器ECS的自动伸缩和高可用性设计,重点关注了弹性伸缩原理与应用、自动伸缩策略、负载均衡器的使用,以及跨地域容灾架构的建立。通过实际代码示例,读者能够全面了解如何在云计算环境中实现弹性的资源管理和高可用性的应用架构。
429 0
|
机器学习/深度学习 分布式计算 Hadoop
三台PC服务器部署Hadoop HA(Hadoop 高可用性架构)
写在前边的话:         转载请注明出处:@http://blog.csdn.net/gamer_gyt,Thinkagmer 撰写         之前是在自己电脑上部署的hadoop集群,但并未涉及到HA配置,这次将集群迁移到PC服务器,但是问题来了,只有三台,但是我还想配置HA,PC服务器是CentOS6.5,原来想着在上边部署VM,从而部署HA集群,但经测试,未果,遂弃之,就想到了在三台机器上部署HA集群。
1401 0
|
9天前
|
人工智能 弹性计算 编解码
阿里云GPU云服务器性能、应用场景及收费标准和活动价格参考
GPU云服务器作为阿里云提供的一种高性能计算服务,通过结合GPU与CPU的计算能力,为用户在人工智能、高性能计算等领域提供了强大的支持。其具备覆盖范围广、超强计算能力、网络性能出色等优势,且计费方式灵活多样,能够满足不同用户的需求。目前用户购买阿里云gpu云服务器gn5 规格族(P100-16G)、gn6i 规格族(T4-16G)、gn6v 规格族(V100-16G)有优惠,本文为大家详细介绍阿里云gpu云服务器的相关性能及收费标准与最新活动价格情况,以供参考和选择。
下一篇
无影云桌面