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 硬件更换及修复

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

简易过程如下：

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

3 主机识别

更换控制器之后，LUN的Serial可能发生改变。（不绝对）

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

3.1确认Serial是否发生变化；

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

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

storage*>lun serial -x /vol/volume/volumeSerial (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_seriallun serial /vol/blocks_fvt/ncmds_lun2 DlaIYSD4XPFr

更多信息可参考

https://library.netapp.com/ecmdocs/ECMP1196995/html/GUID-4884DD02-793C-483B-987F-06655E0BED38.html

将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：

输入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.91fcp       76.64fcp       60.01fcp       61.09
Instance fcp_latencymsfcp       45.50fcp       52.75fcp       56.45fcp       34.93fcp       40.26fcp      101.50fcp       85.34fcp       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 root@XX.XX.XX.XX "stats show -i 2 -n 900 fcp:fcp:fcp_latency"
root@XX.XX.XX.XX's password:
Instance fcp_latencymsfcp       34.23fcp       40.42

4.5 关闭autogiveback

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

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

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