一线架构师实践指南:云时代下双活零切换的七大关键点

朱祥磊 2016-09-08 10:16:28
作者介绍

朱祥磊山东移动BOSS系统架构师,负责业务支撑系统架构规划和建设。获国家级创新奖1项、通信行业级科技进步奖2项、移动集团级业务服务创新奖3项,申请发明专利13项。

 

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

 

三、云化下的双活

 

1、云化后的双活考虑

 

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

 

\

 

 
场景1:第三代中EBUS跨中心双活集群

 

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

\

 

 

 

 
场景2:基于VMware虚拟化平台双活设计

 

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

 

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

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

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

 

\

 

关键技术:

  • Vmware HA高可用

    1)跨站点集群高可用;

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

  • VMware Vmonitor 动态迁移

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

  • Vmware DRS 分布式资源调度

    1)自动计算和平衡资源,提高硬件资源利用率;

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

 

四、双活技术关键点

 

 
关键点1:大二层网络

 

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

 

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

 

\

 

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

 

\

 

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

 

\

 

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

 

\

 

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

 

 
关键点2:GoldenGate双活方案数据同步优化关键点

 

基于数据复制软件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进程

 

 
关键点3:Oracel ADG双活方案数据同步性能分析

 

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

 

\

 

\

 

\

 

  • 日志产生量(采集于2015年4月初)

    日均产生归档量 1300 GB,其中1节点 600 GB,2节点 700 GB。1天日志的峰值为 1705 GB,1节点峰值 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的维护操作,比如添加数据文件,会导致目标库应用时延相应增加,可通过调整维护作业时间窗口加以避免。

     

     
    关键点4:Oracle Extended RAC双活方案关键参数

     

     

    基于Oracle  11g  Extended RAC+IBM GPFS A-A  双活方案数关键参数:

     

    \

     

    注意:

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

    • 所有网络均采用Load Balance模式的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,以保证数据的一致性,防止脑裂发生;

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

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

     

     
    关键点7:需要全面的计划内外测试场景

     

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

     

    \

     

    五、双活效果

     

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

     

    • 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%的硬件投资。

     

    相关专题:

     

     
     
    精选专题(点击蓝色标题可阅读全文)

    ◆  近期热文  ◆  

    阿里、Facebook、Cloudera等巨头的数据收集框架全攻略

    去IOE时代,逆流而上的Oracle Exadata有什么看头?

    MySQL5.7中InnoDB不可不知的新特性

    微信支付商户系统的架构揭秘

    RTO零切换!山东移动双活容灾最佳研究和实践(上)

     

    ◆  近期活动  ◆  

    Gdevops全球敏捷运维峰会广州站

    \
    峰会官网:www.gdevops.com

    \


    活动预告