简介面向数据中心运维、解决方案架构师和企业IT决策者这是一份华为FusionCube 3.2虚拟化超融合基础设施技术白皮书系统讲解超融合平台的产品价值、FusionSphere与VMware双场景架构、分布式存储、高性能与线性扩展能力并完整阐述认证授权、加密及访问控制等安全机制以及高可用、故障恢复和数据保护设计可作为规划超融合数据中心、理解HCI架构原理和开展选型评估的参考材料。文档对FusionSphere与VMware场景的典型配置、组网方式和工作原理均有说明还覆盖分布式存储的数据路由、IO路径与Cache机制等关键技术细节。压缩包为单个docx文档大小6.35MB目录结构完整从产品概述到关键业务流程均有章节索引便于直接查阅或做团队分享。已有392人学习下载适合需要了解华为超融合方案或系统学习HCI落地要点的读者。1. FusionCube超融合为什么它不该被当成“几台服务器”第一次看到 FusionCube 超融合平台的报价单很多运维会以为 IT 部门买了一台更贵的 PC 服务器——这个误会值得先拆掉。FusionCube 超融合平台把计算、分布式块存储和网络交换融合进同一个机架单位交付后不再是存储阵列、SAN 交换机、虚拟化服务器三套设备而是一组带统一管理面的融合节点。它解决的是中小团队“存储扩容要排期、虚拟化挂盘要协调”的老问题适合已经在跑虚拟化、又不打算继续维护独立 SAN 的运维和架构师。这篇笔记按白皮书里的架构、部署、调优和排障顺序整理把关键参数和踩坑点都标出来照着走能少走大半弯路。2. 双活A-A架构与硬件形态先把“融合”这个词拆明白2.1 超融合到底“融”了什么在讲 FusionCube 之前先看传统架构是怎么堆的机架服务器负责跑虚拟化集中式存储阵列存数据SAN 交换机在中间负责连接。扩容时先买盘柜、再划 LUN还要维护光纤交换机上的 zone、多路径软件、存储映射任何一个环节断链都会影响生产。超融合把这三层压进一组 X86 节点。每台节点都有本地 CPU、内存和磁盘分布式存储软件把各节点的本地盘聚合成一个全局共享存储池虚拟化层和存储层跑在同一批服务器上数据通过内部以太网横向复制不再经过独立的存储控制器。FusionCube 的核心组件就这么来的FusionSphere 负责虚拟化FusionStorage 负责分布式块存储两者通过管理面统一调度。这套架构带来的第一个变化是性能瓶颈从“存储控制器处理能力”变成了“网络吞吐和磁盘调度”。传统 SAN 的性能上限由控制器决定扩容要换控制器或加盘柜超融合加一台节点计算、存储容量、存储性能同时增加扩展粒度小得多。这也是 FusionCube 白皮书里反复强调“横向扩展”的原因加节点不像加盘柜那么有仪式感却比换控制器便宜也没有控制器之间的双活配置成本。2.2 双活A-A与副本机制FusionCube 的存储层是“全活”架构所有节点同时参与 IO不存在一台存储主控加一台备控“主备等待”的状态。数据被切成固定大小的分片通过一致性哈希分布到所有节点磁盘上每个分片保存多个副本副本的落点会避开同一个节点和同一个磁盘。副本数直接影响可用容量和可靠性。先在白皮书里确认你当前的版本支持哪种副本策略再去看容量。常见的选型逻辑大概是这样副本策略可用容量估算能容忍的故障故障域配置得当推荐场景2 副本约裸容量 / 2单盘故障、单节点故障开发测试、非核心业务3 副本约裸容量 / 3同故障域下两节点或多盘同时故障生产数据库、关键应用故障域把副本分布到不同机柜或不同节点组防止整体掉电或机柜级故障导致数据一次性丢失。我一般建议生产环境至少用 3 副本并把故障域设为“节点级”也就是同一分片的两个副本不允许落在同一台节点上。副本数选多了可用容量下降明显选少了故障窗口太窄这个选择题要在建池之前做完事后改副本策略的动静远比想象中大。2.3 硬件形态边界它和PC服务器不是一个物种“超融合服务器可以归类 PC 服务器吗”——这个搜索词基本等于在问“我能不能用通用服务器把它替换掉”。从 CPU、内存、硬盘接口来看FusionCube 的硬件确实是标准 X86 技术栈但你按 PC 服务器的思路来维护它后面会翻车。原因有三层。第一整机 BOM 是锁定的板卡、磁盘、固件都按超融合平台的兼容列表配套过白皮书里也强调固件一致性混插同容量但不同型号的硬盘底层存储会认为节点异常。第二存储网络参与分布式存储协议节点间的数据同步依赖专用队列和 RDMA 能力通用网卡不一定能接手。第三管理平面和带外监控是整套系统的一部分按单台服务器来孤岛式管理会丢掉全局告警和联动升级的能力。所以结论是形态上是 X86 服务器工程边界上不是 PC 服务器。日常巡检可以按服务器看温度、看风扇但换硬件、升级固件、扩容节点必须回到超融合平台的兼容列表和变更流程里走。2.4 和主流超融合厂商技术的差异做选型的人通常会把华为 FusionCube 和深信服超融合、Nutanix、VMware vSAN 这类产品放在一起比。只看白皮书可能看不出差异点我的对比经验是看三条线。交付形态FusionCube 偏一体机存储节点、管理节点和网络在出厂时已经预集成到现场接通电源和链路就能进入部署纯软件方案由客户自己选服务器和交换机灵活但验证成本在自己身上。存储路径FusionCube 的分布式存储和硬件耦合更紧支持方向是“按官方兼容列表走”纯软件方案对硬件宽容度更高但要自己负责更多硬件排障。网络方案FusionCube 常见 RoCE 网络来消化存储流量配套交换机的 PFC、ECN 参数必须对齐vSAN 也可用 RDMA但很多存量机房实际跑的还是普通万兆 TCP。我的建议是如果机房已经有一批标准化 X86 服务器纯软件方案可能更顺手如果是从零建机房、想少背几个维护包袱一体机交付的 FusionCube 能让开局快很多。架构层的概念先放一边下一章直接进入部署。3. 部署一台能用的FusionCube从存储池规划到LUN上线3.1 部署前的容量与网络规划部署前别急着开箱。有三个问题必须先定下来节点数、副本数、存储网速率。节点数决定容量和故障域布局。三节点是最小集群但三节点加 3 副本时一个节点故障要在剩余两节点上重建数据风险窗口比较大。我一般建议起步就是 4 节点这样 3 副本模式下坏一台节点还有足够空间做数据重建。容量按公式算可用容量 ≈ 裸容量 ×1 - 预留比例÷ 副本数 ×1 - 元数据开销。预留比例我习惯留 10%元数据开销按 3%~5% 估具体看版本。举一个常见配置4 节点、每节点 8 块 4TB 硬盘裸容量 128TB3 副本预留 10%元数据按 4%算下来可用容量约 36.9TB。如果不开精简置备虚拟机能写进去的空间就是这么多。规划项建议值说明管理网络1GE 或 10GE独立 VLAN承载管理面心跳和带外管理不要和业务混跑业务网络10GE / 25GE独立 VLAN承载虚拟机东西向流量存储网络25GE 起步RoCE 建议打开承载分布式存储复制流量MTU 对齐 9000网络规划有个容易忽略的点管理、业务、存储三个平面必须分开。超融合比传统架构更依赖管理面一旦管理心跳和存储流量抢同一链路故障时你连告警都收不全。每个平面至少两路物理链路存储网优先使用独立交换机或至少独立 VLAN。3.2 初始化流程从硬件上电到存储池可用FusionCube 的一体机交付白皮书一般会给出标准开局顺序我按实际操作经验整理成以下几个步骤。第一步硬件上电连接管理口在管理界面里配置带外 IP确认所有节点被纳管并且版本一致。不同批次节点的固件版本必须对齐这是后面换盘不翻车的前提。第二步导入软件许可证配置系统时间NTP 必须指向稳定时钟源和 DNS。时间不同步会造成证书校验失败和日志时间线错乱排障时很痛苦。第三步创建存储池。这一步要选择介质类型全闪、混合、副本数和故障域。全闪池性能和成本都高混合池用 SSD 做缓存、HDD 做容量层。副本数和故障域按生产需求选宁可一开始副本数多预留一点容量也不要事后降副本。第四步等待数据平衡完成。新集群建完后系统会把数据均匀分布到各节点观察后台任务进度等 rebalance 结束再开始建虚拟机。第五步在存储池上创建 LUN按业务规划决定容量和名称映射给计算节点。提示存储池创建后不要急着建虚拟机先确认 rebalance 任务已经完成否则前几个小时的 IO 会不稳定。这套流程里最容易跳过的一步是固件版本核对。我见过有人直接跳过版本巡检进存储池结果存储节点之间版本不一致存储池一直处于告警状态。3.3 映射到虚拟化平台与验证LUN 映射完成后进入虚拟化平台把存储挂上去。这一步叫添加存储本质是把 LUN 格式化并注册为数据存储。挂载后先别急着建虚拟机先做一次路径和性能验证。在 ESXi 上我一般会先看设备是否被正确识别# 列出 ESXi 识别的存储设备 esxcli storage core device list # 检查每条路径的当前状态 esxcli storage core path list正常状态是每个 LUN 显示多条 Active/Optimized 路径。如果看到 Dead 或 Standby别往下走先按第 5 章的 MTU 和链路问题排查。路径验证通过后再创建一个小型测试虚拟机做一轮磁盘读写测试确认 IO 正常后再放业务。参数说明esxcli 是 VMware 的存储命令行入口device list 看设备级状态path list 看多路径状态。设备正常才能保证后续虚拟磁盘 IO 有冗余路径可走。挂载后的另一项验证是“数据存储可见性”也就是确保每个计算节点都能看到同一个 LUN而不是只有部分节点能看到。分布式存储映射遗漏是开局阶段最典型的问题表现是虚拟机只能在部分主机上启动迁移时直接报“主机无法访问存储”。4. 性能与网络调优RoCE、缓存和IO路径上的关键参数4.1 存储网的正确打开方式RoCE 下的 PFC 与 ECNFusionCube 这类超融合设备存储流量默认走内部以太网。如果存储网还是千兆加普通 TCP分布式复制的高峰流量会把链路打满IO 延迟就会很“玄学”——这边看着磁盘不忙那边虚拟机却在卡顿。启动 RoCE 是常见的优化方向但 RoCE 依赖无损网络不能简单地开个开关。PFC优先级流控为存储流量所在的队列提供无丢包保障ECN 负责在队列拥塞前标记报文让网卡自动降速。这两个参数必须和交换机、网卡两端对齐。我一般会这样做给存储流量分一个独立的高优先队列在其他队列之上配置 PFCMTU 统一 9000。# 交换机端口示意存储流量进入队列3打开PFC interface 10GE1/0/1 mtu 9000 qos map 2 to queue 3 qos queue 3 pfc on这里有个反面教训把管理、业务流量也全部塞进无损队列遇到广播风暴时PFC 会把存储队列一起卡死整个集群 IO 中断。无损队列只给真正需要低延迟、低丢包的存储流量用其他流量按普通队列走。参数说明mtu 9000 是为了避免大帧分片qos map 把存储报文的优先级映射到队列 3pfc on 让该队列启用优先级流控。不同交换机的命令风格不一样但思路是通用的确定存储 VLAN、绑定优先级、打开 PFC、核对 MTU。4.2 缓存怎么调读写缓存与回写降级混合介质池里SSD 和 HDD 不是简单堆在一起。FusionStorage 的逻辑是SSD 承担读写缓存和高频随机 IOHDD 主要放容量型数据后台把数据从性能层刷到容量层。读缓存提升随机读命中率写缓存先落 SSD再异步回写 HDD这样写 IO 对 HDD 的随机压力会小很多。真正需要盯的是写缓存水位。回写模式下缓存超过高水位就会把新写入强制降级为直写IO 延迟可能会跳到十几毫秒甚至更高。参数常见建议值说明写缓存高水位75%~80% 触发提示90% 停止新增写入具体数值以当前版本默认值为准刷盘频率按业务类型调整太高增加 HDD 压力太低缓存容易占满读缓存比例保留适当余量别把读缓存配满要给写缓存留空间缓存调优的常见做法容量型业务文件存储、备份可以调低刷盘频率少占 CPU性能敏感型业务数据库则要把高水位调低提前触发告警避免缓存占满后断崖式降级。如果频繁看到“写缓存达到高水位”的告警优先扩容 SSD 缓存而不是继续优化参数。4.3 虚拟机侧磁盘置备、控制器和队列深度存储层的参数调好之后虚拟机侧的决定也会影响最终表现。磁盘置备生产虚拟机建议用厚置备避免 thin 磁盘在数据增长时出现扩容毛刺。测试环境用 thin 可以省容量但必须部署容量告警否则超分会导致整个存储池变满。SCSI 控制器不要在虚拟机上用 IDE 控制器换成半虚拟化 SCSI 控制器VMware 下的 PVSCSI 或华为虚拟化平台的 virtio-scsi队列深度和吞吐都更高。队列深度默认值太小时高并发 IO 压不出性能调得太大又会把压力全转到存储节点上。常见做法是先保持默认跑一轮基准测试再逐步调队列深度直到延迟有明显回升的位置停住这个点就是本集群的边界。块大小和对齐底层分布式存储按条带切数据虚拟机文件系统格式化的块大小如果和条带差异过大顺序 IO 会多一次跨越。通用做法是虚拟机内格式化为 4K底层条带按 1MB 级别规划对多数业务已经够用。5. 常见问题与避坑超融合排障时的五个现场超融合有个和传统架构不同的特点出问题的时候你没有单独的存储控制器可以摘掉排查。磁盘、网络、虚拟化在同一个机架里牵一发动全身。以下五条是真实场景里高频翻车的问题每一条都按“现象 → 原因 → 解决”写。5.1 一块盘掉线整个集群跟着抖现象某节点的一块硬盘掉线后集群 IO 延迟突然飙升虚拟机的监控曲线出现明显尖峰持续几十分钟。原因故障硬盘触发数据重建重建数据的读 IO 和业务写 IO 争抢同一台节点的磁盘与网络资源超融合集群里表现成“单盘故障引发的集群级抖动”。解决在存储管理界面把重建带宽限制到一个安全值我一般设置为不超过节点存储带宽的 30%。同时把重建任务安排在业务低峰期执行。重建期间不要同时进行扩容或备份避免多个后台任务叠加。5.2 LUN 映射过去主机侧存储路径一片红现象LUN 映射完成后虚拟化平台里能看到设备但路径状态是 Dead虚拟机无法在部分主机上启动。原因最常见是网络 MTU 不一致。存储网要求 9000但映射主机的存储网卡或交换机端口还停留在 1500导致大帧被丢弃路径反复超时。其次可能是多路径插件没有正确加载。解决核对存储网所有相关端口和主机网卡的 MTU统一 9000然后重新扫描存储适配器加载对应多路径插件。在 ESXi 里检查每条路径的状态确认全部回到 Active/Optimized 后再继续。5.3 换盘一直失败卡在“等待 Rebuild”现象磁盘故障后按容量买了同规格新盘插上后状态不是“Rebuild 完成”而是反复失败甚至整台节点被标记为异常。原因新盘型号不在兼容列表里固件版本和整机不一致。分布式存储对硬件一致性很敏感控制器识别到未知型号后直接拒绝写入数据。解决换盘前先查兼容列表和当前节点的固件版本。如果换盘已经失败先在带外界面确认固件版本再把新盘对齐到同版本最后手动触发重建任务。从那以后我换盘都强制走一遍兼容性核对再下单。5.4 管理面心跳丢包集群直接脑裂现象两台管理节点之间网络抖动集群出现“脑裂”告警业务 IO 短暂中断。原因管理、业务、存储三网混在同一个链路上某条业务链路打满后管理心跳报文被丢弃管理节点之间失去联系触发隔离保护。解决管理、业务、存储三个平面严格分离管理平面至少绑定两路独立链路。不要在同一个交换机上同时跑管理流量和存储流量。物理隔离做不到的就用 VLAN 加独立队列。5.5 备份任务一跑生产立刻变慢现象定时备份或快照任务启动后生产虚拟机的写延迟明显上升备份结束后恢复。原因备份任务和业务写流量共用同一个写缓存池和同一组存储节点。快照读取产生的随机读会占用读缓存写缓存水位也被推高缓存降级直写后生产 IO 就跟着变慢。解决尽量把备份流量限制在低峰期给备份 VM 设置独立的存储池或独立的 LUN减少和生产资源争用。如果无法分离备份窗口内把备份并发数调低优先保证生产 IO。6. 迁移到FusionCube的实操路径从SAN搬迁与一致性验证6.1 三种迁移路径的取舍从传统 SAN 迁到 FusionCube没有一种“全网通用”的迁移方式。先看停机窗口再看一致性要求。迁移方式停机时间一致性保证适用场景基于虚拟化的存储热迁移storage vMotion几乎为零依赖虚拟化层一致性文件服务器、应用服务器存储层异步复制 / 双写数分钟到数十分钟按复制点保证一致性数据库、关键业务备份恢复停机较长取决于备份恢复逻辑非关键系统、物理机改造我的经验是数据库优先用异步复制或双写切到新端前做一次完整的数据库校验文件服务器用存储热迁移最省事。如果业务接受停机备份恢复是最稳的方案回滚也简单。白皮书里对迁移的架构描述比较完整但界面路径、命令清单和运行截图在文档里更全下载下来对照实操会更稳。6.2 迁移后的验证清单别把数据搬完就交差迁移完成不等于项目结束。我会按以下清单逐项检查数据库的一致性校验Oracle 走 DBV、SQL Server 走 DBCC CHECKDB文件系统做 fsck 或 chkdsk业务层面做登录、读写、增删改查性能上把迁移前的 IOPS 和延迟基线拿出来迁移后再跑同一套基准测试。如果延迟明显变差优先检查存储网络 MTU 和多路径然后再看缓存水位和磁盘队列深度。回退预案也要提前写双写窗口保留一到两周源 SAN 链路不要当时就拆存储快照保留一份。确认验证全部通过后再释放旧 LUN。从那以后我每批虚拟机迁移结束都会强制走一遍到这里的一致性复检再让业务侧开始商用确认无误才释放旧存储。希望帮到你。本文还有配套的精品资源点击获取 FusionCube超融合架构解析：部署调优与双活A-A实践
简介面向数据中心运维、解决方案架构师和企业IT决策者这是一份华为FusionCube 3.2虚拟化超融合基础设施技术白皮书系统讲解超融合平台的产品价值、FusionSphere与VMware双场景架构、分布式存储、高性能与线性扩展能力并完整阐述认证授权、加密及访问控制等安全机制以及高可用、故障恢复和数据保护设计可作为规划超融合数据中心、理解HCI架构原理和开展选型评估的参考材料。文档对FusionSphere与VMware场景的典型配置、组网方式和工作原理均有说明还覆盖分布式存储的数据路由、IO路径与Cache机制等关键技术细节。压缩包为单个docx文档大小6.35MB目录结构完整从产品概述到关键业务流程均有章节索引便于直接查阅或做团队分享。已有392人学习下载适合需要了解华为超融合方案或系统学习HCI落地要点的读者。1. FusionCube超融合为什么它不该被当成“几台服务器”第一次看到 FusionCube 超融合平台的报价单很多运维会以为 IT 部门买了一台更贵的 PC 服务器——这个误会值得先拆掉。FusionCube 超融合平台把计算、分布式块存储和网络交换融合进同一个机架单位交付后不再是存储阵列、SAN 交换机、虚拟化服务器三套设备而是一组带统一管理面的融合节点。它解决的是中小团队“存储扩容要排期、虚拟化挂盘要协调”的老问题适合已经在跑虚拟化、又不打算继续维护独立 SAN 的运维和架构师。这篇笔记按白皮书里的架构、部署、调优和排障顺序整理把关键参数和踩坑点都标出来照着走能少走大半弯路。2. 双活A-A架构与硬件形态先把“融合”这个词拆明白2.1 超融合到底“融”了什么在讲 FusionCube 之前先看传统架构是怎么堆的机架服务器负责跑虚拟化集中式存储阵列存数据SAN 交换机在中间负责连接。扩容时先买盘柜、再划 LUN还要维护光纤交换机上的 zone、多路径软件、存储映射任何一个环节断链都会影响生产。超融合把这三层压进一组 X86 节点。每台节点都有本地 CPU、内存和磁盘分布式存储软件把各节点的本地盘聚合成一个全局共享存储池虚拟化层和存储层跑在同一批服务器上数据通过内部以太网横向复制不再经过独立的存储控制器。FusionCube 的核心组件就这么来的FusionSphere 负责虚拟化FusionStorage 负责分布式块存储两者通过管理面统一调度。这套架构带来的第一个变化是性能瓶颈从“存储控制器处理能力”变成了“网络吞吐和磁盘调度”。传统 SAN 的性能上限由控制器决定扩容要换控制器或加盘柜超融合加一台节点计算、存储容量、存储性能同时增加扩展粒度小得多。这也是 FusionCube 白皮书里反复强调“横向扩展”的原因加节点不像加盘柜那么有仪式感却比换控制器便宜也没有控制器之间的双活配置成本。2.2 双活A-A与副本机制FusionCube 的存储层是“全活”架构所有节点同时参与 IO不存在一台存储主控加一台备控“主备等待”的状态。数据被切成固定大小的分片通过一致性哈希分布到所有节点磁盘上每个分片保存多个副本副本的落点会避开同一个节点和同一个磁盘。副本数直接影响可用容量和可靠性。先在白皮书里确认你当前的版本支持哪种副本策略再去看容量。常见的选型逻辑大概是这样副本策略可用容量估算能容忍的故障故障域配置得当推荐场景2 副本约裸容量 / 2单盘故障、单节点故障开发测试、非核心业务3 副本约裸容量 / 3同故障域下两节点或多盘同时故障生产数据库、关键应用故障域把副本分布到不同机柜或不同节点组防止整体掉电或机柜级故障导致数据一次性丢失。我一般建议生产环境至少用 3 副本并把故障域设为“节点级”也就是同一分片的两个副本不允许落在同一台节点上。副本数选多了可用容量下降明显选少了故障窗口太窄这个选择题要在建池之前做完事后改副本策略的动静远比想象中大。2.3 硬件形态边界它和PC服务器不是一个物种“超融合服务器可以归类 PC 服务器吗”——这个搜索词基本等于在问“我能不能用通用服务器把它替换掉”。从 CPU、内存、硬盘接口来看FusionCube 的硬件确实是标准 X86 技术栈但你按 PC 服务器的思路来维护它后面会翻车。原因有三层。第一整机 BOM 是锁定的板卡、磁盘、固件都按超融合平台的兼容列表配套过白皮书里也强调固件一致性混插同容量但不同型号的硬盘底层存储会认为节点异常。第二存储网络参与分布式存储协议节点间的数据同步依赖专用队列和 RDMA 能力通用网卡不一定能接手。第三管理平面和带外监控是整套系统的一部分按单台服务器来孤岛式管理会丢掉全局告警和联动升级的能力。所以结论是形态上是 X86 服务器工程边界上不是 PC 服务器。日常巡检可以按服务器看温度、看风扇但换硬件、升级固件、扩容节点必须回到超融合平台的兼容列表和变更流程里走。2.4 和主流超融合厂商技术的差异做选型的人通常会把华为 FusionCube 和深信服超融合、Nutanix、VMware vSAN 这类产品放在一起比。只看白皮书可能看不出差异点我的对比经验是看三条线。交付形态FusionCube 偏一体机存储节点、管理节点和网络在出厂时已经预集成到现场接通电源和链路就能进入部署纯软件方案由客户自己选服务器和交换机灵活但验证成本在自己身上。存储路径FusionCube 的分布式存储和硬件耦合更紧支持方向是“按官方兼容列表走”纯软件方案对硬件宽容度更高但要自己负责更多硬件排障。网络方案FusionCube 常见 RoCE 网络来消化存储流量配套交换机的 PFC、ECN 参数必须对齐vSAN 也可用 RDMA但很多存量机房实际跑的还是普通万兆 TCP。我的建议是如果机房已经有一批标准化 X86 服务器纯软件方案可能更顺手如果是从零建机房、想少背几个维护包袱一体机交付的 FusionCube 能让开局快很多。架构层的概念先放一边下一章直接进入部署。3. 部署一台能用的FusionCube从存储池规划到LUN上线3.1 部署前的容量与网络规划部署前别急着开箱。有三个问题必须先定下来节点数、副本数、存储网速率。节点数决定容量和故障域布局。三节点是最小集群但三节点加 3 副本时一个节点故障要在剩余两节点上重建数据风险窗口比较大。我一般建议起步就是 4 节点这样 3 副本模式下坏一台节点还有足够空间做数据重建。容量按公式算可用容量 ≈ 裸容量 ×1 - 预留比例÷ 副本数 ×1 - 元数据开销。预留比例我习惯留 10%元数据开销按 3%~5% 估具体看版本。举一个常见配置4 节点、每节点 8 块 4TB 硬盘裸容量 128TB3 副本预留 10%元数据按 4%算下来可用容量约 36.9TB。如果不开精简置备虚拟机能写进去的空间就是这么多。规划项建议值说明管理网络1GE 或 10GE独立 VLAN承载管理面心跳和带外管理不要和业务混跑业务网络10GE / 25GE独立 VLAN承载虚拟机东西向流量存储网络25GE 起步RoCE 建议打开承载分布式存储复制流量MTU 对齐 9000网络规划有个容易忽略的点管理、业务、存储三个平面必须分开。超融合比传统架构更依赖管理面一旦管理心跳和存储流量抢同一链路故障时你连告警都收不全。每个平面至少两路物理链路存储网优先使用独立交换机或至少独立 VLAN。3.2 初始化流程从硬件上电到存储池可用FusionCube 的一体机交付白皮书一般会给出标准开局顺序我按实际操作经验整理成以下几个步骤。第一步硬件上电连接管理口在管理界面里配置带外 IP确认所有节点被纳管并且版本一致。不同批次节点的固件版本必须对齐这是后面换盘不翻车的前提。第二步导入软件许可证配置系统时间NTP 必须指向稳定时钟源和 DNS。时间不同步会造成证书校验失败和日志时间线错乱排障时很痛苦。第三步创建存储池。这一步要选择介质类型全闪、混合、副本数和故障域。全闪池性能和成本都高混合池用 SSD 做缓存、HDD 做容量层。副本数和故障域按生产需求选宁可一开始副本数多预留一点容量也不要事后降副本。第四步等待数据平衡完成。新集群建完后系统会把数据均匀分布到各节点观察后台任务进度等 rebalance 结束再开始建虚拟机。第五步在存储池上创建 LUN按业务规划决定容量和名称映射给计算节点。提示存储池创建后不要急着建虚拟机先确认 rebalance 任务已经完成否则前几个小时的 IO 会不稳定。这套流程里最容易跳过的一步是固件版本核对。我见过有人直接跳过版本巡检进存储池结果存储节点之间版本不一致存储池一直处于告警状态。3.3 映射到虚拟化平台与验证LUN 映射完成后进入虚拟化平台把存储挂上去。这一步叫添加存储本质是把 LUN 格式化并注册为数据存储。挂载后先别急着建虚拟机先做一次路径和性能验证。在 ESXi 上我一般会先看设备是否被正确识别# 列出 ESXi 识别的存储设备 esxcli storage core device list # 检查每条路径的当前状态 esxcli storage core path list正常状态是每个 LUN 显示多条 Active/Optimized 路径。如果看到 Dead 或 Standby别往下走先按第 5 章的 MTU 和链路问题排查。路径验证通过后再创建一个小型测试虚拟机做一轮磁盘读写测试确认 IO 正常后再放业务。参数说明esxcli 是 VMware 的存储命令行入口device list 看设备级状态path list 看多路径状态。设备正常才能保证后续虚拟磁盘 IO 有冗余路径可走。挂载后的另一项验证是“数据存储可见性”也就是确保每个计算节点都能看到同一个 LUN而不是只有部分节点能看到。分布式存储映射遗漏是开局阶段最典型的问题表现是虚拟机只能在部分主机上启动迁移时直接报“主机无法访问存储”。4. 性能与网络调优RoCE、缓存和IO路径上的关键参数4.1 存储网的正确打开方式RoCE 下的 PFC 与 ECNFusionCube 这类超融合设备存储流量默认走内部以太网。如果存储网还是千兆加普通 TCP分布式复制的高峰流量会把链路打满IO 延迟就会很“玄学”——这边看着磁盘不忙那边虚拟机却在卡顿。启动 RoCE 是常见的优化方向但 RoCE 依赖无损网络不能简单地开个开关。PFC优先级流控为存储流量所在的队列提供无丢包保障ECN 负责在队列拥塞前标记报文让网卡自动降速。这两个参数必须和交换机、网卡两端对齐。我一般会这样做给存储流量分一个独立的高优先队列在其他队列之上配置 PFCMTU 统一 9000。# 交换机端口示意存储流量进入队列3打开PFC interface 10GE1/0/1 mtu 9000 qos map 2 to queue 3 qos queue 3 pfc on这里有个反面教训把管理、业务流量也全部塞进无损队列遇到广播风暴时PFC 会把存储队列一起卡死整个集群 IO 中断。无损队列只给真正需要低延迟、低丢包的存储流量用其他流量按普通队列走。参数说明mtu 9000 是为了避免大帧分片qos map 把存储报文的优先级映射到队列 3pfc on 让该队列启用优先级流控。不同交换机的命令风格不一样但思路是通用的确定存储 VLAN、绑定优先级、打开 PFC、核对 MTU。4.2 缓存怎么调读写缓存与回写降级混合介质池里SSD 和 HDD 不是简单堆在一起。FusionStorage 的逻辑是SSD 承担读写缓存和高频随机 IOHDD 主要放容量型数据后台把数据从性能层刷到容量层。读缓存提升随机读命中率写缓存先落 SSD再异步回写 HDD这样写 IO 对 HDD 的随机压力会小很多。真正需要盯的是写缓存水位。回写模式下缓存超过高水位就会把新写入强制降级为直写IO 延迟可能会跳到十几毫秒甚至更高。参数常见建议值说明写缓存高水位75%~80% 触发提示90% 停止新增写入具体数值以当前版本默认值为准刷盘频率按业务类型调整太高增加 HDD 压力太低缓存容易占满读缓存比例保留适当余量别把读缓存配满要给写缓存留空间缓存调优的常见做法容量型业务文件存储、备份可以调低刷盘频率少占 CPU性能敏感型业务数据库则要把高水位调低提前触发告警避免缓存占满后断崖式降级。如果频繁看到“写缓存达到高水位”的告警优先扩容 SSD 缓存而不是继续优化参数。4.3 虚拟机侧磁盘置备、控制器和队列深度存储层的参数调好之后虚拟机侧的决定也会影响最终表现。磁盘置备生产虚拟机建议用厚置备避免 thin 磁盘在数据增长时出现扩容毛刺。测试环境用 thin 可以省容量但必须部署容量告警否则超分会导致整个存储池变满。SCSI 控制器不要在虚拟机上用 IDE 控制器换成半虚拟化 SCSI 控制器VMware 下的 PVSCSI 或华为虚拟化平台的 virtio-scsi队列深度和吞吐都更高。队列深度默认值太小时高并发 IO 压不出性能调得太大又会把压力全转到存储节点上。常见做法是先保持默认跑一轮基准测试再逐步调队列深度直到延迟有明显回升的位置停住这个点就是本集群的边界。块大小和对齐底层分布式存储按条带切数据虚拟机文件系统格式化的块大小如果和条带差异过大顺序 IO 会多一次跨越。通用做法是虚拟机内格式化为 4K底层条带按 1MB 级别规划对多数业务已经够用。5. 常见问题与避坑超融合排障时的五个现场超融合有个和传统架构不同的特点出问题的时候你没有单独的存储控制器可以摘掉排查。磁盘、网络、虚拟化在同一个机架里牵一发动全身。以下五条是真实场景里高频翻车的问题每一条都按“现象 → 原因 → 解决”写。5.1 一块盘掉线整个集群跟着抖现象某节点的一块硬盘掉线后集群 IO 延迟突然飙升虚拟机的监控曲线出现明显尖峰持续几十分钟。原因故障硬盘触发数据重建重建数据的读 IO 和业务写 IO 争抢同一台节点的磁盘与网络资源超融合集群里表现成“单盘故障引发的集群级抖动”。解决在存储管理界面把重建带宽限制到一个安全值我一般设置为不超过节点存储带宽的 30%。同时把重建任务安排在业务低峰期执行。重建期间不要同时进行扩容或备份避免多个后台任务叠加。5.2 LUN 映射过去主机侧存储路径一片红现象LUN 映射完成后虚拟化平台里能看到设备但路径状态是 Dead虚拟机无法在部分主机上启动。原因最常见是网络 MTU 不一致。存储网要求 9000但映射主机的存储网卡或交换机端口还停留在 1500导致大帧被丢弃路径反复超时。其次可能是多路径插件没有正确加载。解决核对存储网所有相关端口和主机网卡的 MTU统一 9000然后重新扫描存储适配器加载对应多路径插件。在 ESXi 里检查每条路径的状态确认全部回到 Active/Optimized 后再继续。5.3 换盘一直失败卡在“等待 Rebuild”现象磁盘故障后按容量买了同规格新盘插上后状态不是“Rebuild 完成”而是反复失败甚至整台节点被标记为异常。原因新盘型号不在兼容列表里固件版本和整机不一致。分布式存储对硬件一致性很敏感控制器识别到未知型号后直接拒绝写入数据。解决换盘前先查兼容列表和当前节点的固件版本。如果换盘已经失败先在带外界面确认固件版本再把新盘对齐到同版本最后手动触发重建任务。从那以后我换盘都强制走一遍兼容性核对再下单。5.4 管理面心跳丢包集群直接脑裂现象两台管理节点之间网络抖动集群出现“脑裂”告警业务 IO 短暂中断。原因管理、业务、存储三网混在同一个链路上某条业务链路打满后管理心跳报文被丢弃管理节点之间失去联系触发隔离保护。解决管理、业务、存储三个平面严格分离管理平面至少绑定两路独立链路。不要在同一个交换机上同时跑管理流量和存储流量。物理隔离做不到的就用 VLAN 加独立队列。5.5 备份任务一跑生产立刻变慢现象定时备份或快照任务启动后生产虚拟机的写延迟明显上升备份结束后恢复。原因备份任务和业务写流量共用同一个写缓存池和同一组存储节点。快照读取产生的随机读会占用读缓存写缓存水位也被推高缓存降级直写后生产 IO 就跟着变慢。解决尽量把备份流量限制在低峰期给备份 VM 设置独立的存储池或独立的 LUN减少和生产资源争用。如果无法分离备份窗口内把备份并发数调低优先保证生产 IO。6. 迁移到FusionCube的实操路径从SAN搬迁与一致性验证6.1 三种迁移路径的取舍从传统 SAN 迁到 FusionCube没有一种“全网通用”的迁移方式。先看停机窗口再看一致性要求。迁移方式停机时间一致性保证适用场景基于虚拟化的存储热迁移storage vMotion几乎为零依赖虚拟化层一致性文件服务器、应用服务器存储层异步复制 / 双写数分钟到数十分钟按复制点保证一致性数据库、关键业务备份恢复停机较长取决于备份恢复逻辑非关键系统、物理机改造我的经验是数据库优先用异步复制或双写切到新端前做一次完整的数据库校验文件服务器用存储热迁移最省事。如果业务接受停机备份恢复是最稳的方案回滚也简单。白皮书里对迁移的架构描述比较完整但界面路径、命令清单和运行截图在文档里更全下载下来对照实操会更稳。6.2 迁移后的验证清单别把数据搬完就交差迁移完成不等于项目结束。我会按以下清单逐项检查数据库的一致性校验Oracle 走 DBV、SQL Server 走 DBCC CHECKDB文件系统做 fsck 或 chkdsk业务层面做登录、读写、增删改查性能上把迁移前的 IOPS 和延迟基线拿出来迁移后再跑同一套基准测试。如果延迟明显变差优先检查存储网络 MTU 和多路径然后再看缓存水位和磁盘队列深度。回退预案也要提前写双写窗口保留一到两周源 SAN 链路不要当时就拆存储快照保留一份。确认验证全部通过后再释放旧 LUN。从那以后我每批虚拟机迁移结束都会强制走一遍到这里的一致性复检再让业务侧开始商用确认无误才释放旧存储。希望帮到你。本文还有配套的精品资源点击获取