1、通信公司业务容灾备份工程可行性研究报告XX工程咨询有限公司二零XX年XX月通信公司业务容灾备份工程可行性研究报告建设单位：XX建筑工程有限公司建设地点：XX省XX市编制单位：XX工程咨询有限公司20XX年XX月37可行性研究报告编制单位及编制人员名单项目编制单位：XX工程咨询有限公司资格等级： 级证书编号：（发证机关：中华人民共和国住房和城乡建设部制）编制人员： XXX高级工程师XXX高级工程师XXX高级工程师XXXX有限公司二XX年XX月XX日目 录第一章 总 论61 概述62 项目背景和必要性63项目建设目标74简要结论75可行性报告项目构成及研究范围8第二章 业务预测91预测的范围及期限2、92. XX业务量预测9第三章 系统现状及需求分析131 系统现状132存在问题和需求分析16第四章 建设方案论证181 建设目标和原则182 建设方案19第五章 工程建设进度36第六章 投资估算及效益分析371. 投资估算372. 综合效益分析37第一章 总 论1 概述1.1 项目名称与建设单位工程名称：XXXX业务容灾备份工程建设单位：XX股份公司1.2 编制依据1）关于委托编制XXXX业务容灾备份等四项工程可行性研究报告的函（2006年1月9日）；2）XX集团公司提供的XX业务容灾备份项目建议书；3）XX骨干智能网网络优化方案研究（评审稿）（2005年11月）；4）邮电部技术规定智能网技3、术体制(YDN 031-1997)；5）电部技术规定中国智能网设备业务控制点(SCP)技术规范(YDN048-1997)；6）中华人民共和国通信行业标准No.7 信令网工程设计规范；(YD/T5097-2000)；7）上海邮电设计院关于本项目的调研信息。2 项目背景和必要性XX业务是XX于2003年开放的面向商业客户和大客户的主被叫分摊付费业务。XX业务作为一个较新的业务，正处于快速增长期，用户数逐渐增多，业务量迅猛增长。截至2005年12月用户数为662个，与2005年1月相比增长503个，涨幅为316%。2005年12月总通话次数6825779次，与2005年1月份相比，涨幅为156。XX4、业务将是今后XX集团公司推广和发展的一个重点，随着业务的进一步发展，用户数和呼叫量将有更大的增长。XX业务承载在SHNSCP3上，SHNSCP3为XX业务分配的业务容量为86CAPS，目前实际话务量接近45CAPS。XX业务作为面向大客户的业务，安全性非常重要。虽然，SHNSCP3已经采用了2N的容灾方案，但是，这些容灾仅仅限于本SCP系统内部，如果出现一些特殊的灾难情况，例如地震、火灾、机房断电等，这些内部容灾方案将无能为力，而系统在短时间内也无法恢复，由此将造成严重的经济损失，更重要的是会带来恶劣的社会影响，严重损坏XX在客户中的良好形象。基于以上原因，本报告提出了XX业务系统异地容灾的需5、求。通过异地容灾，在生产系统发生灾难性故障时, 将呼叫切换到灾备系统，由灾备系统提供业务处理，保证后续呼叫的正常处理，将损失降到最低。3项目建设目标本工程将实现XX业务的异地容灾，通过灾备系统的建设及容灾机制的实施，实现在生产系统发生故障无法处理业务时，可以切换到灾备系统临时处理业务，在生产系统恢复后再切换回生产系统处理业务。通过异地容灾，实现在生产系统发生故障时最大程度的保证XX业务的正常提供。系统容量需满足到2007年底业务发展的需求。4简要结论本文件对XXXX业务的异地容灾的可行性进行研究。本项目通过新建并利旧部分设备，建设XX业务的灾备系统，采用异地容灾机制，实现上海SHNSCP3的系6、统级备份，以应对以下情况的故障，如：从SSP到SCP的信令链路中断、SCP系统级的宕机、由于地震等外力导致的机房或机柜倒塌等。本工程总投资估算额为434.23万元人民币。经论证，本工程的建设在技术上和工程上是可行的。5可行性报告项目构成及研究范围5.1 项目构成本工程的可行性研究报告共一册，即XXXX业务容灾备份工程可行性研究报告。5.2 研究范围本可行性报告研究范围如下：1)总论2)业务预测3)系统现状及需求分析4)建设方案论述5)建设进度安排建议6)投资估算及效益分析第二章 业务预测1预测的范围及期限本报告主要针对XX业务的发展情况进行预测，预测期到2007年底。1.1 预测的基础资料1）7、XX集团提供的XX业务话单统计报表；2）规划方法：XX规划方法。1.2 预测基本原则和基本方法1）预测基本原则业务预测是确定基本建设规模的重要依据，它直接关系到工程建设的规模和投资，以及工程建成投产后的经济效益。业务预测既要反映客观需要，又要考虑现实条件的可能性。本报告以XX业务每个月呼叫量和呼叫时长统计结果为依据，对2007年底之前的XX业务进行预测。本预测采取的主要预测方法为趋势外推法，是XX业务预测中用得较为普遍的一种预测方法，即根据历史数据建立数学模型，然后进行外推，求得对未来业务发展趋势的预测。2）预测方法的确定本预测的基础资料主要取自于XX对XX业务的统计报表。本预测采取的主要预测8、方法为趋势外推法，是XX业务预测中用得较为普遍的一种预测方法，即根据历史数据建立数学模型，然后进行外推，求得对未来业务发展趋势的预测。2. XX业务量预测2.1 预测基础数据截至2005年12月30日，XX已经发展了662个XX业务用户。2005年12月总呼叫次数为682.5779万次，通话时长为246084.84小时;2005年1月用户数为159个，总呼叫次数为266.5760万次，通话时长为130001.75小时。2005年1年内通话次数增长了156,通话时长增长了89，由此可见XX业务发展迅速。1）呼叫次数统计下表是2005年1月至2005年12月XX业务呼叫次数统计表。日期总计（次）29、005年1月26657602005年2月22806932005年3月26359612005年4月29484542005年5月37958742005年6月45243012005年7月49335682005年8月54676822005年9月53170132005年10月55888042005年11月59264602005年12月68257792）呼叫时长统计下表是2005年1月至2005年12月XX业务呼叫时长统计表。日期总计(小时)2005年1月130001.752005年2月109785.182005年3月129930.172005年4月145568.572005年5月176870.2320010、5年6月205186.122005年7月175620.532005年8月193551.712005年9月188546.072005年10月201028.452005年11月209926.872005年12月246084.842.2 业务发展趋势根据2005年1月2005年12月呼叫次数的统计数据，采用趋势外推法得到预测期内业务发展趋势。由上图可见XX业务发展迅速，发展趋势良好。到2007年12月XX业务的呼叫次数预计将达到1600万次，比2005年12月增长134.4%。2.3 结论预计2007年12月，XX业务的呼叫量将达到1600万次，比2005年增长134.4%。根据对XX业务的运营经验11、，以及2006年3月按日话务量统计报表分析可知，一周中工作日话务量较平均，周末话务量较大，周末晚上8点30分到9点30分的话务量最大,下表是根据话务数据得出的XX业务的话务模型。表2-2.3-2忙日集中系数0.06忙时集中系数0.4XX业务忙时CAPS的计算公式如下：业务CAPS = 月呼叫量忙日集中系数忙时集中系数/3600。160000000.060.4 107CAPS。目前SHNSCP3为XX业务分配的容量为86CAPS，考虑到“XX17900业务平台建设工程”将对SHNSCP3进行改造，改造完后系统的处理能力将大幅提高，届时可以通过调整XX业务的容量满足2007年底107CAPS的业务12、需求。第三章 系统现状及需求分析1 系统现状1.1 骨干智能网现状概述XX骨干智能网采用以SCP为核心，基于7号信令网的组网结构，目前骨干智能网主要网元,除各SSP外,还包括5套SCP、4套独立IP、2套SMP。SCP与XX全网63个DC1/SSP、4个I-SSP/ITS之间通过HSTP准直连链路进行连接，业务由DC1/SSP、I-SSP/ITS集中触发，信令寻址方式目前都是采用上行GT寻址方式，下行DPCSSN的寻址方式，GT码的翻译工作由HSTP负责。目前，BJNSCP5、SHNSCP3、SHNSCP4与8大区HSTP都建有直连链路，SHNSCP5、CDNSCP2和4个独立IP仅与本省HS13、TP开设直连链路。SCP、独立IP由SMP进行管理，SCP与SMP之间通过DCN网/ATM网进行连接，其中BJNSCP5和SHNSCP4采用贝尔设备，由BJNSMP3（贝尔）管理，SHNSCP3、SHNSCP5、上海独立IP、广州独立IP采用华为设备，由BJNSMP5(华为)管理。CDNSCP2、成都独立IP、北京独立IP采用欣方设备，骨干智能网上没有建设欣方SMP，规划中，这两个设备都由四川省智能网欣方SMP设备管理。骨干智能网上还建有2台语音短信中心（IN WebServer），分布在上海和成都，与SHNSCP5、CDNSCP2通过数据链路连接，处理来自上海、广州短信一级网关发送过来的语音14、短信。XX骨干智能网整体网络拓扑图见图1.1。图.1XX骨干智能网网络拓扑图1.2 SHNSCP3系统现状1.2.1网络结构目前XXSHNSCP3正在进行改造，以承载17900业务。工程完成后，平台将同时承载17900业务和XX业务。该平台为华为公司智能网系统，采用SAU+SCU+SDU的结构，SAU负责七号信令的接入，SCU负责执行SCF功能，处理具体的业务逻辑，同时访问SDU；SDU负责用户数据的存储和处理。SAU、SCU与SDU之间通过100BaseT局域网相连。SAU负责将呼叫送到SCU，SCU执行具体的业务逻辑，从SDU中查询用户数据进行处理，并将处理后的结果更新SDU中的数据。SC15、U和SDU硬件均采用IBM小型机系统。SAU采用华为C&C08交换机。上海SHNSCP3采用2N容灾机制。SCU硬件为两台IBM 6M1小型机，双机之间采用双机热备工作方式，2N冗余结构。SDU硬件为两台IBM p550小型机双机，同样采用双机热备工作方式，2N冗余结构。SHNSCP3的组网结构如下图所示，两台局域网交换机和两台CISCO R2600路由器组成了主备网络。主机通过FE分别接入两台局域网交换机。两台SAU通过64K信令链路连接SSP。SHNSCP3与北京BJNSMP5通过DCN网互联。图1.2 SHNSCP3组网结构图1.2.2 设备配置SHNSCP3的SAU、SCU及SDU的设16、备配置如下表所示。SAU采用华为C&C08交换机，支持64条64K信令联路，32个E1。表3-1.2-1 XX平台设备配置表系统名称设备名称 设备型号CPU内存内置硬盘磁阵容量（GB）(GB)(GB)SHNSCP3SCUIBM 6M1双机4750 MHZ4218169SDUIBM p550双机21.65GHz42738*146BJNSMP5SMPIBM p550双机2*1.65GHz42*73G8*146原SMP5主机目前闲置HP N4000双机4440 MHZ421889在SHNSCP3改造中，BJNSMP5原来的主机HP N4000小型机双机被IBM p550双机替换。目前，两台HP N417、000为闲置设备。1.2.3 业务部署SHNSCP3上承载的业务包括17900业务和XX业务，其中17900又分为一次拨号业务、二次拨号业务以及充值管理。目前17900业务正处于工程建设阶段，XX计划今后将面向个人用户的主要卡类业务整合到17900业务平台上。表3-1.2-2 业务容量情况表业务分配容量实际业务量发展趋势(CAPS)(CAPS)17900一次拨号50-工程建设中二次拨号116.27-充值管理2.67-XX8645业务发展迅速，到2007年底预计达到107CAPS2存在问题和需求分析XX17900 业务平台工程建设中对SHNSCP3进行了改造，系统由SAU+SCP改造成SAU+S18、CU+SDU。SCU利旧SCP的主机IBM 6M1双机，新建了一套IBM p550双机作为SDU，新建一套IBM p550双机作为SMP替换原有设备。系统的处理能力有较大富余，可以满足今后两年业务发展的需求。系统存在的主要问题是XX业务缺少异地容灾机制，存在安全隐患。XX业务作为面向大客户的业务，安全性非常重要。虽然，现在的SHNSCP3已经采用2N的容灾方式，但是，这些容灾仅仅限于本SCP系统内部，对于以下情况，这些内部容灾方案无能为力： 从SSP到SCP的信令链路中断； 由于地震、战争等原因导致的机房或机柜倒塌； 其他不可预见的灾害，导致系统瘫痪；而异地容灾则正好能处理以上异常情况，提供系19、统的可靠性。本工程需实现XX业务的异地容灾备份，通过容灾备份实现生产系统与灾备系统之间的数据同步，在生产系统发生故障时，可以切换到灾备系统临时处理业务，在生产系统恢复后再切换回生产系统处理业务。第四章 建设方案论证1 建设目标和原则1.1 建设目标本工程将实现XX业务的异地容灾，通过灾备系统的建设及容灾机制的实施，实现在生产系统发生故障无法处理业务时，可以切换到灾备系统临时处理业务，在生产系统恢复后再切换回生产系统处理业务。通过异地容灾，实现在生产系统发生故障时最大程度的保证XX业务的正常提供。1.2 建设原则XX业务的异地容灾应遵循以下原则：1）安全可靠性容灾方案首先应考虑安全可靠性及技术方20、案的成熟性。在生产系统出乎预料地失效时，应能实时、自动地响应，灾备系统能迅速接管后续的呼叫，将损失降到最小。采用的容灾方案在现网中应有一定范围的应用和成功的案例，避免不确定因素的引入，导致灾备方案本身的不可靠性。2）方案应具有可操作性和可实施性容灾方案应保证可操作性和可实施性，应确保与容灾系统相关的其它系统资源及物理条件能满足容灾方案的实施。3）经济性容灾方案在保证安全可靠性的基础上应兼顾经济性。充分利用现有设备和资源，尽可能减小投资。同时，考虑到灾备系统只是在特殊的情况下临时代替生产系统，为节约投资，灾备系统的硬件配置不再考虑2N冗余。4）容灾方案的实施应保证现网的平滑过渡，尽量减小对现网业21、务和网络的影响。2 建设方案2.1 容灾系统概述为了实现XX业务的异地容灾，首先需要建设容灾系统。容灾系统由生产系统和灾备系统构成，生产系统指正常情况下现网负责处理业务的系统。XX业务的生产系统即SHNSCP3，包括SCU、SDU等设备。灾备系统指为生产设备提供容灾备份功能的设备。当灾难发生使得生产系统发生故障时，灾备系统可以恢复生产系统的数据甚至接管业务，避免造成不可挽回的损失。业务容灾侧重业务完整性，尽可能地保证业务不中断或者可以快速恢复。提供业务容灾的前提条件需要在异机有一份生产系统业务数据的备份，并且在生产设备由于灾难而无法工作时，灾备系统利用备份数据快速恢复业务。在智能网中，业务的恢22、复包括信令的切换、周边网元数据链接的切换等工作，并且还需要考虑生产系统修复之后的反向倒换过程。2.1.1 容灾系统方式根据生产系统和灾备系统的不同组网、逻辑关系，业务容灾组网方案可以分为互备容灾组网和独立容灾组网两种方式。2.1.1.1 方式一：互备容灾组网互备容灾是指两套设备作为生产设备同时对外提供服务，同时，每台生产设备也担当另外一台生产设备的容灾设备，如下图所示。图2.1-1互备容灾组网示意图互备容灾组网不增加新的硬件设备，但为了能够在生产系统(如生产系统1)遭受灾难时，对应的灾备系统（生产系统2）能够接管其业务，对应生产系统1需要生产系统2为其预留一定的处理能力。互备容灾方式是通过降低23、生产系统的利用率来换取容灾功能的。互备容灾信令及IP组网比较复杂，在进行容灾接管之后，一套物理系统需要作为两套逻辑系统提供业务，信令寻址及数据连接的调整都比较复杂。并且由容灾接管引起的双倍话务量冲击可能引发连环故障(Chain Reaction)，导致原本正常的生产设备受损。2.1.1.2 方式二：独立容灾系统组网灾备系统独立建设，在正常情况下不参与生产。灾备系统放置于独立的容灾中心(与生产系统所在的机房保持一定的距离)，可以更有效地应付机房停电等故障。图2.1-2独立容灾组网示意图如上图中独立建设一套容灾系统，作为3套生产系统的容灾设备，不影响原有生产系统的组网及容量，并且在任何一套生产系统24、发生故障的情况下，容灾系统可以完全接管其业务，并且不影响其它生产系统。由于多套生产系统可以共用一套容灾系统，此组网方案也称为N+1容灾方案。2.1.1.3灾备方式比较下面从安全可靠性、设备利用率、以及对现有系统的影响几个方面对两个方式做比较。 安全性两种方式对于业务而言都有生产系统和灾备系统，在灾难发生时可以实现有效的切换，具有同样高的安全性。但是如果方式一中的生产系统为灾备业务预留的容量不够，在容灾接管时引起的双倍话务量冲击可能引发连环故障(Chain Reaction)，导致原本正常的业务受损。 设备利用率为了能够在生产系统故障时容灾系统可以完全接管业务，方式一需要生产设备预留50%容量，25、即设备的利用率为50%；方式二在1+1情况下，设备的利用率同样为50%，如果容灾系统不考虑2N冗余(设备单机配置)，设备利用率为67%。在N大于1的情况下，利用率更高。由此可见方式二的设备利用率高于方式一。 对现有系统的影响方式一采用循环备份的方式，生产系统同时又是灾备系统，需要在生产系统上部署多个业务，容灾机制的运行更加复杂。方式二建设独立的容灾系统，生产系统上只需要部署容灾运行机制，对现有系统影响不大。从以上几个方面的比较来看，方式二优于方式一。方式一的应用适合在已有两套系统，且资源都有较大富余，为了节省投资，采用两套系统互为灾备实现业务容灾。2.1.2 容灾系统运行过程在完成容灾系统的建26、设后，即可利用灾备系统对生产系统实施容灾。容灾系统的工作过程包括基线建立、增量复制、灾难切换、灾难恢复。 基线建立基线建立指将生产设备上的业务数据复制到容灾设备，是进行增量复制的基础。基线建立过程一般只需要进行一次，在生产设备和容灾设备之间的复制关系未被破坏之前，都无需重新建立基线。 增量复制基线建立完成之后，就可以通过复制软件进行增量复制：将生产设备发生变化的数据复制到灾备设备，保证容灾设备上的备份数据与生产设备上的业务数据一致。 灾难切换一旦生产设备遭受灾难或者发生故障，就可以实施灾难切换，使容灾设备对外提供业务。灾难切换包括信令切换、外部实体（SCP、SDP）连接切换等。切换方式可以分为27、自动切换和人工切换两类。信令切换是智能网容灾中非常重要的内容，为了简化信令切换过程，建议SSP全部通过HSTP转接访问生产设备。同时，灾备设备与生产设备的信令网组网方式一致。 灾难恢复在生产设备遭受灾难或者发生故障后实施灾难切换，容灾切换成功后灾备系统开始对外提供服务。当生产系统修复后，系统对外的服务需要从灾备系统重新切换到生产系统来提供，这个过程称为灾难恢复。灾难恢复实际上由灾备设备到生产设备的反向基线建立、反向增量复制和反向灾难切换过程三个步骤构成的。2.2 XX业务异地容灾系统结构本报告建议采用独立容灾系统组网方式建设XX业务异地容灾系统，考虑新建一套XX业务的灾备智能网系统。灾备系统与28、SHNSCP3采用同样的系统结构，以确保容灾机制的实施。灾备系统由SAUSCUSDU组成。生产系统与灾备系统之间通过数据链路实现数据同步。灾备系统同样由BJNSMP5管理。下图是XX业务容灾系统结构图。图2.2 XX业务异地容灾系统结构图2.3 灾备系统设备配置要求灾备系统按目前SHNSCP3上XX业务的容量需求配置，目前XX业务的容量为86CAPS，根据业务预测到2007年底业务量将达到107CAPS，考虑SHNSCP3改造完后系统的处理能力将大幅提高，届时可以通过调整XX业务的容量满足2007年底107 CAPS的业务需求。灾备系统的配置需求按照XX业务107CAPS的业务量计算。2.3.29、1 SCU设备配置要求1）处理能力需求华为智能网系统业务对SCP的处理能力需求通过TPM-C测算。XX业务的基础数据如下表所示：表4-2.3-1XX业务CAPS107XX业务TPS7tpmC与TPS 值的转换系数9CPU 最大负荷70TPS 表示每次呼叫的事务处理数，与业务软件复杂度相关。XX业务需求TPM-C业务CAPSTPS转换系数/ CPU 最大负荷=10779/70%9630tpmC。由于本期业务平台采用SCUSDU 的结构，所以上述计算的TPM-C 值为SCU和SDU的TPM-C之和。SCU 负责整个业务处理的55，因此SCU的TPM-C需求为：9450555297tpmC2）存储需30、求SCU的存储需求主要包括系统存储和话单存储两部分组成。 其中系统存储空间需求约为3GB； 话单存储空间 = 容灾业务的总CAPS数话单大小每天的忙时长话单的暂存天数36001071378303600/1024/1024/1024=11.8GB；两部分相加为14.8GB，同时考虑2.0的冗余系数，存储需求为29.6GB。2.3.2 SDU设备配置要求1）处理能力需求SDU 负责整个业务处理的45，因此SCU的TPM-C 需求为：9450454334tpmC2）存储需求SDU的存储需求主要包括系统存储和用户数据存储两部分组成。 其中系统存储空间约为3GB； 用户数据存储空间较少约1GB两部分相加31、为4.5 GB，同时考虑2.0的冗余系数，存储需求为9GB。2.3.3 SAU设备配置要求SAU负责SCP与SSP的七号信令的接入，XX业务的信令链路计算参数如下表所示。表4-2.3-1XX业务CAPS107双向TCAP消息数9平均消息长度(Byte)133信令链路负荷(单向)0.4SSP至SCP的信令链路需求数计算公式如下：64K信令链路数=XX业务CAPS每呼叫双向TCAP消息数消息长度8/(640002单向信令负荷)20条。灾备系统的信令链路组织与生产系统保持一致，即与八大区HSTP开设直连信令链路。通过对2005年12月分省通话话单的分析，以此为依据计算各省所占的XX业务量比例，由此计32、算信令链路的分配。信令链路建议配置情况如下表所示：表4-2.3-1序号八大区HSTP负责汇接省HSTP业务比例小计64K信令链路需求数建议配置1上海HSTP对上海HSTP7.95%17.15%3.52*22浙江HSTP5.75%3福建HSTP2.38%4江西HSTP1.07%5广州HSTP对广东HSTP16.84%18.32%3.72*26广西HSTP1.08%7海南HSTP0.40%8南京HSTP江苏HSTP9.06%11.30%2.32*29安徽HSTP2.23%10武汉HSTP湖北HSTP3.40%5.46%1.12*211湖南HSTP2.06%12成都HSTP云南HSTP3.39%1233、.00%2.42*213贵州HSTP1.15%14四川HSTP5.59%15重庆HSTP1.62%16西藏HSTP0.24%17西安HSTP陕西HSTP2.43%4.81%1.02*218甘肃HSTP0.68%19新疆HSTP0.97%20宁夏HSTP0.44%21青海HSTP0.29%22北京HSTP北京HSTP9.75%19.59%4.02*223天津HSTP1.71%24内蒙古HSTP0.72%25黑龙江HSTP2.27%26吉林HSTP1.53%27辽宁HSTP3.61%28郑州HSTP河南HSTP2.68%11.38%2.32*229河北HSTP2.80%30山东HSTP3.76%334、1山西HSTP2.15%合计100.00%20 322.4 灾备系统建设方案2.4.1 方案一：利旧建设方案方案一建议利旧XX17900 业务平台工程建设中BJNSMP5替换下来的HP N4000小型机双机来建设XX的灾备系统。两台HP N4000中的一台作为SCU、另外一台作为SDU。还需新建一台SAU。HP N4000单机配置为4440 MHZ CPU、4G内存、218G硬盘。磁盘阵列容量为89G。处理能力27500tpmC。根据灾备系统的设备配置需求和HP N4000小型机的配置可以看出，HP N4000作为SCU或者SDU都可以满足业务的处理能力和存储需求。方案一的投资估算如下表所示，35、包括灾备系统的网络设备、灾备系统SAU费用、容灾系统软件费用、灾备业务软件费用及工程实施费用等。表4-2.4-1 方案一投资估算编号名称投资估算 （万元）备注1灾备系统交换机4.00 2灾备系统路由器20.00 3SHNSCP3路由器替换20.004灾备系统SAU80.00 32条64K SS7信令链路5灾备系统数据库软件50.00 6灾备系统平台软件50.00 7灾备系统XX业务软件40.00 8灾备数据同步软件80.00 数据同步软件，备份工具软件9工程费用40.00 利旧SMP设备搬迁、业务软件加载，数据割接，业务测试总计384.00 2.4.2 方案二：新建建设方案方案二与方案一不同之36、处在于方案二的SCU和SDU全部新建。目前生产系统的主机全部是IBM设备。建议灾备系统的主机与生产系统采用同一厂家的设备。综合考虑本期工程的设备配置需求以及今后的扩容，建议采用IBM eServer p系列的小型机。方案二的投资估算如下表所示，与方案一的差别在于多了SCU和SDU硬件设备的投资。表4-2.4-2 方案二投资估算编号名称投资估算 （万元）备注1灾备系统交换机4.00 2灾备系统路由器20.00 3SHNSCP3路由器替换20.004灾备系统SAU80.00 32条64K SS7信令链路5灾备SCU28.00 2CPU/4G内存6灾备SDU28.00 2CPU/4G内存7灾备系统数37、据库软件50.00 8灾备系统平台软件50.00 9灾备系统XX业务软件40.00 10灾备数据同步软件80.00 数据同步软件，备份工具软件11工程费用40.00 业务软件加载，数据割接，业务测试总计440.00 2.5 方案比较方案一的优点在于使用利旧设备，节省投资。不足之处在于HP N4000采购时间较早，早已过了保修期，且N4000属于停产设备，后续的硬件扩容及维保比较困难。方案二的优点在于通过新建IBM主流的小型机，在系统容量、稳定性、后续扩容及售后服务方面均优于方案一。不足之处在于增加了投资。下表是对两个方案从各方面的一个比较。表4-2.5-1项目方案一：利旧方案方案二：新建方案业38、务容量107 CAPS107 CAPS后续可扩展性一般，HP N4000设备已停产，存在生产系统与灾备系统容量不匹配的风险。好，灾备系统的扩容不存在问题。可靠性一般，但由于HP N4000属于停产设备，系统的后续维护比较困难。好，新建设备采用IBM 主流小型机，系统可靠性高。工程实施较复杂，涉及2台HP N4000设备的搬迁简单，新建系统不涉及利旧设备搬迁。投资大小小，估算为384万元大，估算为440万元从以上的比较可以看出，方案二在系统的可靠性、后续可扩展性、工程实施方面都要优于方案一。但是，考虑到HP N4000的处理能力可以满足到2007年底XX业务容量需求，且有一定余量，预计今后两年暂39、不需要扩容，从节约投资的角度考虑，建议采用方案一。2.6 容灾实现机制异地容灾工作原理即在生产系统退出服务时，灾备系统接替业务处理，在生产系统恢复后，业务处理再由灾备系统切换回生产系统。以上两个方案在容灾实现机制上一致，下面以方案一描述容灾实现机制。如图2.2 XX业务异地容灾系统结构图所示，在灾备系统SDU上加载XX业务SDU侧的软件模块，通过对数据的增量复制，实现对SHNSCP3的XX业务数据进行远程备份；同时在灾备系统SCU上加载XX业务SCU侧的软件模块，作为XX业务的灾备SCU。容灾机制主要涉及三个方面：数据同步，生产系统与灾备系统之间的切换以及恢复，下面从这三个方面来说明。2.6.40、1 文件及数据复制文件复制：生产机上的文件复制进程通过FTP实现生产机和容灾机的系统表数据、业务文件、配置文件、License文件的同步（同步间隔时间最小可设为一秒）。业务数据更新：基于数据库本身的数据复制，Informix 数据库提供CDR数据复制功能，实现数据库数据同步。2.6.2 业务接管生产系统的故障分为两种情况:1)SHNSCP3整个网络全部宕了或SSP到SHNSCP3的链路全部断了，导致SSP到SHNSCP3的呼叫请求不可达，在这种情况下，STP需要将新发生的呼叫路由到灾备系统，由灾备系统来负责接管XX业务。生产系统切换到灾备系统的切换点在HSTP上。骨干智能网DC1/SSP到SC41、P寻址方式是GT寻址，由HSTP根据GT号码翻译表将生产系统的GT码翻译为生产系统的信令点，当生产系统发生故障时，HSTP将GT号码翻译为灾备系统的信令点。切换有人工切换和自动切换两种方式。人工切换：在主用业务平台故障的情况下，通过全国N7MS的人机命令（批处理）修改HSTP上GT码翻译表，将GT号码对应的DPC由生产系统的DPC码改为灾备系统DPC，切换时间小于1分钟。 自动切换：在HSTP上配置GT码对应的主用DPC和备用DPC，主用DPC为生产系统DPC，备用DPC为灾备系统DPC。如果发现主用SCP不可到达，HSTP在进行GT码翻译时，自动将GT码翻译为备用DPC，切换时间为秒级。自动42、切换的隐患在于如果SCP与HSTP之间的链路不稳定时，可能会造成生产系统与容灾系统来回切换。同时存在生产系统可排除故障的情况以及实施灾难切换也不能恢复业务的情况，如：生产设备业务数据被误删除，STP故障等。因此，建议采用人工切换方案。HSTP完成信令切换后，DR-S在容灾机上对转发过来的信令消息中的目的地址进行分析，自动启动灾难生产机所对应的应用业务，实现容灾机对生产机的业务接管，保证了业务的持续运行和管理。在SCU发生容灾切换后，SMP会重连容灾机。SCU切换时间 3分钟。2)SDU宕机，导致生产系统SCU对SDU的访问不可达在这种情况下，需要完成生产系统SDU与灾备系统SDU之间的切换，生43、产系统SCU访问灾备系统SDU。切换有人工切换和自动切换两种方式。自动切换：配置SCU中的主备SDU设置，并设置访问主用SDU最大允许的失效时间，当在一定时间内，不能够正常连接生产SDU时，需要连接到对应的灾备SDU进行业务数据的访问。SDU自动切换时间为秒级。人工切换：对于SDU人工切换是通过配置SCU的配置项，使SCU连接生产SDU失败后，不自动连接容灾SDU，而是需要人工修改该配置项后，才在连接生产SDU失败后，连接容灾SDU。为了避免由于SDU掉电或者网络故障等可恢复的故障导致SDU切换，建议采用人工切换的方式。 生产系统恢复当生产系统恢复可用之后，同样采用数据库复制技术将灾备SDU的44、数据同步到生产系统上，对生产SDU的数据进行更新。在确定生产系统与灾备系统业务数据一致后，人工切换回生产系统。2.7 灾备系统带宽需求2.7.1 灾备系统与生产系统带宽需求带宽计算包括两部分，一是生产SDU到灾备SDU的数据同步带宽，另一部分是生产SDU故障时，生产SCP到灾备SDU的带宽。1)生产SDU到灾备SDU的数据同步带宽生产SDU到灾备SDU的同步数据基于TCP/IP协议。带宽计算公式如下：带宽需求=CAPS每呼叫产生的复制LOG大小8bit。生产机的CAPS为107 CAPS，每个呼叫产生4个CDR复制事务，每个CDR复制事务产生1KB的复制日志。带宽需求=107418/1024 45、= 3.3Mbps。对于SCU来说，主要为文件复制，不存在CDR复制，对网络带宽的要求相对较低，带宽需求2M。2) 生产SDU故障时，生产SCU到灾备SDU的带宽生产SDU故障时，生产SCU访问灾备SDU的数据流基于TCP/IP协议。带宽计算公式如下。带宽需求=业务CAPS每个呼叫访问SDP的消息数消息长度8bit。XX业务每个呼叫访问SDP的消息数取为4，消息长度取定为3KB。由此计算：带宽需求=107448/1024=13.3Mbit/s。由于生产SDU到灾备SDU的数据同步是在生产SDU正常时才会发生，而生产SCU到灾备SDU的访问只有在生产SDU故障时才需要，两者不可能同时发生，所以取46、其组合大者为：13.3Mbit/s。考虑到传输开销的带宽，以及网络利用率，建议生产系统与灾备系统之间的带宽需求为26 Mb/s。2.7.2 灾备系统与BJNSMP5带宽需求BJNSMP5需要对灾备系统进行管理，同时灾备系统在接管业务后需要将话单传送至BJNSMP5。业务管理所需的带宽较少，这里主要考虑话单传送所需带宽。带宽需求XX业务的CAPS业务话单大小2（冗余系数）XX业务的CAPS为107，话单大小为137Byte。计算得，灾备系统到BJNSMP5带宽需求为0.23Mb/s。由此可见带宽需求很小，建议灾备系统与BJNSMP5通过DCN网以1 Mb/s带宽互联。2.8 灾备系统业务计费在生47、产系统发生灾难性故障，灾备系统接管业务处理后，相应地对用户的计费也由灾备系统完成，计费方式同生产系统一致。即由灾备SCP下发计费类别等信息（费率、业务的话费门限值等），SSP 根据计费类别等进行计费监视，在呼叫完成后，呼叫的详细记录将同时通过No.7 信令的INAP 规程传送至SCP（包括通话的主、被叫，通话起始时间、结束时间，通话时长等），再送至业务管理点BJNSMP5进行统计，并由BJNSMP5将呼叫起止时间、呼叫类别、主叫号码等计费信息再送至XX的全国计费结算中心，用于XX业务的计费结算。2.9 本工程建设的配套需求2.9.1 对信令网、传输网的需求通过2.3节对信令网需求的分析可以看出48、，灾备SCP与八大区HSTP需开设32条64KLink信令链路，建议每个局向开设两条E1承载信令链路，共需16条E1链路资源。2.9.2 对数据网的需求通过2.7节对数据同步的带宽需求计算可知，SHNSCP3和灾备SCP之间需要开设26Mb/s带宽的数据链路。如果灾备系统与生产系统部署在不同的城市，建议通过ATM网互连，保证数据传输的可靠性。如果灾备系统与生产系统部署在同城的不同局址，建议通过传输专线互连。灾备系统到BJNSMP5带宽需求为1Mb/s的数据链路，建议通过DCN网承载，要求新建系统所在局房具备DCN接入条件。目前SHNSCP3的两台路由器采用华为R2631，没有配置ATM口或者P49、OS口，且R2631属于停产设备，无法扩容，本工程建议新建两台带ATM端口或者POS口的路由器替换R2631。2.9.3 对机房配套的需求本工程将新建一套灾备系统，设备机柜包括3个SAU机架、1个服务器机柜和1个网络机柜共5个机柜，同时还需考虑电源柜。SAU设备需直流供电，其它设备交流供电。新建SAU直流功耗需求估计约1000W。服务器及网络设备的交流功耗需求估计4500W。2.10 灾备系统局址选择目前XX骨干智能网系统主要部署在北京和上海，其中：SHNSCP3(XX、17900业务)、SHNSCP4(800、600业务)、SHNSCP5(语音短信)位于上海；BJNSCP5(公务通、190350、00业务)、BJNSMP3、 BJNSMP5位于北京。本期新建XX业务灾备系统考虑建在北京或者上海。北京XX长途局房位于北京静安中心大楼地下2 层机房，目前，BJNSCP5部署在该局房。上海XX长途局房包括武胜XX大楼、横浜XX大楼、花木XX大楼和漕溪XX大楼。目前，XX业务生产系统SHNSCP3部署在武胜XX大楼，考虑到异地容灾，新建灾备系统需安装在其它局房，考虑局房的功能定位和现有条件，上海除武胜外的三个长途局房中，漕溪XX大楼(与XX大楼相距约15公里)十二层长途交换机房较适合部署本项目新增的灾备系统。下面将从局房配套条件和异地容灾实施两方面，对北京静安局房和上海漕溪局进行灾备系统局址选51、择的方案比较。1)机房配套条件新建灾备系统共需5个设备机柜，目前，北京上海漕溪局和静安局房都有足够的机房空间安装新建系统。但是静安局房的机房空间相对紧张，地下二层机房本身不规则(成三角形)，安装完新建系统后，机房剩余空间不多。上海漕溪局机房的交直流系统容量可以满足本期工程需求。北京静安局房的交流电源容量还有富裕，可以满足新建系统需求，但是直流电源容量较为紧张(100A 整流模块19 个，已启用14个)，在满足本工程后，剩余容量不多。上海漕溪局和北京静安局房的传输资源及数据网资源均可满足本工程的需求。考虑到北京XX公司只有静安大楼地下二层一个长途交换机房，且目前机房空间已较为紧张，如果将灾备系统52、部署在该机房，今后其它系统的设备扩容就会存在问题。而上海有多个长途局房，机房资源更加丰富，配套设施也相对完善。2)异地容灾实施灾备系统部署在上海漕溪局或者北京静安局对于XX业务的容灾都具有很高的安全性和可靠性。相对而言，对于城市级的灾难事件，例如重大地震导致多个局房全部倒塌，在这种情况下部署在北京安全性更高。从对灾备系统的管理和维护来讲，部署在上海优势更大，因为目前XX业务系统SHNSCP3部署在上海，对XX业务系统维护和管理的技术力量也集中在上海。这样，在系统发生故障或者发生容灾切换时，可以有更快的响应时间和更好的技术支撑。3) 局址选择结论从以上两个方面的比较可以看出除了应对城市级的灾难事53、件外，部署在上海比部署在北京更有优势。但是如果真的发生这种灾难事件，上海长途交换网的HSTP和SSP将全部瘫痪，XX业务也无法正常提供。综合考虑上述因素，本报告建议将XX业务的灾备系统部署在上海漕溪局，实现同城异地的灾备。第五章 工程建设进度根据XX集团对本工程建设的总体要求，本工程投产期定在2006年底。表5-1 本期工程建设进度表序号时间2006年工程进度1月2月3月4月5月6月7月8月9月10月11月12月1可研编制2可研会审及批复3技术规范制定4谈判订货5设备到货6工程设计7设备搬迁8业务部署及测试9试运行及初验第六章 投资估算及效益分析1. 投资估算本工程总投资估算额为434.23万54、元人民币。工程建设其它费按设备费的7%计取，预备费按3计取。表6-1 本期工程投资估算表序号费用类别规模容量投资估算备注项目名称单位单价数量总价(万元)(万元)一硬件及软件费用1灾备系统交换机台2.00 24.00 2灾备系统路由器台10.00 220.00 3SHNSCP3 路由器替换台10.00220.004灾备系统SAU套80.00 180.00 32条64K SS7信令链路5容灾机数据库软件套50.00 150.00 6灾备系统平台软件套50.00 150.00 7灾备系统XX业务软件套40.00 140.00 8灾备系统软件套80.00 180.00 数据同步软件，备份工具软件小计155、344.00 二工程费用1工程实施及测试费40.00 利旧N4000搬迁、业务软件加载，数据割接，业务测试2机房配套建设费10.00灾备系统机房电源柜及DDF等配套建设三工程其他费27.58 (小计1+二)*7%小计2421.58 四预备费12.65 小计2*3%总计434.23 2. 综合效益分析XX业务是XX于2003年开放的面向商业客户和大客户的主被叫分摊付费业务。业务正处于快速增长期，用户数逐渐增多，业务量迅猛增长。XX业务作为面向大客户的业务，安全性非常重要。如果由于一些灾难性事件或不可预见性事件造成业务无法正常提供，而短时间内系统又无法恢复正常，将造成严重的经济损失，更重要的是会带来恶劣的社会影响，XX在客户中的良好形象将受到破坏，由此会带来客户忠诚度的下降，给竞争对手带来可乘之机。本工程通过XX异地容灾系统的建设，即使发生机房断电、地 震等灾难性事件导致生产系统无法工作时，仍有一套备用系统保证正常的业务提供，由此大大提高了XX业务系统的高可靠性、安全性，对大客户的业务质量得到了保证。本工程的建设为XX的固网增值业务市场提供更强的竞争能力。虽然本项目的建设不带来直接的经济效益，但通过本项目的建设将大大增强XX业务的整体抗风险能力，增强XX在固网增值业务市场的竞争能力，符合XX确定的业务转型的战略目标，因此，建议上级主管部门加快本项目的立项。