系统可用性论文

系统可用性论文（精选12篇）

系统可用性论文 篇1

随着网络技术的发展, 各单位的应用越来越丰富, 也越来越复杂, 他们对计算机系统的依赖性不断增强。应用的后台核心领域是否具有保护业务关键数据和维持应用程序的高可用性的能力已经成为影响工作的关键因素, 人们不仅希望保障关键业务数据信息的完整, 而且希望联机应用能够不间断或在最短时间内恢复, 这就是所谓的计算机系统的高可靠性、高可用性问题[1]。应用系统不能因为自然灾害、设备故障或人为因素等原因引起计算机系统停顿、数据丢失, 导致业务处理的长时间中断, 因为这将会造成巨大的经济损失和声誉损害。本文旨在讨论影响系统高可靠性、高可用性的因素, 寻找较佳的高可用性系统建设方案。

所谓数据高可用性是指确保网络数据不受各种因素侵扰、网络数据实时可用的技术, 主要包括群集技术、防火墙技术、入侵检测技术、网络防毒技术、数据备份技术、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.

[4]蒋谢彬, 李献球.高可用系统的技术与应用[J].计算机系统应用2003 (1) :31-33.

系统可用性论文 篇2

随着LMDS技术的成熟和商用化进程的加快，LMDS网络作为电信级系统的一些问题就凸现出来。可用性是其中的关键因素。深入分析LMDS系统的可用性，对运营商而言具有非同寻常的意义。

LMDS（26GHz）系统自19开始进入中国市场，历经两年多的技术试验阶段后，终于完成了行业标准和频率规划的制订，并于开始进入商用试验阶段。目前，信息产业部电信管理局已批准中国移动、中国联通、中国电信和中国网通四个运营商开展26GHzLMDS接入网业务的运营许可，26GHzLMDS系统的商业应用即将拉开序幕。

26GHz频段频谱资源丰富，按FDD双工方式规划的LMDS工作频率范围为24450MHz～27000MHz，其中，可用带宽为：1008MHz×2，可采用的波道配置有4种方案，其基本信道间隔为3.5MHz、7MHz、14MHz和28MHz。工作在26GHz的LMDS系统相对低频段无线接入系统而言，自然其接入带宽大是其重要的特点，系统的主流技术均是以支持综合业务接入为设计目标的。当前，LMDS系统空中接口协议没有也难以形成统一的标准，设计者从不同的视角和性能价格比的权衡中设计了各具差异性的LMDS产品，在一定程度上给运营商的技术选择带来些困惑。实际上选择本身就是一种权衡的过程，任何事物都有一定的两面性，从单一视角看问题往往是片面的，本文针对LMDS系统的几个热点问题开展分析以供参考。

影响LMDS系统可用性的因素包括设备的可靠性（取决于设备的质量和所提供的冗余度）、为LMDS系统供电的外部电源系统的可靠性、反常传播（净空衰落和降水）、维护组织的有效性、由人为干扰引起的意外中断及其他干扰。在评估系统可用性时，设备可靠性和反常传播是主要的关注因素。

设备对系统不可用性的影响

设备的可靠性通常用“平均故障间隔时间”MTBF来表征，在评估设备对系统不可用性影响时，还须考虑维护组织的有效性及设备的可维护性水平，他们决定了当系统出现故障时所需的平均修复时间（用MTTR表征）的长短，以大唐无线通信公司的R3000LMDS系统为例，说明由于设备特性所引入的不可用性指标如下：MTBF＝20万小时；MTTR＝2小时（因LMDS系统应用于城市环境，交通方便，基站各部件可热插拔，CPE按模块化设计，网管系统完善）则设备的不可用性＝〖100－（MTBF×100/MTBF＋MTTR）〗×100％＝0.1％。

在R3000LMDS系统中，基站是有冗余设计的（主控板、ATM复用板、电源系统、调制单元、上下变频单元及ODU均可按1＋1或N＋1冗余配置）。但在所有点对多点的LMDS系统产品中，这些冗余设计均是有损伤切换的，对可用性的改善度主要体现在MTTR中，冗余对外部馈电系统故障及雨衰中断不起任何作用。

反常传播对可用性的影响

反常传播主要包括阻挡衰落、多径衰落、降雨衰减等。

DDD阻挡衰落：阻挡衰落是指由于电波传播路径不满足余隙标准而带来的附加衰减，在LMDS系统应用环境下，造成余隙不够的主要因素是建筑物阻挡，例如：在26GHz频段，2km路径按0.6F1（F1：第一菲涅尔区半径）设计，在路径中点的余隙应大于或等于2.4米，这个余隙标准不仅针对从建筑物顶部电波穿越时要得到保证，而且包括从建筑物边缘（楼间）穿越时也应有足够的余隙，

当余隙小于0.6F1时将出现阻挡衰减，衰减的大小取决于余隙的尺寸和阻挡物的物理形状，阻挡衰减势必使衰落储备降低。虽然在LMDS系统应用中由于空中传输距离较小，平衰落引起的中断问题可以不予考虑，但衰落储备的降低必定使降雨带来的不可用性指标恶化，在LMDS系统传输设计和工程实施中应引起足够重视。

DDD多径衰落。由于工作在26GHz的LMDS系统大多是在城市环境中应用，传输距离短，建筑物对26GHz频率的信号反射衰减较大（约20dB以上），因此，多径引起的衰落现象对不可用性指标带来的影响很小，可以不予考虑。

DDD降雨衰减：由于LMDS系统工作在26GHz频段，其波长与雨滴尺寸相近，因此，由于降雨对电波引起的吸引和散射将使信号经受衰减，这种衰减呈现非选择性能和缓慢的时变特性，是导致信号劣化，影响系统可用性的主要因素。国际电信联盟对降雨的影响已进行了深入研究，在ITU－RP.837建议中，将地球分为15个降雨气候区，分别以大写字母A到Q来表示，每一降雨区是以与它相关的降雨强度统计来表征，并给出了对应不同降雨强度所发生的时间概率。遵照ITU－RP.838建议，可以针对工作频率、极化和降雨率计算比衰减（dB/km）和有效路径长度（这是考虑到在整个传输段长度上降雨强度不是均匀分布的缘故），进而可以针对衰落储备值Ft计算出在一定传输距离下，降雨衰减超出Ft的时间百分数P，或反之，根据雨衰特性及Ft求出在保证P值一定的情况下可用的通信距离是多少。必要时，还可以根据在ITU－RP.841建议，从长期百分数P变换到最坏月份百分数Pu。在考虑LMDS因雨衰引起的不可用性指标时，时间百分数P即为不可用性指标。

关于LMDS系统不可用性分析

由上述分析可以看出，LMDS系统的不可用性主要是降雨引起的，在26GHz频段不能简单地因雨衰的影响就作出使用LMDS系统将面临极大运营风险的结论，下面几点分析可供参考。

DDD根据ITU－R提供的雨区分布图，我国雨衰较大的地区主要集中在广东、广西、福建、浙江等沿海地区，其他大部分地区因降雨引起的不可用性是可以承受的。如果保证可用性指标达到99.99％，在北方及中西部地区通信距离可达到2km～5km，在南方多雨地区可达到0.5km～2km，如果可用性指标降低到99.9％，达到中等质量的应用水平，LMDS系统覆盖范围还可进一步得到改善。

DD保证足够的衰落储备是提高可用性的重要条件之一。决定衰落储备大小的主要因素有最大发信功率、收发天线增益、接收机的门限电平（BER＝10－3

）及空间传输损耗等，前三项因素是由所选择设备的固有特性决定的，但在发信功率、接收门限一定条件下尽量选择高增益天线是有益的。空间传输损耗除自由空间传输损耗外，应尽量通过设计和施工确保不再增加阻挡衰减的成分，在同一地区，选择不同厂家的设备，以及不同的工程服务支持能力，在相同的距离上将会有不同的可用性指标出现，这是值得使用LMDS系统的运营商注意的一个问题。

DDDATPC（自动发信功率控制）。ATPC技术本身主要是为了解决系统间干扰及雨衰两个互相矛盾的问题而设计的。LMDS系统是点对多点通信系统，在一个扇区内，不同的用户终端与基站距离不同，在同一基站范围内最好的设计是所有扇区及一个扇区内的所有远端站达到基站接收机的收信电平相近，这样可减少扇区之间或同一扇区由不同远端站引入的相互干扰，因此需要系统具备ATPC功能，而在考虑同城域不同基站之间的干扰时，希望各基站在保证必要的误码特性条件下（BER＝10－9），尽量降低发信功率，那么，这势必使每段电路的衰落储备降低，在出现一般降雨时，不可用性指标就已开始劣化。因此，兼顾雨衰而引起的不可用性，在系统设计时采用了AT?PC技术，随着雨衰的增加和误码性能的恶化，系统自动调整发信功率，直到最大发信功率为止，从而解决了前面所提到的问题。由于雨衰而导致的不可用性是由最大发信功率决定的，因此ATPC并不会对系统可用性指标带来改善。

OA办公系统实用性 篇3

关键词：OA系统核心应用 功能 性能 办公自动化

OA系统主要是为了政府机关以及事业单位的办公信息上下传达以及信息采集等服务的，能够将政府机关各个部门以及下属单位之间通过信息系统联系在一起，实现了党政机关单位的日常办公的信息化，规范化，标准化。

首先对于一家应用单位来说如何选择适合的OA系统是个主要问题， 选择OA系统时都应该遵循一个原则，那就是只选对的，不选贵的，适合本企业应用所需，不然什么都免谈，产品不仅具有传统OA软件的核心应用：文档管理、信息发布等功能，还提供了工作流等代表数字化办公发展方向的功能模块。在功能设置上不是追大求全，没有任何“花架子”模块，而是关注核心应用，使得用户的软件投资花到刀刃上。专业版和高级版不限制用户数，使得用户的应用规模不因价格因素而受到限制，同时，随软件免费赠送一定时间的服务与升级。软件价位充分考虑中国国情，通过内部研发与营销模式的优化改良，降低了运营成本，而不是将过高的自身成本转嫁给用户。软件实施、应用、购买成本低就是给用户省钱，面对越来越务实的企业与政府采购，低价优质顺应民心。

1 选择OA办公系统时应当注意的方面

1.1 首先在选择办公系统的时候，需要查看所选的OA办公系统能不能满足所要求的功能，如果不支持即时通讯的功能，那么，可以说这个系统对企业是毫无用处的，不仅无法帮助企业，还可能会造成企业的损失。采用先进的B/S结构，客户端简单便捷，运行的速度快，无论是在公司，还是在家里还是出门在外，这个系统都能够满足工作的需求。如果采用的服务器是公网IP的话，那么就能够通过路由器从外界访问，不需要任何其他的设置，就能够实现办公的信息化。在未来，也许OA还能够支持移动手机，那时候，就能够真正的随时随地办公了。

1.2 OA系统的易用性应非常强。系统最好采用简单便捷的，不用安装或者采用傻瓜式的安装，能够让用户非常方便的设置访问权限以及工作流。要发挥软件性能的优势，使得多台电脑能够组合成一套高性能的集群，并实现企业信息化。

1.3 OA系统的性价比要高，企业客户案例要多，服务支持要好。OA系统的稳定性很重要，因为大量企业信息资料存入其中，OA系统的不稳定造成资料丢失会对企业造成大的损失，无法弥补。因此要对数据进行集中的控制，避免数据的意外泄露。

1.4 OA系统的扩展性也要非常的强，最好采用积木式结构，可以按需选配，自由组合想要的功能，或者可以二次开发，提供第三方接口，这样也便于管理和查找疏漏。

如今，大部分组织内部人员年龄跨度较大，众口难调，只有易用性高的OA办公系统才能获得用户的一致青睐。而OA办公系统的严密性和健壮性是衡量软件优劣的重要指标，也是反映OA软件厂商实力差距的重要方面。此外，不实用的OA办公系统，无论看起来功能多丰富，性价比多高，都可能造成与企业和行业发展的不配套，无法达到提升效率的目的。

2 OA办公系统应具备的性能

2.1 开放性：把整合用到极致，从技术上看，万户OA采用整合性强的技术架构（J2EE）作为底层设计对软件的整合性会有决定性的帮助。如此，软件就能预留大量接口，为整合其他系统提供充分的技术保障。

2.2 易用性：学软件有难度，但上网人人都会。OA是目前国内唯一一款能真正做到彻底网络风格化的协同软件，平台从整体到细节，彻底坚持网络风格，甚至能实现与外网的全面打通，从而，让软件应用变得像上网一样简单。

2.3 健壮性：没有并发数上限的平台坚持网络风格是最大限度提升软件健壮性的一种有效手段，这样一来，决定应用并发数的并不是软件平台本身，而是硬件和网络速度；也就是说，从理论上讲， OA这样的软件平台没有严格的并发数限制。

2.4 严密性：“用户、角色、权限”三维管控还不够企业，尤其是集团型企业，从制度落地的现实需求来看，一方面必须有统一的信息平台，另一方面，又必须给各个子公司部门相对独立的信息空间。所以，OA办公系统不仅要实现“用户、角色和权限”上的三维管控，还必须同时实现信息数据上的大集中与小独立的和谐统一，也就是必须实现“用户、角色、权限+数据”的四维管控，具备全面的门户功能。而万户OA平台的权限分配就能成功实现严密的分级设置模式，彻底实现真正的门户应用。

2.5 逐级化：包括职级门户，如集团-公司-部门三级办公门户，各办公门户的入口统一但相对独立，需要协作的信息和流程也可以互联互通。还包括内外部门户统一，如OA（内部门户）和网站（外部门户）信息的整合。

2.6 平台化：提供一个易用、开放的协同应用平台，客户自己可以便捷的搭建个性化的功能模块，并轻松实现系统内部和外部流程、数据、人员、权限的整合，而无需编码，或只需极少量编码。

2.7 移动化：未来的OA系统在PC上操作的时间将

越来越少，人们将更多的使用手机等移动终端来操作OA，包括收发消息、审批文件、上传下载、安排日程等，OA系统在手机上的兼容性正在不断成熟。

2.8 业务化：OA系统将不再是一个纯粹用于行政办公的通用性软件，而是越来越多的和客户的业务管理相结合，结合的载体在于流程管理和任务管理，但OA不会像ERP那样管理具体的业务数据，还是侧重于业务协作过程管理。可能还有人想到了云化、流程化、智能化、知识化等这样的概念。

办公的信息化是一个不断发展，不断向前的过程，伴随着信息技术的发展，办公的信息化可以分为以下几个发展阶段：网络办公的智能化使得办公的工作变得越来越轻松和便捷；电脑化办公使得单位储存文件，保存数据以及一些软件的应用更加方便；网络的程序化在办公的网络化的基础上，能够实现对整个网络的全面有序管理。总之，办公自动化的应用和发展，使得企业节约办公时间，提高了办事效率。本文中提到的OA系统正是将以上这些阶段全部都串联了起来，发挥了各个阶段的作用，为企业提供了最便捷的服务。

参考文献：

[1]孙敏.办公自动化[M].北京：理工大学出版社，2010.4.1.

[2]王宇翔.计算机办公自动化应用基础教程[M].北京：西北工业大学出版社，2008.1.1.

[3]栾跃.软件开发项目管理[M].上海：上海交通大学出版社，2005.8.1.

海量存储系统高可用性研究 篇4

由于传统互联网业务、网络多媒体以及新兴的网络存储、网络游戏、物联网等高速发展,人类对数据的需求飞速增长。就医药行业而言,医疗影像数据以每年15%-20%的速度增长,未来10-15年,影像数据将达到PB级。随着数据需求的持续高速发展,PB级存储服务迫在眉睫[6,7]。

几乎所有应用都需要集群提供不间断的服务,集群的高可用性指不论在主动备份、系统升级、维修、配置更改,还是在被动的硬件出错、断电、网络失败等情况下,集群都能够持续提供服务,或使宕机时间减至最少。

本文针对现有的海量存储系统架构,设计了与之适应的高可用性保障方案,并对方案进行了详细的描述。此时表明,此方案能够满足现有集群系统服务的高可用性。

1 海量存储系统

海量存储系统,如图1所示,主要由数据服务器群、应用服务器群和前后端高性能网络组成[6]。

应用服务器群:提供邮件、存储、视音频等服务,单个服务器可以提供一种服务,也可以提供多种服务,服务期间服务可相互交叠。

数据服务器群:包括管理节点服务器(元数据服务器)与数据节点服务器。管理服务器保存元数据,即对象数据地址信息、控制信息、命名空间等;对象数据节点存储数据对象,对象服务器之间通过后端网络进行数据协同。

应用服务器接通过前端网络向数据服务器管理节点请求数据存储信息;通过地址信息,应用服务器从对象数据服务器读数据或向对象服务器写入信息;数据节点间通过后端网络同步数据,相互监测和通信。

2 高可用性

2.1 高可用性方案设计

传统集群系统高可用方案包括了[2,3]:

主从方式:主服务器提供服务,备服务器监测主服务器状态,一旦主服务器由于升级、断电等原因宕机,备服务器接管服务。

对称方式:两台服务器互相监测对方状态,一旦其中一台 出现故障,另一台服务器接管工作。

多机互备方式:每台服务器提供多种服务,多台服务器服务互相交叉,服务器之间相互监测协调;当一台服务器宕机时,其他服务器监测到,立即启动相应服务。

针对现有海量存储系统的架构,以及服务器的特征,设计了与之适应的高可用性保障方案:

(1) 管理节点服务器可用性方案

管理服务器一方面存储元数据,以提供应用服务器寻找数据的路径,一方面管理数据节点。由于管理节点一般是由一台服务器构成,所以对于管理服务器的可用性保障采取主从方式实现。当主机宕机时,备机接管服务,直到主机重新恢复。管理节点活动服务器与备用服务器之间通过后端网络保持数据协同。

(2) 数据节点服务器可用性方案

为了降低成本,提高数据节点服务器的利用率,同时也为了保证数据的安全,节点数据通常存储多个数据副本在不同数据节点服务器上。针对这个特性,在数据服务器群中,采用多机互备的方式来保障其高可用性。数据服务器之间通过后端网络同步数据。

例如数据D1存储与节点N1,D1在N2、N3节点上分别有副本D2、D3、N2,N3则成为D1数据的备用服务器,当节点N1宕机时,N2或者N3取代N1提供数据D1的服务。

2.2 高可用性方案实现

方案实现采用的海量存储系统平台基于GFS文件系统,服务器之间的心跳通信通过开源软件Heartbeat实现,并由开源软件Pacemaker进行集群资源管理。实现方案的逻辑视图如图2所示。

下面通过对软件的介绍来描述方案的实现机制。

Heartbeat[4]

Heartbeat是一个通信进程,服务器通过它发送心跳信号,来检测其他伙伴的状态,以及保持通信。Heartbeat具体包括几个模块:

通信模块:通过单播、多播、组播等方式向其他服务器发送或接受信息、查询状态等。

集群协同模块:保证了集群中各服务器能够平等协调的通信。

进程间通信库:定义了一系列进程间通信函数,通过查询方式无障碍地访问伙伴进程。

无障碍日志模块:具有很高的优先级,可以无障碍地进入系统日志记录Heartbeat日志信息。

Pacemaker[5]

为了提供友好的用户性,Heartbeat需要与集群资源管理软件配合,来停止打开服务。Pacemaker是支持Heartbeat的可扩展集群管理软件。通过Heartbeat监测节点状态,Pacemaker可以适时打开或关闭服务,并通过Heartbeat对集群状态的日记记录,调整服务在集群上的位置,改善集群的可用性。

GFS[1]

GFS(Google File system)是谷歌公司开发的开源分布式文件系统,为数据密集型服务、应用提供高效、高可靠的数据服务。GFS能够使集群像读写本地文件系统一样,读写集群共享的数据阵列。

GFS集群架构包括一个Master服务器和多个Chunk服务器,被Client端访问。Master维护元数据,即对象数据的命名空间,地址信息,控制信息等。Chunk服务器负责对象数据的存储,不同Chunk服务器之间通过后端网络保持数据协同。

3 方案测试和结果

实验环境构成包括主备用管理服务器各一台,配置信息如表1所示;数据节点服务器3台,互备配置信息如表1所示;应用服务器一台,配置信息如表2所示。

应用服务器以50ms的间隔时间不断向管理服务器发送数据请求,数据服务器返回5k数据包,同时分别中断主管理服务器网络、数据节点1网络,在应用服务器端测量中断前后接收到数据的间隔时间,即测量服务恢复时间,测试结果见表3。

测试结果表明不论管理服务器或者数据节点服务器的中断,回复时间都维持在5s-6s,由于设定服务器请求为50ms,相对5s-6s的中断时间,可以忽略,因而方案基本满足存储系统数据服务的可用性。

4 结 语

随着数字图书馆、电子商务、多媒体传输等应用的不断发展,对存储系统的规模及可用性提出了更高的要求,高可用性的研究对于海量存储系统的服务性能提升起到重要作用。本文针对海量存储系统提出了一种与之适应的高可用性保障方案,并对其进行了验证,结果表明方案能够满足其高可用性需求。下一步研究重点集中在对高可用方案的改善,以使服务器恢复时间更短。

摘要：对海量存储系统架构进行介绍和分析,对传统集群高可用方案进行介绍,提出针对海量存储系统架构的高可用性保障方案,并对方案进行测试。测试结果表明,当服务器宕机后,系统能够在极短的时间里恢复服务。所设计的方案可以满足海量存储系统的高可用性需求。

关键词：海量存储,高可用性,集群

参考文献

[1]Ghemmawat S,Gobioff H,Leung Shuntak.The Google file system[C]//Proceedings of nineteenth ACM symposium on Operating system princi-ples,2003.

[2]Blake C,Rodrigues R.High availability,scalable storage,dynamic peer net-works:pick two[C]//Proceedings of the9 th conference on Hot Topics in Operating Systems,USENIX2003.

[3]Wayne R.High availability becoming highly necessary[J].AS/400 Systems Management,1997,25(11):24.

[4]The Linux-ha user’s guide[M/OL].http://www.linux-ha.org/doc/users-guide/users-guide.html.

[5]Pacemaker1.1configuration explained[M/OL].http://www.clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Pacemaker_Explained/index.ht-ml.

[6]金崇英,李小勇,白英彩.海量存储系统的发展与展望[J].计算机应用与软件,2011,28(8):193-195.

[7]白英彩,金崇英.海量存储系统的研究与应用[J].软件产业与工程,2010(5).

[8]Bower K D,Juels A,Operea A.HAIL:a high-availability and integrity layer for cloud storage[C]//Proceedings of the16 th ACM conference on Computer and communication security,2009.

[9]Ahluwalia K S,Jain A.High availability design patten[C]//Proceed-ings of the2006conference on pattern languages of programs,2006.

污染源在线监测系统的适用性检测 篇5

污染源在线监测系统的适用性检测

文章概述了国内污染源在线监测系统的安装现状、管理现状及检测依据;介绍了目前国内环境监测仪器的`认证程序,基本要求及适用性检测的仪器类型.

作 者：滕恩江 杨凯 TENG En-jiang YANG Kai 作者单位：中国环境监测总站,北京,100012刊 名：中国环保产业英文刊名：CHINA ENVIRONMENTAL PROTECTION INDUSTRY年，卷(期)：2008“”(1)分类号：X84关键词：在线监测 适用性检测 认证

系统可用性论文 篇6

摘要：目的评价危重病人严重度分类系统（Critical Patient Severity Classification System，CPSCS) 对入住重症监护病房后1～6个月脑外伤病人预测死亡率、功能性残疾、认知能力的实用性。方法200例脑外伤病人纳入研究，主要终点测验为入住重症监护病房后1~6个月的死亡率、功能性残疾、认知能力评价。结果应用CPSCS分辨生存和死亡的机率分别为77.5%和81.3%，但是在预测脑外伤病人功能性和认知康复可靠性低。结论研究结果表明，CPSCS可用于预测脑外伤病人死亡率，对于功能性和认知结局预测价值有限。

关键词:脑外伤；重症监护病房；护理；危重病人严重度分类系统

中图分类号:R-3文献标识码:A文章编号:1004-4949(2013)05-0163-03 危重病人严重度分类系统（ Critical Patient Severity Classification System，CPSCS) 最初用于疾病严重度分层，后来将其用于预测病人的预后，特别是对死亡率的预测［1］。 疾病严重度分类系统可提供改善病人处理及入住重症监护病房（ICU）的标准的建立。此外，分类系统也可作为比较治疗和护理管理在不同医院和科室的差异［2］。疾病严重度评估的工具有多种，急性生理、年龄、慢性健康评估（Acute Physiology, Age, and Chronic Health Evaluation ，APACHE), 治疗干预评分系统（Therapeutic Intervention Scoring System ，TISS), 疾病评分（Sickness Score）, 多器官衰竭（Multiple Organ Failure ，(MOF) 在临床上使用广泛［3-5］。上述3种评分系统由于可靠性能和效能高而应用广泛，但是也存在某些限制：①需要大量的生理学测验；②费时；③不适用于病人治疗和ICU护理效率评价［6］。就护理方面来说，病人分类的一个最主要的目的是有效地分配护理资源［7］。ICU护理资源的合理分配应该根据ICU疾病分类系统确定［8］。危重病人严重度分类系统（Critical Patient Severity Classification System，CPSCS), 可用于评估护理工作的需求而优先补充［9］。CPSCS 是公认护理管理的实用工具。为了拓展CPSCS的临床用途，本研究试图将其用于脑外伤病人预后的预测。ICU的病人最重要的预后是死亡率，尤其是重症脑外伤病人［10］。此外，脑外伤病人生存者残疾出院存在不同程度的生活障碍， 对于功能性、认知和社会康复的预测与死亡率预测一样重要。

1资料和方法

研究设计和对象：

本研究采取前瞻性预测研究设计。研究对象为200例入住本院ICU的脑外伤病人。

资料采集方法：

所有研究对象在入住ICU3d应用CPSCS 评估。预后变量包括死亡率、功能残疾、认知能力，分别与入住ICU后1和6个月评估。 6个月前出院病人评价的资料采集通过随访获得。

指标 ：

CPSCS 由8个方面组成：生命体征测验、监护、日常生活能力（ADL）、饮食、静脉治疗和药物、处理和操作、呼吸道管理、教育和情感支持。8大项 分别由9~22条组成，根据护理需要、难度、时间等进行评分（表1）。根据总分，病人分6类（分值越高疾病越严重）：0～13分，14～32分，33～65分，66～98分，99～150分，>151分。

表1危重病人严重度分类系统（CPSCS）

项目内容生命体征（TPR，BP）（1）生命体征≤4次/d（2）生命体征4h1次或6次/d（3）生命体征3h1次或8次/d（4）生命体征2h1次或12次/d（8）生命体征1h1次或24次/d（2）肛或腋温≥4次/d（2）检查脉搏≥6次/d（2）倾斜试验≥6次/d（6）术后、产后、新生儿体征监护（2）出入量8h或×3（4）出入量4h或×6（8）出入量2h或×12（16）出入量1h或×24（2）循环或基础检查2h或×12（3）神经检查4h或×6（6）神经检查2h或×12（12）神经检查1h或×24（2）CVP/ICP/LAP2h或×12（4）CVP/ICP/LAP1h或×24（6）心脏/呼吸/体温/血压监护（6）经皮监护（4）动脉或ICP或导管监护（2）动脉或ICP读数2h或×12（4）PAP/PCWP/RVP读数2h或×12（2）心输出量3次/d或×3呼吸道管理（2）氧疗（2）刺激咳嗽或深吸气4h1次（2）IPPB或雾化2次/d或×2（4）IPPB或雾化6h1次或×4（6）IPPB或雾化4h1次或×6（8）氧气帐（Crop tent or mist tent）（2）胸部物理治疗2次/d或×2（4）胸部物理治疗6h1次或×4（6）胸部物理治疗4h1次或×6（2）吸引4h1次或×6（4）吸引2h1次或×12（8）吸引1h1次或×24（16）吸引30min1次（10）呼吸机（4）气管切开护理×3（48h后）（6）气管切开护理×3（48h前）日常生活（6）婴幼儿护理（<5岁）（2）自我/轻微护理（>5岁）（6）帮助（>5岁）、自动体位（14）完全依赖（>5岁），辅助体位（18）整体护理（<5岁），体位和皮肤护理（32）整体护理（<5岁），体位和皮肤护理2h1次（4）临时体位变化或轮班擦洗（14）转身架（每次2人，每2h1次）（8）儿科休养或观察饮食（5）管饲（团注）4h1次或×6（8）管饲（团注）3h1次或×8（10）管饲（团注）2h1次或×12（2）连续管饲，每袋一换（6）>5岁，经口进食，喂食×3（10）<5岁，经口进食，喂食×3（2）婴/新生儿，奶瓶×1（12）婴/新生儿，4h1次或×6（18）婴/新生儿，3h1次或×8（24）婴/新生儿，2h1次或×12静脉治疗或药物（4）KVO（每天2瓶以下）（4）肝素封管（6）简单（每天更换液体瓶3或4次）（8）复杂（部位≥2，多通道，4h更换液体瓶）（2）IV给药，8h或×3（3）IV给药，6h或×4（4）IV给药，4h或×6（2）血制品（每次）（2）除IV外，每3h给药或×8（4）除IV外，每2h给药治疗，操作（2）静脉穿刺、导尿、心电图（2）手术准备或灌肠（2）实验室检查×6，血培养×3（2）简单管道管理，尿管管理（2）冲洗，滴注≤4次/d（2）光疗（2）约束（2）辅助下床到躺椅×3（2）辅助下床行走返回×1（2）陪伴病人离开病房>15min，<30min（2）其他活动 >1min，<30min（2）复杂隔离>30min ，<1h（4）胸部置管，腰穿（4）胸腔穿刺、腹腔穿刺、心包穿刺（4）导管置入×4（4）复杂的着装(>30min)（4）运动锻炼×3（4）陪伴病人离开病房>30min（4）其他活动>30min，<1h；特殊操作>1，<4h（8）需要护士持续护理的其他活动或Q1h（12）新入院（4）转移（室内）教育和情感支持教育（2）分组教育（4）术前教育（4）特殊教育（分病种教育）情感支持(>30min /24 h) 10 = 情感支持最大点（4）病人/家庭支持（焦虑、孤独、拒绝，等）（4）生活方式修正（图像、模拟）（6）感觉缺陷（智力受损、失明、失聪、失语）注意（99）1名病人至少需要1名护士（151）1名病人需要护士多人为便于评价功能性残疾，采用残疾等级量表（Disability Rating Scale ，DRS) ［11］，分值越高代表功能残疾水平越高。认知能力应用功能性认知指数（ Functional CognitiveIndex，FCI)测验。

医保高可用性集群系统建设实践 篇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

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

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网络中断, 中间件服务器物理故障。

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

系统可用性论文 篇9

1 指纹识别系统的基本原理

模式识别是指纹识别系统的重要应用和理论工具, 最早是在20世纪七八十年代发展起来的, 主要用于对声音、文字等模式信息的识别, 以解决外部环境与计算机的直接通信问题。模式识别的基础在于辨别2个不同样本的差别, 同一个人在不同的条件下指纹的差别极小, 而不同的人即使是在相同的条件下, 指纹也会有所差别, 再加上指纹采集起来比较简单, 因此可作为识别个人身份的最佳特征。

2 网络在线指纹考勤系统可用性途径

(1) 采集指纹识别技术安全可靠。指纹人人有, 人人不同, 且具有唯一性、独特性的特点。指纹识别技术是最成熟也是最早建立的一种生物测定技术, 识别过程中涉及传感器技术、数字图像处理、模式匹配等技术, 再加上近年来国内外在指纹识别技术上取得了突破性进展, 该技术作为一种身份识别方法是十分准确、安全的。与钥匙IC卡、密码等相比, 指纹识别不存在忘记、替代和窃取等问题, 因此更易管理, 且更为安全。将指纹识别引入到考勤管理系统, 能够极大地增强考前管理的准确性、可靠性和软件的安全性。目前, 较为常用的指纹识别系统采用的是美国Digital Persona公司U.are U.系列的模式识别系统, 识别的错误率可降至0.01%, 具有较高的安全性和可靠性。

(2) 客户端操作简便, 且安全方便。目前指纹识别系统对指纹特征的抽取、匹配、注册以及对员工考勤信息的浏览等多采用Win98/Me客户机系统操作完成。对指纹特征注册的过程也就是用户指纹在电脑中储存的过程, 描述指纹图像结构的信息就是指纹特征, 每一幅指纹图像所对应的特征长度仅在200~300个字节范围内, 且每一个图像的特征唯一。特征匹配的过程就是在客户端储存信息中寻找与待确认指纹特征相匹配的记录的过程, 客户端识别成功, 则能够找到与客户指纹特征相匹配的记录, 并能够对匹配的时间和相关信息进行记录。客户端在完成指纹识别功能之后, 会对当时的网络情况进行检查, 若网络状况正常, 客户端则会自动将记录的数据传送到服务器, 服务器经过相应的处理之后, 则会将数据反映到考勤结果当中。反之, 倘若当时的网络环境不正常, 客户端则自动完成对数据的储存工作。由于客户机便于挪动, 因此, 可放在任何方便考勤的地方, 而且客户端购买的数量也可以根据各个单位的需求自发配置, 客户机运转操作所需要的软件只需要在开机设置方面设置成自动开机即可, 这样, 即使文化程度较低, 不擅长计算机操作的人员也可以使用。

(3) 服务器与客户端分开, 便于考勤。服务器除了可以接收指纹匹配结果和客户端传递的注册指纹特征外, 在空闲时也能够手动或自动完成对各个数据库的核对工作, 以保证服务器与客户机的所记录的指纹特征数据的同步更新。同时, 也能够及时取走网络故障时暂存于客户机的匹配结果信息。该类服务器的使用存在的优点有:首先, 避免影响员工考勤。企事业单位工作环境复杂, 在服务器由于某种元因关闭或网络故障时, 每个客户端可以成为独立的考勤系统进行考勤工作。其次, 降低网络拥塞事件发生的概率。在线指纹系统操作环境下, 对指纹的注册、提取等工作的完成大都是在客户机上进行, 因此所需要的网络流量较少, 能够有效避免指纹特征匹配时网络拥塞事件的发生。

(4) 服务端功能完善, 便于考勤工作的安排。网络在线指纹系统服务器端主要存在以下功能:首先, 信息管理功能。该功能下, 操作人员除了可以记录符合查询员工的基本信息以外, 也可实现对员工信息的编辑、产出、添加以及对员工指纹的录入、报表输出等。其次, 排班功能。该功能模块性排班人员可通过对排班的设定、排版对象时间的设定以及对节假日的设定等编排员工的出勤班次, 排班的方式存在轮班、按周排班等多种方式, 排班的安排确定之后, 也可以根据员工的意见进行微调。在排班的调整上, 也可以采用手动修改方式, 手动修改中某一个员工在1年或1周内的排班情况, 可以以日程表的形式呈现, 界面清晰明了, 便于统计, 且操作简单。第三, 考勤结果浏览统计功能。网络在线指纹考勤系统的服务器可以按照不同的要求对不同员工的原始考勤结果进行复合查询, 系统具有即时显示客户机传递的考勤信息的即时查询功能, 且能够对考勤结果按照一定的速率更新。在统计规则确认的制定下, 还能够对员工的出勤情况进行统计。最后, 输出功能。网络在线指纹考勤系统的服务器能够实现对各种报表数据的输出, 操作简单, 且便于统计。以上服务器的各个功能中, 对考勤系统结果的统计是最为重要的一部分, 其结果的准确性直接关系到结果的可靠性。对此, 大部分的考勤系统都将加班申请数据库、节假日数据库以及缺勤申请数据库的内容和推理过程存放在了数据库中, 并运用合适的产生式规则法设计, 建立出各种考勤结果的规则库, 将实际的出勤情况输入, 与规则库中各种各样的条件相匹配, 就能够将正常、早退、迟到、未出勤、请假、迟到早退、中途外出等不同的出勤结果统计出来。这种统计方法准确而快速, 且能够充分考虑到事件的无关系, 对于新出现的情况, 只需添加新的规则即可。

(5) 指纹登入的软件登录方法为了安全且无记忆负担。网络在线指纹考勤系统的软件登录可以采用指纹登录的方法, 不同人员, 根据其管理内容的不同设置权限, 如考勤统计员级别、考勤员级别、系统管理员级以及考勤调度员级等。与传统的账号密码登录方式相比, 不仅不存在账号、密码泄露等问题, 也不会给用户造成记忆密码的负担, 因此, 在使用方面具有无法替代的优越性。

(6) 网络在线指纹考勤系统的使用能够有效提高管理效率, 降低管理成本。首先, 在管理层面上, 网络在线指纹考勤系统在考勤过程中除去了人为因素的干扰, 不仅能够体现管理对事不对人的原则, 也能够有效杜绝管理过程中的人员化现象, 对于体现管理的公开、工作、公平, 提高各个企业机构管理效率有着重要意义。此外该系统的使用, 不仅能够促进企事业单位能够员工管理的科学化、规范化和正规化, 准确的数据记录也能够真实有效的反应员工的迟到、早退、旷工能情况。在数据查询方面, 除了具有模糊查询、数据查询和功能查询的功能之外, 还能够进行满足各种需要的复杂查询, 且人员管理项目齐全, 能够大大提高数据查询效率。且在数据整理完成之后, 该系统具体完整的报表输出功能, 该功能能够及时、准确、明了的提高员工的基本信息, 有助于单位领导及时了解各单位的管理情况并做出正确的判断和决策。最后, 在管理成本方面, 该系统使用后, 部门无需在另外投入资金购买任何的考勤卡和打卡机等, 员工考勤也不必担心考勤卡的遗失问题等, 不仅节约仪器成本, 也能够使管理更方面、更先进、更智能。

3 结语

网络在线指纹考勤系统的应用不仅能够有效地避免管理过程中代考勤等问题, 也增加了员工考勤的灵活性和保密性。且该系统对考勤结果的智能化统计能够很直观地呈现员工的考勤情况, 很大程度上提高了领导管理员工的便利性。

参考文献

[1]曾祥绪.网络在线指纹考勤系统可用性措施[J].计算机应用, 2010 (10) :2831-2833.

[2]章通, 陈金玉.网络指纹考勤系统的设计与实现[J].计算机应用与软件, 2011 (2) :73-75.

系统可用性论文 篇10

1 系统的可用性分析

1.1 系统可用性简介

系统可用性(Availability)是信息工业界用来衡量一个信息系统提供持续服务的能力,它表示的是在给定时间内系统在特定环境中能够满意工作的概率。简单地说,可用性是系统运行时间除以系统运行时间和停机时间之和所得的结果,即:可用性=系统运行时间/(系统运行时间+系统停机时间)。

对于小的问题一般不需停止整个系统,此处计算的是严重的失效,即那些需要恢复程序数据,重新加载程序,重新执行等情况的失效。

1.2 影响系统可用性的主要因素

在建设11185系统时,应以提高系统的可用性作为主要建设原则,在系统设计阶段就予以特别关注。在设计一套完善的可用性系统之前,必须充分认识制约系统可用性的条件。经过全面分析系统,发现影响11185系统可用性的主要因素包括:

1.2.1 软件层因素

1)软件缺陷:11185系统是一个计算机综合应用平台,软件构成较复杂,既包括CTI、IVR、录音等平台软件,也包括座席、后台管理、工单处理等业务应用软件。由于呼叫中心的固有特性,各类软件之间的藕合性比较强,软件错误容易产生扩散及连带影响。比如,CTI出现软件问题就可能导致部分座席不能登录,或者登录以后话路不能正常接入,造成业务处理软件无法运行。

2)病毒影响:由于11185后台业务处理点PC机均使用Windows系统,一般是多业务处理台席,多人进行操作,易遭受计算机病毒的攻击。

另外,由于CTI、录音等主要服务器都是Windows系统,也易受到计算病毒的影响,造成系统软件的不稳定。

3)人为操作失误

11185系统中每个座席都要经过网络、话路配置,配置若不注意会出现相互冲突现象,导致座席不能正常使用。用户在完成业务处理过程中由于人为的操作失误,会造成用户与系统的交互失败。另外,系统管理员和座席人员的误操作也会导致部分功能的中止。

4)监控不到位:呼叫中心系统集成诸多的软硬件产品,需要对系统的关键运行数据进行监测(如CPU、内存、硬盘容量、网络通信、节点负载等),由于维护人员的监控不到位,往往会直接影响到系统的稳定运行。如节点负载超负荷亦会造成系统运行的不正常等。

5)更新与升级:11185系统在建设及运行过程中,根据实际需求,会进行相关的系统变更工作(指平台软件的更新升级)。平台进行系统变更时通常都会涉及到CTI、IVR,直接影响到接入话路的处理,从而影响到系统的可用性。

1.2.2 硬件层因素

呼叫中心的基本功能是实现呼叫的接续和处理,一个呼叫的接续过程涉及到不同设备的协同处理,呼叫信息的接续过程定义为呼叫路径,呼叫路径中的任何关键节点设备失效,都将导致呼叫接续的中断。

硬件故障具有相当的不确定性,突发性强,难以控制。服务器出现硬件故障影响系统运行的现象是突然宕机,无法重新启动。接入交换机有问题,话路无法接续,造成呼叫中断。出现硬件故障后,带来的后果是系统功能的中止,更严重的会造成系统数据的丢失。而且整个维修过程都需要一定的手续和时间,给故障恢复带来一定的困难。

网络关键设备也会有出现故障的可能,但一般情况下,网络设备出现故障的机率比服务器小。

解决单点失效可采用完全冗余的解决方法,即所谓的2N架构,把所有可能出状况的组件都准备两套,确保主要组件损坏时备用组件可立即接手运作。但如果所有的关键设备都采用冗余方式,投资成本大,且可能出现设备闲置,此做法在实际工作中并不切实可行。

1.3 系统关键设备的选择

系统关键设备的个数越少,系统的可用性也就越高。在选择关键设备时,应对系统设备逐个分析,明确设备和系统运行之间的关系,不断缩小范围,最后将11185的关键设备确定为接入交换机、数据库服务器、WEB服务器(11185系统后台业务处理采用B/S结构,适用于全省联网作业处理流程)。并没有将呼叫中心常见的CTI服务器和IVR服务器纳入关键设备,是因为CTI和IVR只是呼叫中心语音平台的应用功能,实际应用中,用户话路进入交换机后,是可以不经过CTI和IVR,直接分配到座席,从而不影响话路的接续。

1.4 系统设备的可用性层次结构

11185系统设备种类繁多,通过对系统的可用性分析,可以将11185设备分为三个层次:

1)关键设备:接入交换机、数据库服务器、WEB服务器。

2)二层设备:CTI服务器、IVR服务器。

3)三层设备:录音服务器、传真服务器、网关PC及其它设备。

设备分层直接说明了设备的可靠性和可维护性等级,层次越高的设备,可靠性和可维护性要求自然越高,同时可用度也较高。设备分层结构为整体系统可用性的实现奠定了基础;另一方面,11185的设备分层也有助于11185系统的故障分析和定位,对运维工作有很大的帮助。

2 系统可用性的实现

以上述分析为基础,从可用度、成本及效能之间的平衡为出发点,结合系统的可靠性和可维性,设计出综合提高11185可用性的方法。

2.1 提高软件可用性设计

1)针对软件缺陷:在系统开发过程中就采用科学的软件工程方法,提高软件质量,注重系统及应用软件测试,尽量做到早发现早修改;系统运行时遗漏的缺陷可通过改正性软件维护加以处理。系统在经过一段时间运行后,软件缺陷将控制在一定的范围内,通常不会出现重大软件缺陷。

2)针对计算机病毒:防病毒措施主要包括技术和管理两大方面:

在技术上可在系统中安装网络防病毒软件,以提供对病毒的检测、清除、免疫和对抗能力;从系统网络整体安全防范的角度去考虑,控制网络病毒(如蠕虫病毒)的传播。配置一台服务器作为病毒防护管理控制中心,以实现网络中防病毒软件的统一管理和升级,确保系统中的每台机器都运行最新版本的病毒查杀软件。

在管理上应制定一整套有关的规章制度,提高员工计算机病毒的防范意识,加强软件的管理,不随便安装和使用软件尤其是盗版软件,限制软盘和优盘的使用等。

3)针对人为操作失误:通过加强系统管理员和座席人员的培训,建立严谨的运维制度,严格按照系统相关操作文档进行操作,也可降低对系统的误操作。

4)针对监控不到位:关键设备可靠性不可能达到100%,但通过有效的系统监控和日常维护,80%的故障隐患是可以预先发现并消除的。

关键设备应具备主动预警监控模块,从而改变传统的由维护人员被动响应故障的局面,实时对系统的运行数据进行监测,对超过预警阀值的参数进行主动预警,通过短信、呼叫等手段主动通知维护人员,以利于维护人员提前发现故障的隐患,为故障隐患的排除争取宝贵的时间。

5)针对系统更新升级:系统在进行软件升级前,先对数据库和相关软件进行备份,严格按照升级操作文档进行操作,避免因升级失败而造成数据的丢失和系统运行不正常。

2.2 关键设备高可用性设计

关键设备位于分层结构的顶层,包括接入交换机、数据库服务器、WEB服务器。三个设备对于呼叫中心系统都构成单点失效,接入交换机有问题,话路无法接入;数据库服务器或WEB服务器有问题,业务无法受理和处理。所以,关键设备的可用性是重点设计内容,可通过提高硬件规格、采用专业软件支持、合理配置实现高可用度。

1)接入交换机:11185接入交换机是呼叫平台的核心,为此专门选用了Avaya的Definity G3si,为电信级设备,高可用度可达到99.999%(1年的停机时间不超过5分15秒)。

为进一步确保话路畅通,还设计了备用方案B和C。方案B为利用通信机房已有的内部电话系统阿尔卡特A4400交换机作为备用交换机;方案C是建立5路备用电话线,通过发生故障时,电信局端进行设置实现号码转移到备用电话线上。

2)数据库服务器:数据库服务器采用基于SAN的双机高可用性技术:两台至强服务器作为主机,一台磁盘阵列柜作为共享存储系统,实现RAID5。采用双机热备模式,当主机正常运行工作,从机处于监控准备状态。当主机宕机时,从机接管主机的工作,待主机恢复正常后,可按自动或手动的方式将服务切换到主机上运行。

3)WEB服务器:WEB服务器采用2台PC服务器,操作系统为Windows Advanced Server 2000,通过系统配置实现双机集群,从而实现网络负载平衡和单点故障转移。

2.3 旁路CTI的软件设计

为了使系统在出现问题时能绕过CTI和IVR,应对交换机和座席业务软件都做专门设计配置,特别是对座席业务软件的登录界面增加是否连接CTI的选项,默认为连接CTI。

比如,当遇到CTI与IVR系统更新引起的中断时,座席代表可退出座席业务软件,并选择不连接CTI重新登陆。这时,利用交换机的ACD功能也能将话务转接到相应的工作组。座席代表完全可接听用户电话办理业务,只不过是少了CTI的功能。从对于用户业务的可用性而言,这种情况是可以接受的。

增加连接CTI的选项的另一个好处是方便座席业务软件的测试。

2.4 非关键设备可用性设计

对于属于非关键设备的服务器、座席PC等,可采用同型号配置和N+1的方法。

1)同型号配置:CTI、IVR、录音服务器等其它二三层服务器设备采用同机配置,即采用同一品牌型号,主板、硬盘保持一致,内存可根据性能要求有所不同。

2)N+1:N+1就是增加一台同型号配置的备用机。通过硬盘复制,使得每台工作服务器都有复制硬盘。当工作服务器出现硬件或软件故障时,将相应的复制硬盘插上备用机,由于所有服务器是同型号配置,可以轻易实现故障工作服务器的备机替换。

2.5 确保系统可用性的安全策略

11185系统的使用人员有座席人员、管理人员、开发人员,系统本身又要与综合网、金融网、互联网相联,系统运行的外界环境较为复杂,不安全因素多,直接影响到系统的可用性。安全策略的制定是系统可用性的有利保障。

1)物理安全:物理安全主要防范各种自然灾害(防火、防水、防雷击),防范各种人为入侵及盗窃,防止擅自操作和使用设备,防止业务信息的丢失、泄露和破坏等。因此需要从基础设施、网络设备、故障处理、机房条件等方面为系统提供安全可靠的运行环境和条件。

2)网络安全:综合采用路由器ACL访问控制技术、网络物理隔离及VLAN等技术和手段,保障11185系统与其他系统的安全连接。对于与互联网的连接,可采用双层防火墙和VLAN技术。

2.6 建立故障应急预案

即使在设计上已经保证了系统的可用性,并且设置了系统运行主动预警模块,故障的出现还是不能100%避免的。根据故障处理的指导原则,以最短的时间完成故障的处理和系统的恢复,最大限度地减少故障造成的运营损失,必须建立节点的故障应急预案,包括故障点的快速确认方法、故障数据收集、处理和恢复的详细步骤。对于拥有良好文档的系统,当发生故障时,诊断更快速准确,从而保证在故障处理时能够游刃有余。

3 结束语

本文从11185系统的可用性分析出发,提出呼叫中心系统的可用性必须从系统设计阶段就要开始关注,可用性不仅仅是单个设备的可用性,更要充分意识整个系统可用性的重要性。要从系统设备的相互作用、实际具体运作中去寻求提高系统的可用性方法,建立起系统设备的可用性分层结构,以实现可用度、成本及效能之间的平衡。

参考文献

[1]陈勇,杨学良.基于分散式呼叫中心的管理系统的设计与实现[J].计算机工程与设计,2002,23(12):48-51.

[2]伍芃华.多媒体呼叫中心构建与CRM策略[M].北京:人民邮电出版社,2003.

数据可用性的评估方法分析 篇11

摘 要：针对日益突显的数据质量问题，文章从数据可用性的角度，介绍并分析了目前国内外基于单个属性的数据质量评估方法，指出了相关工作的进一步研究方向。

关键词：数据质量；可用性；评估方法

中图分类号：TP315 文献标识码：A 文章编号：1006-8937（2015）15-0062-02

随着大数据时代的来临，数据集合中劣质数据也随之大量产生，导致信息数据整体质量下降，数据的有效使用受到了极大限制。为了更加有效发挥各行各业大数据的作用，开展数据可用性研究具有较大的战略意义。

1 数据可用性定义

研究者们普遍认为，数据的可用性可以从数据的一致性、准确性、完整性、时效性及实体同一性五个方面进行考察，其具体定义如下：

①数据的一致性：指数据信息系统中各相关数据信息之间相容、不产生矛盾。

②数据的准确性：指数据信息系统中每个数据表示现实物体的精准程度。人们对数据进行操作的各个环节都可能影响数据准确性。

③数据的完整性：指数据集合包含的数据完全满足对数据进行各项操作的要求。

④数据的时效性：是指在不同需求场景下数据的及时性和有效性。对应用系统而言，往往对数据时效性要求较高，过时的数据即使分析出来了也不会对实际应用产生有价值的影响。

⑤实体的同一性：指同一实体在各种数据源中的描述统一。

一个数据集合，满足以上五个性质的程度称为该数据集合的可用性。

2 评估方法分析

对于数据可用性评估，国内外研究人员也进行了许多工作。以下从数据的一致性、精确性、完整性、时效性、实体同一性五个方面进行介绍和分析。

2.1 基于一致性的方法

文献[1]针对异地备份系统中数据持续变化的情况，设计并实现了一种基于累积摘要值的一致性检测方法。该方法解决了传统一致性检测需要中断备份任务的问题，保证了备份任务的连续性，并且能够迅速检测本地服务器和远程备份中心数据的一致性，提高了一致性检测的效率。

文献[2]从已有的一致性维护方法出发，针对海量数据多副本之间一致性维护，从一致性维护过程中所涉及的更新发布、更新传播方式、更新传播内容、更新冲突解决等几个方面进行了分析，提出了相应的解决办法。

文献[3]针对P2P分布存储系统中大型数据对象面临的数据一致性问题，提出了数据一致性维护方法PLCP。该方法从提高更新传播速度和减少日志空间开销的角度进行了数据优化。同时针对数据更新的问题和关键属性更新的问题，提出数据一致性维护方法DACP和KACP。

文献[5]从无线传感网络数据安全的角度，结合一些廉价的保护技术，提出了利用跨层一致性评估信息整体质量的方法。

基于数据一致性的方法，主要体现在集中存储方面，对于分布式和非关系数据方面研究还较少，适用于海量数据的一致性评估方法有待进一步探索。

2.2 基于精确性的方法

数据精确性方面的研究结果比较少见，文献[6]从精确度低的角度，提出了对应的精确性评估算法。该算法考虑了一种基于可能世界语义的描述方法。目前的研究结果显示，数据精确性的评估方法还有待研究者们深入探究。

2.3 基于完整性的方法

针对海量关系数据中普遍存在的数据不完整现象，刘永楠等研究了关系数据完整性度量问题。针对数据的完整性计算问题，提出了数据完整性计算模型，以及精确算法和基于均匀抽样的近似算法。理论分析证明了近似算法可以达到任意的精度要求，可以高效地对数据完整性进行计算，通过在DBLP数据上的实验验证了算法的有效性和高效性。

在具体应用领域，张少敏等利用IEC61970对智能电网进行信息集成，然后根据完整性定义，对智能电网数据进行自动机建模，给出了一种无需对数据进行直接操作的数据完整性定量评估模型。

Barcelo P等将传统的完整性理论扩展到XML数据上，讨论了不完整XML数据的表示问题。

另外，针对云存储服务中数据的完整性问题，一些研究者提出了PDP 和POR。这两种方案都采用了概率性证明思路，即存储服务提供商向数据拥有者证明其完整的持有数据拥有者存储的数据。

基于数据完整性评估方面的结论还较少，特别是具有普遍适用价值的方法，还有待进一步研究。

2.4 基于时效性的方法

文献[7]针对历史评价数据时效性会影响评价计算准确性的问题，引入了评价数据的时间属性，构造了评价数据衰减因子，减小了时效性对于评价计算准确性的影响。

文献[8]研究了包含冗余记录的集合在给定时效约束下的时效性判定问题，并首次提出了时效性判定问题的求解算法.

在建筑能耗领域，文献[9]通过对几类典型公共建筑能耗数据的统计分析对比，提出了采用近1年的能耗数据作为统计样本的建议。

基于时效性方面的研究非常匮乏，已有的少量研究结论都主要针对一些特殊应用，还需深入系统的研究。

2.5 基于实体同一性的方法

实体同一性是数据可用性研究较多的一个方面，实体同一性研究主要涉及两类方法：第一类是从语义规则的角度进行同一性研究，这类方法主要通过经验知识来描述实体的同一性问题；第二类是从相似性的角度进行同一性研究，该类方法主要采用相似度函数来对实体同一性进行判定。

针对实体同一性方面的相关技术，包括实体识别的效率问题、识别的增量计算、半结构化数据上的实体识别等，文献[4] 展开了相对完整的讨论。

对于实体统一性的评估方法大多针对关系数据，针对复杂结构数据、半结构化数据、非机构化数据方面的研究还很少。

3 结 语

在大数据时代，数据量急剧增长，数据的可用性问题将严重影响基于数据的知识和决策。确保大数据的可用性是进行大数据分析、处理的关键基础，将直接关系到大数据价值的体现。本文针对数据质量问题，从数据可用性的角度，介绍并分析了目前国内外基于单个属性的数据质量评估方法，将有助于促进大数据可用性的研究。

参考文献：

[1] 刘仕一，李涛，刘哲哿，等.异地备份系统数据一致性检测方法[J].计算机工程与设，2010，（17）.

[2] 周婧，王意洁，阮炜，等.面向海量数据的数据一致性研究[J].计算机科学，2006，（4）.

[3] 周婧.P2P分布存储系统中海量数据的数据一致性维护技术研究[D].长沙：国防科学技术大学，2007.

[4] 刘显敏，李建.中实体识别问题的相关研究[J].智能计算机与应用，2013，（2）.

[5] Mattia Monga，Sabrina Sicari.Assessing Data Quality by a Cross-Layer

Approach[D].Ultra Modern Telecommunications & Workshops，2009.

[6] Cheng R，Chen J，xie X.Cleaning uncertain data with quality guarant-

ees[J].Proceedings of the VLDB Endowment，2008，（1）.

[7] 杨超，吴爱荣.基于衰减因子的评价数据时效性处理方法[J].计算机工程与设计，2010，（3）.

[8] 李默涵，李建中，高宏.数据时效性判定问题的求解算法[J].计算机学报，2012，（11）.

系统可用性论文 篇12

辽河油田地质信息系统自2006 年运行以来, 作为面向全油田提供服务的数据处理门户网站,依托浏览查询、数据加载、数据审核等业务系统、历史资料库与临时管理库等众多资源收集所需信息,通过一体化的底层数据模型以及多种编程技术的应用,形成涵盖井位坐标、井属性、井斜、有效厚度、分层、解释表、测井、录井、试油等13 类油田生产数据、能够实现数据、表格、报表、图件一体化应用的综合信息系统。 油田地质信息系统的特点是覆盖面广,数据量大,信息种类多,高浏览量和访问量对数据库系统有较高的要求,要求能实现大量用户并发访问的同时保障其24×7 的可用性、可靠性、故障快速恢复。 保证数据库的高可用性,直接影响辽河油田勘探开发研究水平。

1ORACLE RAC技术

Oracle RAC (RAC:Real Application Cluster), 即Oracle实时应用集群,是Oracle数据库的一种高可用解决方案,以网格计算思想而产生的[1]。 在RAC环境中,Oracle运行于两个或多个计算机节点上,各节点部署集群组件、数据库监听、数据实例、数据库服务等,而数据文件则部署在独立存储中,被各节点共享使用[2]。 节点中的数据库实例通过高速缓存合并机制(Cache Fushion)进行数据同步。

Oracle数据库集群具有负载均衡(Load Balance) 和透明应用故障切换(Failover)两大特征。 负载均衡是把数据访问请求分配到集群中的各节点中, 从而提高数据库系统的整体吞吐能力;透明应用故障切换提供24×7 提供不间断的数据访问,当一个节点出现故障时,连接在该节点上的终端用户会被自动重新连接到其余正常的数据库节点上,无需手工连接,该切换对客户端的数据访问是透明的[3,4]。

应用服务的运行离不开数据,共享数据的集中存储和数据量的不断增长,必然要求数据库必须具备较高的运行性能和稳定性。 在传统的单机环境中,通常是将数据库配置在一台服务器上,存在着潜在的不稳定威胁,主要表现在数据丢失的危险性,负载不能动态平衡,无法实现故障时的容错和无断点恢复等。而采用Oracle RAC集群技术,动态的进行负载均衡,可提高访问数据库的效率,提高数据中心的可靠性和抗灾难性,为信息系统提供一个高效、可靠的数据平台。

2实施方案

2.1 环境规划

(1) 数据库服务器。 采用4 台Oracle SPARCT4-4 服务器:4×SPARC T4 八核3.0G Hz处理器、512 G内存、4×600 GB 10 K rpm SAS磁盘,拥有出色的单线程和多线程吞吐性能,提供适合于大型数据库以及地质绘图的综合应用服务。

(2) 软件平台。 操作系统采用Solaris 10, 数据库软件采用Oracle 11g及Oracle 11g RAC相关组件。

(3) 存储服务器。 使用2 台HDS VSP存储阵列, 具有强大的可横向、纵向及深度的扩展功能,为共享存储虚拟化的多个应用提供安全的多用户环境。 Oracle RAC集群是完全共享式的体系架构, 因此存储机制采用ORACLE自带的自动存储管理(ASM), 兼顾磁盘间大量的IO快速读写及联机磁盘的动态平衡。 每台HDS均划分出25 个250 G的LDEV, 组成ASM的+DATA卷组, 用于存放数据库数据;3 个1 GB的LDEV, 组成asm的+OCRVT卷组, 用于存放控制文件、 参数文件、 联机日志文件等; 其中一台HDS划分出15 个250 GB的LDEV, 组成ASM的+ARCH卷组,用于存放Oracle数据库的自动归档文件;这些卷组均作为共享磁盘,分配给4 台数据库服务器。

(4)网络。 采用2 台Brocade 5100 交换机,搭建SAN存储网络, 避免单点故障, 保障SAN环境的安全可靠性; 采用2 台Infiniband交换机实现私有网络,保障私有网络的可靠性与失败切换。

2.2 部署实施

2.2.1 架构设计

考虑到地质信息系统对底层数据库性能的要求以及对高峰负载的处理,选择采用4 台Oracle RAC架构为用户提供数据查询与保存服务,作为数据库服务器,每台主机配备2 块网卡:一块网卡用于公共网络上的客户程序通信,另一块用于集群通信。 同时为了保证数据库运行的安全性、稳定性与可靠性,在此架构设计过程中,全面考虑了服务器、网络、存储的冗余,最终实现了高可用数据库集群系统。 系统的架构如图1 所示。

与以往双机热备环境不同的是,集群系统的4 个节点可以同时为用户提供服务,解决了同时只能1 台数据库服务器为用户提供服务的问题;4 个节点服务器通过2 台控制交换机与“ 心跳线” 相互监测对方的运行状态, 包括操作系统的运行、 网络通信和应用运行情况等, 一旦发现1 台主机的运行出现问题,故障机上的应用就会立即停止,其上的应用及资源就会被转移至另外3 台数据库节点中的一台,解决了高可用问题。 考虑到RAC的缓存融合需要,采用Infiniband交换机作为节点间的互连通信设备,这4 台数据库服务器向用户提供的数据是完全相同的,不会因为用户连接到不同节点而出现数据不一致的情况,同时也避免因为某节点故障而导致存活节点上用于互连的网卡被禁用。

在网络设计上采用全冗余架构,数据库内网采用双线连接到2 台内网核心交换机。 当网络中一条链路出现故障时,服务器的流量会自动切换到另外一条网络链路,保证用户的正常使用。 集群存储采用FC-SAN的架构,使用作为主存储,每台数据库服务器都是用两块HBA卡和FC数据交换机相连,FC交换机和HDS存储相连。 这些FC链路都是采用双线连接,当一条链路出现故障时,系统仍然能够正常稳定运行。

2.2.2 具体实施

根据以上部署方案,简要介绍一下4 节点集群系统的安装及配置过程。

(1) 按照系统架构图搭建系统硬件平台, 安装Solaris 10 操作系统,连接光纤存储;

(2)组装存储设备,创建数据体系共享逻辑卷组, 向其中添加设备;

(3) 进行安装前环境检查, 配置系统参数、 环境变量及oracle用户环境;

(4) 安装集群系统Grid软件、Oracle 11g软件, 创建ASM磁盘组;

(5)创建数据库,手动开启归档并对数据库参数进行设置。

2.3 内存管理

集群系统是由4 节点组成,每节点实例都有自己的内存区域,分为系统全局区SGA(System Global Area)和程序全局区PGA (Program Global Area)。 SGA是每个数据库主要的缓存区域,PGA由进程在本地分配用于保护与用户进程相关的内存段。 在11g中,oracle内存管理引入了自动内存管理AMM(Automaitc MemoryManagerment),通过修改参数MEMORY_TARGET及MEMORY_MAX_TARGET实现, 将SGA和PGA都纳入了自动管理的范畴。设置并启动AMM后,Oracle将自行决定SGA和PGA的分配和使用,可极大的简化DBA对于内存的调整和管理工作。

MEMORY_TARGET参数指定的是在自动管理时可以使用的共享内存大小, 不能超过MEMORY_MAX_TARGET参数设置的大小。 如果没有设置,默认等于MEMORY_TARGET的值,通过指明scope=spfile这个条件来实现数据库在下次启动后让改变生效的目的。

2.4 负载均衡

在Oracle RAC体系中,负载均衡(Load Balance)是指对用户连接进行管理, 使他们从事的工作平均分布在Oracle RAC节点或集群数据库实例之间[5]。 共有两种类型的连接负载均衡,客户端负载均衡和服务器端负载均衡。 客户端负载均衡是在客户端连接定义文件tnsnames.ora中通过设置参数LOAD_BALANCE=ON来实现, 默认为ON, 因此除非是希望关闭,否则不需要这一引用。

服务器端负载均衡主要由服务器监听器(Listener)来实现。当收到新的连接请求时, 监听器将判断每个数据库实例(Instance) 的工作负载, 并选择一个最轻负载的实例进行连接;数据库进程pmon会将每个实例的工作负载情况通知监听器,以便监听器能够掌握各数据库实例的负载情况。 只有在数据库实例初始化参数LOCAL_LISTENER和REMOTE_LISTENER中指定的监听器才能够接受这些负载数据, 可采用命令SQL>show parameter listener进行查看。 从Oracle 11g开始,Oracle自动为LOCAL_LISTENER数据库参数设定值,因此不需要手动设置这个参数。 对于REMOTE_LISTENER,必须保证这一参数的值为rac-scan:1521,如果不正确,可以尝试利用以下命令修改:

SQL > alter system set remote_listener = 'rac -scan :1521'scope=bothsid='*';

这一命令要在每个节点上单独执行,注意区分HOST的名字及sid的值;

通过上述配置, 可以实现4 个节点间负载的动态均衡,保证负载在集群的各个节点中均衡分发,使用户的作业能够以最快的速度被数据库服务器处理。

3实施效果

应用本文部署的Oracle 11g RAC集群系统后,我们对访问地质信息系统的客户端数量与服务器响应时间进行了统计,结果见图2。 如图2 所示,集群系统下,地质信息系统的响应时间明显短于传统的单机系统,而且,随访问系统的客户端数量递增,这种差距便越发显著。 这是由于在传统的单机模式下,所有的作业在服务器端按串行方式逐个执行, 客户端等待时间长,服务器负载高;而集群模式下所有的作业会按照各个节点负载的多少均衡分发并行执行,因此客户端延迟小,能够做到负载均衡。 本文中所应用的4 节点Oracle 11g RAC系统能够在最大的程度上发挥这种优势。

此外,集群系统的处理速度比照传统的单机系统也有显著的提升。 如图3 所示,当利用地质信息系统进行指定层位的井位分布图绘制时,随着井数的增加,集群系统所需的处理时间增长趋势远低于传统单机系统。 当客户端需要绘制一张2000口井的井位分布图,传统系统模式需要70 秒,集群模式下则只需19 秒,节省约2/3 的时间。

4结语

应用本文部署的Oracle 11g RAC集群系统,充分利用了服务器资源,能够显著降低服务器访问负载,使地质信息系统的运行效率得到大幅度提升。 目前,该架构实施1 年以来,已稳定运行与本数据中心,良好的实现了24×7 小时无间断服务,能够做到负载科学协调、自动分配、数据处理方式按照并行完成,实现很高的资源利用率等诸多优点。 为精确的地质图件绘制与地震解释等地质研究提供良好的数据服务,同时为各项地质业务应用提供了一个高效、可靠的数据平台。

摘要：随着辽河油田地质信息系统在勘探开发研究中应用的不断深入,高浏览量和访问量对系统的后台数据库提出了较高的要求。文章在Oracle RAC技术基础上,实施构建了油田地质信息高可用性数据库系统,并通过内存管理及负载均衡提升系统运行效率。

关键词：Oracle RAC,高可用性,油田地质,内存管理,负载均衡

参考文献

[1]闫黎.基于Oracle RAC的数据库架构分析与企业应用[J].计算机系统应用,2013,22(11):200-203.

[2]刘宪军.Oracle Rac 11g实战指南[M].北京:机械工业出版社,2011.