应用级容灾设计及功能规格书.docx
《应用级容灾设计及功能规格书.docx》由会员分享，可在线阅读，更多相关《应用级容灾设计及功能规格书.docx（32页珍藏版）》请在冰豆网上搜索。
应用级容灾设计及功能规格书
1文档介绍
1.1文档编写目的
编写《中国电信国际清算及应用容灾项目_应用容灾平台功能规格说明书》的目的是：
∙准确全面地定义和阐述中国电信国际清算及应用容灾项目_应用容灾平台的业务需求，明确建设目标和功能；
∙为中国电信相关业务部门和技术部门提供对这个系统的统一的文字理解：
为业务部门判断系统是否满足其业务需要提供文字依据，为技术部门设计与实现系统提供统一标准；
∙在设计中国电信国际清算及应用容灾项目_应用容灾平台之前尽可能周密考虑全部需求及设计要求，减少以后可能的重新设计、重新编码、重新测试等工作；
∙为方案设计、核定项目成本、编制计划进度提供准确的依据；
∙为对项目的完成进行验收提供基准；
∙为需求变更提供基准。
1.2文档阅读对象
本文档供以下相关人员阅读、参考和评审：
∙中国电信国际清算及应用容灾项目_应用容灾平台项目领导小组
∙中国电信国际清算及应用容灾项目_应用容灾平台项目管理组
本文档将为项目管理组制定和修改项目开发时间进度、项目计划、资源计划以及风险控制计划提供详尽的依据。
∙中国电信国际清算及应用容灾项目_应用容灾平台项目开发组
本文档将成为国际清算及应用容灾平台开发组进行国际清算及应用容灾平台设计和开发的依据。
∙中国电信国际清算及应用容灾项目质量保证和测试组
本文档将作为中国电信国际清算及应用容灾项目测试组制定和执行系统测试计划的依据，同时质量保证组将据此制定、修正和执行质量保证计划。
∙中国电信系统使用方
中国电信系统使用方将阅读并确认本文档是否在合同要求下，正确和完整地描述了业务需求；并将以此为基础进行系统验收。
1.3缩略语定义
缩略语
描述
中国电信
中国电信公司
惠普公司
中国惠普有限公司
DR
DisasterRecovery（容灾）
主系统（MasterSite）
处于生产状态的系统，其处理结果下发各省，用于实际财务结算
备系统（SlaveSite）
处于备份状态的系统，它跟从主系统同步处理，处理结果不下发，不用于实际财务结算
同步索引（SyncIndex）
用于主备系统的应用程序同步的核心信息，由主系统生成，由备系统解释执行
结果导入
将主系统处理的最终结果（包括下发文件、统计汇总报表等）通过网络传递到备系统，由备系统导入数据库或备份存档，以备查询
主备热线
指主备系统之间网络连接，用于传递同步信息或必要的数据文件
公参表
由最终用户维护的公共参数信息表，由所有子系统共享
随机变量
主系统的应用程序在运行过程中从外部环境（操作系统等外部接口）取得的具有随机性并影响处理结果的数据
结果
用户可以直接查询的最终结果表或文件，非进程运行的中间结果
HA（HighAvailability）
高可靠性，用于消除软硬件系统发生的单点故障（SPOF），而设计的主机冗余系统
切换过渡期
在发生灾难切换后，决定停止国内下发剔重的时间段。
1.4参考文档
参考文档名
版本
日期
1.5文档概要
本文档的以下其他章节的主要内容概述如下：
∙系统概述
本章节将概要描述中国电信国际清算及应用容灾项目_应用容灾平台的建设背景、总体架构和业务支撑功能等内容。
∙系统功能性需求
本章节将详细描述中国电信国际清算及应用容灾项目_应用容灾平台的功能性需求。
∙系统非功能性需求
本章节包含了对性能、安全性等系统非功能需求的详细描述。
∙使用用例概述
本章节将概要描述使用用例的总体和分解组织结构。
∙系统运行与开发环境
本章节将描述中国电信国际清算及应用容灾项目_应用容灾平台的运行与开发环境，包括硬件和软件环境配置详细信息。
∙附录
附录将包括需求编号命名规则、需求附件清单、业务流程规格说明书等内容。
2系统概述
2.1总体要求
本期主中心和容灾备份中心之间数据一致性的实现通过应用软件来实现。
应用软件开发时加入应用同步和数据稽核机制，使两中心的数据保持一致。
实施应用同步技术的前提是两个中心同时运行、拥有相同的输入数据，因此只需要对什么时候用什么系统处理什么数据进行应用同步，对处理后结果的正确性进行数据稽核，而不需要进行大批量数据的远程复制。
2.2灾难定义
应用容灾平台应可以对以下五类情况实现容灾：
——地震、战争、火灾等自然灾害和其它不可抗拒的灾难
——长时间无法修复性停电、大楼损坏等外部设备损坏的灾害
——主机升级、检修等计划性或策略性宕机等长时间无法正常工作
——人为失误造成的灾害（如主机系统、数据信息被严重破坏等）
——长时间无法修复电路中断（广域网线路故障）
即当主系统出现以上情况时，备份系统能够在短时间内接替、延续主系统的生产任务。
2.3应用容灾平台需要实现的功能
本期建设的全国计费结算容灾平台采用双中心异地容灾方式，双中心分别设置在北京和上海，要求计费结算系统的容灾基于应用方式实现。
容灾平台不仅要实现数据的容灾，同时在灾难发生后，要保证关键业务的连续性。
该系统将包含以下功能：
1）数据同步：
实现生产中心和容灾中心之间、以及容灾中心的应用系统之间数据的一致和完整。
2）切换、回切实现切换和回切过程。
2.4应用容灾同步机制
容灾平台中，生产系统是实际的运营系统，灾备系统也在运行之中。
为了保证灾备系统能够迅速切换成生产系统，备份系统的所有运行都要与主系统保持一致——同步。
应用容灾同步机制包括“处理顺序”和“处理时间”两个要素，主系统处理，备系统跟从。
主系统在正常处理数据的情况下，还要生成同步索引，传送给备份系统。
同步索引包括主系统任务号、主系统处理时间及其他所需信息。
主系统的环境变量标识为“主系统”，处理话单过程中生成并发送同步信息，并向省中心、国际运营商发送下发相关结果；备系统的环境变量标识为“备系统”，接收同步信息并按此信息执行处理流程，不下发结果。
利用应用软件进行数据同步的机制示例如下图所示：
图2.1应用同步机制
1）生产中心子系统1开始处理一个批次话单，并将任务信息发送到灾备中心，通知灾备中心子系统1处理同一批次话单；
2）生产中心和灾备中心的子系统1同时处理话单；
3）生产中心处理完一个批次话单，将结果信息发送到灾备中心以供校验，确认灾备中心处理完毕且校验正确后，继续往下由子系统2处理数据（处理前发送同步信息通知灾备中心子系统2进行处理）；
上述流程的实现基于以下两个关键要点：
1）同步机制必须贯穿于数据处理的各个环节中，而且每个环节的开始和结束都必须同步。
这些环节包括数据上传至传输平台后计费结算系统取话单的采集过程、预处理过程、批价过程、结算处理过程、文件下发过程等。
2）同步信息校验过程必须可控。
正常情况下，主备中心同时处理，几乎同时完成，校验过程很短暂；一旦备中心发生问题，主中心在等待一定时间后仍未收到备中心的确认信息，则触发仲裁机制，判定是继续等待还是进入下一个处理环节。
备中心告警并排除故障，故障恢复后重新处理并检查结果。
根据上述容灾需求可以解释为如下的应用容灾数据同步方案：
图2.2应用容灾数据同步方案
1）主系统业务子系统1开始一个新的处理，
2）主系统业务子系统1收集本次任务相关输入信息并生成输入同步索引（注：
以下简称index）；
3）主系统业务子系统1生成的index发送到应用容灾平台；
4）主系统业务子系统1开始处理本批次话单。
5）主系统业务子系统1收集本次任务输出稽核信息并生成输出稽核信息。
6）容灾平台收集到index，根据index进行调度处理
7）备份系统业务子系统1按照index调度的要求开始处理相应的批次话单
8）备份系统业务子系统1收集本次任务输出稽核信息并生成输出稽核信息。
9）容灾平台仲裁主系统业务子系统1和备份系统业务子系统1的稽核信息
10）如果主备系统的稽核信息一致，主备系统正常完成本次任务
11）如果主备系统的稽核信息不一致，容灾平台发送报警信息给计费网管，主备系统异常退出，等待人工进行问题分析和障碍处理。
2.5应用容灾平台总体结构
上图概要描述应用容灾平台的主要组成部分以及相互关系。
1．容灾应用程序接口：
应用程序（国际清算，总部计费，帐务摊分）通过容灾应用程序接口（DR-API）与容灾平台相联，主要完成输入同步信息生成，输出稽核信息生成等容灾相关功能。
2．软件版本控制：
该模块负责确保容灾平台主备系统运行的软件的版本的一致性，备份机应用程序根据输入同步索引进行数据同步时，如果发现备份机应用程序软件版本和输入同步索引记录的主机应用程序软件版本不一致时，停止执行，并报警给缴费网管系统，有人工进行处理。
3．仲裁调度：
该模块负责对输出稽核信息进行仲裁，并对相应应用程序进行调度。
4．容灾切换：
该模块包括容灾切换工具，并在灾难发生后完成主备系统切换等操作。
5．容灾监控接口：
该模块负责按报警级别记录主备容灾平台运行状态信息，为计费网管提供提供监控信息。
6．输入同步索引管理：
输入同步索引管理模块负责完成如下功能：
包括IDX文件生成（在主系统中根据容灾API所产生的IDX数据生成IDX文件以便向备系统传递），IDX解释执行（在备系统中），业务程序间依赖关系检测等功能。
它是容灾平台的核心，负责协调各个子系统，对备份系统有调度功能，它负责启动或触发所有的容灾化应用需同步的应用程序。
7．灾信息传输：
该模块负责在主备系统之间传递容灾同步平台产生的同步数据。
包括：
1）主系统发向备系统的IDX消息文件
8．系统管理：
该模块负责在主备系统对容灾平台各种参数的配置管理。
另外为确保惠普提供的容灾平台的正常运作，并且在灾难发生时迅速决策和切换，还必须建立一套完善的基于惠普容灾平台的容灾运作管理规范和规章。
这些规范和规章不属于容灾平台功能范围，是属于容灾平台运营保障制度的一部分。
2.6假设与依赖
1）应用容灾化在输入数据方面的要求：
主备容灾平台运行的清算系统、总部计费、帐务分摊系统各自业务所需的文件交换通过智能交换平台进行。
容灾信息传输模块仅负责IDX消息文件和仲裁消息文件的传输。
2）应用容灾化在输入同步索引信息方面的要求：
需要进行容灾化的应用系统，必须在业务处理之前必须收集到本次业务处理所必须的全部的运行参数，以便生成输入同步索引信息（INDEX）给容灾平台，由容灾平台在容灾备份机根据INDEX进行应用容灾数据同步。
3）公共参数表（例如：
局向数据，费率表等）是主备机容灾化应用运行时必须保持一致的表，对这些数据表的变更需要遵循如下原则：
a）每条公参有有效时间，失效时间（按天：
如果不限制按天生效，备机运行时，无法保证其load的公参和主机一致。
因此公参按天生效！
）
b）容灾化业务程序必须依赖公参的有效时间来处理业务逻辑。
c）不允许delete，只能修改过期时间。
（否则无法保证公参表的完整性）
d）要在0点前给出一段时间来同步主备sid数据。
（否则无法保证备机公参0点前和主机一致）
e）当天有效的记录，不能update；也不能插入当天有效的记录；如果必须做则需要重启主备机容灾化应用。
（因为每12小时外发文件，没有回滚机会。
）
4）应用容灾化需要进行软件的版本控制，因此必须满足如下要求：
a）每个容灾化应用必须有配套的软件版本控制文件，该文件记录目前正在主、备系统运行的容灾化应用的版本号。
该文件的格式见容灾平台HLD.
b）容灾化应用在升级主备系统容灾化应用时，必须同步更新配套的版本控制文件的相关信息。
5）应用容灾化需要进行仲裁调度，因此容灾化应用必须满足如下的要求：
a）仲裁处理API是仲裁功能的关键，容灾化应用必须调用仲裁处理API。
b）容灾化应用必须在业务提交前等待仲裁。
等待仲裁时，业务处理的结果（例如输出文件）不能被后续进程读取。
c）如果仲裁结论一致，容灾化应用按照正常业务逻辑提交业务结果。
d）如果仲裁结论不一致，容灾化应用必须回滚本次业务的结果，并推出进程，等待人工处理。
e）每个业务的输出稽核信息依赖于不同的业务处理，但是仲裁在进行比对时，直接进行文本比对，无需理解业务内容；
f）仲裁运行有2种运行模式，2种模式的切换需要手工操作。
6）必须符合应用容灾的同步机制（见2.1的内容），必须符合容灾平台要求的开发规范。
容灾应用程序接口是应用容灾化功能的关键，容灾化程序必须按规范调用容灾应用程序接口。
7）各个应用的容灾化由各自应用自己进行容灾化分析，由单独的文档进行容灾化分析和设计。
8）计费网管负责完成容灾平台的容灾监控和报警功能（包括业务逻辑需要的监控、报警），负责提供监控和报警的界面。
容灾平台负责提供容灾监控接口。
9）由于高额处理进程的实时性要求和业务逻辑需要，主机的高额进程只做同步不做仲裁，不等待备机的回馈信息。
10）各个应用的容灾化后的统计报表功能由各自应用自己进行容灾化处理。
11）当灾难切换时，在输入数据方面的要求智能交换平台负保证文件不缺失！
容灾化应用负责对外输出的文件不缺失。
12）负责对外发送文件的模块，在主机发生灾难时，有可能已经外发部分文件。
因此需要做容灾切换时，备机切换为主机继续外发文件时，有可能重复文件，因此要求接收文件的应用需要对接受到的文件进行查重处理，以避免由于容灾切换导致的文件重发对接受方应用的影响。
3系统功能性需求
应用容灾平台
3.1.1容灾应用程序接口（DR-API）：
1）功能概述
应用程序（国际清算，总部计费，帐务摊分）通过容灾应用程序接口（DR-API）与容灾平台相联。
容灾应用程序接口（DR-API）的功能主要包括输入信息索引（IDX）生成和稽核信息生成，这些API需要嵌入到国际清算的应用程序中去，并且在以后新业务开发过程中都要遵守依据此平台所制定容灾开发规范，在新业务的应用程序中适当地嵌入DRAPI，来保证主备系统处理的同步。
2）需求描述：
◆REQ_ADR_API_1：
初始化输入同步索引文件（index）文件。
◆REQ_ADR_API_2：
读取本地软件版本配置信息，填写到index文件。
◆REQ_ADR_API_3：
填写输入同步索引文件（index）文件。
◆REQ_ADR_API_4：
提交index，index文件填写完成，关闭index文件。
◆REQ_ADR_API_5：
取得系统是主机运行状态是备机运行状态。
◆REQ_ADR_API_6：
释放API调用过程中申请的系统资源（文件、内存）。
◆REQ_ADR_API_7：
生成输出稽核信息，通知仲裁调度模块。
◆REQ_ADR_API_8：
当主系统reload公参时在index中标记reload＝yes。
◆REQ_ADR_API_9：
备分系统读该index时，根据该标记来reload公参。
（如果不这样，备机不能保证和主机一致，所以生效时间前，必须完成数据的更新！
）
◆REQ_ADR_API_10：
负责根据情况生成报警信息到日志文件，供计费网管系统收集信息进行报警，由人工进行处理。
3）假设和前提:
◆容灾应用程序接口是应用容灾化功能的关键，容灾化程序必须按规范调用容灾应用程序接口。
3.1.2软件版本控制：
1）功能概述
容灾备份系统正确运行的首要问题是建立与主系统具有相同处理能力和处理行为的等价系统，从而保证主备系统对相同的文件执行相同的处理流程，并且在灾难故障时，备份系统能够正确延续主系统的数据处理。
为确保主备系统所运行的软件系统具有等价性，必须确保备份系统与主系统实时保持相同的软件版本，
容灾平台必须建立一套完善的软件版本控制、更新的机制和规章，确保主备系统为实时等价系统。
本章描述了主备系统的软件版本控制功能及过程。
2）总体结构
容灾平台为了更好地保证版本的一致性，在主备系统中引入软件版本控制的概念。
总体结构如下：
图3-1软件版本控制总体结构图
该模块负责确保容灾平台主备系统运行的软件的版本的一致性，该功能的工作原理如下：
1）主机应用程序容灾化后，调用DR-API。
2）DR－API将读取主机的软件版本配置文件的版本相关信息，
3）DR-API生成输入同步信息索引文件，并记录软件版本信息到输入同步信息索引文件中；
4）输入同步信息索引文件传输到备份机；
5）备份机indexmanager将读取输入同步信息索引文件中的版本信息
6）备份机indexmanager读取备份机软件版本配置文件的版本相关信息，根据输入同步索引的版本信息比较备份机的软件版本配置信息
7）如果版本信息一致，根据输入同步索引调度执行对应的应用程序。
8）如果版本信息不一致，停止调度执行应用程序，生成报警信息到日志文件，供计费网管系统收集信息进行报警，由人工进行处理。
3）需求描述：
◆REQ_ADR_VC_1：
版本参数配置文件用于记录版本更新的时间、涉及的程序名称、软件版本等信息，为版本监控提供依据。
◆REQ_ADR_VC_2：
DR－API将读取主机的软件版本配置文件的版本相关信息，并记录软件版本信息到输入同步信息索引文件中；
◆REQ_ADR_VC_3：
备份机indexmanager读取输入同步信息索引文件中的版本信息，读取备份机软件版本配置文件的版本相关信息；根据输入同步索引的版本信息比较备份机的软件版本配置信息；如果版本信息一致，根据输入同步索引调度执行对应的应用程序。
如果版本信息不一致，停止调度执行应用程序，生成报警信息到日志文件，供计费网管系统收集信息进行报警，由人工进行处理。
3.1.3仲裁调度：
1）功能概述
该模块负责对输出稽核信息进行仲裁，并对相应应用程序进行调度。
仲裁与调度的目的是在主系统或备系统完成后，相应进程不再继续进行后续处理,处于等待状态；需要等待主备系统均正常完成，由仲裁进场对主备系统处理的结果进行一致性校验,如果校验结果一致，主备系统进程重新激活；否则，进程继续保持等待，等待网管进行人工干预。
根据这个需求，主备系统的同步运行可以理解为如下的运行模式：
图3－2：
主备同步运行模式一
在这种模式下：
1.主机系统业务程序开始运行，调用容灾平台API生成INDEX。
2.index通过容灾平台indexmanager传输到备系统，备系统indexmanager触发备份机业务进程启动。
3.主机系统、备份系统业务程序生成输出稽核信息，稽核信息发送给仲裁调度模块。
4.主备系统的仲裁调度模块相互沟通稽核信息，并对稽核信息进行比较和仲裁，将仲裁比较结果发送给主备系统各自的业务程序。
5.主备系统业务程序根据仲裁结果，如果仲裁结果一致则按正常业务逻辑进行业务提交。
否则，主备系统业务进程回滚业务操作，然后退出运行状态，等待人工干预。
在这种运行模式下，主备系统业务程序在下例情况下会推出运行，需要人工进行干预：
一、主备系统业务程序运行参数不一致
1．主备系统业务程序版本不一致
2．主备系统业务程序公参不一致
3．主备系统业务程序输入文件内容不一致
4．备系统业务程序缺失输入文件
5．主备机器应用配置（私有参数）不一样，（系统集成的配置错误）
二、主备系统业务程序异常出错
三、应用程序bug，导致处理结果不一致（主备机器的逻辑有部分不一致）。
四、网络延误导致的异常
1．indx传输异常（延迟、错误），导致备份机器延迟启动，主机业务程序仲裁超时，导致主备仲裁失败。
2．主备系统业务程序互传输出稽核信息异常（延误，错误），导致仲裁失败
由于有上述的异常情况将导致主系统业务程序无法正常执行，需要人工干预，检查和处理出错的原因。
某些情况下将影响主系统业务程序的时效性。
因此，需要容灾平台支持主系统业务程序不做仲裁的运行模式：
图3－3：
主备同步运行模式二
在这种模式下，主机不再等待备份机的输出信息。
1.主机系统业务程序开始运行，调用容灾平台API生成INDEX。
2.index通过容灾平台indexmanager传输到备系统，备系统indexmanager触发备份机业务进程启动。
3.主机系统、备份系统业务程序生成输出稽核信息，稽核信息发送给仲裁调度模块。
主系统业务进程提交输出稽核信息后，按正常流程进行业务提交，不再等待备份机器的反馈信息。
4.备份系统根据主备系统的输出稽核信息进行仲裁，仲裁结果一致时，备系统进程按正常业务逻辑进行业务提交。
否则，备系统业务进程回滚业务操作，然后退出运行状态，等待人工干预。
2）需求描述：
◆REQ_ADR_JC_1：
收集输出稽核信息
◆REQ_ADR_JC_2：
比较对应的稽核信息,如果对应的稽核信息一致，调度主备应用程序继续运行。
如果对应的稽核信息不一致，调度主备应用程序退出运行。
◆REQ_ADR_JC_3：
如果对应的稽核信息不一致，生成报警信息到日志文件，供计费网管系统收集信息进行报警，由人工进行处理。
3）假设和前提:
◆仲裁处理API是仲裁功能的关键，容灾化程序必须调用仲裁处理API。
◆容灾化应用必须在业务提交前等待仲裁。
等待仲裁时，业务处理的结果（例如输出文件）不能被后续进程读取。
◆如果仲裁结论一致，容灾化应用按照正常业务逻辑提交业务结果。
◆如果仲裁结论不一致，容灾化应用必须回滚本次业务的结果，并推出进程，等待人工处理。
◆每个业务的输出稽核信息依赖于不同的业务处理，但是仲裁在进行比对时，直接进行文本比对，无需理解业务内容；
◆仲裁运行有2种运行模式，2种模式的切换需要手工操作。
3.1.4容灾切换：
1）功能概述
该模块包括容灾切换工具，并在灾难发生后完成主备系统切换等操作。
容灾切换是指容灾平台的主系统与备系统相互转换的过程，按照切换的条件划分包括“有计划的切换”和“灾难切换”，其中演习切换包含于有计划的切换之中。
本章将详细介绍容灾平台提供相应的工具、命令和相关操作流程，配合实现主备系统相互切换的过程。
由于切换后，主备系统之间会产生差异，系统将提供详细的切换差异清单。
容灾切换操作
容灾平台的切换操作是指在特定情况下将备系统切换成主系统，将主系统切换成备系统的过程，这种切换主要有两种形式，第一种是在没有灾难发生情况下的有计划的切换，包括演习切换，第二种情况是在灾难发生之后的灾难切换。
本节主要介绍切换的具体操作过程、系统提供切换的操作工具。
有计划切换（含演习切换）
有计划的切换是在灾难未发生之时，进行备系统切换成主系统，主系统切换成备系统的切换过程。
有计划切换是在容灾平台运转正常后，备系统已建立并且在跟踪主系统运行的前提条件下进行的。
为不影响正常的生产，并保证新主系统月结算/统计数据的完整性，这种有计划的切换推荐在上一结算月尾，即21日零时进行，但是系统也能够在任何时候进行有计划的切换，并且这种有计划的切换主备系统处理结算数据没有差异。
具体操作如图3-4所示：
图3-4有计划的切换流程图
具体切换流程即是：
1.主系统执行“SHUTDOWN”操作，只shutdown应用程序，不shutdown数据库。
2.备系统进行IDX清仓，此时备系统所缺失的IDX都可以找得到；
3.备系统清仓完毕，备系统执行“SHUTDOWN”，只shutdown应用程序，不shutdown数据库。
4.备系统清仓完毕后，使用更换配置命令，更改系统配置为主系统配
升级会员 