Netapp 3200 7mode排障经验

最近通过几起Netapp存储排障经历,积累了一些经验,集中总结一下。

本文基于以下假想背景:

  • 一个控制器发生了硬件故障,另一个控制器发生了Takeover接管操作,但单节点性能不足以承载全部业务,由此性能下降,后续更换了故障控制器的主板,重新拉起设备。

  • 设备是Netapp FAS3200系列的存储,配置为7-Mode。

1 初步判断

1.1 硬件_控制器告警灯

正面黄色灯:硬件故障或者failover状态未启动;

背部黄色灯:代表此控制器处于被takeover状态,而不是硬件故障。因此,在修复时不是先灭灯才可giveback。而是giveback成功后再灭灯。

1.2 系统_性能数据

当业务负载较大,存活的controller上性能出现瓶颈时,网页图表可能加载不出来。

此时可以SSH到命令行界面,使用sysstat命令检查。

storage>sysstat -x 2

Tips:

如看到cifs IO输出为0,不代表此存储上没有cifs业务。处于瓶颈状态时,存储优先提供fcp业务。

1.3 确认影响业务范围

在存活节点用Volume show查看输出,对判断业务影响范围往往最可靠。即使是管理员,记忆也可能有偏差,会影响到向业务干系方汇报的准确度。

在出现设备硬件故障时,除非能短时修复,否则立即尝试从应用层面调整解决,后续再选择时机更换故障控制器,修复HA。

2 硬件更换及修复

宕机的控制器访问不了,需要使用串口连接(在尾部控制器面板找串口标志)。

简易过程如下:

image-20201221110233376

完成giveback后,完成修复的故障控制器节点应该能够正常启动和进入系统。再次对端口、聚合、磁盘、Volume信息等做检查,确保基本工作状态正常。

3 主机识别

更换控制器之后,LUN的Serial可能发生改变。(不绝对)

如果业务主机反复扫描,甚至重启,都无法识别原有LUN。可检查同一个LUN,是否发生了Serial改变。如果是,则手动将现在的Serial修改为之前的,再尝试扫描。

3.1确认Serial是否发生变化;

在主机层面找到需要修复的LUN,查看其Serial(24位数字)。

image-20201221112454144

在存储上,用命令查看Serial,比较两者是否一致。如下图。

storage*>lun serial -x /vol/volume/volume
                 Serial (hex)#:0x4431649592444345804731

如果不一致,则尝试存储端,使其与主机端一致。

3.2 查找原始Serial

注意,存储端命令需要以12位字符串形式输入,主机上能看到的24位数字是不行的。因此需要到存储AutoSupport日志中寻找原先的配置。

如果本地存储系统无法启动,可以从存活节点中读取,位置:c$\log\autosupport\。

AutoSupport每天都会生成一个文件夹,形如202012060015.1.files

其中保存了各种命令的输出结果,截取部分如下:

image-20201216170939802

找到LUN-configuration命令的输出文件,可在其中查找目标LUN的Serial号(12位字符串)。

image-20201221110924433

3.3 刷新LUN Serial

使用如下命令:

//lun serial [-x] lun_path new_lun_serial

lun serial /vol/blocks_fvt/ncmds_lun2 DlaIYSD4XPFr

更多信息可参考

Netapp Lun Serial命令语法

将LUN号刷回之后,在主机上尝试重新扫描,若仍无效则重启再试,应该可以解决。

4 技巧

4.1 找日志的方法

方法一:CIFS共享

在以域管理员用户登陆的Windows客户端上访问\\存储管理地址\c$

(前提是启用了CIFS服务,c$默认开启)可以看到

image-20201208200331177

方法二:FTP工具连接

此方法需要开启FTP服务,并建立FTP专门用户useradmin。

可检查options ftp命令输出。如果都是off则不行;

方法三:命令行工具

进入特权模式,命令提示符发生变化。

storage>priv set advanced
storage*> 

在终端工具(如securecrt)开启日志记录后,直接用rdfile命令在窗口中读取日志文件。

storage*>rdfile /etc/messages

断开会话,日志就被保存到了securecrt指定的位置。

Tips:

  • 输入ls /etc/log,可以列出log下的文件,大部分文件不能rdfile

  • 如果控制器还处于故障状态未能正常启动,则尝试到存活节点上查找共有配置信息-如LUN Serial;

4.2 使用performance counter查看性能

网页性能监控图表和sysstat命令能看到的指标是预设的,个数也较少。但还有一个快速简易地观察更多指标的方法——通过命令调用performance counter。

命令示例如下:

stats show -i 2 -n 900 fcp:fcp:fcp_latency                  //收900次fcp_latency信息
stats show -i 2 -n 900 aggregate:aggr1:total_transfers     //收900次aggr1的total_transfers信息

其中,最后的fcp_latency、total_transfers就是conter,前面两个单词为Object和Instance,这些在官方可查。

命令输出效果如下:

 fcp       32.91
     fcp       76.64
     fcp       60.01
     fcp       61.09
Instance fcp_latency
                  ms
     fcp       45.50
     fcp       52.75
     fcp       56.45
     fcp       34.93
     fcp       40.26
     fcp      101.50
     fcp       85.34
     fcp       70.79
    

以下是相关官方链接:

Netapp Manual Page,介绍命令语法。

https://library.netapp.com/ecmdocs/ECMP1368825/html/cmdrefnow/

stats命令详解,举例部分提到*object_name:instance_name:counter_name用法。

https://library.netapp.com/ecmdocs/ECMP1368825/html/cmdrefnow/man1/na_stats.1.html

可用性能计数器定义信息可参考:Definitions of performance counters。

https://library.netapp.com/ecmdocs/ECMP1608437/html/GUID-04407796-688E-489D-901C-A6C9EAC2A7A2.html

4.3 Nvram状态

image-20201221141430174

在Sysstat -X的命令输出中,Disk Util不是评价存储磁盘达到性能瓶颈的可靠指标。它反映最繁忙的一块磁盘的使用率,而不是所有磁盘的平均使用率。因此该项指标只能作为参考使用。当它长时间显示为100%时,才值得引起关注。

而CP_ty列不同字母代表的Nvram状态,更能说明性能问题。

如果出现大量的“B”开头的状态,则代表性能不好。它表示在上一个CP未结束时发起了新的CP,造成递归等待;(而小b会更不好)。

可以凭肉眼粗略判断出现的”B”的数量,也可以抓取日志后统计出现频率。

image-20201221141651656

性能富余的系统中,CP_ty列大部分为“-”,性能瓶颈的系统中,会有较多B开头字母。

关于各项CP_ty值的含义,具体可参考链接:

https://kb.netapp.com/Advice_and_Troubleshooting/Data_Storage_Software/ONTAP_OS/FAQ:_Consistency_Point

重点可看“What is the Back-to-Back (B2B) Consistency Point Scenario?”部分

4.4 同时收集多项指标数据

Netapp存储命令行只能单会话窗口登录。不能同时在多个终端上以root用户身份登陆。在当前会话窗口,只能显示单条命令的输出,如果想输入其它命令,只能中断当前命令。

当需要同时追踪多条命令输出的时候,比如收集不同的performance counter输出,可以通过从其它linux终端远程到存储上执行命令来实现。以下是一个例子,我们可以一边在存储上收集sysstat -x 结果,一边在linux终端上收集fcp_latency信息。如果打开更多的linux会话,还可以收集更多。

ssh root@XX.XX.XX.XX "stats show -i 2 -n 900 fcp:fcp:fcp_latency"
root@XX.XX.XX.XX's password: 
Instance fcp_latency
                  ms
     fcp       34.23
     fcp       40.42

4.5 关闭autogiveback

命令行下输入options cf,观察是否开启。如开启,建议关闭,命令如下:

options cf.giveback.auto.after.panic.takeover off

两个控制器上都需要进行操作。

此条目发表在IT技术分类目录,贴了标签。将固定链接加入收藏夹。

发表评论

您的电子邮箱地址不会被公开。 必填项已用*标注