简介：《华为S2600T维护手册》面向互联网行业IT运维人员与初次接触华为OceanStor T系列存储的管理员，针对S2600T在实际项目中如何管理、配置与维护设备这一问题提供操作指引。压缩包内为1个pdf文件，整体约545KB，内容围绕集成存储管理软件ISM展开，从设备发现、状态监控到资源配置均有讲解，并辅以故障监控与告警管理的思路说明。手册的具体价值在于把基础业务配置拆解为可直接照做的流程：通过浏览器登录ISM并处理安全证书提示，指定IP地址发现设备；创建RAID组时以RAID6为例，预留最后一块硬盘作为热备盘，在成员盘故障时自动接管数据；随后在RAID组中划分LUN、创建主机组与主机、添加iSCSI启动器并完成LUN映射，形成视频监控场景下的存储供给闭环。文中还提醒默认账号密码的保管要求，避免资源被误删影响业务。目前已有516人学习，适合存储初学者按图索骥上手。
1. 华为S2600T维护手册到底在维护什么
一台华为 S2600T 安安静静待在机柜里，平时谁也不会想起它。真正让人半夜被电话叫醒的情况无非三种：前面板某个盘位转黄灯、主机侧业务开始报 I/O 超时、管理界面弹出一条没人看得懂的告警。S2600T 属于 2U 双控入门级阵列，常见配置是 12 个盘位，后端走 SAS 环路，前端是若干千兆 iSCSI 口或 8Gb FC 口——这条链路上一共站着存储、主机、交换机三个角色，维护手册的价值在于把这三层信息对齐到同一张表上。
只盯其中一层最容易误判：盘已经由热备自动顶替并重建完，主机侧还在喊超时，那问题大概率不在硬盘；反过来，存储侧满眼绿灯，交换机某个端口的 CRC 错误却在悄悄往上涨，这是链路问题。这篇写给手上真有一台 S2600T 的运维和机房工程师，也写给接手了别人留下的老存储、手里只剩一个管理 IP 和一句"没密码"的人。
2. 吃透华为S2600T的硬件视图与CLI：盘位、控制器、LUN怎么对应
S2600T 的排错速度，八成取决于你能不能在两分钟内把"前面板第几个灯亮"翻译成"CLI 里哪一块盘、属于哪个 RAID 组、映射给哪台主机"。这一章先把硬件语言和命令行语言对上，再谈巡检和故障。
2.1 前面板与后视图上的灯，先说真话
前面板 12 个盘位，每个盘位一颗状态灯加一颗活动灯。绿灯常亮是在线、绿灯闪烁是有读写、黄灯常亮是故障或预测故障、灯灭是空槽位或没被配进 RAID 组。这个区分很关键：把"正在重建的盘"和"已经坏掉的盘"混在一起看，很容易把还能用的盘拔下来。
后视图要看三处：控制器 A/B 上的 ALM 告警灯、电源模块和风扇模块的指示灯、BBU（电池备份单元）的充电/失效指示。控制器 ALM 红灯往往意味着发生过主备切换，此时业务可能还活着，但性能和管理路径会受影响。BBU 黄灯通常不致命，却会让写缓存策略从回写自动降到写穿，业务侧表现为写入变慢。
| 位置 | 灯态 | 含义 | 该做什么 |
|---|---|---|---|
| 盘位状态灯 | 绿常亮 | 在线、已加入 RAID 组 | 无需动作 |
| 盘位状态灯 | 绿闪 | 有读写活动 | 无需动作 |
| 盘位状态灯 | 黄常亮 | 故障或预测故障 | 到 CLI 核对状态，确认热备是否已顶替 |
| 盘位状态灯 | 灭 | 未配置或空槽位 | 核对是否掉盘、是否被人误拔 |
| 控制器 ALM | 红 | 控制器告警或离线 | 检查是否发生主备切换、管理口是否可达 |
| BBU | 黄 | 充电中或需更换 | 确认缓存写策略是否已回退为写穿 |
2.2 三种登录方式：串口、SSH 与管理客户端
S2600T 的入口通常有三条：机箱后部的 RJ45 console 串口、控制器管理网口的 SSH、以及在 PC 上安装的图形管理客户端。串口是保底手段，管理网口 IP 忘了、SSH 被关了，就只能靠它；串口参数常见是 115200-8-N-1、无流控。
# 方式一：串口登录（Windows 用 SecureCRT / putty 连 COM 口，Linux 用 minicom） minicom -D /dev/ttyUSB0 -b 115200 # 方式二：管理网口 SSH，账号体系随交付批次不同，以现场交付文档为准 ssh admin@192.0.2.10 # 登录成功后第一件事不是敲命令，而是把命令树列出来 help ?不同固件版本对同一条命令的拼写、层级、参数都可能不一样，凭记忆敲是新手最容易翻车的地方。先help或?把命令树打出来，再决定用哪条，这个习惯能省掉大量"命令不存在"的来回。如果连口令都没有，优先找交付时的验收文档或原厂报修渠道重置，不要试图暴力尝试，触发账号锁定反而更麻烦。
2.3 盘位号、控制器号、LUN ID 的对应关系
看输出的时候，最容易卡住的是编号体系。S2600T 的双控结构决定了同一条 LUN 在同一时刻只由 A 或 B 其中一个控制器"归属"（owning controller）提供服务，另一个控制器通过心跳和路径冗余接管。理解这一点，才能解释为什么"主机侧只看到一条路径"和"LUN 不可访问"是两类不同的问题。
| 层级 | 常见命名 | 说明 |
|---|---|---|
| 机箱 | CTE0 / Enclosure 0 | 单台 S2600T 通常只有一个 2U 机箱 |
| 槽位 | 0 ~ 11 | 前面板从左到右，与盘位灯一一对应 |
| 控制器 | A / B | 各持有一组前端端口，主备角色可切换 |
| RAID 组 | RG0、RG1… | 由若干槽位组成，RAID 5/6/10 |
| LUN | LUN0、LUN1… | 映射给主机，归属某个控制器 |
| 主机 | Host 别名 | 由 iSCSI IQN 或 FC WWPN 唯一标识 |
2.4 用只读命令固化一份资产基线
接手一台老存储，第一件事不是优化，而是留证据。把只读状态命令的输出按日期存成文本，日后盘坏了、性能掉了、别人改过配置，你手里有对比基准。
#!/bin/bash # 采集 S2600T 只读状态基线，文件名带日期，方便逐日 diff DATE=$(date +%F) OUT=/var/log/s2600t_baseline_${DATE}.txt # 逐条执行只读命令并落盘；ssh 免密需提前用 ssh-keygen + ssh-copy-id 配好 for CMD in "show system" "show controller" "show disk" "show raidgroup" \ "show lun" "show host" "show port"; do echo "===== ${CMD} =====" >> "$OUT" ssh -o ConnectTimeout=10 admin@192.0.2.10 "$CMD" >> "$OUT" 2>&1 done echo "baseline saved to ${OUT}"这段脚本里，ConnectTimeout=10防止某条命令卡住把整轮采集拖死；>>用追加而不是覆盖，避免中途失败丢掉前面已经采到的内容；命令全部是只读的，不会改动 RAID 组或映射关系。实际执行时若某个固件版本不支持其中某条命令，脚本会在对应小节留下报错，正好当作版本差异记录——这比事后凭印象回忆"当时那条命令是不是支持"靠谱得多。采集完把文件放一份到存储之外的机器上，别只留在跳板机里。
3. 华为S2600T日常巡检：CLI、多路径、交换机三层怎么查
巡检的目的不是打卡，是在故障发生前把"渐变项"揪出来：预测故障计数在涨、某条路径长期不活动、某个端口错包在累积。这三类问题在出事之前都不会告警，只能靠主动比对。
3.1 五分钟硬件巡检清单
到机房先不碰键盘，眼睛和耳朵过一遍：盘位有没有黄灯、后视图电源和风扇指示灯是否全绿、风扇声音有没有异常高频、控制器 ALM 是否亮红。然后打开管理界面看当前活动告警列表，重点关注是否有人为屏蔽或确认过的告警——老设备上"已确认"的告警堆了一屏，其中往往埋着真实故障。
最后是 CLI 侧的四条基础命令，覆盖系统、控制器、电源与电池：
show system # 系统整体状态、运行时间、是否有告警 show controller # 主备角色、缓存写策略、控制器健康 show power # 电源模块状态与冗余情况 show battery # 或 show bbu，看电池健康与充电状态顺序上先看整体再看局部，避免一上来就陷进某一颗盘的细节里。硬件巡检的结论要落到一句话："目前有没有正在降级的部件"，而不是"我看了灯都正常"。
3.2 存储侧：把 show 命令的输出变成判定结论
光把命令敲一遍没意义，得知道哪些字段值得盯。硬盘要看健康状态和预测故障标记，RAID 组要看当前是 Normal、Rebuilding 还是 Degraded，前端端口要看速率协商结果和收发状态，缓存要看写策略是否仍为回写。
| 检查项 | 正常 | 需关注 | 需立即处理 |
|---|---|---|---|
| RAID 组状态 | Normal | Rebuilding | Degraded 且无可用热备 |
| 硬盘预测故障 | 无标记 | 计数持续增长 | 已报故障 |
| BBU / 电池 | 健康且充满 | 充电中 | 失效或需更换 |
| 缓存写策略 | 回写 | — | 已回退为写穿 |
| 前端端口 | 双口均有流量 | 单口长期无流量 | 端口全部中断 |
判定阈值不是拍脑袋定的：RAID 组进入 Rebuilding 说明冗余已经短暂失去，此时性能下降和二次故障风险同时上升；写策略从回写变写穿，说明缓存保护失效，写入性能可能掉到原来的一半以下。这两项一旦出现，巡检结论就不能写"正常"。
3.3 主机侧：UltraPath 与 multipath 会话核对
存储侧一切正常，业务照样可能报错，因为瓶颈常常在主机侧的多路径上。华为主机侧的多路径软件提供upadmin系列命令，原生 Linux 环境则用multipath和iscsiadm交叉验证。
# 华为 UltraPath 侧：看虚拟 LUN、路径状态、发起端 upadmin show vlun # 每条 LUN 对应的虚拟设备 upadmin show path # 关键：每条路径的状态与优先级 upadmin show initiator # 本机 IQN / WWPN，用于和存储侧 Host 记录比对 # Linux 原生侧交叉验证 multipath -ll # 各 mpath 设备的路径数与状态 iscsiadm -m session -P 3 # iSCSI 会话详情，含每条的连接状态判断标准很直接：一条 LUN 在正常情况下至少应有两条路径处于 Active/Optimized 状态，只看到一条就是单点，网络抖一下就断业务。upadmin show initiator输出的 IQN 要和存储侧show host里记录的一致，不一致意味着重装系统或换过 HBA 卡，映射关系已经失效，这时候怎么重启主机都没用。
3.4 交换机侧：iSCSI 链路要看的错包计数
前端走 iSCSI 的场景，链路一定穿过交换机，存储和主机都看不见的物理层问题只能在这里发现。华为交换机的运维习惯里，端口错包计数是第一优先级：
# 登录华为交换机，查看对接存储/主机的具体端口 display interface GigabitEthernet 0/0/24 display interface brief | include up重点看三个数：CRC 错误、丢弃包（discard）、光模块收发光功率。CRC 持续增长说明线缆、模块或对端口有问题，这不是存储能修的；收发光功率接近临界值则是"还没坏但快了"的典型信号，比等它彻底断链再排查从容得多。把这些计数和存储侧端口状态并排记录，就能区分"存储端口假死"和"链路质量差"。
4. S2600T故障处置：单盘失效、链路降级、LUN不可访问
前面都是预防，这一章是动手。三类高频故障的处理路径差别很大，共同点是：先确认冗余还在不在，再决定动作快慢。
4.1 单块硬盘失效：从告警到重建完成的完整动作
硬盘失效是最常见也最容易被处理错的一类。正确顺序是先在 CLI 确认该盘状态和所属 RAID 组状态，再确认热备盘是否已经顶替、重建是否已经启动，最后才谈换盘。
show disk # 找到黄灯对应的槽位，确认状态为故障 show raidgroup # 确认 RAID 组是 Rebuilding 还是 Degraded show event log # 或 show alarm，看最近事件，确认是否有多次掉盘记录如果 RAID 组显示 Rebuilding，说明热备已经上工，此时最该做的是什么都别拔。重建期间阵列处于无冗余或低冗余状态，RAID 5 再坏一块就是数据丢失，能先把备份跑起来就先跑备份。等重建完成、状态回到 Normal，再按槽位号更换故障盘，换盘时确认新盘容量、转速、接口类型与原盘匹配，型号不同要先确认兼容性。
提示：更换前一定要核对槽位号。S2600T 前面板的物理位置和 CLI 里的槽位号通常一一对应，但机柜里装了多台设备时，看错机箱、拔错机器的事故并不罕见。
如果 RAID 组直接是 Degraded 且没有热备盘顶替，说明冗余已经失去且没有自动修复能力，这时动作要快：立刻确认备份状态，准备同规格备件，并联系原厂确认当前状态下在线换盘的安全边界。不同固件版本对"重建中是否允许其他操作"的限制不一样，拿不准就别动。
4.2 链路降级与 iSCSI 掉线：先分清是网络还是存储
主机报 I/O 超时，第一反应不是重启存储，而是分清故障域。从主机侧 ping 存储前端口，能通说明 IP 层没问题，再看多路径里是不是只剩一条路径在工作。
# 主机侧：确认到存储前端口的连通性 ping -c 5 192.0.2.20 ping -M do -s 8972 192.0.2.20 # 若启用巨帧，用大包探测 MTU 是否一致 # 再看多路径状态，判断是单路径抖动还是全断 upadmin show pathping -M do禁止分片、-s指定包大小，是验证两端 MTU 是否一致的常用手段。如果是启用了巨帧的环境，一端 9000、另一端 1500，小包能通、大包全丢，表现就和"时好时坏"一模一样，很容易被误判成存储不稳定。若连通性正常而路径数只剩一条，问题多半在交换机端口或线缆，回到上一章的错包计数去查。
4.3 LUN 不可访问：映射、CHAP、多路径三点排查
"主机看不到 LUN"和"看得到但 I/O 报错"是两回事，排查方向不同：
| 现象 | 优先检查 | 常见原因 |
|---|---|---|
| 主机完全看不到 LUN | 存储侧 Host 映射 | initiator IQN/WWPN 变了，映射失效 |
| 看得到 LUN 但 I/O 报错 | 多路径路径状态 | 只有单路径，链路抖动后未恢复 |
| iSCSI 登录失败 | CHAP 认证配置 | 密码不一致或认证模式改了 |
| 只有部分主机受影响 | 该主机的 Host 记录 | 别名冲突或多主机共用同一 initiator |
排查顺序建议从存储侧往主机侧走：先在存储上确认 LUN 存在、已映射给对应 Host、LUN 归属的控制器在线；再到主机侧核对upadmin show initiator与存储记录是否一致；最后检查 CHAP 配置和 iSCSI 会话建立过程。反过来从主机日志开始翻，往往会绕远路。
4.4 BBU 失效后写策略变写穿，性能掉一半怎么解释
BBU 或超级电容的职责是在意外断电时把缓存中的数据保住。一旦它失效，阵列会把写策略从回写降级为写穿——写操作必须落到盘上才返回确认，不再经过缓存加速。业务侧的感受就是写入延迟明显升高、吞吐下降，而所有硬件指示灯可能只是后视图一个黄色小灯。
处理路径是先更换电池模块，等充电状态回到健康、写策略恢复为回写，再观察性能是否回升。不要在电池未恢复的情况下手工强行改回回写策略，那等于把缓存里的数据暴露在断电丢失风险下。这一步的判断依据要看 CLI 返回的电池健康与充电状态字段，而不是只看灯。
5. 进阶：配置备份、固件升级与换盘的安全窗口
到这一步，设备已经在稳定运行，剩下的是怎么让下一次故障处理更省事。
5.1 配置与映射关系备份
存储最贵的不是硬件，是那份映射关系。把它导出并离线保存，等于给未来的自己留了一条退路。
# 导出当前配置（命令名随固件版本不同，先用 help 确认） show host # 主机别名与 initiator 清单 show lun # LUN 与归属控制器 show port # 前端端口 IP / WWPN show raidgroup # RAID 组构成与热备策略把这几条的输出连同交换机侧的 zone 配置、主机侧的upadmin show vlun结果一起打包归档，文件名带日期。恢复场景下，你需要的往往不是"存储配置文件的二进制"，而是"哪条 LUN 原来映射给哪个 initiator"这种可读信息。
5.2 固件升级与换盘前的检查清单
| 动作 | 升级前必查 | 换盘前必查 |
|---|---|---|
| 冗余状态 | 双控均在线、无降级 | RAID 组处于 Normal，无正在进行的重建 |
| 数据保护 | 关键业务已备份 | 关键业务已备份 |
| 兼容性 | 控制器/硬盘固件与目标版本匹配 | 备件容量、转速、接口类型一致 |
| 窗口 | 业务低峰，双控逐个升级 | 业务低峰，避开批处理时段 |
| 回退 | 确认可回退到当前版本 | 保留原盘，确认不立即销毁 |
升级采用双控逐个进行的方式，升级期间单控运行，性能和冗余都会临时下降，必须挑业务低谷。硬盘固件升级则更要谨慎，它对盘上数据有直接影响，做之前确认原厂给出的兼容性与步骤说明。
换盘和下电之前，把 LUN 归属控制器、主机侧多路径状态、交换机对应端口号先抄在一张纸上或存进一个文本文件里，事后对着看，比翻半小时日志快得多；这张纸同时也是下次交接时最省口舌的材料。
本文还有配套的精品资源，点击获取
