企业官网建设流程全解析

简介：这份《NetApp存储日常维护手册》面向NetApp FAS系列存储的运维工程师与系统管理员，聚焦设备日常管理、操作规范与故障排查，适合具备一定存储基础、需要系统掌握FAS3200系列维护技能的中级技术人员参考。资源包内含1个doc文档，约10.3MB，以图文混排形式组织，便于按章节查阅与打印留存。手册内容覆盖硬件设备说明、System Manager图形接口与CLI命令行管理、正常开关机顺序、日常检查与性能监控、故障诊断，以及存储池与FlexVol创建、CIFS/NFS共享、Snapshot与配额配置等操作，并延伸至FlexClone技术与存储虚拟化方案，目录层级清晰、知识点成体系。目前已有1933人学习下载，可作为日常巡检、故障处置与项目交付时的案头参考，帮助读者快速定位操作入口、理清维护流程并补齐技术盲区。

1. 从一台 FAS3240 的告警灯说起：这套维护环境到底装什么

凌晨两点被叫到机房，FAS3240 前面板一个橙灯常亮，Activity 灯不闪，业务侧 NFS 挂载全部超时。翻出随机文档才发现，问题不在存储本身，而是前一天有人按普通服务器习惯先关了控制器再关磁盘柜，Shelf ID 顺序全乱，开机自检卡在中间态。这类翻车在 FAS3200 系列上太常见了——硬件本身不娇气，娇气的是维护这套环境的人有没有把「装什么、按什么顺序开、用什么工具连」理清楚。这篇笔记面向刚接手 NetApp FAS 系列、需要把日常维护环境从零搭起来并跑通健康检查的开发者，也写给已经会用 CLI 但想补齐 System Manager 图形端和开关机规范的老手。装不好不会炸盘，但会在扩容、快照、配额这些日常动作上反复踩坑，最后连 autosupport 都收不全。

2. 装前环境盘点：FAS3200 硬件端口与 System Manager 依赖

动手连设备之前，先把「这台机器上有什么口、图形端靠什么跑」列清楚。FAS3200 系列的后端端口不是随便插的，插错一个口，轻则链路降速，重则心跳不通导致 HA 接管异常。我一般会先对着机器后背拍一张照，再逐口核对，避免在机房蹲着翻 PDF。

2.1 FAS3200 后端端口对照与用途

FAS3240 这类机头的后端端口在手册里写得很细，但实际接线时最容易混的是 c0a/c0b 和 0a/0b。前者是控制器之间的心跳线接口，后者才是接磁盘柜的 SAS 口。下面这张表是我按手册整理、并在现场核对过的版本，装环境时直接照着对：

提示：e0M 和 SP 是两个口，很多人只接了 e0M 就以为带外管理齐了，结果控制器宕机时 SP 连不上，只能跑机房。装环境阶段两个都接上，后面排错会省很多事。

2.2 System Manager 2.1 的客户端与存储端依赖

图形端不是装完就能点开。手册明确要求客户端有 Adobe Flash Player 8.0 或更高、Java Runtime 1.6 或更高，这两个在现在的浏览器环境里已经是玄学级别的存在，我一般单独留一台老系统或虚拟机专门跑 System Manager，不和日常办公环境混。存储端则要先通过 CLI 把下面这组服务打开，否则图形界面登录会卡在认证阶段：

# 在 FAS3240A1> 提示符下逐条执行，开启图形管理与 SNMP snmp.access legacy # 允许旧版 SNMP 访问方式 snmp.enable on # 打开 SNMP 服务 ssl.enable on # 启用 SSL ssl.v2.enable on # 兼容 SSLv2，老版 System Manager 依赖 ssl.v3.enable on # 启用 SSLv3 httpd.admin.enable on # 打开 HTTP 管理接口 httpd.admin.ssl.enable on # 打开 HTTPS 管理接口 snmp community public # 设置只读 community，按现场策略改

这几条里，snmp.access legacy和ssl.v2.enable on是给 System Manager 2.1 这种老客户端兜底的，新版环境里通常默认关闭，不打开就会遇到「能 ping 通但登录报协议错误」。httpd.admin.ssl.enable on决定你后面是用 http 还是 https 访问，生产环境建议只留 https，把 http 那条关掉。community 字符串不要照抄 public，按现场安全策略换成别的，改完记得同步到监控系统，不然 SNMP 采集会断。

2.3 管理入口二选一：图形端与 CLI 的取舍

System Manager 能覆盖卷、共享、LUN、Qtree、Quota、SnapMirror 这些日常动作，适合做一次性配置和给不熟命令的同事看状态；CLI 则是排错和批量操作的主场，?或help能列出全部命令，help vol这种二级帮助会告诉你vol create、vol status各自支持什么参数。我的习惯是：建 Aggregate、建 FlexVol、配 CIFS/NFS 共享这类结构化操作走图形端，核对结果和写巡检脚本走 CLI。两边登录账号都是 root，密码在初始安装时设定，改密码用passwd，别等到交接时才发现没人记得。

3. 按顺序装起来：开关机规范与 Aggregate/FlexVol 创建

环境盘点完，真正容易出事的环节是「顺序」。FAS 系列的开关机不是普通服务器那套，磁盘柜和控制器之间有严格的先后关系，装环境阶段如果第一次开机就乱序，后面所有健康检查的基线都是错的。

3.1 开机与关机的正确顺序

开机顺序手册写得很清楚：先按 Shelf ID 号依次开磁盘柜电源，等大约 20 秒再开存储控制器；然后开接存储的以太网或光纤交换机；最后开挂载存储的服务器或磁带库。这个 20 秒是给磁盘柜完成自检、SAS 链路稳定的时间，抢这几秒经常导致控制器起来后认不全盘。

关机反过来，而且更考验人：

# 关机前先确认应用和主机侧已断开，再登录控制器执行 halt -f # 强制停机，两个机头都要执行，回到 CFE> 状态

halt -f的-f是强制，正常流程下先halt不带参数更稳妥，只有在系统卡住、正常停机无响应时才用-f。执行完两个机头都回到CFE>后，先关控制器电源，再按 Shelf ID 倒序关磁盘柜。我见过有人只 halt 了一个机头就去拔另一个的电源，结果 HA 伙伴以为对方故障，触发接管，起来后卷状态一片异常。关机顺序这条，建议打印出来贴在机柜门内侧。

3.2 创建 Aggregate：RAID 类型与磁盘选择

Aggregate 是 NetApp 的存储池，扩容和新建都从这里开始。图形端路径是 Storage -> Aggregates -> Create，起名比如aggr_test，RAID 类型选raid_dp（双校验，FAS 系列默认推荐）。关键在选盘那一步：加入同一个 Aggregate 的磁盘必须是同类型、同大小、同转速，否则系统会以最慢、最小的那块为上限，等于白白浪费好盘。SATA 盘不能混进 SAS 的 Aggr，反之也不行。

RAID Size 对 FC/SAS 盘默认是 16，这个值决定一个 RAID 组里数据盘和校验盘的比例，扩容时如果现场有特殊要求再调，日常维护保持默认即可。图形端点 Select Disk 时注意看磁盘的 owner 是不是当前控制器，HA 环境下另一台机头持有的盘要先做归属调整，否则选不进来。

3.3 创建 FlexVol 与 NAS 共享（CIFS/NFS）

FlexVol 是建立在 Aggregate 之上的灵活卷，日常业务数据都落在这一层。图形端 Storage -> Volumes -> Create，选好所属 Aggr、卷大小、是否开启 Snapshot 预留。这里有个参数取舍：Snapshot 预留比例默认 5%，如果业务写放大明显，预留太小会导致快照很快失效，我一般按业务写入量给到 10%~20%，具体看现场。

NAS 共享分两条线：CIFS 走 Storage -> Shares，NFS 走 Storage -> Exports。CIFS 依赖域或本地用户配置，NFS 则要确认 export 规则里的客户端网段和权限（rw/ro、root squash）。CLI 侧对应的命令是vol create、cifs shares、exportfs，图形端配完可以用exportfs或cifs shares回读一遍，确认规则真的落盘了，而不是界面上显示成功、底层没生效。

3.4 Snapshot 与目录配额的最小配置

Snapshot 配置在 Storage -> Snapshot，核心是策略（schedule）和保留份数。日常维护环境建议先建一个「每小时、保留 24 份」的基础策略，再按卷绑定，别一上来就开太密，否则 Snapshot 预留很快被吃满。目录配额在 Storage -> Quotas，先开 quota 再设规则，顺序反了规则不生效。配额类型分用户、组、Qtree 三种，装环境阶段先用 Qtree 配额把测试目录圈起来，验证quota report能出数，再推广到业务卷。

4. 日常维护环境跑通：健康检查项与 autosupport 收集

装完不是结束，能把每日健康检查跑成固定动作，这套环境才算真正立住。手册第 5 章列的检查项看着多，实际按「目测—硬件—网络—集群—容量—Inode—性能—日志—autosupport」这条线走一遍，十分钟内能完成。

4.1 硬件与网络状态的快速核对

目测先看前面板：Power 绿灯、Fault 橙灯灭、Activity A/B 绿灯亮或闪烁，AE 系列 B 灯不亮属正常。后端看 NVMEM Battery 灯，闪烁绿表示处于电池备份待机，上电正常运行时应为灭。机架电源模块看 PSU status，正常是灯亮、其余灭；风扇问题则是风扇灯亮。这些灯语手册里有完整表格，装环境时对着抄一遍，比出事时现查快得多。

网络检查用ifconfig看 e0a/e0b 和 e0M 的链路与地址，netstat看路由和连接。集群状态用cluster show或图形端 HA config 看两个机头是否都 healthy，心跳口 c0a/c0b 的ifstat计数有没有异常增长。

4.2 容量、Inode 与性能的巡检命令

容量看df -h和vol status，重点不是总量，而是 Snapshot 预留和 Aggregate 剩余。Inode 用df -i或vol status -i，小文件多的卷 Inode 先满、容量还有富余，这是 NAS 场景的经典坑。性能看sysstat，关注 CPU、磁盘利用率、网络吞吐三条曲线，装环境阶段先跑一次基线，后面才有对比。

# 日常巡检最小命令集，按顺序执行并记录输出 df -h # 卷容量与 Snapshot 占用 df -i # Inode 使用率 vol status # 卷状态、是否在线、Snapshot 策略 aggr show_space # Aggregate 剩余空间 sysstat -x 1 # 每秒刷新性能，Ctrl+C 退出

sysstat -x 1的-x是扩展输出，1是刷新间隔秒数，巡检时跑十几秒看趋势就够，别长时间挂着占终端。输出里的 Disk Util 长期高于 80% 就要查是业务峰值还是某块盘拖慢。

4.3 日志检查与 autosupport 收集

日志在图形端 Diagnostics -> Logs，CLI 侧看/etc/messages和ems事件。装环境阶段先把ems的告警级别确认一遍，避免关键事件被过滤。autosupport 收集用autosupport invoke -node *，两个机头都发一次，确认能正常生成并投递，这一步是后面报修流程的前提——autosupport 收不全，支持中心拿不到现场信息，开案会拖很久。

5. 避坑与排查：五条装环境时最容易翻车的记录

5.1 图形端登录报协议错误

现象：System Manager 能 ping 通存储，登录时卡住或提示 SSL/协议不兼容。原因：存储端ssl.v2.enable、httpd.admin.ssl.enable没开，或客户端 Java/Flash 版本过低。解决：按 2.2 节那组命令逐条确认，客户端换一台带 Java 1.6+ 和 Flash 8+ 的环境，别在最新浏览器上硬试。

5.2 开机后认不全磁盘柜

现象：控制器起来后aggr show_space或disk show少盘。原因：开机时磁盘柜没等够 20 秒就开控制器，或 Shelf ID 顺序接错。解决：按 Shelf ID 重新核对接线，关机后严格按「磁盘柜→等 20 秒→控制器」重来，别在运行态反复插拔 SAS 线。

5.3 Aggregate 扩容后容量不达预期

现象：加了一批盘进 Aggr，可用容量比算出来的少。原因：混入了不同转速或不同大小的盘，系统按最慢最小盘为上限。解决：扩容前用disk show -v核对型号和转速，同 Aggr 只加同规格盘，混插的盘单独建 Aggr。

5.4 Snapshot 预留被吃满导致快照失效

现象：卷容量还有，但快照陆续失效，vol status显示 Snapshot 预留满。原因：预留比例按默认 5% 给，业务写入放大后不够用。解决：按写入量把预留调到 10%~20%，同时检查快照策略是否过密，必要时降低频率或缩短保留份数。

5.5 autosupport 投递失败

现象：autosupport invoke执行后没有生成记录，报修时支持中心要不到信息。原因：管理口路由不通、SMTP/HTTP 投递地址没配，或 e0M 与 SP 只接了一个。解决：先ifconfig e0M确认地址和网关，再查 autosupport 配置里的投递目标，两个管理口都接上，投递失败时看/etc/messages里的具体报错。

6. 装完怎么验证跑通：一次完整健康检查的收尾动作

环境装没装成，不看界面能不能点开，看能不能把一次完整健康检查从头跑到尾、并且结果可复现。我的验证顺序是：先目测前面板和后端灯语，确认没有橙灯；再cluster show确认两个机头 healthy、心跳口计数正常；然后df -h、df -i、vol status、aggr show_space四条命令的输出各存一份，作为基线；接着sysstat -x 1跑 15 秒看趋势；最后autosupport invoke -node *两个机头各发一次，确认投递成功。

这套动作跑通后，把命令集写成一个巡检脚本或一张检查表，每天固定时间执行，输出归档。下面是我自己用的最小验证清单，装完环境当天必须全绿才算收工：

有一次我图省事，装完只看了图形端显示正常就收工，结果第二天巡检发现 autosupport 一直没投递出去，管理口路由是错的，等到真出故障要开案时才补，白白多花半天。从那以后我每次装完 FAS 环境，都强制把这张表从头到尾走一遍，尤其是 autosupport 和开关机顺序这两项，宁可多花十分钟，也不留到出事时再补。希望帮到你。

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