在容灾的方案中，用户往往会根据预算和业务不同的安全等级要求，制定不同级别的容灾方式，更有一部分最终用户，对安全及潜在的风险知之甚少，至少我遇到部分客户是这样的。

通常我比较中意与金融行业的客户讨论方案，我想这一态度会有很多同行与我达成共识，最主要因为他们通常走在技术最前沿，更快的尝试新技术(毕竟人家有钱嘛)，能够更好的找到方案的切入点，并且管理人员能够更专业的提出一些需求，通常这些需求他们已经认识到，在技术上已经可以解决。

如果我们不考虑客观因素，如何提供一个高安全级别的方案给用户 ？

分享下以往的方案，以及我对容灾安全方面的一些认识，在内容里我刻意省去一些宏观的理论，比如RPO，RTO，或投资回报率之类的，原因在于，我想更贴切的表达我想要表达的内容，而那些通常我只是在方案里面凑字数。

High Availability+Remote Replication +CDP

-至少我认为这是目前最佳的业务连续性方案

--------------------------------------

（一）High Availability__高可用

对于高可用性的理解，集成商经常会通过不同的方式展现给用户，而无论如何展现，都是在尽最大力度包装其方案，使其更完美。导致一些潜在问题无法被客户重视，在今后的运行中，必须花更多时间修复这些“方案Bug”。SNIA权威的定义了高可用性的概念，而目前技术则能够做的更出色，我们升级这个概念为：

当主机意外停机时，业务能够无缝转为连续性，并且能够自动的同步增量数据，无需人工干预。

应用主机：

可以使用应用业务本身的集群功能，如MS Failover Cluster，AIX HACMP，Oracle RAC,VMware vSphere等等，这样能够保障应用主机方面的高可用性。采用第三方集群软件可能要考虑到兼容性和监听参数，并且市场绝大部分的集群软件并不支持-负载均衡机制，仅仅做到应用主机之间的Failover,而这一点Oracle RAC和vSphere绝对会更有优势。

存储层：

在高可用性的方案中，对存储设备提出了更高，更苛刻的要求，而不仅仅基于RAID磁盘的保护。我们希望应用主机集群之间的共享卷时刻响应服务。如果不能够做到这一点，主机已经部署的集群系统将会荡然无存，因此，存储层的高可用更为重要。

关于存储层的高可用性方案，我们有很多选择的余地，但是哪些是我们想要的？

以下有三种方案可选：

1）基于CDP高可用性方案，目前仍然有广泛的市场，这些产品通常会在应用主机安装代理软件，分拆IO至CDP的设备，待主存储故障，由CDP设备进行指定时间点的回退。由此我们需要至少考虑4个问题：需要手动挂在备援卷时间通常是多久？对主机原有性能的影响，甚至说最初设计主机硬件平台时，我们需要把CDP所损耗的性能计算进去？与操作系统的兼容性？支持多少个主机集群？按照自身的经验来说，我认为这对主机性能是个不小的损耗，并且产生恶性的放大效应，尤其是CPU。当主机业务繁忙时，必定会产生更多的IO，此时主机需要更多的性能处理业务，而就在此时，CDP的代理软件同样提出了更高性能需求，因为有更多的IO要处理，看来EMC当初把分拆IO的工作交给SAN Switch确有优势。另外，分拆IO到CDP的设备是实时写入的吗？这一点很重要。如果是实时的，意味着CDP存储设备写入的性能至少要高于主存储，否则会降低原有的IOPS。如果不是实时写入的，意味著在应用主机会有Buffer，当主机意外停机后，会导致数据丢失，而丢失的程度却居于Buffer到底有多少东西。

通过以上来看，依靠CDP高可用架构设计，考虑的因素确实很多，有更简单的吗？往下看：

2）通过应用主机来完成高可用，IBM在一些方案希望那些小型环境用户通过AIX逻辑卷管理工具(LVM)完成存储与存储之间的Mirrored，由于两套存储之间是Mirror，当一台存储设备故障，而第二台则可以接管。

VERITAS则是在应用主机彻底安装一个文件系统，允许添加更多的存储设备进行Mirror，或者包含了更多的功能。这两方面来看，应用主机在承载业务同时还充当一个软RAID的，这对主机性能影响会比CDP来的更沉重。

无论是CDP或者基于应用主机卷镜像，能够带来很多的思考，如果我们的容灾节点建立的两个数据中心，比如100km,业务是否会因此而造成隐患，尤其是面对巨大，且无法估算的延迟。其二，为什么不能把这些工作单纯的交给存储层来做，而应用主机主机专心的提供生产服务。

3）基于存储层的高可用性方案，目前一线存储厂商均能够提供此方案，依靠中，高端的存储产品。使用两台或多个存储节点集群，存储阵列所提供给应用主机的每一个共享卷会Mirroring到另外一套存储设备，应用主机不会感知镜像卷的不同，照常进行读写操作，很多时候依靠应用主机的MultiPath Software对镜像卷进行聚合与Failover工作，只是当一台存储节点故障，MultiPath Software会及时切换至另一健康路径，而这条路路径有可能指向另一台存储节点。存储节点之间可以部署在同一个机房，或者有限距离内的同城之间。一些高端的容灾存储已经扩展到了远程复制功能，允许再次把镜像卷复制到另一个地区来减小灾难影响。这类厂商和技术类似：IBM PPRC,HDS TrueCopy,EMC SRDF......。总之，整个数据同步周期完全脱离应用主机，完全由存储之间，及存储之间的高效链路来完成。

用于高可用的存储节点之间，如果支持负载均衡，那就再好不过。我们都知道，这与存储阵列的双控之间双活完全不是一个概念。在位于两个站点之间的独立的存储设备，在任意时间，完全允许应用程序写入数据，而不是一台Active，另一台等待Failover，这是实际意义上的双活，当与那些具备负载均衡高级集群程序配合，可发挥更大效益，如Oracle RAC，VMware vSphere等等。

基于存储层的高可用无疑是一个不错的选择，是否还有其它注意的？

首先，通常来说，客户必须购买两个或多个同厂商，同型号的设备，这是被绑定的，其次需要一笔昂贵的预算，因为这类方案的设备通常是中，高端的。再有就是目前已有的存储设备，无法再利旧，或与其相容性的工作等等；（这些问题也能够规避，我写在另一篇博文）详见存储虚拟化。

若干个容灾存储设备之间，为了保障及时Failover响应，节点之间数据任何时刻都会是一致的。OK，这也延伸出来第二个问题，如果位于主存储上面一个卷，遭受到网络***，病毒蠕虫，或者误操作呢？毋庸置疑，备援存储节点也会更改这些数据同步主存储上面的更改，这个问题必须引起关注。

因此，我们仍然需要借助快照进行辅助，当类似问题发生时，让我们的数据能够回退到上一个时间点。对于一些关键的业务及要求性比较高的IT组织，CDP技术将是一个不二的选择，在于其提供更密集的时间点，稍后聊CDP。

----------------------------------------------------------------------------
（二）Asynchronous Remote Replication_异步远程复制

之前讨论的高可用方案，很大程度的使我们业务连续性的需求得到满足，但是一些细节也很重要。比如采用实时镜像的2套设备，通常规定了一个有限的距离。这是因为2套实时镜像的设备之间的线路不仅仅是传统的心跳线，而是Mirroring Link's。线路里面往往跑的是信息数据，更远的距离意味着更大的延迟，所以我看到的厂商往往把距离限制在有限距离之内，例如200km。这也是为什么我们看到很多用户的同城容灾中心之间，没有太多超过100km的主要原因。

当一个地区，或城市发生灾难，意味着我们将失去所有的数据，哪怕是高可用方案也是荡然无存，所以客户希望能够再次创建副本，放置在一个更远的地区：另一个省市或国家。
此时我们需要使用Remote Replication方案来实现，通常使用Asynchronous Replication（异步复制）技术：较之前者，不会对数据采取回环的验证，对线路的要求当然就没有这么苛刻，并且能够把数据备份到一个理想的场所,关键在于主中心与灾备中心一般使用IP 网络进行数据的，所以消除的距离限制。

另外：之前有供应商提到，远程备份是为了提供灾难后数据能够最快的挂载。我自己不认可这种观点，并且对最终用户我也不会承诺。
1.如果真的了解Asynchronous这种技术，您就会明白，"不会对数据采取回环的验证"是它最大的硬伤，这也是我们为什么不直接使用远程复制，而刻意在本地使用高可用的主要原因。简单来说，很多情况下，远端的备份数据与本地的主/副本数据有可能是不一致的。在这种情况下，即使挂起远端的数据，也未必会有我们预想的结果。这种情况的产生可能是故障时，数据停留在缓冲区没有传过去，或者在IP网络里。

2.还有更现实的一点，不要更多的追求智能，挂在远程数据中心的备援卷给Standby应用主机。道理很简单，当需要启动远程灾备中心时，通常是本地数据不可用的状态，比如洪灾，火灾，地震。而此时远程数据则是唯一剩下的副本数据，由于上述介绍了远程复制的传输机制，灾难有可能会带来与源数据不一致，如果未作任何计划挂载远端的数据副本很有可能会造成写入错误，破坏仅剩的数据，最好借助快照或CDP更为安全。
-----------------------------------

（三）CDP_持续数据保护技术

快照功能是一个很古老的技术，但是并没有因为岁月流逝被运维人员舍弃，至少我个人还是比较青睐的。它能够在故障发生时，回滚到上一个时间点，减少了误删除，病毒，文件。但随之业务关键性，时间窗口成为无法忍受之痛。逻辑性损坏带来的损失。

在容灾上，无论是基于哪种技术的复制，或是基于Block的更新都不会进行数据可靠性的验证。
这里的可靠性我指的是，如果我们在一个源数据上误删除一个文件，那么同步的副本数据也会执行删除动作。所以我们需要一个用于回滚的机制，在因为数据逻辑错误而无法挂载时，返回上一个时间点。快照虽然可以提供上一个时间点的回滚，但是对于客户更高级别的要求，早某些情况可能会力不从心，比如快照无法提供一个密集的恢复时间，对一个大容量的卷。假如：做一个快照窗口需要1分钟，那么后面59秒的数据意味着丢失，对于大型数据库系统会有更大的损失。

CDP技术彻底的改变了传统数据回滚的方式，使用时间轴进行恢复，用户可以回拨到需要的一个时间点，不再有时间的备份窗口。弊端往往是损耗一部分空间进行I/O的log记录。如果把快照比作照相机，那么真正的CDP技术则无疑是持续录像机，我们可以更加密集回放和提取每一个帧的镜头。

在这个议题上至少有两点需要先声明：

1）较之前提到CDP，这个议题仅仅是用于对存储之间高可用的一个补充，而不是完全用于容灾。下图能够看出，数据实时同步和高可用部分，依靠的仍然是存储之间。也因此，在众多的CDP产品方案中，可以选择那些依靠存储层，完全脱离应用层的产品，也就说CDP执行周期对应用主机完全透明，更是无需在应用层安装代理软件，使用主机性能分拆IO等等。记住，完全独立。

2）CDP产品目前很多，但是这里讨论的是SNIA True CDP技术，而不是某些依赖于连续快照的准CDP。

在下图能够看到，防止存储系统意外宕机的——高可用部分仍然是依靠独立的，具备实时复制的节点进行作业（这些节点或许是某些同型号的高端存储，或许是位于存储前端的引擎，又或是内置存储虚拟化技术的网关）。而CDP仅仅是高可用部分的一个附加技术，只是当面临应用主机遇到如：软件升级过程bug(如，数据库)，病毒蠕虫，网络***，人为逻辑错误等等，之后才会进行数据状态时间点的回退。但凡发生存储意外停机，或者同城的某个site瘫痪CDP技术将不参与恢复作业，而是依靠高可用的核心部分实时复制，最终，这是一个完善而又无需争议的聪明做法。

------------------------

High Availability+Remote Replication +CDP

注：上述引用的“实时复制”技术SNIA标注是synchronous replication。大意是数据副本被实时的更新在额外节点。

-------------------------------------------------------The end........