企业官网建设流程全解析

简介：浪潮存储系统AS Manager管理软件配套技术手册面向存储管理员、IT运维与基础架构人员，用于帮助读者掌握存储系统日常配置、监控与安全防护方法，可作为部署与排障时的参考文档。资源为PDF格式文档，压缩包内含1个pdf文件，整体约3.58MB，内容完整且便于离线查阅。

手册详细介绍了AS Manager的用户身份验证、图形化管理与存储系统管理三大核心能力，涵盖软件安装时的JRE环境要求、安装步骤，以及通道名称、IP地址、端口号等关键参数的设置方式。此外，手册从运维安全角度提出使用管理私网与公网物理隔离、设置6位以上含字母数字及特殊字符的强密码、定期更换并控制密码知晓范围等建议，帮助用户降低存储系统被非授权访问的风险。

该资源已有1565人学习下载，适合正在部署或日常维护浪潮存储系统的技术人员按章节快速查阅操作要点，同时也为初学者提供了一条从环境准备到安全加固的完整学习路径。

1. AS Manager是什么：存储交付和日常运维都绕不开的那个入口

接手任何一套浪潮AS系列存储，第一件要摸清楚的事就是AS Manager。它是这套存储系统的统一管理入口，负责存储池、LUN、主机映射这些资源的配置，也负责把控制器状态、硬盘健康、性能和告警送到运维人员面前。存储手册通常按功能菜单编排，但实际运维是按流程走的，先建什么、后配什么、哪些参数动了会影响生产，这才是真正值钱的经验。下面按交付顺序展开，从登录配置讲到主机映射，再讲日常监控和常见故障排查，最后给几个能直接落地的运维习惯。

2. AS Manager的部署形态与首次连接：把管理通道先打通

2.1 管理服务器与存储管理口的职责分工

AS Manager的典型部署是管理服务器加浏览器客户端。管理服务器可以是一台独立服务器，也可以以虚拟机形式部署在虚拟化平台上，它通过带外管理网络与存储控制器的管理口通信。所谓带外，是指管理流量不经过业务光纤口和iSCSI业务口，走控制器背板上的专用以太网管理口，这样就算业务链路拥堵，管理通道依然可用。代价是运维上多了一条需要单独规划的网段。

我一般会把管理网段、业务网段、存储网段严格分开。管理网段不承载业务流量，交换机上不做多余策略，保证管理服务器和所有存储管理口二层互通就行。存储上架时，交付工程师会为每个控制器配置管理IP，双控制器各有独立地址，AS Manager通过这两个地址分别掌握两个控制器的状态。有条件的话，配置一个浮动管理地址，控制器切换时管理IP不漂移，后续运维会省很多麻烦。

带宽方面管理流量占比很小，百兆口够用，但网卡和交换机端口模式要配对。常见的坑是管理口连到交换机后协商成了半双工，平时看不出来，一有流量就掉包，登录页面能打开但操作频繁超时。这类问题优先在现场的网管交换机上确认端口协商和错误包计数。

2.2 首次登录前的网络检查和初始口令

打开AS Manager管理界面前，先把网络基础确认掉。管理服务器能ping通两个管理IP，浏览器到管理服务器的链路通，防火墙没拦掉管理端口。很多现场首次登录失败不是口令不对，而是管理网段划分混乱：管理IP和业务IP冲突、管理服务器缺网关导致跨网段访问失败，或者交换机端口被划进错误的VLAN。查这些问题优先级高于动设备配置。

登录凭据使用设备交付时提供的初始账号，不同批次设备的初始口令策略可能不一样，不要依赖网上流传的默认口令，以设备铭牌标签和交付文档为准。首次登录后马上修改初始口令，再创建只读权限的监控账号给日常巡检和监控平台用。管理员的变更操作与只读账号的查询分离，出问题能从操作日志追到人，这在多人协作的机房里几乎是铁律。

顺便说一句，AS Manager登录页一般都有版本号和补丁信息，首次登录时记录一下，后续做升级判断要用。浏览器方面，新版本普遍支持现代浏览器直接访问，不需要额外插件；旧版本可能依赖Java运行环境，如果登录后界面反复提示启动控制台，先检查浏览器安全设置里是否拦截了本地应用调用。

2.3 添加设备后的健康状态确认

管理服务器接入存储系统后，第一眼看设备健康总览，不要急着创建存储池。确认顺序：双控制器运行状态是否正常，主备角色是否符合预期；所有硬盘是否online，有没有fail或foreign状态；控制器缓存电池是否normal，电池老化会让写缓存降级成直写，性能直接打折；控制器固件和硬盘固件版本是否一致，不一致的会在后续扩容和故障替换时遇到兼容性问题。

这些确认项是后续所有配置的地基。电池异常、硬盘failed、控制器版本不一致时创建存储池，相当于在结构不稳的地基上盖楼，出问题时排查成本非常高。每台设备添加进AS Manager后，把健康状态记录到运维档案，后续巡检时对比，状态变化一目了然。特别是电池状态，很多存储故障的根因追溯到最后都是电池老化导致写缓存策略变化，而这类变化在早期是没有明显告警的。

3. 用AS Manager交付一块业务存储：存储池、LUN与主机映射

3.1 存储池规划：RAID级别、热备盘与硬盘分组

存储池是LUN的容量来源。AS Manager里创建存储池之前，先把硬盘分组和RAID策略定清楚。硬盘分组的核心原则是同时同速：同组内的盘容量一致、转速一致、接口类型一致，SATA盘和SAS盘不要混组，不同容量也不要混。混用会让慢盘拖慢快盘，容量小的盘限制组内可用空间，后续扩容时还会出现换盘困难。分组之后决定热备盘归属，全局热备还是分组热备，取决于你对安全性和容量的权衡。

RAID级别的选择依据是业务IO特征。数据库、高随机读写的业务优先RAID10，随机读写性能稳定，安全性好，代价是容量利用率50%；文件共享、备份存放这类容量敏感型业务选RAID5或RAID6。这里有个趋势要重视：单盘容量超过4TB后，RAID5的rebuild时间很长，重建窗口期再坏一块盘就是全组数据风险，所以我倾向大容量盘组用RAID6或RAID10，宁可少两块盘的容量，也不赌重建窗口期的运气。

部分型号支持在存储池内做分层，把SSD和HDD组合，热点数据自动迁移到SSD层。这个功能看着先进，但管理复杂度高，冷热数据识别不准时反而浪费SSD寿命。入门阶段先用单类型磁盘池把基础跑稳，再考虑分层不迟。

3.2 创建LUN：容量模型、预分配与访问策略

存储池就绪后创建LUN。LUN是给业务主机使用的逻辑磁盘，在AS Manager里承载容量、访问策略和映射关系。创建时几个参数要明确：容量大小、精简还是厚配置、读写缓存策略、LUN名称和编号。

精简配置按需分配容量，创建时逻辑容量可以大于物理容量，适合虚拟化和文件共享，但必须配套容量监控，池写满后所有LUN会一起故障；厚配置创建时一次性预留物理空间，适合数据库这种对空间确定性要求高的场景。我的经验是：业务侧有严格容量管理的项目优先厚配置，资源池型环境或测试环境用精简配置。LUN命名用「应用名_环境_用途_容量」的规范格式，别用业务代号玩个性，几十上百个LUN时规范的命名是运维效率的分水岭。

访问策略里重点关注读写缓存。读缓存对绝大多数业务有益，写缓存依赖控制器电池保护，电池正常时写缓存能显著降低延迟。个别场景要求关写缓存，比如对持久性有特殊审计要求的应用，但这类场景很少。不要因为听别人说关缓存安全就一刀切，随机写场景下关闭写缓存的性能损失是数量级的，先确认电池状态再决定参数。

注意：精简配置池的使用率达到90%，先扩容池容量再创建新的精简LUN，否则池写满时所有LUN的写入都会阻塞。

3.3 主机映射与多路径验证：阵列配置真正生效的一步

LUN创建完，业务主机还是看不到盘，因为LUN在存储侧没有被授权给任何主机。AS Manager里先登记主机，再建立主机与LUN的映射。登记时要填操作系统类型和HBA标识：FC环境填HBA卡WWN，iSCSI环境填启动器IQN。主机类型选错会让存储侧下发错误的SCSI参数，Windows和Linux的差异在部分场景下会导致主机侧磁盘异常。

映射完成后到业务主机执行扫描。Linux下确认新盘：

# 重新扫描SCSI总线，让新映射的LUN对系统可见 echo "- - -" > /sys/class/scsi_host/host0/scan # 查看块设备列表，确认新盘已经出现 lsblk

echo "- - -"是触发SCSI主机控制器重新扫描的通用写法，三个短横线分别表示通道、目标、LUN，全写代表不限定范围，所有新LUN都会扫出来。执行后lsblk能看到新盘。主机有多块HBA卡时，要分别对每个host目录执行一次扫描，只扫一个host只覆盖一条链路。

FC环境推荐配多路径，Linux用device-mapper-multipath，Windows用MPIO。配置后验证：

# 查看多路径聚合后的dm设备，确认每条路径状态 multipath -ll

输出里关键看每条path的状态是active还是failed，active数量应等于物理路径数。聚合的理想结果是每个LUN对应一个dm设备，路径双活。文件系统建在多路径设备上，绝对不要直接在/dev/sdX上建，重启后盘符漂移会带来挂载失败的坑，这个翻车现场很多老工程师都经历过。

4. 日常监控与容量预警：把AS Manager当成仪表盘而不是配置工具

4.1 性能指标看什么：IOPS、时延、缓存命中率

AS Manager的性能视图能看控制器级别的IOPS、吞吐量、平均时延，也能下钻到单个LUN甚至磁盘。日常巡检优先看三个指标：控制器CPU利用率、缓存命中率、磁盘平均响应时间。

控制器CPU持续超过70%，要排查是否存在异常扫描风暴或前端链路拥塞；缓存命中率是存储性能的晴雨表，读命中率长期低于50%，说明业务工作集大于缓存容量，或者缓存策略不合适，读密集业务可以尝试加大预读参数；磁盘平均响应时间超过20毫秒要留意，正常机械盘在10毫秒以内，明显偏高说明磁盘负载重或者有慢盘。慢盘的特征是响应时间比其他盘高一个数量级，同时IOPS不高但队列深度不低，在性能视图里对比各盘曲线很容易识别出来。

时延异常时，先判断是单LUN热点还是整池过载。单LUN热点常见于某个应用发起大规模数据扫描，整池过载则要回到存储池结构找原因，比如RAID类型、条带大小和业务IO是否匹配。性能排查切忌一上来就怀疑硬件，多数情况下是结构问题和负载问题。

4.2 告警阈值与通知渠道怎么设

告警配置的目标是在故障演变成事故前接到提醒。容量类阈值最先要设：存储池使用率80%为规划线，到了就要排扩容；90%为紧急线，缩短观察周期；超过95%基本进入风险状态，特别是精简配置池，写满的后果是全员阻塞，不是单个LUN的问题。

硬盘类告警关注预测性故障类预警，多数阵列支持类似SMART的硬盘健康监测，出现预警后安排维护窗口更换，不要等盘彻底fail。控制器和电池状态告警属于高优先级，电池多数有几年寿命，老化是渐变过程，提前更换比应急更换成本低得多。

通知渠道推荐邮件加SNMP双路。邮件负责人工处理，SNMP对接机房的监控平台做工单联动。设通知时把噪音控制住：同类型告警做汇聚，设置抑制窗口。链路抖动时断开和恢复告警在几分钟内反复出现，没有抑制窗口，告警平台会被刷屏，真正的故障反而被淹没。告警级别分开，警告级只提醒，紧急级才电话通知，值班人员不会因为通知太多而麻木。

4.3 容量管理与扩容操作流程

容量管理最怕的不是没容量，是没有提前量。把存储池使用率趋势记录下来，每周看一眼变化，推算出剩余可用时间。趋势比绝对数值更关键：剩余80%容量的池，如果每周消耗2%，四十周就用完，扩容流程要及时启动。很多现场翻车都是看到告警才开始找硬盘，结果采购周期长，业务只能降级扛着。

扩容的典型路径：加硬盘、扩存储池、扩LUN。物理盘插进去先确认状态online，再扩展磁盘组或创建新组，新容量并入存储池，最后扩展LUN。LUN扩完到主机侧执行rescan，再做文件系统扩展，Linux在线扩容前确认文件系统类型和版本支持在线操作。扩容的每一步做完都回头看一眼状态，不要一口气点完，中途任一步失败都要先处理干净再继续。

5. AS Manager使用避坑与常见问题排查

5.1 管理页面打不开：问题通常不在AS Manager本身

现象：浏览器输入管理服务器地址一直转圈，或者登录成功后操作超时、刷新又退回登录页。原因里最常见的是管理网段的问题：管理IP被其他设备占用、交换机端口协商异常、VLAN划分错误，其次是管理服务器服务进程僵死，虚拟化部署时虚拟机资源不足很容易触发，还有一类是浏览器兼容性，旧版本界面依赖Java插件，新浏览器默认禁用导致控制台起不来。

解决顺序是：先ping测试管理服务器和两个控制器管理IP，再确认管理服务器系统层的服务进程状态，最后排查浏览器和插件。管理IP冲突是最隐蔽的，这类故障表现为管理口间歇性失联，ping时而通时而不通。处理办法是在交换机上做管理IP的静态ARP绑定，从根上杜绝占用。不要一发现问题就重启管理服务器，先确认网络再动服务，重启有时会把现场线索冲掉。

5.2 主机识别不到LUN：先查映射登记而不是反复扫描

现象：AS Manager里映射状态显示正常，业务主机反复扫描就是看不到磁盘。最常见原因是FC环境的WWN登记错误，多端口HBA卡登记时选错口，光纤交换机zone没划或划错也常见；其次是主机类型选错，存储侧以错误的协议参数响应；还有LUN ID冲突，映射编号和主机已有磁盘编号重叠，部分操作系统直接忽略。

解决：先核对WWN和zone，用HBA厂商工具查出每个FC端口的实际WWN，和AS Manager里登记的一一比对。LUN ID冲突就换个未用编号重新映射。排查顺序固定住，先验证映射定义再决定是否重启主机。重启主机不是解决方案，反而可能把问题从存储侧转嫁到业务停机，无谓拉长故障时间。

5.3 存储性能不达预期：从控制器热点和存储池结构查起

现象：业务反馈数据库写入慢，AS Manager里对应LUN延迟高，但控制器CPU不高、缓存命中率正常。常见原因有三类：存储池RAID类型和业务IO模型不匹配，随机写密集的数据库跑在RAID5上，每次写要触发读改写，延迟天然高；同一池内业务互相干扰，一个LUN的重负载拖慢同池其他LUN；条带参数不当，IO集中在少数盘上形成热点。

解决：用性能视图把延迟拆到磁盘级别，看是整池偏高还是个别盘偏高。整池偏高，考虑迁移LUN到更匹配的池或调整RAID结构；个别盘偏高，先查慢盘再查条带。这类问题先不要怀疑硬件损坏，存储盘故障率其实很低，多数是结构、参数、负载的复合问题，按数据说话定位，不要凭感觉换硬件。

5.4 告警刷屏：先确认链路状态再决定是否换盘

现象：同一块盘或同一个控制器端口反复出现告警、恢复、再告警，邮件通知刷屏。原因可能是管理网络抖动导致管理面通信间歇中断，监控侧看到的是状态抖动的假象；也可能是光纤链路协商不稳，光模块衰减处于临界；还有一种情况是硬盘偶发读写超时，但SMART和自检都正常，属于盘体信号质量边缘问题。

解决：先看告警时间规律。固定间隔优先怀疑监控轮询和管理链路，调整告警抑制窗口，再检查交换机端口和光模块；不固定间隔则优先排查物理链路。硬盘偶发超时不要急着换，连续观察一周，如果出现频率上升再安排更换。误判换盘会导致本来稳定的阵列因为热备重建而短暂降级，反而增加风险。

6. 用好AS Manager的三个习惯：配置备份、定期巡检与稳妥升级

6.1 变更前导出配置：成本最低的后悔药

AS Manager一般支持把存储池、LUN、映射、告警配置导出成文件。我养成的习惯是每次变更前导出一份，变更后再导出一份，按日期版本存放。配置导出只要几分钟，但映射配错、存储池参数误改都有后悔药。配置文件要放到存储系统之外的机器上保存，存到同一台存储上就失去备份意义了。

6.2 每周十分钟巡检：把隐患拦在告警之前

每周固定做一次巡检，清单就几项：控制器状态和角色、电池模块状态、硬盘告警、存储池使用率变化、最近24小时告警记录。顺手把容量趋势记到表格里，两张表比下来，容量耗尽时间和硬盘健康趋势都有迹可循。这十分钟的价值在于，存储故障多数是渐变而不是突发，能看到趋势，就不会被突发告警打个措手不及。

6.3 固件升级的顺序感：先管理软件，再控制器，最后硬盘

固件升级是存储运维里风险最高的操作。我的顺序是先升级AS Manager管理软件，再升级控制器固件，最后根据发布说明决定是否升级硬盘固件。每步升级完验证正常再走下一步；双控制器按交替方式升级，一个升级完成并回切角色后再操作另一个；全程保留配置备份和升级前日志。升级窗口选业务低峰期，避开备份作业时段，升级中途异常第一时间回退，不硬着头皮继续。

做了这些年存储运维，AS Manager上踩过的坑，十有八九不是平台功能缺失，而是操作顺序不对、容量趋势没看、变更前偷懒没备份。把这三个习惯养成，这套存储系统会省心很多。希望这篇笔记对你上手AS Manager有帮助。

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