作者: ATS王绘丽/李洪涛
作者简介：
王绘丽：目前任职于IBM混合云计算部门，资深工程师。超过10年的服务银行客户的经验，熟悉银行核心系统基础架构，目前主要专注于银行数据中心的双活研究。
李洪涛：从事IBM主机相关技术和方案实施工作已有24年的经验。致力于为中国主机客户提供尽心尽力的服务。对业界其他的IT技术和架构也有充满兴趣。
文章导读：
继2016年底宇宙行成功进行双活乾坤大挪移Live Demo之后，作为双活1.0的进阶版，双活2.0应运而生，我们称之为GDPS/Active-Active ZDL（Zero Data Loss）即双活数据零丢失解决方案。本文简单明了地解释ZDL的基本原理，以及和双活1.0基本架构的对比和用户价值。在文章的最后还回答了两个很关键的问题：1.为什么要引入PPRC? 2. 双活ZDL架构下的对称和非对称部署。
在IBM大型主机的世界中，有一个GDPS家族为数据中心提供全方位的呵护。经历了20多年的历练，这个家族可以高质量地提供好几种灾备和双活的解决方案，再配以灵活的深度可裁剪能力，自然有适合您的选择。其中的GDPS/Active-Active双活方案宇宙行已经在两年多前成功实施上线，并成功实现了生产系统运行中进行的一键式乾坤大挪移。
事隔一年多，关注宇宙行的朋友可能还注意到了朋友圈里这样一则消息《工行主机新一代双活非对称架构投产成功》（2018年4月）：
宇宙行总是不负众望的。升级了同城双活架构到达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(零数据丢失)架构的数据复制架构不同：
* 图中标注的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的核心作用。可以罗列出至少以下几点：
- 提供一个对整个GDPS/A-A架构进行集中监控的平台；
- 启动/停止数据复制；
- 管理、监控不同的负载(workload)；
- 管理、操作跨站点的负载均衡；
- 管理、操作磁盘及软件复制架构；
- 对两个站点的主机进行管理和操作，包括进行集群和成员的启动/停止，临时容量调整等；
- 进行计划内/计划外的自动化负载切换或站点切换；
- 用户可以通过裁剪脚本嵌入自己特有的一些操作。
别看架构变化不太大，可产生了两大效果：
第一，磁盘级同步数据复制在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的方式，那么，我们就说这样的配置是对称架构，否则就是非对称架构。
如果真到了对称架构的模式，我们又有更多的想象空间了。比如，对称架构下的站点切换模式和平台运行模式。
