高可用性软件架构设计和实现论文

2024-04-27

高可用性软件架构设计和实现论文（共6篇）

篇1：高可用性软件架构设计和实现论文

摘要：硬件冗余可以极大地提高计算机应用系统的可用性，然而，一旦关键硬件出现故障或数据库宕机，正在进行中的业务流程通常会中断。探讨了一种如何实现应用系统高可用性的软件架构的设计方案，以弥补纯硬件冗余应用系统的不足。

关键词：高可用性;软件容错;分布式数据库

在业内，计算机应用系统的可用性定义为计算机应用系统保持正常运行时间的百分比，通常用表1所示的“9”的个数来划分可用性的类型。

通常，硬件冗余(容错计算机、双机或多机集群、磁盘阵列、SAN等)、数据复制、合理的灾难备份和恢复策略都可以极大地提高计算机应用系统的可用性。正因为如此，当前，对于计算机应用系统的高可用性、业务的可持续性要求，业内通常以硬件系统的高可用性来应对或代替。常见的解决方案是双机(或多机)集群方案或直接采用容错计算机来保障系统的高可用性，应用软件的设计和开发往往仅注重业务流程的分析和过程控制。在这种完全依赖硬件来保障整个系统的可用性的系统里，一旦关键硬件出现故障或数据库宕机，正在进行中的业务流程(如需较长执行时间的事务处理、后台批处理过程等)必然会中断，这是因为双机切换也需要时间。对此，应用软件本身并无多少作为，该类业务必须等待系统重新恢复后全部或部分重做。

本文以基于大型数据库的应用系统为例，从“软件容错”设计的概念出发，参考“分布式”数据库结构设计，以“系统服务总线”为核心，给出了一种可行的高可用性软件架构的设计方案，可以极大地提高应用软件的可用性和业务系统的可持续性。无论是传统的C/S架构，还是近年来流行的B/S架构，本文中给出的设计方案都有一定的参考意义。

1软件结构模型

任何基于大型数据库的应用系统，都可以抽象为对数据的“读”和“写”操作。至于客户端如何展现“读”到的数据，以及“客户端”与“服务端”基于何种通信协议通信，不在本文讨论之列。

软件结构的设计其实就是针对“读”和“写”的一系列流程的设计。如何最大限度地保证系统中的所有“硬件”和“软件”协同工作，正确完成每一次“读”和“写”的操作，也就是对系统“高可靠性”和“高可用性”的要求。

图1是基于“软件容错”和“分布式数据库系统”的原理，并参照了计算机“总线”的工作原理给出的一种基于分布式数据库或文件系统的高可用性的软件架构设计方案。系统采用3层架构：客户端、中间应用层和数据库层。

2系统设计

2.1数据库配置为了更清楚地阐述本文的设计方案，先对数据库的配置及其功能进行描述。本系统中，数据库按角色可划分为如下三类数据库：控制数据库(COTROLL DB)、日志数据库(LOG DB)、业务数据库(BUS DB_N)。

2.1.1控制数据库

控制数据库也可以是一个或多个系统控制(参数)文件。它存放要访问的目标数据库的节点(N)、端口、用户、文件头、表、视图等信息;存放对节点、业务数据库、表或视图的授权或访问控制信息;目标数据库(或文件)的当前状态(联机/脱机、忙/空闲等);目标数据库中的表或视图的当前状态(联机/脱机、忙/空闲、加锁/解锁等)。

2.1.2日志数据库

日志数据库独立于业务数据库之外，用于记录客户端节点信息、请求时刻和发来的所有请求的原始内容，但不做业务流程相关的处理、运算等。记录每次数据操作分配的唯一的“事件号”(EVENT_ID)。对每一次客户端的“请求”，“系统服务总线”(SYSSRV)会分配唯一的标识符号，可以定义为有一定意义的字符串，比如，“当前时刻+流水号”。以上信息可以被压缩、打包、加密后存放，以记录格式保存于数据库的表或文件中。它可以设计为数据库中的一个或多个表，也可以是文件格式。

2.1.3业务数据库

业务数据库记录所有业务相关的数据信息。所有业务数据库的相关业务逻辑的数据结构相同，即，N个节点的业务数据库中与业务模式相关的表、视图、过程或其他程序设置相同。

需要特别指出的是：

(1)控制数据库、日志数据库和业务数据库可以是不同数据库厂家或品牌的产品。比如，日志数据库可以采用低端的数据库产品或开源数据库系统，业务数据库可以采用高端的大型数据库产品。

(2)控制数据库、日志数据库和业务数据库在物理上和逻辑上是可以相互隔离的，这可以极大地提高系统的整体安全性。目标数据库和要访问的表或视图对客户端来说是“不可见”的，由控制数据库动态定义和控制。

(3)所有类别的数据库在物理上位于一个或多个节点上，即节点N>=1;任意一个节点N上建有一个或多个业务数据库(逻辑数据库>=1);任意一个节点是一个完整的、可独立工作的计算机。根据性能要求，可以是高性能PC机、PC服务器、小型机、集群或超级计算机，或是它们的“混合体”;任意一个节点是指定网络中的一个指定节点。

2.2应用层设计

中间应用层由5个后台进程构成：(1)系统服务总线(SYSSRV);(2)数据库写进程(DBWRT_N);(3)数据库读进程(DBRED_N);(4)数据库在线恢复进程(DBRCY);(5)日志检查进程(LOGCHK)。

2.2.1系统服务总线

这是一个后台监听、分发、调度总进程。设计目标具有一定的“自我修复”和“自我复制”动能。它可以根据负载情况，自我复制或开启子进程响应新的负载;可以动态配置可服务的节点或客户端;可以为特定节点或客户端指定专用进程;它通过“DBWRT”和“DBRED”“读/写”日志数据库或日志文件。

2.2.2写进程

写进程负责向所有节点写数据。它可以配置成多进程/单进程模式;多进程模式，指对应每个业务数据库N都有独立的“写”进程;单进程模式，指对应多个业务数据库只有一个主进程，主进程开启多个线程提供“写”服务。

2.2.3读进程

读进程负责向所有节点读数据，它可以配置成多进程/单进程模式。多进程模式指对应每个业务数据库N都有独立的“读”进程，单进程模式指对应多个业务数据库只有一个主进程，主进程开启多个线程提供“读”服务。

根据需要，读进程可以配置成：向所有在线节点并发读数据，返回最快的结果集，抛弃其他的结果集，并中断其他读进程;也可以配置成：随机读某个节点的数据，如果失败或超时，则再随机读余下的在线节点，直到“读”成功或失败;还可以配置成向所有节点顺序读数据，过程类似上面“随机读”。

以上“读写”业务数据库的进程，设计上支持多种数据库访问接口，针对“表”或“视图”提供统一格式的、标准的、动态的SQL数据操作接口和方法，完成对数据库中表或视图的增、删、改、查和批处理操作。它们可以设计为数据库中的存储过程，也可以是C++，Java程序的API或混合体。

2.2.4数据库在线恢复进程

该进程负责检查全部或部分节点数据库(包括所有授权控制数据库、业务数据库和日志数据库)或文件的工作状态;检查数据库或文件表中数据的一致性;将以上检查结果写入日志数据库(或日志文件)。

当某个业务数据库中的表写入失败时，它负责从“日志数据库”的表或日志文件中读出原始数据，接着写入出现问题的业务数据库的表中，并检查结果。或从其他节点的数据库中读相关数据并写入到出现问题的业务数据库的表中。

接收外部命令，根据“时间点”或“事件号”从特定时刻、特定数据库(包括日志数据库)、特定表恢复数据到特定目标数据库的表或文件。

2.2.5日志检查进程

该进程负责读、写日志文件，检查数据操作结果的一致性。如果不一致，则报告给“系统服务总线”，将问题数据库或数据库中的表、视图设置为“离线”状态。

3系统实现

3.1系统初始化启动配置好的后台进程即完成系统初始化过程。

3.2数据“写”流程

数据“写”流程的主要步骤如下：(1)客户端通过给定协议(或混合多种通信协议)向后台“系统服务总线”发送“写”请求。

(2)激活“数据库写进程”，将客户端的“请求”写入“日志数据库”(或日志文件)，并分配一个唯一的“事件号”。

(3)“系统服务总线”查询“授权/控制数据库”(或/配置文件)得到客户端请求访问的数据存放的目标数据库(或文件)节点N(或文件存放的节点N)、端口、用户、表、文件头等信息。节点N可以是多个，即节点N>=1。

(4)“系统服务总线”向N个“数据库写进程”发送数据“写”访问请求，并得到各节点的返回结果集。

(5)只要有1个节点写入成功，“系统服务总线”就将写入成功的标志发回客户端;“数据库写进程”将各节点的返回结果状态写入“日志数据库”(或日志文件)中。

(6)“日志监控”查询“日志数据库”(或日志文件)，比较N个节点的写入状态。如发现写错误、失败、超时等状态，则将该“业务数据库”(或文件、表、视图)标志为“非正常联机数据库”(或文件、表、视图不可用)。

(7)激活“数据在线恢复进程”，进程为“非正常联机数据库”，则执行数据库数据“同步”。在线同步恢复如失败，则将该“数据库”标志为“需要DBA维护”的类别，留待DBA或软件维护工程师处理。

3.3数据“读”流程

数据“读”流程的主要步骤如下：(1)客户端通过给定协议(或混合多种通信协议)向后台“系统服务总线”发送“读”请求。

(2)激活“写进程”，将客户端的“请求”写入“日志数据库”(或日志文件)，并分配一个唯一的“事件号”。

(3)“系统服务总线”查询“授权/控制数据库”(或/配置文件)得到客户端请求访问的数据存放的目标数据库节点N(或文件存放的节点N)、端口、用户、表等信息。

节点N可以是多点，即节点N>=1。

(4)“系统服务总线”查询“授权/控制数据库”(或/配置文件)得到可用的、空闲的目标数据库节点N(或文件存放的节点N)。

(5)激活“读进程”(或随机、或顺序)向N个节点的“业务数据库”(或文件)发送数据“读”访问请求，并得到各节点的返回结果集。

(6)“系统服务总线”将最快返回的结果集发回客户端;抛弃其他结果集，中断其他读进程。

在本系统的设计和实现中，由于采用了“分布式”数据库或文件系统部署，只要N个节点中至少有一个节点的“业务数据库”正常工作，因为一个或几个“业务数据库”系统(或节点硬件)故障所引起的业务系统的不可持续性理论上将可以完全避免，因而提高了系统的“容错”性。

由于N个数据库同时在线，且节点是否可用、空闲等状态可实时监控，这为特定业务快速访问和独享访问提供了先决条件。如可以指定某特定“业务数据库”仅为某个或几个特定客户端服务提供“读”访问。

因为设计了统一、标准的增、删、改、查的过程方法或API，前端开发人员甚至不必写任何SQL语句就可以完成对数据库中表或视图的操作，可以大大地缩短编程和调试时间。

需要指出的是，虽然“系统服务总线”具有“自我修复”和“自我复制”的特点，但因为“节点”硬件故障或“授权/控制数据库”(或/配置文件)或“日志数据库”故障而引起的全系统不可用依然存在，因此，建议该节点采用性能好、可靠性高的中、高端服务器。

篇2：高可用性软件架构设计和实现论文

12328电话系统由呼叫中心平台和电话管理系统平台组成。呼叫中心平台包括电话服务系统、短信服务系统、微信服务系统、服务监督网站、移动终端服务系统、邮件服务系统、转办受理系统、交办受理系统；电话管理系统平台包括业务处理系统、知识库系统、决策分析系统、运行管理系统。

（一）呼叫中心平台 1．电话服务系统

电话服务系统通过排队、接入、保持、录音、三方通话、外呼、转接等功能，为投诉举报、信息咨询、意见受理等业务提供电话受理渠道，并实现呼入弹屏、历史呼叫自动检索、数据项录入、知识库检索等功能。

博域通讯一体化呼叫中心平台产品BYICC2.0采用上表所述型号的呼叫中心行业主流品牌硬件作为本产品出厂时的呼叫中心系统硬件平台，从而为保障呼叫中心系统平台的电信运营商级稳定性奠定了坚实的硬件基础。采用博域通讯一体化呼叫中心平台产品BYICC2.0的呼叫中心系统硬件(专业部分)通常包括：[1]一体化CTI通讯服务器，模拟语音卡{包括通用底板，板载的功能模块如外线模块、坐席模块、内外线联合模块等，以及坐席铃流馈电电源}，数字中继语音卡{支持ISDN PRI[30B+D]信令以及中国7号信令[TUP、ISUP]以及中国1号信令的呼叫接续，支持75Ω E1同轴线、100Ω T1双绞线及120Ω E1双绞线等多种阻抗的数字中继线}，VoIP语音网关(VOIP语音卡){支持SIP/SDP/H.323协议}，CT-BUS总线电缆等；或[2]多媒体(语音)交换机{包括交换机机架、交换机中央主控板与后出线板、交换机功能板如模拟功能板/数字中继板/VoIP功能板/Asterisk功能板以及与功能板对应的后出线板、板载模块等}。作为一站式呼叫中心解决方案与开放式的标准的呼叫中心(联络中心)系统平台，博域通讯一体化呼叫中心平台产品BYICC2.0在一台CTI通讯服务器(多媒体语音交换机)上融合了呼叫中心系统的所有常用功能，这对于降低呼叫中心系统的建设和维护成本具有重要意义；博域通讯一体化呼叫中心平台产品BYICC2.0高度的集成性和整合性极大地回避了非集成系统普遍遇到的软硬件冲突以及不同厂家的系统接口的连接和配置难题，为企业/政府机关免去了昂贵的成本、复杂的网络连接以及众多服务器和程控交换机设备，大大地降低了呼叫中心系统的建设成本。博域通讯一体化呼叫中心平台产品BYICC2.0(也称为一体化呼叫中心系统产品BYICC2.0)致力于面向广大企业和政府机构普及呼叫中心系统(Call Center)。经过大连广播电视台、深圳地铁四号线、佛山水业集团、郴州市桂东县人民政府、岳阳市公安局交通警察支队、泉州市老龄办、招远市公安局、广东江门海关、黑龙江省人民政府采购管理办公室、大理广电、威海第二热电集团、丽江数字电视、滨州市博兴县教育局、深圳华强电子世界网、广西环江电力、中青旅山水时尚酒店、广州白天鹅宾馆、盘锦市司法局、南宁海方燃气、清远市劳动和社会保障局、贵州四方鼎立、长安铃木汽车、新疆特力电信、长沙三诺生物、昭通广电、广西出入境检验检疫局、巴彦淖尔市商务局、无锡生活在线、黑龙江省柴河林业局、淄博市淄川区城市管理行政执法局、西宁市财政局、文山广电、保山广电、西双版纳广电、大同市纪委监察局、无锡市民政局、恩施自来水、寻甸县第一人民医院、深圳市司法局、荆门市农业局、大宝化工、乌兰察布市住房公积金管理中心、云南省大理市第二人民医院、福建省莆田市老龄工作委员会、辽宁省数字证书认证中心、香港昌机集团等众多企业/政府机关呼叫中心成功案例验证的博域通讯一体化呼叫中心平台产品BYICC2.0作为CTI软硬件一体化平台开机即可使用，硬件平台采用呼叫中心行业主流硬件厂商(如杭州三汇、深圳东进、广州毅航通信、上海迅时通信等)的多媒体交换机和语音板卡以及VOIP语音网关，以ALL-IN-ONE/嵌入式的方式集成并固化了PBX/ACD/IVR/CTI/数字录音/语音信箱/VOIP[支持完全分布式、远程中继和远程IP座席方式的混合应用]/TTS/电子传真/来电弹屏（Screen PopUp）/人工座席软件/短信/统计报表软件/维护管理工具软件/智能自动外拨（也称为智能自动外呼或自动批量外呼）软件/客户关系管理(CRM)/工作流(派工单流转/电子工单流转)管理/与已有计算机技术支持系统的数据接口/易学易用的软件二次开发环境以及软件二次开发的模板程序源代码(呼叫中心系统第三方开发接口)/运营管理等核心的呼叫中心功能模块，同时提供定制化软件开发技术服务。博域通讯一体化呼叫中心平台产品BYICC2.0中的交互式语音应答(IVR)流程软件BYICCIVR2.0和座席软件BYICCAgent2.0以及统计报表软件BYICCReport2.0已经内置了经过规模商用验证的通用客户关系管理(CRM)功能，通常能满足大部分最终使用部门的业务功能需求。这里提到的通用客户关系管理(CRM)功能包括客户档案信息管理，投诉建议记录管理，业务受理记录管理，业务咨询记录管理，业务查询记录管理，客户回访记录管理，电话营销管理，派工单/工作流管理，销售业务管理，和与已有计算机技术支持系统(如MIS系统/GIS系统/OA系统/ERP系统/BOSS系统等)的数据接口等。作为易于建设/部署实施、易于管理/维护、易于二次开发的高度集成的呼叫中心系统平台成熟产品，对于CRM个性化业务功能需求较少的呼叫中心系统/客户服务中心系统项目(不论系统采用SS1/ISDN PRI/SS7的数字中继线路还是模拟电话线路，不论系统配置4个座席还是64个座席或120个座席)，采用博域通讯一体化呼叫中心平台产品BYICC2.0(也称为一体化呼叫中心系统产品BYICC2.0)的贵单位呼叫中心系统即装即用，在1个工作日内即可直接投入正式的商业运行。呼叫中心平台是指对各行各业的用户都适用的呼叫中心系统的通用部分，往往由专业的呼叫中心厂商提供。对于个性化应用较少的企业/政府部门，只需在呼叫中心平台上做个性化配置，呼叫中心系统就可以投入运营。对于个性化应用功能需求较多的企业/政府部门，则需要在呼叫中心平台上做二次开发，二次开发可以由系统集成商(SI)来完成，对于开发力量较强的企业/政府部门也可以自己进行二次开发。对于那些呼叫中心应用软件功能做得比较完善的高级呼叫中心平台，只需进行软件的个性化配置，而无须做二次开发。如果用户需要行业化的客户服务流程，则需外购专业的CRM(客户关系管理)软件。呼叫中心平台通过二次开发接口与专业CRM软件集成。因此，呼叫中心平台，就象房子的地基，支撑起呼叫中心系统的业务和系统负荷。呼叫中心系统的内核是以通信为基础的企业[政府机关]对内对外沟通联络系统，最具技术含量的核心部分是交换机系统PBX(Private Branch Exchange)以及CTI(计算机电信集成)系统；呼叫中心系统制造商需要依靠对通信技术的深刻理解，才能提供高稳定、高可用、高可靠的PBX系统以及CTI系统，灵活可靠地满足企业[政府机关]对于通信不断增长和变化的需求。呼叫中心中间件(即通常所讲的CTI中间件)产品是呼叫中心系统中的各种计算机系统与通信系统之间的桥梁，屏蔽了呼叫中心系统的底层通信的复杂性，为软件开发人员提供了一个简单而统一的易学易用的软件二次开发环境，减少了呼叫中心系统的程序设计的复杂性，在实施呼叫中心系统项目时将软件开发人员的注意力集中到最终用户的个性化CRM业务流程(如客户档案管理、业务咨询管理、业务查询管理、业务受理管理、投诉建议管理、客户回访与市场调查管理、工作流/工单管理、销售业务管理、与已有计算机技术支持系统[如MIS/ERP]的数据接口等)的定制开发上，从而大大减少了软件开发人员在技术上的负担。采用CTI中间件产品建设呼叫中心系统项目的显著优势包括：(1)减少呼叫中心系统项目的建设成本；(2)降低呼叫中心系统开发/实施的失败率；(3)缩短呼叫中心系统的开发周期；(4)节约呼叫中心系统的开发成本；(5)简化呼叫中心系统与已有计算机技术支持系统的集成/整合；(6)减少呼叫中心系统的维护费用；(7)提高呼叫中心系统的开发质量；(8)保证呼叫中心系统技术进步的连续性；(9)增强呼叫中心系统的生命力；(10)保护已有的投资。

2．服务监督网站

部级12328网站主要实现省级子网站导航和部级服务监督综合信息政务公开。地市级12328网站实现投诉举报业务受理、业务信息查询、政务信息公开等功能。省级不受理呼叫业务的，实现地市级子网站导航和省级服务监督综合信息政务公开；省级受理呼叫业务的，在提供地市级子网站导航和省级服务监督综合信息政务公开的同时，还需实现投诉举报业务受理、业务信息查询、政务信息公开等功能。

3．短信服务系统 12328短信平台实现投诉举报、信息咨询等业务受理和公众出行等公益信息发布，以及投诉举报处理结果告知等功能。

4．微信服务系统

实现投诉举报、信息咨询等业务受理，业务处理进展查询和结果反馈，公众出行等公益信息发布功能。

5．移动终端服务系统

移动终端APP实现投诉举报、信息咨询等业务受理，业务处理进展查询和结果反馈，公众出行等公益信息发布功能。

6．邮件服务系统

通过12328邮箱方式受理投诉举报、信息咨询等业务，自动形成业务受理工单，并通过邮件回复进行业务处理结果反馈。

7．转办受理系统

受理外单位或外部门转送的交通运输服务监督业务，实现工单生成、业务处理及结果反馈功能。

8．交办受理系统

受理上级部门交办的交通运输服务监督业务，实现工单生成、业务处理及结果反馈功能。

（二）电话管理系统平台 1．业务受理系统

业务受理系统接收电话、短信、网站、邮件、移动终端、微信等渠道受理的服务监督信息。工作人员通过业务受理系统对信息内容进行整理与记录后，按照《12328电话系统业务流程规范》填写电子表格，形成业务处理工单。

2．业务处理系统

与业务处理工作流程紧密结合，实现工单流转、催办督办、查询反馈、企业直通车、多渠道工单查重及并案处理、重大投诉举报处理等功能。

3．统计分析系统

结合对12328电话业务统计数据的挖掘整理，实现相关类型数据的同比分析、环比分析，结合管理决策的需要实现行业热点分析、行业动态预警、行业专题分析、趋势分析等功能。

4．知识库系统

知识库系统具备知识生命周期管理、多库管理、文档锁定、知识版本控制、知识导入导出、知识维护流程管理、编码管理、配置管理、系统管理等功能，能结合结构化数据和非结构化数据对图文、表格等多种类型数据知识进行采编、查询和管理。知识库系统一方面可作为一个独立系统提供信息查询服务，另一方面可通过与电话管理系统整合，结合具体业务运行数据的积累，实现相关知识信息的动态更新。

5．运行管理系统

篇3：高可用性软件架构设计和实现论文

基于ATCA的高级电信计算架构的系统, 虽然在硬件设计上就考虑了系统的高可用性要求, 但是要达到电信级99.999%的高可用性, 除了硬件设计上采用冗余设计模型, 软件设计上同样要采用一些提高系统可用性的措施来保证系统的高可用性。大多数的系统不能很好的处理由于系统失效所引起的运行系统的配置改变, 而需要通过频繁的强制性的故障点检测机制来保障系统的可用性, 这样势必影响运行任务的效率, 甚至要通过完全重新启动相关的系统服务或者整个机器才能使系统重新正常工作。共享会话信息和状态信息的冗余硬件设备使得物理链路的冗余成为可能。动态选举算法可以消除人为干预的需要, 这样就可以及时地完成失效恢复。本文中将展示一种灵活的、可动态装载、基于组件模块化的高可用性框架, 大大地扩展了高可用性计算能力, 使得在ATCA高级电信计算平台上的所有设备能够协同、高效地保证系统服务的高可用性, 并且允许根据系统的实际属性和应用的需要来适配和调整设计。

二、技术方法介绍

目前在基于ATCA高级电信计算架构的系统中对待这种失效问题通常采取的解决方案就是失效容忍或间隙恢复法 (Gap Recovery) 和反转恢复法 (Rollback Recovery) 。然而, 大多数系统并不能有效地解决由于失效问题引起的运行系统配置改变, 而需要完全重新启动必要的系统服务甚至是整个机器设备。高可用性力图通过预防措施避免意外的失效问题发生。高可用性措施目前主要是集中解决单节点服务的连续正常工作的情况, 而我们需要将这些努力进一步扩展到基于ATCA高级电信计算架构的整个系统环境的所有共同协作的设备节点和服务上。

有很多种实现高可用性服务的技术, 其中主要包括主/从型热备份技术、不对称式主/主型热备份技术和对称式主/主型热备份技术。主/从型热备份技术遵循上述失效模型。各个服务任务的状态都定期的保存到某些稳定的共享存储介质中或通过网络发送给相关的热备份组件。当服务失效时, 热备份的系统设备就可以根据所得到系统最近的或当前状态信息接管系统服务。这种方式会引起由于系统恢复或者系统根据获得的旧的系统备份状态信息回滚到系统从前的某个状态下而导致的短暂服务中断。不对称式主/主型热备份技术比主/从型热备份技术更加有效的提高系统的可靠性、可用性和可服务性。在这个模型下, 多个设备节点提供相同的服务, 但是缺乏协作, 即当一个主用设备在故障发生的情况下, 其他主用设备接管服务来保证服务连续可用从而提高系统不间断服务能力, 然而由于在所有参与互备份的设备间缺乏协作能力, 不能智能的同步主用设备间的状态和控制信息, 而使得其仅仅适合有限的应用场合。对称式主/主型热备份技术通常由两个或多个运行相同服务的设备协同工作来保障系统提供连续服务能力。这种技术可以使用分布式的控制机制或扩展虚拟同步机制来维护一套公共的全局性的系统状态信息。

本文中阐述的方法可以扩展基于ATCA高级电信计算架构的系统的高可用性能力, 从而确保系统有能力在热倒换硬件组件的时候, 可以动态地感知系统配置。为了使基于ATCA架构平台下的系统更具有未来的挑战性, 本文提出了一种对称式主/主型高可用性热备份技术的系统软件框架, 从而很好的克服上文中提到的其他方法所存在的系统服务可用性低的弊端。

三、技术方案设计与实现

为了提供这种适用于基于ATCA架构的主/主型热备份高可用性系统, 本文提出了一种灵活的、模块化的和可动态装卸载的高可用性组件框架模型。主要由四个层次构成:通讯驱动层、成员组通讯系统层、分布式控制接口层和应用服务层。

其中最底层的通讯驱动层提供各种适配底层硬件所对应的网络协议模块, 可以为上层提供单播和组播消息服务能力, 同时也提供相关的失效检测机制。成员组通讯系统层提供组成员管理、外部故障检测和可靠的组播机制和成员组内的组播消息算法。分布式控制接口层建立一个成员组系统和应用服务层之间的通道, 为应用服务层提供更易于调用成员组通讯系统层的一个标准服务接口以及分布式控制、状态机控制、checkpoint模块、消息模块和动态选举机制模块等丰富功能。应用服务层包括各种为用户定制的服务应用程序, 例如系统监控模块、文件服务模块、日志服务模块和时间服务模块。

这个高可用性框架本身就是基于组件化的独立模块组成。各个逻辑层之间以及各个模块之间都是通过消息服务模块提供的同步和异步消息机制来进行通讯的。每一层都可以由其他提供不同特性具有相同服务功能的模块层所替换。这种框架允许软件模块使用共享库、动态库或插件技术来实现模块的替换。下面详细介绍各个层。

(1) 通讯驱动层

目前ATCA高级电信计算架构系统支持许多种网络技术, 例如Ethernet、Infiniband、Star Fabric、PCI Express、Rapid IO等多种交换协议。本文的高可用性框架可以支持ATCA硬件提供商所支持的各种网络技术以及现存的协议标准。利用通讯驱动层可以在高可用节点设备之间建立起有效的通讯机制, 以便使这些设备通过分布式控制接口层来更好的为上层应用服务提供网络通讯服务。

使用通讯驱动层来适配不同的网络技术并抽象出统一的通讯API应用程序接口, 可以提高系统的互换性和互操作性, 这一概念并非新东西。

消息服务模块指的是缓存的消息传递系统, 可以提供相同节点上不同任务或不同节点间消息队列。一条消息队列允许多对一的通讯。当消息队列关闭时, 如果消息还没有使用, 消息服务模块必须保留消息到使用完为止。即当主用活动节点失效后, 备用节点负责接收并处理相应的消息, 直到备用节点倒换生效后, 消息服务模块才彻底删除此消息。

此外, 目前通讯驱动层仅仅提供处理原始数据报文的接口, 高层协议主要在成员组通讯系统层来进行管理的。这一层主要借鉴和参考RMIX框架模型, 提供动态的、支持系统异构性 (诸如字节序和高级协议等) 、可重新配置的通讯框架。

(2) 成员组通讯系统层

成员组通讯系统层包含所有必要的协议和业务, 这些协议和业务都是服务于主/主型热备份高可用性框架, 并且通过分布式控制接口层为上层应用服务提供组成员间通讯服务的, 同时也适合于主/从型热备份高可用性系统等其他高可用性系统模型中为多个热备份的从设备提供状态信息一致性复制服务。成员组通讯系统层也提供组成员管理、外部故障监测、可靠的组播机制和成员组内的组播消息算法。本层有许多第三方中间件和开源中间件项目可供参考, 例如SA论坛中AIS应用接口文中AMF高可用性管理框架就可以作为参考模型。由于不是本文的重点, 故不作详细讨论。

(3) 分布式控制接口层

分布式控制接口层所支持的应用程序接口API要基于应用特性实现。确定性对称式应用可以使用内存、文件、状态机和数据库的接口实现, 不确定性非对称式应用可以使用分布式控制接口和远程过程调用 (RPC) 接口实现。这些应用属性完全基于成员组通讯系统层的要求, 例如任务调度的批处理程序在一个集群系统中的所有主用的活动节点上运行, 并且维护着一个全局性的状态信息。每个活动节点都会以相同的顺序接收这些状态的改变并维护一致的状态信息。任务调度请求信息送达到这些活动节点中的任意一个, 导致了状态信息改变, 其他的活动节点也将以相同的顺序接收到这些请求。利用控制状态机机制, 保证任务调度程序的流程对于成员组通讯系统中的每个节点都是确定的。当流程结束时, 检查在系统中的状态信息是否符合仲裁规则, 若符合, 则更新信息到分布式虚拟同步数据库, 否则认为状态更新信息无效。

本系统实现高可用性的关键在于通过本文中提到的动态选举机制来实现主用节点间的状态同步功能或主用节点间的倒换功能, 从而保证了系统的持续不间断的工作。下面详细介绍一下动态选举算法。为了确保系统的高可用性顺利执行, 每个节点必须维护相当数量的本地状态信息。这些状态信息通常称为会话信息。会话信息只不过是一组数据, 通过对这些信息的学习、解析和基于指定选举规则的计算, 从而选举出系统主用活动节点, 保证系统服务的连续高可用性。先介绍一下算法中会用到的一些基本概念和关键字。

①节点的初始化状态视图, 表明算法开始时的所有节点状态信息。所有节点看到的初始化视图信息都是一致的。用W表示。②历史主用活动节点, 系统在没有新的会话信息更新前根据动态选举机制选出的主用活动节点。③根据给定节点q产生的会话更新信息选举出的主用活动节点。初始时, 所有的节点项会话信息等于上述中初始化视图信息W。④节点的不明确会话信息集合。这些是所有节点的不明确会话信息集合列表。⑤会话序列号, 初始为0, 用于对新会话的计数。⑥布尔型标志状态位表示本节点当前状态是否是主用活动节点状态。

无论何时系统的拓扑连接发生改变, 新视图中的节点就会开始两轮消息确认流程。节点在第一轮消息时, 交换所有节点的内部状态信息, 主要发送各自节点的不明确会话集合信息和历史主用活动节点信息等。如果当前节点根据动态选举算法的仲裁规则准备试图成为当前视图会话的主用活动节点, 就要发送第二轮消息。如果第二轮消息被所有节点成功接收到, 那么当前节点就成功成为主用活动节点。如果第二轮消息没有成功接收到, 可能是由于其他连接的变化, 那么试图成为主用活动节点的节点就再次形成不明确状态, 重新开始新的一轮选举。节点的解析规则允许节点在拓扑连接变化而被隔离后, 再次和其他节点取得连接时, 其依然能够根据解析规则来更新内部状态信息, 并且节点能够学习到连接中断期间的会话信息。

一旦算法完成了同其他节点的状态信息同步之后, 算法开始决定当前节点是否成为当前视图状态信息下的新主用活动节点。主要是通过节点从所有接收到的不明确会话信息中学习各节点的状态更新信息, 然后根据会话状态更新信息的解析规则, 就可以最终判断出当前节点是否能够成为当前视图状态下的主用活动节点。主用活动节点的确定机制主要是依赖于动态选举原理来完成。即选举结果主要是根据历史主用活动节点和所有的不明确会话信息集合依据选举策略算法规则来决定当前节点是否可以成为新的视图信息下的新主用活动节点。如果多个主用节点同时声明自己要成为主用活动节点, 那么就要根据其他信息来决定谁将成为新主用活动节点。习惯上, 业内是根据节点的IP地址或节点名称来选择, 通常选择节点IP地址小的或节点名称的字典排序靠前的节点成为最终的主用活动节点。

(4) 应用服务层

本文中涉及的高可用性框架由于底层设计方面的灵活和强大功能, 故可以提供很多不同类型的应用, 支持各种不同的计算场合的需要。这些应用包括:系统监控服务、文件系统服务、日志服务、名字服务、时间服务等用户定制的各种服务。

四、总结

本文提出的灵活性、动态化、基于组件式的高可用性系统模型可以极大地提高系统的无故障持续工作能力, 充分满足基于ATCA架构系统的电信级99.999%的高可靠性和高可用性要求, 大大优于传统集中式单点控制型的高可用系统可持续服务能力。其中可动态装卸载的通讯驱动层模块设计技术允许系统无缝地实现对不同硬件设备提供商所提供的网络技术和相关的底层网络协议的支持, 大大提高了系统的互通性和互操作性, 降低系统集成成本。特别是上文中介绍的动态选举机制和checkpoint模块、分布式控制模块以及状态机控制模块共同完成主用节点间的状态同步功能和主用节点间的协作, 从而确保了系统的持续不间断的工作能力的极大提高。采用本方法可以在不升级硬件的条件下, 仅仅通过软件设计满足基于ATCA架构的电信级系统设备在不会对系统效率和系统性能产生较大影响的前提下, 大大地降低产品成本, 缩短系统研发周期, 极大地提高了系统的高可用性要求, 产生重大的经济效益。

参考文献

[1]PICMG 3.0“, AdvancedTCA (Base Specification) ”Rev3.0 24-Mar-2008http://www.picmg.org/v2internal/specifications2.cfm?thetype=One&thebusid=2.

[2]PICMG 3.1, “AdvancedTCA Ethernet”Rev2.0 3-Aug-2012http://www.picmg.org/v2internal/specifications2.cfm?thetype=One&thebusid=2.

[3]PICMG 3.2, “AdvancedTCA InfiniBand”Rev1.0 22-Jan-2003http://www.picmg.org/v2internal/specifications2.cfm?thetype=One&thebusid=2.

[4]Service Availability Forum Hardware Platform Interface Specification SAI-HPI-B.03.02, 4-Aug-2009, http://www.saforum.org/link/linkshow.asp?link_id=222259

[5]马克思 (美) 等著“, 高可用性系统设计”, 汪青青, 卢祖英译.北京:清华大学出版社.2005-07-01.

[6]Sean Dague, Kevin gao, David Judkovic, Rusty Lynch, Louis Zhuang, Tariq Shureih, Thomas Kanngieser, Renier Morales, “OpenHPI Manual”, http://openhpi.sourceforge.net/manual/book1.html

篇4：实现医院信息系统高可用性设计

浙江大学医学院附属第一医院(简称浙医一院)系三级甲类综合性医院,是浙江省医疗、教学与科研指导中心之一,现有职工2500余人,开放床位1600多张,年门诊量180万人次,高峰期日门诊量近9000人次,年出院人次3.3万,年手术人次2万余,拥有PC机1500台,打印机760台。

原先HIS服务器系统为两台Alpha Server ES45,配置4个CPU,4GB内存和一台RA7000磁盘阵列,通过SCSI连接,构成Cluster系统,在系统中主要运行Oracle8.0.5数据库,整套系统在高峰时段的CPU利用率已接近100%。2007年初,新的病房大楼投入使用,开放床位扩大到2500张,这样原先的HIS服务器的性能、可用性、安全性等都不能适应要求,而随着医院业务规模的不断提高,对IT系统的可靠性要求则越来越高。HIS系统已经是整个医院日常有序运行的基础,如果出现故障,将造成整个医院业务的中断,所以在新一代系统升级中,系统的可用性、可靠性成了重中之重,要做到系统没有任何一个单点故障。

2 系统设计

在对系统进行升级时,考虑了今后3至5年的发展需求,经多方考察论证,最后选定了系统方案,其结构如下图所示。

采用2台HP rx8620服务器作为数据库服务器,组成集群系统,rx8620目前配置10个处理器,40GB内存,采用两个EVA4000磁盘柜,通过Mirror Disk/UX软件实现两个磁盘柜之间的冗余备份,整个系统没有任何一个单点故障。系统运行ORACLE 10g RAC并行数据库,实现了应用的负载均衡,采用千兆以太网作为高速互连设备。为了防止人为误操作而造成数据库无法正常启动,采用了ORACLE Data Guard高可靠性数据库解决方案,建立一套Data Guard RAC2数据库系统,作为生产数据库RAC1的备份数据库(Standby Database),系统自动把生产数据库RAC1的Log文件发送到备份数据库Data Guard RAC2,然后自动更新到备份数据库。

一般情况下做ORACLE Data Guard需要配置单独服务器和存储柜,为了节约医院的投资,把Data Guard与生产用服务器放在一起,平时只在一台服务器上启动Data Guard实例,由于该实例消耗CPU的资源不到5%,所以这种方案既节省了投资,又保证了高可用性、高安全性的要求。

rx8620是一款32路主机,采用惠普公司的Superdome服务器体系构架,采用基于cell板的模块化构架,这使rx8620同样可以做到基于电子故障隔离的硬件分区技术(n Partition)、基于软件的分区技术(v Partition)、资源的分区技术(Resource Partition)和基于目标的资源管理(WLM)。rx8620采用cross-bar交换机技术,这样,系统内存带宽可以达到64GB/s,CPU带宽可以到51.2GB/s,I/O带宽可以到16GB/s。

SAN技术是目前比较流行的存储技术,网络化存储,是目前大型企业存储整合的理想解决方案。本项目,采用SAN技术来整合整个IT系统,建立一个集中化的SAN存储网络。提供2台16端口的4Gbps标准的SAN交换机,组成一个冗余互备的SAN网络,所有主机通过两条冗余互备的SAN链路联接到SAN网络中。

采用两台HP虚拟化存储设备EVA4000磁盘柜,最大配置提供33TB的存储容量,在本项目中,每个EVA4000磁盘柜提供14个146GB的磁盘,共4TB的容量,通过运行在HP-UX操作系统Mirror Disk/UX实现两个EVA4000磁盘柜之间的镜像,两台服务器的任何数据读写都会同时写到两个磁盘柜上,通过HP MC/Service Guard Extension for RAC软件,提供ORACLE RAC并行计算的文件系统支持,当任何一台服务器发生故障之后,其上的应用系统自动切换到另外一台服务器上,整个过程对于应用系统是透明的。当任何一台EVA4000磁盘柜发生故障之后,不会中断应用系统的运行,当故障EVA4000磁盘柜修复之后,可以在线地把修复的磁盘柜加入到运行环境中。EVA4000磁盘柜能够同时支持多台异构平台的共享访问,包括UNIX、WINDOWS、Open VMS、Linux等,通过磁盘柜的安全控制机制保证不同主机单独访问各自的存储空间。EVA4000的虚拟化技术是对传统RAID技术的一次革命,通过虚拟化技术,大大提高了EVA4000磁盘柜的访问性能,提高了磁盘柜的可靠性和可管理性。

Oracle Data Guard除了用于容灾目的之外,还可以提供其他类型的功能,比如把Data Guard数据库作为Report和查询数据库来使用,以及有效克服生产数据库无法打开的特殊故障。但生产数据库无法打开时,传统的工作备份恢复过程需要比较长的时间,造成业务停机时间过长,如果有了Data Guard备份数据库,用户可以迅速把Data Guard备份数据库转为生产数据库,立即投入使用。

3 应用讨论

在高可用性和安全性要求中,针对各种可能发生的故障问题,系统采取了应对措施:

服务器故障。服务器故障可以通过M C/Service Guard集群软件,自动把集群系统资源,包括通过Mirror Disk镜像完成的共享文件系统,网络浮动IP地址等,切换到另外一台服务器上。由于ORACLE数据库采用RAC并行模式运行,所以,不会发生切换过程。

集群心跳线故障。配置了两个互为冗余,又负载均衡的千兆以太网作为集群心跳线,任何一个网卡或链路发生故障,都不会影响应用程序的正常运行。

网络故障。配置了两个互为冗余,又负载均衡的千兆以太网作为数据网络,任何一个网卡或链路发生故障,都不会影响应用程序的正常运行。

SAN存储网络故障。配置了两个互为冗余的SAN交换机,任何一台交换机发生故障之后,都不会影响应用系统的运行。

磁盘柜故障。磁盘柜本身的任何部件也是全冗余的,没有任何单点故障,在可靠性上比单台服务器的可靠性高,但是,仍然有可能发生人为故障,或者固化软件BUG所引起的故障,在本方案中,通过Mirror Disk/UX软件,实现两个磁盘柜的镜像,保证任何一台磁盘柜发生故障之后,系统自动切换到另外一台服务器上,不会影响应用系统的正常运行。

人为误删除。通过以上的冗余措施之后,系统在硬件方面能够克服除了灾难之外的所有故障,但是仍然无法解决人为的误删除或数据文件逻辑错误等造成的数据库的数据丢失或不一致。对于数据文件逻辑错误导致ORACLE数据库不能启动,通过启用Data Guard来解决;对于人为误删除,目前ORACLE数据库提供两种解决方案:方案一、在误删除之后,到系统生产RAC的LOG文件更新到备份Data Guard RAC数据库之前(因为Standby数据库可以在只读方式下打开),这段时间内,备份数据有一套正确的数据保留着;方案二、ORACLE 10g数据库提供Flashback功能(闪回功能),可以查找删除数据之前某一时刻的数据,同时提供了Recyclebin,类似于Windows的垃圾箱功能,它是把Drop的表先放入Recyclebin,不是直接物理删除,所以用户可以从Recyclebin去恢复误删除的表。

在本方案中,采用包括从硬件到软件全方位的冗余解决方案,实现无单点故障,有效地克服了人为的误操作所导致的系统停机,2006年12月初,整套方案在浙医一院成功启用,运行稳定,性能良好,平时CPU使用率在10%以下,原先从2000万条记录的表中查找总记录数需30分钟,现在只需2分钟,达到了系统重构和升级的实际目标。

摘要：结合浙江大学医学院附属第一医院的实际案例,通过对服务器、数据库系统的实际选型,论述了如何实现医院信息系统的高可用性、负载均衡和安全性。

关键词：医院信息系统,高可用性,负载均衡,ORACLE RAC,Data Guard

参考文献

[1]冯春培等,ORACLE数据库DBA专题技术精粹.冶金工业出版社.2004

[2]滕永昌,Oracle10g数据库系统管理.机械工业出版社.2006

篇5：软交换系统软件架构设计与实现

软交换概念的提出至今,经过了多年的发展实践,相关的技术标准、规范正逐步成熟和完善。人们对软交换技术的认识和应用的思路也随着实际工作的深入和实践领域的拓宽,发生了相应的变化和重点的转移。

软交换机是电路交换网向分组网演进的核心设备,也是下一代网络的重要设备之一,它独立于底层承载协议,主要完成呼叫控制、媒体网关接入控制、资源分配、协议处理、路由、认证和计费等主要功能,并可以向用户提供现有电路交换机所能提供的所有业务以及多样化的第三方业务。它基于业务与控制相分离、控制与承载相分离的思想,通过开放的接口和业务提供的灵活性带来网络结构更加清晰、业务提供更加丰富灵活、建设和维护更加有效等好处。

软交换系统在公网的应用部署已经进入了稳定的发展时期,而在专网通信系统中软交换系统的建设也即将进入快速发展期。软交换系统的蓬勃发展需要学术界、工程界、用户和设备制造商等多方的努力才能发展得更好。以远东哈里斯通信有限公司的软交换机研发经验为基础,描述了一个软交换机系统软件的架构设计实现。

1 系统设计依据及要求

软交换机系统软件的设计是以原信息产业部发布的行业标准《YD 1434-2006-I软交换设备总体技术要求》为设计依据的,并严格遵循该标准中对关键功能、技术指标、系统架构和业务提供等方面的设计要求;同时,系统开发完毕后的功能测试也以能通过《YD 1435-2006-I软交换设备测试方法》中规定的测试项目为最低要求。

在保证符合《YD 1434-2006-I软交换设备总体技术要求》中规定的各项要求的前提下,重点设计了如下的功能:

① 系统的高可靠性;

② 系统对多种终端协议类型和中继协议类型的支持;

③ 大容量,支持10万用户以上规模的应用;

④ 行政通信与调度通信可以合一;

⑤ 支持多种组网方式;

⑥ 支持多种宽窄带业务,并提供业务开发接口;

⑦ 系统具备完善的监控和管理能力。

对于上述重点设计要求,在进行系统框架结构设计时,均提出了有针对性的技术解决设计方案。

2 系统软件架构设计

软交换机系统软件的框架结构如图1所示。系统共分为6个子系统:协议接入和适配子系统、通用呼叫和资源控制子系统、业务接入子系统、公共服务子系统、HA高可用子系统、操作维护管理(OAM)子系统,其中有些子系统又可细分为更具体的下一级子系统或功能模块。下面将逐一对每一个子系统的功能、关键子模块及设计要点进行设计说明。

2.1 协议接入和适配子系统

协议接入和适配子系统主要完成对多种终端协议和中继协议的接入和适配工作。该子系统以模块化的形式实现了对多种协议的接入设计,同时也便于增加新的接入协议。其中协议接入适配模块的设计功能是将各种不同的协议信令抽象转化为软交换系统内部的统一消息,或将通用呼叫和资源控制子系统下达的控制指令转换为对应的协议信令并传递给协议模块;各个协议模块分别完成对应的协议消息的接收/发送、解包/打包等功能。由于篇幅限制,下面仅给出了七号信令接入模块和SIP协议接入模块的框架结构。

2.2 通用呼叫和资源控制子系统

通用呼叫和资源控制子系统完成对呼叫的处理和控制(包括呼叫控制、连接承载控制、资源控制等),并在呼叫事件符合应用业务所设定的触发点时,激活上层的应用业务来对呼叫进行控制。该子系统是软交换机的核心控制模块,呼叫关联模型和基本呼叫处理是它的2个关键模块。呼叫关联模型和基本呼叫处理2个模块的设计吸收了智能网技术中成熟的呼叫模型技术,并对其进行了改进和扩充。其中,基本呼叫处理模块主要实现呼叫控制和连接承载控制功能,而呼叫关联模型模块一方面向上层提供呼叫的关联关系,另一方面实现单点控制、多点控制和多媒体处理功能。鉴权与认证和资源管理是该子系统的另外2个关键模块,它们负责对软交换机控制下的网关、终端和媒体服务器等周边设备进行鉴权和维护管理。

通用呼叫和资源控制子系统实现了SIP Server或者H.323网守的大部分功能,在实际使用中,可代替SIP Server或H.323网守来使用。接入模块的框架结构如图2所示。

2.3 业务接入子系统

业务接入子系统主要完成提供部分内嵌业务逻辑和对外提供业务开发接口以便于新业务的提供。其中内嵌业务逻辑子系统主要提供各种补充业务,箭头表示消息的传递方向。INAP协议适配接口子系统用于与业务控制点(SCP)设备进行连网,SCP设备通过INAP协议为软交换系统提供智能网业务。安全管理接口子系统为PARLAY API和JAIN API业务接口提供安全管理功能。PARLAY API模块和JAIN API模块负责将业务能力适配子系统呈现的业务视图分别使用PARLAY API和JAIN API的形式来呈现给外部应用服务器,并由外部服务器上运行的业务逻辑通过调用PARLAY API或JAIN API来为软交换系统提供业务。业务能力适配子系统负责将系统内的私有的业务能力适配统一消息分别在其上层系统所使用的协议、消息或API之间进行转换。

业务接入子系统在内嵌业务逻辑子系统内设计了调度通信业务逻辑,该业务逻辑通过SIP协议和外部调度台进行通信,共同配合组成一个完整的调度通信系统。通过许可文件可屏蔽软交换机的调度通信业务,使软交换系统专一完成语音、数据和多媒体的行政通信功能。其系统结构如图3所示。

2.4 公共服务子系统

公共服务子系统主要负责屏蔽操作系统的差异性,并为操作系统之上的应用提供各种基本功能的二次封装,例如内存管理、定时服务和信号量等。该子系统是由众多函数库和服务进程组成。公共服务子系统为特殊条件下的系统移植打下了良好的基础。

2.5 高可用子系统

高可用子系统(High Availability Subsystem,HA)负责整个软交换机系统的热冗余备份功能的实现。软交换机被设计成为了1+1热冗余备份的系统,平时工作时分主用机架和备用机架,主用机架之上的HA高可用子系统负责将主边呼叫中的稳态数据实时的发送到备用机架,并由备边HA高可用子系统将数据分发给各个相关进程进行数据更新,同时HA高可用子系统负责维护数据的一致性;另外,当备边重启完成后,备边的HA高可用子系统负责向主边的HA高可用子系统索要冗余数据。HA高可用子系统的框架结构和模块构成如图4所示。

2.6 OAM子系统

OAM子系统是由多个独立运行的进程组成,每一个进程完成一个特定的功能。这些进程与外部的GUI程序或者WEB应用程序进行消息通信,从而完成人机交互;对内与软交换机内部的各模块或子系统使用私有协议进行消息交换。OAM子系统完成的功能如下:命令行解析和处理、提供SNMP协议接口、数据配置管理、CDR管理、错误管理、告警管理、消息和信令跟踪、日志管理、业务量统计、内存数据管理、拥塞控制和系统安全管理等功能。

3 系统实现

考虑到基于ATCA(高级电信计算架构)技术标准的硬件平台是技术发展的趋势,以及该平台在系统扩展性、可靠性、稳定性、计算能力上的优越表现,软交换机的硬件平台采用了ATCA技术标准的机箱和单板。

为了满足电信级的应用需求,操作系统采用了符合CGL 4.0规范的、WindRiver公司的、电信级的、实时的、嵌入式的Linux操作系统。

系统核心模块的开发全部采用的是标准C语言,少量程序采用了Shell编程。外部GUI采用Delphi语言,Web应用则采用了Perl、ASP.net、Java等语言。

为了保证系统在大话务量下对数据存取的速度要求,系统采用了高速内存数据库技术,关键数据常驻内存,系统负载较轻时再进行硬盘数据的交换。

依据软交换机许可文件提供的系统最大并发数等数据,系统在进行初始化时,会依据上述数据进行精确的内存池分配,对能够处理的最大呼叫量、允许注册的最大用户数、业务呼叫量等关键数据在各个模块或进程内所需要的内存池buffer个数和大小,进行精确的计算和分配,从而可以根据实际需求对硬件能力和系统容量进行精确的配置。

4 结束语

描述了一个软交换机系统软件的框架功能结构及其概要实现过程,论述的设计思想已经被应用于实践开发。经实践证明,该框架结构设计思路清晰,结构合理,充分实现了系统的设计要求和目标,对实际开发工作有很强的指导作用。同时提及的设计思想对于同类开发或研究项目而言也是一种有益的参考。

参考文献

[1]YD1434-2006-I.软交换设备总体技术要求[S],2006.

[2]YD1435-2006-I.软交换设备测试方法[S],2006.

[3]齐幸辉.软交换内嵌业务逻辑子系统框架结构设计[J].计算机与网络,2009,35(366):45-47.

篇6：软交换机高可用平台的设计与实现

高可用性(HA)是指通过运用硬件或软件冗余技术来减少常规维护与系统故障引起的停机时间,使系统持续运行。电信设备的可用性指标为99.999%,这意味着一年中因各种原因导致的不可用时间不得超过5 min。

软交换是下一代网络(NGN)核心,是一种基于包交换、以软件来实现交换与呼叫控制管理的电信网络新技术。它将各种的接入数据以分组的形式在IP骨干网上传输,从真正意义上实现了目前各种网络的整合。

软交换机位于软交换网络的控制层面,是软交换网络的核心。因此它的可用性将直接影响到整个网络的服务质量。本文通过对HA的研究,提出了一种软交换机高可用平台的解决方案。

1 可用性分析

可用性是指系统正常的运行时间与总的运行时间之比。系统的正常运行时间用平均无故障时间(Mean Time Between Failures,MTBF)表示,总的运行时间应用平均无故障时间加上平均故障修复时间(Mean Time To Repair,MTTR)表示。MTTR表示在人员、工具和材料等条件具备下,修复故障平均所需要的时间。则可用性A为:

undefined。 (1)

从式(1)可以看出,要提高系统的可用性,应该从2方面入手:缩短平均故障修复时间;延长平均无故障时间。

当系统上运行的程序产生不正确的结果或根本不能提供服务时,就表明已经发生了故障。研究表明,在系统出现故障之前,其内部就可能已经产生错误(Error)。错误可以被发现并进行纠正,潜在错误在一定条件下才会被激活,一个激活的错误会从一个组件扩散到另一个组件,产生新的错误。错误表现出来的现在上的诱因是失效(Fault)。它可能是一种电磁干扰、程序缺陷、操作员发出的错误指令或者已经损坏的组件。在系统发生故障前,能正常运行一段时间,突然出现故障,然后故障被修复,接着恢复正常工作,系统将不断重复这一周期。

通常系统确定之后,它的MTBF是确定的,几乎不可能改变,所以需要尽可能地减少系统的MTTR,延长系统运行周期中的平均无故障时间,来提高系统的可用性。这样就意味需要采取各种措施和技术来最大限度地减少系统的故障修复时间。需要在2个方面努力:① 在系统故障之前就需要监测到某种征兆,采取及时的修补策略,从而避免故障的产生;② 在故障产生之后,采取快速的恢复策略和技术,减少故障修复时间。这样才可以最大限度地减少故障修复时间。对于可能出现的各种故障要采取有针对性的策略和技术,又需要综合应用,权衡之间的制约关系,运用组合的策略。

2 软交换机高可用平台的实现

2.1 高可用软交换系统结构

高可用系统和非高可用系统的最本质的区别是:高可用系统需要提供系统状态实时监测和系统故障管理。系统状态实时监测的目的是监视系统的健康状态,及时发现系统中的故障;系统故障管理的功能是发现系统出现故障后,对故障模块进行修复,当修复失败后进行系统切换。

要完成这样的功能需要在系统中增加一个专门的模块来实现,这个模块称为HA管理中间件。HA管理中间件与系统的其他模块有接口,HA管理中间通过这些接口来监测各个模块,收集各个模块的运行状态,当检测到模块出现问题时,由HA管理中间件进行修复。本方案的整个软交换系统结构如图1所示,采用了系统级冗余,可分为4个部分。

硬件平台:由整个硬件和固件组成,通常由硬件设备制造商提供。它需要支持Windows、VxWorks、Linux和Solaris等操作系统。本方案采用ATCA硬件平台。

操作系统:为应用软件和HA管理中间件提供基本的进程调度和资源管理。

HA管理中间件:这是高可用平台的核心。包含了高可用平台系统提供的系统状态实时监测和系统故障管理等高可用平台系统的特有功能。

应用软件:支持HA的应用软件也需要提供和HA管理中间件的接口。HA管理中间件通过这些接口可以检测应用软件的状态,从而达到管理应用软件的目的。

通过对高可用软交换机的结构分析可知,软交换机的高可用平台是由HA管理中间件和HA管理中间件与其他模块的接口组成的。HA管理中间件是整个系统的核心,其设计的好坏直接影响到系统的可用性,高可用平台的设计很大程度是HA管理中间件的设计。

2.2 HA管理中间件实现

HA管理中间件的结构如图2所示。

启动管理模块:HA管理中间件第一个启动的模块,负责启动系统管理模块,监视系统管理模块的健康状态,处理HA管理中间件启动过程中与操作系统的信息交互。

系统管理模块:负责启动和关闭HA管理中间件的其他模块,并且监控这些模块的健康状况,维护平台的状态,是HA管理中间件的核心模块。

平台管理模块:监视硬件平台的状态,当硬件平台发生故障时通知系统管理模块。

复制管理:负责系统的数据同步和故障时的切换操作。同步数据需要一个可靠的同步通道——复制通道,复制通道是由ATCA背板提供的可靠冗余通道。在2个同步端点间使用SCTP协议建立和维护复制通道。备架的复制管理模块通过发送心跳消息来监视主架的健康状态。

软交换管理:监视软交换应用的各个模块的健康状况,当发现模块异常时,调用相应的预置的处理策略进行处理,需要切换时,发送切换消息给系统管理。

2.3 系统状态实时监测和系统故障管理

系统状态实时监测是通过发送心跳消息来实现的。HA管理中间件定期向被监控模块发送心跳消息,收集被监控模块的响应。当3次收不到被监控模块的响应或者模块报告自己出现故障时,HA管理中间件就要对这些检测到的故障进行分类,调用相应的程序进行处理,即故障管理。

故障管理包括故障修复和切换。HA管理中间件把被监控的模块分为核心模块和非核心模块,本方案采用双机热备冗余,HA管理中间件把对软交换机看作是核心模块。当检测到非核心模块故障时,首先对其进行修复,如果修复3次都失败,就进行系统主备切换。若检测到核心模块故障,直接进行主备切换,不调用修复程序。

在HA管理中间件的作用下,软交换机分为图3中的7个状态,下面简要介绍下状态间的流程。

启动时,由NULL状态加载系统配置,进入初始化状态。如果加载失败,再次进入NULL状态;若应用加载成功,进入就绪状态,HA管理中间件进行主备判断,进入正常主状态或者正常备状态。进入正常备状态后,备架的HA管理中间件开始监控主架的状态,如果检测到主架故障,发起主备切换,切换成主架,进入到正常主状态。在正常备状态下,任何一个被监控模块发生故障,都要重启备架。在正常主状态,软交换机开始对外提供服务,如果非核心模块故障,进入一般故障主状态,核心模块故障进入到严重故障主状态在一般故障主状态,对故障进行修复,修复成功重新回到正常主状态;修复失败或此时检测到核心模块出现故障,进入到严重故障主状态。在严重故障主状态,把故障信息写到系统日志中,然后重启进入到NULL状态。

3 测试

采用C语言实现了软交换机高可用平台,为检测其性能,采用故障注入法进行相应测试。把模拟的软件和硬件故障注入到系统中,测试高可用子系统能否检测到故障,判断故障类型,能否对故障进行正确的处理。

① 正常状态下的主备切换:在系统正常运行情况下,向主架发出切换命令。切换后,整个系统能继续对外提供服务,基本满足了主备切换的要求,测试正常;

② 主架非核心模块故障:向主架注入非核心模块故障,HA管理中间件能检测到故障,并调用预先设计好的修复程序对其进行修复,修复好后整个系统能继续对外提供服务;修复失败时,引发主备切换。切换后,整个系统能继续对个提供服务。符合高可用平台的设计要求,测试正常;

③ 主架核心模块故障:向主架注入核心模块故障,HA管理中间件能检测到故障,发起主备切换,切换后整个系统能继续对外提供服务。符合高可用平台的设计要求,测试正常;

④ 备架核心模块故障:向备架注入核心模块故障,HA管理中间件能检测到故障,重启备架,符合高可用平台的设计要求,测试正常;

⑤ 备架非核心模块故障:在备架注入非核心模块故障,HA管理中间件能检测到故障,没有进行故障修复,直接重启备架,符合高可用平台的设计要求,测试正常;

⑥ 主架硬件故障:在主架注入硬件故障,HA管理中间件能检测到故障,发起主备切换,切换后整个系统能继续对外提供服务,符合高可用平台的设计要求,测试正常;

⑦ 备架硬件故障:在备架注入故障故障,HA管理中间件能检测到故障,重启备架。符合高可用平台的设计要求,测试正常。

4 结束语

从以上测试结果可以看出,本文设计的高可用平台能够发现注入的各种故障,对故障进行分类,进行正确的处理,能够满足软交换系统对高可用性的基本要求。下一步的工作重点是如何进一步提高系统检测故障时间和制定更加高效的故障管理策略,最把软交换系统打造成一个可以自我调节、自我管理和自我诊断的智能系统。

参考文献