讨论：DR讨论

xiaomao2008

global mirror真的是乱序的吗?我觉得这个是一个很好的思路或想法,但我有点怀疑,show一下相关的文档给大家吧
现在我对global mirror为什么要最后做一下flashcopy比较好奇,是你说的乱序,还是其他原因

ericlee_sz

现在依然卖得这么火，是因为厂家为了销售额继续欺骗用户。。盘阵级容灾的弱点太多了

1)投资巨大。。。两边需要对等盘阵，一般需要裸光纤保证数据传输。。。有所谓的异步方式。但我
不知道他们的数据一致性是怎么保证的

2）对生产系统性能影响巨大。。。这点我知道很多用过的人都比较痛苦吧。。只要客户不知道就行

3）浪费巨大带宽。。。一般需要全裸光纤。。对带宽资源的浪费也是非常巨大的。。。而真正的
rpo能到多少。。。也不好说。。。要根据数据的压力

4）灾备系统是“死”的系统。。不能提取快照来做容灾演练，不能做QA,开发。。等等。。更加
浪费投资

5）对容灾的容量和带宽以及压力无法评估。。。听天由命。

6）数据不能回滚。。当真正灾难发生，容灾系统到底能不能起来还未可知。。


所以。。盘阵级容灾一碰到CDP容灾多半会死。。因为差距太过明显

难飞之猪

原帖由 ericlee_sz 于 2009-6-16 15:17 发表
现在依然卖得这么火，是因为厂家为了销售额继续欺骗用户。。盘阵级容灾的弱点太多了

1)投资巨大。。。两边需要对等盘阵，一般需要裸光纤保证数据传输。。。有所谓的异步方式。但我
不知道他们的数据一致性是 ...

真是非常崇拜阁下。
您这一番话将导致一场IT界的变革，什么《信息系统灾难恢复规范》，什么《银行业信息系统灾难恢复管理规范》都不对，都得按照您的这个理论改去

jgtvisionnex

我可以找到的一些IBM的资料！但是感觉没说啥！

DS8000 copy service 特性 (metro mirror,global mirror , 3-site mirror等）

DS8000 提供非常强大的copy service 功能。DS8000 提供三种典型的数据灾难复制方案。Metro Mirror，Global Mirror, Metro Global Mirror等。
Metro Mirror 是同步数据复制方案，始终保持本地数据和异地数据是一致的。每一次IO都需要在异地的DS8000 上先完成，本地的IO才能完成。这种数据复制功能对本地DS8000的IO性能有影响，根据距离的增加影响会越来越大。理论上，最大支持300 公里的Metro Mirror方案。
Global Mirror 是异步复制方案，本地数据和异地数据不是实时同步的，本地IO的完成跟异地IO没有关系。一般的情况下，异地数据总是和本地数据有着一定的差别（异地的数据没有本地的数据新，差着时间点）。基本上，Global Mirror 对本地DS8000 的IO 性能没有影响。理论上，Global Mirror 不受距离限制。
Metro Global Mirror 是一个三点数据灾备方案，典型的是，同城做一个Metro Mirror的方案，然后在异地配置一个Global Mirror的方案。小范围内的灾难，在同城进行恢复（恢复速度快，数据几乎没有丢失），如果是大范围的灾难，在异地进行恢复（恢复速度慢，丢失一部分的数据）。这是一个完全的数据灾难方案，适用于多种灾难情况，而且能根据具体的情况，三点数据灾难方案可以做相应的调整。

笑看风云_淡

原帖由 难飞之猪 于 2009-6-16 18:15 发表

真是非常崇拜阁下。
您这一番话将导致一场IT界的变革，什么《信息系统灾难恢复规范》，什么《银行业信息系统灾难恢复管理规范》都不对，都得按照您的这个理论改去

看到2点：1：南非蜘蛛的FANS，
2：做银行业的

笑看风云_淡

原帖由 jgtvisionnex 于 2009-6-17 13:44 发表
我可以找到的一些IBM的资料！但是感觉没说啥！

DS8000 copy service 特性 (metro mirror,global mirror , 3-site mirror等）

DS8000 提供非常强大的copy service 功能。DS8000 提供三种典型的数据灾难复制 ...

看来你连18摸的容灾白皮书都没看过

bcheckrc

原帖由 ericlee_sz 于 2009-6-16 15:17 发表
现在依然卖得这么火，是因为厂家为了销售额继续欺骗用户。。盘阵级容灾的弱点太多了

首先同情一下那么多可怜的用户，被忽悠的投入了大量的时间金钱人力物力，到头来只不过得到了一个弱点多多的产品方案...

1)投资巨大。。。两边需要对等盘阵，一般需要裸光纤保证数据传输。。。有所谓的异步方式。但我不知道他们的数据一致性是怎么保证的

需要对等盘阵，投资巨大，这个是事实。但是有其他什么方案能让灾备这端的盘阵用较低端的设备就能胜任吗？要知道，一旦发生灾难，之后生产中心的重建往往需要花费数个月以上的时间，而这段时间里，所有受灾备保护的应用全部是运行在灾备中心的盘阵上，压力不可能很小。打个比方，一家十几口原来住在一套别墅里，地震震塌了以后搬进了一间两室一厅里要凑合上半年，可能吗？起码要弄套复式以上的吧。异步方式的一致性怎么保证，你不知道，我也不知道，厂家估计也不会舍得把核心算法公布出来。厂家怎么宣称怎么保证那是虚的用来忽悠的我们不提也罢，但是至少我做过的盘阵级容灾里平时的测试和几次容灾演练时，数据的一致性都是可靠的，可能是我的运气一直不错吧

2）对生产系统性能影响巨大。。。这点我知道很多用过的人都比较痛苦吧。。只要客户不知道就行

对生产系统性能有影响，没错，但是未必是巨大，因为其中受到不少因素的影响和制约的，比如传输链路的带宽不理想或者是出现问题时，同步方式可能会造成应用的超时，异步方式会造成cache的大量占用。我对大部分厂商的复制技术不了解，但是我遇到的使用HDS Journal方式的UR时，对生产系统的性能影响已经小了很多了

3）浪费巨大带宽。。。一般需要全裸光纤。。对带宽资源的浪费也是非常巨大的。。。而真正的rpo能到多少。。。也不好说。。。要根据数据的压力

带宽的浪费，这个不能这么说，选多少带宽应该是量体裁衣的过程而不是越大越好。距离近做同步，那么可能就需要多根光纤来直拉，距离远做异步或者Journal，那么可能租用相对带宽小一点、几百m的线路就行，这个本来就要根据rto/rpo的要求来定。真正的rpo能到多少，和多方面的因素挂钩，真要知道那需要实测，演练一次应该就能搞定

4）灾备系统是“死”的系统。。不能提取快照来做容灾演练，不能做QA,开发。。等等。。更加浪费投资

这是死穴，确实是致命伤，资源闲置很厉害。不过灾备系统做容灾演练还是有的，我遇到几个客户都是直接用灾备设备来做的，根本不用快照什么的，胆子比较大啊，还好演练时都没发生过灾难，否则……

5）对容灾的容量和带宽以及压力无法评估。。。听天由命。

听天由命的说法有点过了，所有的数据指标在实施的时候都是要测试的，即使不能做到100%的准确，也不会误差到听天由命的地步吧

6）数据不能回滚。。当真正灾难发生，容灾系统到底能不能起来还未可知。。

真正灾难发生时，容灾系统到底能不能起来取决于很多因素，比如人员、制度、架构等等，容灾技术也只是其中的一环。当其他因素出现问题时，不管容灾技术是选用的盘阵级的还是其他类型的，结果都一样。我经历过的几次演练，由于其他因素都已经事先做好充分的准备，因此灾备系统都是正常起来的。至于真正的灾难发生时能不能正常起灾备，我持保留态度

所以。。盘阵级容灾一碰到CDP容灾多半会死。。因为差距太过明显

不懂CDP，因此不便发声。这位朋友看样子是各种高手，能否具体介绍一下其优势，让大家来学习学习，也能让盘阵级容灾死的其所，死有瞑目了

ericlee_sz

楼上的哥们。。可谓个中高手。。。发言也非常中肯


但坦白说对生产系统性能影响是非常重要的。。普通来说可能就看看平时运行情况。。客户。一般没考虑到峰值情况。。客户也没考虑过链路出现故障的情况。。。特别是没断。。但速度严重降下来。。也就是延迟严重降低下来。。。这种情况用同步方案往往很要命的

我这里王婆卖瓜自夸下自己的产品：

        生产系统性能不受容灾系统冲击。生产系统可支持无agent生产系统作为客户的关键业务系统。如果我们要实施的容灾系统将会影响到生产系统的性能以及系统可靠性，那将给客户带来灾难性的后果。容灾系统正常运行后对生产系统的性能影响应近似为0。并且为不影响生产系统正常运行，应尽量不安装任何agent在生产系统

        容灾系统任何故障不影响生产系统
容灾系统出现任何故障都不应该影响生产系统性能以及正常使用造成影响。包括本地CDP盘阵，容灾系统盘阵列，光纤，以及WAN等等。

        容灾系统安装与使用简单方便。客户的容灾系统安装与使用应以简单，方便为原则。系统结构过于复杂将会影响这个系统的性能和可靠性，并且会增加客户IT运营和管理成本。争取在5分钟到10分钟就可以完成 对整个系统的安装。

        支持应用分级式容灾。在我们的生产系统中有大量的不是特别重要的生产系统，同时又会产生大量写I/O 数据。我们可以在关键系统业务繁忙时，停止其送数据过程，为生产系统预留生产系统资源和带宽资源例如，邮件系统我们可以让其每天晚上送更新数据，文件系统可以调度成每周末送更新数据等等。。

        在带宽允许条件下，应该实现同步复制,,及实时的将数据传送到容灾端.支持同步/异步自动切换
实时传送的核心要求,就是需要将整套系统的RPO降到近似0,支持将个系统的RPO降到15秒以内,当生产系统发生鼓障,容灾系统在半分钟以内接替生产系统工作.
        支持双活系统,即容灾端应可以用作准生产系统.

传统盘阵级容灾不能使用容灾系统,容灾系统只作为生产系统的备份..我们本地的要求是容灾系统可以做报表,做开发,做测试..也就是说..容灾系统可以做为一个准生产系统使用.

        True CDP支持生成任意时间点快照容灾系统应支持可生成任意时间点毫秒级快照..容灾系统应有能力抓取生产系统每个写I/O...并将此I/O以同步/或异步的方式送到容灾系统中。。其中必须有机制保证数据的一致性。

        支持带宽管理,容灾智能评估系统.
客户在容灾系统设计分析的时候最头痛的问题，就是WAN带宽到底需要多大？生产系统的峰值I/O是多少。或者在指定RPO情况下，我需要多大WAN带宽：或者在指定带宽情况下，我的系统能达到多大RPO..


客户往往需要根据自己身情况，可能需要将生产中心的数据实时复制到一个容灾中心去,这样可能存在多个应用争用同一个带宽的问题,因此在本系统中必须要支持WAN带宽管理功能,为不同的应用定制不同的带宽.另外还必须支持智能评估系统.可对我们生产系统的数据,生产数据增量,带宽进行智能的评估。

wolfop

原帖由 ericlee_sz 于 2009-6-16 15:17 发表
现在依然卖得这么火，是因为厂家为了销售额继续欺骗用户。。盘阵级容灾的弱点太多了

1)投资巨大。。。两边需要对等盘阵，一般需要裸光纤保证数据传输。。。有所谓的异步方式。但我
不知道他们的数据一致性是 ...

我狂笑三声，你卖CDP也别枪的那么明显。另外对于基于盘阵容灾的原理、优劣、能实现什么都没弄清楚就攻击，你这样只会影响别人对CDP的看法。哈哈哈。

wolfop

现在依然卖得这么火，是因为厂家为了销售额继续欺骗用户。。盘阵级容灾的弱点太多了

1)投资巨大。。。两边需要对等盘阵，一般需要裸光纤保证数据传输。。。有所谓的异步方式。但我
不知道他们的数据一致性是怎么保证的
不知道你乱说什么，自己去仔细研究研究EMC SRCF/A, IBM的PPRC/X，HDS/HP的true copy，看看他们的实现方式在喷不迟。你当所有的用盘阵容灾的是傻子？

2）对生产系统性能影响巨大。。。这点我知道很多用过的人都比较痛苦吧。。只要客户不知道就行
哈哈哈，再狂笑。那么多用的还没听说谁抱怨，只要前期准备工作认真做了，真的做到了按照IO准备线路。我本人试过通过40M的IP网络做异步的盘阵数据复制，从头到尾客户就没抱怨过性能。

3）浪费巨大带宽。。。一般需要全裸光纤。。对带宽资源的浪费也是非常巨大的。。。而真正的rpo能到多少。。。也不好说。。。要根据数据的压力
DWDM听所过么？没听说过？回去补课。

4）灾备系统是“死”的系统。。不能提取快照来做容灾演练，不能做QA,开发。。等等。。更加
浪费投资
再狂笑，盘阵能做远程复制，本地就不能再做一个快照了？

5）对容灾的容量和带宽以及压力无法评估。。。听天由命。
无法评估？那是你自己水平不够。

6）数据不能回滚。。当真正灾难发生，容灾系统到底能不能起来还未可知。。
不能回滚？大概也就让你设计基于盘阵的容灾会设计出这样一个结果。

所以。。盘阵级容灾一碰到CDP容灾多半会死。。因为差距太过明显
这个更可笑，还没没见到那个关键生产系统用CDP的。CDP本质只是一个概念炒作。