【作者】赵海

1. 容灾设计规划的步骤

容灾对于企业的 IT建设来讲是非常重要的事情，如何进行企业的容灾架构设计规划是整个容灾建设的核心关键事宜，因此需要一套方法论或者科学的步骤来参考。概括起来应该遵循以下逻辑进行：

根据图中所示的逻辑思路，我们需要依次解答以下几个问题：

① 为什么要搞容灾建设？

这个问题非常重要，因为企业搞容灾建设的背景可能会因为行业背景、监管标准、业务特点等情况不同而完全不一样。例如多数金融行业搞容灾建设是因为监管的行业要求，有的企业则是因为曾经面临过数据中心灾难教训或者看到别人的教训而主动搞容灾建设。不同的建设目的会导致追求的目标不尽相同。

② 建设成什么样的容灾架构体系，用什么样的标准去衡量？

在《企业容灾选型指南-1：什么是企业容灾》文章当中详细阐述过：RTO&RPO是搞容灾建设的最核心目标，一切容灾建设目的都需要回到RTO和RPO的评估上来。

RTO：企业可容许服务中断的时间长度，简言之业务可以恢复的最快时间。

RPO：企业可容许数据丢失的数量级，简言之数据可以恢复到最新的时刻点。

企业因搞容灾的初衷不同，那么对RTO和RPO的目标也会有严格和宽松之分，所谓严格的RTO&RPO指标就是政府或行业监管的最低标准，不同规模性质的企业有不同的最低标准要求。所谓宽松就是企业为了平衡投入成本和容灾架构带来的受益，可以将RTO&RPO锁定在一定范围内。

③ 建设的容灾架构应该是什么级别（国家标准&国际标准）？

在《企业容灾选型指南-1：什么是企业容灾》文章当中详细阐述过：银监局和中国人民银行对商业银行业最严格的要求标准是5级容灾标准，RPO<=15分钟，RTO<=30分钟。而根据国际标准share78，六级容灾标准是RPO=0，RTO=分钟级；七级容灾标准是RPO=0，RTO近似为0。

企业可以根据这些标准界定自己应该实现的最低标准，比如说5级或者6级标准。

④ 选择什么样的容灾架构技术体系，如何评估各种容灾中的关键技术方案？

以同城双中心容灾为例，企业需要评估网络层、应用层、数据库层、存储层等纵向各个功能层的具体技术方案，同时需要考虑到纵向和横向的融合和扩展。评估的时候，我们需要选择好评估的维度以及关键风险的把控，后续章节我们会详细介绍评估这些关键技术方案的方法和思路。

2. 评价容灾技术的维度

每一种容灾技术方案，从实现的技术复杂度、需要投入的成本、需要承担的风险、技术的先进性、技术的成熟度等几个方面来综合评估，寻求适合企业的最佳技术组合方案 。

① 技术复杂度： 对于容灾技术方案的技术复杂度，总的原则是同目标可达的情况下，架构越简单越好。

大的方面分析来看，不仅仅需要考虑建设的复杂度还需要考虑运维的复杂度；不仅仅要考虑方案本身的复杂度还需要考虑方案需要依赖的环境的复杂度；不仅仅需要考虑横向复杂度还要考虑纵向的复杂度。

② 投入成本： 对于企业来讲，投入成本是非常总要的一项因素。总的原则是同目标可达的情况下，成本越少越好。大的方面分析来看，投入成本不仅包括容灾方案本身的设备成本还需要考虑软件成本；不仅需要考虑建设成本还需要考虑运维成本；不仅需要考虑资源成本还需要考虑人力成本；不仅需要考虑一次性成本还需要考虑持续投入成本。

③ 承担风险： 所谓风险，最主要的就是极端情况下的RTO和RPO风险。总的原则是可以在宽松目标范围内适度降低，但是不能因此而承担灾难性的风险概率。大的方面分析来看，承担风险主要包括极端情况下的数据丢失风险、区域性业务中断扩展的风险。

④ 技术先进性： 所谓技术先行性，一方面要看技术本身与主流发展的方向是否匹配，另外一方面要看技术本身在性能、高可用、扩展性、兼容性等方面的能力。总的原则是在目标可达的情况下，选用先进的技术体系。

⑤ 技术成熟性： 所谓技术成熟性，不仅需要从技术体系本身的发展历史来看它的健壮性和稳定性，还需要从技术方案应用的案例情况以及市场的反馈情况来看技术的成熟性。

当然以上五个方面的评估维度，在具体分析技术方案的时候，可以根据方案本身的特点建立起一套评估指标体系，根据不同维度指标的得分情况来具体评估。

3. 关键容灾技术比较分析

3.1 DB：HA vs AA vs AS

数据库层的集群模式是容灾设计当中必不可少的部分，这部分的服务模式一般会有三种类型：以操作系统级别的HA与数据库服务相结合的模式；通过数据库层实现的AA服务模式；通过数据库层容灾技术实现的AS服务模式。下图是我们对这三种模式的抽象描述：

服务模式 ：只有一个浮动VIP，以主数据中心为基础提供对外数据访问接口服务。

集群模式 ：主备模式，主节点提供服务，备节点故障时刻接管服务。

存储模式 ：主备节点均可以激活存储卷，正常时刻只有激活节点可以挂载存储卷并具备读写权限。

环境依赖 ：跨数据中心L2网络；共享存储卷（可以是操作系统或者是存储网关实现的虚拟共享卷）；第三方仲裁站点（与主备数据中心有相互独立的L3网络）。

服务模式 ：SCAN IP+2个VIP，主备中心以负载均衡的模式对外提供服务。

集群模式 ：主主模式，节点可以扩展，主备节点同时提供服务。

存储模式 ：主备节点共享存储卷，通过节点间的缓存协调机制以及锁机制实现并发控制。

环境依赖 ：跨数据中心L2网络；共享存储卷（可以是操作系统或者是存储网关实现的虚拟共享卷）；第三方仲裁站点（与主备数据中心有相互独立的L3网络）。

服务模式 ：主库VIP+备库VIP，并且不能是同网段地址；主库对外提供服务。

集群模式 ：主备模式，但是主库的A可以扩展为AA集群，主库对外服务，备库故障时切换为主库。

存储模式 ：主备节点各自拥有自己的存储卷，从主库到备库实现数据复制。

环境依赖 ：双中心网络三层可达即可。

我们从技术复杂度、投入成本、承担风险、技术先进性、技术成熟性五个维度来对比分析这几种技术方案的优劣，篇幅的原因，我们这里只做大方面的定性分析，不做体系化的指标模型分析。

技术复杂度上 ，HA和AA模式均依赖于跨数据中心L2网络，AS模式仅需要跨数据中心L3可达即可，相对来讲AS模式的技术复杂度会更优。

投入成本上 ，建设阶段HA和AA模式会因为跨数据中心L2网络环境的建设而投入更多的设备、软件以及线路成本，AS模式多数需要人为干预切换，因此后期需要专门的高水平团队管理容灾切换。

承担风险上 ，AA模式连个节点之间的Cache/Lock管理非常重要，一旦私网出现不稳定问题，影响极其重大，小则性能出现问题，大则数据重大损坏集群崩溃；HA模式正常情况下是单节点控制读写，因此不会产生因为读写竞争出现的重大性能或数据损坏问题；AS模式双节点之间只是日志单向复制，风险相对较其他两种模式小很多。

技术先进性上 ，AA模式RTO&RPO理论上都是零，可以达到7级容灾目标；HA模式(RPO=0，RTO约为0-30分钟级别)，可以达到6级容灾目标；AS模式(RPO约为0，RTO约为0-30分钟级别)，也可以达到6级容灾目标。架构扩展和灵活性方面，AA可以扩展到多节点集群，AS模式可以扩展多一对多以及级联架构，而HA的扩展性和灵活性都非常差；性能方面，AA模式可以横向扩展，AS不仅可以横向扩展，而且可以读写分流；HA模式只能增加单节点处理能力。

技术成熟性上 ，HA模式虽然历史较长，但是并不是一个成熟的数据库高可用技术，它受限于操作系统方面的处理机制。而AA模式就是基于数据库集群服务而诞生的成熟高可用技术，但是官方并没有把它作为一种成熟的容灾技术宣传（例如Oracle将Extended RAC作为过渡的容灾架构，而不是官方正式认可的容灾技术方案），而AS模式是官方认可的成熟容灾技术。

3.2 Replication: Mirror vs Log Replication

关于数据复制技术，我们在《企业容灾选型指南- 3 ：数据复制技术》当中介绍了常见的几种技术方案，但是总结来看，其实无非两种模式，一种是基于镜像的双写复制技术，一种是基于端到端的拷贝复制技术（日志拷贝应用 &存储Block复制，仅考虑日志拷贝应用模式 ）。

对于数据复制的这两种模式的对比分析，我们主要从风险和技术复杂度、先进性三个方面来看：

从承担风险上来看 ，基于镜像实现的数据复制模式，其复制原理主要是基于操作系统存储卷或者存储的Block来进行双写，跟数据库层的事务操作没有任何关联性，无法识别Block里面包含的业务数据。极端情况，如果主数据中心因为数据库层配置文件或元数据之类的数据损坏而导致的灾难，这个时候备数据中心也会发生同样的问题。而基于重做日志应用的数据复制完全是数据库应用层的事务操作实现的数据复制，它的复制不会掺杂数据库配置层、系统层等外界的多余的写操作，因此不会存在这种逻辑Block损坏的事故概率。另外一方面，这种模式的镜像是不平衡的，每一次写过程都会受到IO延时不平衡的影响，性能极大受到外界不稳定网络的影响，而且放在AA数据库集群环境会无限放大。

从技术复杂度来看 ，如果是本地镜像，那么技术复杂度并不高，但是如果是跨数据中心的镜像技术，无论是基于操作系统层还是基于存储层，都是需要基于远距离SAN环境做跨中心的镜像，每一次IO都需要经历远距离写的过程。因此它的技术复杂度一定高于后者。

从技术先进性来看 ，基于镜像的数据复制技术，那么RTO&RPO理论上都是零。基于日志应用实现的复制技术虽然也可以实现同步复制，但是实际应用当中绝大多数采用高可用或者性能模式，网络传输质量好的情况下，RPO只能接近于零，出现故障的时候需要切换时间，RTO指标也不如前者。

3.3 Storage：HA vs AA

存储网关集群技术实现的数据复制，也是基于镜像实现的数据复制，总结市场上的一些产品方案，总结来看主要分为两种模式，一种是以VPLEX为代表的双活网关模式，另外一种是以SVC为代表的HA网关模式（厂商的宣传永远是双活，但是我们需要从单个存储卷的维度去看它是不是双活，另外即使双活做到卷和IO的粒度也不一定是好事，需要辩证去看）：

如图所示，上图是基于HA模式和AA模式的存储网关实现数据复制的基本技术轮廓，主要区别在于两个网关节点的工作模式。HA两个节点针对同一个卷的工作模式是主备，单边故障的时候可以切换到备节点工作，有些产品可以做到同步缓存，甚至利用存储操作系统虚拟化技术做到虚拟机漂移并自动接管存储卷读写，有些则需要较长的切换过程。AA两个节点针对同一个卷的工作模式是主主，通过全局缓存和分布式锁机制控制并发。底层都是双写，只是由一个点写下去还是由两个点协商写下去的区别。

对比这两种技术方案，应该说从技术复杂度、成本投入都没有太明显的区别，所以我们着重还是要从风险和技术先进性及成熟度上来做辩证性比较。

承担风险上 ，存储网关的AA架构类似于Oracle RAC架构，两节点之间的通讯数据量不仅量非常大（维持全局Block缓存和分布式锁），而且非常重要，一旦出现通讯不稳定问题，两节点无法协商完成并发写入控制，严重的时候可能出现更严重的问题。如果与数据库层的RAC集群配合使用，那么风险无疑是雪上加霜，纵向两套集群（DB、Storage）都是同类机制，都严重依赖双数据中心的通讯质量，不确定性就太高了。HA架构相对于AA来讲，最大的优点在于双写是由单边发出的，无需协调控制，最少不会出现因协调不稳定出现的性能及数据安全风险。这两种模式与数据库集群配合的时候，都会面临同样的风险，那就是仲裁冲突的问题，还需要谨慎考虑。 

技术先进性上 ，站在理论的高度，认为可以实现存储卷、IO级别的双活就是技术上的制高点，实现以应用为最小粒度的双活就是伪双活；其实站在业务的高度，我们认为只要两套系统都能运作，都能承载应用就可以了，企业追求的目标是业务连续性，不是IO连续性。这个意义上讲，二者没有区分出太大的优劣。 

技术稳定性上 ，二者都是基于操作系统及数据库高可用技术实现的存储容灾技术，技术源头都有较长历史传承。所以大家还要从市场的应用状况来考察。