企业官网建设流程全解析

简介：面向VMware vSphere虚拟化平台运维与存储工程师，提供一套来自某大厂实际生产环境的存储在线切换迁移完整方案，解决存储设备升级、容量调整或容灾切换中必须保持虚拟机业务不中断的难题。方案内容共5章，从迁移前必读的适用场景与注意事项入手，详细列出基础信息统计、机房布线、ESXi主机光纤卡更换、系统状态检查与工具准备，并规划目标端RAID组与LUN划分、SAN交换机配置及数据备份要求。迁移执行阶段演示了如何添加目标存储映射、利用vSphere热迁移在线搬移数据、移除源存储以及完成业务系统调测，并对迁移后的I/O性能验证给出指引；同时针对割接失败或异常情况给出了明确的数据备份与回退步骤，便于及时止损。资源包为1个DOC格式文档，大小1.92MB，目录结构完整，章节划分清晰，可直接作为企业存储迁移项目参考。目前已有141人学习，适合正在规划存储迁移或希望优化现有迁移流程的工程师、架构师。

1. 为什么非换不可：SC040 的存储迁移决策逻辑

制造业大厂的生产虚拟化环境里，DELL Compellent SC040 这种老存储往往是最先撑不住的那一环——剩余空间见底、控制器故障率往上走、微码版本老到厂商都快不维护了。但生产虚拟机不能停机，于是 VMware Storage vMotion 就成了唯一现实的选择：不改虚拟机配置、不重启业务，把数据从 SC040 在线搬到 HPE 3PAR 20800v2。这套方案文档的含金量在于它不是讲 Storage vMotion 的通用教程，而是一份可以直接照着操作的割接流程——从物理布线怎么切、LUN 状态什么时候能迁、到回退怎么走。适合虚拟化运维、存储工程师和负责业务连续性的人，照着做能省掉大半现场摸索的时间。

2. 迁移前一周准备：环境盘查、机房布线与 16Gb HBA 卡更换

2.1 基础信息三张表：主机、交换机、源存储不能漏

接手存储迁移的第一步不是去点 vCenter 里的迁移按钮，而是先把现有的物理环境盘清楚。方案里强调了升级前 1 周就要做基础信息统计，这个时间节点踩得很准——太早了信息容易变，太晚了出了问题没时间改。统计范围是三类设备：ESXi 主机、源端 SAN 交换机、源端存储，每类一张表。

我的习惯是主机表至少记这些字段：品牌型号、序列号、主机名、业务地址、机柜位置、HBA 卡 WWN。特别注意 WWN 要记全，后面在 3PAR 管理端映射 LUN 给主机时全靠它，少一位都映射不上。交换机表要记微码版本和管理地址，Brocade B300 这种老交换机在割接前后都要留底。源存储表重点记控制器微码版本、可用空间和机柜位置。

# 用 esxcli 批量导出主机 HBA WWN，比在 vCenter 图形界面一台台翻快得多 esxcli storage core adapter list | awk '{print $1, $NF}'

这段命令的意思是把每台 ESXi 主机的存储适配器名称和对应的 WWN 一起列出来，$NF取的是行尾的 WWN 字段。实际生产环境我建议直接在 vCenter 里逐个主机核对，因为esxcli输出的 WWN 格式是 0x 开头的冒号分隔形式，而存储端映射时需要的是naa.开头的格式，两边要做一次转换核对。核对完别急着收工，把每台主机到交换机端口的物理对应关系也写上，后面改光纤线的时候能少走不少弯路。

2.2 布线规划与 HBA 卡更换：26 根光纤线，先拿一台闲置主机试水

方案里提到需要提前部署 13 台 ESXi 主机到两台目标 SAN 交换机 A/B 的光纤线，每台主机两根，总共 26 根。这里有个很容易被低估的细节：光纤线不是插上就完事，要提前布好并打好标签，两端都要标清楚 A 端 B 端。现场割接的时候时间紧张，手里拿着线头对不上端口表，那感觉只能用"血压拉满"来形容。

HBA 卡更换是这次迁移里最需要谨慎的硬件操作。源端 13 台 ESXi 主机用的是 8Gb 光纤卡，目标 SAN 交换机是 16Gb，不换卡链路带宽就卡在 8Gb。方案的做法是库里找 12 块闲置 16Gb 卡换给 6 台主机，但换法很讲究——先拿一台闲置 ESXi 主机添加或更换光纤卡，测试稳定后再动其余 5 台同型号主机，不搞全面铺开。

提示：HBA 卡更换前确认主机在维护模式，vCenter 里右键主机 → 进入维护模式，等所有虚拟机迁走或关机后断电再操作。换完卡上电，进 vCenter 确认 adapter 被正常识别、WWN 已更新，再退出维护模式。

2.3 运行状态检查和工具清单：迁移前把风险项排干净

在启动迁移之前，方案里明确了要做一轮彻底的巡检，包括业务运行状态、主机运行状态、源存储状态、光纤交换机状态四个维度。巡检不是走过场，方案里专门提到要通"重启主机、集群切换"来验证业务系统真的健康——这一点很多团队不敢做，但恰恰是最该做的。如果连重启和切换都经不起，那在线迁移过程中的短暂 I/O 波动很可能直接打崩业务。

网络层面要盯住 vmkernel 所在网卡的链路状态，要求双千兆。这次巡检已经发现部分主机网卡降速为 10/100M，这在迁移期间是个定时炸弹——vMotion 传输走存储网络还好，但控制面信令如果走这张网卡，降速会直接影响迁移任务稳定性。多路径状态也要检查，本文场景用的是 VMware 自带 NMP 多路径软件，要确认每条链路都是 active 状态，没有 degraded 路径。

工具清单看起来琐碎，但缺一样都闹心。软件层面：SSH 登录工具、FTP 工具、3PAR management console、DELL Compellent management console。硬件层面：串口线（RJ45 口）、网线、防静电手套、标签纸、一台确认能接 RJ45 串口的笔记本。防静电手套这玩意儿很多人嫌麻烦不戴，但在机房里拔插光纤模块时被静电打一下，轻则端口 down，重则设备重启，这笔账自己掂量。

3. 目标存储准备：3PAR RAID/LUN 划分、Zone 规划与数据备份

3.1 RAID 组与 LUN 划分：从"正在格式化"到在线

目标端 3PAR 20800v2 的准备工作分两个阶段：先建 RAID 组和划分 LUN，再把 LUN 映射给主机端口组。方案里 RAID 组和 LUN 规划是一张 30 行的卷清单，实际生产里卷数量和容量完全取决于源存储上的数据量，这张表的作用是让你逐行核对，别到迁移时才发现目标存储空间算少了。

划分 LUN 时有个状态机必须搞清楚：新创建的 LUN 初始状态是"正在格式化"（或者叫 zeroing），这个阶段 LUN 可以配置，但不能跑数据迁移。必须等全部 LUN 从"正在格式化"变成"在线"，才能开始迁数据。如果不等格式化完成就强行迁移，会出现数据写入异常，最坏情况是迁移到一半目标 LUN 不可写，虚拟机直接 I/O 错误挂起。

提示：3PAR 的 LUN 格式化本质是底层物理空间清零，大容量 LUN 格式化耗时可能以小时计。规划时间表时要把这步算进去，别把格式化时间和迁移时间安排在同一天。

RAID 级别的选择要看业务对性能和冗余的平衡。生产虚拟机建议至少 RAID-5 或更高，有条件的业务可以用 RAID-10。容量规划不是简单的"源 LUN 总大小相加"，VMFS 文件系统自身有开销，建议目标总容量按源数据量的 1.2 到 1.5 倍规划。方案里源存储向 ESXi 映射了 1 个 100G 的 LUN，目标存储创建了 4 个 LUN（2×100G、2×150G），这就是考虑了扩容需求的典型做法——迁移时先用一个容量匹配的 LUN，其余 LUN 留给后续业务扩容。

3.2 目标端 SAN Zone 规划：主机端口与存储 IOPORT 同 Zone

SAN 交换机规划的实质是打通主机到存储的链路。目标端要做的核心操作是：把主机的端口和 3PAR 存储的 IOPORT 划入同一个 Zone 中，并确保两个 Zone 分别落在两台交换机上做冗余。这里有两个常见做法需要说明：

第一，Zone 命名建议包含"主机名_存储名_交换机名"三段式命名，例如ESXI01_3PAR_SW_A。别用ZONE1、ZONE2这种流水号命名，存储迁移项目的周期往往按周算，回头排查链路问题时会发现自己根本不记得哪个 Zone 对应哪条链路。

第二，每台 ESXi 主机的两块 HBA 卡要分别连接两台 SAN 交换机，也就是主机端做了链路冗余。Zone 划分时每台主机在两台交换机上各建一个 Zone，每个 Zone 里包含该主机的一块 HBA 卡端口和 3PAR 的一个 IOPORT。这样即使一台交换机故障，另一条链路仍能保持存储访问。

配置完成后一定要做端到端确认。我的做法是在每台交换机上查看 Zone 内的端口是否都处于在线状态，然后在 ESXi 主机上执行多路径扫描，确认每个 LUN 都有两条 active 路径。如果看到只有单路径，先查交换机的端口配置和 Zone 成员关系，再查光纤线有没有插错端口——这两个问题占了 SAN 链路故障的八成以上。

3.3 数据备份：三层备份保住底线

方案里数据备份分了三层：第一层是业务配置信息，包括集群、业务平台信息；第二层是光纤交换机配置备份；第三层是源存储上待迁移的数据，用虚拟机快照做备份。这三层少哪层都不行。

很多人觉得 Storage vMotion 是 vSphere 原生的在线迁移技术，靠 VAAI 从存储层直接拷贝，数据不会坏，就不做备份。这是典型的侥幸心理——迁移过程中如果目标存储出现硬件故障、固件 bug、或者光纤链路闪断导致数据不一致，没有备份就只能接受数据丢失的后果。虚拟机快照备份看起来很基础，但在割接场景里它就是后悔药。

提示：快照要确认创建成功并且能正常删除，别只做完快照就收工。迁移完成后要第一时间删除迁移前创建的旧快照，否则快照文件会在源存储上持续占用空间，而且会拖慢虚拟机性能。

源存储上数据量大的话，虚拟机快照备份的耗时也要提前预估。我在类似项目中的做法是：迁移前一个工作日晚上创建快照，第二天早上确认快照状态正常，再进行迁移。这样既保证备份新鲜度，又不至于让快照在源存储上停留太久。

4. Storage vMotion 实操：从物理连线到移除源存储

4.1 物理连接变更：先切一路，迁移完成再切另一路

方案里"添加目标存储映射"这一步估算时间按 120 分钟起，这个估算是很现实的，因为整个过程涉及物理改线、存储映射、主机 rescan、建数据存储四个环节，链路越复杂耗时越长。

以方案中的 ESX 双机集群为例，源端架构是两台 ESXi 主机的 HBA 卡分别连到两台 Brocade B300 交换机，再接到源存储 SC040。目标端接入 3PAR 20800v2 后，组网变成混连状态。变更的先后顺序很讲究：先拔掉 ESXi 到原 B300 交换机的一路光纤，插入到连接 3PAR 的目标交换机的 1 路光纤；此时主机还保留着到源存储的另一条链路，存储访问不中断。等所有虚拟机迁移完成、业务验证通过后，再把另一路光纤从 B300 交换机拔下来，插到连接 3PAR 的目标交换机 2。

如果你在手忙脚乱中把两路光纤同时切过去了，而目标存储还没有完成 LUN 映射或者 Zone 配置，主机可能完全丢失存储连接，那就是不必要的生产事故。所以顺序必须是：一次只动一路，且先保证新链路路径可用再动另一路。

4.2 LUN 映射与 rescan：让 ESXi 集群识别目标存储

物理改线完成后，接下来的关键操作是把 3PAR 上格式化完成的 LUN 映射给 ESXi 主机。映射之前先要从 vCenter 里拿到 ESXi 主机的 HBA WWN：找到对应主机，查看"Configuration → Hardware → Storage Adapters"，记下每块 HBA 卡的 WWN。

拿到 WWN 后在 3PAR 的 ISM 管理软件里操作，按照源存储的映射配置把 LUN 映射给 ESXi 主机。这里有个设计细节值得学习：源存储只映射了 1 个 100G 的 LUN，目标存储却创建了 4 个 LUN，这是为了给后续扩容留空间，同时也为了迁移时能按虚拟机分组落盘，避免所有虚拟机挤在同一个 LUN 上。

映射完成后，ESXi 主机需要做一次 rescan 才能看到新 LUN。在 vCenter 里选择 ESXi 主机，右键"Configuration → Hardware → Storage Adapters"，在输出的 vmhba2 上选择 rescan。这里有个省事的机制：同一集群内只要一台主机识别到目标存储的 LUN，其他主机在默认配置下会自动识别。但我的建议是不要省这一步——手动逐台检查一遍，确认每台主机的存储列表里都出现了目标 LUN。

4.3 创建目标数据存储：VMFS-5、命名与容量选择

主机识别到 LUN 后，还需要在 LUN 上创建 VMFS 文件系统，也就是数据存储。vCenter 里进入 ESXi 主机的"Configuration → Hardware → Storage"，点击"Add Storage"，选择"Disk/LUN"，此时会列出可用的 LUN，目标存储映射过来的 LUN 就在其中。

这里三个注意点：

第一，一次只能选择一个磁盘。如果选中的磁盘容量不够，创建完数据存储后要扩展，而不能在创建时跨多个磁盘做条带。方案里明确提到"一次只能选择一个磁盘"，这是很多人容易忽略的限制。

第二，文件系统版本选 VMFS-5。这个版本兼容性最好，既能支持较新的 vSphere 版本，又不会有 VMFS-6 在某些老环境里的兼容问题。方案里用了 VMFS-5，如果你的 vCenter 和我一样跑在老版本上，别试图赶时髦选 VMFS-6。

第三，命名要有继承性。方案里源数据存储叫mxy_stor_1，目标存储命名为mxy_stor_dest，一眼就能看出对应关系。实际项目中建议在命名里带日期或者批次信息，比如3PAR_VMFS01_2025之类，多个批次迁移时不会混淆。

创建完成后，在"Storage"视图里应该看到目标数据存储显示为可用状态、容量正确。此时别急着迁数据，先在目标数据存储上右键 →"属性"，确认"文件系统版本"是 VMFS-5、"最大文件大小"等信息正常。

4.4 执行在线迁移：右键虚拟机选"更改存储"

数据存储准备好之后，迁移的主体工作就是在 vCenter 里把虚拟机逐个从源存储移动到目标存储。选中要迁移的虚拟机，右键 →"迁移"，在迁移类型中选择"仅更改存储"，然后在目的地里选择新创建的目标数据存储。

不用改主机，因为虚拟机还在原来那台 ESXi 上跑着，Storage vMotion 的职责只是把磁盘文件从源数据存储复制到目标数据存储。执行后可以在 vCenter 的任务列表里看到迁移任务，迁移过程中虚拟机保持开机状态，业务不停。

方案里迁移过程其实调用的是 FSDM/FS3DM 服务，优先级是 Hardware FS3DM > Software FS3DM > FSDM。如果源端和目标端存储都支持 VAAI（硬件卸载），迁移走的是 Hardware FS3DM 数据路径——从源存储直接拷贝到目标存储，传输走存储网络，Kernel 只做信令验证。这意味着 Storage vMotion 的性能瓶颈在存储阵列本身，而不是 ESXi 主机的 CPU 和网络，这也是在线迁移能保持业务稳定的核心原因。

4.5 迁移后清理：移除源存储 LUN 与线缆

全部虚拟机迁移完成后，不能直接把源存储连接拔了，要按顺序清理。第一步在 vCenter 里逐个确认所有需要迁移的虚拟机已经全部在目标数据存储上，确认方式很简单——虚拟机的磁盘文件路径应该指向目标数据存储。

第二步从 ESXi 主机上卸载（unmount）源数据存储。右键源数据存储 →"卸载"，系统会检查是否还有虚拟机在使用它。如果还有虚拟机残留，卸载会失败，这时候需要回刚才的步骤确认遗漏的虚拟机。

第三步从主机配置里移除（detach）源存储的 LUN。这个操作会断开主机与源存储的映射关系，但不会删除源存储上的数据，保留数据是为了回退留后路。

最后一步才是物理上把光纤线从 B300 交换机完全断开，插到目标交换机上，完成整个组网切换。此时 Check 一下最终组网：ESXi 主机 → 目标交换机 → 3PAR 存储，一路走通。

5. 避坑：Storage vMotion 迁移中最容易翻车的五个点

5.1 网卡协商到 10/100M，迁移还没开始就输在起跑线

现象：巡检发现部分主机的 vmkernel 网卡链路协商速率降到了 10/100M，按理说双千兆网卡不该出现这个速率。

原因：物理链路质量问题居多——网线老化、水晶头接触不良、对端交换机端口强制了特定速率。也可能是多路径配置异常导致 HBA 链路降速，但网卡降速通常是物理层的锅。

解决：迁移前必须把降速的链路恢复。方法是先换网线，再检查交换机端口配置，确认两端协商模式一致；如果问题还在，检查物理适配器驱动和固件版本。方案里明确说"迁移之前确保 vmkernel 所在网卡链路状态正常（双千M）"，这条不是建议，是强制要求。

5.2 LUN 还在"正在格式化"就被拉去迁移

现象：在 3PAR 上创建完 LUN 后直接开始 Storage vMotion 迁移，迁移任务卡住或虚拟机 I/O 报错。

原因：LUN 创建后处于"正在格式化"（zeroing）状态，这个状态下 LUN 可以配置映射但不能读写数据。VAAI 的硬件拷贝操作依赖目标存储完成物理空间清零，底层没准备好，拷贝自然进行不下去。

解决：等全部 LUN 状态变成"在线"再进行迁移。规划时间表时给格式化留出足够时间，大容量 LUN 格式化几个小时的常见。迁移前检查一遍所有目标 LUN 的状态，确认"在线"后再启动迁移，一步都不能抢。

5.3 共享磁盘做不了在线迁移，只能离线

现象：虚拟机使用共享虚拟磁盘（如 MSCS 集群节点共享盘），右键迁移时发现 Storage vMotion 不可选或迁移失败。

原因：Storage vMotion 在线迁移不支持共享磁盘。VMFS 管理的非共享磁盘可以在线迁，裸盘或共享 VMDK 只能走离线迁移——关机后迁或者加入额外的约束条件。

解决：迁移前先搞清楚虚拟机的磁盘类型，如果使用了共享磁盘，要么做离线迁移（先关机再迁），要么把共享盘排除在迁移范围之外。方案说明里专门标注了"如果 VM 使用的盘为共享磁盘则只能做离线迁移"，这是 Storage vMotion 的功能边界，别试图绕过。

5.4 添加数据存储一次只能选一块盘，容量不够要等建完再扩

现象：创建新数据存储时，想把映射过来的多个 LUN 一次性全部选中做成一个大存储，发现界面不支持。

原因：VMware 的 Add Storage 向导设计就是一次只能选一个 LUN 创建数据存储，不支持多 LUN 聚合。这是产品功能限制，不是操作失误。

解决：容量规划时把 LUN 大小切割合理，创建数据存储后如果有扩容需求，再执行扩容操作（Extents 扩展），把后续 LUN 加进去。方案里说得很清楚："一次只能选择一个磁盘，若容量不够，创建成功后，再扩容该数据存储"。别在这个设计上纠结，按它的规则走。

5.5 VAAI 没激活，Hardware FS3DM 不会生效

现象：迁移时发现传输走的是网络而非存储网络，迁移速度明显低于预期，ESXi 主机 CPU 负载异常上升。

原因：Storage vMotion 迁移时优先调用 Hardware FS3DM，但前提是源端和目标端存储都支持 VAAI。如果有一端不支持或者 VAAI 功能没激活，迁移会回退到 Software FS3DM 或者 FSDM，数据走主机内存和网络转发，性能大打折扣。

解决：迁移前用命令验证 VAAI 状态：

# 查看设备是否支持 VAAI，naa 开头的 ID 替换成源存储的 LUN esxcli storage core device vaai status get -d naa.6000d31000430b0000000000000000331

运行后看输出里的Hardware acceleration字段是否为Supported。两端都支持 VAAI 才能走 Hardware FS3DM 路径，这是在线迁移性能的保底。如果发现不支持，赶紧查存储的 VAAI 插件是否安装正确、存储端许可证是否激活，不要等到迁移跑到一半才意识到走错了数据路径。

6. 迁移后的验证与回退：调测不达标怎么安全回到源端

6.1 业务调测与倒换验证

迁移完成后不急着宣布成功，先做一轮业务调测。调测覆盖的范围要细致：业务系统能否正常登录、数据库连接是否正常、集群服务是否健康，以及跨主机的业务切换是否仍然顺畅。我在实际项目中习惯的做法是，先虚机内的业务验证，再跨主机的集群切换验证（如 VMware HA），最后存储链路验证（确认所有 LUN 路径都是 active/optimized）。

调测过程如果发现业务异常，先看 vCenter 事件和存储告警，别急着回退。多数时候问题出在目标存储性能参数或 LUN 映射关系上，这些小问题可以在目标端修正，不用惊动源端。

6.2 回退方案：割接失败后怎么导回

回退的前提是回退方案里三层备份都做了：业务配置信息、交换机配置备份、源存储数据快照。割接失败导回的核心操作是把虚拟机在源存储上的数据恢复出来，再把虚拟机重新关联回源数据存储，迁移前创建的快照在此时发挥作用。

如果回退发生在迁移早期（源存储数据未删除、源存储连接未断开），最直接的路径是把虚拟机关机，用 Storage vMotion 反向迁移回源数据存储，再按原配置恢复映射。如果回退发生在迁移后期（源存储已离线），则需要通过备份恢复到源存储。注意源存储离线后恢复时间会拉长，这也是为什么方案里建议保留源存储 LUN 与数据直到业务验证完成。

6.3 收尾习惯：验收清单和复盘记录

迁移完成且业务验证通过后，我习惯强制自己做一遍完整的收尾复查：确认同一集群内每台 ESXi 主机的存储适配器都能看到所有 LUN，确认没有残留的虚拟机仍然引用源存储 LUN，确认所有源存储的映射已解除，最后把光纤线标记和交换机配置备份留档。做完这遍复查，当天晚上的迁移才可以安心收工。

从那以后的每次存储迁移，我都强制先走一遍环境盘查、VAAI 验证、备份确认再动手改线，顺序不乱、步骤不减，宁可多花一小时做检查，也不愿意凌晨三点站在机房里跟交换机端口较劲。这套方案文档里最值钱的部分不是 Storage vMotion 本身，而是把"怎么避风险"和"怎么回退"都提前想清楚了。希望帮到你。

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