高可用性

高可用性（共11篇）

高可用性 篇1

摘要：随着网络的快速普及,网络承载了大量的应用,对可靠性的要求越来越高。需要充分使用设备冗余,软件恢复和备份,故障恢复机制等解决措施,提高网络的可靠性。

关键词：MTBF(平均故障间隔时间),MTTR(平均故障恢复时间),RP(路由处理器),RPR(弹性分组环),VRRP(虚拟路由冗余协议)

1 网络应用的现状

随着网络的快速普及和应用的日益深入,各种关键业务和增值业务在网络上解决方案得到了广泛部署,网络带宽也以指数级增长,对可靠性的需求也越来越高,尤其是在各种运营商网络、商业经营网络和管理控制网络中,需求显得更为突出。网络短时间的中断就可能影响大量业务,造成重大损失。作为业务承载主体的网络高可用性(High Availability,HA)日益成为关注的焦点。从运营商到大中型企业客户,在构建网络时,99.999%的电信级已经成为解决方案基本需求之一。

2 网络可用性的度量

定义一个网络设备的可用性或正常运行时间的方法有几种。“可用性”是指一个路由器实际处理和转发数据包的时间百分比。因此,一个系统的可用性可以表达为网络的平均故障间隔时间(MTBF)和它的平均故障恢复时间(MTTR)。计算公式如下:

如表1,从公式中可以看出,要提高网络的可靠性,需要提高网络的平均故障间隔时间和缩短平均故障恢复时间。

3 在网络建设中,需要全方位多角度的对网络可靠性给予充分保障

1)硬件设备的可靠性:要提高设备的可靠性需要选用合适的硬件以及将备份的硬件部件构建到系统中去。[1]

(1)双路由处理器:RP是路由器的大脑。它计算路由和转发表,并将最佳路径信息发送给对等路由器。采用双RP可以极大的缩短系统的故障恢复时间。

(2)硬件系统架构:路由器的硬件架构选择将对系统的潜在可用性产生影响。最主要的路由器架构有集中式架构和分布式架构。

在集中式架构系统中,数据包处理和转发工作在一个中央共享RP中执行,各网络接口线路板相对简单(见图1)。如果中央RP发生故障,所有的路由和数据包转发都会停止,对整个系统的影响很大。在这种架构中,双RP设计变得非常关键。

在分布式架构系统中,数据包转发能力被置于每块线路板中(见图2)。将转发引擎从中央RP转移到每块线路板降低了RP故障的影响,因为在RP故障期间线路板仍可继续转发数据包。

(3)冗余供电、线路板、风扇和机架都对降低MTTR具有关键意义。此外,将这些部件设计成能够热插拔可以极大地提高正常运行时间,而且使得工作中的系统不必关机就可以直接更换部件。

2)软件的可靠性,在设计高可用性软件中有几个关键目标。

(1)将软件故障的影响降到最低

降低软件故障影响的一种方法是只重启发生故障的那个软件进程,而不是重启整个系统。这必须在保留路由、转发表和会话的情况下完成。

另外要将软件故障的影响限制在路由器本身,防止对网络的其他部分产生更广泛的影响。为了实现这个目标,路由器必须运行被激活RP和备份RP并让它们的信息保持同步。需要注意的是:在何种程度上让处于工作状态的RP和备份RP保持其全部信息,并如何同步是一个关键性的设计考虑。其决策反映了在系统恢复速度和成本之间的一个平衡折中。可供选择的方案有冷、暖和热待机备份系统。[2]

a冷备份方案中,处于工作状态的RP和备份RP之间不共享任何状态信息,软件故障将导致完全的复位,备份RP自动接替发生故障的处于工作状态的RP,但是必须从头开始建立自己的路由表。此外,所有的线路板也将进行复位。这种方案下发生的是彻底的用户停机。不过,与没有备份RP时相比MTTR仍然较低,因为系统可以自动开始恢复,无需维修或更换路由器。

b暖备份方案中,路由器配置和软件镜像都已经载入了备份RP。当备份RP必须重建其路由表信息时,由于跳过了配置和镜像重载步骤,因此降低了MTTR。

c热备份方案中,备份RP加载了路由器配置、软件镜像和网络状态信息,而且还由处于工作状态的RP对其进行连续更新。同步的状态信息对应于所用的协议,这样当处于工作状态的软件或硬件RP发生故障时,备份处理器就可以接替和恢复系统而不造成任何服务损失。处于工作状态的RP和备份RP之间的同步率决定了备份处理器在任意时刻的更新程度,从而也决定了系统的恢复速度。处理器同步次数越多,失配的可能性就越小。不过,频繁同步增加了系统资源的消耗。这可能会影响路由器的吞吐性能,或者需要在系统中增加额外的处理能力。

(2)对软件故障进行迅速检测和恢复。[3]

对实际硬件和软件故障的检测必须迅速进行以便使系统得以及时恢复。具体时间长短取决于系统的设计。

3)将系统恢复时新会话的阻塞间降到最短。

在RP发生故障(包括硬件故障或软件故障)的情况下,设备的恢复将需要花费一些时间。包括将新的软件镜像加载到备份RP、加载配置、对其初始化、取得Layer 2连接和Layer 3路由协议以及重建路由表。

4 节点和链路的可靠性

链路失效也是影响网络可靠性的一个重要因素,为此需要实现以下几个目标。

1)提供备份链路[4]

可以提供1+1备份或者N+1备份,1+1的备份方案虽然方案比较昂贵,但可以提供比N+1更高的可用性。

进行链路备份同样需要软件提供相应的支持。

(1)TRUNK,TRUNK是端口汇聚的意思,就是通过配置软件的设置,将2个或多个物理端口组合在一起成为一条逻辑的路径从而增加在交换机和网络节点之间的带宽,同时如果一条物理端口。

(2)VRRP(Virtual Router Redundancy Protocol),VRRP可以创建一个具有虚拟MAC地址和虚拟IP地址的虚拟路由器,VRRP可以在工作站的缺省网关失效时提供一个备份路由器(见图3)。

(3)RPR(Resilient Packet Ring),快速的环保护倒换(50ms)功能。与SDH中的物理层环保护倒换不同,RPR采用2层的环保护倒换(见图4),其具体实现时可分为类似于MS-Spring的环回方式(Wrap),以及源节点切换的转向方式(steering)。这两种倒换方式均有其优缺点,前者简单(仅涉及故障端两端的节点切换),数据包丢失少,但带宽占用多,后者则反之。

(4)FRR(fast reroute)技术,提供快速保护倒换能力。

当一条LSP出现问题,不能正常传输信令和数据,这时候就将信令与数据转移到事先已经建立好的另外一条路径上去,以保证业务不会中断。可以这样理解FRR是一种保护措施。在FRR中有三种不同类型的保护方案,一种是路径保护,也称为端到端保护,这种方式是通过和现在的LSP并行建立额外一条LSP,这条LSP只会在发生失效时使用。另外一种为局部保护,或称为本地保护,即备份LSP只对原LSP的一部分进行保护。最后一种是针对LSP中的结点进行保护,这种称为结点保护。根据具体应用不同,可以分为LDP FRR,TE FRR,VPN FRR。

2)节点和链路故障的迅速检测和切换。[5]

1)BFD(Bidirectional Forwarding Detection),BFD是从基础传输技术中经过逐步发展而来的,因此它可以检测网络各层的故障。它可以用于检测以太网、多协议标记交换(MPLS)路径、普通路由封装以及IPSec隧道在内的多种类型的传输正确性。

2)OAM(Operation Administration and Maintenance),通过定期查询的方式检测网络故障,将故障信息传递给管理实体,并且可以进行性能监控,根据这些信息评估网络的稳定性。根据运行链路的不同,有ETH oam,mpls oam,atm oam等。

5 结束语

在做网络规划时,需要充分应用上面的各项技术。保证关键设备双归属,重要链路聚合,重要设备冗余部署,流量路径合理规划。

参考文献

[1]网络高可用性技术白皮书,华为3com技术有限公司.

[2]Build High Availability into Your IP Network,CommsDesign.

[3]Get high availability using effective fault management,CommsDesign.

[4]Optimizing RTOSes for HA architectures,CommsDesign.

[5]Enterprise NetworkDesign Patterns:High Availability.SUN.

高可用性 篇2

凡是我们写成功的程序大部分都会和数据库进行交互，我们的数据库也必须有必要的措施防止数据库的崩溃，在我们学习高可用性解决方案之前我们都是用的数据库备份和还原(如果你连这个都没考虑到，那你写的程序也太不安全了)。具体的备份的实现也有很多，比如说完整备份，差异备份……这里都不具体说了，大家可以去另外学习。但是这些备份会浪费好多时间，且随着数据库的增加几何性的增长?当一个网站的数据库发生故障时，我们不可能用备份的形式去完成数据库的维护。比如你正在京东买东西，突然京东的数据库服务器硬盘坏了，你必须等待后台人员备份好数据库后你才能去购买?或者目前半小时不能购买了以后你还会去京东买东西吗?那这些问题如何解决呢?这就需要我今天说到的一些高可用性解决方案了。

构建高可用性的政府网站 篇3

一、用户绩效是我国当前电子政务提升的第一要务

经过10年的发展，全国政府网站的体系已经基本形成，电子政务由投资建设阶段向应用推广阶段转变。在新公共管理运动的背景下，电子政务测评在近年来已经逐步开始用“绩效途径”来取代传统的“效率途径”，重视服务质量和顾客满意度。正如企业信息系统或电子商务的发展规律，电子政务在转变期也同样面临一个难题：一方面政府每年投入巨资，加速建设和维护；而另一方面，广大社会公众对政府网站的社会参与度和满意度却普遍较低，网站的公共服务质量亟待提高。根据近期中国青年报社会调查中心调查显示：85.6%的人曾访问过政府网站，但是仅有28.3%的人经常访问；61.3%的人对政府网站感到不满意，32.0%的人感觉一般，不到7%的人表示满意；33.1%的人认为政府网站需要加强网上互动交流，提供网上政府服务（《中国青年报》，2008.12.16）。

2009年1月11日，由国家工业和信息化部主办、中国软件评测中心承办的“第七届（2008）中国政府网站绩效评估结果发布暨经验交流会”上，工业和信息化部副部长杨学山指出，09年國家不再委托专门的机构进行政府网站测评，而围绕政府网站建设重点内容和重要方向给出核心指标体系，主要体现出政府门户网站作为政府信息公开和政务公开的主渠道、企业和老百姓提供政务服务的主渠道以及公民表达意见、需求和政民互动的主渠道。这预示着我国政府门户网站的测评将从以综合排名为重点转为注重公共服务质量、注重用户使用过程和注重改善与反馈

的新阶段。

二、可用性是政府门户网站绩效的根本来源

任何网站都是一种“自助式”的产品，访问者所能依靠的只有自己来独自面对这个网站。电子政务与传统公共服务的重要区别在于，用户是通过对网站的使用来达到主动获取服务的目的。传统产品看重的是最终消费结果，而网站服务依靠的却是连续的使用过程。用户在任何一个点击步骤上都有可能终止接受服务，并有可能不会有二次访问。用“战战兢兢，如履薄冰”来形容这一过程并不为过。互联网的经验告诉我们，在任何一个点击步骤上让用户多花一点点时间，用户终止访问的可能性就要呈几何倍的增加。国际著名可用性专家尼尔森(Nielsen)根据实际测试结果指出：比起阅读报纸或杂志，用户在浏览网站时通常比较缺乏耐性；用户对内容复杂的网页往往感到不知所措；用户很少阅读冗长的网页，而只是扫描吸引他们的重点；立体而鲜明的按钮与标题可以有效地引导使用者的阅读；搜寻引擎的辅助功效并不大，使用者常无法输入正确的关键字,而得到许多完全无关的结果；使用者需要网站的整体架构指引；“正在建设中”的提示令用户反感；用户普遍难以忍受两次以上的点击错误；过时的网页内容会大幅降低网站的整体形象；提供网站设计者或经营者的有关信息，可让使用者产生安全感；使用者偏好网上的直接互动模式，例如可以要求进一步的信息，参与讨论以及网站的用户问卷调查；网页上的色彩以及闪动的画面应谨慎使用。这些都是网站的“可用性”问题。

政府网站可用性将直接影响到电子政务功能的实现。对社会公众而言，起首要决定作用的并不是政府网站信息、功能栏目等是否够多、够用，而是它们的编排、设置和推介方式是否围绕公众的需求和认知习惯，是否好用、能用。网站的可用性是留住用户、引导继续使用，并产生满意感的关键。很难想像，一个在布局上让用户觉得别扭，在导航上让用户不知所措，在按钮设计上让用户频频犯错，在内容编写上让用户阅读吃力……的政府网站，会体现出该政府部门“以民为本”的宗旨，很有可能会让用户觉得是“脸难看，门难进”。这对始终高度重视电

子政务建设，每年投入大量人力和物力来完善各项网站内容和功能的政府来说，是一件令人相当惋惜的事情。

三、开展“政府网站可用性工程”是践行科学发展观的基本要求

可用性工程是人机交互研究领域的重要分支，是新的“以用户为中心”的Web设计与运营方法论，强调在对用户使用行为的测试基础上设计网站架构和内容，并持续优化，以始终达到用户最佳的使用体验。可用性工程已经逐步被应用于商业性网站，阿里、腾讯等著名互联网公司均设有可用性测试和交互设计部门，但是在电子政务领域，由于较多采取建设外包，独立或半委托运营的模式，网站可用性往往成为“三不管”地带。

与一般商业网站相比，政府网站更加强调服务的平等性、可达性、交互性和用户满意度；我国的电子政务也不同于西方发达国家的政府网站，其公共服务涉及层面更加广泛和深入，用户需求和使用行为更加复杂多样，兼顾效率和效果更是我国政府为民服务的首要准则。从用户打开主页的那一刻开始，每一步点击和浏览都是在接受公共服务，因而都是重点工作；这与现实中政府工作人员的一举一动都是“为民服务”是一样的道理。因此，“政府网站可用性工程”的意义更为重大，其要求也更高。

提倡“政府网站可用性工程”，实际上是要求电子政务“以用户为中心”，了解用户的网站使用习惯，尊重用户对网站的感知和评判意见，最后运用科学系统的可用性工程方法来优化政府网站，破解用户使用率低、满意度不高的难题。在政府网站的日常运营上，政府工作的重点既不是一味的强调技术和资金投入，更不是简单的委托外包后置之不管，而是不回避现有用户的使用问题，并以其为核心，重视对用户需求的跟踪，持续优化网站，提升政府网站的可用性。

四、构建我国政府网站可用性指南

“可用性指南”是经过研究和反复验证后，能够达到最好的用户使用体验效果的网站设计和运营原则与标准（如ISO体系中就有专门的可用性指南）。目前我国尚无统一规范的政府网站可用性指南，很多政府网站在建设、改版和日常维护中，往往是根据技术人员、主管领导和业务人员的一时感觉进行评判和方案拍板，没有严格的按照用户群进行需求分类，更没有通过特征用户的测试来确定各项方案。

建设我国政府网站可用性指南，是切实推进“政府网站可用性工程”的关键。可按如下框架开展相关工作：

（1）政府网站可用性的目标：通过高可用性的网站使用，让用户逐步从信息浏览，到在线办理，再到互动参与，最后形成对政府网站的满意和信任；

（2）政府网站可用性的绩效标准：用户上网的任务效率、任务效果和任务满意度；

（3）政府网站可用性的内涵：

◎网站内容：实时性，各层次人群的可读性，标题链接的易懂性，首页图片和文中插图效果，站内搜索效果和外部引擎搜索效果；

◎网站易使用：整体感觉和布局符合用户一般习惯，导航和标签的内容分类清晰、定位链接准确，办事流程按钮和点击路径简便易懂；

◎网站定制化：当地特色，互动效果，促销推广，定制化模块；

◎网站情感：权威性，亲和力，重大突发事件下的安抚性等。

（4）政府网站可用性的用户研究方法：

◎用户分类：运用人物角色方法，在普通公众、企业投资者、外来游客三种基本类别下，进一步细化，形成具有典型性的人物模型，针对该人物角色来分析其代表性需求和对可用性的反应；

◎用户行为：运用Web服务器访问日志数据挖掘，获得用户对可用性的总体反应；

◎用户态度：运用问卷调查方法，获得用户对可用性的基本态度和评价；

◎用户习惯：运用实验室测试方法，获得在网站上的使用过程和效果；

（4）政府网站可用性的工程：确定可用性各内涵获得最佳用户体验效果的具体标准；结合实际背景，对各内涵的标准进行组合和筛选，形成模块化的政府网站可用性设计、改进与运营方案。

综上所述，构建高可用性的政府网站，实质上是强调了人机交互过程中的以用户为中心的理念，这不仅是当前商业网站设计和运营的主流思潮，也是我国当前公共服务“以民为本”的具体体现。各级政府在网站设计和运营中，更多的运用可用性工程方法；理论界和实践界在政府网站可用性问题上，更多的从科学角度进行研究，形成可指导实际的可用性指南，这必将极大地提升政府网站在用户使用上的效率、效果和满意度，从而推动我国电子政务进入全面应用和持续效果提升的新阶段。

(本文由国家自然科学基金项目（70672049）资助。 ）

(作者刘渊系浙江大学管理学院教授、博士生导师；

高可用性系统研究 篇4

所谓数据高可用性是指确保网络数据不受各种因素侵扰、网络数据实时可用的技术, 主要包括群集技术、防火墙技术、入侵检测技术、网络防毒技术、数据备份技术、UPS和异地容灾等。保障系统的高可用性归根到底是保证系统服务不中断, 系统不停机。

1 系统停机原因及可用性评价

停机故障的定义为:当环境致使用户无法准时完成他的工作, 我们就说系统发生了停机故障。

引起停机的原因有很多, 常见的有:硬件故障、软件故障、网络故障、人为错误、自然灾害和其他原因等。图1为对停机故障常见原因的调查结果图。

图1来自计算机行业分析机构Gartner/Dataquest, 分析停机故障的最主要原因为软硬件故障和人为因素。

系统的可用性计算公式为:undefined

A指可用性的百分比, MTBF指平均故障问题时间, MTTR是指最长修复时间。对于某一特定系

统的MTBF为100 000小时, MTTR为6min, 其可用性为99.9999%。要获得6min的停机时间的可用性, 需要一个持续运行100 000h的组件, 两次故障间隔要超过11年, 即要获得99.9999%的可用性整个系统在11.4年内只允许6min的停机时间, 而非每一个组件。

考虑到实际的需要, 单一的技术是完全不可能实现的, 这是一个不现实的目标, 只能很大程度的依靠运气来保证系统的安全了。

只有将整个系统的故障间隔增大, 减少系统的停机时间才能获得较高的系统可用性。下面将从各个方面来讨论提高系统可靠性的方法。

2 高可用的机房环境

机房环境是整个系统的基本保障, 没有一个高可用的机房环境, 系统将无法稳定、可靠运行。机房环境包括:电力保障、防雷、防尘、防火、防静电、适宜的温湿度、监控、防盗等。

2.1 电力保障

为保障有效用电, 可以从两个不同的电网获得电力供应进行双路供电, 可以避免一路电源故障而导致的系统运行中断。如果系统以双机热备 (主从服务器) 的方式提供服务, 要为每个服务器分别引入一路电源。

UPS (不间断电源) 也是一种避免电力中断的设备, UPS可以为系统提供几分钟乃至几小时的故障处理时间, 可利用这段时间安全关闭数据库、文件系统, 为后备电源的接入赢得时间。

发电机是提供系统用电的最后一道屏障。停电后, 在UPS电量耗尽之前, 使用发电机供电可以有效保障系统用电, 避免了因电力故障而导致的系统不可用。

2.2 监控与防盗

保证系统设备的物理安全与保障系统的数据是同等重要的, 禁止非工作人员进入机房并为机房安装专用的监控报警装置可以有效预防和发现非法闯入者, 避免因蓄意破坏而导致的系统不可用。

2.3 防火、防水

防火、防水同样很重要, 为机房安装一套独立于大楼消防系统的保护装置, 而且为其配备警铃报警器, 以便于工作人员及时发现紧急情况。而且要为机房配备专用的气体灭火系统, 以保证未发生火灾的设备被水损坏。

设备机房应该放在二楼以上的地方, 避免受到洪水、消防用水、暖气用水等的浸泡。

2.4 温度与湿度

为保护机房设备免受高温和潮湿的破坏, 一定要按照系统运行的最长时间要求安装合适的空调设备。最好的办法是为机房设备设立独立于大楼的制冷设备, 这样可以将大楼的制冷设备的故障隔离, 而且减少了整个制冷系统的能耗。机房空调应选用专用的 (下送风) 机房空调, 以保证有效地制冷。

适宜的温度也可以减少机房内的浮沉, 避免灰尘落在设备内而导致的短路等故障。

2.5 避雷与接地

防雷, 机房系统一定要设立独立于大楼的防雷系统。以保证机房等弱电系统的设备免受雷击, 避免因雷击而造成的系统设备不可用, 这些设备包括网络设备和服务器等。

接地, 机房设置分离的强弱电接地系统, 将强电系统接地和弱电系统接地分开进行, 避免因静电而导致的系统设备故障。

3 高可用服务提供

3.1 高可用网络

网络是计算机通信的基础, 有了高可用的网络才能为系统服务提供一个良好的通信保障。建立高可用的网络可以有效避免网络中断或网络阻断的故障。

3.1.1 构建冗余网络

冗余网络连接保护网络, 使之免于发生在网络接口卡、包含NIC的I/O子系统或连接到NIC的某个网络硬件的电缆这些部件上的故障, 可以避免主机到网络的单点故障[2]。

另外冗余网络还指建立网络的IP路由冗余, 通过网络设备的冗余连接, 保证了网络通信的高可用, 有效避免单个网络设备的损坏或链路的失效而影响整个网络系统的瘫痪。

3.1.2 网络安全

将企业内部网络与外部网络区分开来, 是阻挡来自外来干扰的最好办法。通过设置进出数据过滤机制, 可以监控和过滤有效访问, 拒绝恶意和非法访问, 从而保证内部网络的安全。

3.1.3 补丁与防病毒

安装防病毒软件可以将电脑的病毒程序全部杀死, 避免产生额外的网络带宽和负担, 可以减少被恶意程序影响。如可以有效防止ARP、拒绝服务攻击等, 删除记录用户名密码等木马, 防止受到远程控制软件的控制等。

及时安装系统补丁程序, 将已知系统漏洞的威胁消除, 具报道, 现有的入侵和损害多数是由于未及时安装系统补丁造成的。

3.2 高可用服务系统

性能稳定、可靠的服务系统是提供高可用服务的必要条件。利用集群技术, 将两台或多台服务器通过集群软件连接形成服务器群, 在系统中配置一个或多个备用系统, 作为主服务器的备份。如果主服务器发生故障, 备用系统自动跟进, 在经过短暂的中断后, 全面接管主系统。这样系统故障引起的停机时间将不会超过主系统和备用系统的切换时间, 该时间一般为几秒至几十秒。

3.2.1 服务器系统

服务器系统包括其硬件冗余、热插拔 (Hot Plug) 、DP (双处理) 、SMP (对称多处理) 、RISC和CISC处理器架构、总线技术、磁盘技术、电源技术、智能输入输出 (I2O) 、双核处理器技术、64位处理器技术等[3]。

3.2.2 应用服务软件

群集技术是指在系统中配置一个备用系统, 作为主服务器的备份。一般通过集群软件管理群集系统, 群集系统依靠群集软件实现服务系统的软件可用性, 依靠群集系统可以实现故障转移。

良好的系统服务软件也是提高系统服务可靠性的一部分, 如性能优良的数据库软件、安全稳定的操作系统等。

3.3 高可用的应急方案

在设备出现故障后 (如RAID磁盘中有一块盘损坏、冗余系统中一个系统出现停机等故障) , 由于可用性较高, 暂时不会影响到系统的使用, 但存在可用性隐患, 如不及时解决该故障, 就会导致系统不可用。如何在最短的时间内修复这类故障, 各个单位都应有自己的方式和办法, 有些单位甚至需要制定详细的应急方案和策略。

为设备购买7×24的服务是一项比较理想的选择, 这样可以以最快的速度来解决这类故障, 降低系统的不可用因素。

4 高可用数据管理

数据管理是对系统数据的保护, 数据保护更多地体现在诸如容灾系统的建立、容灾方案的可行性、异地存储方案的部署等方面。涉及的技术有NAS、FC SAN、IP SAN、数据同步、数据镜像、热备份、互援备份[4]等。

数据的存储与管理有六个层次, 如图2所示。这几个层次之间是互相独立的, 选择任一个层次不会对其它层的选择使用产生影响, 如选择硬件RAID并不一定排除对软件RAID的需要, 反之亦然。

图2 数据管理层次

在系统中构建和实施SAN (存储区域网络) , 可以带来诸多好处, 如集中化和整合存储资源、共享存储资源、减轻网络负载、加速备份速度、改善数据访问等。利用FC SAN或IP SAN可以更好地提高存储区域网络的性能, 提高系统数据的可用性保障。

5 高可用容灾

5.1 数据备份

如果数据备份做的好, 它会成为对付任何灾难的最后防线。即使在系统完全失效的情况下, 只要有有效的备份在, 数据就可以得到恢复。要注意的是数据镜像不能代替数据备份, 他们两者的功能是不一样的, 不管有没有镜像, 备份都是必须进行的工作。

5.1.1 备份软件

虽然各操作系统或各数据库系统都带有数据备份的功能, 但该功能不能充分的满足用户的实际备份需求, 由于商业备份软件具有很多优点, 成为人们的首选工具。

5.1.2 备份类型与策略

备份的类型关系到备份的性能。由于备份牵扯到备份数据量的大小、数据所占存储空间的大小、备份速度的快慢、数据恢复的难易、备份时服务中断与否以及中断时间长短等因素, 选择合适的备份类型至关重要。

5.2 数据恢复

恢复的速度取决于备份的速度与复杂程度, 越高速的备份, 其恢复速度越慢。数据恢复是系统可用性的最后保障, 因此一定要保证备份生成的磁带都能进行可靠恢复。

5.3 数据库维护

数据库管理员应该定期对数据库进行优化, 以保证数据库处在最佳的服务状态。

6 高可用管理制度

6.1 正规的操作规程

无论是系统用户还是系统管理员, 都要遵循一定的操作规程, 这套规程必须是被证实不会给系统带来负面影响的。任何对规程的改变都要事先在试验平台上进行相关的试验, 通过后才可用于系统中。应有专门的人员或者机构来监督和实施操作规程。

6.2 人员培训

可靠的人力资源保障也是系统可用性的组成部分之一。

高质量的用户培训, 确保用户掌握关于系统方面的知识, 避免和减少用户因误操作而造成的数据丢失等问题, 在用户投入实际工作之前和工作之中都要根据工作要求为其提供充分的系统培训。

对于系统管理人员更应该给予足够的重视, 不仅要在专业技能上给与充分的培训和训练, 还要重视其思想。为他们提供一个宽松的学习生活空间, 让他们更乐于为目前的工作效力, 而不是总想着跳槽或没有安全感。这样就可以避免更多的人为因素造成的系统故障, 如不安心工作、蓄意破坏等。比起其他安全性来说, 这种潜在危险对系统带来的影响更加巨大, 更不好防范。

6.3 系统管理制度

系统管理是指过程、数据、工具和组织的组合, 是充分有效地管理一个系统所必需的综合性手段。树立并制定管理目标是系统管理中的首要任务, 只有充分地了解才能尽力地实现这一目标。质量测量与跟踪环节非常重要, 通过测量与跟踪环节可以衡量所取得的测量数据是否达到系统的目标要求。可以根据管理实施的状况对管理计划进行再次分析并作出修改, 以便提供更有效的系统支持。

7 总结

可以通过多种方法提高系统的可用性, 每一种方法都不是独立存在的, 他们有密切的联系。只有按照本单位的实际情况来部署和实施高可用性, 将各种方法进行有机的统一, 才能做到最佳的高可用性系统。

参考文献

[1]Chris Oggcrino.高可用性网络基础[M].中国电力出版社, 2002.

[2]EvanMarcus, 汪青青.高可用性系统设计[M].清华大学出版社, 2005.

[3]王达.网管员必读—服务器与数据存储[M].电子工业出版社2005.

高可用性 篇5

1.实时迁移,

2.快速迁移,

3.移动虚拟机,

4.高可用四种功能

首先打开一个ping 192.168.0.245 –t窗口来持续不断的ping虚拟机

如图的管理工具上我们可以看到实时迁移以及快速迁移和移动虚拟机的几个选项卡

1. 测试虚拟机的实时迁移功能

实时迁移也就是将虚拟机不断线快速迁移到另一台虚拟机

我们呢可以直接在虚拟机上单击实时迁移到另一节点选项来进行迁移,因为本例只有2个节点,所以迁移到的目标那里也就只有一个节点可选,如图我们讲2k8实时迁移到C2

需要注意的是如果实验或者在生产环境中,节点的物理CPU不一样的话,需要设置虚拟机的处理器属性选项卡中的迁移到具有不同处理器版本的物理计算机,否则无法进行迁移和高可用

整个过程是联机作业的,我们从大约9:44开始作业

整个过程ping一直没断,也就是说虚拟机一直在提供服务

在9:45迁移完成,开始转换到新物理机上去运行虚拟机

经过1分左右的时间完成操作,中间只有1次闪断,如果我们的环境是千兆,也许就没这一次闪断!

看看虚拟机的状态,现在已经运行到C2这个节点上,运行正常!下面玩玩快速迁移,也就是将虚拟机快速移动到另一节点,中间会断线!

2. 快速迁移

快速迁移,也就是将虚拟机快速移动到另一节点

同样是图形化操作,将虚拟机迁移到节点C1吧

时间9:51

开始保存虚拟机状态以便迁移,中间断ping了

保存状态完成,开始向心机器恢复状态

向新节点还原状态

OK,花了2分钟时间完成完全迁移到新节点工作,这适用于虚拟机没有创建在群集共享卷才需要做这样的迁移

看看状态已经迁移回C1节点.

3. 虚拟机移动

我们测试在没有共享卷的环境中使用这个移动虚拟机功能

同样是将虚拟机挂起,然后保存状态,然后恢复到新节点C2去,开始于9:54

还在保存状态

1分钟后开始还原状态

再过1分钟移动完成,这功能跟快速迁移好像差不多

看看虚拟机状态又回到C2了

4. 测试虚拟机的高可用性HA

我们将节点C2关闭,因为当前虚拟机在节点C2上,

关机后群集侦测到C2宕机,立即将虚拟机挂起,然后跟vmware ha一样将虚拟机自动重新启动了

一直到启动完成,虚拟机这里显示联机了,但是虚拟机还在启动过程中

看这里正在重新启动虚拟机

启动完成,恢复服务,呵呵,整个过程基本上完了,如果配合scvmm2008做一个负载均衡,就跟vmware ha差不多啦,啥功能都有了,虚拟机实时迁移,高可用,负载均衡!

万国数据建立高可用云数据中心 篇6

万国数据服务有限公司副总裁孙岗表示，万国数据推出的高可用云数据中心不仅可以为用户提供数据中心常见的CPU、内存、存储、网络等IT资源的按需服务，还可以为用户带来虚拟资源池服务，由企业在类似私有云的环境中创建并管理虚拟机资源，设置网络和安全策略。

比如，通过万国数据外高桥数据中心配套的高质量BGP网络，用户IT部门可以创建可交互操作的服务交付模式和方法，从而在确保安全性和控制力的同时全面实现灵活性和云计算优势，用户甚至可以通过“混合云”模式，进一步扩展企业内部数据中心的逻辑界限，使其能够利用广阔的公有云资源服务。这些云服务既可以按小时根据使用的资源付费，也可以按照资源池以固定月租费或年费的形式付费。

与一般主打灵活和成本优势的云计算服务不同，“高可用”是万国数据云数据中心及其相关云服务的主要特点。“万国数据通过多年的服务，积累了非常多的应用云经验，自己总结了一些高可用的方法。所有的这些方法都可以在高可用服务框架下展开实施，其中云计算服务也是我们高可用服务框架下的一个服务。‘高可用’本身就代表了万国数据的核心理念。”孙岗说。

据孙岗介绍，万国数据会从多方面来保证云数据中心的高可用性：一方面，位于上海外高桥的这个高可用云数据中心构建于高等级的IT基础设施之上。比如，设有双路供电，并专门设有一个35kv的变电站来满足数据中心的供电需求，全部符合ISO 270001标准的安全体系等；另一方面，该云数据中心提供的是VMware vCloud DataCenter服务。VMware vCloud DataCenter服务是一种随时可用的企业级云计算服务，只能由经过VMware认证的服务商提供。这种严格的认证机制不仅保证了云服务本身的高可靠性，还可以确保云服务在公有云和用户基于VMware产品构建的私有云之间进行自由迁移，从而能够充分应对突发性计算的需求；第三，这次推出的云数据中心是万国数据联合软银共同建设的，此前软银已经在日本建立了类似的数据中心。类似的云数据中心和云服务都已经在日本得到了检验。

“作为企业级的高等级云服务，万国数据高可用云数据中心对于IT资源和运维等各方面都制定了严格的标准和要求。其符合国际最高等级数据中心要求的物理环境与设备、高规格的运维及支持，以及严格的安全审计规范，都将成为万国数据云数据中心云服务的重要支持资源。”孙岗总结说。

医保高可用性集群系统建设实践 篇7

关键词：医疗保险系统,单机系统,双机镜像系统

0前言

在北京市医保十几年的发展建设历程中,医保系统的各方面技术都在不断地进行调整。系统接口技术从内嵌式到外挂式的发展;硬件系统结构也从最初的单机系统升级到双机镜像系统。然而随着医院医保业务量的逐年增加,参保人员的广泛覆盖,医保门诊、住院实时结算业务的上线等诸多原因,造成了双机镜像系统在医保业务处理方面出现了瓶颈,已制约了医院医保信息化建设的发展。为此,建立医保高可用性集群系统,以提高服务器的性能及稳定性和扩展性,确保医保系统数据的安全。本文介绍了我院不同时期的医保系统硬件结构和开发技术。

1 单机系统

医保系统建设初期,采用单服务器系统,即一台医保前置机。前置机是双网卡结构,设置内外网,其IP地址分别指向医保中心分配地址和医院内部网络地址,并对NAT路由进行设定。内网卡连接医院信息系统(HIS),外网卡连接医保,同时要保证内网和外网的连通,从而保证客户端与前置机的连通,使终端用户可以随时访问医保前置机。

在前置机中安装SQL server数据库;安装上传下载程序,使前置机可以上传下载数据。

单机系统运行多年后,门诊的实时刷卡业务的实现,使得业务处理数据量不断增大,对系统稳定性的要求也越来越高。为了降低系统灾难发生所造成的损失和影响,故对系统的性能要求需重新定位,即系统应该具备容灾功能。

2.1 网络拓扑结构

2台服务器分别安装3块网卡,内网卡通过内网交换机连接到医院内网,外网卡通过路由器、光电转换器连接到医保外网,2台服务器之间通过心跳线连接实现双机镜像(图1)。

2.2 系统工作原理

通过SQL server的镜像功能,在主服务器(数据库服务器)和镜像服务器(应用层服务器)之间建立镜像关系。这2台电脑上均安装数据库和应用层,但主服务器的应用层不启用,系统在做日常业务时只调用镜像服务器上的应用层。医院每天的业务数据在写入主服务器的同时也在镜像服务器进行存储,当主服务器宕机时,可以启动镜像服务器上的镜像数据库作为主数据库,使医院业务继续进行。当镜像服务器宕机时,可以启动主服务器上应用层,业务可以照常进行。

3 高可用性集群系统的建设

大众对于中医的广泛认同及参保人员的全面覆盖,使得医保系统处理数据量的激增。几十G的数据库运转增加了服务器的网络压力,医院在上午业务量大时占用系统资源,使门诊、住院实时刷卡业务处理速度变慢,继而出现停顿及死锁的现象,情况严重时需要重启设备释放系统资源,2台医保服务器重启时间需10 min左右,增加患者排队等候时间。一系列的情况表明原有的双机镜像系统也不能满足医院医保系统的建设要求,急需建设医保高可用集群系统,以提高医保系统性能,更好地满足门诊、住院实时结算的需要,提高医保数据的安全性和读写速度。

3.1 网络拓扑结构

集群系统的硬件由2台应用服务器、2台数据库服务器及磁盘阵列组成。服务器内部通过心跳线连接,将数据存储到磁盘阵列;应用服务器通过专网交换机、路由器、光电转换器和医保光纤连接到专网。应用服务器和数据库服务器通过内网交换机连接到医院内网,数据库集群和应急服务器实时镜像实现数据交互。由这些设备共同组成的医保集群系统(图2),为医保应用系统的各终端提供程序访问和数据存储服务。

3.2 切换过程

(1)切换前停止所有医保相关业务,关闭服务器。调整原有2台服务器位置,同时将2台集群服务器与磁盘阵列机连接。通电启动所有设备,完成阵列的配置工作,建立和调试网络均衡和集群体系。

(2)2台应用服务器实现网络流量均衡功能、通过心跳线相互通讯,虚拟一个公共IP地址,加入到医院的院内局域网中,以供院内局域网的客户端访问。将医保光纤通过医院的交换机分别接入到2台应用服务器上,使服务器均能接入到医保专网,并与医保网络正常通讯。

(3)2台数据库服务器之间,通过操作系统(2003企业版)实现容错集群功能。在集群系统中部署医保业务系统,设置系统参数,使得医保业务系统能正常运转。医保应用系统的数据则统一存储到磁盘阵列中,磁盘阵列通过光纤直接连接到2台集群服务器的光纤卡上。

(4)完成集群系统与应急服务器间的数据镜像调试。当集群系统整体宕机时,在很短时间内,应急服务器可临时代替集群系统,为全院的医保结算系统提供服务,起到业务系统的应急作用。

(5)备份医保数据后,将医院医保当前数据从原数据库服务器移植到集群系统中。系统切换完成后恢复医保业务。

4 结束语

高可用性集群系统建立后,解决了高业务量处理时间出现的停顿及死锁现象,提高了处理速度。在系统稳定性方面得到了改善,而且,当其中1台服务器出现故障时,在5~10 min内系统能自动完成切换,无需人工干预,降低了风险机率,保证了医保结算业务连续性。医保系统的建设是全面的,离不开硬件环境和软件系统的支撑。硬件环境建设发展,在一定程度上又促进了医院医保信息化的发展进程。

参考文献

[1]刘堃靖,王志奇,李力.我院信息系统与医疗保险接口的实施[J].中国医疗设备,2009,24(8):64-65.

[2]徐署华,江文,李英林.基于集群的某市医保系统服务器容错方案[J].微计算机信息,2007,(30):282-283.

[3]孙树学,孙文英,李莉,等.北京市“持卡就医、实时结算”对医保定点医院的影响及对策分析[J].中国医院,2009,13(12):59-60.

[4]宫彦婷,常建国,荣文英,等.持卡就医实时结算促进医院信息化系统高度整合[J].医疗卫生装备,2010,31(8):101-102.

[5]韩晟,张铭,王锦伟,等.基于“军卫一号”的医保住院患者结算软件的设计与开发[J].中国医疗设备,2011,25(1):56-58.

[6]张暄,唐晓东.HIS与医保系统接口程序设计方案及实现[J].实用医药杂志,2009,(1):69-71.

高可用性 篇8

Forrester Research安全与风险副总裁兼研究总监Stephanie Balaouras写道:“一个随时在线、随时可用的企业的目标就是100%的服务可用性。由于某些宕机时间无法避, 对企业来说, 重要的是把态度从被动应对宕机时间转变为主动规划、完善流程和采取预防性措施。企业应该在客户急需他们的时候努力提供可用的服务。” (《Building The Always-On, Always-Available Enterprise》, 弗雷斯特研究公司, 2014年6月) 。

SUSE Linux Enterprise Server for SAPApplications包括最完整的开源集群解决方案SUSE Linux Enterprise High Availability Extension的各部分组件。SUSELinux Enterprise High Availability Extension能帮助保护企业在x86服务器上运行的任务关键型工作负载, 这已在世界各地的数据中心得到证实。

使用SUSE Linux Enterprise for SAPApplications高可用性组件, 包括新的资源代理, 客户可使SAP HANA系统复制自动化从而优化数据库的可用性, 尤其是借助SAPHANA的内存预加载功能。

高可用性 篇9

关键词：殡葬,开源软件,系统

1 中心业务系统设计方案

广州市殡葬服务中心的业务系统设计方案如图1所示, 总共分为4个层面来考虑。

在接下来的章节, 做了具体方案描述。

2 存储

使用磁盘整列, 搭建RAID5或者RAID10。利用RAID本身的特性来保证数据的完整性。在很大程度上保证不会因为单个硬盘的故障而导致的数据丢失。按照数据量的大小和 重要性, 主要有以下几种方式:

2.1 小数据量的备份

对于数据量较小, 数据的要求又相对没那么高的系统来说, 使用磁盘整列, 搭建RAID5或者RAID10, 加上定时的刻盘备份就已经可以满足要求, 同时在资金投入方面能够控制到最低。

2.2 大数据量的备份

对于大数据量的系统, 光靠刻盘备份的话工作量太大, 刻盘所花费的时间过长, 而且万一出现故障, 使用光盘进行恢复的时间也会很长。这个时候, 使用磁带机进行备份或者使用双磁盘阵列来进行互相备份是更适合的选择。双阵列备份需要做两种方式的备份:

2.2.1 同一阵列不同卷的实时备份

由于是在同一个阵列中, 所以实时备份的系统花销也在可接受的范围之内。而且在出现逻辑故障的时候能够迅速地进行恢复, 将损失的数据降到最少。

2.2.2 两个不同阵列之间的备份

由于需要花销的网络带宽太大, 所以这主要采用一种非实时备份的方式, 每天或者每过一定时间段的业务空闲时间进行。当主阵列出现不可修复的物理故障的情况下可以直接切换到从属阵列, 但是两个备份点之间的数据将会丢失。相对于单阵列情况下的数据全部丢失来说, 在遇到如此重大物理故障的情况下能够将数据的损失降到最低。

2.3 双阵列的同步写入备份

对于数据量小, 但是数据重要性非常高的系统来说, 也可以选择使用双阵列的同步写入, 同步修改的方式来保证每一条数据都有两份。保证每一条数据都不会因单个物理故障而丢失。 与此同时配合数据库本身的归档功能, 能最大程度地保证数据的安全。

3 数据库

使用支持集群的Oracle或者MySQL, postgreSQL等数据库。将数据存放在磁盘阵列中, 然后在两台或以上的服务器中配置数据库的集群。可以根据数据写入的频率和对性能的要求来设置实时同步写入或者异步的写入, 同步写入的数据实时性更高, 但是对于系统性能的影响更大一些, 如果是异步的写入则对系统的性能影响比较小, 但是极端情况下有可能造成少量的数据丢失。

更进一步的备用方案是, 在这两台主的数据库服务器之外的服务器 (最好是不同机房) 上再通过虚拟机建立与实际服务器配置相同的数据库虚拟机, 数据库存储指向同样的磁盘阵列位置。在正常情况下, 虚拟机处于暂停的状态; 当两台实体数据库服务器都出现问题导致数据库软件无法提供服务的情况下, 直接启动虚拟机接管掉实体数据库服务器集群的虚拟IP, 构造成虚拟数据库服务器集群, 接管对数据库的访问, 中间件不需要做任何的修改即可以持续地提供服务。

4 中间件

4.1 利用服务器自身的集群功能

通过Web Server自身的集群功能, 在两个Web Server之间保持同步, 从而达到两个Web Server之间的无差别访问。

4.2 利用新增的分发软件

通过在Web Server和客户端之间增加一个请求分发软件, 如Apache, Nginx等, 由这个软件来完成负载均衡。将特定的请求分发到指定的Web Server。

根据火葬场管理所业务系统的实践经验, 详细描述第2种方式如下:

第一, 使用两台中间件服务器, 每一台服务器上使用Web Server部署一个中间件应用 , 中间件服务器使用Oracle的连接串连接到Oracle的rac集群。

第二, 在每一台中间件服务器上部署一个Nginx软件。Nginx的作用主要在于接受客户端的请求 , 然后分发到Web Server, 隐藏掉真实的Web Server端口。Nginx可以根据客户端IP或者请求的链接地址等对请求进行分发。具体的分发规则可以根据实际系统情况来进行配置, 尽量达到将请求均匀的分配到不同的Web Server, 以便获得更好的性能和稳定性。Nginx还有一个非常好的功能是, 可以设置自动检测其下所配置的Web Server的状态, 如果有Web Server无法相应 (如宕机或者异常关闭), 则不会将请求分配到该异常Web Server中。对客户端屏蔽掉Web Server的错误, 只要两个Web Server中有一个能够正常工作, 便可以向客户端提供不间断的服务。

第三, 使用keepalived来保证当两台中间件服务器中的任意一台出现物理故障的时候仍然能够向客户端提供不间断的服务。keepalived的功能是使用两个 (或以上) 的keepalived程序, 一个keepalived维持一个 (或者多个) 虚拟IP, 多个keepalived之间互为备份 , 当安装keepalived的主服务器出现故障, 网络不通的时候, 作为备份的keepalived程序将接管掉keepalived主服务器的IP地址, 整个接管过程基本可以在1秒之内完成。这样即使一台中间件服务器宕机或者网络故障的时候, 另一台中间件服务器可以马上接管请求, 对客户端来说基本不会产生影响, 客户端仍然可以正常的进行业务操作, 甚至觉察不出中间件有发生任何异常。

keepalived还可以配置一个脚本来自动检测Nginx进程的状态, 当检测到Nginx进程出现异常的时候会自动对Nginx进行重新启动, 如果重启失败, 则会直接关闭该服务器上面的keepalived进程, 释放掉该服务器所持有的虚拟IP。可以有效的防止当Nginx出现故障时, 由于服务器继续持有虚拟IP, 继续接受客户端请求而导致的请求无法响应的故障。

5 客户端

5.1 使用单一 IP 地址进行负载均衡

中间件采用单一的入口IP, 每一次请求都访问同一个IP地址, 由这个IP地址的请求分发软件将请求分发到中间件的任一台服务器中进行处理; 而另一个IP的请求分发软件就只是单纯地作为备份。然后再由这个IP地址将处理结果返回。但是这个方案的缺点是单一入口, 可能导致请求和返回都集中于一个网卡上, 单一网卡负载过大。

5.2 使用 DNS (域名服务器) 进行负载均衡

配置DNS服务器, 将中间件所在的两台 (或多台) 服务器的由keepalived维持的虚拟IP绑定到同一个域名中。通过域名服务器本身的机制, 客户端对该域名进行访问请求的时候, 由域名服务器解析成所配置的IP中的一个, 从而达到负载均衡的功能。避免出现客户端集中往单一IP发送请求的状况。

5.3 对客户端的代码进行少量修改

使得客户端在启动的时候随机的选择虚拟IP中的一个, 并在之后的业务请求中一直使用该IP, 直到重新启动时再重新执行随机选取IP的过程。也可以达到将客户端的请求分散到各个IP中的目的。并且对于当前没有内部DNS服务器的情况下, 省去了新建并维护DNS服务器的工作。目前采用的是此种方案。

6 结语

经过以上针对4个层面上的配置, 可以让业务系统的可用性基本上达到7*24不间断提供服务的水平。对于出现故障的情况, 可以保证在遇到:

第一, 存储的单一磁盘损坏。

第二, 任意一台 (非全部) 数据库服务器出现数据库应用崩溃, 数据库服务器网络中断, 数据库服务器物理故障。

第三, 任意一台 (非全部) 中间件服务器出现Web Server程序崩溃, Web Server网络中断, 中间件服务器物理故障。

在非极端异常的情况下, 业务系统均能够不间断地提供服务。不会因为某一台设备的故障, 损坏而导致业务系统的中断。从而能够让业务系统连续不断地运行, 并在出现故障的情况下, 可以有充分的时间对设备进行检测维修, 而不会对业务的运行造成影响。

高可用性 篇10

SUSE全球业务 开发负责 人Naji Almahmoud表示 :“自去年 推出针对SAP HANA部署的高 可用性能 力以来 ,SUSE继续为企 业客户扩 展并提升了 这种功能。SUSE率先使用 开源高可用 性能力支 持SAP HANA,这能够帮助客户在使用自己现有SUSE基础架构创 建高可用 性SAP HANA解决方案时节省成本。运行关键工作负载的SAP系统必须满足可用性的最高标准,SUSE致力于提升SAP服务的可用性。”

通过SUSE Linux Enterprise在优化成本的前提下复制SAP HANA系统需要一台运 行非关键 系统的次 级服务器。如果初级服务器发生故障,次级服务器自动终止非关键操作并接管主要操作,将所有客户端都连接至次级服务器。多层能力支持初级数据中心和远程数据中心之间的自动非同步系统复制,引入第三个系统服务器作为额外冗余。

高可用性 篇11

“高可用性”通常用来描述一个系统经过专门的设计,从而减少停工时间,而保持其服务的高度可用性。高可用性系统要求能够不间断地对外提供服务,并且具有较高容错性。传统的“停机—更新软件版本—重启”的应用软件更新方法势必会影响系统的可用性。惠普相关专家的一项调查表明,在被调查的高可用性应用程序产生的5921次停机中,有75%是由于软硬件维护的原因造成的。

本文引入一款要求可用性达到99.999%的电信级高可用性集群系统,针对此系统提出一种有别于传统停机更新策略,并且具有强容错性、修复性的动态软件更新策略。文中将详细介绍此更新策略的实现方法。

最后总结这种动态更新方法优点,同时对此方法进一步的完善提出建议。

1高可用性集群系统

1.1系统简介

本系统主要应用于第三代移动电话服务(3G),基于AdvancedTCA这一开放的标准硬件平台,应用Linux操作系统开发。向上层应用程序提供开发接口, 同时控制和屏蔽底层硬件的复杂特性。3G系统使用户能在任何时间、任何地点与任何人连接,传递高质量的视频并提高声音的清晰度,这要求本系统为上层应用提高可靠、持续的高质量服务(如图1所示)。

1.2系统构成

本系统为满足高可用性要求,提高系统的容错性和不间断性,采用集群式机构。系统主要由文件服务器和服务组两部分组成(如图2所示),其功能如下:

文件服务器(FS) 它通过采集和分析信息,提供高可用性管理的核心服务,同时决定SBC的冗余状态。

服务组(SBC) 它运行一个或几个服务,协作完成系统服务。

无论文件服务器还是服务组均有两个对等的节点(node)组成一个簇(cluster),采用主从方式(非对称方式)的结构。一个节点为活动(active)单元,另一个节点为备份(standby)单元。活动单元主机工作时,备份单元主机处于监控准备状态。当活动单元主机宕机时,系统可以把IP、客户业务等资源切换到备份单元,备份单元主机接管活动单元的一切工作,待活动单元主机恢复正常后,按使用者的设定以自动或手动方式将服务切换到指定的主机上运行。数据的一致性通过共享存储系统解决。

这种集群式结构使整个系统能连续不间断地对外提供服务,从而为机构的关键业务提供24×365的可靠保障,满足了系统高可用性和可靠性的要求。

2更新系统设计

2.1动态更新策略构想

要保证系统的高可用性,需要实现不停机的更新,并且在更新出错的时候可以及时停止更新,恢复系统。根据上文描述的高可用性集群系统特点,更新的主要步骤设计如下(如图3所示):

(1) 更新包传送文件服务器的活动单元主机(简称主文件服务器) 因为集群簇中每个服务组提供的上层服务不同,因此更新包中除了需要有标识更新版本号的配置文件,还需要标识更新文件与服务组关系的更新配置文件。更新包将从共享存储设备,传送至主文件服务器的默认目录下。

(2) 更新文件传送至对应服务主机 根据更新包中的配置文件于更新文件名,主文件服务器将通过ftp,传送更新文件到每个服务节点的指定目录下。为保证更新后的一致性,服务组的活动单元与备份单元均要接收更新文件到默认目录下。

(3) 文件更新开始 监测各个服务组中主机状态是否正常,备份系统核心文件,将服务组中备份单元设置为更新准备状态。

(4) 备份单元主机文件更新 备份单元根据更新配置文件,更新系统。此时服务组中的活动单元主机正常提供系统服务,保证服务不间断。

(5) 更新文件启动测试 备份单元主机更新完成后通过服务重启,检测更新后备份单元主机是否能够正常提供服务。

(6) 更新文件开始工作 文件服务器和服务组中的活动单元与备份单元进行状态转换。更新后的备份单元转换为活动单元接管服务工作。

(7) 文件更新完成 当前所有备份单元进行文件更新,并且在此过程中系统运行状况良好,文件更新完成。

以上更新过程中的文件传输均采用FTP协议,通过在文件服务器端配置FTP 服务器来实现。在更新的(1)-(6)步骤中,若更新出现异常,系统可以利用共享存储设备上的备份恢复系统。

2.2动态更新详细流程

按照2.1节提出的更新策略,设计实现更新的整个流程如图4所示。

在整个更新流程中,主要更新步骤的详细设计如下:

文件更新前需要进行确认 主要的确认点包括:监测更新包是否放入共享存储设备指定目录下;主文件服务器上是否有足够的磁盘空间进行更新;查看系统状态是否正常。

ftp_fup 为保障系统安全,需要在ftp协议相关的配置文件中,设置正确的用户名和密码。

load_fup 首先更新包在主文件服务器的默认更新目录下解压。然后主文件服务器根据更新包中的配置文件和更新文件名,将更新文件传送到相应的服务组主机。

str_fup 文件更新开始,将文件服务器(FS)和服务组(SBC)中活动单元主机的核心文件备份至共享存储设备。所有备份单元断开与系统应用连接,状态设置为准备更新状态。

sby_fup 每个服务组中备份单元,进行文件更新。更新完成后,为保障系统正常运行不被影响,备份单元依然保持与系统断开连接。

sby_fup tst 所有备份单元通过服务重新启动,测试更新文件是否能够完成服务系统正常启动要求。同时主文件服务器监测备份单元的启动状态,及时发现异常,终止更新。

act_fup 所有的活动单元和备份单元进行状态转换。原备份单元接管管理和服务工作。数据一致性,由备份单元按照系统配置的时间间隔,和活动单元通过共享存储设备完成系统状态通信,信息共享来保证。

服务器监视系统状态 当前主文件服务器,监测系统服务运行状态,主要监测更新后的系统服务组是否正确提供系统服务。具体监测时间根据系统服务规模进行设定。

all_fup end 当前所有备份单元进行文件更新。更新完成后,进行服务启动测试。如果所有服务组中备份单元均可成功启动,系统正确更新到指定版本,此次文件更新结束。

在load_fup,str_fup,sby_fup,sby_fup tst,act_fup,all_fup end等更新阶段,如果发生更新异常终止,需要应用系统命令和共享存储设备上的备份文件恢复系统。

3测试和结果

计算机系统的高可用性定义为系统保持正常运行时间的百分比:

MTTF/(MTTF+MTTR) × 100%

式中,MTTF是平均无故障时间,表示系统的可靠性;MTTR是平均维修时间,表示系统的可维护性。可见要获得更高的可用性,减少MTTR是一种实用可行的途径。上文中设计的动态更新策略,实现了不停机更新,更新过程占用的时间,就是减少的MTTR。

另外根据正常的升级更新;各版本间随机更新;更新异常系统自动恢复这三种情况,设计测试矩阵,测试基于此动态更新方法,一个由一组文件服务器,四组服务组组成的高可用性集群系统的更新情况。测试具体方案及结果如表1所示。

从测试结果看出:更新包越大,相应的更新时间就越长,相对传统的停机更新模式节省的时间也越长;另外在随机更新回退到前一版本和更新异常的实验中,都得到了正确的更新结果,验证了此更新策略具有高的可适性和可靠性,能满足高可用性集群系统的更新需求。

4结语

随着信息化建设的不断推进,对于电信、金融、航空等数据业务需求量大的领域,高可用性业务系统的依赖越来越多。本文基于一款高可用性集群系统,设计出在系统服务不中断的情况下,实现系统的动态更新方法,保证了系统的可用性、可扩展性和运行性能。下一步的研究重点是:如何实现更新文件同时向多个服务组主机传送,更好地提高更新效率。通过进一步完善该更新策略,可使其灵活应用到更多的高可用性集群系统中。

参考文献

[1]Minoru Etoh.下一代移动系统:3G/B3G[M].北京:机械工业出版社,2007.

[2]Heimann D I,Mittal N,Trivedi K S.Availability and Reliability Model-ing for Computer Systems[J].Advances in Computers,1990,31:175-233.

[3]Dolev D,Malki D.The transis approach to high availability cluster com-munication[J].Communications of the ACM,1996.

[4]Plasil F,Balek D,Janecek R.SOFA/DCUP:Architecture for Compo-nent Trading and Dynamic Updating[C]//Proceedings of ICCDSp98.Annapolis,Maryland,USA,IEEE CS Press,1998.

[5]Neamtiu I,Hicks M,Stoyle G,et al.Practical Dynamic Software Upda-ting for C[C]//Proc.of the 2006 PLDI Conference.Ottawa,Canada:[s.n.],2006:72-83.