1. 信创超融合选型前先想清楚这四件事信创超融合不是把“国产CPU服务器国产虚拟化软件”堆在一起就完事选型真正的门槛在业务适配和长期运维。IDC报告里能看到市场份额排名但落到自己机房得先回答四个问题跑什么业务、有多少存量物理机/虚拟机、现网网络架构能不能平滑过渡、后续扩容是加节点还是换整柜。先说业务类型。办公系统、邮件、OA这类业务对IOPS和时延要求不高国产CPU的问题暴露不明显但生产数据库、大数据分析、高并发Web服务对CPU指令集、虚拟化调度、存储热点的敏感度完全不同。很多信创项目验收时跑得好好的一上生产性能就翻车根子往往在选型时没区分业务等级。再说存量资产。大部分单位不是从零新建而是有一堆存量x86服务器和VMware虚拟机。信创超融合如果只能“推倒重来”成本会直接劝退。好的方案应该支持纳管存量主机、在线迁移业务镜像、保留原IP和主机名甚至支持异构CPU混池——虽然混池性能有损耗但能让迁移窗口放宽到几个月而不是几周。第三看网络。超融合最怕“节点间通信挤在一条线上”。千兆环境下5节点以上IO就开始明显变慢万兆起步才算合格。选型时一定要问清楚方案用的是标准TCP/IP还是RDMARoCE网卡能不能复用交换机的缓存和端口缓存够不够扛突发最后是扩展策略。信创超融合扩容有两种路线垂直加盘/加卡或者水平加节点。垂直便宜但有上限水平扩展要考虑集群规模的License成本。很多厂商报价单里“每节点License”和“每TB容量License”分开算算总账时尤其要小心。这四个问题想透了再去看IDC报告里那些排名和份额才不会被数字带偏。毕竟报告归报告自己的业务就绪度、团队运维能力、供应商在本地有没有人才是真正的决定因素。2. 信创超融合的核心指标不是“能跑”而是“跑得稳、坏得起、迁得动”2.1 硬件选型CPU、硬盘、网卡都有坑信创超融合的硬件部分CPU是第一个分水岭。目前主流是鲲鹏ARM、海光x86、飞腾ARM、龙芯LoongArch、申威Alpha这几类。选型时别只看核数和主频关键要问虚拟化层对这类CPU的特性支持是否完整比如海光是x86架构兼容性最好原有基于x86编译的软件基本可以直接跑迁移改造成本最低鲲鹏和飞腾是ARM生态相对依赖源码重编译但如果业务本来就是Java/Python这类跨平台技术栈影响其实不大龙芯和申威的非主流指令集对第三方闭源软件比如某些商业数据库的特定版本可能直接装不上选之前必须做一次“软件兼容性摸底”。硬盘方面信创超融合普遍配NVMe SSD做缓存层或全闪层。这里有两个容易被忽略的点一是SSD的耐久度DWPD超融合写入放大会放大SSD磨损选企业级SSD时DWPD至少1.0以上最好到3.0二是盘控配合ARM平台搭配的SSD固件如果没做适配可能出现异常掉盘、性能剧烈波动。建议让厂商提供“已验证兼容清单”不接受“应该没问题”这种说法。网卡是另一个重灾区。信创服务器目前很多默认配千兆电口但超融合存储至少万兆起步。有些厂商的方案支持25G/100G RoCE如果预算允许优先上25G因为超融合的存储性能很大程度取决于网络。RoCE虽然能降低CPU开销但需要交换机支持无损网络PFC/ECN这对现网交换机是个硬门槛。如果没有条件改造网络那就明确要求厂商给出“万兆普通TCP”下的性能基准值别拿RoCE的理想值来忽悠。2.2 软件栈虚拟化、分布式存储、管理平台三层都必须“信创”信创超融合的软件栈不是随便装个开源的KVM和Ceph就能交差。现在主流国产超融合平台比如深信服、华为、浪潮、新华三、中兴等都基于KVM做虚拟化但KVM只是内核部分上面的管理平台、迁移工具、存储调度、高可用机制才是厂商真正积累壁垒的地方。选型时把软件栈拆成三个层面来看虚拟化层基于KVM是主流但要确认厂商是否深度定制了CPU调度、内存复用、NUMA感知、大页内存这些特性。特别是有没有针对国产CPU做优化比如鲲鹏的亲和性调度、海光的虚拟化扩展SEV-ES支持。对大部分业务而言KVM原生就够但如果你要跑Oracle RAC这类对锁和内存敏感的数据库就得问清楚厂商有没有专门调优。分布式存储层这是超融合的“心脏”。要关注副本机制两副本还是三副本、故障域设置主机级、机架级还是数据中心级、数据重建策略是否限速、是否优先保证业务IO、硬盘亚健康检测能不能提前发现坏道和慢盘。信创环境下尤其要看存储层是否支持“跨代异构扩容”比如老节点是SATA SSD新节点是NVMe能不能混池并自动做分层调度而不是一刀切全池降速。管理平台层信创超融合的管理平台不仅要做虚机生命周期管理更要支持信创要求的“一云多芯”纳管。比如同时管理鲲鹏池和海光池甚至x86存量池能不能在一个界面上统一监控、统一迁移。此外国产化环境下的安全合规等保2.0、密评也需要管理平台有对接能力比如日志审计、三权分立、双因素认证这些基础功能。2.3 高可用与容灾不是“有HA”就行要追问RPO/RTO信创超融合的高可用很多销售会说“我们有HA”但“有HA”和“满足业务可用性要求”是两码事。选型时至少追问三个细节故障恢复时间RTO一个节点宕机虚机自动重启到另一节点是分钟级还是秒级秒级切换需要存储层支持内存数据同步或者持续性快照不是所有方案都有。数据恢复点RPO默认的RPO通常是“最后一份落盘数据”但如果虚机内存里有未落盘的交易数据宕机就丢了。对核心数据库业务要问有没有“一致性快照日志回放”能力把RPO降到接近零。故障域设计信创超融合的故障域最低是主机级高级一点支持机架级。如果你只有两节点很多厂商会声称“两节点也能建集群”但两节点没有仲裁节点脑裂风险极高。建议至少三节点起步或者采用“两节点外置仲裁”模式仲裁要独立于业务网络。2.4 数据迁移存量VMware迁移要提前做“兼容性体检”信创超融合替换VMware是常见场景但迁移不是把这个虚机导出来再导进去那么简单。VMware里的虚机可能是厚置备磁盘、带VMXNET3网卡、装了VMware Tools直接导到KVM平台会遇到驱动不兼容、磁盘格式不一致、网络配置失效等一系列问题。好的迁移工具应该支持无代理迁移不用在源虚机里额外装Agent在线迁移业务不中断至少中断窗口可控转换时自动适配磁盘总线类型IDE转VirtIO、LSI转SATA、网卡类型E1000转VirtIO保留原IP、原主机名和静态网络配置对源端为Windows的虚机能自动注入KVM平台需要的virtio驱动防止迁移后蓝屏。这些能力大部分国产超融合厂商都有但“有”和“全面兼容”差距很大。建议选型时拿三五台典型虚机做一次完整迁移演练尤其是Windows Server和Oracle这类复杂业务别等割接日才第一次迁移。3. 实操手记一次信创超融合落地的完整过程下面用我经历的一次真实项目来串讲整个落地过程。背景某单位有约80台存量x86服务器跑着200多台虚拟机主流是VMware vSphere 6.7业务包括OA、邮件、ERP、部分Oracle数据库。信创要求是新增业务全部上信创存量业务视情况分批迁移。目标是建一套信创超融合集群规模从5节点起步后续扩展到16节点。3.1 选型对比与商务谈判别只看产品Demo选型阶段我们对比了深信服、华为、新华三、浪潮四家。坦白说各家产品在PPT上功能都差不多真正的差异在细节深信服超融合方案成熟度高管理平台易用性最好社区活跃售后响应快但License价格偏高且扩容是按节点容量双重计费。华为硬件自研程度高与泰山服务器配合最稳存储性能优化好但管理平台偏复杂对操作人员要求较高。新华三生态丰富与H3C网络设备联动好整体方案打包能力强但分布式存储的历史包袱稍重某些版本升级有坑。浪潮性价比突出尤其服务器硬件性价比高但软件成熟度和售后体系相对前三家稍弱。商务上几个容易踩的坑一是“首期5节点”和“满配16节点”的License单价可能完全不同谈判时要锁定未来3年的扩容量单价二是存储容量按“裸容量”还是“可用容量”算两副本和三副本的可用空间差别很大报价单必须写清楚三是原厂实施和本地代理商实施价格差很多但如果涉及复杂迁移强烈建议要求原厂顾问到场哪怕是远程支持。3.2 硬件配置与集群设计计算和存储要分开算账集群规划我按“计算为主、存储为辅”的思路设计。既然存量业务是VMware迁过来CPU选海光最稳妥x86兼容性最好每节点2颗CPU32核/颗内存512GB系统盘用2块480GB SATA SSD做RAID1缓存盘用2块1.92TB NVMe SSD数据盘配12块4TB SATA HDD。这样单节点裸容量48TB三副本后可用16TB5节点就是80TB可用空间够初期用了。网络是重头。每节点配2块25G光口网卡存储迁移平面和4块千兆电口网卡管理业务平面。交换机直接上两台25G ToR做MLAG双活。这里特别测量了一件事RoCE模式下PFC死锁恢复时间——厂商承诺的是两个节点同时故障30秒内恢复正常实测结果在业务低峰期能达标高峰期会到40多秒但业务侧没有报错能接受。关于存储副本策略我们最终选了三副本但没有全集群统一而是按“业务重要程度”划分存储池核心数据库池三副本普通应用池两副本。这样做的好处是成本可控坏处是后期运维多一个存储池要管理巡检要同时盯两套副本的健康状态。如果有预算建议一开始就全三副本省心很多。3.3 存量业务迁移从VMware到信创别硬迁迁移是整个项目里最磨人的环节。我们分三步走第一步盘点与分类。把200多台虚机按“操作系统、应用类型、数据敏感度、可停机窗口”四维分类。Windows Server 2008/2012的存量机器很多跑了非常老的应用直接迁到KVM平台可能驱动和SID都有问题这类机器不强行迁优先用新机器重新部署应用重装大法LinuxCentOS 7/8、Ubuntu虚机迁移成功率最高优先迁Oracle数据库单独评估因为涉及文件系统、ASM、网络监听配置迁移后要严格验证。第二步迁移演练。挑了三台典型虚机一台Windows、一台CentOS、一台Oracle测试库做试迁移。Windows那台果然蓝屏了原因是virtio驱动没注入成功厂商工具在迁移界面有个“注入驱动”勾选默认关闭开了之后还要等重启时驱动加载全程要30分钟。CentOS那台顺利迁完IP保留成功。Oracle测试库迁完后监听正常但ASM磁盘组报了一个告警排查半天是磁盘UUID冲突因为源端ASM盘有自定义标识迁移工具没带过来后面通过手工改ASM参数解决。第三步分批割接。每周割接两批每批不超过20台割接窗口选在凌晨。每台机器的割接流程固定为停机快照 - 迁移数据 - 目标端启动 - 保持原IP对外服务 - 业务验证 - 原平台释放资源。整个过程持续了五周基本没有出现影响业务的重大事故。唯一的经验教训是迁移当天不要再碰源端哪怕只是加个监控脚本都可能影响迁移数据的最终一致性。3.4 上线运维那些没写在文档里的坑集群上线后运维阶段也踩了几个值得记录的坑。第一坑慢盘问题。分布式存储最怕的其实是“慢盘”而不是“坏盘”。坏盘会被立即标记并重建慢盘却因为“还活着”而拖慢整个存储池的IO。我们的集群运行两个月后业务反馈数据库偶尔变慢排查发现是某块4TB HDD的延迟从20ms波动到300ms但SMART报告全是绿的。后来靠存储平台的“亚健康检测”功能标定并隔离了这块盘。这个教训是选型一定要选有慢盘检测和自动隔离能力的方案别手动去看SMART晚了。第二坑快照累积。迁移保护期我们做了很多快照但有些快照忘了删集群运行三个月后快照数量达到几千个。分布式存储的COW写时复制机制会让快照链上的每个IO都变慢后续通过对老快照做合并整理性能才恢复。日常运维一定要有“快照生命周期管理”制度比如7天自动清理。第三坑磁盘扩容的副本平衡。中途加了3块数据盘到存储池平台会自动做数据平衡但平衡过程会导致存储池IO明显下降。如果是在业务高峰期触发扩容业务侧能感觉到明显变慢。建议运维排程时把扩容操作放在周末并且提前预估平衡时间避免影响周一高峰。4. 常见问题与排查技巧实录4.1 性能不达预期先查网络再查盘信创超融合性能出问题很多人第一时间怀疑CPU或磁盘但其实网络是首要嫌疑。有一次客户反馈“虚机IO很慢”我们先是检查了SSD缓存命中率——正常又查了HDD组——也正常。最后发现是物理链路中一根光纤跳线接口脏了25G链路协商降级到万兆存储流量被卡在链路上。所以排查性能问题时务必备好光模块测试仪先确认链路协商速率和误码率再往上层查。4.2 国产CPU虚拟化的性能损耗怎么评估ARM架构的CPU在做虚拟化时中断处理和内存管理与x86不同某些场景下虚拟化损耗会比x86明显。所以选型时别只信厂商给的“物理机性能”要看“虚拟机性能”。建议用基准工具比如UnixBench、sysbench、dbench在物理机和虚拟机里各跑一遍对比损耗比例。正常损耗在5%~15%以内可以接受如果超过20%要追问厂商有没有开启CPU直通、NUMA亲和等优化。特别是跑数据库业务时建议直接采用“绑核大页内存共享存储”的组合方案把虚拟机性能尽量拉近物理机。4.3 信创超融合和原有VMware长时间并存怎么管理很多单位是“VMware信创超融合”双栈并存这种情况最头疼的是运维复杂度翻倍。我的建议是别试图在两个平台上做实时双写而是做好“主备切换”和“数据同步”两层。备份层面统一用一套备份软件同时兼容两个平台数据同步层面如果业务允许停机走定时导出导入如果不能停机用数据库层的复制机制或者应用层的消息同步不要依赖存储层的透明同步因为跨异构存储的同步始终是不稳定因素。4.4 信创验收和等保测评容易忽略的细节信创项目验收时除了性能指标还有几项容易被忽略一是管理平台的三员管理是否到位系统管理员、安全管理员、审计管理员要分开二是日志留存是否满足6个月以上三是是否具备防病毒和入侵检测的对接能力四是密码合规改造密评有没有预留接口。建议在招标阶段就把这些要求写进技术规范书避免验收阶段返工。我们自己就吃过亏前期没提密评接口后期被测评机构卡了一个多月。5. 三个选型建议和一个最实用的避坑技巧选型这件事我个人的体会是产品能力是一方面供应商的本地服务能力和运维团队的接受度更关键。三个建议供参考建议一POC测试一定要上真实业务负载。很多POC是拿FIO/IOmeter跑纯IO看起来数字漂亮但和真实业务差别很大。我推荐把最典型的业务流程比如一个ERP并发录入场景、一个报表导出场景搬上去跑两到三天观察业务侧响应时间和错误日志这才算数。建议二把“运维可运维性”放进评分表。别只看“功能有多全”要看“日常操作有多简单”。一个只有专家能玩的系统和一个人人能快速上手的系统一年后的运维效率和故障恢复速度会差很多。可以问厂商要一份《日常巡检手册》看是不是每个运维动作都有明确截图和命令示例。建议三合同里写明“升级不破坏兼容”条款。国产超融合软件迭代很快但版本升级引入的兼容性问题也很常见。合同里一定要写清楚软件升级必须保证现有虚拟机和存储池的兼容性若升级导致业务不可用厂商要无条件回滚并承担损失。这句话能省掉很多扯皮。最后分享一个最实用的避坑技巧买之前先让厂商做一次“反向兼容性清单”。不是厂商给你一个“我们支持的操作系统列表”而是你把自己现网所有应用、数据库、中间件版本列出来交给厂商让架构师逐一确认“这些版本在这个信创超融合平台上的支持程度”并签字盖章。这个清单比什么测试报告都靠谱因为它把账号绑定到了具体人和具体版本上。超融合选型没有银弹最终都是“业务适配团队能力供应商支持”的三方平衡。希望这份手记能帮正在做选型的同行少走几步弯路。