未解决
此帖子已超过 5 年
1.1K 消息
0
528
常见MirrorView/S故障排查
常见MirrorView/S故障排查
转载请在文首保留原文出处：EMC中文支持论坛https://community.emc.com/go/chinese
介绍
一般和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，作为辅助镜像。
应用于
MirrorView/S