企业官网建设流程全解析

简介：这份《NetApp存储日常维护手册》面向NetApp FAS系列存储的运维工程师与系统管理员，聚焦设备日常管理、操作规范与故障排查，适合具备一定存储基础、需要系统梳理维护流程的中级技术人员参考。资源包内含1个doc文档，压缩包约10.3MB，以Word文档形式完整呈现手册正文，便于查阅与打印。手册内容覆盖硬件设备说明、System Manager图形接口与CLI命令行管理、正常开关机顺序、日常检查与性能监控、故障诊断，以及存储池与FlexVol创建、CIFS/NFS共享、Snapshot与配额配置等操作，并延伸至FlexClone技术、存储虚拟化与解决方案设计。目录按目标、硬件说明、设备管理、日常操作等模块分层组织，结构清晰，可当作随查随用的维护参考。目前已有1933人学习下载，适合需要规范NetApp存储运维流程、补齐操作细节的读者使用。

1. 一份 2013 年的 FAS 维护手册，今天还能照着干吗

上周帮一个朋友看他们机房里那台还在跑的 FAS3240，面板上 Activity A 灯闪得挺欢，但 System Manager 死活连不上，Flash 插件在浏览器里一片空白。翻出这份《FAS 系列存储日常维护手册》，PDF 一共六十多页，从硬件指示灯一路写到故障报修流程，看着像老古董，实际翻完发现：里面关于 Aggregate 怎么建、FlexVol 怎么划、Snapshot 怎么配、开关机顺序怎么走的那几段，跟现在 Data ONTAP 的 CLI 逻辑几乎没变。变的只是图形界面从 Flash 换成了 Web，命令还是那些命令。这份手册适合两类人：一是刚接手 NetApp 存储、需要一套能照着敲的日常巡检清单的运维；二是手里有老 FAS 设备、官方文档太厚翻不动、想找一份“人话版”操作路径的工程师。它不教你架构设计，但能让你在凌晨两点被告警叫醒时，知道先看哪个灯、敲哪条命令。

2. 硬件先看灯：FAS3200 面板与开关机顺序的实操拆解

2.1 前面板三颗灯，判断“能不能远程连”的第一步

手册第 2 章把 FAS3200 前面板的 Power、Fault、Activity A/B 四颗灯的状态组合列了一张表，这张表看着枯燥，实际是现场排查的第一道分诊台。系统正常时 Power 绿灯常亮、Fault 橙灯灭、Activity A/B 绿灯亮或闪烁；AE 系列机型的 B 灯不亮属于正常。只要出现任何不符合的组合，手册直接给结论：联系支持。这话没错，但现场更实用的读法是先分清“灯不对”和“连不上”是不是同一件事。

我一般会按这个顺序看：Power 灯不亮，先查 PDU 和电源线，别急着开 ticket；Power 亮但 Fault 橙灯常亮，说明控制器在启动、初始化、维护模式或检测到模块故障，这时候 System Manager 连不上是正常的，等它走完或者接串口看启动日志；Fault 灭但 Activity 灯全灭，机器活着但没负载，先确认业务侧是不是已经断了。手册里那张表的价值不在于背状态，而在于让你在打开电脑之前就知道该不该慌。

后面板端口那张表更值得抄下来贴在机柜门上。0a/0b 是后端 SAS 口，接磁盘柜；c0a/c0b 是心跳口，HA 双机场景下这两根线松了，Cluster 状态就会翻车；e0M 是远程管理口，SP 是远程串口，这两个口不通，后面所有远程操作都免谈。很多“存储失联”的工单，最后查下来是 e0M 的网线被隔壁机柜施工碰掉了，跟存储本身一点关系没有。

2.2 开关机顺序：为什么关机要倒着关磁盘柜

手册 3.3 节给的顺序很明确。开机：按 Shelf ID 依次开磁盘柜电源，等约 20 秒再开控制器，然后开交换机，最后开挂载存储的服务器。关机反过来：先确认应用关闭、服务器关闭，root 登录后对两个机头分别执行halt -f回到 CFE> 状态，先关控制器电源，再按 Shelf ID 倒序关磁盘柜。

这个顺序不是仪式感。磁盘柜先上电，控制器启动时才能在后端 SAS 链路上枚举到所有 shelf，Shelf ID 顺序错乱会导致磁盘归属识别异常，轻则某个 aggregate 降级，重则控制器进不了正常启动流程。关机时先停控制器再关盘柜，是为了让控制器在断电前完成 NVMEM 刷盘和文件系统干净卸载；反过来先断盘柜，控制器会看到后端磁盘批量消失，触发一连串告警，下次开机还得花时间清。

halt -f里的-f是强制跳过确认，HA 双机环境下要对两个节点都执行，别只 halt 一个就以为完事。回到 CFE> 提示符才算真正停住，看到这个提示符再动手拔电源。手册没写但现场必须补的一条：执行 halt 之前先cluster show确认节点状态，如果对端已经挂了，单节点 halt 会让业务彻底中断，这时候该走的是接管流程而不是关机。

3. 存储资源怎么划：Aggregate、FlexVol 与共享配置的图形/命令行双路径

3.1 建 Aggregate：RAID-DP 与磁盘同质性这两个参数别拍脑袋

手册 4.1.2 节用 System Manager 演示建 aggregate，起名 aggr_test，raidtype 选 Raid_dp，RaidSize 设 16。这几个参数背后有硬约束：加入同一个 aggregate 的磁盘必须同类型、同大小、同转速，否则系统以最慢最小那块为上限；SATA 盘不能混进 SAS 盘的 aggregate，反之也不行。RAID-DP 是双校验，允许同时坏两块盘，代价是每个 RAID 组少一块盘的容量，FC/SAS 盘默认 RaidSize 16 就是这个平衡点。

图形界面点几下就建完了，但真正要记的是 CLI 等价命令，因为远程排障时你未必有图形环境：

# 查看可用磁盘，确认类型、大小、转速一致 storage disk show -container-type unassigned # 创建 RAID-DP aggregate，指定 16 块盘为一个 RAID 组 aggr create aggr_test -B 16 -t raid_dp -d 16 # 确认创建结果与 RAID 状态 aggr show aggr_test aggr status -r aggr_test

-B 16是每个 RAID 组的磁盘数，-t raid_dp指定 RAID 类型，-d 16表示从可用池里取 16 块。执行前一定先跑storage disk show -container-type unassigned看清单，混了型号的盘在图形界面里可能被过滤掉，CLI 里却可能让你选进去，建完才发现容量按小的算。扩容时同理，新加的盘要和现有 aggregate 成员同规格，这条在手册里用“否则将于转速最慢、大小最小的磁盘类型为上限”一句话带过，实际踩过的人都知道那意味着白买了几块大盘。

3.2 FlexVol 与 CIFS/NFS 共享：先有卷，再有导出

手册 4.1.3 到 4.1.4 的路径是：建 FlexVol，再配 CIFS 或 NFS 共享。FlexVol 是跑在 aggregate 上的逻辑卷，可以单独设配额、单独做 Snapshot，这是 NetApp 区别于传统卷管理的核心。CLI 建卷：

# 在 aggr_test 上创建 500GB 的 FlexVol vol create vol_data aggr_test -s 500g # 查看卷状态与可用空间 vol show vol_data df -h vol_data

-s 500g是卷大小，单位可以是 g/m/t。卷建完不会自动共享，NFS 要配 export，CIFS 要配 share，手册 4.1.4 节在图形界面里走了一遍，CLI 侧对应的是：

# NFS 导出，允许 10.0.0.0/24 网段读写 exportfs -p rw=10.0.0.0/24,root=10.0.0.1 /vol/vol_data # CIFS 共享（需先确认 CIFS 服务已启动） cifs shares -add data_share /vol/vol_data

exportfs -p的-p表示持久化，重启后规则还在；rw=后面跟允许访问的网段，root=指定哪个客户端有 root 权限，不写的话客户端 root 会被映射成匿名用户，挂载能成功但写文件权限报错，这是 NFS 侧最常见的“玄学”问题之一。CIFS 侧cifs shares -add之前必须确认cifs setup已经跑过、域或工作组已配好，否则命令直接报服务未启动。

3.3 Snapshot 与配额：保护点和容量闸门要一起配

手册 4.1.5 和 4.1.6 分别讲 Snapshot 和目录配额。Snapshot 是 NetApp 的增量快照，几乎不占额外空间，但保留策略不设上限，卷会被快照撑爆。配额则是给目录或 Qtree 设容量和文件数上限，防止某个用户把卷写满。两条命令：

# 为 vol_data 创建名为 hourly 的快照策略，保留 6 份 snapshot policy create hourly 6 # 给 /vol/vol_data/project 目录设 100GB 硬配额 quota resize /vol/vol_data quota set /vol/vol_data/project 100g

snapshot policy create的第二个参数是保留份数，配合计划任务使用；quota set的硬配额超了直接写失败，软配额只告警。配额改完要quota resize让卷重新计算，否则新配额不生效，这个动作手册里没强调，但漏了就会以为配额没配上。Snapshot 和配额最好同时配：快照防误删，配额防写满，只配一个都是半套保护。

4. 日常巡检与排错：从 Cluster 状态到 autosupport 的检查清单

4.1 每日巡检七项：目测、硬件、网络、Cluster、容量、Inode、性能

手册第 5 章把日常维护拆成目测、硬件状态、网络、Cluster 状态、卷容量、Inode 数量、性能、日志、autosupport 九项。现场时间紧的时候，我一般按“先看会不会马上出事”排序：Cluster 状态和卷容量优先，Inode 和性能其次，日志和 autosupport 放最后但每周至少跑一次。

# Cluster 与节点状态，双机是否都健康 cluster show system node show # 卷容量与 Inode 使用率，超过 90% 要处理 df -h df -i # 网络与端口状态 network interface show network port show

cluster show看两个节点的健康状态和 epsilon 持有者，任一节点显示不可达，先查 c0a/c0b 心跳线和 e0M 管理网；df -h看容量百分比，df -i看 Inode 使用率，Inode 满了跟容量满了表现一样都是写不进去，但处理方式完全不同——容量满删文件或扩卷，Inode 满往往是小文件海量堆积，得先定位目录。手册 5.6 节单独列 Inode 检查，就是因为这个坑太常见。

4.2 autosupport 与日志：报修前先把证据攒齐

手册 5.9 节要求收集 autosupport 信息，5.8 节查日志。autosupport 是设备自动生成并发送的诊断包，开 case 时支持方第一句往往就是“把 autosupport 发过来”。手动触发：

# 立即生成并发送 autosupport autosupport invoke -node * # 查看最近日志中的错误与告警 event log show -severity error

-node *表示所有节点都触发，双机环境别只发一个。event log show -severity error过滤出错误级别事件，比翻全量日志快得多。报修流程手册第 6 章写了 GSC 开案和备件更换，实际用的时候把 autosupport、event log show输出、故障时间点三样备齐，开案沟通效率能高一截，不然来回补材料就是好几轮。

5. 避坑清单：五条现场翻车记录与排查路径

5.1 现象：System Manager 打不开，浏览器一片空白

原因：手册 3.1 节列的前置条件里，Adobe Flash Player 8.0 以上、Java Runtime 1.6 以上是硬门槛，新版浏览器早已移除 Flash 支持，插件加载不出来界面就是白的。另外存储端httpd.admin.enable、ssl.enable、snmp.enable没开，连登录页都出不来。

解决：先 SSH 上去逐条确认options httpd.admin.enable、options ssl.enable为 on，snmp.access legacy和 community 配好；图形界面走不通就切 CLI，手册第 4.2 节整段 CLI 操作就是为这种情况准备的，建卷、配共享、做快照的命令一条不少。

5.2 现象：NFS 挂载成功，但客户端写文件报 Permission denied

原因：exportfs规则里没给客户端 root 权限，客户端 root 被映射成匿名用户，目录属主是 root 时写不进去。或者导出网段写错，客户端 IP 不在rw=列表里，挂载能过但读写被拒。

解决：exportfs -p rw=<网段>,root=<客户端IP> /vol/vol_data补上 root 参数，重新导出后用exportfs不带参数查看当前规则确认生效。改完在客户端touch一个测试文件验证，别只看挂载成功就收工。

5.3 现象：扩容加了新盘，aggregate 容量没按预期涨

原因：新盘和现有成员盘类型、大小、转速不一致，系统按最小最慢的盘计算，或者新盘根本没加入 aggregate 还在 unassigned 池里。手册 4.1.2 节那句“以转速最慢、大小最小的磁盘类型为上限”就是提前打的预防针。

解决：storage disk show -container-type unassigned核对新盘规格，aggr status -r aggr_test看 RAID 组构成，确认无误再aggr add aggr_test -d <磁盘ID列表>。加完aggr show对比容量变化，数字对不上就查是不是混了盘。

5.4 现象：卷容量还有余量，应用却报“设备上没有空间”

原因：Inode 用尽。NetApp 卷的 Inode 数量在创建时按比例分配，海量小文件场景下容量没满但 Inode 先耗尽，df -h看着正常，df -i已经 100%。

解决：df -i确认 Inode 使用率，定位小文件集中的目录做清理或归档；长期方案是建卷时调大 Inode 上限或拆分多个卷分摊。手册 5.6 节把 Inode 检查单列一项，就是让巡检时别只看容量。

5.5 现象：双机环境中一个节点 halt 后，另一个节点没接管，业务全断

原因：执行halt -f前没确认对端状态，对端本身已经不健康，单节点停机后没有接管方；或者心跳线 c0a/c0b 有问题，Cluster 早就处于降级状态没被发现。

解决：关机前先cluster show和system node show确认双节点健康、epsilon 正常；心跳异常先修链路再谈停机。手册 3.3 节关机顺序里“确认所有连接的应用已关闭”只是第一步，Cluster 健康检查是没写进去但必须补的一步。

6. 把手册变成自己的巡检脚本：三条命令加一张表

手册给的是操作路径，真正让日常维护省力的是把高频检查固化成脚本。我习惯在管理跳板机上放一个只读巡检脚本，每天定时 SSH 到存储跑三条命令，输出落到本地文件，异常项人工复核。核心就三行：

#!/bin/bash # 只读巡检，不执行任何变更操作 ssh admin@<存储管理IP> "cluster show; df -h; df -i" > /var/log/netapp_check_$(date +%F).log ssh admin@<存储管理IP> "event log show -severity error -time-range 24h" >> /var/log/netapp_check_$(date +%F).log ssh admin@<存储管理IP> "aggr show; vol show" >> /var/log/netapp_check_$(date +%F).log

第一条抓 Cluster 和容量/Inode，第二条抓过去 24 小时错误事件，第三条抓 aggregate 和卷的整体状态。脚本只读，不碰任何配置，跑在跳板机上比登图形界面快得多。输出文件按日期命名，出问题时往前翻几天就能看出趋势，比事后回忆“上周是不是就告警了”靠谱。

配合脚本用一张简单的判断表，比背手册状态组合实用：

这张表不是替代官方监控，而是给没有上监控系统的小环境一个最低成本的兜底。脚本跑顺之后，我把手册里“目测指示灯”那一步也加进了每周一次的现场走查：灯不对先看表，表不对再跑脚本，脚本报错再开 case，顺序反了就容易在无关的告警里绕圈。

血泪经验是有一回扩容后没跑aggr status -r核对，新盘混了一块不同转速的进去，容量按小的算，业务侧感知到的是“扩了跟没扩一样”，翻了两天才定位到那块盘。从那以后我每次动完 aggregate 和卷，都强制走一遍“命令确认 + 容量对比 + 一天后回看 event log”这三步，宁可多花十分钟，也不留一个隔夜才爆的雷。这份手册的价值不在于它写得多全，而在于它把该看的点都列出来了，剩下的就是把它变成你自己的动作习惯。希望帮到你。

本文还有配套的精品资源，点击获取