简介一份面向信创虚拟化及云平台建设的完整解决方案演示文稿适合IT架构师、云计算运维及信创项目管理人员参考。内容从信创建设面临的挑战入手围绕国产芯片多技术路线、应用迁移难、性能弱等痛点提出基于虚拟化云计算屏蔽底层差异、统一管理存量与新建环境的整体思路随后给出服务器虚拟化、云管理平台、容器云平台及多云融合等多层次技术架构并对不同规模用户和建设等级进行分级规划。资源包内含1个pptx文件大小3.09MB目前已有981人学习。方案重点介绍了信创虚拟化选型要点、多芯片资源池管理、业务高可用、应用平滑迁移以及替代VMware等典型场景可帮助读者快速形成方案框架支撑技术选型、项目汇报和内部培训。1. 信创替代的第一道坎为什么先解决虚拟化信创项目推进时最容易被低估的不是芯片性能而是“多路线共存”带来的管理复杂度。一台鲲鹏920、一台海光3535、一台飞腾FT2000各自跑不同的操作系统和中间件如果还按物理机粒度去运维硬件差异会直接放大到应用层迁移一个业务往往要连底层一起换。虚拟化和云平台在这里的真正价值是把芯片差异屏蔽在IaaS层之下让上面跑的应用只面对统一的计算、存储、网络资源视图。这套方案覆盖的是从单集群虚拟化到多云管理平台的完整链路服务器虚拟化软件解决资源池化轻量云平台解决软件定义数据中心云管理平台解决异构资源统一调度。适合两种人看一是正在做信创迁移规划的技术负责人需要把“替代VMware”这件事拆成可执行的选型指标二是实际动手建集群的运维工程师关心HA、热迁移、性能损耗这些落地参数。下文围绕芯片适配、虚拟化选型、轻量云平台搭建、存量业务迁移四个层面展开遇到的关键参数和命令会直接给出来。2. 多芯片架构下的资源池设计先把芯片差异量化信创环境和x86机房最大的区别是机柜里可能同时存在ARM、MIPS、Alpha、x86四条指令集的服务器。把它们混在一套虚拟化平台里管理前提是先把芯片性能差异量化否则调度策略无从谈起。2.1 芯片性能基线用SPEC2006拉平对比口径方案中给出了一组典型的信创芯片单核性能参考数据这组数据是资源池划分的重要输入芯片型号架构SPEC2006单核主频GHz海光3535x86353.5鲲鹏920ARM28.62.6兆芯KX-6000x8622.63.0飞腾FT2000ARM19.12.4龙芯3A4000MIPS182.0兆芯KX-5000x8615.42.0申威421Alpha12.42.4飞腾FT1500AARM111.5龙芯3A3000MIPS10.61.5注意SPEC2006单核数据代表的是整数和浮点运算能力的综合分能直接反应用户业务在这个芯片上能拿到多少计算密度。实际规划时我一般会把芯片按性能分为三档第一档海光、鲲鹏920承载数据库、中间件等核心业务第二档兆芯KX-6000、飞腾FT2000承载常规Web应用第三档龙芯、申威承载办公类、非实时类业务。这样划分的意义在于虚拟化平台的DRS动态资源调度在跨芯片节点迁移时不会因性能差异导致业务体验断崖式下跌。2.2 同构优先、异构兜底的资源池策略跨芯片热迁移目前在技术上仍然受限ARM节点和x86节点间的vMotion类操作并不可靠。因此常见做法是先在相同芯片架构内建集群开启HA和DRS不同芯片的集群通过上层云管理平台统一纳管做的是“冷迁移”或“重建部署”而不是实时在线迁移。# 以鲲鹏920环境为例查看节点CPU拓扑确认NUMA节点分布 lscpu | grep -E NUMA node|Architecture|CPU\(s\) # 检查KVM内核模块是否支持嵌套虚拟化部分信创OS默认关闭 cat /sys/module/kvm_arm/parameters/nested这里第一段命令是看CPU的NUMA拓扑信创服务器大多是2路或4路配置虚拟化层在分配vCPU时要尽量让同一虚拟机的vCPU落在同一个NUMA节点内避免跨节点内存访问带来的性能损耗。第二段是检查嵌套虚拟化开关如果要在信创虚拟化平台里再跑虚拟机做测试这个参数需要开启如果只是承载生产业务保持关闭反而更安全可以减少攻击面。2.3 内存和IO的隔离参数多芯片混布环境下内存带宽和IO中断的争抢比x86机房更明显。创建虚拟机的QEMU参数里以下几项值得重点调优# 虚拟机绑核示例将4个vCPU绑定到物理CPU 8-11关闭自动迁移 qemu-system-aarch64 \ -name kp920-vm01 \ -smp 4,threads1,sockets4 \ -numa node,cpus0-3,memdevmem0 \ -object memory-backend-file,idmem0,size32G,mem-path/dev/hugepages,shareon \ -device virtio-blk-pci,drivesystem_disk \ -overcommit mem-lockon \ -no-reboot主要参数说明-smp指定vCPU拓扑信创环境建议socket数等于物理芯片数避免跨片调度mem-path/dev/hugepages启用大页内存ARM芯片上TLB miss开销比x86更高2MB大页能显著降低虚拟内存转换开销shareon允许内存共享是开启热迁移的前提。mem-lockon锁定内存页防止被交换到磁盘这在混合负载场景下能减少延迟抖动。信创芯片的虚拟化性能损耗通常会比x86高3到5个百分点这些参数就是用来把那几个点找补回来的。3. 替代VMware vSphere国产虚拟化平台的选型与落地“替代VMware”是信创虚拟化项目里出现频率最高的需求但替代不是换个Hypervisor那么简单。vSphere的成熟体现在HA、DRS、vMotion这些机制的细节里国产虚拟化平台要接得住原有运维习惯才谈得上平滑替换。3.1 选型时的六项功能验证清单拿方案里提到的CNware KV这类企业级虚拟化平台来说选型不能只看兼容性列表要按生产标准做实测。我通常会把验证拆成六个维度功能完备性对照vSphere常见功能清单逐个打勾重点包括HA高可用、DRS动态资源调度、DPM分布式电源管理、虚拟机热迁移、存储热迁移、模板克隆、快照回滚。虚拟化性能同规格虚拟机对比物理机性能SPEC CPU和fio分别测CPU和磁盘损耗超过8%要追问原因。应用性能选定核心业务场景用LoadRunner或JMeter跑压测记录TPS和响应时间百分位P99。稳定性物理资源均分为若干虚拟机满负载运行fio、LTP等压测工具至少持续一周观察是否有内存泄漏、CPU steal time异常。高可用主动kill虚拟机进程、拔网线、重启物理节点验证HA切换时间和数据一致性。兼容性操作系统要覆盖统信UOS、银河麒麟、中标麒麟、中科方德数据库覆盖达梦、人大金仓、神舟通用中间件覆盖东方通、金蝶天燕、宝兰德。下面给出一个适合在选型阶段执行的fio稳定性压测命令跑满7天并记录延迟分布# 4K随机写队列深度32直接I/O模式持续168小时 fio --namestability_test \ --filename/dev/sdb \ --rwrandwrite \ --bs4k \ --iodepth32 \ --ioenginelibaio \ --direct1 \ --size20G \ --runtime604800 \ --time_based \ --group_reporting \ --output./fio_4k_randwrite_7d.json \ --output-formatjson # 查看CPU steal time判断虚拟化层是否过度调度 mpstat -P ALL 5 | grep -i steal该命令作用是用4K随机写模拟数据库日志文件的写入特征--runtime604800是7天的秒数--time_based确保到时间才停止而不是写完size就结束。steal time如果长期超过5%说明宿主机CPU超分比过高虚拟机在争抢物理核需要降低超分比或迁移部分负载。信创芯片核数多但单核性能弱超分比一般建议控制在2:1以内相比x86环境的3:1或4:1要保守。3.2 迁移路径差异x86存量与信创新建方案里明确区分了两类场景这个区分直接决定迁移方法x86环境存量虚拟化应用无需改造通过v2v工具转换虚拟机磁盘格式后迁入新平台原VMware的虚拟机网卡、磁盘控制器驱动通常可以无缝兼容。信创环境新建应用需要重新编译因为CPU指令集不同二进制无法直接复用。这个场景下的“迁移”实际上是“在新架构上重新部署”。v2v转换常见做法是用qemu-img转换磁盘格式# 将VMware的vmdk转换为qcow2注意目标平台要求的格式 qemu-img convert -p -f vmdk -O qcow2 \ -o compat1.1,cluster_size64K \ /old/vmware/vm01.vmdk \ /new/cnware/vm01.qcow2 # 转换完成后校验 qemu-img check /new/cnware/vm01.qcow2 qemu-img info /new/cnware/vm01.qcow2-p参数显示转换进度大磁盘转换耗时较长没有进度条容易误判为卡死cluster_size64K对数据库类随机读写更友好默认的64K其实已经是较均衡的选择但如果虚拟机主要是日志类顺序写可以改成1M减少元数据开销。转换后务必执行qemu-img check检查快照链一致性vmdk转qcow2最常见的坑是源磁盘有快照未合并转换出来的文件会出现逻辑损坏启动时连不上根文件系统。3.3 HA与DRS的配置参数CNware这类平台的HA机制核心是“管理面高可用数据面故障转移”和vSphere的FDM原理类似但实现细节不同。集群配置时几个关键参数建议如下# 以命令行方式创建高可用集群常见CLI示例参数需按实际版本调整 cnware-cluster create --name prod-cluster \ --ha-enabled \ --ha-heartbeat-interval 1000 \ --ha-failover-level 2 \ --drs-enabled \ --drs-mode fully_automated \ --drs-threshold 3 \ --dpm-enabled \ --dpm-threshold 40ha-heartbeat-interval是心跳间隔单位毫秒默认1000即可过低容易误判主机故障导致虚拟机反复重启ha-failover-level为允许同时故障的物理节点数生产环境至少2意味着集群中有任意两台物理机宕机虚拟机仍能在剩余宿主机上拉起。drs-threshold是迁移激进程度范围1-5信创环境建议设为3太激进会频繁触发跨节点迁移消耗大量网络带宽dpm-threshold 40表示物理机平均负载低于40%时自动休眠部分宿主机这个功能在信创机房初期业务量不大时很实用能省电降噪。3.4 虚拟机高可用的故障演练HA配好之后必须做故障演练不能等到生产宕机才验证。最常见的演练方式是模拟宿主机内核崩溃# 在宿主机上触发内核panic仅限测试环境 echo c /proc/sysrq-trigger # 或强制关闭某一台宿主机的网络测试网络分区场景下的HA行为 nmcli device disconnect enp125s0f0第一种方式模拟的是宿主机彻底宕机触发HA主备切换第二种方式模拟的是网络隔离这个场景更容易暴露问题因为虚拟化平台可能把“网络不通”误判为“主机离线”导致同一虚拟机在两侧同时启动出现脑裂。信创平台的集群锁机制如果依赖存储锁网络隔离时不一定会触发仲裁需要确认集群的fencing策略是否配置了存储心跳或管理网隔离检测。4. 轻量级云平台从三台服务器起步的软件定义数据中心对于100台服务器以下的中小型规模用户直接上OpenStack架构的管理平台往往过重——控制节点、计算节点、网络节点分角色部署后期维护成本比虚拟化本身还高。方案里提到的WinStack这类轻量级云平台走的是另一条路非OpenStack架构两到三台服务器起步计算、存储、网络组件一体化交付。4.1 三节点架构的角色分配轻量云平台通常采用“三节点全功能”的部署模式即每个节点同时承担计算、存储、控制角色通过分布式一致性协议保证数据冗余。这种架构下三个节点实际是三个副本节点角色部署组件资源建议Node 1控制计算存储管理面服务、SDN控制器、分布式存储OSD管理面至少4C8G其余给业务Node 2计算存储计算服务、分布式存储OSD全部给业务Node 3计算存储计算服务、分布式存储OSD全部给业务管理面组件比如SDN控制器、数据库、消息队列做三副本部署任一节点宕机不影响管理面可用性。存储采用分布式副本策略3副本容忍2个副本同时故障。注意副本数与节点数的关系3节点3副本的可用性其实等价于2副本仲裁因为任意2个节点故障后剩余1个节点无法形成多数派数据面会进入只读状态。生产环境想容忍2节点同时宕机至少需要5节点。4.2 部署参数与网络规划轻量云平台部署时网络规划是最容易返工的部分参考方案中的网络调优能力建议按以下参数表落地# 存储网络VXLAN或VLAN隔离MTU开巨型帧 ip link set dev bond1 mtu 9000 # 业务网络配置网卡多队列提升多核处理能力 ethtool -L ens3 combined 8 # 网卡聚合模式信创ARM芯片网卡驱动要确认支持 nmcli connection modify bond0 mode active-backupmtu 9000是给存储网络用的分布式存储的副本流量占带宽很高巨型帧能减少CPU中断次数但前提是交换机端口和所有存储节点都配了9000同时生效否则出现分片反而更慢。ethtool -L配置网卡多队列让不同vCPU处理不同的网络中断这个对ARM芯片尤其重要因为ARM核的网卡中断处理能力弱多队列能让中断均摊到多个核。网卡聚合模式建议active-backup而不是LACP因为轻量云平台的管理交换机往往不支持动态LACP协商配了反而链路起不来。4.3 存储策略本地盘分布式副本替代集中式存储信创场景下集中式存储如传统SAN成本高且生态适配慢轻量云平台的常见做法是用服务器本地盘构建分布式存储也就是超融合思路。副本策略的取舍如下2副本可用容量是原始容量的一半适合非核心业务容忍单盘故障。3副本可用容量是原始容量的三分之一适合核心数据库容忍单节点故障。纠删码EC 42可用容量约66%CPU开销高适合大文件、备份类数据。虚拟机磁盘性能调优时重点看两个参数——缓存策略和IO队列# Libvirt磁盘配置示例避免QEMU层缓存导致的性能波动 driver nameqemu typeraw cachenone ionative/ iotune total_bytes_sec104857600/total_bytes_sec total_iops_sec5000/total_iops_sec /iotunecachenone让虚拟机数据直接落盘绕过QEMU页缓存避免双重缓存造成的数据不一致风险ionative启用Linux原生AIO配合libaio可以降低IO延迟。iotune限制单盘吞吐100MB/s、5000 IOPS防止某个虚机打满磁盘影响邻居这在分布式存储环境下尤其重要。日志型应用数据库建议数据盘和控制盘分离控制盘用raid1或日志策略数据盘用副本策略混在一个存储池里会导致日志写入延迟被数据盘的大块写拖累。4.4 容器云平台作为敏态补充信创环境里存量应用是稳态业务用虚拟化平台承载新型微服务应用是敏态业务更适合容器云平台。轻量云平台通常提供内置的Kubernetes发行版与虚拟机共用底层IaaS资源。规划建议是把容器集群分两个资源池一个是纯容器的裸金属池性能最好但隔离性弱另一个是虚拟机里的嵌套容器池隔离性强但性能有损耗。信创环境普遍建议后者因为容器镜像的CPU指令集依赖在上层已经通过虚拟机屏蔽异构芯片的差异不会传导到容器层。5. 存量业务迁移上云的三个实操细节信创迁移的成败不取决于新平台本身而取决于迁移过程中业务中断时间的控制。按方案中的经验迁移要尽量“不改变部署方式、不改变运维方式”让业务侧无感切换。实际操作中三个细节值得特别关注。5.1 迁移前的应用画像不是所有应用都适合直接迁移。先做一轮应用扫描分类决定迁移策略。需要采集的数据包括CPU使用率峰值、内存占用、磁盘IOPS和吞吐、网络流量特征、对外提供的端口和服务、启停脚本的依赖关系。采集命令在源x86虚拟机上执行# 采集7天的资源使用峰值保存到文件用于迁移后对比 sar -u -r -b -n DEV 10 60480 /tmp/migration_baseline_7d.txt-u看CPU-r看内存-b看磁盘IO-n DEV看网络流量每10秒采样一次持续7天共60480个采样点。这份基线的价值在于迁移完成后做同样周期的对比测试判断新平台是否存在性能回退。迁移前还应该在源虚拟机上记录应用配置文件清单/etc下的改动、tomcat/nginx的server.xml和conf.d避免新环境重新部署时遗漏配置项导致功能异常。5.2 在线迁移与离线迁移的选择信创替代场景下在线迁移业务不中断和离线迁移业务短时中断技术路线完全不同选择依据是业务可接受的停机窗口# 离线迁移停机后做全量拷贝窗口大约等于数据量的传输时间 rsync -avP --delete /var/lib/libvirt/images/app01/ \ roottarget-cnware:/data/images/app01/ # 在线迁移先预拷贝内存脏页最后短暂切换x86同构迁移场景 virsh migrate --live --p2p --tls \ --desturi qemutls://target-cnware/system \ app01离线迁移的rsync命令里-a保留权限和属主因为应用容器里可能有专用系统账户--delete确保增量同步时目标端清理掉源端已删除的文件这个命令适合在停机窗口内重复执行两到三次让增量越来越小最后一次在窗口开始前完成把业务切换时间压缩到分钟级。在线迁移的--p2p跳过中转主机两台宿主机直连减少一跳延迟--tls加密传输避免内存数据在网络上明文暴露。信创异构环境x86迁到ARM目前不支持--live只能走“离线迁移重新编译”的路子。5.3 迁移后的验收基线迁移完成后不能被“能启动、能访问”掩盖数据一致性问题需要建立最小验收基线一是数据一致性校验对数据库业务做行数对比和checksum抽样二是性能对比用迁移前记录的baseline做同样压测TPS、P99时延变化不超过10%视为合格三是高可用验证在新平台上主动触发一次故障切换确认业务RPO/RTO符合承诺。这里推荐一个小技巧在迁移后第二周做一次“反向验证”——把新平台的备份恢复到测试环境确保备份链路本身可用这样万一新环境出问题还能回滚。最后再强调一个容易被忽略的点信创虚拟化平台的管理组件全部上容器或微服务化之后管理面的资源占用只有x86同类的三分之一但仍然要单独监控管理节点自身的CPU和内存。管理面一旦假死整个集群的调度、HA、监控全部失效业务虚机即使存活也处于“无人看护”状态。定时巡检中增加一条管理面健康检查比任何高可用配置都更能兜住底。本文还有配套的精品资源点击获取
信创虚拟化落地指南：多芯片适配与VMware替代实践
简介一份面向信创虚拟化及云平台建设的完整解决方案演示文稿适合IT架构师、云计算运维及信创项目管理人员参考。内容从信创建设面临的挑战入手围绕国产芯片多技术路线、应用迁移难、性能弱等痛点提出基于虚拟化云计算屏蔽底层差异、统一管理存量与新建环境的整体思路随后给出服务器虚拟化、云管理平台、容器云平台及多云融合等多层次技术架构并对不同规模用户和建设等级进行分级规划。资源包内含1个pptx文件大小3.09MB目前已有981人学习。方案重点介绍了信创虚拟化选型要点、多芯片资源池管理、业务高可用、应用平滑迁移以及替代VMware等典型场景可帮助读者快速形成方案框架支撑技术选型、项目汇报和内部培训。1. 信创替代的第一道坎为什么先解决虚拟化信创项目推进时最容易被低估的不是芯片性能而是“多路线共存”带来的管理复杂度。一台鲲鹏920、一台海光3535、一台飞腾FT2000各自跑不同的操作系统和中间件如果还按物理机粒度去运维硬件差异会直接放大到应用层迁移一个业务往往要连底层一起换。虚拟化和云平台在这里的真正价值是把芯片差异屏蔽在IaaS层之下让上面跑的应用只面对统一的计算、存储、网络资源视图。这套方案覆盖的是从单集群虚拟化到多云管理平台的完整链路服务器虚拟化软件解决资源池化轻量云平台解决软件定义数据中心云管理平台解决异构资源统一调度。适合两种人看一是正在做信创迁移规划的技术负责人需要把“替代VMware”这件事拆成可执行的选型指标二是实际动手建集群的运维工程师关心HA、热迁移、性能损耗这些落地参数。下文围绕芯片适配、虚拟化选型、轻量云平台搭建、存量业务迁移四个层面展开遇到的关键参数和命令会直接给出来。2. 多芯片架构下的资源池设计先把芯片差异量化信创环境和x86机房最大的区别是机柜里可能同时存在ARM、MIPS、Alpha、x86四条指令集的服务器。把它们混在一套虚拟化平台里管理前提是先把芯片性能差异量化否则调度策略无从谈起。2.1 芯片性能基线用SPEC2006拉平对比口径方案中给出了一组典型的信创芯片单核性能参考数据这组数据是资源池划分的重要输入芯片型号架构SPEC2006单核主频GHz海光3535x86353.5鲲鹏920ARM28.62.6兆芯KX-6000x8622.63.0飞腾FT2000ARM19.12.4龙芯3A4000MIPS182.0兆芯KX-5000x8615.42.0申威421Alpha12.42.4飞腾FT1500AARM111.5龙芯3A3000MIPS10.61.5注意SPEC2006单核数据代表的是整数和浮点运算能力的综合分能直接反应用户业务在这个芯片上能拿到多少计算密度。实际规划时我一般会把芯片按性能分为三档第一档海光、鲲鹏920承载数据库、中间件等核心业务第二档兆芯KX-6000、飞腾FT2000承载常规Web应用第三档龙芯、申威承载办公类、非实时类业务。这样划分的意义在于虚拟化平台的DRS动态资源调度在跨芯片节点迁移时不会因性能差异导致业务体验断崖式下跌。2.2 同构优先、异构兜底的资源池策略跨芯片热迁移目前在技术上仍然受限ARM节点和x86节点间的vMotion类操作并不可靠。因此常见做法是先在相同芯片架构内建集群开启HA和DRS不同芯片的集群通过上层云管理平台统一纳管做的是“冷迁移”或“重建部署”而不是实时在线迁移。# 以鲲鹏920环境为例查看节点CPU拓扑确认NUMA节点分布 lscpu | grep -E NUMA node|Architecture|CPU\(s\) # 检查KVM内核模块是否支持嵌套虚拟化部分信创OS默认关闭 cat /sys/module/kvm_arm/parameters/nested这里第一段命令是看CPU的NUMA拓扑信创服务器大多是2路或4路配置虚拟化层在分配vCPU时要尽量让同一虚拟机的vCPU落在同一个NUMA节点内避免跨节点内存访问带来的性能损耗。第二段是检查嵌套虚拟化开关如果要在信创虚拟化平台里再跑虚拟机做测试这个参数需要开启如果只是承载生产业务保持关闭反而更安全可以减少攻击面。2.3 内存和IO的隔离参数多芯片混布环境下内存带宽和IO中断的争抢比x86机房更明显。创建虚拟机的QEMU参数里以下几项值得重点调优# 虚拟机绑核示例将4个vCPU绑定到物理CPU 8-11关闭自动迁移 qemu-system-aarch64 \ -name kp920-vm01 \ -smp 4,threads1,sockets4 \ -numa node,cpus0-3,memdevmem0 \ -object memory-backend-file,idmem0,size32G,mem-path/dev/hugepages,shareon \ -device virtio-blk-pci,drivesystem_disk \ -overcommit mem-lockon \ -no-reboot主要参数说明-smp指定vCPU拓扑信创环境建议socket数等于物理芯片数避免跨片调度mem-path/dev/hugepages启用大页内存ARM芯片上TLB miss开销比x86更高2MB大页能显著降低虚拟内存转换开销shareon允许内存共享是开启热迁移的前提。mem-lockon锁定内存页防止被交换到磁盘这在混合负载场景下能减少延迟抖动。信创芯片的虚拟化性能损耗通常会比x86高3到5个百分点这些参数就是用来把那几个点找补回来的。3. 替代VMware vSphere国产虚拟化平台的选型与落地“替代VMware”是信创虚拟化项目里出现频率最高的需求但替代不是换个Hypervisor那么简单。vSphere的成熟体现在HA、DRS、vMotion这些机制的细节里国产虚拟化平台要接得住原有运维习惯才谈得上平滑替换。3.1 选型时的六项功能验证清单拿方案里提到的CNware KV这类企业级虚拟化平台来说选型不能只看兼容性列表要按生产标准做实测。我通常会把验证拆成六个维度功能完备性对照vSphere常见功能清单逐个打勾重点包括HA高可用、DRS动态资源调度、DPM分布式电源管理、虚拟机热迁移、存储热迁移、模板克隆、快照回滚。虚拟化性能同规格虚拟机对比物理机性能SPEC CPU和fio分别测CPU和磁盘损耗超过8%要追问原因。应用性能选定核心业务场景用LoadRunner或JMeter跑压测记录TPS和响应时间百分位P99。稳定性物理资源均分为若干虚拟机满负载运行fio、LTP等压测工具至少持续一周观察是否有内存泄漏、CPU steal time异常。高可用主动kill虚拟机进程、拔网线、重启物理节点验证HA切换时间和数据一致性。兼容性操作系统要覆盖统信UOS、银河麒麟、中标麒麟、中科方德数据库覆盖达梦、人大金仓、神舟通用中间件覆盖东方通、金蝶天燕、宝兰德。下面给出一个适合在选型阶段执行的fio稳定性压测命令跑满7天并记录延迟分布# 4K随机写队列深度32直接I/O模式持续168小时 fio --namestability_test \ --filename/dev/sdb \ --rwrandwrite \ --bs4k \ --iodepth32 \ --ioenginelibaio \ --direct1 \ --size20G \ --runtime604800 \ --time_based \ --group_reporting \ --output./fio_4k_randwrite_7d.json \ --output-formatjson # 查看CPU steal time判断虚拟化层是否过度调度 mpstat -P ALL 5 | grep -i steal该命令作用是用4K随机写模拟数据库日志文件的写入特征--runtime604800是7天的秒数--time_based确保到时间才停止而不是写完size就结束。steal time如果长期超过5%说明宿主机CPU超分比过高虚拟机在争抢物理核需要降低超分比或迁移部分负载。信创芯片核数多但单核性能弱超分比一般建议控制在2:1以内相比x86环境的3:1或4:1要保守。3.2 迁移路径差异x86存量与信创新建方案里明确区分了两类场景这个区分直接决定迁移方法x86环境存量虚拟化应用无需改造通过v2v工具转换虚拟机磁盘格式后迁入新平台原VMware的虚拟机网卡、磁盘控制器驱动通常可以无缝兼容。信创环境新建应用需要重新编译因为CPU指令集不同二进制无法直接复用。这个场景下的“迁移”实际上是“在新架构上重新部署”。v2v转换常见做法是用qemu-img转换磁盘格式# 将VMware的vmdk转换为qcow2注意目标平台要求的格式 qemu-img convert -p -f vmdk -O qcow2 \ -o compat1.1,cluster_size64K \ /old/vmware/vm01.vmdk \ /new/cnware/vm01.qcow2 # 转换完成后校验 qemu-img check /new/cnware/vm01.qcow2 qemu-img info /new/cnware/vm01.qcow2-p参数显示转换进度大磁盘转换耗时较长没有进度条容易误判为卡死cluster_size64K对数据库类随机读写更友好默认的64K其实已经是较均衡的选择但如果虚拟机主要是日志类顺序写可以改成1M减少元数据开销。转换后务必执行qemu-img check检查快照链一致性vmdk转qcow2最常见的坑是源磁盘有快照未合并转换出来的文件会出现逻辑损坏启动时连不上根文件系统。3.3 HA与DRS的配置参数CNware这类平台的HA机制核心是“管理面高可用数据面故障转移”和vSphere的FDM原理类似但实现细节不同。集群配置时几个关键参数建议如下# 以命令行方式创建高可用集群常见CLI示例参数需按实际版本调整 cnware-cluster create --name prod-cluster \ --ha-enabled \ --ha-heartbeat-interval 1000 \ --ha-failover-level 2 \ --drs-enabled \ --drs-mode fully_automated \ --drs-threshold 3 \ --dpm-enabled \ --dpm-threshold 40ha-heartbeat-interval是心跳间隔单位毫秒默认1000即可过低容易误判主机故障导致虚拟机反复重启ha-failover-level为允许同时故障的物理节点数生产环境至少2意味着集群中有任意两台物理机宕机虚拟机仍能在剩余宿主机上拉起。drs-threshold是迁移激进程度范围1-5信创环境建议设为3太激进会频繁触发跨节点迁移消耗大量网络带宽dpm-threshold 40表示物理机平均负载低于40%时自动休眠部分宿主机这个功能在信创机房初期业务量不大时很实用能省电降噪。3.4 虚拟机高可用的故障演练HA配好之后必须做故障演练不能等到生产宕机才验证。最常见的演练方式是模拟宿主机内核崩溃# 在宿主机上触发内核panic仅限测试环境 echo c /proc/sysrq-trigger # 或强制关闭某一台宿主机的网络测试网络分区场景下的HA行为 nmcli device disconnect enp125s0f0第一种方式模拟的是宿主机彻底宕机触发HA主备切换第二种方式模拟的是网络隔离这个场景更容易暴露问题因为虚拟化平台可能把“网络不通”误判为“主机离线”导致同一虚拟机在两侧同时启动出现脑裂。信创平台的集群锁机制如果依赖存储锁网络隔离时不一定会触发仲裁需要确认集群的fencing策略是否配置了存储心跳或管理网隔离检测。4. 轻量级云平台从三台服务器起步的软件定义数据中心对于100台服务器以下的中小型规模用户直接上OpenStack架构的管理平台往往过重——控制节点、计算节点、网络节点分角色部署后期维护成本比虚拟化本身还高。方案里提到的WinStack这类轻量级云平台走的是另一条路非OpenStack架构两到三台服务器起步计算、存储、网络组件一体化交付。4.1 三节点架构的角色分配轻量云平台通常采用“三节点全功能”的部署模式即每个节点同时承担计算、存储、控制角色通过分布式一致性协议保证数据冗余。这种架构下三个节点实际是三个副本节点角色部署组件资源建议Node 1控制计算存储管理面服务、SDN控制器、分布式存储OSD管理面至少4C8G其余给业务Node 2计算存储计算服务、分布式存储OSD全部给业务Node 3计算存储计算服务、分布式存储OSD全部给业务管理面组件比如SDN控制器、数据库、消息队列做三副本部署任一节点宕机不影响管理面可用性。存储采用分布式副本策略3副本容忍2个副本同时故障。注意副本数与节点数的关系3节点3副本的可用性其实等价于2副本仲裁因为任意2个节点故障后剩余1个节点无法形成多数派数据面会进入只读状态。生产环境想容忍2节点同时宕机至少需要5节点。4.2 部署参数与网络规划轻量云平台部署时网络规划是最容易返工的部分参考方案中的网络调优能力建议按以下参数表落地# 存储网络VXLAN或VLAN隔离MTU开巨型帧 ip link set dev bond1 mtu 9000 # 业务网络配置网卡多队列提升多核处理能力 ethtool -L ens3 combined 8 # 网卡聚合模式信创ARM芯片网卡驱动要确认支持 nmcli connection modify bond0 mode active-backupmtu 9000是给存储网络用的分布式存储的副本流量占带宽很高巨型帧能减少CPU中断次数但前提是交换机端口和所有存储节点都配了9000同时生效否则出现分片反而更慢。ethtool -L配置网卡多队列让不同vCPU处理不同的网络中断这个对ARM芯片尤其重要因为ARM核的网卡中断处理能力弱多队列能让中断均摊到多个核。网卡聚合模式建议active-backup而不是LACP因为轻量云平台的管理交换机往往不支持动态LACP协商配了反而链路起不来。4.3 存储策略本地盘分布式副本替代集中式存储信创场景下集中式存储如传统SAN成本高且生态适配慢轻量云平台的常见做法是用服务器本地盘构建分布式存储也就是超融合思路。副本策略的取舍如下2副本可用容量是原始容量的一半适合非核心业务容忍单盘故障。3副本可用容量是原始容量的三分之一适合核心数据库容忍单节点故障。纠删码EC 42可用容量约66%CPU开销高适合大文件、备份类数据。虚拟机磁盘性能调优时重点看两个参数——缓存策略和IO队列# Libvirt磁盘配置示例避免QEMU层缓存导致的性能波动 driver nameqemu typeraw cachenone ionative/ iotune total_bytes_sec104857600/total_bytes_sec total_iops_sec5000/total_iops_sec /iotunecachenone让虚拟机数据直接落盘绕过QEMU页缓存避免双重缓存造成的数据不一致风险ionative启用Linux原生AIO配合libaio可以降低IO延迟。iotune限制单盘吞吐100MB/s、5000 IOPS防止某个虚机打满磁盘影响邻居这在分布式存储环境下尤其重要。日志型应用数据库建议数据盘和控制盘分离控制盘用raid1或日志策略数据盘用副本策略混在一个存储池里会导致日志写入延迟被数据盘的大块写拖累。4.4 容器云平台作为敏态补充信创环境里存量应用是稳态业务用虚拟化平台承载新型微服务应用是敏态业务更适合容器云平台。轻量云平台通常提供内置的Kubernetes发行版与虚拟机共用底层IaaS资源。规划建议是把容器集群分两个资源池一个是纯容器的裸金属池性能最好但隔离性弱另一个是虚拟机里的嵌套容器池隔离性强但性能有损耗。信创环境普遍建议后者因为容器镜像的CPU指令集依赖在上层已经通过虚拟机屏蔽异构芯片的差异不会传导到容器层。5. 存量业务迁移上云的三个实操细节信创迁移的成败不取决于新平台本身而取决于迁移过程中业务中断时间的控制。按方案中的经验迁移要尽量“不改变部署方式、不改变运维方式”让业务侧无感切换。实际操作中三个细节值得特别关注。5.1 迁移前的应用画像不是所有应用都适合直接迁移。先做一轮应用扫描分类决定迁移策略。需要采集的数据包括CPU使用率峰值、内存占用、磁盘IOPS和吞吐、网络流量特征、对外提供的端口和服务、启停脚本的依赖关系。采集命令在源x86虚拟机上执行# 采集7天的资源使用峰值保存到文件用于迁移后对比 sar -u -r -b -n DEV 10 60480 /tmp/migration_baseline_7d.txt-u看CPU-r看内存-b看磁盘IO-n DEV看网络流量每10秒采样一次持续7天共60480个采样点。这份基线的价值在于迁移完成后做同样周期的对比测试判断新平台是否存在性能回退。迁移前还应该在源虚拟机上记录应用配置文件清单/etc下的改动、tomcat/nginx的server.xml和conf.d避免新环境重新部署时遗漏配置项导致功能异常。5.2 在线迁移与离线迁移的选择信创替代场景下在线迁移业务不中断和离线迁移业务短时中断技术路线完全不同选择依据是业务可接受的停机窗口# 离线迁移停机后做全量拷贝窗口大约等于数据量的传输时间 rsync -avP --delete /var/lib/libvirt/images/app01/ \ roottarget-cnware:/data/images/app01/ # 在线迁移先预拷贝内存脏页最后短暂切换x86同构迁移场景 virsh migrate --live --p2p --tls \ --desturi qemutls://target-cnware/system \ app01离线迁移的rsync命令里-a保留权限和属主因为应用容器里可能有专用系统账户--delete确保增量同步时目标端清理掉源端已删除的文件这个命令适合在停机窗口内重复执行两到三次让增量越来越小最后一次在窗口开始前完成把业务切换时间压缩到分钟级。在线迁移的--p2p跳过中转主机两台宿主机直连减少一跳延迟--tls加密传输避免内存数据在网络上明文暴露。信创异构环境x86迁到ARM目前不支持--live只能走“离线迁移重新编译”的路子。5.3 迁移后的验收基线迁移完成后不能被“能启动、能访问”掩盖数据一致性问题需要建立最小验收基线一是数据一致性校验对数据库业务做行数对比和checksum抽样二是性能对比用迁移前记录的baseline做同样压测TPS、P99时延变化不超过10%视为合格三是高可用验证在新平台上主动触发一次故障切换确认业务RPO/RTO符合承诺。这里推荐一个小技巧在迁移后第二周做一次“反向验证”——把新平台的备份恢复到测试环境确保备份链路本身可用这样万一新环境出问题还能回滚。最后再强调一个容易被忽略的点信创虚拟化平台的管理组件全部上容器或微服务化之后管理面的资源占用只有x86同类的三分之一但仍然要单独监控管理节点自身的CPU和内存。管理面一旦假死整个集群的调度、HA、监控全部失效业务虚机即使存活也处于“无人看护”状态。定时巡检中增加一条管理面健康检查比任何高可用配置都更能兜住底。本文还有配套的精品资源点击获取
