本文基于以下假想背景：
-
一个控制器发生了硬件故障，另一个控制器发生了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/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
更多信息可参考
将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.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
以下是相关官方链接：
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值的含义，具体可参考链接：
重点可看“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