在容灾的方案中,用户往往根据需求不同级别的安全标准，更有一部分最终用户，对安全及潜在的风险知之甚少，至少我遇到部分客户是这样的。
通常我比较中意与金融行业的客户讨论方案，我想这一态度会有很多同行与我达成共识，最主要因为他们通常走在技术最前沿，更快的尝试新技术(毕竟人家有钱嘛)，能够更好的找到方案的切入点，并且管理人员能够更专业的提出一些需求，通常这些需求他们已经认识到，在技术上已经可以解决。
如果我们不考虑客观因素，如何提供一个高安全级别的方案给用户 ？
分享下以往的方案，以及我对容灾安全方面的一些认识，在内容里我刻意省去一些宏观的理论，比如RPO，RTO，或投资回报率之类的，原因在于，我想更贴切的表达我想要表达的内容，而那些通常我只是在方案里面凑字数。
HA+Remote Replication +CDP
---至少我认为这是目前最佳的业务连续性方案
--------------------------------------
HA__高可用
对于高可用性的理解，集成商经常会通过不同的方式展现给用户，而无论如何展现，都是在尽最大力度包装其方案，使其更完美。导致一些潜在问题无法被客户重视，在今后的运行中，必须花更多时间修复这些“方案Bug”。SNIA权威的定义了高可用性的概念，而目前技术则能够做的更出色，我们升级这个概念为：
当主机意外停机时，业务能够无缝转为连续性，并且能够自动的同步增量数据，无需人工干预。
应用主机：
可以使用应用业务本身的集群功能，如AIX HACMP，Oracle RAC,当然VMware vSphere能做到更好，这样能够保障应用主机方面的高可用性。采用第三方集群软件可能要考虑到兼容性和监听参数，并且市场绝大部分的集群软件并不支持-负载均衡机制，仅仅做到应用主机之间的Failover,而这一点Oracle RAC和vSphere绝对会有优势。
存储层：
在高可用性的方案中，对存储设备提出了更高，更苛刻的要求，而不仅仅基于RAID磁盘的保护。我们希望应用主机集群之间的共享卷时刻响应服务。如果不能够做到这一点，主机已经部署的集群系统将会荡然无存，因此，存储层的高可用更为重要。
关于存储层的高可用性方案，我们有很多选择的余地，但是哪些是我们想要的？
基于存储层的CDP高可用性方案，目前仍然有广泛的市场，这些产品通常会在应用主机安装代理软件，分拆IO至CDP的设备，待主存储故障，由CDP设备进行指定时间点的回退。由此我们需要至少考虑4个问题：需要手动挂在备援卷时间通常是多久？对主机原有性能的影响，甚至说最初设计主机硬件平台时，我们需要把CDP所损耗的性能计算进去？与操作系统的兼容性？支持多少个主机集群？按照自身的经验来说，我认为这对主机性能是个不小的损耗，并且产生恶性的放大效应，尤其是CPU。当主机业务繁忙时，必定会产生更多的IO，此时主机需要更多的性能处理业务，而就在此时，CDP的代理软件同样提出了更高性能需求，因为有更多的IO要处理，看来EMC当初把分拆IO的工作交给SAN Switch确有优势。另外，分拆IO到CDP的设备是实时写入的吗？这一点很重要。如果是实时的，意味着CDP存储设备写入的性能至少要高于主存储，否则会降低原有的IOPS。如果不是实时写入的，意味著在应用主机会有Buffer，当主机意外停机后，会导致数据丢失，而丢失的程度却居于Buffer到底有多少东西。
通过以上来看，依靠CDP高可用架构设计，考虑的因素确实很多，有更简单的吗？往下看：
通过应用主机来完成存储的任务，IBM在一些方案希望用户通过AIX卷管理工具完成存储与存储之间的Mirrored，由于两套存储之间是Mirror，当一台存储设备故障，而第二台则可以接管。
VERITAS则是在应用主机彻底安装一个文件系统，允许添加更多的存储设备进行Mirror，或者包含了更多的功能。这两方面来看，应用主机在承载业务同时还充当一个软RAID的，这对主机性能影响会比CDP来的更沉重。
无论是CDP或者基于应用主机卷镜像，能够带来很多的思考，如果我们的容灾节点建立的两个数据中心，比如100km,业务是否会因此而造成隐患，尤其是面对巨大，且无法估算的延迟。其二，为什么不能把这些工作单纯的交给存储层来做，而应用主机主机专心的提供生产服务。
基于存储层的高可用性方案，目前一线存储厂商均能够提供此方案，位于中，高端的存储产品。使用两个或多个存储节点集群，存储阵列所提供给应用主机的每一个共享卷会进行Mirroring，对象则是另外一套存储设备，应用主机不会感知镜像卷的不同，照常进行读写操作，很多时候依靠应用主机的MultiPath Software对镜像卷进行聚合与Failover工作，只是当一台存储节点故障，MultiPath Software会及时切换至另一健康路径，而这条路路径有可能指向另一台存储节点。存储节点之间可以部署在同一个机房，或者有限距离内的同城之间。一些高端的容灾存储已经扩展到了远程复制功能，允许再次把镜像卷复制到另一个地区来减小灾难影响。
用于高可用的存储节点之间，如果支持负载均衡，那就再好不过。我们都知道，这与存储阵列的双控制器完全不同。在于存储设备之间，在任意时间，完全允许应用程序写入数据，而不是一台Acive另一台等待Failover，这是实际意义上的双活，能够完全迎合那些具备负载均衡的应用程序。
基于存储层的高可用无疑是一个不错的选择，是否还有需求注意的？
首先，通常来说，客户必须购买两个或多个同厂商，同型号的设备，这是被绑定的，其次需要一笔昂贵的预算，因为这类方案的设备通常是中，高端的。再有就是目前已有的存储设备，无法与其相容性的工作等等；（这些问题也能够规避，我写在另一篇博文）
若干个容灾存储设备之间，为了保障及时Failover响应，节点之间数据任何时刻都会是一致的。OK，这也延伸出来第二个问题，如果位于主存储上面一个卷，遭受到网络攻击，病毒蠕虫，或者误操作呢？毋庸置疑，备援存储节点也会更改这些数据同步主存储上面的更改，这个问题必须引起关注。
因此，我们仍然需要借助快照进行辅助，当类似问题发生时，让我们的数据能够回退到上一个时间点。对于一些关键的业务及要求性比较高的IT组织，CDP技术将是一个不二的选择，在于其提供更密集的时间点，稍后聊CDP。
---------------------------------------------------------------------------
Remote Replication_远程复制
之前讨论的高可用方案，很大程度的使我们业务连续性的需求得到满足，但是一些细节也很重要。比如采用实时镜像的2套设备，通常规定了一个有限的距离。这是因为2套实时镜像的设备之间的线路不仅仅是传统的心跳线，而是Mirroring Link's。线路里面往往跑的是信息数据，更远的距离意味着更大的延迟，所以我看到的厂商往往把距离限制在100km，这也是为什么我们看到很多用户的同城容灾中心之间，没有太多超过35km的主要原因。
当一个地区，或城市发生灾难，意味着我们将失去所有的数据，哪怕是高可用方案也是荡然无存，所以客户希望能够再次创建副本，放置在一个更远的地区：另一个省市或国家。
此时我们需要使用Remote Replication方案来实现，通常使用Asynchronous Replication（异步复制）技术：较之前者，不会对数据采取回环的验证，对线路的要求当然就没有这么苛刻，并且能够把数据备份到一个理想的场所,关键在于主中心与灾备中心一般使用IP 网络进行数据的，所以消除的距离限制。
另外：之前有供应商提到，远程备份是为了提供灾难后数据能够最快的挂载。我自己不认可这种观点，并且对最终用户我也不会承诺。
1.如果真的了解Asynchronous这种技术，您就会明白，"不会对数据采取回环的验证"是它最大的硬伤，这也是我们为什么不直接使用远程复制，而刻意在本地使用高可用的主要原因。简单来说，很多情况下，远端的备份数据与本地的主/副本数据有可能是不一致的。在这种情况下，即使挂起远端的数据，也未必会有我们预想的结果。这种情况的产生可能是故障时，数据停留在缓冲区没有传过去，或者在IP网络里。
2.还有更现实的一点，不要更多的追求智能，挂在远程数据中心的备援卷给Standby应用主机。道理很简单，当需要启动远程灾备中心时，通常是本地数据不可用的状态，比如洪灾，火灾，地震。而此时远程数据则是唯一剩下的副本数据，由于上述介绍了远程复制的传输机制，灾难有可能会带来与源数据不一致，如果未作任何计划挂载远端的数据副本很有可能会造成写入错误，破坏仅剩的数据，最好借助快照或CDP更为安全。
-----------------------------------
CDP_数据连续保护
快照功能是一个很古老的技术，但是并没有因为岁月流逝被运维人员舍弃，至少我个人还是比较青睐的。它能够在故障发生时，回滚到上一个时间点，减少了误删除，病毒，文件
逻辑性损坏带来的损失。
在容灾上，无论是基于哪种技术的复制，或是基于Block的更新都不会进行数据可靠性的验证。
这里的可靠性我指的是，如果我们在一个源数据上误删除一个文件，那么同步的副本数据也会执行删除动作。所以我们需要一个用于回滚的机制，在因为数据逻辑错误而无法挂载时，返回上一个时间点。快照虽然可以提供上一个时间点的回滚，但是对于客户更高级别的要求，早某些情况可能会力不从心，比如快照无法提供一个密集的恢复时间，对一个大容量的卷，做一个快照假如需要10秒，那么1分02秒05秒的数据意味着丢失，对于大型数据库系统会有更大的损失。
CDP技术彻底的改变了传统数据回滚的方式，使用时间轴进行恢复，用户可以回拨到需要的一个时间点，不再有时间的备份窗口。弊端往往是损耗一部分空间进行I/O的log记录。
