企业官网建设流程全解析

1. 为什么“对接”这件事值得单独拿出来讲

做过存储交付的人都有一个共同感受：SAN存储和Linux主机的对接，看起来只是插几根线、装个多路径软件、扫一下盘，但真正在现场翻车的概率高得离谱。我见过太多案例，光纤链路指示灯一切正常，lsscsi却什么都看不到；也见过主机识别到同一块盘出现了八条路径，业务侧一读写就报 I/O 错误；还有更隐蔽的，多路径聚合看起来成功了，结果实际流量全压在一条链路上，性能只有理论值的三分之一。

这篇内容围绕华为SAN存储系统与Linux主机对接展开，把我在实际交付中反复验证过的思路、参数、排查手法完整梳理一遍。核心关键词就是SAN存储、Linux主机、多路径、LUN映射、iSCSI与FC、ALUA、队列深度。它解决的核心问题是：让Linux主机稳定、正确、高性能地识别并使用华为SAN存储上的块设备，并且在链路故障时能平滑切换而不是直接宕机。适合正在做存储交付的工程师、需要给业务系统挂载块存储的运维人员，以及想搞清楚“多路径到底在干什么”的开发同学参考。哪怕你之前只会在图形界面点下一步，跟着下面的逻辑走一遍，也能把这件事做扎实。

我先把结论性的判断放在前面：对接成功与否，不取决于存储侧配置得多漂亮，而取决于主机侧的多路径策略、链路状态和存储侧的LUN映射三者是否严格对齐。任何一环错位，表现出来的症状都可能是“盘看不到”或者“盘能用但很慢”，而这两类问题的排查路径完全不同。下面按设计思路、核心细节、实操过程、问题排查四个层次展开。

2. 整体设计思路与方案选型拆解

2.1 先想清楚：FC还是iSCSI，这不是随便选的

华为SAN存储对接Linux，第一步永远是确定链路类型。主流就两条路：FC（Fibre Channel，光纤通道）和iSCSI（IP SAN）。这两者的选择直接决定了后面主机侧要装什么驱动、配什么参数、排查时看什么日志。

FC的优势在于稳定性和低延迟，协议栈在硬件HBA卡上跑，主机CPU几乎不参与，适合数据库这类对时延敏感的业务。代价是需要独立的交换机、HBA卡和光模块，成本高，而且 zoning（分区）配置一旦出错，排查起来比IP网络麻烦得多。iSCSI的优势是复用现有以太网，成本低、配置直观，但协议栈跑在主机内核里，对网络质量和主机CPU有一定要求，而且必须处理好MTU和流量隔离，否则存储流量和业务流量抢带宽，性能会非常难看。

我的选型经验是这样的：核心交易库、高并发OLTP，优先FC；文件服务、备份归档、测试环境，iSCSI完全够用。如果现场只有以太网条件，iSCSI也能做得很好，前提是把独立网卡、独立VLAN、巨帧这几件事做到位。这里没有绝对优劣，只有场景匹配。

2.2 多路径不是“装了就行”，策略才是灵魂

Linux主机对接SAN，绕不开多路径（Multipath）。原理不复杂：主机到存储之间通常有多条物理链路（双HBA、双交换机、双控制器端口），如果不做聚合，操作系统会把同一块LUN识别成多个独立的块设备（比如/dev/sdb、/dev/sdc其实是同一块盘），业务一旦误操作就是数据灾难。

多路径软件的作用就是把这些“看起来不同的设备”聚合成一个逻辑设备，同时负责路径选择和故障切换。华为官方推荐的是UltraPath，但绝大多数Linux环境用的是内核自带的DM-Multipath（device-mapper multipath），配合华为存储的ALUA（Asymmetric Logical Unit Access，非对称逻辑单元访问）特性工作。我个人的建议是：除非有明确的官方支持要求，优先用DM-Multipath，因为它随内核走、维护简单、社区资料多，出问题好查。

这里有个关键认知：多路径策略决定了性能上限和故障切换行为。常见的策略有round-robin（轮询）、least-pending（最少未完成请求）、queue-length（队列长度）、service-time（服务时间）。华为存储支持ALUA，意味着控制器端口分“优化路径”和“非优化路径”，正确的做法是让多路径识别ALUA并优先走优化路径，而不是无脑轮询。这一点后面在配置里会具体展开。

2.3 LUN映射：主机视角和存储视角必须对齐

存储侧把LUN映射给主机，靠的是主机标识。FC场景下是WWN（World Wide Name），iSCSI场景下是IQN（iSCSI Qualified Name）。这里最容易出的问题是：主机上看到两个HBA端口，就有两个WWN，映射时只加了一个，结果就是“一条链路能用、另一条链路扫不到盘”，多路径自然聚不起来。

所以设计阶段就要明确：每台主机有几个发起端（initiator），存储侧就要把对应的所有WWN/IQN都加入主机组（Host Group）。华为存储的主机组概念很清晰，一个主机组对应一台物理主机（或一组需要共享访问的主机），LUN映射到主机组，主机组里的所有发起端都能看到这块LUN。这个逻辑理顺了，后面基本不会在“看不到盘”上浪费时间。

3. 核心细节解析与实操要点

3.1 主机侧前置检查：别急着扫盘

很多新手拿到环境第一件事就是rescan-scsi-bus.sh，扫不到就开始怀疑存储。我的习惯是先做主机侧的前置检查，把基础条件确认掉，能省掉一半的无效排查。

第一件事是确认HBA卡或iSCSI发起端的状态。FC场景下看/sys/class/fc_host/下的端口状态，port_state应该是Online，port_name和node_name能正常读出。iSCSI场景下用iscsiadm -m session看会话是否建立，iscsiadm -m node看目标发现记录是否正确。这些是“链路层”的健康度，链路不通，后面全是空谈。

第二件事是确认多路径软件的状态。systemctl status multipathd必须是 running，multipath -ll即使暂时没有设备也应该能正常执行不报错。如果 multipathd 没起来，就算扫到盘也是裸设备，聚合不了。

第三件事是确认内核模块。lsmod | grep -E "dm_multipath|scsi_dh"，dm_multipath是多路径的核心模块，scsi_dh_alua是ALUA的设备处理器，华为存储场景下这个模块很关键，没有它多路径就无法正确识别优化路径。

提示：这三步检查建议固化成脚本，每次对接前跑一遍，比事后翻日志高效得多。我自己的习惯是把检查项写成一个 checklist，逐项打勾，避免遗漏。

3.2 多路径配置文件的关键参数

DM-Multipath的核心配置文件是/etc/multipath.conf。这个文件默认可能不存在或者全是注释，需要自己写。下面是我在华为存储场景下常用的配置骨架，参数含义逐条说明：

defaults { user_friendly_names yes find_multipaths yes path_grouping_policy group_by_prio path_selector "service-time 0" failback immediate no_path_retry 5 rr_min_io_rq 1 max_fds 8192 } devices { device { vendor "HUAWEI" product "XSG1" path_grouping_policy group_by_prio path_selector "service-time 0" path_checker tur prio alua failback immediate no_path_retry 5 dev_loss_tmo 60 fast_io_fail_tmo 5 } }

逐条解释为什么这么配。path_grouping_policy group_by_prio配合prio alua，意思是按ALUA优先级分组，优化路径一组、非优化路径一组，正常走优化路径，故障时切到非优化路径。这比无脑round-robin更符合华为存储的硬件特性，因为非优化路径要跨控制器，延迟更高。

path_selector "service-time 0"是按服务时间选择路径，0表示动态计算，它会把I/O发给当前响应最快的路径，比固定轮询更适应实际负载波动。failback immediate表示路径恢复后立即切回，适合对延迟敏感的业务；如果业务对路径抖动敏感，可以改成failback 30之类的延迟回切。

no_path_retry 5是个容易踩坑的参数。它表示所有路径都失效时，重试5次后把I/O标记为失败，而不是无限排队。设成queue会让I/O一直挂着，业务表现为“卡死”；设成较小的数字则快速失败，业务层能感知到错误并做处理。这个值要根据业务容忍度来定，数据库类业务我一般设5到10。

dev_loss_tmo 60和fast_io_fail_tmo 5是一对配合参数。前者是设备丢失后多久从系统移除，后者是I/O快速失败的超时。fast_io_fail_tmo必须小于dev_loss_tmo，否则快速失败机制不生效。这两个值设得太大会导致故障切换慢，设得太小可能误判瞬时抖动，5和60是我实测下来比较平衡的组合。

注意：vendor和product字段必须和存储实际上报的一致，用multipath -ll或cat /sys/block/sdX/device/vendor确认。写错了这段device配置根本不生效，多路径会走defaults，行为可能不符合预期。

3.3 ALUA优先级与路径分组的关系

ALUA这个概念值得单独说清楚，因为它是华为存储多路径性能的关键。简单类比：存储有两个控制器A和B，一块LUN在某一时刻“归属”其中一个控制器（比如A），从A的端口访问是优化路径，从B的端口访问是非优化路径。非优化路径不是不能用，而是要经过控制器间的内部转发，延迟更高。

DM-Multipath通过prio alua读取存储上报的ALUA状态，自动把优化路径分到高优先级组，非优化路径分到低优先级组。multipath -ll的输出里能看到prio=50（优化）和prio=10（非优化）这样的标记，status=active的组就是当前使用的组。

这里有个实操要点：如果发现所有路径的prio都一样，说明ALUA没生效。常见原因是scsi_dh_alua模块没加载，或者存储侧没开启ALUA。这时候多路径会退化成普通轮询，性能会打折扣。排查方法是cat /sys/block/sdX/device/alua_state，正常应该能看到active/optimized或active/non-optimized。

3.4 LUN映射的粒度与共享控制

存储侧映射LUN时，华为存储的主机组机制支持精细控制。我的建议是一台主机一个主机组，不要图省事把多台主机塞进一个组，除非业务确实需要共享访问同一块LUN（比如集群文件系统）。原因很简单：主机组是访问控制的最小单位，混在一起会导致A主机能看到本该只给B主机的LUN，既不符合最小权限原则，也容易在故障时误判。

映射完成后，主机侧扫盘的正确姿势是：

# 重新扫描SCSI总线 rescan-scsi-bus.sh -r # 或者针对特定host扫描 for host in /sys/class/scsi_host/host*/scan; do echo "- - -" > $host; done # 重新加载多路径映射 multipath -r # 查看聚合结果 multipath -ll

rescan-scsi-bus.sh -r的-r表示移除已消失的设备再重新扫描，比单纯扫描更干净。手动往scan文件写- - -是通配扫描，三个字段分别是channel、target、LUN，全用通配符表示扫全部。扫完后multipath -r让多路径重新读取，最后multipath -ll确认聚合结果。

4. 完整实操过程与关键环节实现

4.1 FC场景从零到可用的完整流程

假设现场是双HBA、双交换机、存储双控的典型FC组网。第一步在存储侧创建LUN并加入主机组，主机组的发起端要填两个HBA的WWN。WWN在主机上用cat /sys/class/fc_host/host*/port_name获取，注意格式是0x开头的16位十六进制，填到存储侧时去掉0x。

第二步在交换机上做zoning。原则是单initiator对单target，即每个HBA端口单独一个zone，zone里只放一个存储控制器端口。这样做的目的是隔离故障域，一个zone出问题不影响其他路径。zone配好后确认交换机上zoneshow能看到生效配置，主机侧cat /sys/class/fc_host/host*/port_state全部Online。

第三步主机侧加载多路径并配置multipath.conf，然后扫盘。扫盘后multipath -ll应该看到每块LUN一个mpath设备，下面挂着多条路径，路径状态active ready或active ghost（非优化路径）。如果只看到一条路径，回到zoning和主机组检查。

第四步验证故障切换。这是很多人跳过但极其重要的一步。手动禁用一条路径（echo offline > /sys/block/sdX/device/state），观察multipath -ll里该路径变成failed，业务I/O是否正常继续。再恢复路径，确认failback生效切回。这个演练做一遍，心里就有底了。

4.2 iSCSI场景的差异化配置

iSCSI的流程前半段不同。主机侧先装iscsi-initiator-utils，启动iscsid和iscsi服务，用cat /etc/iscsi/initiatorname.iscsi拿到IQN，填到存储侧主机组。然后发现目标：

iscsiadm -m discovery -t sendtargets -p <存储业务IP>:3260 iscsiadm -m node -T <target IQN> -p <存储业务IP>:3260 --login

登录后iscsiadm -m session能看到会话。这里的关键差异是网络层要配好：独立网卡、独立VLAN、MTU 9000巨帧（存储侧和交换机侧都要配一致），并且关闭该网卡的ARP过滤等可能干扰的特性。巨帧没对齐是iSCSI性能差的头号原因，ping -M do -s 8972可以验证端到端巨帧是否通。

iSCSI的多路径配置和FC基本一致，区别在于path_checker可以用tur或readsector0，以及dev_loss_tmo可以适当调大，因为IP网络的抖动比FC更常见。另外iSCSI建议开启node.session.timeo.replacement_timeout的合理设置，配合多路径的no_path_retry一起控制故障行为。

4.3 文件系统与挂载的收尾细节

多路径聚合出/dev/mapper/mpathX之后，才轮到分区和文件系统。这里有个原则：永远对/dev/mapper/下的设备操作，不要对/dev/sdX操作。因为sdX是单条路径的裸设备，重启或链路变化后编号可能变，而mpathX是稳定的逻辑设备。

分区用parted而不是fdisk，因为大于2TB的LUNfdisk处理不了。parted /dev/mapper/mpathX mklabel gpt建GPT分区表，然后mkpart建分区。文件系统按业务选，XFS适合大文件和高并发，ext4通用性好。格式化后写入/etc/fstab时，用UUID而不是设备名，blkid /dev/mapper/mpathXp1拿UUID，避免设备名变化导致挂载失败。

挂载参数里nofail建议加上，避免存储暂时不可达时主机启动卡在挂载阶段。_netdev对iSCSI场景也建议加，表示等网络就绪后再挂载。这两个参数是很多“重启后主机起不来”事故的解药。

5. 常见问题与排查技巧实录

5.1 问题速查表

5.2 三个我踩过的坑

第一个坑是主机组漏加WWN。早期做FC对接，主机两个HBA只加了一个WWN到主机组，结果扫盘只看到一半路径，多路径聚合出来的设备路径数不对。当时以为是zoning问题，查了半天交换机，最后回到存储侧对比才发现。教训是：映射前先把主机所有发起端列出来，逐个核对，别凭印象。

第二个坑是**fast_io_fail_tmo大于dev_loss_tmo**。这两个参数设反了，快速失败机制完全不生效，链路断开后I/O挂了几分钟才报错，业务侧表现为“假死”。后来养成习惯，配完多路径一定用multipathd show config确认参数实际生效值，而不是只看配置文件写了什么。

第三个坑是iSCSI巨帧只配了一端。主机网卡设了MTU 9000，交换机没设，存储侧也没设，结果大包被分片，吞吐反而比标准MTU还低。用ping -M do -s 8972一测就露馅。巨帧这件事，端到端任何一环没对齐都是白配，必须逐跳验证。

5.3 排查的通用心法

对接类问题的排查，我的经验是从下往上、从物理到逻辑。先看物理链路（光模块、网线、指示灯），再看链路层（FC的port_state、iSCSI的session），再看SCSI层（lsscsi、/sys/block），最后看多路径层（multipath -ll）。每一层确认健康再往上走，不要跳层猜。很多“多路径不聚合”的问题，根子其实在更下面的链路层。

另外，日志要看对地方。dmesg看内核层的SCSI扫描和错误，journalctl -u multipathd看多路径守护进程的动作，存储侧看告警和主机连接状态。三边日志对时间戳，往往能快速定位是哪一侧先出的问题。我习惯在对接完成后把三边的关键日志各存一份基线，后续出问题有对比参照。

6. 性能调优与长期维护的几个实操建议

对接完成只是开始，长期稳定运行还需要一些调优和维护动作。队列深度方面，/sys/block/dm-X/queue/nr_requests和/sys/block/dm-X/queue/scheduler值得关注，数据库类业务把调度器设为none（或mq-deadline）通常比默认的cfq类调度更合适，减少不必要的I/O合并开销。nr_requests根据业务并发适度调大，但不要盲目拉满，否则可能加剧存储侧压力。

监控上，multipathd show paths和multipathd show maps可以脚本化采集，重点盯路径状态变化和failback次数。路径频繁在active和failed之间抖动，往往预示光模块老化或线缆接触不良，早发现早处理。存储侧的主机连接状态和端口误码率也要纳入监控，误码率上升是链路劣化的早期信号。

维护窗口里做固件升级或控制器切换前，务必确认多路径的failback和no_path_retry配置能扛住控制器重启的窗口期。我一般会在升级前手动做一次路径切换演练，确认业务无感知，再动存储侧。这个习惯帮我避免过好几次升级期间的业务中断。

我个人在实际操作中的体会是，SAN对接这件事，配置本身不难，难的是对“为什么这么配”的理解。把ALUA、多路径策略、超时参数这三者的关系吃透，大部分现场问题都能自己推演出原因。最后再分享一个小技巧：每次对接完成后，把multipath -ll的完整输出、multipath.conf、主机WWN/IQN清单、zoning配置各存一份归档，下次同类环境直接对照，能省掉大量重复劳动。