浏览
帮助
登录
此帖子已超过 5 年
Solved!
sercher
54 消息
0
2477
2013年10月13日 23:00
这项技术如何进行故障排查,一般故障点如何。
我这边需要写文档,谢谢。
回复(3)
cxemc
2 Intern
•
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
2 Intern
2 Intern
•
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
2 Intern
2 Intern
•
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
2 Intern
2 Intern
•
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,作为辅助镜像。