企业官网建设流程全解析

1. 信创超融合选型前，先想清楚这四件事

信创超融合不是把“国产CPU服务器+国产虚拟化软件”堆在一起就完事，选型真正的门槛在业务适配和长期运维。IDC报告里能看到市场份额排名，但落到自己机房，得先回答四个问题：跑什么业务、有多少存量物理机/虚拟机、现网网络架构能不能平滑过渡、后续扩容是加节点还是换整柜。

先说业务类型。办公系统、邮件、OA这类业务，对IOPS和时延要求不高，国产CPU的问题暴露不明显；但生产数据库、大数据分析、高并发Web服务，对CPU指令集、虚拟化调度、存储热点的敏感度完全不同。很多信创项目验收时跑得好好的，一上生产性能就翻车，根子往往在选型时没区分业务等级。

再说存量资产。大部分单位不是从零新建，而是有一堆存量x86服务器和VMware虚拟机。信创超融合如果只能“推倒重来”，成本会直接劝退。好的方案应该支持纳管存量主机、在线迁移业务镜像、保留原IP和主机名，甚至支持异构CPU混池——虽然混池性能有损耗，但能让迁移窗口放宽到几个月而不是几周。

第三看网络。超融合最怕“节点间通信挤在一条线上”。千兆环境下，5节点以上IO就开始明显变慢；万兆起步才算合格。选型时一定要问清楚：方案用的是标准TCP/IP还是RDMA？RoCE网卡能不能复用？交换机的缓存和端口缓存够不够扛突发？

最后是扩展策略。信创超融合扩容有两种路线：垂直加盘/加卡，或者水平加节点。垂直便宜但有上限，水平扩展要考虑集群规模的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颗CPU（32核/颗），内存512GB，系统盘用2块480GB SATA SSD做RAID1，缓存盘用2块1.92TB NVMe SSD，数据盘配12块4TB SATA HDD。这样单节点裸容量48TB，三副本后可用16TB，5节点就是80TB可用空间，够初期用了。

网络是重头。每节点配2块25G光口网卡（存储+迁移平面）和4块千兆电口网卡（管理+业务平面）。交换机直接上两台25G ToR，做MLAG双活。这里特别测量了一件事：RoCE模式下PFC死锁恢复时间——厂商承诺的是两个节点同时故障30秒内恢复正常，实测结果在业务低峰期能达标，高峰期会到40多秒，但业务侧没有报错，能接受。

关于存储副本策略，我们最终选了三副本，但没有全集群统一，而是按“业务重要程度”划分存储池：核心数据库池三副本，普通应用池两副本。这样做的好处是成本可控，坏处是后期运维多一个存储池要管理，巡检要同时盯两套副本的健康状态。如果有预算，建议一开始就全三副本，省心很多。

3.3 存量业务迁移：从VMware到信创，别硬迁

迁移是整个项目里最磨人的环节。我们分三步走：

第一步，盘点与分类。把200多台虚机按“操作系统、应用类型、数据敏感度、可停机窗口”四维分类。Windows Server 2008/2012的存量机器，很多跑了非常老的应用，直接迁到KVM平台可能驱动和SID都有问题，这类机器不强行迁，优先用新机器重新部署应用（重装大法）；Linux（CentOS 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并发录入场景、一个报表导出场景）搬上去跑两到三天，观察业务侧响应时间和错误日志，这才算数。

建议二：把“运维可运维性”放进评分表。别只看“功能有多全”，要看“日常操作有多简单”。一个只有专家能玩的系统，和一个人人能快速上手的系统，一年后的运维效率和故障恢复速度会差很多。可以问厂商要一份《日常巡检手册》，看是不是每个运维动作都有明确截图和命令示例。

建议三：合同里写明“升级不破坏兼容”条款。国产超融合软件迭代很快，但版本升级引入的兼容性问题也很常见。合同里一定要写清楚：软件升级必须保证现有虚拟机和存储池的兼容性，若升级导致业务不可用，厂商要无条件回滚并承担损失。这句话能省掉很多扯皮。

最后分享一个最实用的避坑技巧：买之前，先让厂商做一次“反向兼容性清单”。不是厂商给你一个“我们支持的操作系统列表”，而是你把自己现网所有应用、数据库、中间件版本列出来交给厂商，让架构师逐一确认“这些版本在这个信创超融合平台上的支持程度”，并签字盖章。这个清单比什么测试报告都靠谱，因为它把账号绑定到了具体人和具体版本上。

超融合选型没有银弹，最终都是“业务适配+团队能力+供应商支持”的三方平衡。希望这份手记能帮正在做选型的同行少走几步弯路。