岗位上待久了你会发现存储巡检这事最难的不是不会敲命令而是不知道哪些命令组合在一起能反映整台设备的真实状态。今天把我自己整理的 HPE_3PAR C630 主控配 H3C CF22030 扩展盘柜的监控命令集拿出来从日常巡检到故障定位一次说清楚适合正在做存储运维、刚接手 3PAR 环境或者准备做存储监控脚本的同行参考照着敲就能用。这套组合在中小型数据中心里很常见C630 负责控制器的计算和主机端口CF22030 作为磁盘扩展柜提供盘位容量两者通过 SAS 链路连接。很多朋友以为监控重点在 C630 的控制器其实盘柜侧的温度、风扇、电源才是最容易出大事的地方。下面的命令集按巡检顺序展开每一条我尽量说清为什么看这个字段、什么状态算正常。1. 认清这套组合C630 主控加 CF22030 盘柜的监控边界1.1 登录方式和命令前置知识3PAR 的命令行入口不是普通 SSH 到 Linux 那种而是通过ssh 3paradm管理IP进入登录后是cli%提示符。整套监控命令集基本都走show、stat两个前缀前者看静态状态后者看动态性能。我在实际运维中建议直接用 SSH 批量执行而不是进交互式 CLI 再慢慢敲因为输出量大容易翻页卡住。需要记住一个原则3PAR 的命令输出默认是分页显示的在交互式会话里如果输出内容超过一屏会卡住等待输入。写自动化脚本时一定要避免这种模式批量采集时用ssh 3paradmIP 命令直接执行输出到本地文件即可。这个细节我后面会专门讲。1.2 监控范围怎么划分这套组合的监控范围要分成三层来看控制器层C630 的两个控制器、内部缓存、主机端口、后端 SAS 链路。盘柜层CF22030 的电源、风扇、温度、SAS 级联状态、盘位状态。数据层物理磁盘PD、逻辑磁盘LD、虚拟卷VV、主机映射VLUN。很多运维新人容易犯的错误是只盯着showpd看磁盘状态忽略了showcage、showtemp、showfan这些硬件健康检查命令。存储硬件故障的链条往往是风扇转速异常导致温度升高温度升高加速磁盘老化最后表现为某块盘degraded。如果只等磁盘报错才处理往往已经晚了。下面我按巡检顺序把每层的关键命令拆开讲。2. 日常巡检命令先看系统、告警和物理盘2.1 系统级状态showsys、showversion、showalert开机器之前先确认系统整体状态。第一优先级是showsys和showalert。cli% showsys -i cli% showalert cli% showalert -vshowsys -i能看到系统名称、系统类型、序列号、节点数量、缓存大小、软件版本这些基础信息。日常巡检重点看状态字段是否为正常的normal如果出现degraded或系统量化为只读说明系统级有严重问题业务 IO 可能受影响。showalert是 3PAR 的工作日志会在页面上直接列出问题严重级别、时间、节点和描述。这个命令应该是每天开机的第一道检查项。遇到严重告警如Critical、Major要先看Minor和Info级可以记录后按计划处理。用showalert -v能看告警的完整描述和影响范围比只看缩略信息更可靠。我这里有个实操习惯每天用脚本把showalert输出落盘按日期归档。这样不但能回溯告警产生时间还能判断告警是间歇性出现还是持续存在。比如某些盘柜链路告警只在搬家或换线后出现单纯看当天输出很难发现规律。2.2 物理盘状态showpd 的关键字段磁盘是存储最脆弱的环节showpd必须每天看。cli% showpd cli% showpd -s cli% showpd -i裸执行showpd会列出所有物理磁盘的 ID、位置Cage 和 Slot、类型、容量、状态。输出里的normal、degraded、failing、offline这几个状态要分清楚normal正常不需要动作。degraded磁盘出现坏块或校验异常但仍在线工作。failing磁盘被判定为即将故障系统会尝试做热备替换或 RAID 重建。offline磁盘离线不可用如果是数据盘涉及冗余度一定要重视。showpd -s输出的是容量摘要我一般用来快速确认系统整体容量余量。showpd -i则更详细每块盘会多出磨损度、RAID 重写信息等字段。刚工作那会儿我不理解为什么有些盘状态明明normal但盘位上的报警灯在闪后来看了showpd -i的磨损和重写字段才明白某些盘正处于后台 RAID 重写流程中这时候不要去拔盘。判断这块盘是不是真的故障建议结合showpd -i里的RW字段重写次数和Degraded字段一起看。我遇到过不少次单看showpd状态是normal但RW数值持续增长盘片内部正在频繁做重写这种盘虽然还没下线也应该列入更换计划。3. 盘柜硬件健康检查CF22030 温度、风扇、电源一个不能少3.1 用 showcage 查盘柜整体状态CF22030 这类扩展盘柜在 3PAR 里是通过showcage来查看的它没有一个单独的管理 IP所有传感器状态都由主控 C630 收集。cli% showcage cli% showcage -vshowcage会列出系统中所有盘柜Cage的编号、是直连还是级联、SAS 链路状态、盘柜电源和风扇聚合状态。正常的盘柜状态显示为ok如果有异常会显示degraded或failed。特别注意showcage -v里每个盘柜的级联路径。3PAR 后端链路是双路径的如果某一条链路断掉盘柜可能还能正常工作但冗余已经没了。这种状态下如果再坏一根线整个盘柜都会掉线。所以看盘柜状态不能只看电源和风扇还要看后端路径是不是两条都在线。3.2 电源模块、风扇和温度怎么判断cli% showps cli% showfan cli% showtemp这三个命令是硬件健康三重奏巡检时建议一起执行。showps输出电源模块状态正常为up或ok异常会出现down、failed。CF22030 盘柜一般有双电源模块我最担心的是那种显示一块电源正常另一块报异常的现场这时候系统还在正常运行但已经失去了电源冗余。如果恰逢机房断电或上游电路波动掉电风险会成倍增加。showfan看风扇转速状态正常为normal。有些盘柜风扇出现问题时转速下降是渐进的不是一瞬间从normal变failed。我遇到过风扇转速偏低但状态还没报错的场景温度传感器已经比平时高了 3 到 4 度。这种早期信号如果不记录等到温度告警出来故障往往已经持续一段时间。showtemp看温度信息包括控制器的 CPU 温度和各个盘柜的温度。不同型号温度阈值略有差异但我一般以 40 度以下为健康基线超过 45 度就要开始关注散热风道超过 50 度基本确认有风扇故障或机房空调问题。温度是磁盘故障的重要诱因CF22030 作为盘柜对温度更敏感里面的硬盘长期在高温环境下运行故障率会明显上升。3.3 盘位与磁盘定位cagepos 怎么对应物理槽位用showpd看到某块盘报failing后现场操作员要找到物理盘位置就需要理解盘位编号。3PAR 的位置信息一般用CagePos表示例如0:1:2意思是 Cage 0 的 Magazine 1 的 Slot 2。在 CF22030 这种盘柜上要注意盘位是从左到右还是从右到左编号不同代际的盘柜规则不一致。现场最稳妥的办法是沿着盘柜的面板标签把盘位号和 3PAR 输出的编号逐一对上。我吃过亏有一次按showpd的 CagePos 把盘抽出来发现位置对不上因为该盘柜盘位编号是 0 起始而面板标签从 1 开始。所以巡检记录里一定要写清楚编号规则最好贴一张在盘柜门内侧避免拔错盘。拔错盘的后果很严重一旦误拔冗余组里的盘最坏情况是直接触发数据不可用。4. 性能监控命令集不会看统计字段等于白查4.1 性能统计三件套statpd、statld、statvv性能问题排查比状态巡检复杂3PAR 提供了一组stat命令用于性能数据采集。我把它叫性能三件套物理盘维度、逻辑盘维度、虚拟卷维度。cli% statpd -i 2 -c 5 cli% statld -i 2 -c 5 cli% statvv -i 2 -c 5-i是采样间隔秒数-c是采样次数。上面的例子是每隔 2 秒采样一次共采样 5 次。采集完成后输出会列出每个对象的 IOPS、吞吐量KB/s、平均响应时间ms等字段。分析性能瓶颈的正确顺序是先看物理盘statpd有没有到达性能上限再看虚拟卷statvv哪些卷在大量读写最后反查这些卷对应的主机和业务。很多人一上来就看statvv发现某个数据库卷响应时间很高然后直接下结论说存储慢。实际上可能是这个卷下面正好有坏盘导致了高延迟如果不落到statpd上看很容易抓错重点。4.2 响应时间多少算异常3PAR 的性能输出里响应时间是个关键指标。物理盘的平均响应时间在机械盘上通常维持在 3 到 10 毫秒超过 20 毫秒说明负载偏高全闪配置则应该稳定在 1 毫秒以下。如果看到某块盘的响应时间突然从 5 毫秒跳到 40 毫秒大概率是盘片在重写、故障转移或者有慢盘拖累。还有一点容易被忽略statpd里的Busy字段表示磁盘繁忙度正常应该在 60% 以下。磁盘达到 100% 繁忙不一定是业务量太大也可能是单块盘坏道导致重试加剧。我在排查时如果看到某块盘 Other 类命令占比高会优先怀疑这块盘有物理问题而不是扩容的问题。4.3 性能采集注意事项性能采集不能只跑一次尤其是间歇性性能问题必须拉长采样周期。建议至少采集 5 分钟以上才能看到高峰段。我一般跑statvv -i 5 -c 60持续 5 分钟然后对比业务高峰时间段的波形。另外注意stat命令本身也会增加一定的系统开销不要在生产高峰期长时间高频采集。采集间隔低于 1 秒、持续几十分钟这种操作对正在跑业务的生产存储会有影响。日常监控建议间隔 5 秒以上真的遇到故障需要细粒度分析时再临时缩短到 2 秒。5. 逻辑资源与映射监控LD、VV、VLUN 的关联分析5.1 showld逻辑磁盘状态怎么看物理盘之上是逻辑磁盘LD它是 RAID 组在 3PAR 里的实际载体。cli% showld cli% showld -i cli% showldchshowld列出所有 LD 的 ID、名称、所属 CPG、RAID 类型、总容量和已用容量。重点关注状态字段是否为normal。如果出现degraded说明这块逻辑盘下面的物理盘有故障虽然业务可能没感知但冗余已经发生变化要及时安排处理。showldch是逻辑盘变更日志专门记录 LD 的创建、扩展、删除、状态变更。这个命令在故障回溯时非常有用。比如某天凌晨数据库突然变慢通过showldch能倒查是否有人在这段时间创建了大容量 LD 导致后台资源抢占。5.2 showvv 与 showvlun卷和主机映射的检查逻辑虚拟卷VV是最终呈现给主机使用的存储空间VLUN 则是主机与 VV 的映射关系。cli% showvv cli% showvv -v cli% showvlun cli% showvlun -tshowvv常规输出能看到卷名称、状态、所属 CPG、使用量、共享/独占类型。showvv -v能看到更详细的卷属性包括是否启用了快照和数据压缩。日常巡检关注状态是否为normal以及卷容量使用率是否接近上限。showvlun看主机与卷的映射输出包括主机名、VV 名称、LUN ID、端口类型FCP 或 iSCSI、状态。这里我特别关注映射是否有多路径遗漏。比如一台主机开了 4 条光纤通路结果某个 LUN 只映射了 2 条路径主机端看就是 multipath 有一条 path 处于 degraded疲劳度不均可能导致性能下降。5.3 发现问题后的关联分析方法光看单条命令往往不够需要关联起来才能定位。我通常的做法是用showvlun查出某主机的所有 LUN 映射用showvv反向查这些 LUN 对应的 VV 名称用showld查这些 VV 落在哪个 LD / RAID 组用showpd查这个 LD 覆盖的物理盘范围。这样一层层剥下去主机上的 IO 延迟问题最终会落到具体物理盘上。我有一次帮客户排查 Oracle RAC 偶尔出现节点驱逐的故障最后就是靠这种关联分析发现两个 ASM 磁盘组的部分 PD 落在了同一块故障盘上迁移了对应 VV 后才彻底解决。6. 巡检脚本与遗留记录把监控命令变成自动习惯6.1 用 SSH 免交互跑批量命令手敲命令巡检容易漏项尤其晚上值班时人困马乏。建议把整套命令集固化成脚本每天自动执行。因为 3PAR 的 CLI 走 SSH可以用带expect的脚本或密钥认证方式执行。下面是一个简化示例用expect自动登录并收集关键状态#!/usr/bin/expect set timeout 30 spawn ssh 3paradm192.168.1.10 expect { password: { send YOUR_PASSWORD\r } Password: { send YOUR_PASSWORD\r } } expect cli% send showsys -i\r send showalert\r send showpd -s\r send showcage\r send showps\r send showfan\r send showtemp\r send statvv -i 2 -c 3\r send exit\r expect eof如果你的机房网络策略允许更推荐配置 SSH 密钥登录这样就不再依赖expect里的明文密码脚本也更稳定。3PAR 官方对 SSH 密钥的支持在部分版本里有限制配置前先确认版本号。还有一种方式是使用 3PAR 的 REST API推荐新版本但 CLI 在任何版本都能用兼容性更好对于监控脚本来说足够了。6.2 输出落盘和阈值提醒光收集不判断没有意义。脚本把输出存到本地后建议再用grep或简单的文本匹配做告警判断。比如检测输出中是否有failed、degraded、offline关键字一旦出现就往监控平台推送消息。下面是我在用的一个简易判断逻辑片段脱掉了具体告警通道后大概是这个样子#!/bin/bash OUTPUT$(expect /path/to/collect.exp) echo $OUTPUT /var/log/3par_$(date %F).log if echo $OUTPUT | grep -E failed|offline|Critical ; then echo 3PAR critical alert on $(date) | mail -s 3PAR ALERT opsexample.com fi注意 3PAR 命令输出里带空格和表格线直接对整段文本做grep时可能出现误报。我的经验是先拿到纯状态列比如用showpd -s后提取某个状态字段再判断而不是对整页输出做关键字匹配。6.3 巡检记录该留多久存储巡检日志建议最少保留一年。这是因为磁盘故障有很强的周期性规律一年的记录能帮你判断当前盘柜是否进入故障高发期。CF22030 这类盘柜里的机械盘在运行到第三到五年以后故障率会明显上升通过历史showalert和showpd -i记录你可以提前制定换盘预算和窗口。别小看这些零散的命令输出关键时刻它能帮你回答“这块盘什么时候开始有问题的”“上次出现同类告警是什么时候”这种管理层最关心的问题。7. 常见故障排查实录从命令输出到决策动作7.1 现象一盘片显示 failing但现场盘位灯不亮这是我处理过很多次的状况。showpd显示某块盘failing但现场看盘柜面板没有任何故障灯。原因是 3PAR 对失败的判定比硬件指示灯更敏感到达一定错误阈值就会标记failing而盘柜硬件本身的报警灯可能由更低级的控制器逻辑控制两边判定标准不一致。正确做法是以showpd -i的输出为准不要因为灯没亮就认为没有故障。如果failing状态持续存在而且该盘被标记为可替换就可以安排在线换盘。换盘确认前最好用showpd -s检查热备盘状态确认有可用热备再动盘。7.2 现象二盘柜温度升高但风机显示正常前面我提过风扇和温度要一起看就是因为有风机状态正常但温度已经偏高的情况。排查步骤是用showtemp确认温度是持续升高还是瞬时波动用showfan核对所有风扇实际转速重点关注转速值而不只是状态字段到现场检查盘柜前后风道是否被堵大部分盘柜的进风口都在前面板下方最容易堆灰尘检查同一机柜里其他设备是否也发热异常排除机房空调故障。如果温度持续偏高且风扇全速运行说明风扇已经在尽力散热但环境温度过高。这时候即使状态显示 normal也应该按照环境问题上报别等showalert报high temperature才干预。7.3 现象三某卷延迟高但不是物理盘的问题有次客户的 Oracle 数据库卷延迟持续偏高我按流程查了statpd物理盘响应时间完全正常后来通过statvv对上号的卷才发现问题出在卷上同时挂了一个测试环境的备份任务备份流量通过主机侧和数据库流量混在了一条路径上。存储本身没扛不住是主机端带宽分配不合理。这类问题从命令集的角度来复盘就是物理盘正常不代表端到端路径正常。还要结合statport看主机端口是否拥塞结合主机侧 multipath 看链路负载是否均衡。监控命令集只是一部分排查链路问题要前后端一起看。7.4 现象四有告警但不知如何处理showalert输出的告警不一定都需要立刻操作。我的处理优先级是告警级别实例响应动作Critical控制器故障、盘柜链路断立即处理通知应用方Major磁盘 failing、电源故障尽快处理安排换盘或维修Minor温度略高、风扇转速偏低观察记录当天处理Info配置变更、登录记录记录归档无需响应3PAR 的告警信息大部分能在官方知识库里查到但记下这个级别对应关系基本够用。真正遇到没把握的告警先别急着 dismiss建议保留 24 小时再清理万一后续故障定位需要原始告警佐证你至少还能找回记录。7.5 换盘操作前的三条规则最后说说换盘这个避不开的操作。刚才讲了要看showpd -s确认热备状态这里再补三条我积累的规矩第一拔盘前必须再次确认盘位号别只信一次输出。换盘全程周围有其他设备在震动或搬运时我见过有人对照着错误标签拔了旁边的盘。第二拔盘动作要快拔出来后新盘插进去之前别离开现场。第三换盘后观察showpd返回normal状态并且确认 RAID 重建没有异常报错再离开重建过程期间不要碰同 RAID 组里的其他盘。这几点看着基础但每次事故复盘都能翻出来。存储巡检和换盘说到底拼的不是操作有多炫而是每一步都做了确认和记录。我个人实际用下来觉得这套 C630 加 CF22030 的监控命令集覆盖日常巡检、性能分析和故障定位已经足够关键是形成一个固定的执行习惯。哪怕只是每天早上看一眼showalert和showpd -s也比出了一堆 alert 没人看强得多。等这套命令用顺了再往脚本化、告警联动和容量预测方向扩展监控体系自然就完整了。