最近通过几起Netapp存储排障经历,积累了一些经验,集中总结一下。
本文基于以下假想背景:
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 硬件更换及修复
宕机的控制器访问不了,需要使用串口连接(在尾部控制器面板找串口标志)。
简易过程如下:

完成giveback后,完成修复的故障控制器节点应该能够正常启动和进入系统。再次对端口、聚合、磁盘、Volume信息等做检查,确保基本工作状态正常。
3 主机识别
更换控制器之后,LUN的Serial可能发生改变。(不绝对)
如果业务主机反复扫描,甚至重启,都无法识别原有LUN。可检查同一个LUN,是否发生了Serial改变。如果是,则手动将现在的Serial修改为之前的,再尝试扫描。
3.1确认Serial是否发生变化;
在主机层面找到需要修复的LUN,查看其Serial(24位数字)。

在存储上,用命令查看Serial,比较两者是否一致。如下图。
storage*>lun serial -x /vol/volume/volume
Serial (hex)#:0x4431649592444345804731
如果不一致,则尝试存储端,使其与主机端一致。
3.2 查找原始Serial
注意,存储端命令需要以12位字符串形式输入,主机上能看到的24位数字是不行的。因此需要到存储AutoSupport日志中寻找原先的配置。
如果本地存储系统无法启动,可以从存活节点中读取,位置:c$\log\autosupport\。
AutoSupport每天都会生成一个文件夹,形如202012060015.1.files。
其中保存了各种命令的输出结果,截取部分如下:

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

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$默认开启)可以看到

方法二:FTP工具连接
此方法需要开启FTP服务,并建立FTP专门用户useradmin。
可检查options ftp命令输出。如果都是off则不行;
方法三:命令行工具
进入特权模式,命令提示符发生变化。
storage>priv set advanced
storage*>
在终端工具(如securecrt)开启日志记录后,直接用rdfile命令在窗口中读取日志文件。
storage*>rdfile /etc/messages
断开会话,日志就被保存到了securecrt指定的位置。
Tips:
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状态

在Sysstat -X的命令输出中,Disk Util不是评价存储磁盘达到性能瓶颈的可靠指标。它反映最繁忙的一块磁盘的使用率,而不是所有磁盘的平均使用率。因此该项指标只能作为参考使用。当它长时间显示为100%时,才值得引起关注。
而CP_ty列不同字母代表的Nvram状态,更能说明性能问题。
如果出现大量的“B”开头的状态,则代表性能不好。它表示在上一个CP未结束时发起了新的CP,造成递归等待;(而小b会更不好)。
可以凭肉眼粗略判断出现的”B”的数量,也可以抓取日志后统计出现频率。

性能富余的系统中,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 [email protected] "stats show -i 2 -n 900 fcp:fcp:fcp_latency"
[email protected]'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
两个控制器上都需要进行操作。