基于存储容灾安全性置疑

vecentli

我不了解卷一级的复制方案。

但远程容灾较多的解决方案cdp（Continuous Data Protection），比如EMC的recoverpoint是基于io的，
只要多个lun之间配置了cg，我们还没发现db不能打开的情况。

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

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

vecentli

存储容灾不耗费主机性能，但耗费存储性能啊，而目前硬件的瓶颈更多的是出现在存储上。
存储容灾的好处就是管理简单。

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

blue_prince

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



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

SALES叫啥名字？也有可能SALES把淘宝和支付宝给搞混了，支付宝那边部分用了存储的容灾哈。

blue_prince

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

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

DG的话怎么说呢，主要是怕丢联机日志部分的内容吧。呵呵，假如说主库和备库放在30KM内的同城异地机房，那么拉个祼光纤把两个机房对应的光纤交换机打通。这样把STANDBY的存储划一个VG出来，这个VG用来做主库的另外一组日志成员，这样联机日志就在两个机房的存储上都有了。这样假如主库机房全部断电了，备库可以把这个VG MOUNT上去，然后进行恢复再打开提供服务，可以做到不丢失数据。

vecentli

如果有裸光纤，用最大可用性模式就好了，何必多此一举啊。

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

DG的话怎么说呢，主要是怕丢联机日志部分的内容吧。呵呵，假如说主库和备库放在30KM内的同城异地机房，那么拉个祼光纤把两个机房对应的光纤交换机打通。这样把STANDBY的存储划一个VG出来，这个VG用来做主库的另外一组日志成员，这样联机日志就在两个机房的存储上都有了。这样假如主库机房全部断电了，备库可以把这个VG MOUNT上去，然后进行恢复再打开提供服务，可以做到不丢失数据。

[ 本帖最后由 vecentli 于 2008-12-17 14:12 编辑 ]

anycall2010

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


SALES叫啥名字？也有可能SALES把淘宝和支付宝给搞混了，支付宝那边部分用了存储的容灾哈。

他要把淘宝和支付宝搞混，他不会把PINER也搞到支付宝吧？

blue_prince

原帖由 vecentli 于 2008-12-17 14:10 发表
如果有裸光纤，用最大可用性模式就好了，何必多此一举啊。

一个是存储级别，DG的话则是网络级别，最大可用实际使用效果还值得怀疑。

anycall2010

原帖由 vecentli 于 2008-12-17 14:10 发表
如果有裸光纤，用最大可用性模式就好了，何必多此一举啊。

楼上没看懂巴乔的意思，为了保证联机日志放到异地，所以才拉裸光纤。

vecentli

其实都是oracle层面的。
   
一个就是redo logfile的mirror。
最大可用性也是oracle管理的。
            
如果有裸光纤，选择的余地就大拉。。

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

一个是存储级别，DG的话则是网络级别，最大可用实际使用效果还值得怀疑。

ruluo

用盘阵自带的卷拷贝软件来做的, 不是第三方的。

我做过的这个也是基于存储层的。相关存储厂商都有此类技术：

EMC: SRDF（Symmetrix Remote Data Facility）
IBM: PPRC （Peer-to-Peer Remote Copy）
HITACHI: TrueCopy/Nanocpy
LSI: RVM（Remote Volume Mirror）
Netapp: SnapMirror