存储巡检命令行实战：3PAR与H3C CF22030监控命令集

机房夜班最怕什么不是交换机闪灯不是服务器风扇狂转而是存储阵列在你手机还没响的时候先响了。我手里管着两台颇有代表性的中端存储——一台HPE 3PAR C630一台H3C CF22030一个外资品牌的老将一个国产全闪的新锐。今天把这两台设备这些年用下来的监控命令集整理成文希望能帮同样要伺候这两类存储的朋友少走弯路。这套命令集解决的就是存储运维里最核心的三件事容量还够不够、磁盘有没有坏、控制器和端口状态正不正常。覆盖日常巡检、故障定位、自动化采集三大场景。刚接手存储的新人可以照着命令敲一遍老运维则可以拿走改造自己的巡检脚本。1. 先摸清家底这两台存储到底在机房干什么1.1 一台块存储老将一台国产全闪新锐HPE 3PAR C630是3PAR中端产品线里的主力型号也是很多人接触3PAR的第一台设备。它的核心优势在于硬件ASIC加速和小颗粒度chunklet数据分布机制。传统存储做RAID是把一整块盘绑进一个RAID组3PAR会把每块盘切成很小的chunklet再均匀打散到所有磁盘上所以它的热点分布比传统阵列均匀得多。C630支持FC、iSCSI、NAS等多种协议混合负载场景下表现很稳虚拟机、数据库、文件共享都能扛。H3C CF22030则完全是另一个路数。它是H3C UniStor CF22000系列里的全闪阵列型号里的30一般对应容量档位或者盘位规模。全闪配置让它在高IOPS场景里有天然优势尤其适合数据库在线日志、容器平台、VDI这类对响应时间敏感的负载。最近几年国产化替代需求多CF22030在政企、金融、教育行业的出场率明显上升。这两台设备的定位和监控逻辑其实不一样。3PAR C630我更多担心的是机械盘老化、RAID重构、chunklet分布是否均匀CF22030是全闪反而更关注SSD磨损寿命、控制器瓶颈和光纤链路协商速率。所以监控命令虽然都叫“看状态”但看的东西侧重点完全不同。对比项HPE 3PAR C630H3C CF22030产品定位中端混合存储中高端全闪阵列介质类型传统机械盘/SAS SSD混插全SSD/NVMe核心架构chunklet打散ASIC加速全闪控制器架构典型负载虚拟化、数据库、文件共享高IOPS数据库、VDI、容器监控重点磁盘状态、RAID重构、容量水位SSD寿命、控制器CPU、链路速率1.2 存储监控为什么不能只靠看灯存储设备有个特点它是“慢变量”设备。服务器出问题往往是即时的比如宕机、死循环、内存溢出一台机器挂了影响的是单点业务。但存储不一样一块磁盘从出现坏道到彻底fail可能持续几周甚至几个月控制器内存从频繁纠错到真正报错也是一点点劣化的过程。这个过程中数据可能已经在悄悄处于危险状态。所以存储监控的关键是“把慢变量变成可观测的趋势”。你需要在故障真正发生之前看到磁盘错误计数在上涨、控制器CPU使用率在爬坡、容量水位在逼近阈值。这也是为什么命令行监控比Web界面更值得依赖——Web界面适合单次查看但命令行的输出格式统一、字段明确方便脚本化采集、历史化对比。1.3 命令集的三条主线我整理监控命令时习惯分成三条主线后面所有命令都按这个逻辑组织状态类命令回答“现在有没有问题”。比如告警查看、磁盘状态、控制器状态、端口状态。性能类命令回答“现在快不快”。比如IOPS、带宽、时延、CPU占用率。空间类命令回答“还能撑多久”。比如卷容量、池容量、chunklet使用情况。这三条主线分别对应存储运维的三个核心问题安全、效率、容量。日常巡检按这三条线走一遍基本能把存储的健康状况摸个八九不离十。2. 3PAR C630这套命令背下来日常巡检就稳了2.1 登录方式和权限控制3PAR的CLI登录方式很简单SSH到存储管理IP默认端口22用户一般是3paradm或者单独创建的只读用户。登录后直接进入CLI界面不需要像网络设备那样再输入enable进入特权模式。对于已经熟悉Cisco或H3C网络设备的人来说这个设计反而要小心——没有模式隔离意味着你在普通会话里也能敲出配置类命令。我的建议是严格区分账号用途。日常巡检单独创建一个只读账号比如monitor_c只授权show类命令权限。运维操作再用3paradm主账号。这样就算巡检脚本逻辑写错了最多也就是多看几遍输出不会把生产配置搞坏。3PAR的权限体系可以做到命令级授权这个能力别浪费。登录后有几个实用习惯可以养成。第一先用showalert看全局告警这是所有巡检动作的第一步。第二用showversion确认当前固件版本很多命令输出字段在不同版本间有细微差异知道版本才能正确解读。第三准备退出前用showhealth或者showservicestate整体扫一遍作为快速体检的收尾。2.2 第一优先showalert看告警showalert是3PAR监控里含金量最高的一条命令建议每天第一次登录先敲它。它会列出所有硬件和系统告警输出包含告警ID、状态、严重级别、发生时间、代码和消息描述。输出里有两个字段需要特别重视。第一个是State取值一般是New、Ack、Sev三种。New表示告警还没被任何人确认Ack表示已确认但还没解决Sev表示当前仍然处于严重状态。第二个是Severity从轻到重大致是Info、Warning、Minor、Major、Critical、Fatal。真正需要立即处理的是Critical和Fatal级别的告警以及所有New状态的新告警。# 查看所有告警 showalert # 只看新告警 showalert -f new # 按严重级别过滤数字越小越严重不同版本参数略有差异 showalert -p 3实际巡检中我不建议只敲一条裸的showalert然后盯着屏幕看因为告警多了以后输出非常长。更实用的做法是配合过滤参数先看新增的、再看严重的。如果showalert -f new输出为空说明从上一次确认以来没有新问题这一天的心可以放下大半。这里有个经验之谈3PAR的告警尤其是磁盘相关的很多是“提示性”的而非“故障性”的。比如某块盘出现几个坏块系统会报Minor告警但它会通过内部机制把数据重映射到备用区域。所以看到Minor级别磁盘告警不用立刻准备换盘但需要持续观察错误计数是否在增长。真正到了Major级别才需要进入换盘流程。2.3 磁盘健康是命根子showpd与showpd -s磁盘是存储里最脆弱也最容易被量化的部件。3PAR里查看磁盘状态的核心命令是showpd它会列出每块物理磁盘的详细信息包括磁盘ID、所在笼位、状态、类型、转速、容量、已分配容量等。State字段是重点中的重点常见取值有normal、degraded、failed、absent。normal是正常failed是彻底故障absent是物理上检测不到磁盘。这里特别要提醒degraded这个状态它不直接等同于坏盘而是表示这块盘的数据完整性和可用性受到了影响。可能是出现了坏道也可能是某个chunklet读写异常。遇到degraded的第一反应应该是确认原因而不是直接拔盘。# 查看所有物理磁盘状态 showpd # 查看系统总体容量裸容量汇总 showpd -s # 查看磁盘初始化/重构进度新增盘后必看 showpd -ishowpd -s输出的是整个系统的裸容量汇总包括总容量、已分配容量、空闲容量。这条命令适合每天早上快速确认“空间有没有突然掉一大块”。如果昨天看总空闲还有20%今天突然变成10%那大概率是有卷在做快照或者有大批量数据写入需要进一步定位。还要学会看showpd输出里的Degrade列。正常情况下这块应该全是0只要出现非0值说明有chunklet处于降级状态底层数据分布已经受到影响。巡检时如果发现Degrade列有数字配合showalert看有没有对应告警基本能确定问题方向。2.4 卷和逻辑盘showvv与showld联动排查3PAR存储里用户看到的是虚拟卷VVVV底层由逻辑磁盘LD构成LD再落实到具体的chunklet。这个三层架构是3PAR和传统存储最大的区别也是排查问题时最容易绕弯的地方。showvv查看虚拟卷状态。重点关注Prov字段它标记这个卷是TPThin Provisioning精简配置还是FPFully Provisioned完全配置。精简卷的空间是动态分配的实际使用量可能远小于显示容量。另一个关键字段是V-Statenormal是正常状态如果看到rare、base_only这类非正常状态说明底层LD可能存在数据不完整的情况。showld则往下看一层查看逻辑磁盘的状态。LState字段有complete、initializing、modifying等取值。complete表示正常initializing说明正在初始化modifying说明正在做RAID类型调整或扩容。如果LD长期停留在非complete状态比如一直initializing不结束就需要深入排查了。# 查看所有虚拟卷 showvv # 查看虚拟卷详细空间使用 showvv -sp # 查看逻辑磁盘状态 showld实际排障中VV和LD要联动看。比如业务反馈某个卷性能突然下降showvv看V-State正常但showld发现对应LD正在modifying那性能下降大概率是底层数据重构导致的属于正常现象只是需要告知业务方忍耐一段时间。反过来如果showvv状态异常而showld正常问题往往出在卷配置或映射层面和物理盘无关。2.5 端口、主机和映射showport/showhost/showvlun存储和主机之间是通过端口和映射关系连起来的。主机报“看不到存储卷”的时候很多人第一反应是去查Zoning但其实存储侧的三条命令就能帮你快速定位问题。showport查看端口状态包括FC端口和iSCSI端口。Ready字段是yes还是no直接决定链路通不通Speed字段看协商速率是否符合预期。如果端口显示no后端主机那边再怎么做Zoning也看不到盘。另外3PAR有“主机端口”和“磁盘端口”之分查链路时别只盯着一类看前后端端口都要过一遍。showhost显示主机信息包括主机名、WWN号、操作系统类型。当服务器换了HBA卡或者做了双机切换WWN会变化此时showhost里记录的主机信息可能已经过时映射关系就会对不上。showvlun则查看虚拟卷和主机之间的映射关系输出会告诉你哪个VV映射给了哪个主机对应的LUN ID是多少。# 查看端口状态 showport # 查看主机信息 showhost # 查看LUN映射 showvlun我排查主机看不到盘的顺序通常是先showvlun看映射在不在再showport看端口up不up最后showhost确认主机WWN有没有变化。这三个命令按顺序走一遍90%的“找不到盘”问题都能定位到具体环节。2.6 性能类命令statcpu/statport/statvv存储性能排障和服务器不一样不能光看CPU和内存更要关注存储内部的数据路径。3PAR的性能命令以stat开头含义是“统计”和show类命令的“状态查看”是两码事。statcpu查看控制器的CPU使用率它会显示每个控制器的实时和历史负载类似Linux下的top命令输出。如果某个控制器CPU长期跑满说明压力不均或者有异常负载需要进一步下钻。statport按端口维度统计IOPS、吞吐量、队列深度。这条命令可以用来判断链路是否成为瓶颈。比如主机侧业务卡顿但statport显示端口带宽已经打满那瓶颈就在链路而不在存储本身。statvv则按照虚拟卷维度统计性能能直接看出到底是哪个业务卷消耗了最多的IOPS和带宽。这是定位“存储慢是谁拖的”最有用的命令。# 查看控制器CPU使用率 statcpu # 查看端口性能统计 statport # 查看卷性能统计 statvv # 查看缓存命中率 statcache使用性能命令有个注意事项它们本身会消耗系统资源。虽然这个开销通常很小但在业务高峰期反复长时间跑性能统计还是会造成额外负担。我的习惯是采样几轮拿到趋势数据就停不持续挂在那里刷屏。另外性能数据要看历史趋势才有意义单次的瞬时值说明不了太多。所以如果要长期留存建议脚本化定期采集并归档。2.7 容量规划showvvspace与showpdch容量监控是存储运维里最“常态化”的工作也是规划性最强的一部分。3PAR的容量命令看起来很基础但用好了能避免很多“临时抱佛脚”的扩容操作。showvvspace按卷展示空间使用详情包括卷大小、已使用空间、保留空间、快照占用等。重点关注Rsvd字段它代表这个卷实际占用的物理空间。对于精简卷来说Rsvd才是真实成本VSize只是逻辑上限。如果某个卷的Rsvd接近VSize说明这个卷即将写满需要提前扩容或者清理数据。showpdch查看chunklet的分布情况。chunklet是3PAR的数据分布单元了解chunklet分布能判断底层数据是否均匀。如果大量chunklet集中在某几块盘上那么这几块盘的负载会远高于其他盘形成热点。# 查看卷空间使用 showvvspace # 查看chunklet分布 showpdch # 查看系统整体空间汇总 showspaceshowspace是容量报表的核心来源它把系统总容量、已用容量、可用容量汇总在一张表里。做季度容量规划的时候直接拿showspace的历史数据进行趋势分析比逐卷加起来靠谱得多。容量规划的核心思路是“看趋势不看绝对值”单周的数据说明不了问题连续两个月的下降斜率才是扩容决策的依据。3. H3C CF22030监控命令国产全闪的巡检套路3.1 登录方式顺带澄清一个常见误区H3C CF22030属于H3C UniStor存储产品线。这里必须先澄清一个很多朋友容易混淆的点很多人因为H3C这个品牌习惯性拿它和H3C交换机路由器的Comware命令体系去套这是不对的。CF22030是存储阵列不是网络设备登录方式、命令体系、管理思路都和网络设备完全不同。登录CF22030通常有三种方式。第一是SSH到存储管理IP在命令行下执行监控命令第二是登录存储Web管理界面图形化查看状态第三是通过带外管理HDM口查看硬件层面信息。日常巡检我最常用的是SSH命令行因为输出格式统一方便脚本采集。我现场这台CF22030固件版本的CLI命令大部分以show开头下面涉及的命令均以该版本为例。不同版本之间有细微差异拿不准的时候先敲help或者?查看命令补全列表这个习惯比死记命令本身更值钱。3.2 系统状态和告警第一时间知道存储是否降级CF22030巡检的第一条命令是查看系统整体状态。存储和服务器不一样它最怕的不是单部件故障而是“降级运行”。控制器故障后剩下一个控制器硬扛所有业务这个状态下性能会明显下降而且恰好在这个时间点再坏一个控制器整个存储就会停摆。# 查看系统整体状态确认控制器节点角色 show system status # 查看系统告警 show alarm # 查看历史事件记录 show eventshow system status输出控制器状态、节点角色、HA状态等信息。正常情况下两个控制器都是active状态一主一备或者双活。如果看到某个控制器状态是failed或者offline说明存储已经进入降级运行模式需要立即处理。show alarm和3PAR的showalert作用类似列出所有告警。重点关注Critical级别的告警以及出现了但还没确认的New告警。show event则能查看历史事件比如控制器切换记录、磁盘插拔记录。排查问题时先翻这个很多时候能把故障时间线拼出来。3.3 磁盘状态和SSD寿命全闪存储的独特挑战CF22030是SSD全闪配置所以磁盘监控的重点和机械盘阵列完全不同。机械盘怕坏道SSD则怕磨损和高温。温度过高会加速SSD老化频繁写入会消耗PE寿命。所以全闪存储的磁盘巡检除了看状态还要看寿命。# 查看磁盘列表和状态 show disk # 查看磁盘健康信息和SSD寿命 show disk -s # 查看RAID组状态 show raidshow disk列出所有磁盘的型号、容量、状态。状态字段正常应该是online或者normal出现degraded、failed就需要告警升级。show disk -s能看到SMART信息包括磨损度Wear_Leveling_Count、媒体磨损指示Media_Wearout_Indicator、重定位扇区数、温度等。这里要特别提醒全闪阵列换盘不像机械盘那样可以从“有没有异响”来辅助判断SSD坏了往往就是毫无征兆地从online变成failed。所以SSD寿命数据一定要主动盯等它彻底挂了再处理你就已经处于被动位置了。我一般以70%寿命作为警戒线到线就开始准备备件低于50%就列入月度重点观察。3.4 存储池和卷容量水位的正确视角全闪存储的容量管理比机械盘阵列更微妙。SSD写入有放大效应容量使用率越高GC垃圾回收越频繁性能劣化越明显。所以全闪阵列的容量阈值要设置得比机械盘更保守不能等满了再扩。# 查看存储池容量 show pool # 查看卷状态和容量 show volume # 查看LUN映射 show lun # 查看主机信息 show hostshow pool展示存储池的容量、已用空间、剩余空间。容量水位一般建议保持在80%以下如果超过85%就要触发扩容流程或者清理无效数据。show volume查看每个卷的状态和容量分配情况和3PAR的showvv类似。show lun查看卷和主机之间的映射关系show host查看主机WWN和iSCSI发起程序信息。很多朋友习惯把show disk里的磁盘容量加起来跟领导汇报“系统还有多少空间”这个做法其实不准确。磁盘容量之和是裸容量真正业务可用的要扣掉RAID校验空间、热备盘、快照预留、文件系统开销等。所以容量汇报应该以show pool的输出为准而不是盘子加总。3.5 性能数据全闪阵列的瓶颈往往不在盘全闪阵列的硬件IOPS能力非常强单块NVMe盘动辄几十万IOPS。但实际业务中很少有人能把全闪的盘性能完全发挥出来因为瓶颈往往出在控制器、缓存、光纤链路这些环节。所以性能监控的重点要放在数据路径上。# 查看整体性能 show performance # 按卷查看性能 show performance volume # 查看控制器CPU和缓存使用率 show controller performanceshow performance输出系统的整体IOPS、带宽、时延这是最顶层的性能视图。如果整体时延异常再通过show performance volume下钻到具体卷看看是哪个业务“拖后腿”。show controller performance则关注控制器的CPU使用率、缓存命中率、写入缓存水位。实际排障经验全闪阵列出现“存储慢”的反馈先查控制器CPU是否打满再查光纤链路的协商速率最后才怀疑磁盘本身。因为全闪磁盘的性能余量太大盘本身成为瓶颈的概率其实很低。很多时候是控制器忙不过来或者主机侧链路被限速。3.6 日志导出和版本信息排查前先留证据处理存储故障有个原则先留证后动手。因为一旦执行了切换、重启、拔盘这类操作故障现场就被破坏了事后想复盘只能靠日志。# 查看固件版本 show version # 查看授权状态 show license # 导出日志 show log exportshow version务必牢记同一个问题在不同版本上的处理方式可能完全不同向原厂报障时对方第一句话大概率就是问版本号。show license则确认功能授权是否正常有些高级功能比如远程复制、快照如果授权到期会导致对应功能异常。排查前把这几个信息记录下来是对自己也是对原厂工程师负责。4. 从命令集到巡检脚本半小时巡检压缩到三分钟4.1 脚本设计三原则命令集整理出来之后下一步一定是脚本化。手敲命令适合临时排障日常巡检必须自动化。我在设计存储巡检脚本时始终坚持三个原则。第一是只读原则。巡检脚本只能使用show类只读命令绝不能包含任何配置类操作。这样即使脚本因为逻辑BUG误执行最坏情况也只是多采集了一些数据不会影响生产。第二是带时间戳原则。每次巡检输出都保存到以日期命名的文件里比如20250609_3par_health.log。没有时间戳的输出不具备历史对比价值存了跟没存一样。第三是可对比原则。巡检不是看单次输出而是对比相邻两次输出的变化。容量下降了5%、告警新增了两条、控制器CPU使用率上涨了10%这些变化才是巡检真正要捕捉的信息。4.2 3PAR巡检脚本用expect做SSH交互3PAR的CLI是交互式会话直接用bash的ssh命令不方便采集输出我用expect来做自动交互。下面这个脚本覆盖了3PAR日常巡检的核心命令。#!/bin/bash # 3PAR日常巡检脚本 IP10.0.0.10 USERmonitor_c PASSyourpass DATE$(date %Y%m%d) OUTDIR/var/log/storage-monitor/3par mkdir -p $OUTDIR expect EOF set timeout 30 spawn ssh $USER$IP expect { password: { send $PASS\r } yes/no { send yes\r; exp_continue } } expect cli send showalert -f new\r expect cli send showpd -s\r expect cli send showvv -sp\r expect cli send showport\r expect cli send exit\r expect eof EOF注意脚本里的password是明文存储的。在测试环境可以这么用生产环境建议改用SSH密钥认证或者从加密的凭据文件里动态读取。另外expect脚本里的cli提示符要和实际登录后的提示符完全一致否则expect会在错误的位置继续执行。登录一次确认提示符格式再写进脚本。这个脚本执行完整个expect EOF块内的输出都会打到标准输出。实际使用时可以整体重定向到日志文件同时加上时间戳./3par_monitor.sh ${OUTDIR}/${DATE}_3par.log 214.3 CF22030巡检脚本用paramiko解决SSH难题H3C CF22030的CLI虽然也走SSH但交互方式和3PAR不完全一样。为了省去麻烦的expect状态机我用Python的paramiko库来执行命令代码更可读后期加命令也方便。import paramiko import datetime host 10.0.0.20 user monitor pwd yourpass cmds [ show system status, show alarm, show disk, show disk -s, show pool, show volume, show performance, ] client paramiko.SSHClient() client.set_missing_host_key_policy(paramiko.AutoAddPolicy()) client.connect(host, usernameuser, passwordpwd) output_lines [] for cmd in cmds: stdin, stdout, stderr client.exec_command(cmd) output_lines.append(f### {cmd}) output_lines.append(stdout.read().decode()) client.close() date_str datetime.date.today().strftime(%Y%m%d) with open(f/var/log/storage-monitor/cf22030/{date_str}_cf22030.log, w) as f: f.write(\n.join(output_lines))这段脚本核心逻辑不复杂连上设备依次执行命令把输出写入带日期的日志文件。paramiko的exec_command对每个命令都是独立执行不需要维护交互状态比expect更省心。4.4 告警推送把关键输出扔给值班群光有巡检日志还不够真出了事不能等着人去看日志。我做的第三层是把巡检输出里的关键告警自动推到值班群用的是企业微信和钉钉都支持的Webhook方式。思路很简单在巡检脚本里加一段解析逻辑如果输出里出现了Critical、Fatal、failed这类关键词就触发Webhook推送。if grep -qiE Critical|Fatal|failed|degraded ${DATE}_3par.log; then curl -s https://qyapi.weixin.qq.com/cgi-bin/webhook/send?keyyour-key \ -H Content-Type: application/json \ -d {msgtype:text,text:{content:3PAR巡检发现异常请登录存储查看日志}} fi这种方式能保证“巡检到问题后第一时间有人知道”即使凌晨三点也没问题。当然推送只能作为通知手段真正排查还是需要登录设备看详细输出所以推送消息里最好附上日志文件名方便值班人员快速定位。4.5 监控账号的授权建议自动化巡检的前提是专用监控账号。3PAR那边创建只读用户CF22030那边同样创建只读用户。存储设备的账号权限体系大多能做到命令级授权巡检脚本用到的每一条命令都可以单独授权这是最稳妥的方式。带外管理HDM账号和存储CLI账号是分开的两边都要配置监控账号。巡检脚本只走CLI通道HDM账号单独用于硬件状态检查。两个通道的账号权限都遵循最小化原则不授权任何写操作。5. 真实遇到过的坑巡检命令是这样救命的5.1 degraded不一定就是盘坏了先确认再动手有一次巡检3PARshowpd输出里有一块盘的State是degraded。按照常规思路degraded就是要换盘的前兆我当时连备件都准备下单了。后来多敲了一条showpd -i才发现这块盘不是坏了而是前一天加盘后系统正在做数据重构chunklet正在往新盘里搬数据所以状态显示降级。这个状态下如果贸然拔盘反而会打断重构流程给系统造成额外的数据风险。从那以后我养成了一个习惯看到degraded先查原因确认是坏道、数据重构还是其他逻辑操作引起的再决定要不要进入换盘流程。showalert里对应告警的详细描述showpd -i里的初始化状态结合起来看基本能判断出来。5.2 showpd -s显示的是裸容量汇报前先换算做容量汇报时最容易踩的坑是把裸容量当可用容量。showpd -s输出的总容量是把所有物理磁盘容量加起来的裸容量它没有扣除RAID校验开销、热备盘、快照预留、内部元数据占用。所以看到“系统还剩50%空间”很可能只是裸容量维度真正业务可用的空间要小得多。正确做法是看showspace输出里的可用容量或者showpool/showvvspace里汇总之后的值。给领导汇报容量之前先确认自己看的是物理层还是逻辑层的数据口径不一样结果差很多。CF22030那边同理show disk加总是裸容量show pool才是业务视角的容量。5.3 全闪存储的寿命数据比状态字段更值得盯CF22030是SSD全闪我踩过最深的坑就是只盯着磁盘状态字段看忽略了寿命数据。SSD和机械盘不一样它在生命周期内状态很长一段时间都是online看起来一切正常但实际上磨损已经悄悄推进。等状态从online变成failed的时候往往是寿命耗尽的瞬间留给你的反应时间非常短。现在我做全闪存储巡检show disk -s里的SMART寿命数据是我重点关注的对象。磨损度超过70%就列入备件计划超过50%的话月度巡检变成每周巡检。这个经验同样适用于所有SSD阵列不管是H3C还是其他品牌的闪存存储。5.4 巡检节奏日常、每周、每月各看什么顺手整理一个巡检频率表供参考。实际操作中可以根据设备重要程度和业务敏感度调整节奏。巡检周期3PAR C630CF22030重点事项每日showalert、showpd -s、showspaceshow alarm、show pool有无新告警、容量是否突变每周showpd、showvvspace、showportshow disk、show disk -s、show volume磁盘状态、SSD寿命变化、端口链路每月showld、showpdch、statcpu汇总show system status、show performance汇总底层数据分布、性能趋势、固件版本核对巡检不是“看一遍”就结束关键是历史对比。所有输出保存成文件后每周挑一天做一次对比分析看容量曲线、告警数量、磁盘状态变化。这种趋势分析才是巡检真正的价值所在也是从“被动救火”走向“主动运维”的分水岭。存储这行干久了最大的体会是真正的高手不是会救火而是能在故障发生前把苗头按下去。这套命令集整理出来就是希望后来的人能站在这些经验上少走弯路。命令本身都不难难的是知道什么时候该看哪条命令、输出里的哪个字段才是关键。希望大家拿着这套命令集把存储巡检这件事从烦心事变成肌肉记忆。