适用场景

存储出问题的代价通常比服务器大：一台服务器挂了业务还能切，存储挂了所有虚机和数据库一起躺。SAN 运维的核心就三件事：路径别断、盘别同时坏、性能基线心里有数。

配置步骤（存储性能定位）

# 1) 先看是谁在打 IO
pidstat -d 1 5
iotop -o -b -n 2

# 2) 看时延与队列
iostat -x 1 5 | awk '{print $1, $2, $10, $11, $12, $22}'
# 关注：await（毫秒）、aqu-sz（队列深度）、%util

# 3) 区分随机/顺序、读/写
# 随机小 IO 多 -> 数据库；大顺序 IO -> 备份/日志/视频

# 4) 存储侧看前端端口与卷负载
# 控制器管理界面：前端端口 IOPS、卷时延、后端盘组繁忙度

# 5) 常见结论
#  - 时延高但吞吐不高：多为随机 IO 或后端盘组瓶颈
#  - 吞吐高时延也高：可能已接近控制器或链路极限
#  - 单卷热、其他卷闲：存储侧负载不均

关键参数与建议

  • 双控双路径：主机侧多路径（MPIO/multipath）必须启用，两条路径分别走不同交换机
  • RAID 策略：业务盘优先 RAID10 或 RAID6 + 热备盘，热备盘要定期检查是否真的在被使用
  • LUN 映射：命名与用途要能对应到业务（禁止 LUN01/02 这种命名），映射变更要留记录
  • 快照与克隆：快照不是备份，只用于短时回滚；克隆用于测试环境并限制生命周期
  • 性能基线：IOPS、时延（读/写）、队列深度，按月采集，扩容与业务上线前必须复测
  • 告警接入：控制器、电源、风扇、电池、盘、链路、卷容量全部接入统一监控
  • 固件与驱动：控制器固件、HBA 驱动、多路径软件版本要在兼容列表内，升级走变更窗口
  • 容量水位：卷使用率 75% 预警、85% 必须处理，避免写满导致业务异常

容易踩的坑

  • 只看吞吐不看时延，认为「带宽没打满就没问题」
  • 业务慢就扩存储，实际是数据库全表扫描
  • 备份窗口与业务高峰重叠，IO 争抢
  • 只看平均时延，P99 已经飙到几百毫秒
  • 卷映射到同一盘组，互相拖累却找不到原因
  • 没有基线数据，无法判断「现在慢」还是「一直慢」

验证与巡检

# 时延与队列（P95 思路）
iostat -x 1 20 | awk '/sd/{print $1, $10, $22}'

# 应用侧感知
# 数据库：慢查询日志与等待事件
# 虚拟化：虚拟机磁盘时延（datastore latency）

# 存储侧阈值参考
# 全闪：< 3ms；机械盘阵列：< 15ms（读）/ < 25ms（写）
  • 巡检：时延在阈值内、无长期高队列、备份与业务错峰、有季度性能基线

小结

SAN 运维验收：拔掉一条链路业务不中断、单盘故障能自动热备重建、时延基线在阈值内、告警能到人。三项都能实测，才算运维到位。

> 说明：文中命令为通用写法，不同型号/版本可能略有差异，落地前请对照设备实际版本的官方文档；带外管理与安全设备变更建议先在测试设备验证。