3 Silver

MirrorView/S 故障排查点

跳至解决方案

这项技术如何进行故障排查,一般故障点如何。

我这边需要写文档,谢谢。

标签 (1)
0 项奖励
1 解答

已接受的解答
3 Zinc

Re: MirrorView/S 故障排查点

跳至解决方案

MirrorView/S 故障排除情况

情况描述操作

规划测试并激活维护

故障切换,然后回切

仅针对测试执行日常维护;设

备组和镜像工作正常。

检查 MirrorView 设备组信息,并激活到

目标站点 VNX for file/VNX for block 对的

手动故障切换,同时源站点仍可运行。

然后,执行恢复以测试回切。执行激活

时,目标站点充当设备组中所有镜像的

主要角色,源充当备份角色。

注意:为进行测试,在执行故障切换测

试时,请确保源 VNX for block 和

MirrorView 链路正常。如果在链路中断

的情况下执行故障切换测试,则将在恢

复过程中自动执行完全同步,以便重建

设备组和镜像,这非常耗时。

一个或两个

MirrorView 链路临时

丢失

一个或两个 MirrorView 链路丢

失将会导致设备组处于“系统

断开”状况。需要进行链路恢

复,以使设备组可以返回到

“同步”或“一致”和“活

动”状态。

在这种情况下, Unisphere 中

的 sys_log 或 VNX for file 状态

包含针对链路中断错误生成的

警报/ 事件。第 115 页的“从

日志文件中检索信息”提供了

详细信息。

只要组的组恢复策略设置为

“Automatic”(作为存储系统配置的一

部分创建该组时,此为默认值),设备组

就应该能够自动从临时链路中断错误中

恢复。

但是,如果该组的恢复策略设置为

“Manual”,则您必须运行

nas_devicegroup -resume 才能从链路中

断故障中恢复。

只要映像仍处于同步状态,您就可避免

执行强制性激活。如果在一个或两个链

路中断的情况下激活故障切换,将会

导致在恢复中执行完全同步,而强制升

级后发生的任何写入都将在恢复过程中

丢失。

源站点故障 源站点故障将会导致设备组处

于“系统断开”状况,同时也

表示出现以下情况:

• 主映像 LUN 故障

• 源存储阵列故障

• 两个存储处理器故障

• MirrorView 链路故障(较长

时间内链路中断)

注意:如果单个 源存储处理器

发生故障,则使用

nas_devicegroup 命令暂停

并恢复设备组操作。如果要在

此时执行故障切换激活,则这

属于正常的故障切换,而非强

制的故障切换。第 99 页的

“暂停设备组操作”提供了详

细信息。

对于单个源存储处理器故障之外的源站

点故障,请执行强制故障切换激活操作。

(要使备份映像对目标 VNX for file 可

见,需要对备份映像执行强制故障切

换。) 不能将源映像转换为备份映像。

在原帖中查看解决方案

0 项奖励
3 回复数
5 Rhenium

Re: MirrorView/S 故障排查点

跳至解决方案

我觉得首先要理解MirrorView的原理,并确认配置是遵照标准流程做的。这方面可以参考MirrorView Knowledge Book: http://www.emc.com/collateral/hardware/white-papers/h2417-mirrorview-know-cx-series-flare-wp-ldv.pdf 以及Unisphere的帮助手册。

真的出现了MirrorView相关问题,如果网络上没有太明显的异常,那通常EMC工程师都会要求收集两边存储的SPcollects日志、ktcons日志和交换机日志。同时回答或弄清附件文档里的这些问题:

1. 问题描述

2. 之前做了什么改动?

3. 之前MirrorView有没有正常运行过?

4. 主从站点间的距离?

5. 如果主从站点间据较远,线路供应商(ISP)是否有QoS设定?

6. MirrorView线路是否还有其它应用使用?

普通用户可以排查的就是硬件、网络线路状况和MV设置。如果硬件、网络和配置上都正常,那就只能分析日志了。Ktcons日志较为底层和复杂,不建议用户自己来分析,具体可以参考下列KB来收集:

emc206698 "Collecting relevant information required for triaging MirrorView connectivity-related problems": https://support.emc.com/kb/54297

emc218773 "Troubleshooting one-sided MirrorView connectivity issues": https://support.emc.com/kb/58236

4 Beryllium

Re: MirrorView/S 故障排查点

跳至解决方案

一般和MV/S相关的故障类型可能会包含这么几种,这些都是公开信息,你可以直接作为你的文档参考:

“支持MirrorView /同步的一级和二级阵列之间的距离”

如果距离被指定,就是一级和次级阵列之间的的点至点的距离。 MV / S本身不要求任何距离限制,理论上MV / S ,可用于IP网络的任何距离。然而,实际的距离将是有限的,因为应用程序的最小延迟,电缆损耗,等等,这就是为什么一般会被指定最大距离。在实践中,规避这种限制,通过使用“存储距离扩展”的技术。

存储距离扩展是指几种不同的技术,使数据通信在光纤通道存储区域网络(SAN)的光纤电缆延长跨度。除非某种形式的存储距离扩展,电缆损耗,延迟(时间所需的冲动来回) ,和波长会成为SAN里源(发射器)和目标之间的距离的限制(接收器) 。

“池中的LUN镜像同步失败,可能会导致严重的性能问题”
在MV的初始同步中,主要镜像是一个基于池的LUN,这个LUN是不完全由主机分配的,这种情况下可能有严重的性能问题。在某些情况下,LUN变得无法被他们的服务器访问。
还有一个问题, “零差距”镜像到辅助站点,这将导致一个连续系统的的fracture / partial sync。
主要和次要的MirrorView / S的( MV / S)镜像使用基于池的LUN,且次要镜像正在同步。
•主机的I / O (写请求)可能会取消,主镜像已完成I / O,并正在等待次镜像完成I / O
•当写请求被取消, MV / S fracture镜像,然后立即尝试同步。
•由于连续写入请求取消,镜像系统处于fracture-sync周期下,从来没有完成同步。

“MirrorView / S LUN使用FAST Cache的性能问题”
EMC的MirrorView开发团队证实在启用FAST cache的LUN上使用MV / S时,高响应时间可能会导致I / O取消和镜像随后可能断裂。当FAST cahce被禁用于辅助阵列上,响应时间恢复正常。解决方法是在包含次级MV / S的LUN的池上禁用FAST cache。对于正常的LUN变化没有影响,因为同步镜像延迟限制写的响应时间和FAST cache也帮不上忙。唯一的情况,次级LUN的FAST cache对性能改进是,如果次级镜像被提升为主镜像,FAST cache将提高I / O本地读取的响应时间。然而,池,它是一个问题,因为辅助阵列内的池的所有的LUN,需要FAST cache被禁用,不只是那些远程镜像用到的LUN。这意味着该池内的任何LUN不能使用FAST cache。该方案的另一个解决方法是在辅助阵列上拥有多个池,从而使非镜像LUN可使用FAST cache池。

“无法使用MirrorView同步( MV / S)大于2TB的池LUN (thick LUN,thin LUN) ”
此问题的出现,只有当你在没有数据的新的LUN上试图建立一个MV / S的关系。此刻避免这种情况的解决方法是预先格式化或在做LUN初始设置时在该LUN上添加辅助镜像之前,把数据放到源LUN上。这是首选的解决方法。
例如:
1.Bind新的LUN 。
2。创建镜像。
3。添加次要的,不需要初始同步。
4。增加LUN的存储组等。
另一种解决方法是使用“正常”的FLARE LUN而不是池LUN,作为辅助镜像。

3 Zinc

Re: MirrorView/S 故障排查点

跳至解决方案

MirrorView/S 故障排除情况

情况描述操作

规划测试并激活维护

故障切换,然后回切

仅针对测试执行日常维护;设

备组和镜像工作正常。

检查 MirrorView 设备组信息,并激活到

目标站点 VNX for file/VNX for block 对的

手动故障切换,同时源站点仍可运行。

然后,执行恢复以测试回切。执行激活

时,目标站点充当设备组中所有镜像的

主要角色,源充当备份角色。

注意:为进行测试,在执行故障切换测

试时,请确保源 VNX for block 和

MirrorView 链路正常。如果在链路中断

的情况下执行故障切换测试,则将在恢

复过程中自动执行完全同步,以便重建

设备组和镜像,这非常耗时。

一个或两个

MirrorView 链路临时

丢失

一个或两个 MirrorView 链路丢

失将会导致设备组处于“系统

断开”状况。需要进行链路恢

复,以使设备组可以返回到

“同步”或“一致”和“活

动”状态。

在这种情况下, Unisphere 中

的 sys_log 或 VNX for file 状态

包含针对链路中断错误生成的

警报/ 事件。第 115 页的“从

日志文件中检索信息”提供了

详细信息。

只要组的组恢复策略设置为

“Automatic”(作为存储系统配置的一

部分创建该组时,此为默认值),设备组

就应该能够自动从临时链路中断错误中

恢复。

但是,如果该组的恢复策略设置为

“Manual”,则您必须运行

nas_devicegroup -resume 才能从链路中

断故障中恢复。

只要映像仍处于同步状态,您就可避免

执行强制性激活。如果在一个或两个链

路中断的情况下激活故障切换,将会

导致在恢复中执行完全同步,而强制升

级后发生的任何写入都将在恢复过程中

丢失。

源站点故障 源站点故障将会导致设备组处

于“系统断开”状况,同时也

表示出现以下情况:

• 主映像 LUN 故障

• 源存储阵列故障

• 两个存储处理器故障

• MirrorView 链路故障(较长

时间内链路中断)

注意:如果单个 源存储处理器

发生故障,则使用

nas_devicegroup 命令暂停

并恢复设备组操作。如果要在

此时执行故障切换激活,则这

属于正常的故障切换,而非强

制的故障切换。第 99 页的

“暂停设备组操作”提供了详

细信息。

对于单个源存储处理器故障之外的源站

点故障,请执行强制故障切换激活操作。

(要使备份映像对目标 VNX for file 可

见,需要对备份映像执行强制故障切

换。) 不能将源映像转换为备份映像。

在原帖中查看解决方案

0 项奖励