浏览
帮助
登录
此帖子已超过 5 年
Solved!
sercher
54 消息
0
2461
2013年10月13日 23:00
这项技术如何进行故障排查，一般故障点如何。
我这边需要写文档，谢谢。
回复(3)
cxemc
362 消息
2013年10月15日 02:00
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 可
见，需要对备份映像执行强制故障切
换。） 不能将源映像转换为备份映像。
Roger_Wu
4K 消息
1
2013年10月14日 01:00
我觉得首先要理解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
1个附件
emc206698 - Collecting relevant information required for triaging MirrorView connectivity-related problems.doc
o17Uu33DCF12520
1.1K 消息
2013年10月14日 22:00
一般和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，作为辅助镜像。
戴尔支持资源
查看更多
查看全部
Top
cxemc
362 消息
0
2013年10月15日 02:00
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 可
见，需要对备份映像执行强制故障切
换。） 不能将源映像转换为备份映像。
Roger_Wu
4K 消息
1
2013年10月14日 01:00
我觉得首先要理解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
1个附件
emc206698 - Collecting relevant information required for triaging MirrorView connectivity-related problems.doc
o17Uu33DCF12520
1.1K 消息
1
2013年10月14日 22:00
一般和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，作为辅助镜像。