基于存储容灾安全性置疑

anycall2010

原帖由 五“宅”一生 于 2008-12-16 21:50 发表
LS当时就应该掏出电话给piner来一个。哈哈

piner那本书，我已经研究过了。我觉得PINER写得也比较模糊。我在MSN上跟他提过这个问题，他没有回答。我猜测，他也只是见过，或者听别人讲过。测试就不好说了。

anycall2010

原帖由 ruluo 于 2008-12-16 14:01 发表
我做过，就没有发现起不来的情况，:-)

DA1放在主站点，DA2放在备站点，每个上面都有一个大小相同的卷，主站点DA1上的卷暂时叫做在线卷，备用站点DA2上的卷成为镜像卷。数据通过光纤网络从DA1上的在线卷复制到DA2上的镜像卷，定时对镜像卷做快照，通过快照验证数据库是否能够正常打开。如果DA1坏掉，可以从DA2上的最近的可用快照就可以打开数据库。

楼上说的，怎么很象基于第三方软件的容灾技术？我见过有客户使用VERTIAS的VVR这样做过。请明示！

anycall2010

原帖由 blue_prince 于 2008-12-16 17:16 发表


我们不是用DMX的容灾，用DATA GUARD来做容灾

大哥，我在家测试过DG容灾，DG容灾实时性不好啊。你们如何规避？我在PINER的书上也看过，可是他也没有提出什么好的规避方法啊？

anycall2010

原帖由 mustapha 于 2008-12-16 19:20 发表



晕，看来被EMC的sales给忽悠了，他过来给我们说，淘宝原来用dg做容灾，现在机器太多，管不过来，现在他们买了我们的dmx存储，用存储的容灾，管理方便多了，不信你可以去问piner  。  我晕，sales说的真的似的，又是个大忽悠

靠，SALES的话，你都信？我算一个比较实在的SALES，有时候，我觉得自己都是昧着良心说话。

anycall2010

原帖由 awk_____ 于 2008-12-16 21:56 发表
EMC这方面的成功案例很多，但是存储容灾还是有很多局限性的，特别是价格还很贵，一般都要20W打底。
我虽然是做EMC存储的，但是在orcale的容灾上我还是建议使用DG比较好，现在DG的配置也很方便又免费，为什么不用呢?

还是那句话，很多用户不会管理，而且DG的实时性不高。我也知道，存储容灾的实施费用和本身的LIENSE比较贵，但是毕竟管理比较简单，而且更主要不耗费主机性能。如果楼上有成功案例，不妨评估一下，基于存储容灾的安全性，可靠性究竟如何？

[ 本帖最后由 anycall2010 于 2008-12-16 23:56 编辑 ]

anycall2010

原帖由 anycall2010 于 2008-12-16 23:48 发表


靠，SALES的话，你都信？我算一个比较实在的SALES，有时候，我觉得自己都是昧着良心说话。

你要相信SALES，非把年过差不可！忽悠你的那个SALES哥们知道PINER近段在闭关练功，不打理任何人，所以他才说让你问PINER。

vecentli

业界流行的方式，比如EMC 的mirrorview，ibm的evm。

主机下发给存储的写io，到存储后，先写入primary的阵列，然后再写入到secondary的阵列，
最后反馈给主机，表示一个写io的完成。

这种方式的容灾，两个阵列的数据是完全一致的。

原帖由 novenbersky 于 2008-12-15 08:27 发表
据说高端存储的同步复制能进行每次写入的同步确认，并且IO队列也进行了序列化编号的，也就是采取类似DG的最大保护模式的方式，虽然影响性能，但是保证实时同步。

vecentli

snapshot不是拿来做容灾的，是用来做测试的。

原帖由 awk_____ 于 2008-12-15 12:49 发表
就拿EMC的存储来说吧snapview，快照就是一个时间点的一个拷贝。其中还分两种clone和snapshot。
在容灾的环境更多的是snapshot
snapshot的基本原理其实网上也有很多介绍。你可以认为它就是一个照相机，一个快照就是拍下了某个时刻LUN的数据状态。

vecentli

就EMC的snapshot来说吧。
一个快照就相当于在内存中产生一个bitmap，一个位对应一个extent，一个extent对应多个block。

如果由写io影响该lun上的一个extent，则sp会把该extent复制一份到reserved lun中，并在bitmap里做更新，以后测试机mount该快照的时候，相应block的查找会自动转到reserved lun里面。

原帖由 novenbersky 于 2008-12-15 12:28 发表


能否解释一下这个快照的基本原理？

vecentli

我觉得存在起不来的可能，比如redolog放在fs上面。
有一些更改可能还在fs的cache里面，如果此时生产端发生故障，则有可能导致数据库不一致。

原帖由 wolfop 于 2008-12-15 15:06 发表
10次有8次起不来，夸张了，就算异步复制，10次有一次起不来都不到。
何况很多容灾都是先做同步复制，再异步复制到更远的距离。
当然，究竟能否起来，不是那么简单，万一真是站点故障，你怎么保证生产端的CPU、内存没傻掉，把active redolog写坏了。所以一般会再弄多一份BCV/FLASHCOPY/SHADOWIMAGE之类的东西。