零数据丢失 -- 开创主机双活数据中心新模式

字数 3568阅读 8149评论 1赞 3

**在IBM大型主机的世界中**，有一个GDPS家族为数据中心提供全方位的呵护。 经历了20多年的历练，这个家族可以高质量地提供好几种灾备和双活的解决方案，再配以灵活的深度可裁剪能力，自然有适合您的选择。其中的GDPS/Active-Active双活方案宇宙行已经在两年多前成功实施上线，并成功实现了生产系统运行中进行的一键式乾坤大挪移。

> “…(2016年) 11月5日上午9时25分，在工商银行数据中心（上海）嘉定园区召开的“两地三中心”同城切换现场观摩会上，随着中国人民银行范一飞副行长发出切换指令，工商银行核心主机系统及人行跨行支付系统在2分钟左右实现了由上海外高桥园区至嘉定园区的切换，系统在嘉定园区运行约1小时12分后，10时39分范一飞副行长发布回切指令，系统又成功回切至外高桥园区。接管运行期间，工商银行全集团各项业务正常开展，交易响应情况及系统运行性能良好。…” --来自: [工行在沪召开两地三中心同城切换观摩会](http://www.icbc.com.cn/icbc/工行风貌/工行快讯/工行在沪召开两地三中心同城切换观摩会.htm "工行在沪召开两地三中心同城切换观摩会")

事隔一年多，关注宇宙行的朋友可能还注意到了朋友圈里这样一则消息《工行主机新一代双活非对称架构投产成功》（2018年4月）：
> 。。。4月1日凌晨，在总行信息科技部地领导及全行科技团队地共同努力下，数据中心（上海）基于主机双活2.0技术架构，成功实现上海同城站点间的接管运行，并将主机双活2.0非对称架构纳入常态化运行，标志着工行新一代双活架构建设----“北极星”计划取得阶段性突破，业务连续性保障水平再上新台阶！。。。

宇宙行总是不负众望的。升级了同城双活架构到2.0版！双活2.0和非对称架构，这又是什么意思呢？让我来给您解答一下。2016年底成功地进行了生产运行中的双活乾坤大挪移Live Demo的版本称为双活1.0，这次的进阶版本被宇宙行定版为双活2.0。双活2.0使用的基础架构是IBM称为GDPS/Active-Active ZDL（Zero Data Loss，ZDL）即双活数据零丢失的解决方案。

其实大家都有一个期望就是能够在系统层面做到零数据丢失。然而，通常使用数据库层面的异步复制技术达不到啊。于是，IBM在原有GDPS Continuous Availability sites (GDPS AA 1.0)概念的基础上，结合磁盘复制技术进行创新，特意为同城距离的GDPS AA实现了零数据丢失的功能，从系统层面在保证RPO=0的情况下，一个方案同时解决计划内和计划外的事件应对。

出个简单明了的架构示意图如下，让我们来一起看看GDPS/A-A 1.0的基本架构和GDPS/A-A ZDL(零数据丢失)架构的数据复制架构不同：

![ZDL.PNG](/home/attachment/201806/01/1218371_152786268342716.PNG)
* 图中标注的GDPS/A-A 1.7 ZDL的意思是在GDPA/A-A 1.7版时加入了零数据丢失（ZDL）的架构支持。

**首先**要注意的一点是数据复制路线的变化。1.0的基本架构是通过IBM InfoSphere Data Replication for Db2 z/OS (IIDR，也简称QREP)在生产Site1把Db2的日志更新进行捕获(Capture)，然后传输到Site2进行日志重放(Apply)。ZDL的架构不同的地方是引入了MTMM(Multi-Target Metro Mirror)或者叫MTPPRC。通过磁盘的PPRC同步复制技术把Db2的日志同步传输到Site2。在Site2再进行Db2的日志更新捕获和日志重放。ZDL结合了PPRC同步复制技术和数据库异步复制技术，保证Db2日志RPO=0，再通过数据库复制补齐Site2数据库中的内容(在同一个站点内进行，速度会非常快)，达到数据层面的RPO=0。

**其次**再多看一点MTMM。AA1.0基本架构下，一般的生产系统(在Site1)都会配置本地的PPRC同步磁盘复制，同时激活Hyperswap功能。这样就可以保证本地磁盘的高可用了。而在ZDL架构下引入的MTMM，在保证本地磁盘高可用的情况下，还可以再多一份磁盘拷贝放到远端。如图中所示，RS1和RS2是在Site1的两套磁盘做本地磁盘高可用。RS3是第三份磁盘拷贝放到了Site2。这三份磁盘之间通过三角形两两互联。正常情况下数据复制的方向如RL1和RL2所标识的。MTMM也支持两种配置，一种是三份磁盘等量复制；一种是本地两份全量，第三份部分复制。图示中的RS3是部分复制的配置。如果当本地磁盘发生Hyperswap(RS1故障，RS2接管)后，RL3的虚线会即时转变为RS2到RS3的复制链路，同步两端的状态(MTIR)，并继续进行数据复制。

**再次**来看看QREP复制组件位置的变化。ZDL架构下“在Site2再进行Db2的日志更新捕获和日志重放”，这个变化还是很有意味的。数据复制的架构通过这样的变化脱离了Site1的生产数据库。减少了数据复制组件和生产数据库的相互影响，同时Capture和Apply之间的稳定性也得到极大提升。Site1生产环境变得更加单纯了。

**最后**，CDDS (压缩字典数据集)是新引入的一个重要组件。通过CDDS的PPRC镜像，源端Db2 DSG (Data Sharing Group)的一些关键状态信息都同步复制到了Site2。这样，在Site2的QREP才在不进入源端环境的情况下，能够正确了解源端Db2 DSG的状态，从而进行正确的Capture/Apply操作。例如，CDDS中包含了Db2 DSG集群成员的Log使用状态；包含了源端数据库表正在使用的两代压缩字典，等等。

那么**GDPS**在整个架构中起到什么作用呢？简单回答就是两个中心，两个主机集群，好多磁盘，好多软件实例，还有应用负载，数据复制，你一定想应该有个东西能够统一管理，自动化操作，方便的配置等等，这就是GDPS的核心作用。简单罗列一下至少有以下几点：
1. 提供一个对整个GDPS/A-A架构进行集中监控的平台；
2. 启动/停止数据复制；
3. 管理、监控不同的负载(workload)；
4. 管理、操作跨站点的负载均衡；
5. 管理、操作磁盘及软件复制架构；
6. 对两个站点的主机进行管理和操作，包括进行集群和成员的启动/停止，临时容量调整等；
7. 进行计划内/计划外的自动化负载切换或站点切换；
8. 用户可以通过裁剪脚本嵌入自己特有的一些操作。

别看架构变化不太大，可产生了两大效果：
第一，磁盘级同步数据复制在Site2形成了一个真正的Site1生产数据库的影子，实时同步；
第二，QREP的数据捕获(Capture)移到Site2，变得更加独立。

这两大效果反映到**用户的实际场景中的价值**，那就是无论计划内还是计划外的事件都可以做到RPO=0。同时优化了整体的复制架构，使得复制的效率和稳定性都得到大幅提升。通过GDPS和客户裁剪的脚本可以让两中心的统一运维管理得到极大的简化并提升效率。

总结都写了，但还有两个问题重要问题要说明一下！

**问题一**：为啥要引入PPRC同步复制呢 ？
**回答**：实际效果前面都写到了。那么从理论上如何认识这件事情呢？“双活或者多活数据中心在要求数据完整一致的情况下，就必须要在整体的架构设计中在某个层面保证某一类数据跨中心的完整一致，在出现问题时，可以通过这类数据进行数据库数据的恢复。”这个说法很容易通过反证法证明。

PPRC的引入，是把数据最终恢复用到的Db2日志进行跨中心的同步复制。在数据中心的层面完成整个系统中最关键的数据完整一致的保证。从系统的层面实现RPO=0。

**问题二**：为啥叫非对称架构呢？
**回答**：从上面的图中也可以看到，从Site1到Site2是通过MTMM加上QREP的方式把Db2日志复制到Site2并在Site2进行Db2日志重放。而从Site2到Site1图中并没有明示通过什么方式。如果从Site2到Site1选用的方式也是通过和Site1到Site2一样的MTMM加上QREP的方式，那么，我们就说这样的配置是对称架构，否则就是非对称架构。

**如果**真到了对称架构的模式，我们又有更多的想象空间了。比如，对称架构下的站点切换模式和平台运行模式。。。。

作者：IBM zATS王绘丽、李洪涛

同城双活数据中心双活数据中心方案 IBM双活数据中心双活

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！