谈谈双活业务中心和异地容灾备份设计
谈谈双活业务中心和异地容灾备份设计
今天谈下多数据中心和异地容灾备份方面的内容。在前面一篇文章里面我详细谈到过一个软件业务系统的高可用性设计，其中既包括了IT基础设施的高可用，也包括了业务软件系统设计方面的高可用性设计。
对于高可用，我想再简单总结下，核心为三个方面的内容：
- 高可靠：冗余性设计，无任何单点故障
- 高性能：能够满足大数据量或海量并发访问下响应需求
- 高扩展：能够动态水平弹性扩展
对于三者之间的关系，我前面整理过下面一个图来进一步说明：
上图可以看到高可靠，高性能和高扩展性三者之间的关系。
对于高可靠性来来说，传统的HA架构，冗余设计都可以满足高可靠性要求，但是并不代表系统具备了高性能和可扩展性能力。反过来说，当系统具备了高扩展性的时候，一般我们在设计扩展性的时候都会考虑到同时兼顾冗余和高可靠，比如我们常说的集群技术。
对于高性能和高扩展性两点来说，高扩展性是高性能的必要条件，但是并不是充分条件。一个业务系统的高性能不是简单的具备扩展能力就可以，而是需要业务系统本身软件架构设计，代码编写各方面都满足高性能设计要求。
对于高可靠和高性能，两者反而表现出来一种相互制约的关系，即在高性能支撑的状态下，往往是对系统的高可靠性形成严峻挑战，也正是这个原因我们会看到类似限流熔断，SLA服务降级等各种措施来控制异常状态下的大并发访问和调用。
容灾备份概述
前面谈高可靠性可以看到，我们更多的还是谈的在一个数据中心里面的冗余和集群设计，以确保整个IT基础设施架构没有任何的单点故障。但是如果整个数据中心都出现问题，那么我们的应用自然会受到影响处于不可用状态，同时我们的数据存储也存在丢失的问题。
这也是我们谈容灾备份，很多大的集团企业建设自己的两地三中心的一个原因。
什么是容灾备份？
对于容灾，简单来说就是当数据中心发生各种未知灾难的时候，能够确保数据不丢失或少丢失，同时IT业务系统能够不间断运行或快速切换恢复。
这里面实际上强调了两个重点， 即：
- 数据本身不丢失或少丢失
- 应用本身不间断或少间断
整个容灾设计就是围绕这两个关键目标来实现。
而对于容灾备份则是通过在异地建立和维护一个备份存储系统，利用地理上的分离来保证系统和数据对灾难性事件的抵御能力。
根据容灾系统对灾难的抵抗程度，可分为 数据容灾和应用容灾 。
- 数据容灾是指建立一个异地的数据系统
- 应用容灾比数据容灾层次更高，即在异地建立一套完整的、与本地系统相当的备份系统
当前可以看到，我们更多的已经不再是间断的数据层面的容灾备份，而是需要具备保持业务连续性的应用级容灾能力。
简单来说，就是我们需要设计要整体应用所涉及到的IT基础设施，数据库，应用中间件和应用部署包全部在2个数据中心进行部署。部署完成的架构需要确保即使某一个数据中心完全瘫痪，也不应该影响到业务系统的正常运行和连续性。
对于容灾等级的定义可以参考下图：
从图中可以看到，如果要实现业务系统本身的异地双活和不间断运行，那么就必须达到第七级的异地同步应用容灾的标准。即是：
在异地建立一个与生产系统完全相同的备用系统，他们之间采用同步的方式进行数据复制。当生产中心发生灾难时，备用系统接替其工作。该级别的容灾，在发生灾难时，可以基本保证数据零丢失和业务的连续性。
也正因为如此，我们看到，多数据中心之间的数据库同步复制能力将是构建一个异地同步容灾备份设计的关键内容。
数据库同步复制技术
前面已经谈到，要实现应用级的容灾备份，一个关键就是通过数据库的实时同步和复制，在A地出现机房故障和问题的时候可以平滑快速的迁移到B地。虽然这种远程数据复制和同步存在一定的延迟，但是基本已经可以满足业务连续性的需求。
谈到数据库的实时复制，一般会谈到一个重要产品，即Oracle公司的GoldenGate，该软件是一种基于日志的结构化数据复制软件，它通过解析源数据库在线日志或归档日志获得数据的增删改变化，再将这些变化应用到目标数据库，实现源数据库与目标数据库同步、双活。
GoldenGate可以在异构的IT基础结构（包括几乎所有常用操作系统平台和数据库平台）之间实现大量数据亚秒一级的实时复制。
GoldenGate是一种基于软件的数据复制方式，它从数据库的日志解析数据的变化（数据量只有日志的四分之一左右）。该将数据变化转化为自己的格式，直接通过TCP/IP网络传输，无需依赖于数据库自身的传递方式，而且可以通过高达9:1的压缩率对数据进行压缩，可以大大降低带宽需求。在目标端，GoldenGate TDM可以通过交易重组，分批加载等技术手段大大加快数据投递的速度和效率，降低目标系统的资源占用，可以在亚秒级实现大量数据的复制。
GoldenGate的工作原理可以用下图描述：
在任何实时数据同步和复制中，需要考虑如下几个关键问题：
- 事务一致性：在复制目标端需要按照源端相同的事务环境进行，确保目标上数据一致性。
- 检查点机制：在抽取和装载时都需要记录检查点，确保网络故障下仍然能够完整复制。
- 可靠数据传输：需要保证数据传输的完整性，请求和应答，同时提供数据加密压缩。
对于数据实时同步和复制工具，其核心是需要基于日志来实现，这一方面是可以实现准实时的数据同步，一方面是基于日志实现不会要求数据库本身在设计和实现中带来任何额外的约束。我们也看到有些基于数据库表设计增加触发器或存储过程来实现的数据库复制，这些本身都是损耗了性能和增加了复杂度。
对于数据库的实时同步和复制，阿里巴巴专门有一个开源项目，即otter来实现分布式数据库的同步复制，其核心思想仍然是通过获取数据库的增量数据日志，来进行准实时的同步复制。因此otter本身又依赖于另外一个开源项目即canal，该项目重点则是获取增量数据库同步日志信息。
当前otter的重点是实现mysql间的数据库同步复制，其实这个在前面我一些文档里面谈到基于mysql数据库的dual-master架构的时候已经谈到过，基本即利用的类似技术来实现两个mysql数据库间的双向同步数据库复制。
要注意这个双向本身指既可以A->B，也可以从B->A，在某个时间节点本身是单向的。
对于otter的功能和支持的数据库比GoldenGate要少得多，除了支持mysql数据库间的实时数据同步和复制外，还支持mysql->oracle的单向数据同步和复制。但是不支持oracle->mysql的数据同步和复制。但是otter本身提供了一个很好的开源框架，我们可以基于该框架扩展对其它数据库的支持。
在扩展的时候有一个重点，即数据库本身是否提供了增量数据日志，对于mysql数据库容易实现其主要原因还是mysql数据库提供了相当方便的binlog日志功能，这些log日志本身就很方便的转换为朝目标端执行的sql语句。
而对于常见的数据库，在网上搜索下，可以看到一些做法。
对于oracle，重点是监控oracle的redo log，即在线重做日志和归档日志。对于一些商用产品可以直接监控到redo log，仅仅依赖于该文件而不耗费其它资源。而如果我们来实现，则常用的方法还是基于oracle logminer来对redo log进行解析。虽然性能上稍微有差异，但是基本可以达到准实时的数据库解析和同步。
对于Sql Server数据库的日志分析，首先可以看到网上有一个专门的商业工具，即log explorer，这个工具可以用来做sql server数据库的日志解析和分析。其中对于事务，检查点等都有详细的记录。其次可以使用fn_dblog解析Sql Server的数据库日志，网上有专门的方法在这里不展开，现在还没有具体测试过，但是整个方法思路是没有问题的。
而对于sql server 之间的数据库同步和复制，则sql server本身就提供有方便的基于快照或基于事务的数据库同步复制工具，只需要经过简单的配置即可以实现。正因为这个原因，我们也看到，对于sql server数据库本身在日志解析和分析方面开放出来的能力本身是相当较弱的。
随着国家对自主研发数据库和中间件技术的大力支持，当前还没一个能够实现国产数据库如人大金仓，达梦数据库同国外的oracle ,sql server数据库间的数据实时同步和复制工具。对于这类工具是可以基于开源otter产品的思路来进行定制开发和实现的，但是前提还是各个数据库厂家需要开放相应的日志采集和处理能力。
基于GoldenGate实现数据库同步复制
GoldenGate TDM（交易数据管理）软件是一种基于日志的结构化数据复制软件，它通过解析源数据库在线日志或归档日志获得数据的增删改变化，再将这些变化应用到目标数据库，实现源数据库与目标数据库同步、双活。
GoldenGate TDM 软件可以在异构的IT基础结构（包括几乎所有常用操作系统平台和数据库平台）之间实现大量数据亚秒一级的实时复制，其复制过程简图如下：
GoldenGate TDM的数据复制过程如下：
利用捕捉进程(Capture Process)在源系统端读取Online Redo Log或Archive Log，然后进行解析，只提取其中数据的变化如增、删、改操作，并将相关信息转换为GoldenGate TDM自定义的中间格式存放在队列文件中。再利用传送进程将队列文件通过TCP/IP传送到目标系统。捕捉进程在每次读完log中的数据变化并在数据传送到目标系统后，会写检查点，记录当前完成捕捉的log位置，检查点的存在可以使捕捉进程在终止并恢复后可从检查点位置继续复制；
目标系统接受数据变化并缓存到GoldenGate TDM队列当中，队列为一系列临时存储数据变化的文件，等待投递进程读取数据；
GoldenGate TDM投递进程从队列中读取数据变化并创建对应的SQL语句，通过数据库的本地接口执行，提交到数据库成功后更新自己的检查点，记录已经完成复制的位置，数据的复制过程最终完成。
由此可见，GoldenGate TDM是一种基于软件的数据复制方式，它从数据库的日志解析数据的变化（数据量只有日志的四分之一左右）。GoldenGate TDM将数据变化转化为自己的格式，直接通过TCP/IP网络传输，无需依赖于数据库自身的传递方式，而且可以通过高达9:1的压缩率对数据进行压缩，可以大大降低带宽需求。在目标端，GoldenGate TDM可以通过交易重组，分批加载等技术手段大大加快数据投递的速度和效率，降低目标系统的资源占用，可以在亚秒级实现大量数据的复制，并且目标端数据库是活动的
GoldenGate TDM提供了灵活的应用方案，基于其先进、灵活的技术架构可以根据用户需求组成各种拓扑结构，如图所示：
GoldenGate TDM 可以提供可靠的数据复制，主要体现在下面三点：
保证事务一致性
GoldenGate TDM 在灾备数据库应用复制数据库交易的顺序与在生产中心数据库上的顺序相同，并且按照相同的事务环境提交，确保在目标系统上数据的完整性和读一致性，为实时查询和事务处理创造了条件。
检查点机制保障数据无丢失
GoldenGate TDM的抽取和复制进程使用检查点机制记录完成复制的位置。对于抽取进程，其检查点记录当前已经抽取日志的位置和写队列文件的位置；对于投递进程，其检查点记录当前读取队列文件的位置。检查点机制可以保证在系统、网络或GoldenGate TDM进程故障重启后数据无丢失。
可靠的数据传输机制
GoldenGate TDM 用应答机制传输交易数据，只有在得到确认消息后才认为数据传输完成，否则将自动重新传输数据，从而保证了抽取出的所有数据都能发送到备份端。数据传输过程中支持128位加密和数据压缩功能。
Oracle 公司的GoldenGate产品，可以在异构的IT基础结构之间实现大量数据的秒一级的数据捕捉、转换和投递。GoldenGate可以支持几乎所有常用操作系统如和数据库平台：
操作系统支持：MS NT, 2000, XP, Linux, Sun Solaris, HP-UX, IBM AIX, HP NonStop, TRU64, IBM z/OS，OS/390 数据库支持： Oracle, DB2, MS SQL Server, MySQL, Enscribe, SQL/MP, SQL/MX, Sybase, Teradata, 其他ODBC 兼容数据库
GoldenGate的应用场景-容灾和应急备份
其中一主一备，快速恢复和切换，最小化数据损失，重新同步主备两端数据。主库数据变化能够实时的同步到备库，用途主要是在非计划性停机时候保持业务的连续性。
GoldenGate的应用场景-减少计划内停机
主要是保障业务零或近似零停机，在滚动升级中降低业务中断带来的损失。主要用途是保障系统/应用/数据库在升级，移植和维护期间业务的可用性。
GoldenGate的应用场景-双业务中心
主要是实现负载均衡（需要考虑全局多点的负载均衡，既提高性能，又避免业务中心的整体单点故障），提供系统整体性能。保障连续可用，快递的容灾接管，实现冲突的监测和处理。
业务系统数据库双活和主备设计
首先我们还是回顾下业务系统容灾备份设计的目标究竟是什么？
简单来讲就是要避免在单个数据中心出现无预知灾难的时候，整个数据不丢失，整个应用仍然能够正常持续运行。而对于持续不间断运行，我们仍然可以分为两个层面。
- 完全不间断，自动实现切换，对业务无感知
- 短暂间断，需要人工手工切换负载均衡或IP地址完成
对于生产运营类的企业IT系统需要做到完全不间断，而对于内部管理类的信息系统往往做到短暂间断也可以接受。比如我们常说的电信运营商的BSS域系统，那么就需要做到完全不间断自动切换，而对于MSS域围绕ERP管理系统等，能在30分钟内完成切换调整就可以满足需求。
对于一个双业务中心的设计，可以看到里面有两个重点，一个就是数据库本身的双活设计，还有一个就是应用服务器集群本身的双活设计。
数据库双活或主备设计
对于数据库本身的技术种类，对双活读写的支持，数据延迟的大小，可靠性等可以参考上图进一步了解。在考虑双活数据库设计的时候可以重点参考。
对于双业务中心和异地双活设计，前面我很多文章都已经谈到过，实际上最难的就是数据库如何保证双活，大部分的异地容灾方案数据库本身都是单活的，一个作为备份库。
对于数据库双活和主备设计，实际上在数据库层面分为三个层面。
- 数据库单活：一个做为备份库，平时不工作，在出现问题再动态切换
- 数据库写单活，读双活：只有主库可以写，但是两个数据中心数据可以同时读
- 数据库双活：即表格里面谈到的Oracle ASM Extended RAC方案，这个没怎么接触过
对于应用服务器的Cluster集群，实际要做到双活就比较简单，由于不存在数据持久化的问题，因此只需要搭配上层的全局负载均衡往往就容易实现上层应用服务器集群的双活配置。
方式1：通过GoldenGate来实现数据库单活设计
对于GoldenGate既支持数据单向复制，也支持数据库双向同步复制。
我们可以通过数据库单向复制来实现数据库的主备模式双活，即一个作为Master主节点数据库，一个作为Standby的备库。如下：
当主库出现无法预知的灾难故障的时候，我们可以将访问切换到备库节点上，在主库节点恢复后备库节点重新返回备库模式，前端访问用户也重新连回到主库节点。
也就是说在主库恢复后，实际上还有一个过程即：
备库上所做出的修改和更新需要实时同步更新回主库。
因此虽然说这种模式是数据库单向复制，实际上是指在某一个时点只允许一个方向的数据流。而不是说数据只能够从主节点朝备节点同步。
方式2：通过GoldenGate来实现数据库双活设计
对于数据库双活设计即可以采用GoldenGate数据库双向同步复制来实现。实际上我们并不建议这种方式，主要是以下几个方面的考虑。
即在数据双向复制的情况下对应用系统本身的设计会有额外的要求，比如全局序列号的起始值的规划，如何防止数据循环复制，如果网络存在延迟，如何确保一个大的业务操作实时的数据一致性要求等。这些往往都是双活数据库本身存在的问题。
其次，在数据库双活设计下，应用集群和数据库间往往存在两种方式如下：
对于方式1即应用集群只固定访问同数据中心的数据库，对于方式2即应用集群全部访问上层两个数据库暴露的VIP地址，通过VIP来确定访问两个数据库。
对于方式1我们看到，实际上在数据库中心A的数据库宕机后，由于应用集群可能没有宕机，那么全局负载均衡仍然会分发路由请求给应用集群A，这个时候实际仍然出现访问中断的情况。
而对于方式2采用了数据库VIP后，虽然解决了上面的问题，但是很容易出现应用集群A要跨域访问到数据库中心B的数据库服务的情况。
也就是在采用浮动VIP时候，希望是要做到应用集群A优先访问数据库A，只有当数据库A出现故障的时候才路由访问数据库B。
方式3：不采用GoldenGate的思路
如果不采用GoldenGate，那么我们就需要手工去处理以保证两个数据库间的数据同步复制。在我们实施ESB服务总线项目的时候，由于数据库实例本身无状态和一致性要求，因此我们完全可以采用晚上定时进行数据库增量脚本同步的方式来同步数据。
其次，对于修改元数据的相关操作，则需要应用程序同时在两个数据中心的数据库同时进行操作，这个同时操作也可以通过应用自动实现，也可以人工同时操作，毕竟对元数据配置修改往往本身就是低频操作。
全局负载均衡和智能DNS路由
当我们谈双活数据中心的时候，前面更多谈的数据库的部署和同步方案，既然是双活，那么APP Server应用服务器就必须要做到能够同时工作。而对于应用服务器集群我们考虑的时候要注意，实际上在我们配置的时候，数据中心A和数据中心B两个集群都是操作数据中心A的数据库，否则就会出现数据库双向同步复制问题。
要做到应用集群双活，在前面文章方案已经谈到，必须在数据库中心A和B上面还有一个全局的负载均衡设备进行全局负载均衡，同时全局负载均衡设备本身还需要HA配置确保无单点故障。
对于最终用户的访问，我们企业DNS域名进行访问。
同时在两个数据中心配置智能DNS设备，本身进行HA架构冗余设计，如下。
智能DNS设备实际上要完成的事情很简单，就是用户通过域名访问，智能DNS能够返回具体某个数据中心的上层负载均衡IP地址信息。
我们以单活架构来进行说明如下：
- 用户通过域名访问，将请求发送给智能DNS解析设备
- 智能DNS在主数据中心正常情况下返回主数据中心的负载均衡IP地址
- 在获取到IP地址后，应用再发起对主数据中心的实际业务访问
如果主数据中心本身出现灾难宕机。
那么这个时候请问到DNS的时候则返回数据中心B的负载均衡IP地址信息。这个时候备库数据库自动变化为主库承担应用的读写任务。
应用集群本身的Admin设置和应用部署
对于应用服务器集群，往往会有一个Admin集群管理节点，通过Admin可以实现对应用集群内所有节点的状态监控，应用的部署，负载均衡等相关操作。
即使我们采用了类似F5等负载均衡设备，往往集群仍然需要设置管理节点以方便集群监控和应用程序的部署。
那么在启用双数据中心后可以看到，对于Admin节点建议仍然是在两个数据中心各自一套，即应用程序的更新和部署仍然在两个数据中心各自手工部署来完成。特别是在主备模式下，这种手工方式处理基本没有任何影响。
但是如果在双活架构模式下，如果手工完成往往就存在一定的延迟性的问题。
这个实际又有两种解决方案和思路。
- 其一是通过一个Admin来管理两个数据库的所有集群节点
- 其二是通过灰度发布策略等方法来控制部署时间上的延后
对于第一种方式实际我们不建议，其本身增加了了两个数据中心集群的耦合度，同时本身管理的复杂度，集群本身的状态一致性保证复杂度都会增加。最好的方式仍然是通过灰度发布等策略控制来解决该问题。
