47 12345
发新话题
打印

EMC牛人来看看mirrorview

EMC牛人来看看mirrorview

有个fracture log和write intent log,看得我头大,上来向大牛求助:
我只知道,当secondary不可达时两个log都记录了Primary LUN的改变信息,以便secondary恢复时不用重新做一次全同步,而只要把log中记录的内容同步过去就OK了。
1、是不是只要使用了mirrorview,fracture log就是打开的一个选项,而write intent log是一个可选的选项?
2、当write intent log激活时,fracture log就被永久储存,对吗?
3、write intent log激活后会影响一定性能
1  write intent log 是可选的选项
2  fracture log存储在SP 的memory里面,  write intent log 是作为 private WIL LUN保存的
3  frature log 的使用需要性能优化工作
1.是的
2.不对
3.YES
引用:
原帖由 rais 于 2008-8-27 08:27 发表
1.是的
2.不对
3.YES
Fracture log is persistent if the write intent log is enabled for the Primary LUN 。
我看到这么一句话,不知该怎么理解?能帮忙解释下么?
请看附件中mirrorview/A的流程图,有几个问题请教:
1、“黄金拷贝”的创建是通过什么来触发的?创建的容量为多大?
2、增量集的大小?增量集的传输有何规则没?是否当增量集到某个大小时,触发它往secondary同步?这个大小应该是可以设定的对吧,最小可以到对少?因为这直接关系到RPO。
3、当secondary不可达时,primary LUN有个fracture log或者write intent log跟踪primary LUN的改变信息,并将其保存在相应的log中。
write intent log是128M大小对吗?这个是可调的吗?是只有一个,还是可以有多个?

附件

mirrorview.JPG (34.96 KB)

2008-8-27 09:44

mirrorview.JPG

先来分析一下两个LOG的具体用途。

The fracture log is only in SP memory and its size is not user-configurable. The maximum size of the log is 32 KB per secondary image. Bits represent variable-sized extents (contiguous blocks) depending on the size of the LUN. When MirrorView synchronizes from the fracture log, data is read and transferred 64 KB at a time. (Multiple I/Os can be read to synchronize each extent.)

The formula is as follows:

If LUN Size >= 32 GB
FL = 32 KB
Else
FL (in KB) = ( LUN Size (in KB) / 128 KB (min FL Extent) ) / 8 (bits/byte)


The fracture log is a bit map on each SP memory that is used during a failure of the secondary array. This log indicates which portion of the primary images might differ from the secondary image(s). The fracture log is used when the primary image cannot reach its secondary image. Broken cables between two arrays can cause this or a failure of the SP on the secondary array. An administrator might purposefully cause a fracture by stopping the mirror. If a secondary image is unreachable, MirrorView marks the secondary image as "fractured" and records the writes on primary image in a fracture log. The fracture log tracks regions as they change on the primary image for as long as the secondary image is unreachable. When the secondary LUN return to service, the secondary image must be synchronized with the primary by using data in fracture log. This is a partial synchronization, resulting in substantial time savings.

[ 本帖最后由 ender 于 2008-8-27 10:23 编辑 ]
The write intent logs hold pointers to writes that have not yet been made to the secondary mirror image. It is a recovery mechanism in case the primary storage system fails. By default it is set to 128MB.The write intent log requires a minimum 128 MB of private disk space for each SP in the array. Navisphere CLI lets you designate the size of the LUN for write intent log above the 128 MB.However, there does not appear to be any advantage to increasing the size of the write intent above the minimum size required.
目的也很简单,就是在简单故障的情况下,待故障解决后能快速把增量数据发送到DR端的存储上。

不过默认才128M,对于一个生产系统来说这个LOG实在太小。也许像NETAPP那样搞个NVRAM比较爽一点,哈哈。
引用:
原帖由 lzj09022351 于 2008-8-27 09:44 发表
请看附件中mirrorview/A的流程图,有几个问题请教:
1、“黄金拷贝”的创建是通过什么来触发的?创建的容量为多大?
2、增量集的大小?增量集的传输有何规则没?是否当增量集到某个大小时,触发它往secondary同步? ...
MIRRORVIEW/A  我没看到过成功案例的文档,据说有。不了解,也没有机会去做。
引用:
原帖由 ender 于 2008-8-27 10:33 发表
目的也很简单,就是在简单故障的情况下,待故障解决后能快速把增量数据发送到DR端的存储上。

不过默认才128M,对于一个生产系统来说这个LOG实在太小。也许像NETAPP那样搞个NVRAM比较爽一点,哈哈。
首先感谢ender给我贴那些E文原理,我有这个文档 ,只是看到后来还是有些疑问,所以想请你帮忙解释一下我上述疑问。
我也是觉得write intent log默认128M太小,所以才有“是否有多个write intent log”的想法。
还有:如果128M空间写满了,secondary仍然不可达时,怎么办?是不是写另外一个write intent log?(前提是允许有多个write intent log,就像ORACLE的redo log,写满了自动写下一个?)
 47 12345
发新话题
查看积分策略说明

快速回复主题

选项

[完成后可按 Ctrl+Enter 发布]  预览帖子  恢复数据  清空内容