跳转到主内容

NetApp_Insight_2020.png 

什么是超级逻辑单元重置( SLURR )以及如何从挂起的情况中恢复?

Views:
3
Visibility:
Public
Votes:
0
Category:
data-ontap-8
Specialty:
san
Last Updated:

可不使用  

适用于

  • 集群模式 Data ONTAP 8.3
  • FlexPod 

解答

在集群模式 Data ONTAP 中、逻辑单元号( LUN )是跨集群中一个或多个节点的分布式对象。超级逻辑单元重置( SLURR )是由集群模式 Data ONTAP SCSI 目标触发的内部 LUN 重置机制。在出现以前分布式操作超时的罕见情况时、 ONTAP 内部会启动 SLR 。执行此操作可将自身重新初始化为一致状态。

什么是 SLUR?
  • 超级逻辑单元重置( SLURR )
  • 在 Data ONTAP 中自触发
  • 在将自身重新初始化为一致状态时由 SCSIT 触发
  • 也可能超时的分布式操作
在 SLURR 期间会发生什么情况?
  • 不允许新成员加入 LUN 组
  • 现有成员可以离开 LUN 组
  • 终止所有正在运行的命令和新命令(直至其完成)
  • 逻辑单元清理

由于多种原因,可以触发倾斜。以下 EMS 消息指示每个状态,可用于确定发生了 SLURR :

slur 开始

slur 的开头由scsiblade.lu.int.rst.start EMS 字符串表示

Wed May 27 2015 14:32:11 GMT [node-1: scsit_lu: scsiblade.lu.int.rst.start:DEBUG]: Internal reset started on LUN AvV7z?Cl-tME for reason: initiated by peer

slur 结束

slur 结尾由scsiblade.lu.int.loc.rst.end EMS 字符串表示

Wed May 27 2015 14:36:53 GMT [node-1: scsit_lu: scsiblade.lu.int.loc.rst.end:DEBUG]: Internal reset of LUN AvV7z?Cl-tME was completed on node node-1

SLURR 完成

要在整个集群范围内完成 SLR 、应在所有节点上完成。slur 完成由scsiblade.lu.int.rst.end EMS字符串表示。

Wed May 27 2015 14:36:53 GMT [node-1: scsit_lu: scsiblade.lu.int.rst.end:DEBUG]: Internal reset of LUN AvV7z?Cl-tME was completed cluster-wide.

粘滞的狭缝:

当 SLur 操作未完成时、逻辑单元将进入挂起状态并由scsiblade.lu.int.rst.hung EMS 字符串表示。

Wed May 27 2015 14:32:41 GMT [node-1: scsit_lu: scsiblade.lu.int.rst.hung:ALERT]: Access to LUN AvV7z?Cl-tME is restricted because an internal reset of the LUN was not completed in 30 seconds. Perform a takeover followed by a giveback for the following nodes: node-1
 

集群中的每个节点都将发出一个用于 SLURR 启动的 EMS 。消息字符串包含原因部分。未执行 SLur 的节点将报告由对等方启动。

示例:[scsit_lu: scsiblade.lu.int.rst.start:debug]: Internal reset started on LUN D1dyo]E5t9p5 for reason: initiated by peer.

执行 slur 的节点以及需要重新引导的节点将说明以下几个原因之一。

示例: [scsit_lu: scsiblade.lu.int.rst.start:debug]: Internal reset started on LUN D1dyo]E5t9p0 for reason: PR OUT bb owner died.

如何验证挂起的 SLur 是否存在:

您可以使用以下命令检查 slur 是否已从命令行中卡住。如果响应为空,则不会出现挂起的倾斜:

cluster1::> event log show -messagename *scsiblade.lu*

There are no entries matching your query.

在以下示例中,您可以看到单个 LUN 的多条消息。在某些情况下、 SLR 可以在挂起事件后完成。如果是这种情况、并且不存在 LUN 访问问题、则无需执行“至 / GB ”。

cluster1::> event log show -messagename *scsiblade.lu*
Wed Jun 15 20:20:13 PDT [node-1: scsit_lu_1: scsiblade.lu.int.rst.start:debug]: Internal reset started on LUN AvV7z?Cl-tME for reason: tmr deadman timer expired.
Wed Jun 15 20:21:43 PDT [node-1: scsit_lu_0: scsiblade.lu.int.rst.hung:alert]: Access to LUN AvV7z?Cl-tME is restricted because an internal reset of the LUN was not
Wed Jun 15 20:22:39 PDT [node-1: scsit_lu_0: scsiblade.lu.int.loc.rst.end:debug]: Internal reset of LUN AvV7z?Cl-tME was completed on node node-1.
Wed Jun 15 20:22:39 PDT [node-1: scsit_lu_0: scsiblade.lu.int.rst.end:debug]: Internal reset of LUN AvV7z?Cl-tME was completed cluster-wide.

从挂起的 slur 中恢复:

注:如果挂起事件后发生 SLURR 完成、并且 LUN 当前没有访问问题、请勿执行接管 / 恢复。

注:如果已知或可能存在集群中的阻塞组,请勿执行接管 / 恢复。 如果不清楚这是否属于这种情况、请打开支持案例以验证执行接管 / 恢复是否安全

如果某个 SLR 操作无响应、 EMS 消息将指示应重新引导哪个节点以清除卡住的 SLUR.在迄今为止的所有情况下、单节点重新引导就足以清除挂起的 SLUR.EMS 消息将明确说明从挂起的 SLURR 状况中恢复的补救措施。在上面的示例中,该消息告诉我们需要重新引导哪个节点才能完成粘滞的 SLURM 操作。

注:如果需要根本原因分析( Ra )、请按照 RASTRACE 数据收集(以 KB 为单位)执行操作:
继续恢复之前、如何为以前发生的 SAN 事件的一个 RCAs 收集数据。请参见 Data ONTAP 部分中的第 1 步。

要解决此问题,请执行接管操作、然后为scsiblade.lu.int.rst.hung:ALERT EMS 事件中指示的 LUN 执行恢复。在上面的示例中,对以下节点执行接管 / 恢复:
node1 。

其他信息

不适用