如何看待传统存储复制存在的8大痛点

灾备技术涉及的领域很多，有很多厂商提供了多种技术解决方案，当前比较常见的数据复制技术有几大类，例如基于传统存储的复制技术，技术数据库的复制技术，基于存储虚拟化网关的复制技术，基于主机卷管理的复制技术，基于备份的复制技术等等。

关于传统存储复制的痛点，大家主要关心如下几个方面：

1. 生产中心与同城灾备中心采用同步复制遇见的痛点

2. 存储复制中的复制链路上的痛点

3. 存储和主机密切相关的多路径软件的痛点

4. 基于存储复制技术的两地三中心解决方案的痛点

5. 双活数据中心中仲裁技术的痛点

6. 数据复制所带来的数据完整性，一致性的痛点

7. 数据复制的安全性的痛点

8. 灾难恢复演练中关心的问题

下面逐一加以分析和总结

[*本文主要观点来自多位社区专家及会员分享，由社区专家张鹏汇总、梳理]

一、生产中心与同城灾备中心采用同步复制遇见的痛点

[典型问题]

同步复制技术让生产和灾备中心的联系过于紧密，这样的技术风险点我们该如何规避?

[问题描述]

存储同步复制技术通常应用于生产和同城灾备中，同步技术将生产中心和同城中心的联系过于紧密，生产中心的数据变化会及时同步到同城中心.

就像2015年银监会发布的162号文件中提到的，某银行生产中心数据库文件的损坏导致生产中心的数据库故障，中断业务，由于该行同城灾备中心采用了存储级同步复制技术，数据库损坏文件被复制到灾备中心，导致灾备中心也无法恢复业务。

这种问题是不是技术上的必然风险点?厂商应该如何以此为鉴改进产品?用户应该采取何种措施规避这种风险?

[问题描述]

还有朋友提出这样的问题：

“能否这样理解：传统存储复制技术的致命弱点就是应用如何随生产变更而变更?”

[观点总结]

▶观点一：

关于这个问题，可以谈谈可追溯功能的灾备解决方案。不管存储复制采用同步还是异步复制技术，都只能体现当前或者某一个时间点的状态，不具备追溯功能的灾备解决方案，在应对逻辑错误或者上诉文件损坏的时候就显得力不从心。快照技术是一种解决方案。并且很多第三代存储都实现了不限数量，或不限频率的快照解决方案。我们迫切希望传统存储厂商在更多的高端存储解决方案中进行改进。

▶观点二：

可用多个存储复制版本解决 (消耗大量存储空间)，保存一天前或一个星期前的 版本，再次保存一个同步版本。

▶观点三：

存储级同步复制在生产端数据由于外部因素被损坏的时候，可能灾备端也难以幸免，因此可考虑进行应用级别的同步，同时增大备份频率，将数据丢失降至最小。

观点综述：

同步复制的技术原理决定了生产中心和采用同步复制的同城灾备中心的数据改变是一致的，在存储底层复制单元以上的错误，例如逻辑上的错误，同步复制会将错误一并复制到灾备中心，为此出现此类错误，是同步复制为之所痛的地方，如何防范呢，我们希望厂商能够采用多副本的机制例如频繁的快照技术提供可追溯的灾备解决方案，尽量减少发生此类故障时的损失。

二、存储复制中的复制链路上的痛点

[典型问题]

存储同步复制技术中，远距离光纤传输的延时、抖动等线路问题风险如何避免?

[问题描述]

存储同步复制技术通常应用于生产和同城灾备中，生产存储和同城灾备存储通常采用光纤通道SAN网络连接，其光纤线路距离通常为几十公里，长距离传输线路的不稳定因素，例如延时，抖动，都会给存储复制带来影响，有时甚至是灾难性的影响。

今天就来分析一下，存储同步复制由于光纤网络线路的问题出现的风险。

同步复制出现链路抖动，会影响到生产运行，那么异步复制出现链路抖动会不会影响生产运行呢?

同城灾备或异地灾备建设中，链路距离和网络延迟对于应用场景的考量如何?

在链路距离和延迟方面对于不同的场景要求也是不一样的，是否有具体案例可以针对性的数量一下这方面的问题，遇到问题时对应的解决方案又有那些?

网络抖动对于同城间基于存储的数据同步复制的影响有多大?如何减少网络抖动的概率?

同城间基于存储的数据同步复制方案受网络抖动尤其是频繁发生抖动的对源端主业务的影响程度有多大?要减少网络抖动发生的概率，在网络设计及规划时有什么需要注意的?

[观点总结]

▶观点一：

线路链路实施监控跟踪和运维服务商链路稳定性质量有关，相关线路链路应急预案和恢复手册，希望对你有帮助，谢谢!

▶观点二：

关于延时，一般没有办法，只能找运营商;

抖动问题给你两个建议：

1、实时监控SAN交换机级联链路端口(porterrshow)，一旦发现大量报错，立刻disable这个端口;保证生产端可用。

2、采用iprouter链路(博科交换机的7800),将不同厂商的链路进行绑定(目前在同步环境下的案例，但是异步情况下案例很多，按照原理应该可以解决抖动，而且目前IP的延时也很短了)

▶观点三：

同城或异地灾备或者双活链路抖动是不可避免的，主要考虑的是应用能够接受的程度。目前来说超过50KM距离的场景，应该不会有厂家拍着胸脯打包票的。

▶观点四：

主要还是看系统的RPO和RTO的要求，有些灾备数据是异步复制的，有些实时同步的，对不一样的系统采取的手段不一样，有些就是实时的传输，异地Standby，还有一些是拷贝一些备份数据到异地之后进行数据恢复，金融行业对于实时性要求较高。

▶观点五：

例如网络延迟较大时对证券行业有很大的影响，因为证券行业的特殊性要求数据传输实时性高

▶观点六：

实施前是要对运营商线路进行检测评估的。

▶观点七：

同城间距离及交易情况和RPO要求来评估链路类型和带宽。前期需进行光强度衰减和时延测试。

观点综述：

大家对复制技术中的链路环节还是尤为关注的，通过大家提出的问题，我们不难发现远距离传输的延时和抖动问题，一直是复制技术中的痛点。那么如何解决呢，看来大家更多寄希望于运营商是否能够提供高质量的线路。同时在运维过程中加强监控和应急防范。

三、存储和主机密切相关的多路径软件的痛点

[典型问题]

多个厂商的多路径软件装载在一台主机上的风险，以及多路径软件在存储双活架构中的风险怎么办?

[问题描述]

主机连接存储多路径的问题，这个问题很早开始就一直存在，主要是主机连接多个存储时，每个存储厂商有独立的多路径软件，主机上是否安装多个厂商的多路径软件，一直是用户困惑的;随着双活数据中心解决方案中存储双活的架构出现，主机多路径在灾备技术中也占据着重要地位。

今天主要来分析一下两个问题：

老问题：多个多路径软件装载在一台主机上带来的风险?

新问题：多路径软件在存储双活中的风险?

[观点总结]

▶观点一：

先谈谈老问题：多个多路径软件装载在一台主机上带来的风险?

我想在这个问题上好多实施人员都会遇见，多数的解决办法是为了避免相互扯皮，在一台主机上只装一种多路径软件。实际应用中，多个多路径软件在一台机器上运行，也是存在的。为了避免实施人员和客户的困惑，我们更多的是要呼吁，存储厂商尽量兼容 *** 作系统厂商发布的原生多路径软件。主机的问题让主机去解决，存储的问题让存储去解决。

▶观点二：

再谈谈新问题：多路径软件在存储双活中的风险?

现阶段存储双活架构中多路径软件扮演了重要的角色，多路径软件是否可靠，设置是否正确，是架构稳定性的关键。考验厂商和实施团队的时候到了，请大家关注长距离传输路径和本地路径是有区别的，多路径中路径的选择是要充分考虑这个问题，避免不必要的风险发生。

▶观点三：

有关一台主机上安装多种多路径软件的场景应当尽力避免，在源头就减少这种情况的发生。举个例子：使用powerpath的多路径软件，可以驱动sdd，sddpcm的产品的盘符变化，导致管理和使用上的一系列问题。

参考解决方案：

1. 可以考虑使用存储虚拟网关

2. 同一种应用尽量使用同品牌的存储，使用一种多路径软件进行管理。

▶观点四：

生产环境中 应避免 一个lpar使用多种存储 安装多个多路径软件问题

▶观点五：

多个多路径软件装载在一台主机上带来的风险?可能造成兼容性问题

▶观点六：

多路径软件在存储双活中的风险?只使用存储双活设备指定的多路径软件即可。

▶观点七：

先谈谈老问题：每一个厂商针对针对自家存储设备的多路级管理软件都会开发一些高级功能、监控功能和优化手段;比如说：路径不稳定时候，多路径管理软件就会监控一些参数指标，当某些指标达到一定数值，多路径软件就自动执行一些 *** 作保证生产和性能;不同厂商的 *** 作可能不同，因此可能产生一些故障;而且不好去解决。

▶观点八：

双活环境下多路径软件，对路径组合的监控以及监控参数更加多了;判断项也更多了，我也感觉到参数设置对架构稳定性至关重要。

观点综述：

主机端多路径兼容的问题一直是大家关注的问题，值得一提的是，更多的厂商已经通过支持 *** 作系统原生的多路径软件而解决兼容性的问题了，虽然原生多路径和厂商特有的多路径软件有一些功能上的差异和缺失，但是随着技术的革新，未来应该会有好的改变。存储双活解决方案中多路径软件起着重要的作用，希望大家在使用过程中得以重视，合理配置，强加监控，防范风险。

四、基于存储复制技术的两地三中心解决方案的痛点

[典型问题]

两地三中心的存储复制技术中，三角形复制架构，生产到异地的复制链路真的有用吗?

[观点总结]

▶观点一：

经常看到和听到的架构是这样的。理论上生产数据复制到异地的备份也会对数据有保障，但是架构越复杂，维护， *** 作起来也越复杂，往往这样的架构最后出问题的并不是数据复制链路本身。而是在生产系统故障的时候业务割接时候的其他问题。

举个简单的例子，刚刚做双机结构的时候。是微软win2000+sql2000的架构，做的过程是装好两台系统，配置双机结构，然后在主机上安装SQL,这样备机也同时安装上了sql2000，当主机挂掉，备机会自动接替主机工作，到这里位置一切都很理想，但是很快我们就放弃了这种结构，因为1，当主机故障，备机切换了以后。我无法在线把主机在添加到这个双机结构中，只能把整套双机环境全全部推了重来，2，两台机器不能同时启动，否则会因为争抢资源而导致双机结构崩溃。

现在的技术发展的自然比起零几年的时候要先进了许多，但同样会因为某些条件至于而导致这种理想的架构真的在出现故障的时候能理想的实现智能接管。所以双活也好。两地三中心也好。有成熟的容灾方案，做定期的容灾演练是保证系统架构运行的根本。，如同拿着倚天剑的人一定要是个武林高手。否则可能伤到的会是自己。

▶观点二：

这个问题很奇特，当然是由用的，没有建它做什么，关键看你为什么要建，目的是什么，建灾备的需求，响应级别。

如果说你是认为，本地双活完全能满足生产环境的高可用需求，那就要看是否能满足用户的业务和管理需求，有不少企业做灾备不是为了别的就是为了审计或等保的需要。

你有没有听说过某个IDC机房因失火，造成对外业务全部中断的情况，虽然可能，但基本没有发生过。那做了数据同步建了灾备机房是否就安全了，如果恰巧2个机房相聚数十公里却在同一个地震带上时会发生什么...............

这也就是开始说的，为啥要建灾备，目的、需求、预算要先搞清楚，才能设计建设有效的灾备环境。

▶观点三：

在灾备系统上见过这样的系统，但是业务生产上没有见过有客户这么花气力。

灾备系统是A--B---C，但C不复制到A，是一个不闭合的三角模型。即使是一个灾备三中心，也是相当花钱的。备份存储都是EMC DataDomain的高端产品，都是窄带复制传输，运行也没有问题。恢复验证也测试过，安全性确实有提高，但是三中心数据一致的滞后性还是很明显，基本都在3H左右，数据量大的时候滞后更多。可想而知，如果是业务上三中心互备，算上SAN网络、设备、存储，估计不是特大公司都不会采用了吧。

▶观点四：

还是有用的，当同城灾备中心的异地中心链路有问题的时候，异步数据将自动的通过生产中心到异地灾备中心链路进行数据传输

观点综述：

大家谈到了两地三中心灾备架构的重要性，其实这点我们都是认可的。大家可能没有理解这个问题的真正含义，这里主要想描述的是很多厂商和客户想要达到的三角形闭合的两地三中心架构，主要纠结在A和C 是否有必要连接。

在真实的灾难场景中，生产中心发生灾难，肯定是优先选择同城灾备中心的，因为同城灾备中心的综合配置多数都优于异地灾备中心。只有生产和同城都发生灾难，这种区域性灾难的发生才考虑异地灾备中心接管。所以我个人认为过多关注与A-C的闭环架构没有太多必要。

五、双活数据中心中仲裁技术的痛点

[典型问题]

Quorum/TIe-Breaker对于避免脑裂和场地分割有效吗?仲裁技术是否会给生产数据中心带来风险?

仲裁机制会不会同样带来对生产数据中心的风险?多数用户真的做到第三数据中心仲裁了吗?

[观点总结]

▶观点一：

仲裁机制还是有必要的。如果两个数据中心断开，至少仲裁服务器能在其中一边把应用拉起，避免脑裂。如果能有第三数据中心仲裁的话，那样最好。

▶观点二：

跨数据中心的存储集群技术，必须要有仲裁机制作为保障，希望厂商在这方面加强技术改进，不要让原本作为防范机制成为风险的隐患。

观点综述：

关于防范脑裂的仲裁问题不仅仅是在存储双活解决方案，虚拟化存储双活解决方案中用到，在主机HA的方案中更为广泛的应用。脑裂一直是集群技术中的痛点，为了避免脑裂的发生，厂商想出了多种办法，其中包括仲裁机制。在这里引出这个痛点主要是想提醒更多的用户慎重看待每一个风险点，仲裁也许是解决脑裂的一个好办法，但是它也许也隐藏着其他隐患。如何防范，需要加强运维和应急处置。

六、数据复制所带来的数据完整性，一致性的痛点

[典型问题]

通过存储复制技术，在手工暂停存储复制后，灾备端数据库仍然有一定几率拉不起来。存储复制的目标端如何保证数据库能够拉起来?

同步复制和异步复制是否成功，如何验证?有哪些方法?

[观点总结]

▶观点一：

一般情况下，只要你能保证所有卷组的设置了一致性情况是能保证的。如果还是不行，你可以写一个脚本，先将oracle处于backup状态，立刻停止复制(只对同步有用);再将oracle数据库处于正常状态。

▶观点二：

只遇到过同步复制,2边数据不一致的问题

▶观点三：

复制是否成功，主要看存储管理界面显示的状态，是否有复制中断，但是不能确保数据完整和一致性。

观点综述：

归结起来还是灾备数据和源数据一致性完整性的问题，看来大家在实际环境中确实遇见过灾备数据不可用的情况，这的确是数据复制中最大的痛。虽然存储层面可以通过设备状态，日志等方式监控复制的完成情况，但是无法从业务数据层面来做数据的检查。需要通过工具或管理方法定期从业务数据层面来做检查。来验证灾备数据一定与生产数据一致性，防范真正灾难发生了，灾备数据不可用的风险。

七、数据复制的安全性的痛点

[典型问题]

如何保证存储复制技术中，数据传输的安全性和可靠性?存储加密技术给数据传输带来的影响有多大?

[问题描述]

数据传输的安全一直是监管机构的关注点，存储复制就涉及到数据传输，那么如何保证安全不被篡改和非法获取呢?是加密技术吗?

那么问题来了：目前厂商的产品中是否都具备加密技术?这些加密真的可靠吗?加密给效率带来的影响是否很大?有用户真正在使用吗?

关于加密，这里想谈一个问题，数据传输时是否需要增加加密功能，开启加密功能对复制的影响有多大?

[观点总结]

▶观点一：

存储级别的复制都会自带校验和加密，校验能保证收发数据一致，加密能保证数据安全。存储上的数据本来也不是明文而是数据块，因此再加密后，数据一般很难破解。倒是存储换下来的坏盘，如果重要，建议购买留盘服务。现在采用存储级别的复制的客户也很多了，实施顺利的，现在也少有听到故障重重的案例。

▶观点二：

加密解密这种对数据的附加 *** 作，是否会对数据完整性有影响。其实这个问题和数据传输是否压缩，是否去重类似。加解密，压缩，去重，这些对数据的 *** 作，正常情况下是对数据完整性无影响的，当然也存在异常的因素。数据远距离传输不管是否经过加密，压缩，去重等加工 *** 作，数据的完整性都存在异常的可能。那么我们所关注是否有一种机制，可以定期去检查复制两端的数据一致性。

▶观点三：

网络层面考虑使用安全性较高的专线线路，可保证传输安全。

观点综述：

首先安全是任何时候都必须关注的。安全分为数据完整性，数据可靠性，数据防篡改性等等。灾备是为了防范数据丢失的安全风险，同时也要综合考虑数据的安全性。所采用的安全手段应该是对数据安全有利的，而不会反而成为风险隐患或性能隐患。

八、灾难恢复演练中关心的问题

[典型问题]

上了灾备后，怎么进行演练?

多长时间进行一次灾备演练?

切换后对数据是否异常有什么好的方法进行验证码?

演练中你曾经跳进过哪些坑?

[观点总结]

▶观点一：

主要是手工切换，一年一次或者两次。

▶观点二：

演练是必须的过程，一年一次是必要的。每次演练都可能能发现之前的手册的不完善，并加以补充完善。还有演练需要有实绩业务支持才能验证其有效性。灾难时的应急预案要实现准备好，应急流出要梳理清楚。系统相关业务、技术人员的应急手顺书都要有，并且经过培训和模拟测试。灾备系统演练时需要退避生产系统，网络、存储、主机从灾备端开启后，模拟生产环境进行测试，网络外部接口全部封闭，避免不正常的业务数据通过接口流出，造成其他在线系统的异常。演练过后能铲掉灾备环境的数据，恢复生产环境的网络存储主机。

▶观点三：

模拟演练，一般一年要做一次，可以安排在业务非高峰时段，证券行业比较特殊，一般每年会有那么两次演练。

▶观点四：

灾备演练每年至少演练一次，演练类型可以是模拟演练、实战演练、部分演练和全面演练。大多企业采用模拟演练。

▶观点五：

厂家提供的灾备方案通常只能提供底层的存储接管和应用的启停。真正实施的时候一定要熟练掌握本地应用系统的技术人员协同实施。我碰到过厂家实施灾备系统后(WAS+DB2) *** 作系统切换，WAS应用确实在备机上自动启动起来了，但是因为实施时应用程序包没有放到共享存储中，两台机器本地存储各放了一份。导致新的WAS运行的程序包是最老的版本，导致切换失败。

▶观点六：

版本不一致这个也是一个问题

▶观点七：

做好数据同步，确保容灾端的数据和应用都是最新的，配置文件也不能错

▶观点八：

切换后注意对关联系统的影响，注意IP地址，确认业务运行在哪一端了。(网络策略很重要)演练尽可能减少对生产的影响。