上篇已经详细介绍了我们的项目背景和方案中的各个分层，那么下篇就云化下的双活，分享双活技术关键点和一些试点效果。

1、云化后的双活考虑

云化后，一是出现虚拟化技术，二是应用实现集群化和x86化，难以沿用原有的设计方式，而需要考虑集群化的业务连续性双活方案。

第三代CRM引入分布式服务总线一层，即企业及服务总线，由于EBUS为服务集群，需要做较多的配置，对集群一致性要求较高，建议引入分布式协调机制实现双活设计。

基于存储阵列双活和VMware 跨站点集群功能实现虚拟化平台数据中心容灾解决方案，在阵列双活技术支撑下，通过VMware Cluster 的HA高可用功能实现故障业务切换保护，从而达到保证业务连续性的要求。

• 基础架构层：网络站点间二层互联，采用波分传输，存储实现双活为上层提供共享存储；

• 将两个数据中心服务器配置为一个集群，通过HA和DRS实现高可用和资源动态智能分配；

• 服务器之间建议通过万兆以太网提供心跳服务与vMotion迁移流量，集群内的所有服务器需符合集群的兼容性规则。

关键技术：

• Vmware HA高可用

  1）跨站点集群高可用；

  2）自动监控和检测服务器故障，自动重启VM无须人工干预。

• VMware Vmonitor 动态迁移

  实时在线迁移，不中断业务情况下硬件维护。

• Vmware DRS 分布式资源调度

  1）自动计算和平衡资源，提高硬件资源利用率；

  2）跨资源池资源自动、智能优化。

除了方案4外，均需要采用跨中心间大二层网络，需要确定最优的方案。

• 方案1：采用OTV技术把二层vlan跨三层打通

• 方案2：采用二层光纤直连技术打通

• 方案3：采用基于MPLS网络的VPLS互联

几种大二层方案优缺点分析：

建议直连方案效率最高，其次 overlay方式，再次MPLS。

基于数据复制软件Oracle GoldenGate 性能瓶颈在数据同步环节：实际使用中发现GoldenGate主要性能瓶颈在复制进程Replicat入库速度，因为在容灾端恢复数据过程是执行逻辑SQL，非常消耗资源，总的来说GG性能因素包括：CPU，内存，磁盘I/O，网络和DB性能，下面针对数据同步关键环节优化建议。

抽取进程（Extract） ：DB Log平均生成速度在30~50GB/h，CPU占用1.9% ，该进程主要瓶颈在于LCR转换为UDF环节，主要优化建议：

• 拆分Extract进程，建议同一个schema下表尽量在一个进程组中

• 优化进程参数如eofdelay何flushsecs等

• I/O部分建议增加日志读取间隔3s，增加内存刷新时间3s

投递进程（Pump）：DB Log平均生成速度=在15~30 GB/h

CPU占用7% ，带宽1GB DB Log/分钟为10~15Mb/s。主要瓶颈在带宽和I/O两个部分，优化建议：

1）带宽优化：

• 复制的表最好有主键或唯一索引，减少生产日志量

• 数据传输过程启用数据压缩特性，减少带宽需求量

• 适当增大TCP缓存

2）I/O部分优化：

• 增加队列读取间隔为3s，内存刷新时间为5s

复制/应用进程（Replicat）：结合运维经验单进程处理速度为1GB队列/h，该环节出现性能问题较多，需要重点优化：

• 合并小交易减少事物数量，减少写checkpoint file/table次数

• 大交易拆分（maxtransops参数），提高写入速度

• 基于表或Range等拆分replicat进程

对于Oracle  11g ADG 双活方案数据同步时延分析，系统环境如下：

• 日志产生量（采集于2015年4月初）

  日均产生归档量 1300 GB，其中１节点 600 GB，2节点 700 GB。1天日志的峰值为 1705 GB，１节点峰值 811 GB，2节点峰值 911 GB。单个小时日志峰值为 183 GB，1节点峰值 90 GB，2节点峰值 96 GB。

• 网络流量

  采用千兆网，传输日志平均占用带宽为 16.24 MB/s，单个小时内峰值为52 MB/s

• 应用时延（Transport Lag + Apply Lag）

  异步方式传送日志，平均延时 0.65 秒，正常业务处理期间时延小于10秒；

  生产库中产生大量I/O的维护操作，比如添加数据文件，会导致目标库应用时延相应增加，可通过调整维护作业时间窗口加以避免。

注意：

• 关于RAC仲裁和GPFS仲裁，保证RAC的磁盘仲裁要晚于GPFS的仲裁，使得在网络故障情况下GPFS提前RAC做出判定。

• 所有网络均采用Load Balance模式的EtherChannel，并且网络间做到二层隔离

Oracle 和TT内存库几种模式下数据同步性能分析：

1）Oracle 到TT库同步：

结合运维经验和Oracle官方理论，只要Oracle端性能满足，TT端Cache就能够满足同步要求，实际中刷新间隔时间30秒内，基表约为600MB，当Oracle更新数据量小于15万行记录时，均能在刷新间隔内完成，但对于当Oracle批量业务，Oracle到TT端的同步效能将呈非线性（近指数）下降的趋势，建议将大批量业务拆成小事务处理，分批提交。

2）TT主备异步模式同步：

结合测试和运维经验主备同步极限能力大约为1GB/分钟，当大于1GB时同步出现积压。

3）TT主备同步模式：

同步性能和事物大小及设置超时时间有关系，当主节点事物较大（测试中10万行35M左右），会出现提交超时，同步友好模式下，备节点事务超时，主节点将会提交，结束该事务并继续下一个事务处理；非同步友好模式下，备节点事务超时，主节点将处于等待状态，阻塞排队事务的处理。

1、由于数据中心间距离远，网络稳定性相比同机房差，必须需要额外进行冗余设计，如网络连接、内部网络、san连接等。2个数据中心间网络不稳定情况下，无论存储虚拟化技术还是oracle的rac均可能出现“脑裂”现象，造成访问中断，数据不一致现象发生，需要仔细设计，如采用互联环状全冗余架构等、完善的仲裁机制等。

2、对跨中心间的网络带宽、存储访问带宽利用率不能超过30%。

3、双活由多层软硬件组成，如数据库rac、远程文件系统、存储等，需要仔细规划他们之间的心跳参数，确保越低层的心跳超时时间越高。

• 例子：powerHA仲裁机制

例子：Vplex仲裁机制

VPLEX双活中心数据仲裁—预防“脑裂”

• 具备脑裂预防服务器“witness”： witness是VPLEX的仲裁装置；

• 当链路中断的时候，witness会让一个VPLEX继续工作，另外一个VPLEX停止I/O，以保证数据的一致性，防止脑裂发生；

• 具体哪个站点工作，哪个站点停止可以预先指定。

• ORACLE RAC的心跳参数：misscount是RAC网络心跳时间， disktimeout是表决盘的心跳时间

双活涉及到跨中心网络层，数据层和存储层，故障场景相比较传统架构更多，更复杂，相互之间存在多种依赖关系，需要充分设计故障测试场景：

山东移动通过双活项目试点，取得了一定成果，如下：

• 2013年6月完成Oracel Extended RAC+IBM GPFS  A-A 双活方案在客服系统技术验证并完成上线。

• 2014年4月在资源库进行 Oracle 11g  ADG技术验证和上线，主要用于CRM应急系统和读写分离。

• 2014年2~3月 IBM  PowerHA HyperSwap 测试。

• 2014年6月 基于Oracle  11g  ADG 双活技术在营业四个数据库实现上线，主要用于CRM应急和读写分离---四个区的营业数据库。

• 2015年10月开始测试基于存储自身的双活技术。

预期效果：

• 降低运营风险，提高内外客户满意度。BOSS系统停机窗口构成：主动变更：故障＝1:1，期间主要通过应急停开机系统保证客户缴费开机。

• 引入零切换技术，可以大幅降低BOSS系统停机窗口（含主动和故障），预计降低40－60％，由目前每年150小时降低到70小时左右。

• 提高故障情况下的恢复速度，由现在一般需要30分钟左右到5分钟之内，可以大大降低中心维护压力，提高客户满意度。

• 实现双活，可充分利用容灾侧资源，相当于节约40％的硬件投资。

相关专题：

• RTO零切换！山东移动双活容灾最佳研究和实践（上）

• 扩容成本直降2000万！山东移动精华实践分享！