深夜两点十七分手机弹出一条存储告警短信HPE_3PAR C630上某个磁盘状态从normal变成了degraded。紧接着值班同事在群里问要不要现在去机房我的回复是先别急着去按命令集把这个状态吃透再决定是换盘还是换线。这套命令集是我们运维团队在3PAR C630和H3C CF22030这套SAN组合上跑了两年多才沉淀下来的覆盖了日巡检、性能分析、告警分级、FC链路排查和自动化采集。今天把它完整梳理出来给同样被存储和FC交换机监控折腾过的兄弟们一个可直接参考的实操手册不管是值班工程师、DBA还是基础设施运维都能照着落地。1. 接入设备与监控前的准备账号、连接方式和巡检模型1.1 3PAR C630SSH接入和账号权限的几个坑3PAR C630的管理入口是SSH默认端口22通过管理IP登录。我必须提醒第一次接触3PAR的兄弟3PAR的命令行不是Linux也不是一般存储厂商的CLI它有一套自己定义的命令体系登录后直接输入show开头的命令就能干活。不同账号的权限差别很大3paradm存储管理员日常巡检、查show、改配置都靠它admin偏系统层面管理管用户、网络、服务root底层问题处理用日常监控千万别碰误操作后果很直接。我们生产环境单独建了一个只读巡检账号只授show类权限监控脚本全部用它。原因很简单如果脚本用的管理账号一旦脚本被误改或键盘输入串了把告警处理写成配置变更不是没可能。这种事我在另一套存储上真实见过。登录确认权限后先敲“?”或help确认当前固件版本的命令集。3PAR OS 3.x和4.x在部分命令参数上有细微差别比如某些版本showalert的过滤参数写法不同。每次固件升级后先把常用命令的help输出过一遍确认参数没变再继续用。还有个大坑是多域Domain环境。如果开了域非全局账号查告警可能只看得到自己域内的对象别家域里有磁盘告警你用普通账号跑showalert却是一片绿。所以巡检脚本里我坚持加一步showdomain确认当前账号的域可见范围避免漏报。1.2 CF22030FC交换机的接入方式与命令风格确认H3C CF22030是这套环境里的FC存储交换机承载服务器HBA到3PAR存储之间的所有SAN流量。上联3PAR的前端FC端口下接各业务主机的HBA在fabric里属于核心节点位置很关键。CF22030的接入方式同样是SSH和串口管理。这里如实说明CF22030不同固件批次、不同软件版本的命令行风格有差异。我这台是类Fabric OS风格的命令行本文里FC交换机的命令都基于这套风格来写。如果你在实际设备上敲switchshow报unknown command不用慌换成Comware风格的display switchshow或者直接敲“?”看设备支持的命令清单思路完全一致。后面给的监控指标和阈值判断方法在两种风格下都通用。第一次接入CF22030建议按这个顺序摸清环境看版本确认固件版本和当前license状态看fabric信息确认交换机名称、domain ID和链路角色看端口摘要确认所有端口在线状态是否正常看温度电源排除机房风道、供电隐患。这些信息要存档作为后续监控的初始基线。1.3 我的巡检模型日巡检、周巡检、月巡检监控命令很多真正能长期稳定执行靠的是合适的周期。我按实际运维节奏把监控拆成三个层级运行了两年多效果稳定巡检周期3PAR C630命令H3C CF22030命令重点关注日巡检showalert -status open、checkhealthswitchshow、porterrshow看增量新增告警、端口异常状态周巡检showpd -s、showvv -s、showcpg、showsysswitchshow、sensorshow、cfgshow磁盘卷状态变化、空间趋势月巡检statvv -iter 5 -interval 2、statpd、statportportstatsshow、errshow、portshow光模块性能基线、错误趋势、光功率劣化我想强调一点不要一上来就追求所有命令全自动化。先把日、周、月三个层级的命令人工跑两到三轮把每台设备的正常输出打成基线再决定哪些交给脚本。跳过这一步直接上自动化后面全是误报。2. 3PAR C630核心监控命令从整体健康到后端磁盘逐层下沉2.1 checkhealth日常巡检的第一道闸门3PAR的checkhealth是我接触过的存储里最好用的健康扫描命令。它一次覆盖节点、磁盘、电池、风扇、电源、温度、端口、远程复制、许可证等模块把整个系统的健康状态聚合到一张表里checkhealth -v输出按模块列出Health Status常见三种结果OK正常DEGRADED降级功能还在但冗余或性能受损FAILED功能已经失效需要立即处理。日常巡检只看checkhealth就够了哪个模块报DEGRADED或FAILED再下沉到具体模块细查。举几个常用组合checkhealth disk -v逐个磁盘状态核对配合showpd -s使用checkhealth node -v控制器节点的CPU、内存、缓存状态checkhealth battery -v缓存后备电池状态电池挂了会直接导致缓存降级写性能。实测下来checkhealth跑一次通常几秒到十几秒对生产影响很小。我们把它当作值班交接的固定动作夜班走之前跑一次白班的人看输出就能确认整晚有没有隐性故障。2.2 showalert与事件日志告警驱动的第一响应checkhealth看当前快照showalert看历史未关闭告警。平时最常用这条showalert -status open它会列出所有未关闭的告警包含时间、严重级别、子系统、描述。我判断优先级的逻辑很简单Critical/Major级别无论哪个子系统都优先处理Minor级别但涉及磁盘、电池、复制链路的当天处理掉Minor级别且反复出现的要特别重视往往对应硬件早期失效。另一个专业命令是事件日志showeventlog -t 1d看最近一天事件把事件时间点对应到业务异常的时间线上。遇到“晚上8点数据库突然变慢”这类问题我先拉showalert看有没有同时段告警再翻showeventlog找同时段日志几轮下来就能把问题范围缩到存储系统、FC链路还是主机侧。有个细节容易踩坑3PAR的告警从open变成closed不代表问题真的解决了也可能是维护人员确认过但没处理根因。所以每周最好把近期closed的告警也过一遍确认每个关闭都有明确原因。2.3 showpd/showld/showvv从物理盘到虚拟卷的状态链路3PAR的逻辑结构是一条链物理磁盘PD→ 逻辑磁盘LD→ 共享空间池CPG→ 虚拟卷VV。监控状态要沿着这条链一层层往下看。先看物理盘showpd -s输出里最关键两列State和Space。State正常是normaldegraded说明盘在读写异常或预失败failed说明盘不可用。跑一次showpd -s如果看到大批failed或degraded优先怀疑机柜电源、背板或批量盘问题而不是单盘故障。想看单盘详细信息showpd -i里面包含盘位、序列号、固件版本、转速、容量还有SMART相关计数。换盘前必须用showpd -i拿到准确盘位柜号、pos、bay号别拿错备件白跑一趟机房。再看逻辑盘showld -sLD状态重点关注是不是complete。complete说明RAID正常degraded说明有组成盘离线或降级。这层比showpd更贴近业务showpd只告诉你某块盘坏了showld会告诉你这块盘影响了哪些RAID组进而影响哪些卷。最上层看虚拟卷showvv -s showvv -i一条看空间和快照占用一条看卷类型和状态。卷状态normal是正常degraded说明底层LD可能有问题。排障时推荐按“showvv -i找到有问题的卷→showld -s找对应LD→showpd -s找故障盘”的顺序往下钻比乱翻输出快很多。2.4 statvv/statpd/statport性能定位三件套状态监控之外性能监控才是存储运维的深水区。3PAR的核心性能命令有三个statvv看虚拟卷性能statvv -iter 5 -interval 2 卷名按采样次数和间隔输出TPS、IOPS、MB/s、平均响应时间读写分开展示。用来判断某个卷是否成了业务瓶颈。statpd看物理盘性能参数一样对磁盘健康判断很有价值。如果某块盘响应时间明显高于同柜其他盘比如平均5ms的盘里出现一块持续40ms的盘这块盘大概率在老化。statport看端口性能包括前端主机端口和后端磁盘端口的IOPS、带宽。业务整体变慢却定位不到具体卷时用statport看哪些端口接近饱和再顺链路找业务。性能采集有个铁律不要在业务高峰反复执行大批量stat命令。stat类命令要读取系统计数器并聚合计算IO很忙时会给存储增加额外管理开销。我一般把批量stat采集安排在业务低峰或者人工专项排障时用。还有一个判断经验值得说明看到statpd平均延迟高第一反应不是马上换盘而是先看同柜其他盘的平均延迟。如果都高问题可能在背板或扩展柜只有单独一块高才定位到单盘。2.5 3PAR C630监控阈值参考表结合实际环境把命令总结成一张可直接参考的阈值表监控对象命令正常参考预警阈值物理盘状态showpd -sState为normal出现degraded/failed立即处理LD状态showld -scomplete非complete立即排查卷状态showvv -inormal非normal立即排查磁盘延迟statpd平均10ms连续均值20ms预警50ms报警卷延迟statvv平均5ms连续均值10ms预警节点CPUshownode / checkhealth node80%持续超80%且业务变慢前端端口showport状态ready非ready或CRC持续增长这组阈值来自我们生产环境大量正常和故障数据分析不是拍脑袋定的。不同业务模型会有差异建议先跑两周基线把阈值调成自己环境的版本再用于告警。3. H3C CF22030端口级监控链路状态、错误计数与光模块衰减3.1 switchshow与fabricshow先建立fabric全局视野FC交换机的故障路径很奇怪它往往不是从设备自身状态体现而是从“某个端口连不上”“某个主机看不到盘”这类业务现象暴露。所以监控CF22030的第一步不是看性能是看端口状态概览switchshow这个命令把所有端口按编号列出来包括端口类型F_Port连主机、E_Port连交换机、U_Port通用端口状态Online/Offline连接设备的WWN和速率。我巡检时习惯把Online端口数量跟上一轮对比数量一降马上能定位到是哪条链路掉了。然后再看fabric级状态fabricshow生产环境通常有主备两套fabric或者多台交换机组一个fabric。fabricshow能看到当前fabric的所有交换机成员、domain id、链路情况。fabric出现segmentation分区隔离时大量zone会直接失效业务表现为“主机能看到部分盘但看不到全部”。这种问题单看一台交换机根本发现不了必须用fabricshow把fabric整体拉出来看。经验之谈每次升级交换机固件前一定先跑一次switchshow和fabricshow留档。升级后对比两份输出如果端口类型、WWN注册情况、domain id有变化说明固件升级影响了fabric配置要尽快回滚或调整。3.2 porterrshow与portstatsshow错误计数和流量统计端口状态正常不代表链路健康。很多FC链路故障是“端口Online但错误不断增长”这种最隐蔽。靠porterrshow来抓porterrshow输出里重点看几个错误计数CRC错误链路物理层误码。CRC持续增长说明线缆、光模块或连接器有问题是FC链路里最常见的劣化信号Sync Loss同步丢失光功率大幅波动或断纤Signal Loss信号丢失收不到光信号Link Reset链路复位频繁重置要考虑协议协商或兼容问题。我判断错误是不是问题从不看绝对数量只看增长率。光纤在插拔瞬间、对端设备重启时产生一次性的CRC或Sync Loss很正常。但如果连续两次巡检之间错误计数快速增长物理链路肯定有问题。每周跑一次porterrshow留档下一次对比增长率比当场看绝对值有效得多。流量统计用portstatsshowportstatsshow它给出每个端口的帧数、字节数、丢弃和错误。这个命令在分析端口利用率、判断链路是否被某台主机打满时很有用。大促之后回看portstatsshow会发现某些F_Port吞吐接近端口上限这时就要考虑给这条主机链路加多路径或扩带宽。3.3 portshow与光模块收发光检查porterrshow的CRC或Sync Loss持续增长时下一步要检查物理层先看单端口详情portshow 端口号这个命令看端口状态、实际协商速率、连接WWN、各项错误计数汇总。光模块收发光功率检查更直接。类FOS风格设备一般可以用portshow的optics相关子命令看Rx Power、Tx PowerComware风格对应的命令是display transceiver interface。两种风格我在现场都用过核心看收光功率Rx Power和是否超过模块阈值。光模块衰减判断经验收光功率接近模块规格下限但还在范围内黄色预警同一端口收光功率比上一轮监测下降超过3dB即使还在范围内也要重视光纤或模块在劣化收光功率掉到下限以下主机侧会频繁掉盘、路径切换报警。温度也容易忽略。FC交换机机箱密闭散热一坏就是批量端口Down。sensorshow或类似命令看电源、风扇、温度状态。交换机进风温度超过65℃就要查机房空调和风扇转速超过75℃基本要考虑业务迁移和停机降温。3.4 cfgshow与nsshow业务可见性的最后一道闸门端口和光模块都正常但主机还是看不到盘大概率是zone的问题。CF22030的zone配置用cfgshow查看cfgshow这个命令看当前生效的zone集合和成员。新增主机或存储端口后最常见的错误是线拉好了、WWN也注册了但没加zone业务侧fdisk就是看不到盘。用cfgshow确认WWN在不在正确zone里比在存储端反复改配置快得多。nsshow是另一个常用命令显示当前fabric中已注册到Name Server的所有设备WWN。判断逻辑很简单主机HBA注册上了nsshow里就能看到对应WWN看不到说明HBA到交换机的链路或驱动有问题存储端根本不用查。zone问题的典型场景是两台交换机级联一边zone配置没同步导致业务切换后看不到部分磁盘。我的规则是所有zone变更后两套fabric都跑一次cfgshow核对不能只改一边。3.5 CF22030监控阈值参考表这套阈值是配合3PAR那套一起用的监控对象命令正常参考预警阈值端口状态switchshowOnline出现Offline立即定位CRC错误porterrshow两次巡检间无持续增长单周增长率明显异常同步/信号丢失porterrshow0出现持续计数增长收光功率portshow optics / display transceiver在模块规格范围内接近下限或比上次降3dB设备温度sensorshow65℃65℃预警75℃报警电源风扇sensorshowOK非OK立即处理zone一致性cfgshow两套fabric一致不一致立即修复4. 监控命令集的自动化落地脚本化采集与告警闭环4.1 为什么不能只靠人工敲命令命令写得再全靠人肉每天敲总会有遗漏尤其是凌晨故障和多人交接的时候。真正稳定可靠的监控是让命令在固定时间自动执行、自动对比、自动抛出告警。但我要先泼一盆冷水不要在还没建立基线数据的时候写告警规则否则你会发现满屏误报最后团队对告警脱敏真正的故障反而没人关注。我的落地步骤分三步先人工跑两到三周把每台设备的正常输出存档建立基线写采集脚本把命令输出统一落地成带日期的文件纳入日志管理写判定逻辑基于基线和阈值产生告警再接入通知渠道。4.2 基于SSH执行器的统一采集框架3PAR和CF22030都支持SSH所以用一个统一框架监控机通过SSH Key免密登录设备执行固定命令集合输出按日期保存。3PAR C630的采集脚本示意#!/bin/bash # 3PAR C630 daily health check SSH_KEY/home/monitor/.ssh/id_rsa STORAGE_ADDR3par-mgmt-ip LOG_DIR/data/monitor/3par/$(date %F) mkdir -p $LOG_DIR run_cmd() { ssh -i $SSH_KEY -o ConnectTimeout10 -o StrictHostKeyCheckingno \ monitor$STORAGE_ADDR $1 $2 } run_cmd showalert -status open $LOG_DIR/showalert_open.txt run_cmd checkhealth $LOG_DIR/checkhealth.txt run_cmd showpd -s $LOG_DIR/showpd_s.txt run_cmd showvv -s $LOG_DIR/showvv_s.txt # 如果有未关闭的Critical/Major告警立即通知 if grep -qE Critical|Major $LOG_DIR/showalert_open.txt; then /usr/local/bin/send_alarm.sh 3PAR Critical/Major Alert $LOG_DIR/showalert_open.txt fiCF22030的采集脚本类似换成FC交换机的命令集合#!/bin/bash # H3C CF22030 daily fabric check SSH_KEY/home/monitor/.ssh/id_rsa SWITCH_ADDRfc-mgmt-ip LOG_DIR/data/monitor/cf22030/$(date %F) mkdir -p $LOG_DIR for cmd in switchshow porterrshow sensorshow; do ssh -i $SSH_KEY -o ConnectTimeout10 -o StrictHostKeyCheckingno \ monitor$SWITCH_ADDR $cmd $LOG_DIR/${cmd}.txt done # 检查端口状态出现Offline且非维护窗口触发告警 sed -n /State/p $LOG_DIR/switchshow.txt | grep -i offline \ /usr/local/bin/send_alarm.sh CF22030 Port Offline $LOG_DIR/switchshow.txt脚本本身不复杂但几个细节很重要用专用监控账号配SSH Key认证不用密码每条命令设置超时防止设备hang住时脚本卡死输出保存为带日期的文件方便趋势分析和历史对比维护窗口要能跳过告警比如用维护标志文件控制当天是否启用告警。4.3 告警判定与通知设计命令输出落地之后告警判定是另一层逻辑。我的原则是按故障级别分级立即通知showalert有Critical/Major、checkhealth出现FAILED、FC端口Offline数增加、磁盘状态degraded或failed日报汇总checkhealth出现DEGRADED但未FAILED、CRC错误有增长但幅度不大、空间使用率超过阈值。分级的好处是避免“狼来了”。如果不分级任何小告警都打电话过一个月所有人看告警都无感了。错误计数类指标建议做增长量判定。比如porterrshow的CRC脚本保留前一天文件用diff对比增量prev/data/monitor/cf22030/$(date -d yesterday %F)/porterrshow.txt cur/data/monitor/cf22030/$(date %F)/porterrshow.txt # 计算CRC列增长量增量超过阈值则告警“看增量”比“绝对值超阈值”更适合链路质量监控能过滤掉大量插拔、重启引起的一次性误报减少半夜被叫醒的次数。4.4 SNMP与平台对接的补充思路脚本采集适合中小规模环境。如果监控平台已经接了Zabbix或Prometheus可以考虑直接走SNMP3PAR C630支持SNMP Trap故障事件直接推送到平台告警事件自动入库CF22030支持SNMP v2c/v3平台通过OID轮询端口状态、错误计数器、温度等指标。我的建议是SNMP用于事件和状态发现脚本用于命令输出和深度排查两者结合最好。不要只依赖SNMP因为很多FC交换机和存储的私有MIB节点文档不全现场调试成本很高命令行输出稳定、可读更贴合运维排障习惯。自动化不只是写脚本。见过不少团队脚本写得很漂亮但忘了加日志、加超时、加异常处理故障发生时脚本自己先挂了。我们的做法是每次脚本执行都写执行日志如果SSH连接失败控制器发一条“监控采集失败”的告警这个告警本身就代表设备可能有异常。5. 一次真实故障的完整排查链路告警、日志与两端命令联动5.1 故障现象与初始告警去年一次晚高峰告警平台连续收到两条消息。先是3PAR C630的showalert检测到一块磁盘状态变为degraded然后是CF22030上一个F_Port的CRC错误计数快速增长两台业务主机的多路径软件提示某条路径down。业务侧感知是数据库偶发变慢、切换时有轻微卡顿但还没到完全不可用。值班同事第一反应是“存储盘坏了要不要马上换盘”。我没有让他直接换。理由是degraded不一定会立刻导致路径down而同时间FC端口CRC快速增长提示链路物理层可能也有问题。两个现象同时出现不能只盯着存储端看。5.2 存储端定位showalert与showpd先把存储端命令拉齐ssh monitor3par-mgmt showalert -status open输出里能看到那条degraded告警级别为Major子系统是Disk发生时间在当天17:45左右。接着跑showpd -s找到盘位后确认状态列显示degradedSMART相关计数有异常。再跑showld -s确认这块盘所在LD的状态还是complete也就是RAID冗余还在、数据没有丢只是有进一步恶化的风险。showvv -s和statvv看了业务卷卷状态正常延迟略微升高。存储端结论是存在单盘隐患但当前不构成必须立即强制换盘的紧急条件可以申请维护窗口更换。5.3 FC链路定位portshow与porterrshow存储端判断完之后回头看CF22030。登录交换机porterrshowCRC错误在目标端口增长得相当明显看历史记录这个端口的错误计数在过去两个小时持续增加不是一次性抖动。再跑portshow 端口号确认端口状态Online、协商速率正常但物理错误计数在涨。拔下光纤看光模块接口明显看到一根跳线有弯折痕迹收光功率掉到接近下限。这就暴露了问题那根跳线布线时预留长度不够机柜理线时被拉成了死弯光信号持续劣化。白天业务负载不高不明显晚高峰流量一上来误码快速增长主机多路径检测到链路质量下降触发路径切换。5.4 根因确认与处理最终确认是两件事叠加物理层FC交换机到主机之间的光纤跳线劣化导致链路误码和路径切换存储层3PAR C630上存在一块degraded磁盘属于独立硬件隐患。处理顺序上先处理物理链路。换跳线后porterrshow的错误计数停止增长主机多路径恢复。磁盘在当天夜间维护窗口更换换盘后showpd -s确认新盘状态为normalshowld状态保持complete流程结束。5.5 这次排障沉淀的几条经验这次故障对监控体系影响很大我沉淀了几条关键经验告警要“两端对表”。存储端有问题时同时看FC交换机和主机HBA侧指标经常能发现真正的物理路径问题换盘前先看LD状态和业务影响。degraded但LD complete不等于马上要处理先评估窗口但CRC增长是实时性能问题优先级更高每次处理后把命令输出留档。后来给两台设备都建了输出基线库下次判断先和上一轮数据对比误判率明显降低自动化脚本里一定要有物理链路指标。如果当时只监控存储端的showalert链路劣化可能要拖到完全断链才会被感知。这次之后我把CF22030的porterrshow增量检查加进了日巡检自动化3PAR的磁盘状态检查也改成每次showpd -s都对比上一轮输出。现在再遇到类似的“存储加FC”组合故障值班人员的第一反应已经不再是“要不要去机房”而是先按命令集把两端数据拉出来把问题定位到具体层再动手。