san交换机端口利用率超限告警

san交换机端口利用率超限告警

以下来源@ds，记录于2026年10月28日。

需求

1运维时发现，光纤换机连接存储4个前端端口的其中一个口的利用率超80%（8G hba模块），这个走的是fc san存储网络，另一端是rac物理机。每次告警都出现在晚上的特定时间，例如2点-2点30。请问这个该如何排查呢？
2
3我能想到的是，是不是rac机器multipath的配置有问题呀，到底配置的是主备呢，还是轮训呢？（因为关于rac这里的模式选择我不是很懂）
4
5请根据以上问题给我说明下。

端口利用率在特定时间点飙升，确实会首先让人怀疑多路径配置。不过，结合“夜间特定时段”这个特征，问题的根源往往是多路径策略、物理链路健康度与夜间定时任务I/O突增三者叠加的结果。下面从排查思路和RAC多路径模式两个层面来说明。

🔍 如何排查：从“策略”到“链路”再到“负载”的递进路径

步骤一：确认当前多路径策略是否“名实相符”

你的怀疑方向是对的，首先要确认RAC节点上多路径的实际工作模式。

在RAC节点上执行 multipath -ll，观察输出中几个关键字段：

• path_grouping_policy：如果是 failover，表示主备模式（一个优先级组只有一条活跃路径）；如果是 multibus，表示所有有效路径在同一个组内，具备负载均衡的基础条件。
• path_selector：即使策略是 multibus，实际选路算法也可能导致不均。round-robin 0 是轮询，service-time 0 或 queue-length 0 会动态选择“服务时间最短”或“队列最短”的路径。
• 路径状态：检查是否有多条路径显示 active ready running，且分布在不同HBA端口上。如果某一个HBA下的多条路径虽然存在，但实际I/O几乎为零，说明负载没有真正“散”出去。

如果配置为 failover，那么所有I/O默认集中在一侧HBA的路径上，夜间定时任务一来，单端口利用率冲到80%+就不足为奇了。如果配置了 multibus 但仍然不均，则要进入步骤二。

步骤二：检查物理链路是否存在“隐性降级”

这是最容易被忽略、却常常是直接元凶的一环。多路径软件在检测到某条路径的物理层不稳定时（如SFP光模块老化、光纤线缆污染、交换机端口B2B credit耗尽），会主动避开该路径，把I/O集中到“健康”的那条路径上。

此时从操作系统层面看，所有路径可能都显示 active，但实际上I/O几乎全走了其中一条。VMware环境下的类似案例中，单HBA承担了90%以上的I/O，而另一条“健康”路径几乎空闲。

排查动作：

1. 检查RAC节点系统日志：dmesg 或 /var/log/messages 中是否有 Link Flaky、SCSI reset、I/O error、timeout 等字样。夜间定时任务触发I/O压力时，不稳定的链路更容易暴露问题。
2. 检查HBA端口统计：关注 Loss of Signal、Invalid Tx Word、CRC Error 等计数是否在夜间告警时段前后出现增量。
3. 在SAN交换机侧查看端口误码：Brocade/Cisco交换机上检查该端口是否有 enc_out、crc_err、link_fail 等异常增长。如果端口有物理层错误，多路径会“用脚投票”，把负载推向另一侧。

步骤三：确认夜间2:00–2:30到底在跑什么

“特定时间”是这条线索中最有价值的锚点。必须把这个时间窗口内的I/O来源找出来，否则调优多路径也只是治标。

• 数据库层：查看该时间段的AWR报告，重点关注 log file sync、log file parallel write、direct path read/write 等等待事件是否同步升高。已有案例显示，凌晨2点启动的存储过程导致 direct writes 从0激增至数万，缓冲获取量暴增，存储I/O随之飙升。
• 操作系统层：检查 crontab（包括 oracle 用户的定时任务）、/etc/cron.d/、外部调度工具（如Control-M、Autosys）是否在该时段触发了备份、统计信息收集、批处理作业或数据抽取任务。
• 存储层：如果是备份窗口，确认备份数据流是否被限制在单一HBA路径上。某些备份软件在多路径环境下可能未能正确利用所有路径。

步骤四：交叉验证——策略是否放大了突发I/O的冲击

在确认了夜间I/O突增的来源之后，再回头看多路径策略。failover 模式下，突发I/O的全部压力都由一组路径承担，单端口利用率突破80%是必然结果。即使改为 multibus + round-robin 0，如果I/O是短时脉冲式爆发，轮询粒度（rr_min_io / rr_min_io_rq）设置不当，也可能在短时间内仍集中在某条路径上。

⚙️ RAC多路径模式：主备（failover）与负载均衡（multibus）到底怎么选

Failover（主备模式）：高可用优先，而非性能优先

path_grouping_policy failover 的含义是：每条路径独立成一个优先级组，操作系统只使用优先级最高的那一组中的一条路径，其余路径作为待命备份，仅在活跃路径故障时才接管。

• 优点：行为确定，路径切换逻辑简单，避免了多路径在多个节点间“乒乓”争抢路径的复杂性。部分Oracle/SLES历史文档在RAC场景下推荐 failover，并配合 failback manual 来防止路径频繁回切造成抖动。
• 缺点：日常所有I/O只走一条（或一组）HBA路径，其他HBA端口完全空闲。这正是“4个前端端口只有一个忙”的典型表现。夜间定时任务I/O一旦上来，单端口利用率很容易冲高。

Multibus（多总线 / 负载均衡模式）：性能优先，但需要选对“选择器”

path_grouping_policy multibus 将所有有效路径放入同一个优先级组，然后由 path_selector 决定每条I/O走哪条路径。它才具备真正的负载均衡能力，但效果取决于选择器：

在RAC环境中，multibus + service-time 0（或 round-robin 0）是更常见的高性能配置方向，尤其是在存储阵列支持ALUA、路径性能对等的前提下。但需要注意：RAC的Clusterware对I/O延迟敏感，多路径的路径检查策略（path_checker）应优先使用 tur（Test Unit Ready），它对qdisk和voting disk的干扰最小。

关于“RAC里到底选哪个”的核心结论

没有脱离场景的绝对“正确模式”，但针对你当前的现象，failover 是一个需要重点审视的配置。 如果确认当前是 failover，且业务对存储带宽有明确需求（夜间定时任务I/O量可观），那么将策略调整为 multibus 并配合合适的 path_selector，是让4个前端端口都参与工作的前提。但如果调整后仍然只有单端口繁忙，问题就不在多路径策略，而回到了步骤二的物理链路降级——多路径软件在“避开”它认为不健康的路径。

推荐排查顺序：先通过 multipath -ll 确认现状 → 查SAN交换机端口误码和系统日志排除物理层降级 → 定位夜间定时任务的I/O来源 → 最后再评估是否需要调整 path_grouping_policy 和 path_selector。直接改多路径配置而不先排除链路问题，可能会把原本被“避开”的不稳定路径重新纳入I/O分发，反而引发更严重的性能抖动。

8G hba模块速率

光纤换机连接存储4个前端端口的其中一个口的利用率超80%（8G hba模块），这个8G hba模块速率是多少呢？

8G FC（8Gbps Fibre Channel）HBA/模块的单端口速率要分“标称线速”和“有效吞吐”两个口径看：

所以，8G HBA 单端口理论标称是 8Gbps，编码后有效数据带宽约 6.8Gbps，约 850MB/s；实际能跑到的业务吞吐通常在 800MB/s 左右。

你看到的“端口利用率超 80%”要确认统计口径：

• 如果按 8Gbps 标称/线速统计：80% ≈ 6.4Gbps ≈ 800MB/s，已经接近 8G 单口实际上限，属于很高负载。
• 如果按 6.8Gbps 有效带宽统计：80% ≈ 5.44Gbps ≈ 680MB/s，也比较高，但还没到极限。
• 如果交换机侧按 8.5Gbps 线速统计：80% ≈ 6.8Gbps ≈ 850MB/s，基本就是编码后有效带宽上限。

结合你前面说的“4 个前端端口只有 1 个口超 80%”，如果这个 80% 是按 8G 端口线速算的，那这个口在夜间定时任务窗口已经接近单口饱和。这也进一步说明：要么多路径没有把负载分散到 4 个端口，要么其他路径被多路径软件判定为不健康而避开了，要么夜间 I/O 突增集中到了这一条路径上。排查时建议同时确认 SAN 交换机端口利用率的统计口径是“收/发单向”还是“双向合计”，以及是否按线速还是有效带宽计算。