企业官网建设流程全解析

深夜两点十七分，手机弹出一条存储告警短信，HPE_3PAR C630上某个磁盘状态从normal变成了degraded。紧接着值班同事在群里问：要不要现在去机房？我的回复是：先别急着去，按命令集把这个状态吃透，再决定是换盘还是换线。这套命令集是我们运维团队在3PAR C630和H3C CF22030这套SAN组合上跑了两年多才沉淀下来的，覆盖了日巡检、性能分析、告警分级、FC链路排查和自动化采集。今天把它完整梳理出来，给同样被存储和FC交换机监控折腾过的兄弟们一个可直接参考的实操手册，不管是值班工程师、DBA还是基础设施运维，都能照着落地。

1. 接入设备与监控前的准备：账号、连接方式和巡检模型

1.1 3PAR C630：SSH接入和账号权限的几个坑

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 CF22030：FC交换机的接入方式与命令风格确认

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 我的巡检模型：日巡检、周巡检、月巡检

监控命令很多，真正能长期稳定执行靠的是合适的周期。我按实际运维节奏把监控拆成三个层级，运行了两年多，效果稳定：

我想强调一点：不要一上来就追求所有命令全自动化。先把日、周、月三个层级的命令人工跑两到三轮，把每台设备的正常输出打成基线，再决定哪些交给脚本。跳过这一步直接上自动化，后面全是误报。

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正常是normal，degraded说明盘在读写异常或预失败，failed说明盘不可用。跑一次showpd -s，如果看到大批failed或degraded，优先怀疑机柜电源、背板或批量盘问题，而不是单盘故障。

想看单盘详细信息：

showpd -i

里面包含盘位、序列号、固件版本、转速、容量，还有SMART相关计数。换盘前必须用showpd -i拿到准确盘位（柜号、pos、bay号），别拿错备件白跑一趟机房。

再看逻辑盘：

showld -s

LD状态重点关注是不是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监控阈值参考表

结合实际环境，把命令总结成一张可直接参考的阈值表：

这组阈值来自我们生产环境大量正常和故障数据分析，不是拍脑袋定的。不同业务模型会有差异，建议先跑两周基线，把阈值调成自己环境的版本，再用于告警。

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留档，下一次对比增长率，比当场看绝对值有效得多。

流量统计用portstatsshow：

portstatsshow

它给出每个端口的帧数、字节数、丢弃和错误。这个命令在分析端口利用率、判断链路是否被某台主机打满时很有用。大促之后回看portstatsshow，会发现某些F_Port吞吐接近端口上限，这时就要考虑给这条主机链路加多路径或扩带宽。

3.3 portshow与光模块收发光检查

porterrshow的CRC或Sync Loss持续增长时，下一步要检查物理层，先看单端口详情：

portshow <端口号>

这个命令看端口状态、实际协商速率、连接WWN、各项错误计数汇总。

光模块收发光功率检查更直接。类FOS风格设备一般可以用portshow的optics相关子命令看Rx Power、Tx Power；Comware风格对应的命令是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那套一起用的：

4. 监控命令集的自动化落地：脚本化采集与告警闭环

4.1 为什么不能只靠人工敲命令

命令写得再全，靠人肉每天敲总会有遗漏，尤其是凌晨故障和多人交接的时候。真正稳定可靠的监控，是让命令在固定时间自动执行、自动对比、自动抛出告警。但我要先泼一盆冷水：不要在还没建立基线数据的时候写告警规则，否则你会发现满屏误报，最后团队对告警脱敏，真正的故障反而没人关注。

我的落地步骤分三步：

1. 先人工跑两到三周，把每台设备的正常输出存档，建立基线；
2. 写采集脚本，把命令输出统一落地成带日期的文件，纳入日志管理；
3. 写判定逻辑，基于基线和阈值产生告警，再接入通知渠道。

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_ADDR=3par-mgmt-ip LOG_DIR=/data/monitor/3par/$(date +%F) mkdir -p $LOG_DIR run_cmd() { ssh -i $SSH_KEY -o ConnectTimeout=10 -o StrictHostKeyChecking=no \ 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 fi

CF22030的采集脚本类似，换成FC交换机的命令集合：

#!/bin/bash # H3C CF22030 daily fabric check SSH_KEY=/home/monitor/.ssh/id_rsa SWITCH_ADDR=fc-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 ConnectTimeout=10 -o StrictHostKeyChecking=no \ 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，可以考虑直接走SNMP：

• 3PAR 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 monitor@3par-mgmt showalert -status open

输出里能看到那条degraded告警，级别为Major，子系统是Disk，发生时间在当天17:45左右。接着跑：

showpd -s

找到盘位后确认状态列显示degraded，SMART相关计数有异常。再跑：

showld -s

确认这块盘所在LD的状态还是complete，也就是RAID冗余还在、数据没有丢，只是有进一步恶化的风险。

showvv -s和statvv看了业务卷，卷状态正常，延迟略微升高。存储端结论是：存在单盘隐患，但当前不构成必须立即强制换盘的紧急条件，可以申请维护窗口更换。

5.3 FC链路定位：portshow与porterrshow

存储端判断完之后，回头看CF22030。登录交换机：

porterrshow

CRC错误在目标端口增长得相当明显，看历史记录，这个端口的错误计数在过去两个小时持续增加，不是一次性抖动。再跑：

portshow <端口号>

确认端口状态Online、协商速率正常，但物理错误计数在涨。拔下光纤看光模块接口，明显看到一根跳线有弯折痕迹，收光功率掉到接近下限。

这就暴露了问题：那根跳线布线时预留长度不够，机柜理线时被拉成了死弯，光信号持续劣化。白天业务负载不高不明显，晚高峰流量一上来，误码快速增长，主机多路径检测到链路质量下降，触发路径切换。

5.4 根因确认与处理

最终确认是两件事叠加：

• 物理层：FC交换机到主机之间的光纤跳线劣化，导致链路误码和路径切换；
• 存储层：3PAR C630上存在一块degraded磁盘，属于独立硬件隐患。

处理顺序上，先处理物理链路。换跳线后，porterrshow的错误计数停止增长，主机多路径恢复。磁盘在当天夜间维护窗口更换，换盘后showpd -s确认新盘状态为normal，showld状态保持complete，流程结束。

5.5 这次排障沉淀的几条经验

这次故障对监控体系影响很大，我沉淀了几条关键经验：

• 告警要“两端对表”。存储端有问题时，同时看FC交换机和主机HBA侧指标，经常能发现真正的物理路径问题；
• 换盘前先看LD状态和业务影响。degraded但LD complete不等于马上要处理，先评估窗口；但CRC增长是实时性能问题，优先级更高；
• 每次处理后把命令输出留档。后来给两台设备都建了输出基线库，下次判断先和上一轮数据对比，误判率明显降低；
• 自动化脚本里一定要有物理链路指标。如果当时只监控存储端的showalert，链路劣化可能要拖到完全断链才会被感知。

这次之后，我把CF22030的porterrshow增量检查加进了日巡检自动化，3PAR的磁盘状态检查也改成每次showpd -s都对比上一轮输出。现在再遇到类似的“存储加FC”组合故障，值班人员的第一反应已经不再是“要不要去机房”，而是先按命令集把两端数据拉出来，把问题定位到具体层再动手。