【摘要】本文分享了某银行私有云一云多芯（国产信创硬件）混合资源池建设中获得的宝贵经验和教训，从选型、安装部署到业务上线后的平台运维、迁移，涉及到CPU性能对比、传统网络与云化SDN网络的适配与融合方法、私有云平台的升级演进步骤及注意事项等满满干货，值得借鉴与学习。

【作者】白宇，某银行基础架构高级工程师，主要负责云计算、信创平台能力建设，擅长IaaS计算存储网络基础架构，对虚拟化、云原生有一定研发经验，后续计划研究面向AGI的基础架构建设路径。

　　引言

云计算已经成为企业IT转型的核心驱动力，预计“十五五”期间，云计算技术将迎来新的突破，银行企业建立并不断优化统一管理，高效灵活的私有云环境势在必行，而信创又为银行私有云建设带来了新的挑战。我行在进行私有云一云多芯（国产信创硬件）混合资源池建设的过程中，便遇到了诸多问题，在此过程中，通过对架构思路和解决方案的不断探索，产生了很多经验、思考与教训。

本文从选型思路入手，分析x86海光CPU与ARM鲲鹏CPU的性能对比，分享传统网络与云化SDN网络的适配与融合方法、私有云平台的升级演进步骤及注意事项，并介绍我行在运维自动化的能力建设、多虚拟化/云平台间的跨平台底层克隆迁移、私有云组件/服务的高可用故障演练等各方面的实践经验，还剖析了建设过程中踩坑的几个典型问题实例。希望在信创产品的选型与建设、私有云的运维与运营方面，为广大金融行业同行提供有益的参考。

　一、私有云服务选型

当前业界金融行业私有云供应商主要有5种类型：

1、公有云提供商。采取线上（公有云）/线下（私有云）产品组织能力协同，由成熟的ToC公有云产品服务解决方案，推广复制到ToB私有云产品服务解决方案，提供混合云、私有云、专有云等云化部署形态。典型厂商：亚马逊、阿里云、腾讯云、百度智能云等。

2、传统IT设备提供商。在IaaS基础设施硬件（计算、存储、网络、安全等）和由成熟的虚拟化（如KVM）、云化编排平台（如OpenStack）等开源系统软件的基础上，结合网络SDN软件定义网络能力、云化管理软件、多云管理平台，由传统的硬件设备、虚拟化产品供应商，演进到IaaS云化服务提供商。典型厂商：浪潮、新华三等。

3、中小私有云独立提供商。通过业界前沿技术积累创新，为行业客户提供小规模定制化私有云（IaaS/PaaS/SaaS）产品解决方案。典型厂商：EasyStack易捷行云、UCloud优刻得、Alauda灵雀云等。

4、运营商“云”。依托强大的机房、骨干网络等基础设施和政企服务能力，为政府、公共事业、大型国企提供政务云、国资云、公共云等行业云化产品服务。典型代表：天翼云、移动云、联通云等。

5、金融行业“云”。大型金融机构依托行业技术积累和监管合规要求，提供机房设施托管云、行业SaaS服务等基础设施和云化产品。典型代表：银联云、建行云等。

其中华为等厂商比较特殊，其私有云经过由传统IT设备提供商模式演变到公有云提供商线上/线下协同模式。

我行根据业务发展需要，综合评估云服务提供商安全资质、厂商技术能力、服务本地化支持、项目人员投入情况、商务因素等，选择和一家公有云服务商进行信创私有云合作联创（一云多芯异构资源池建设），为后续全面信创建设做好设备选型对比和技术能力储备等前期准备工作。

　　二、CPU性能对比

计算密集型性能测试

测试分解大质数的计算密集型任务，鲲鹏920 相比海光2代7280有一定性能优势。

MySQL性能测试

海光/鲲鹏测试虚拟机规格均为8C16G，虚拟机磁盘均为SSD/文件系统XFS。

按照鲲鹏厂商工程师调优建议，对鲲鹏服务器BIOS关闭smmu，CPU预取/内存刷新频率由32调整为64；对鲲鹏服务器BIOS修改参数后，鲲鹏在不同操作类型和并发数的多个场景，MySQL5.7/8.0 2个版本相较海光QPS均有一定优势。

（备注：mixed 100并发场景，厂商解释因为内存太少压测不能体现鲲鹏CPU性能优势，需扩容内存或使用BoostKit调优工具对锁进行优化。）

海光CPU利用率比鲲鹏约低1/3，8个vCPU负载较为均衡；鲲鹏vCPU占用较高，vCPU之间负载有一定差异。

性能调优对比

当前鲲鹏920不支持超线程机制（厂商回复鲲鹏920+支持，发布时间待定），海光单CPU可运行更多线程。

鲲鹏为发挥其CPU多核性能优势，需做针对性的调优，如内存和CPU的NUMA亲和性绑核等，需考虑与虚拟化平台、业务使用规范的兼容性。

　三、网络适配融合

私有云云内组网物理拓扑图参考如下：

・云内计算节点overlay 的vxlan vtep端点起在各个计算节点虚拟网桥上（vxlan-vtp端口，作为云上虚拟机vxlan封装的vtep）；

・云内/外部网络underlay 和云内overlay 的vxlan vtep端点起在云内网关组件（部署在管控/网关物理机上的虚拟机），例如安全服务（云上underlay）和ECS互访，网络报文会在云内网关组件做vxlan封装/解封装转换；

・通过专线接入的传统IDC或公有云POP点，传统underlay网络和云内overlay网络的vxlan vtep端点起在DAS交换机，专线外underlay到云上overlay 做vxlan封装，云上overlay到专线外underlay 做vxlan解封装；并在物理专线上使用虚拟（逻辑）接口，预留多租户专线网关云外接入云内网络访问能力；

・云上overlay之间的流量互通，通过软件定义网络SDN方式，其中云厂商自研的各个网络服务软件组件，将网络拓扑配置信息实时写入etcd；网关节点、负载均衡、计算节点等数据面节点上有对应网络服务组件订阅etcd里的相关数据；当控制面数据有更新时，会获取到相应变化，并通知SDN控制器组件，更新数据面转发流表；

・云下underlay和云上overlay 互通的流量经过DAS专线网关交换机，例如桌面云通过专线访问虚拟机，使用一组P4设备作为DAS交换机数据面的SDN控制器，负责专线网关VNI（DAS）和VPC VNI的映射关系，将云下underlay由DAS交换机进入的流量转发到对应的网络组件；

・公有云在传统underlay物理网络基础上，采用overlay虚拟网络结合SDN软件定义网络，实现网络控制面和数据面独立解耦，支撑公有云上大规模多租户逻辑组网需求，并自研多种网络组件实现灵活多样的网络服务；

・线上/线下协同的私有云平台，沿用了公有云云网融合模式，在提供组网灵活性的同时，也大大增加了网络运维的复杂度，打破了传统网络的运维职责边界。

由于云上网络模型的复杂性，通过和厂商开展多次网络方案交流学习，进行多次网络抓包、数据流量走向探究，积累了一定的知识文档总结，形成通用网络问题的独立运维能力。

其中，重点关注了传统underlay vlan网络和私有云overlay vxlan云上网络在专线接入网关侧的高可靠性，并进行了相关专线接入交换机故障演练，发现并优化了多个潜在问题，并且在日常巡检中通过脚本方式自动采集相关网络组件状态进行定期健康检查。

　　四、平台升级演进

由于合作厂商公有云产品和服务快速迭代，跟随厂商云平台线上/线下协同模式，避免平台版本滞后导致的研发支撑能力不足，同时为验证私有云平台平滑升级演进能力，在项目建设初期，我行进行了较为频繁的云平台版本升级（每个季度进行一次）。

升级过程主要分为：

1、厂商提供升级文档方案

2、升级前方案评审和风险评估

3、升级包确认并下载到内网环境

4、升级前置检查

5、升级窗口各组件/服务升级实施

6、升级后复盘总结

7、升级后遗留问题修复

8、升级完成确认

由于私有云平台底层厚重（涉及多个管控/网关节点、多个管控面K8S集群）、搭载包括云监控、PaaS集群、数据库/中间件等多种云服务，每次版本升级，前置准备阶段约需要1周时间，实施时间窗口约为1-2周，升级后遗留问题修复约为1-2周，其中每个阶段均需要厂商深度参与，协调后方研发远程及时支撑，避免升级过程中断和升级时间不可控。

相对于成熟虚拟化平台或者轻量级云管平台，线上线下协同私有云平台由于配置项目众多，各组件间依赖关系复杂，难以做到理想的“一键升级”乃至自动化升级。

1、升级过程自动化程度较低，有大量的脚本需手动执行，与现网环境对比修改配置值等多个手动操作。

2、公有云线上配置修改，未同步到私有云版本，导致平台版本升级后出现不合预期的配置变更，产生难以定位的未知bug（某版本升级后，etcd监听端口从原端口调整为新端口，该变更未同步到专线交换机SDN控制器上的网络组件，导致虚拟机热迁移后从云桌面通过专线访问网络不通）。

3、由于私有云平台本地化部署，随着云平台使用演进，存在部分配置为了适应本地化使用做了相应变更优化，但是升级缺乏配套前置工具检查，无法感知本地化配置变更，出现升级后配置还原原现网配置导致部分功能不可用；私有云平台演进，特别是线上线下协同模式，配套前置工具检查非常重要，否则难以保障公有云版本演进下移到私有化部署平台，在升级过程中保障配置收敛和规避升级风险。

　五、运维自动化能力建设

私有云建设初期，需提供开放平台能力，包括但不限于以下5个方面：

1、预留多租户配额管理能力，可提供给业务团队做基础设施层的资源自主发放管理。

2、嵌入工单流程提供虚拟机/云盘/网络能力等资源自动化审批发放。

3、平台自动化健康巡检（包括所有物理节点、管控面虚拟机、管控面K8S集群相关的服务/进程/pod/关键配置等），定期生成巡检报告。

4、自动化容量统计，包含计算集群（x86海光/ARM鲲鹏）CPU/内存容量水位，存储集群容量水位。

5、多种虚拟化/云平台间，虚拟机跨平台底层克隆自动化。

私有云厂商线上/线下协同模式，往往由公有云提供租户侧完整的多语言SDK配套工具（文档、代码等）可供阅读下载使用，但是往往不提供运维侧SDK，而只提供API文档，为实现上面第3、4、5条描述的开放平台能力，经与厂商沟通提供封装运维侧API相关文档工具指导，通过Python代码建设实现了运维侧功能自动化。

特别注意：虽然公有云厂商往往宣称私有云SDK和公有云同源同构，但实际仍会有微小差异，尤其是在版本演进过程中，可能会存在部分接口/方法/参数变更，导致原自动化代码在平台升级后需进行一定的适配调整。

以封装运维侧API，采集集群/计算节点容量信息为例——

注意：采集容量信息为运维侧数据，需使用admin管理员账号的ak/sk做鉴权

通过自动化脚本，可获取到每个集群的集群类型（Type）、计算节点预留CPU、预留内存、CPU超分比、内存超分比、集群计算节点数量、云主机数量、集群可用CPU、总CPU、可用内存、总内存等资源池相关信息，为运维运营提供数据支撑。

输出部分字段示例：[{ ‘Id’: ‘General_Cluster_1’ , ‘Name’: ‘General_Cluster_1’, ‘Zone’: ‘XXX’ , ‘Type’: ‘X86_64’ , ‘HostReservedCPU’: , ‘HostReservedMemoryMB’: , ‘CpuRatio’: , ‘RamRatio’: , ‘HostsNum’: , ‘InstancesNum’: , ‘AvailableCPU’: , ‘TotalCPU’: , ‘AvailableMemMB’: , ‘TotalMemMB’: }]

　六、跨平台迁移

由于历史原因，在虚拟化、私有云建设过程中，积累了多种厂商基础设施平台，包括超融合、虚拟化、云平台等。

考虑到后续架构演进，需要避免和厂商绑定，在本次私有云平台建设过程中，我们也重点探索并进行了多平台间跨平台虚拟机底层克隆迁移能力的技术积累。

结合运维自动化能力建设，通过自动化脚本方式，将跨平台虚拟机底层克隆迁移的过程步骤完全流程自动化，无需人工干预，大大提升了跨平台虚拟机底层克隆效率，保障了某些难以重新部署服务虚拟机进行跨平台迁移的业务连续性。

自动化脚本实现动作简要说明如下：

1、由原虚拟化/云平台虚拟机ip地址获取到虚拟机实例id、CPU/内存规格，所有系统盘/数据盘大小和云盘（逻辑卷LUN）id。

2、所有系统盘/数据盘导出为指定目录的raw格式镜像文件，scp拷贝目标云平台存储节点。

3、调用python脚本（封装私有云SDK方法），自动创建目标云平台虚拟机（对齐原虚拟机CPU/内存规格，指定vpc/子网，创建相同数量/大小的系统盘、数据盘）。

4、目标虚拟机关机，通过命令导入原系统盘/数据盘.raw镜像文件覆盖目标虚拟机系统盘/数据盘，完成系统盘/数据盘克隆覆盖后，目标虚拟机开机。

经过以上4个步骤，完成虚拟机跨平台底层克隆迁移过程。

　　七、高可用故障演练

故障演练分为管控面（按组件：虚拟机/K8S pod/容器划分）、数据面（按节点类型划分）、网络设备（按设备类型划分）、典型场景 4个维度。

每个测试项分为：测试项目、测试时间、测试动作、功能说明、影响范围、验证结果、优化建议、观测手段、应急预案。

通过故障演练，重点得出：1. 故障影响面 2. 可观测手段 3. 应急预案

对于管控面所有重要虚拟机、服务均进行停止/重启测试动作，数据面按设备类型（计算节点、块存储节点、对象存储节点等）抽样进行停止/重启测试动作。

参考演练表格如下，可按照演练粒度从小到大逐步循序推进：

服务粒度

（点击图片可放大）

管控虚拟机粒度

（点击图片可放大）

物理主机粒度

（点击图片可放大）

通过应急演练，识别多个管控面组件/服务故障冗余度和影响范围，优化部分关键组件/服务副本数量增加故障冗余度，发现专线单链路故障影响云下/云上南北向网络访问等关键风险并推动解决，实现私有云平台级基础设施达成金融级功能高可靠、高可用要求，助力业务连续性保驾护航。

　　八、部分踩坑问题举例

Memblaze虚拟化磁盘性能差优化

Memblaze为信创服务器广泛使用的一款NVMe SSD高性能固态存储磁盘。

在私有云平台升级过程中，发现在管控节点上传解压升级包和容器镜像到仓库过程中，磁盘IO非常卡顿，甚至导致整个私有云平台管控面整体性能劣化，很多接口访问超时报错。

经过厂商多次定位，最终确认Memblaze磁盘需设置PCI 透传（PCI passthrough）功能，使管控虚拟机可以像使用直接附加到这个虚拟机上的设备一样使用主机设备。

以下场景不涉及：Memblaze作为本地盘，未使用虚拟化；Memblaze磁盘作为后端存储池使用，非虚拟化层调用。

对管控物理机执行reboot命令等待物理机启动后：使用virsh list —all查看所有虚拟机是否正常启动

尝试登陆管控物理机内的虚拟机，确认可以正常登陆

虚拟机热迁移系列优化

虚拟机热迁移是保障业务连续性的重要手段，主要分为虚拟机主机热迁移和后端存储热迁移，当宿主机宕机、存储链路故障等异常场景，均会考虑使用虚拟机热迁移进行业务连续性保障。

对于成熟虚拟化厂商（如VMware），通过内置多种故障策略，当感知到可能故障时自动进行虚拟机热迁移，保障故障无感知、业务高可靠，在金融行业得到广泛应用，已成为虚拟化、云平台刚需技术要求。

对于公有云服务提供商，高可靠保障方式存在差异，同时依赖强大的内部研发运维团队，往往对IaaS层面虚拟机热迁移无强制要求。

我行在私有云平台建设过程中，出现多次虚拟机热迁移问题，由此也同厂商联合进行虚拟机批量热迁移压力测试，经过多次定位优化，最终虚拟机热迁移达到可靠可用要求。

虚拟机热迁移后，容器镜像不可用

虚拟机热迁移后，虚拟机内容器镜像不可用，定位发现文件内容变化（镜像大小相同，md5值不一致）。

最终厂商定位为：虚拟机热迁移过程中存在内存脏数据（已优化解决）。

复现方法：进入虚拟机，执行以下fio 命令（特别注意 —verify=crc32c-intel 参数，进行落盘数据校验 ）。

命令运行回显的同时，进行虚拟机热迁移，fio报错中止，报错打印如下截图：

大规格虚拟机(内存大等于64G)热迁移优化

批量热迁移虚拟机，大规格虚拟机(内存大等于64G)热迁移缓慢，部分无法完成热迁移到新的宿主机。

厂商根据公有云运维经验，修改/etc/libvirt/qemu.conf配置文件的如下参数：

开启虚拟机迁移的multifd特性，并且设置线程数为10，加快虚拟机迁移进度。

验证修改libvirtd参数后，大规格虚拟机(内存大等于64G)热迁移符合预期。

热迁移完成时间明显缩短，未出现状态一直迁移中需人工介入情况。

OVS配置没有固化，主机重启后宿主机上虚拟机网络中断

云平台包含服务组件众多，在公有云平台私有化部署工程中，往往难以做到完全的标准化、自动化，需要人工手动导入配置、启动服务等，受限于交付时间紧张、现场工程师经验能力/工作习惯等不可控因素，存在引入潜在风险可能。

OVS（Open vSwitch）是业界广泛使用的一款开源软件交换机，国内主流云厂商往往在OVS基础上，在功能特性、转发性能、可靠性等方面进行自研增强，作为IaaS计算节点数据面网络转发组件。

经排查，存在计算节点路由条目配置有误（厂商回复部署阶段使用ip route命令添加的路由信息没有固化，默认从br-ex网桥的流量指向网关ip，但是主机重启后该路由条目丢失，出现宿主机上虚拟机无法通信问题）。

建议：在私有云平台交付部署完成后，联合厂商在业务上线前进行充分的故障演练、上下电业务测试等，拦截潜在风险问题。

　九、总结

信创私有云从平台部署、业务上线到升级演进（5个版本），历经1年半时间，当前已运行承载了开发测试环境的多套业务系统。除本文列举示例外，还历经多个问题场景，协同厂商共同推动问题优化解决。在项目建设过程中总结提炼多篇技术总结和过程文档，增强了运维人员信创硬件和云化能力储备，同时也认识到私有云线上/线下协同模式的潜在演进风险。希望本文能为同行提供参考，探索选择适合自身业务发展的信创建设路径。