云时代下双活零切换实现与架构设计

云时代下双活零切换实现与架构设计一、项目背景为了更好的保障业务系统运行，提高服务质量，我们先后建立了高可用保障手段、应急容灾系统等保护机制，但仍存在如下矛盾，并越来越突出：1.投资大，效益慢：如今年某系统扩容需要约XXXX万TPCC，XXXT存储设备，需要同步对容灾系统扩容。2.灾备端平时无法打开：灾备端的资源（尤其是存储）平时无法打开使用，造成资源浪费严重。3.切换时间长：一般需要1－2小时以上才能起来。4.故障情况下切换决策难：有时切换时间＋决策时间>＝灾难修复时间，难以决策，期间无法办理业务。5.难以找到RTO、RPO都为0的0切换方案。6.流程复杂，维护难：系统切换需要一系列管理和技术流程，维护复杂，生产、容灾端都需要维护。7.无法做到在线的系统升级迁移和新业务上线。这种情况下，我们急需探索在核心系统中引入容灾系统双活零切换技术，基于如下考虑：1.可以从降低运行风险、提高客户满意度等方面提升业务运营水平。2.可以从降低业务停机窗口、降低维护工作量等方面降低系统运维压力。3.可以降低系统灾难处理压力、最大限度降低业务中断时间，从而提高客户满意度。4.使容灾侧资源平时可用，达到双活。5.降低演练测试的业务停顿窗口，提升演练质量。（一）现有容灾系统架构分析从系统架构上看，容灾方案主要存在如下三种形式：主备模式、双中心互备模式、双活并行模式，而目前各省采用的前两种形式，RTO均不为0，容灾端平时不可用，需要技术、流程保证切换，而双活并行模式，理论上在灾难发生时不影响业务，可以做到”0”切换。                       ·主备模式：在一个中心部署生产系统，另一个中心部署备份容灾系统，通过存储复制或逻辑复制手机实现保护，实现冷备切换，这种情况一般采取存储底层的srdf、pprc复制技术，平时容灾端资源不成在对外应用，数据库不能打开，再出现故障时需要执行定位、切换决策并执行切换流程，故障恢复时间指标RTO至少在半小时，故障恢复点指标RTO可以根据采用的技术不同等于0或接近0。·双中心互备模式：在两个中心机房各自部署一部分应用，既部署生产又部署容灾，互为容灾备份机制，具体每个系统实现机制同主备模式，可以说是主备模式的扩展，是为了解决容灾端资源闲置的临时性方案，生产和容灾同步技术和主备完全相同，计算资源可以通过虚拟化技术实现生产和容灾共享来节约资源，RTO、RPO指标同主备模式。·双活并行模式：一种全新的容灾模式，相同系统在两个中心均能打开使用，承载对外服务，任何一边坏掉不影响业务，灾难情况下可以不需要决策和执行切换，可以实现RTO接近0。（二）现有技术分析为研究双活架构，2015年根据总部统一部署和规划，多个省份成立联合项目组，结合CRM应急保障体系，试点研究最优的双活技术架构。·方案1：基于数据逻辑复制软件，如dsg、gg、shareplex、触发器等。·方案2：基于数据库自身，如Oracle active Dataguard。·方案3：基于远程卷管理软件（主机虚拟化），如赛门铁克、卷管理、OracleASM等。·方案4：基于存储虚拟化设备（SAN虚拟化），如emcvplex，IBMsvc，华为vis等。·方案5：基于存储自身（存储虚拟化），如HDS、HP等（刚发布）。·方案6：基于存储HA机制，如IBMpowerswap，日立HA等。二、方案分层介绍和传统主备方式不同，实现双活需要整个系统架构做改造，即接入层、应用层、数据层、基础架构层等分别考虑：·接入层：需要借助DNS、全局负载均衡等技术实现双活接入和智能路由，流量调配。·应用层：基于互联网化能力开放分布式集群架构，采用ebus服务总线技术对外统一接入。·数据层：需要构建双中心同时可读写的机制，例如OracleExtendRAC。·基础架构层：网络上对稳定性和带宽吞吐性能要求更高，甚至需要打通跨中心的二层网络。存储方面，则需改变一主一备的读写机制，实现同时可读写。下面各层进行仔细介绍。（一）数据层1、双活技术架构数据库层双活部署目前业界主要有三种方式：A/S（Active-Standby）方式，OracleRAC集群实（Active-Active）方式和通过第三方数据复制软件方式。1）Active-Standby方式：基于OracleADG技术，采用从主库向备库传输redo日志方式，备库恢复数据过程可以用只读方式打开进行查询操作，实现了部分双活功能，在主节点故障后可以将备节点切为主节点，平实备节点可以提供只读操作。2）Active-Active方式：通过OracleExtendRAC实现多个集群节点同时对外提供业务访问。该方式做到故障无缝切换，提升应用系统整体性能。3）数据复制软件方式：通过实时抽取在线日志中的数据变化信息，然后，通过网络将变化信息投递到目标端，最后在目标端还原数据，从而实现源和目标的数据同步。 2、基于数据库-ORACLEADG技术特点：·通过网络从生产向容灾传输归档或redo日志，容灾端恢复方式同步数据。·Oracle11g以后容灾库可打开为只读模式，容灾切换时能快速alter为读写状态。·该方式数据同步效率较高，对硬件资源要求低，支持可以线性扩展而不对生产系统造成影响，且底层存储支持异构，正常情况两边数据延迟不大。一般启用场景：1）作为应急或容灾：只有生产侧可以读写，容灾侧只读，双活读，非双活读写。按照测试，数据库切换时间在30S左右。2）作为读写分离机制：分摊生产端压力，降低生产负载。·只读查询业务分离（ADG侧平时运行从生产库迁移过来的查询业务）·数据库备份（使用RMAN进行全备和归档备份到带库）·经分数据实时抽取（当前通过BCV抽取非实时数据）·DB变更前数据库快照备份（大版本升级时同步到BCV工作）·承载BCV库功能，可下线BCV库，释放高端存储给生产使用3）作为数据保护手段：如在ADG库上启用FlashDB特性，需要时可以执行闪回，以恢复误操作等导致的生产库上的数据丢失。技术特征：·通过dsg、goldengate等逻辑复制技术实现跨中心数据库的相互复制，共同提供对外服务，互为备份。·支持跨异构环境，对系统负载影响很低，对交易型数据做实时抓取、路由、转换和传递·支持多线程，提供旁路顺流模式，不影响生产库性能其中：·两个数据中心各建一套数据库，物理独立·基于数据库日志准实时复制数据·ROWID映射机制（对应源数据库和目标数据库的数据记录），通过ROWID来实现记录的定为，在数据装载效率方面有提升·需手工干预故障3、对于ADG和数据复制双活方案对比4、基于Oracle ExtendedRAC双活架构技术特征：·Oracle ExtendedRAC以跨中心共享存储为基础，通过共享存储资源和OracleClusterware数据库集群管理，实现各个中心节点对数据库并行访问。·共享存储可以采用存储自身数据复制技术，存储虚拟网关或远程卷管理等技术，下图是采用的OracleASM存储管理，实现数据的双向实时复制。·ASM支持对本地磁盘的优先读取，避免跨数据中心的数据读取，从而提高I/O性能并减少网络流量；关键实施要点：·两个数据中心分别部署一套存储，各提供一套LUN设备给全部数据库主机。·存储的SAN网络和RAC心跳网络需使用低延迟、高带宽的DWDM光纤链路。·配置ASM磁盘组。每个磁盘组配置两个失效组，每个失效组对应来自一套存储的LUN设备。·在第三个站点部署用于RAC的第3个投票盘，使用NFS的方式挂载到所有数据库主机。·与管理普通的RAC系统类似，需要重点加强对站点间光纤链路情况的监控与应急。一般启用场景：·由于在两个数据中心部署了两套存储和主机设备，因此能够提供对数据中心级别故障的全方位容灾，比如停电、地震等。·出现故障时恢复时间极短，理论上可以达到RTO和RPO为零。·作为同城容灾的解决方案，并具有最高效的资源使用率。5、内存数据库双活技术实现技术特征：·将数据常驻在内存中直接操作的数据库。相对于磁盘，内存的数据读写速度要高出几个数量级，将数据保存在内存中相比从磁盘上访问能够极大地提高应用的性能，目前在BOSS系统内存库已被广泛用于实时计费，主要厂商有OracleTimesTen，Altibase等。内存库集群部署主要有HA主备模式，双活模式，线性拆分和分布式集群四种模式。1）HA模式：·在两个数据中心，备库只读，具备故障转移和容灾备份功能。·主备之间日志同步或异步同步，数据同步延迟比较严重。·适合物理库较小，内存容量不大非关键业务场景·扩展性差2）双活模式：·两套内存库部署在两个数据中心，支持双读写，具备故障转移和容灾备份功能。·数据库之间基于日志采用同步或异步相互同步，但相互之间数据同步存在冲突问，造成数据不一致问题。3）线性拆分模式：针对物理库较大，受内存容量限制问题，在HA基础上将物理库按地市或业务线性拆分成多套内存库，所有内存库支持同时分片读写，客户端请求都通过前端统一接口路由进行分发和处理。·主备间基于日志同步或异步同步；·系统扩展性较强，但维护难度较大；·支持不同地市或业务双活读写。4）分布式集群模式：采用分布式内存库，基于x86分布式集群部署，如：思特奇iDMDB。·主备库基于日志同步或异步同步·支持双活读写（前提数据层和存储层实现双活）·支持分布式自动加载和路由能力·数据自动冗余，RPO=0·支持在线扩展，路由自动调整，便于维护。·开放化，标准化，支持sql92，ODBC,JDBC等6、双活技术优缺点比较（注：应根据实际情况选择合适的方案，只有ExtendedRAC为真正的双读双写）（二）存储层1、双活技术架构存储层作为整个系统核心基础架构平台，其双活技术在整个架构中起到关键作用，目前基于存储层双活方案主要有下面三种：·基于远程卷管理软件的虚拟化，如：Symantec SF，IBMLVM等·基于存储网关虚拟化，如：EMCvplex，IBMSVC·基于存储自身卷镜像技术，HDSGAD1）卷管理软件虚拟化：通过安装在主机上卷管理软件的逻辑卷镜像技术实现底层数据逻辑同步。2）存储网关虚拟化：在每个站点新增存储虚拟化网关设备组成跨站点集群，并对存储卷进重新行封装，对外提供主机I/O访问。3）存储卷镜像技术：将两套磁盘阵列组成一个集群，两台存储上的LUN被虚拟化为一个虚拟卷，主机写操作通过卷虚拟化镜像技术同时写入两个数据中心的存储设备，保证站点之间数据实时同步。 2、基于远程卷管理软件技术特征：·数据同步：底层数据复制采用远程卷管理软件，如赛门铁克的TorageFoundation（SF）、IBM的GPFS等，通过逻辑卷镜像技术实现底层数据逻辑同步。上层应用采用OracleExtendedRAC方案实现远程4节点RAC,使生产和容灾节点都处于在线状态，应用逻辑访问的是同一个数据库。·数据读写：支持双读写。·数据一致性：完全一致。远程卷管理软件改造前后变化：改造前：·主机只需识别当前中心存储·可使用任意卷管理软件如LVM、ASM等·正常状态下容灾存储只读·IO读写都访问本地存储，数据复制由存储底层完成改造后：·主机需识别当前中心存储和远端存储·只能使用SF的卷管理软件·两地存储都为读写状态·数据复制由主机卷镜像完成，写IO以远端写确认为准，读IO优先本地存储3、案例分析——某省方案：IBMGPFS+Oracle11g应用情况：测试了接近一年，2013年在客服资料数据库上线，基于gpfs+oracle11grac。效果：容灾端资源平时可以对外服务或查询，无需专门切换步骤，故障时只需要检查即可。（注：容灾端数据库实例也可以作为统计分析库）前提条件：一、跨数据中心大二层网路建立，二、完善的仲裁机制，第三中心最好，建议环状双平面的网络架构，三、中心间需要高带宽，否则会影响性能。缺点：架构更加复杂；san网络复杂；软件兼容性考虑很多；RTO<=3分钟。 实现要点：·网络改造：需要打通两个中心间大二层网络。·底层存储链路改造：需要认到对端机房存储，带宽要求高。·卷管理软件改造：从现有主机自带LVM迁移到远程卷管理·OracleextendedRAC搭建·提供可靠性较高的二层网络（心跳网络）·提供可靠性较高的共享存储（投票盘）·对底层链路和距离要求高：距离太远会导致响应变慢，官方建议50KM之内。使用场景：·容灾演练时不需要进行数据库的切换，只需应用切换，甚至不用切换。·可分摊当前生产端压力，降低生产负载·按业务梳理进行压力分摊·数据库备份只需要在单中心进行备份·经分数据可实时从生产抽取（通过BCV抽取非实时数据）·提升系统硬件冗余度，提升了系统高可用能力4、基于存储网关虚拟化技术特征：·实现原理：将存储虚拟化技术（EMC的vplex）和Oracle的远程rac技术结合，实现跨中心的数据双活访问。·跨中心的两个存储虚拟成一个对外访问，内部实时同步，保持数据的一致性，平时两边主机分别访问本地存储，故障情况下可跨中心访问对方存储。 5、基于存储虚拟化设备VPLEX存储管理机制：·VPLEX对存储卷进行封装后，让主机的I/O通过VPLEX来访问存储。·封装后的VPLEX卷只是指针集，所有数据的访问还是通过这个指针指到后端存储上，原来存储上的卷的各种属性都不会改变·原先存储卷所具有的各种属性，比如raid保护，快照、克隆等在存储内的各种设置对VPLEX透明，VPLEX不感知也不干涉。·被VPLEX接管了的存储卷只能通过VPLEX访问，不能再直接map给其他主机。·对于同一个数据块的读写冲突机制，是由RAC来保证的。·同步中断后所有数据改变信息都会记录在保持活动的VPLEX一端的log卷中，只要log卷不满，就不会发生全同步，都是增量同步；VPLEX在设置的时候会配置log卷，确保不论多长时间都不会发生全同步的。·具备脑裂预防服务器“witness”：witness是VPLEX的仲裁装置；IBM、华为等也有类似VPLEX的存储网关实现方式，原理有些差异，但因为应用较少，不再介绍。案例：某省基于存储网关虚拟化·通过VPLEX虚拟化技术实现存储及数据的双活，在两个数据中心同为生产并服务于不同主机，实现双活双中心架构·通过Oracle跨站点集群技术提高应用层面的业务连续性，实现应用及业务的双活·两站点主机各自使用本地存储资源，确保性能和效率，提高资源利用率·双中心心跳网要单独组网，防止脑烈6、基于存储HA机制未有应用案例，目前有IBM的powerHAHyperSwap、日立的HAM技术等，原理基本一样。技术特征：·需要采用IBM或日立高端存储设备，利用其虚拟化软件。·主机实现两边并发对外访问，就近原则，存储有一端需要远程读写，效率较低。·上层需要结合Oracle远程rac实现双活 7、基于存储自身卷镜像目前还未有应用案例，HDS/HP/HuaweiOceanStorV3等刚刚发布不久，完全基于存储自身卷镜像实现。技术特征：·不需要额外软硬件，需要采用特定高端存储设备，如VSP、XP7以上才可以。·存储架构没有改变，易于实行。·两边存储可以同时读写。·上层需要结合Oracle远程rac实现双活8、双活方案综合分析（注：整体看红色为最优方案，但要根据各省实际情况选择，上述方案均需要ExtenmdRAC支持）（三）接入层1、基于DNS+全局负载均衡双活架构建设背景：·随着对访问质量和用户感知的提升，对支撑系统稳定性和业务连续性提出更高要求，从数据级容灾升级到应用级容灾，如何减少应用层数据中心切换时间，降低RT0----基于DNS+全局负载均衡保障（GSLB）应用层双活保障架构。·应用级双活：当单数据中心出现故障时，可以将请求引导向另一个可用的数据中心，实现双活高可用。·智能流量控制：GSLB根据后端服务器负载和链路状况实现不同站点间流量调配，链路优选，保证用户访问最佳性能服务器，确保访问质量，提升用户感知。 关键技术方案：·面向应用的智能流量控制·互联网业务多中心并行运行·内网基于IP地址发布的业务多中心并行·突发业务流量处理·应用交付设备集群部署·应用优化和安全·应用加速优化·数据库快速复制·七层DDoS和应用层攻击防护·自动化运营·一键备份·数据库的一键切换1）互联网业务多中心并行模式：通过一组GSLB来对外提供服务，GSLB监控服务的状态，并通知组内其他设备，对于每一个DNS请求返回最佳结果，好的策略选择和配置方式可以最大幅度提高客户体验。2）内部业务多中心互备模式：对于内网业务通过一组GSLB来提供服务，实现DNS解析，负载分发和故障切换。优点：·易于控制，可实现多种流量分布模型，主备、主主或者分应用主备等模型·维护方便，自成系统，与其他设备松耦合·可根据地理位置分布、网络距离或者应用繁忙程度动态调配缺点：·应用必须采用DNS方式进行访问·切换时间相对较长（取决于TTL时间），通常用于互联网应·用5-10分钟，内网应用30-60秒（四）应用层1、应用层设计双活需要从接入、应用层、数据连接等层面考虑实现，才能实现“零”切换。1）建议构建统一管理的接口层或采用服务总线技术：现状：系统使用的协议众多。难以做到每个对外服务接口均支持高可用性，无法实现对外服务的零切换容灾。·网上营业厅、WAP使用CICS协议；·短信、VC、银行等使用SOCKET协议；·IVR、自助终端使用EASYCICS协议；·一级BOSS使用HTTP＋XML协议。对此，需要做的是：·建设统一的对外应用接口平台，或使用SOA架构·负责应用路由/服务指向、对外/对内接口协议的封装和适配功能·建议采用多实例负载均衡的部署模式，在多个服务器间分担系统压力·建议实施时在各个中心建设适当数量的服务器和网络链路冗余，实现系统容灾的无缝切换2）实现应用自动重连机制，确保自动切换，减少人工切换。3）采用全局负载均衡、DNS等技术实现灵活接入。4）建议双中心部署相同的应用集群方式。我们的项目背景和方案中的各个分层，那么下篇就云化下的双活，分享双活技术关键点和一些试点效果。三、云化下的双活1、云化后的双活考虑云化后，一是出现虚拟化技术，二是应用实现集群化和x86化，难以沿用原有的设计方式，而需要考虑集群化的业务连续性双活方案。场景1：第三代中EBUS跨中心双活集群第三代CRM引入分布式服务总线一层，即企业及服务总线，由于EBUS为服务集群，需要做较多的配置，对集群一致性要求较高，建议引入分布式协调机制实现双活设计。场景2：基于VMware虚拟化平台双活设计基于存储阵列双活和VMware跨站点集群功能实现虚拟化平台数据中心容灾解决方案，在阵列双活技术支撑下，通过VMwareCluster的HA高可用功能实现故障业务切换保护，从而达到保证业务连续性的要求。·基础架构层：网络站点间二层互联，采用波分传输，存储实现双活为上层提供共享存储；·将两个数据中心服务器配置为一个集群，通过HA和DRS实现高可用和资源动态智能分配；·服务器之间建议通过万兆以太网提供心跳服务与vMotion迁移流量，集群内的所有服务器需符合集群的兼容性规则。关键技术：·VmwareHA高可用1）跨站点集群高可用；2）自动监控和检测服务器故障，自动重启VM无须人工干预。·VMwareVmonitor 动态迁移实时在线迁移，不中断业务情况下硬件维护。·VmwareDRS 分布式资源调度1）自动计算和平衡资源，提高硬件资源利用率；2）跨资源池资源自动、智能优化。四、双活技术关键点关键点1：大二层网络除了方案4外，均需要采用跨中心间大二层网络，需要确定最优的方案。·方案1：采用OTV技术把二层vlan跨三层打通·方案2：采用二层光纤直连技术打通·方案3：采用基于MPLS网络的VPLS互联几种大二层方案优缺点分析：建议直连方案效率最高，其次overlay方式，再次MPLS。关键点2：GoldenGate双活方案数据同步优化关键点基于数据复制软件OracleGoldenGate性能瓶颈在数据同步环节：实际使用中发现GoldenGate主要性能瓶颈在复制进程Replicat入库速度，因为在容灾端恢复数据过程是执行逻辑SQL，非常消耗资源，总的来说GG性能因素包括：CPU，内存，磁盘I/O，网络和DB性能，下面针对数据同步关键环节优化建议。抽取进程（Extract）：DBLog平均生成速度在30~50GB/h，CPU占用1.9%，该进程主要瓶颈在于LCR转换为UDF环节，主要优化建议：·拆分Extract进程，建议同一个schema下表尽量在一个进程组中·优化进程参数如eofdelay何flushsecs等·I/O部分建议增加日志读取间隔3s，增加内存刷新时间3s投递进程（Pump）：DBLog平均生成速度=在15~30GB/hCPU占用7%，带宽1GBDBLog/分钟为10~15Mb/s。主要瓶颈在带宽和I/O两个部分，优化建议：1）带宽优化：·复制的表最好有主键或唯一索引，减少生产日志量·数据传输过程启用数据压缩特性，减少带宽需求量·适当增大TCP缓存2）I/O部分优化：·增加队列读取间隔为3s，内存刷新时间为5s复制/应用进程（Replicat）：结合运维经验单进程处理速度为1GB队列/h，该环节出现性能问题较多，需要重点优化：·合并小交易减少事物数量，减少写checkpointfile/table次数·大交易拆分（maxtransops参数），提高写入速度·基于表或Range等拆分replicat进程关键点3：OracelADG双活方案数据同步性能分析对于Oracle 11gADG双活方案数据同步时延分析，系统环境如下：·日志产生量（采集于2015年4月初）日均产生归档量1300GB，其中１节点600GB，2节点700GB。1天日志的峰值为1705GB，１节点峰值811GB，2节点峰值911GB。单个小时日志峰值为183GB，1节点峰值90GB，2节点峰值96GB。·网络流量采用千兆网，传输日志平均占用带宽为16.24MB/s，单个小时内峰值为52MB/s·应用时延（TransportLag+ApplyLag）异步方式传送日志，平均延时0.65秒，正常业务处理期间时延小于10秒；生产库中产生大量I/O的维护操作，比如添加数据文件，会导致目标库应用时延相应增加，可通过调整维护作业时间窗口加以避免。关键点4：OracleExtendedRAC双活方案关键参数基于Oracle 11g ExtendedRAC+IBMGPFSA-A 双活方案数关键参数：注意：·关于RAC仲裁和GPFS仲裁，保证RAC的磁盘仲裁要晚于GPFS的仲裁，使得在网络故障情况下GPFS提前RAC做出判定。·所有网络均采用LoadBalance模式的EtherChannel，并且网络间做到二层隔离关键点5：内存数据库数据同步性能Oracle 和TT内存库几种模式下数据同步性能分析：1）Oracle到TT库同步：结合运维经验和Oracle官方理论，只要Oracle端性能满足，TT端Cache就能够满足同步要求，实际中刷新间隔时间30秒内，基表约为600MB，当Oracle更新数据量小于15万行记录时，均能在刷新间隔内完成，但对于当Oracle批量业务，Oracle到TT端的同步效能将呈非线性（近指数）下降的趋势，建议将大批量业务拆成小事务处理，分批提交。2）TT主备异步模式同步：结合测试和运维经验主备同步极限能力大约为1GB/分钟，当大于1GB时同步出现积压。3）TT主备同步模式：同步性能和事物大小及设置超时时间有关系，当主节点事物较大（测试中10万行35M左右），会出现提交超时，同步友好模式下，备节点事务超时，主节点将会提交，结束该事务并继续下一个事务处理；非同步友好模式下，备节点事务超时，主节点将处于等待状态，阻塞排队事务的处理。关键点6：心跳和网络设计防止脑裂1、由于数据中心间距离远，网络稳定性相比同机房差，必须需要额外进行冗余设计，如网络连接、内部网络、san连接等。2个数据中心间网络不稳定情况下，无论存储虚拟化技术还是oracle的rac均可能出现“脑裂”现象，造成访问中断，数据不一致现象发生，需要仔细设计，如采用互联环状全冗余架构等、完善的仲裁机制等。2、对跨中心间的网络带宽、存储访问带宽利用率不能超过30%。3、双活由多层软硬件组成，如数据库rac、远程文件系统、存储等，需要仔细规划他们之间的心跳参数，确保越低层的心跳超时时间越高。·例子：powerHA仲裁机制例子：Vplex仲裁机制VPLEX双活中心数据仲裁—预防“脑裂”·具备脑裂预防服务器“witness”：witness是VPLEX的仲裁装置；·当链路中断的时候，witness会让一个VPLEX继续工作，另外一个VPLEX停止I/O，以保证数据的一致性，防止脑裂发生；·具体哪个站点工作，哪个站点停止可以预先指定。·ORACLERAC的心跳参数：misscount是RAC网络心跳时间，disktimeout是表决盘的心跳时间关键点7：需要全面的计划内外测试场景双活涉及到跨中心网络层，数据层和存储层，故障场景相比较传统架构更多，更复杂，相互之间存在多种依赖关系，需要充分设计故障测试场景：五、双活效果山东移动通过双活项目试点，取得了一定成果，如下：·2013年6月完成OracelExtendedRAC+IBMGPFS A-A双活方案在客服系统技术验证并完成上线。·2014年4月在资源库进行Oracle11g ADG技术验证和上线，主要用于CRM应急系统和读写分离。·2014年2~3月IBM PowerHAHyperSwap测试。·2014年6月基于Oracle 11g ADG双活技术在营业四个数据库实现上线，主要用于CRM应急和读写分离---四个区的营业数据库。·2015年10月开始测试基于存储自身的双活技术。预期效果：·降低运营风险，提高内外客户满意度。BOSS系统停机窗口构成：主动变更：故障＝1:1，期间主要通过应急停开机系统保证客户缴费开机。·引入零切换技术，可以大幅降低BOSS系统停机窗口（含主动和故障），预计降低40－60％，由目前每年150小时降低到70小时左右。·提高故障情况下的恢复速度，由现在一般需要30分钟左右到5分钟之内，可以大大降低中心维护压力，提高客户满意度。·实现双活，可充分利用容灾侧资源，相当于节约40％的硬件投资。