简介《信创云平台建设方案》是一份面向信创产业服务保障基地及政企单位的完整建设规划文档聚焦解决国内信息技术自主创新云平台在核心技术受制、业务环境不可控、安全能力不足及缺乏适配环境等方面的典型问题。文档以入驻基地、搭建信创云、现场适配功能截图展示为主线系统梳理了硬件设备选型、操作系统与数据库软件配置、中间件升级等改造内容并按章节展开项目改造意义、需求分析自主可控、网络/计算/存储资源池、云管理平台、云备份、运维运营及安全系统以及云平台基础设施区设计等关键模块。资源包共包含1个docx文档压缩包大小约29.58MB适合作为信创云平台建设项目的方案模板、申报材料参考或技术架构设计依据。这一方案已有1447人学习下载对于正在编制信创云规划或需要借鉴成熟目录结构的读者具有较好的参考价值。1. 信创云平台建设方案为什么多数项目卡在「选型」而不是技术手里拿到一份《信创云平台建设方案.docx》时很多人第一反应是先找架构图。但真正做过一轮信创云平台落地的人会告诉你难点根本不在 OpenStack 怎么装、K8s 怎么编排而在于你面对的是一个「技术能跑、生态不齐」的底座。信创云平台的核心矛盾是国产芯片、国产操作系统、国产数据库、国产中间件这些组件必须协同工作任何一环的版本对不上前面所有工作都白做。这篇文章不是泛泛谈信创政策而是从方案落地角度把信创云平台的组成、选型、部署、适配和验收讲透适合正在写方案、准备搭建环境或做信创替代的从业者。2. 信创云平台的组成与选型从芯片到虚拟化的四层对应关系2.1 信创云平台四层架构芯片、操作系统、虚拟化、云管信创云平台和我们平时说的私有云、开源云平台在架构上并没有本质区别核心差异在每一层可选的组件被限定在了一个相对封闭的生态里。我习惯把信创云平台拆成四层硬件芯片层、操作系统层、虚拟化层、云管编排层。这四层不是各自独立选型而是存在严格的兼容关系。硬件芯片层目前常见的是鲲鹏ARM 架构、飞腾ARM 架构、海光x86 兼容、龙芯MIPS/LoongArch、兆芯x86 兼容。这直接决定了你后面装什么系统镜像、用哪套编译好的软件包。操作系统层以麒麟、统信 UOS 为主也有部分项目用欧拉、Anolis 这类开源社区版。虚拟化层在信创环境里最常见的组合是 KVM OpenStack也有不少商业方案用自研的虚拟化引擎但底层 Hugs 基本都是 KVM 的变体。云管编排层则是 OpenStack、Kubernetes 或者商业云平台。这里最容易被忽略的是「芯片架构 — 操作系统 — 虚拟化软件包」三者的对应关系。比如在鲲鹏上装麒麟系统看起来没问题但 OpenStack 的 RPM 包如果编译目标是 x86_64直接装就会出现缺依赖或者指令集不对。所以选型第一步不是画架构图而是把每一层用到的软件包的架构支持情况列一张表。我给一个常见的对应表正好可以作为方案附录层主流可选注意事项芯片鲲鹏 920、飞腾 S2500、海光 C86ARM 与 x86 的软件包不能混用操作系统麒麟 V10、统信 UOS、欧拉 openEuler建议选与芯片厂商做过适配认证的版本虚拟化KVM、QEMU、Docker需要确认宿主机内核是否开启相关模块云管OpenStackTrain/Ussuri、K8s、ZStackOpenStack 组件多版本要和 OS 匹配2.2 开源路线与商业路线OpenStack、云平台与超融合的边界很多项目负责人会问「信创云平台到底是用开源 OpenStack 还是买商业云平台」这个问题没有标准答案但有一个很现实的判断标准团队里有没有能扛住 OpenStack 运维的人。OpenStack 的好处是开放、可控、没有授权费但坏处是组件多控制节点光核心服务就有 Nova、Neutron、Cinder、Glance、Keystone、Placement 六七个任何一个服务的配置出错都会导致整个云平台不可用。商业云平台比如 ZStack、云宏、深信服等在信创领域做得好的通常是对国产芯片和操作系统做了深度适配安装体验接近「一键部署」而且提供统一的管理界面和运维告警。但商业方案的授权费用不低并且存在绑定风险——你选了它的云平台后续加节点、升级版本可能都要跟着它走。还有一种路线是超融合把计算、存储、网络在软件层融合到一起。超融合适合中小规模的信创替代场景比如几十台物理机的私有云。它的优势是部署快、运维简单缺点是扩展性不如 OpenStack 那种解耦架构存储和计算绑死在一起后期扩容不灵活。我的建议是如果是百台以内物理机且运维团队不超过三人优先考虑商业云平台或超融合如果是要做规模化、多租户、开放性要求高的信创云平台比如要对接深度学习云平台或智能云平台调度 GPU那就老老实实选 OpenStack 这条路。2.3 选型检查表拿需求文档核对这 7 项写方案最怕的就是「什么都想要」最后交付时一地鸡毛。我一般会拿一份需求文档逐条核对下面 7 项全部满足再往下走芯片架构明确是 ARM 还是 x86有没有指定信创目录内的产品名单。很多项目明确要求使用目录内产品这个必须在选型初期就核对不然方案评审直接被否。虚拟化技术栈是否要求兼容现有 KVM 虚拟机是否要支持 GPU 直通。存储方案是分布式存储Ceph还是集中式存储是否需要快照和备份能力。网络方案是否要求 VXLAN 网络隔离有没有多租户需求。安全合规是否需要接入统一身份认证、审计日志留存 6 个月以上是否要求等保三级。迁移路径现有虚拟机、物理机上的业务如何迁到新平台是否能接受停机窗口。运维能力团队有没有 OpenStack 运维经验决策者愿意投入多少人力。这 7 项里第 5 项最容易翻车。很多人以为信创云平台只要装起来就行结果安全检查时被问「日志审计存在哪里」「虚拟机管理员的操作有没有记录」答不上来。所以选型阶段就要把安全管理组件纳入架构而不是事后补。3. 用 OpenStack 搭建最小信创云三节点最小集群的 5 个步骤3.1 最小环境规划控制、计算、存储怎么分配如果你拿到的是「OpenStack 云平台搭建」方向的方案最需要的是一个能跑通的最小集群。三节点是常见的做法一个控制节点、两个计算节点。控制节点跑 Keystone、Nova API、Neutron、Glance、Placement计算节点跑 Nova Compute 和 Open vSwitch。存储要么用控制节点的本地盘做 Glance 存储要么单独挂一个 Ceph 集群但最小环境不建议一开始就上 Ceph先把功能跑通再说。以鲲鹏 920 服务器为例我给一个参考配置节点角色配置系统node1控制节点16C / 32G / 系统盘 200G 数据盘 500G麒麟 V10 SP2 ARM64node2计算节点32C / 128G / 系统盘 200G 数据盘 1T麒麟 V10 SP2 ARM64node3计算节点32C / 128G / 系统盘 200G 数据盘 1T麒麟 V10 SP2 ARM64网络方面至少两张网卡一张管理网承载 API 和内部通信一张业务网承载虚拟机流量。如果用 VXLAN还要考虑隧道网段和 VLAN 的规划。这些要在安装前确定不然后面改起来会牵连一堆配置。3.2 在鲲鹏环境安装核心组件的命令序列下面给出一个最小化的安装步骤使用 OpenStack Ussuri 版本。注意这里每个命令都是在麒麟 V10 ARM64 环境下验证过的常见做法不同 OS 版本可能包名略有差异。# 1. 配置 yum 源麒麟 V10 需要使用 ARM64 对应的 repo cat /etc/yum.repos.d/local.repo EOF [local] namelocal baseurlhttp://mirror.example.com/kylin/arm64/v10/sp2/ enabled1 gpgcheck0 EOF yum clean all yum makecache # 2. 安装 OpenStack Ussuri 的 RPM 包 # 这里用 packstack 做快速部署比手动逐个装组件快得多 yum install -y openstack-packstack # 3. 生成应答文件然后按需修改 packstack --gen-answer-file/root/answers.txt # 4. 修改应答文件中的关键参数 sed -i s/CONFIG_NOVA_COMPUTE_HOSTS.*/CONFIG_NOVA_COMPUTE_HOSTSnode2,node3/ /root/answers.txt sed -i s/CONFIG_NETWORK_CIDR.*/CONFIG_NETWORK_CIDR192.168.10.0\/24/ /root/answers.txt sed -i s/CONFIG_NEUTRON_OVS_BRIDGE_IFACES.*/CONFIG_NEUTRON_OVS_BRIDGE_IFACESbr-ex:eth1/ /root/answers.txt # 5. 执行部署 packstack --answer-file/root/answers.txt逻辑说明这套命令先解决的是软件源问题信创环境最大的坑之一就是默认源里没有 ARM64 的依赖包。第二步和第三步用 packstack 的应答文件机制把安装参数集中在一个文件里方便审计和重复部署。第四步是重点需要把计算节点列表改成实际的节点主机名或 IP把 Neutron 的网桥映射到你的业务网卡上。参数说明里CONFIG_NETWORK_CIDR必须填管理网络的网段它是 Neutron 创建外部网络的默认参考。CONFIG_NEUTRON_OVS_BRIDGE_IFACES的格式是桥名:物理网卡名如果先填错后面创建出来的虚拟机无法被外部访问。CONFIG_NOVA_COMPUTE_HOSTS用逗号分隔多个计算节点packstack 会通过 SSH 自动把这些节点纳入集群。3.3 验证命令与参数说明部署完成后不要急着登录 dashboard先做三层验证。第一层验证控制节点服务状态第二层验证计算节点是否注册第三层验证网络。# 查看 OpenStack 服务列表确认所有服务都是 UP 状态 source /root/keystonerc_admin openstack service list openstack host list # 验证镜像服务上传一个测试镜像 openstack image create --file cirros-0.5.1-arm64-disk.img \ --disk-format qcow2 --container-format bare cirros-arm64 # 创建测试网络和虚拟机 openstack network create test-net openstack subnet create --network test-net \ --subnet-range 192.168.100.0/24 --dhcp test-subnet openstack server create --flavor m1.small --image cirros-arm64 \ --network test-net --key-name mykey test-vm openstack server list逻辑说明openstack host list输出的结果里如果 node2 和 node3 没有出现在计算节点列表中说明 Nova 到计算节点的 SSH 配置有问题或者计算节点上的 nova-compute 服务没有正常启动。Cirros 是一个轻量测试镜像专门用来验证云平台功能ARM64 版本要选对x86 版本在鲲鹏上跑不起来。openstack server create之后用openstack console url show test-vm拿到 VNC 地址通过浏览器打开可以看到虚拟机的启动日志。如果虚拟机启动失败大多时候是镜像架构不匹配少数情况是虚拟化引擎没有识别到硬件加速。用kvm-ok命令检查宿主机是否支持 KVM如果不支持需要去 BIOS 里开启虚拟化功能。4. 信创适配与安全管理从兼容性矩阵到等保合规的落地路径4.1 信创适配操作系统、数据库、中间件的兼容性矩阵信创云平台搭好之后真正烧时间的环节是业务适配。一个数据库可能是 MySQL一个中间件可能是 Tomcat一个消息队列可能是 RabbitMQ这些软件在信创环境里都有或大或小的兼容性问题。我见过最常见的翻车是应用在 x86 服务器上跑得好好的迁移到鲲鹏上就报Illegal Instruction原因是代码里编译了针对 x86 的指令集。所以适配工作的第一步是做一张兼容性矩阵按业务系统列清楚操作系统、数据库、中间件、JDK、应用框架每一项标注是否经过验证。实际项目中我一般会用表格来管理业务系统操作系统数据库中间件兼容状态OA 系统麒麟 V10达梦 8TongWeb已验证邮件系统统信 UOSopenGauss东方通需测试深度学习平台欧拉MySQL 8.0无GPU 驱动待适配这张表的价值在于它能提前暴露哪些组件需要做替换。比如某个系统强依赖 Oracle而信创要求用国产数据库那就得评估是改写 SQL 还是用兼容组件做平滑过渡。这里要特别提一下「信创适配及安全管理」这个词。很多项目把适配和安全放在一起是因为适配过程中引入的补丁、动态库、配置文件本身就是安全风险的来源。一个稳妥的做法是建立分层的适配验证先做单组件验证再做系统联调最后做安全扫描。跳步的结果往往是上线后查不出问题一遇到并发就崩。4.2 安全管理身份、网络、审计三件套以及信创安全工程师投标时会被追问的细节信创云平台的安全管理不是装一个防火墙那么简单。我在方案里一般会写三件套身份认证、网络隔离、操作审计。身份认证层OpenStack 默认的 Keystone 可以对接第三方 LDAP 或 CAS如果要满足企业内部统一认证建议直接对接统一身份平台避免每套系统都建一遍账号。网络隔离层Neutron 的 VXLAN 网络隔离是基本能力。但真正需要关注的是东西向流量的安全策略同一台物理机上的两个租户虚拟机它们之间的流量如果走 VXLAN 隧道到底在哪里做过滤常见做法是在虚拟机上装安全组但安全组的规则如果设得太粗后续很麻烦。更可靠的方式是在网络节点上部署分布式防火墙或者引入第三方安全虚拟化组件。操作审计层OpenStack 自带的审计日志只记录 API 调用不记录用户实际操作。如果项目要求等保合规需要把虚拟机的 VNC 连接操作、管理员执行的命令、网络规则的变更全部记录到独立的日志平台。这个在方案设计阶段就要预留接口不然后面补审计功能非常痛苦。信创安全工程师投标时评审专家最喜欢追问的细节有三个第一管理面的访问是如何控制的有没有双因子认证第二虚拟机镜像的完整性校验是怎么做的有没有哈希校验机制第三日志留存时间是多长是否支持导出。这三个问题如果答得含糊方案分通常会很低。所以我会在方案里写清楚管理面只允许通过跳板机访问镜像在上传时用 SHA256 校验日志系统保留至少 180 天并定期归档。4.3 信创替代企业微信应用迁移与消息集成的一个折中方案「信创替代企业微信」是很多项目方案里的一个隐藏需求。企业微信这类办公协同工具在信创环境里不可能直接照搬需要一套替代方案。最常见的是用私有化部署的即时通讯组件比如一些基于 OpenFire、Ejabberd 改造的方案。但这类组件和应用系统的集成度通常不够尤其是「扫码登录」「消息推送」这些能力往往需要二次开发。我在项目中给过一个折中方案保留现有企业微信作为客户侧入口但服务端迁移到信创云平台上通过企业微信开放接口把消息转发到信创环境里的业务系统。这样做的好处是前端体验不变后端逐步替换风险小。真正的信创替代是在逐步替换过程中把数据、用户、权限重新梳理一遍而不是一刀切更换。如果你要做全尺寸替代需要规划好三个接口身份认证接口OAuth2、消息推送接口Webhook、通讯录同步接口LDAP/SCIM。这三个接口能跑通大多数 OA、审批、通知类业务都能迁移。切记不要自己发明消息协议走标准接口才能保证兼容性。4.4 深度学习云平台与智能云平台多租户 GPU 调度信创云平台的另一类常见落地场景是深度学习云平台。很多高校和科研机构已经在信创环境里搭建 GPU 集群边缘设备是昇腾或者寒武纪。这类平台和传统云平台的最大区别在于 GPU 虚拟化和调度。OpenStack 社区很早就支持了 GPU 直通但直通意味着一个 GPU 只能给一台虚拟机用资源利用率很低。更好的方案是引入 Kubernetes GPU 共享调度。常见做法是在 OpenStack 的虚拟机之上再搭一层 K8s通过 device plugin 管理 GPU实现同一块 GPU 上跑多个推理任务。信创环境下的 K8s 部署有一点要特别注意镜像仓库和基础镜像必须全部换成 ARM64 或对应架构的版本否则 kubelet 启动时就会报exec format error。智能云平台这个方向也类似核心是把推理引擎、训练框架、数据标注工具统一纳管。如果项目方案里提到智能云平台建议明确你用的是基于 OpenStack 的虚拟化底座还是基于 K8s 的容器底座。两者各有优劣OpenStack 适合传统 VM 业务K8s 适合 AI 业务但 AI 业务里需要 GPU 直通时K8s 的调度灵活性明显更强。5. 信创云平台建设避坑指南5 条高频翻车记录5.1 现象安装 OpenStack 时提示 CPU 指令集不支持在飞腾或鲲鹏服务器上装 OpenStack偶尔会看到Illegal instruction或KVM: unknown symbol。原因是软件包在编译时启用了特定 CPU 指令集比如 AVX512而 ARM 平台上没有这个指令。更诡异的是同一个 RPM 包在 x86 的海光上没问题在 ARM 上就崩。原因是社区或厂商提供的二进制包并非严格针对你的目标芯片优化有些包是用镜像服务器的 CPU 特性编译的。解决方法是优先选用芯片厂商或操作系统厂商提供的适配包而不是从通用源里拉。如果必须从源码编译在CFLAGS里加上-mcpugeneric或-mtunegeneric来降低指令级要求。另一个检查点是内核版本ARM 平台建议内核不低于 4.19太老的内核对虚拟化特性支持不全。5.2 现象虚拟机网络不通但宿主机网络正常创建一个虚拟机后从外部 ping 不通但在宿主机上 ping 虚拟机的 IP 却通。这通常不是安全组的问题而是 Neutron 的网桥映射配错了。常见错误是在CONFIG_NEUTRON_OVS_BRIDGE_IFACES里只写了br-ex没有写物理网卡导致 br-ex 桥没有实际挂载到物理网络上。另一个原因是物理网卡被 NetworkManager 接管和 Open vSwitch 冲突。解决方法是先停用 NetworkManager 对业务网卡的管理再把网卡加入 OVS 桥。用ovs-vsctl show检查桥的状态如果Port eth1显示Interface eth1但状态是DOWN说明物理链路没有起来要检查网线或交换机配置。还有一个容易被忽略的细节VXLAN 需要 MTU 一致如果物理网络 MTU 是 1500而虚拟机接口设了 1450大包会丢但小包能通。5.3 现象存储性能与标称差距极大信创云平台经常配分布式存储但性能测试时 IOPS 只有标称的 30%。最常见的原因是存储网络和数据网络共用同一个千兆网卡Ceph 的副本同步流量和虚拟机的业务流量抢带宽。另一个原因是没有配置 NVMe 缓存层所有写操作都落到机械盘上。解决方法是给 Ceph 单独规划万兆网络并要求所有 OSD 节点使用 SSD/NVMe 作为日志盘。Ceph 的bluestore模式需要配置db设备如果没有单独分配性能会明显下降。调优时可以用ceph tell osd.* bench测单盘性能如果单盘 IOPS 足够那瓶颈就在网络或 PG 数量上。PG 数量可以按(OSD 数量 * 100) / 副本数的公式估算但不要一上来就设 4096PG 太多反而增加管理开销。5.4 现象迁移后应用时区错乱、字符集乱码把现有的 x86 虚拟机迁到信创云平台后有些应用的时间显示快了 8 小时或者日志里的中文变成问号。这通常不是云平台的问题而是迁移时没有保留系统的 locale 配置。新创建的虚拟机默认时区可能是 UTC而原系统是 CST。解决起来不复杂在模板镜像里预设好/etc/localtime软链接和/etc/sysconfig/clock文件。更稳妥的做法是使用完整镜像迁移而不是直接转换格式比如用qemu-img convert时保留原镜像的引导配置。字符集乱码则要检查/etc/profile和系统服务启动脚本里的LANG变量建议在镜像里统一设置为zh_CN.UTF-8或en_US.UTF-8避免服务启动时逐级继承默认值。5.5 现象镜像市场拉取失败或安装后启动不了很多团队喜欢搭建私有镜像仓库把常用系统镜像放进去。但拉取时有时报证书错误有时安装后虚拟机启动不了。证书错误通常是镜像仓库用了自签名证书需要在/etc/docker/certs.d或云平台的 truststore 里加入 CA。启动不了则要仔细检查镜像的格式有些镜像只支持 UEFI而云平台默认用 BIOS 引导需要额外指定启动参数。一个不容易发现的坑是镜像的「最小磁盘大小」标记。如果上传镜像时没有设置格式的虚拟大小而 Flavor 分配的磁盘比镜像要求的小实例会启动但写盘时空间不足。用qemu-img info查看镜像的virtual size再和 Flavor 的磁盘容量比对就能确认。6. 从方案到验收性能基线、自动化验证和一个小习惯方案写得好不好最终要看能不能通过验收。我在信创云平台项目里最常被验收方问到的是「你怎么证明这个平台能支撑业务」所以我的做法是在部署完成后立刻建立一套性能基线和自动验证脚本。性能基线通常包含 5 个指标虚拟机创建耗时从 API 请求到状态 ACTIVE、平均 CPU 使用率、内存分配比例、存储 IOPS、网络吞吐。分别用openstack server create、stress工具和iperf3来测。我一般会在方案里附一个表格写明目标值单台虚拟机创建不超过 60 秒块设备读延迟低于 2ms东西向网络吞吐不低于物理网卡的 70%。这些数字要提前定并留出 20% 的余量。自动化验证脚本我习惯放在控制节点上每天跑一遍输出结果到日志文件#!/bin/bash source /root/keystonerc_admin echo Cloud Health Check $(date) openstack service list | grep -E nova|neutron|glance|keystone | awk {print $2, $4} openstack host list openstack hypervisor stats show这个脚本只做了最基本的健康检查实际项目里我还会加上 API 响应时间的统计。还有一个我养成的习惯所有改过的 OpenStack 配置都放进版本管理不管是/etc/nova/nova.conf还是/etc/neutron/plugins/ml2/ml2_conf.ini每次变更都记录 diff。信创云平台的配置参数比普通私有云更多因为没有现成的经验可抄每一步都是试出来的不留记录三个月后连自己都看不懂当初为什么改这个值。如果只能给一条建议我会说不要把信创云平台当成一个一次性项目要用做产品的心态去沉淀部署脚本、配置清单和踩坑记录。这样下次项目启动你手里有了一份属于你自己的知识库而不是从零开始。希望我的这些经验能帮你在信创云平台建设这条路上少走几个坑。本文还有配套的精品资源点击获取 信创云平台建设全攻略：架构选型与OpenStack落地实践
简介《信创云平台建设方案》是一份面向信创产业服务保障基地及政企单位的完整建设规划文档聚焦解决国内信息技术自主创新云平台在核心技术受制、业务环境不可控、安全能力不足及缺乏适配环境等方面的典型问题。文档以入驻基地、搭建信创云、现场适配功能截图展示为主线系统梳理了硬件设备选型、操作系统与数据库软件配置、中间件升级等改造内容并按章节展开项目改造意义、需求分析自主可控、网络/计算/存储资源池、云管理平台、云备份、运维运营及安全系统以及云平台基础设施区设计等关键模块。资源包共包含1个docx文档压缩包大小约29.58MB适合作为信创云平台建设项目的方案模板、申报材料参考或技术架构设计依据。这一方案已有1447人学习下载对于正在编制信创云规划或需要借鉴成熟目录结构的读者具有较好的参考价值。1. 信创云平台建设方案为什么多数项目卡在「选型」而不是技术手里拿到一份《信创云平台建设方案.docx》时很多人第一反应是先找架构图。但真正做过一轮信创云平台落地的人会告诉你难点根本不在 OpenStack 怎么装、K8s 怎么编排而在于你面对的是一个「技术能跑、生态不齐」的底座。信创云平台的核心矛盾是国产芯片、国产操作系统、国产数据库、国产中间件这些组件必须协同工作任何一环的版本对不上前面所有工作都白做。这篇文章不是泛泛谈信创政策而是从方案落地角度把信创云平台的组成、选型、部署、适配和验收讲透适合正在写方案、准备搭建环境或做信创替代的从业者。2. 信创云平台的组成与选型从芯片到虚拟化的四层对应关系2.1 信创云平台四层架构芯片、操作系统、虚拟化、云管信创云平台和我们平时说的私有云、开源云平台在架构上并没有本质区别核心差异在每一层可选的组件被限定在了一个相对封闭的生态里。我习惯把信创云平台拆成四层硬件芯片层、操作系统层、虚拟化层、云管编排层。这四层不是各自独立选型而是存在严格的兼容关系。硬件芯片层目前常见的是鲲鹏ARM 架构、飞腾ARM 架构、海光x86 兼容、龙芯MIPS/LoongArch、兆芯x86 兼容。这直接决定了你后面装什么系统镜像、用哪套编译好的软件包。操作系统层以麒麟、统信 UOS 为主也有部分项目用欧拉、Anolis 这类开源社区版。虚拟化层在信创环境里最常见的组合是 KVM OpenStack也有不少商业方案用自研的虚拟化引擎但底层 Hugs 基本都是 KVM 的变体。云管编排层则是 OpenStack、Kubernetes 或者商业云平台。这里最容易被忽略的是「芯片架构 — 操作系统 — 虚拟化软件包」三者的对应关系。比如在鲲鹏上装麒麟系统看起来没问题但 OpenStack 的 RPM 包如果编译目标是 x86_64直接装就会出现缺依赖或者指令集不对。所以选型第一步不是画架构图而是把每一层用到的软件包的架构支持情况列一张表。我给一个常见的对应表正好可以作为方案附录层主流可选注意事项芯片鲲鹏 920、飞腾 S2500、海光 C86ARM 与 x86 的软件包不能混用操作系统麒麟 V10、统信 UOS、欧拉 openEuler建议选与芯片厂商做过适配认证的版本虚拟化KVM、QEMU、Docker需要确认宿主机内核是否开启相关模块云管OpenStackTrain/Ussuri、K8s、ZStackOpenStack 组件多版本要和 OS 匹配2.2 开源路线与商业路线OpenStack、云平台与超融合的边界很多项目负责人会问「信创云平台到底是用开源 OpenStack 还是买商业云平台」这个问题没有标准答案但有一个很现实的判断标准团队里有没有能扛住 OpenStack 运维的人。OpenStack 的好处是开放、可控、没有授权费但坏处是组件多控制节点光核心服务就有 Nova、Neutron、Cinder、Glance、Keystone、Placement 六七个任何一个服务的配置出错都会导致整个云平台不可用。商业云平台比如 ZStack、云宏、深信服等在信创领域做得好的通常是对国产芯片和操作系统做了深度适配安装体验接近「一键部署」而且提供统一的管理界面和运维告警。但商业方案的授权费用不低并且存在绑定风险——你选了它的云平台后续加节点、升级版本可能都要跟着它走。还有一种路线是超融合把计算、存储、网络在软件层融合到一起。超融合适合中小规模的信创替代场景比如几十台物理机的私有云。它的优势是部署快、运维简单缺点是扩展性不如 OpenStack 那种解耦架构存储和计算绑死在一起后期扩容不灵活。我的建议是如果是百台以内物理机且运维团队不超过三人优先考虑商业云平台或超融合如果是要做规模化、多租户、开放性要求高的信创云平台比如要对接深度学习云平台或智能云平台调度 GPU那就老老实实选 OpenStack 这条路。2.3 选型检查表拿需求文档核对这 7 项写方案最怕的就是「什么都想要」最后交付时一地鸡毛。我一般会拿一份需求文档逐条核对下面 7 项全部满足再往下走芯片架构明确是 ARM 还是 x86有没有指定信创目录内的产品名单。很多项目明确要求使用目录内产品这个必须在选型初期就核对不然方案评审直接被否。虚拟化技术栈是否要求兼容现有 KVM 虚拟机是否要支持 GPU 直通。存储方案是分布式存储Ceph还是集中式存储是否需要快照和备份能力。网络方案是否要求 VXLAN 网络隔离有没有多租户需求。安全合规是否需要接入统一身份认证、审计日志留存 6 个月以上是否要求等保三级。迁移路径现有虚拟机、物理机上的业务如何迁到新平台是否能接受停机窗口。运维能力团队有没有 OpenStack 运维经验决策者愿意投入多少人力。这 7 项里第 5 项最容易翻车。很多人以为信创云平台只要装起来就行结果安全检查时被问「日志审计存在哪里」「虚拟机管理员的操作有没有记录」答不上来。所以选型阶段就要把安全管理组件纳入架构而不是事后补。3. 用 OpenStack 搭建最小信创云三节点最小集群的 5 个步骤3.1 最小环境规划控制、计算、存储怎么分配如果你拿到的是「OpenStack 云平台搭建」方向的方案最需要的是一个能跑通的最小集群。三节点是常见的做法一个控制节点、两个计算节点。控制节点跑 Keystone、Nova API、Neutron、Glance、Placement计算节点跑 Nova Compute 和 Open vSwitch。存储要么用控制节点的本地盘做 Glance 存储要么单独挂一个 Ceph 集群但最小环境不建议一开始就上 Ceph先把功能跑通再说。以鲲鹏 920 服务器为例我给一个参考配置节点角色配置系统node1控制节点16C / 32G / 系统盘 200G 数据盘 500G麒麟 V10 SP2 ARM64node2计算节点32C / 128G / 系统盘 200G 数据盘 1T麒麟 V10 SP2 ARM64node3计算节点32C / 128G / 系统盘 200G 数据盘 1T麒麟 V10 SP2 ARM64网络方面至少两张网卡一张管理网承载 API 和内部通信一张业务网承载虚拟机流量。如果用 VXLAN还要考虑隧道网段和 VLAN 的规划。这些要在安装前确定不然后面改起来会牵连一堆配置。3.2 在鲲鹏环境安装核心组件的命令序列下面给出一个最小化的安装步骤使用 OpenStack Ussuri 版本。注意这里每个命令都是在麒麟 V10 ARM64 环境下验证过的常见做法不同 OS 版本可能包名略有差异。# 1. 配置 yum 源麒麟 V10 需要使用 ARM64 对应的 repo cat /etc/yum.repos.d/local.repo EOF [local] namelocal baseurlhttp://mirror.example.com/kylin/arm64/v10/sp2/ enabled1 gpgcheck0 EOF yum clean all yum makecache # 2. 安装 OpenStack Ussuri 的 RPM 包 # 这里用 packstack 做快速部署比手动逐个装组件快得多 yum install -y openstack-packstack # 3. 生成应答文件然后按需修改 packstack --gen-answer-file/root/answers.txt # 4. 修改应答文件中的关键参数 sed -i s/CONFIG_NOVA_COMPUTE_HOSTS.*/CONFIG_NOVA_COMPUTE_HOSTSnode2,node3/ /root/answers.txt sed -i s/CONFIG_NETWORK_CIDR.*/CONFIG_NETWORK_CIDR192.168.10.0\/24/ /root/answers.txt sed -i s/CONFIG_NEUTRON_OVS_BRIDGE_IFACES.*/CONFIG_NEUTRON_OVS_BRIDGE_IFACESbr-ex:eth1/ /root/answers.txt # 5. 执行部署 packstack --answer-file/root/answers.txt逻辑说明这套命令先解决的是软件源问题信创环境最大的坑之一就是默认源里没有 ARM64 的依赖包。第二步和第三步用 packstack 的应答文件机制把安装参数集中在一个文件里方便审计和重复部署。第四步是重点需要把计算节点列表改成实际的节点主机名或 IP把 Neutron 的网桥映射到你的业务网卡上。参数说明里CONFIG_NETWORK_CIDR必须填管理网络的网段它是 Neutron 创建外部网络的默认参考。CONFIG_NEUTRON_OVS_BRIDGE_IFACES的格式是桥名:物理网卡名如果先填错后面创建出来的虚拟机无法被外部访问。CONFIG_NOVA_COMPUTE_HOSTS用逗号分隔多个计算节点packstack 会通过 SSH 自动把这些节点纳入集群。3.3 验证命令与参数说明部署完成后不要急着登录 dashboard先做三层验证。第一层验证控制节点服务状态第二层验证计算节点是否注册第三层验证网络。# 查看 OpenStack 服务列表确认所有服务都是 UP 状态 source /root/keystonerc_admin openstack service list openstack host list # 验证镜像服务上传一个测试镜像 openstack image create --file cirros-0.5.1-arm64-disk.img \ --disk-format qcow2 --container-format bare cirros-arm64 # 创建测试网络和虚拟机 openstack network create test-net openstack subnet create --network test-net \ --subnet-range 192.168.100.0/24 --dhcp test-subnet openstack server create --flavor m1.small --image cirros-arm64 \ --network test-net --key-name mykey test-vm openstack server list逻辑说明openstack host list输出的结果里如果 node2 和 node3 没有出现在计算节点列表中说明 Nova 到计算节点的 SSH 配置有问题或者计算节点上的 nova-compute 服务没有正常启动。Cirros 是一个轻量测试镜像专门用来验证云平台功能ARM64 版本要选对x86 版本在鲲鹏上跑不起来。openstack server create之后用openstack console url show test-vm拿到 VNC 地址通过浏览器打开可以看到虚拟机的启动日志。如果虚拟机启动失败大多时候是镜像架构不匹配少数情况是虚拟化引擎没有识别到硬件加速。用kvm-ok命令检查宿主机是否支持 KVM如果不支持需要去 BIOS 里开启虚拟化功能。4. 信创适配与安全管理从兼容性矩阵到等保合规的落地路径4.1 信创适配操作系统、数据库、中间件的兼容性矩阵信创云平台搭好之后真正烧时间的环节是业务适配。一个数据库可能是 MySQL一个中间件可能是 Tomcat一个消息队列可能是 RabbitMQ这些软件在信创环境里都有或大或小的兼容性问题。我见过最常见的翻车是应用在 x86 服务器上跑得好好的迁移到鲲鹏上就报Illegal Instruction原因是代码里编译了针对 x86 的指令集。所以适配工作的第一步是做一张兼容性矩阵按业务系统列清楚操作系统、数据库、中间件、JDK、应用框架每一项标注是否经过验证。实际项目中我一般会用表格来管理业务系统操作系统数据库中间件兼容状态OA 系统麒麟 V10达梦 8TongWeb已验证邮件系统统信 UOSopenGauss东方通需测试深度学习平台欧拉MySQL 8.0无GPU 驱动待适配这张表的价值在于它能提前暴露哪些组件需要做替换。比如某个系统强依赖 Oracle而信创要求用国产数据库那就得评估是改写 SQL 还是用兼容组件做平滑过渡。这里要特别提一下「信创适配及安全管理」这个词。很多项目把适配和安全放在一起是因为适配过程中引入的补丁、动态库、配置文件本身就是安全风险的来源。一个稳妥的做法是建立分层的适配验证先做单组件验证再做系统联调最后做安全扫描。跳步的结果往往是上线后查不出问题一遇到并发就崩。4.2 安全管理身份、网络、审计三件套以及信创安全工程师投标时会被追问的细节信创云平台的安全管理不是装一个防火墙那么简单。我在方案里一般会写三件套身份认证、网络隔离、操作审计。身份认证层OpenStack 默认的 Keystone 可以对接第三方 LDAP 或 CAS如果要满足企业内部统一认证建议直接对接统一身份平台避免每套系统都建一遍账号。网络隔离层Neutron 的 VXLAN 网络隔离是基本能力。但真正需要关注的是东西向流量的安全策略同一台物理机上的两个租户虚拟机它们之间的流量如果走 VXLAN 隧道到底在哪里做过滤常见做法是在虚拟机上装安全组但安全组的规则如果设得太粗后续很麻烦。更可靠的方式是在网络节点上部署分布式防火墙或者引入第三方安全虚拟化组件。操作审计层OpenStack 自带的审计日志只记录 API 调用不记录用户实际操作。如果项目要求等保合规需要把虚拟机的 VNC 连接操作、管理员执行的命令、网络规则的变更全部记录到独立的日志平台。这个在方案设计阶段就要预留接口不然后面补审计功能非常痛苦。信创安全工程师投标时评审专家最喜欢追问的细节有三个第一管理面的访问是如何控制的有没有双因子认证第二虚拟机镜像的完整性校验是怎么做的有没有哈希校验机制第三日志留存时间是多长是否支持导出。这三个问题如果答得含糊方案分通常会很低。所以我会在方案里写清楚管理面只允许通过跳板机访问镜像在上传时用 SHA256 校验日志系统保留至少 180 天并定期归档。4.3 信创替代企业微信应用迁移与消息集成的一个折中方案「信创替代企业微信」是很多项目方案里的一个隐藏需求。企业微信这类办公协同工具在信创环境里不可能直接照搬需要一套替代方案。最常见的是用私有化部署的即时通讯组件比如一些基于 OpenFire、Ejabberd 改造的方案。但这类组件和应用系统的集成度通常不够尤其是「扫码登录」「消息推送」这些能力往往需要二次开发。我在项目中给过一个折中方案保留现有企业微信作为客户侧入口但服务端迁移到信创云平台上通过企业微信开放接口把消息转发到信创环境里的业务系统。这样做的好处是前端体验不变后端逐步替换风险小。真正的信创替代是在逐步替换过程中把数据、用户、权限重新梳理一遍而不是一刀切更换。如果你要做全尺寸替代需要规划好三个接口身份认证接口OAuth2、消息推送接口Webhook、通讯录同步接口LDAP/SCIM。这三个接口能跑通大多数 OA、审批、通知类业务都能迁移。切记不要自己发明消息协议走标准接口才能保证兼容性。4.4 深度学习云平台与智能云平台多租户 GPU 调度信创云平台的另一类常见落地场景是深度学习云平台。很多高校和科研机构已经在信创环境里搭建 GPU 集群边缘设备是昇腾或者寒武纪。这类平台和传统云平台的最大区别在于 GPU 虚拟化和调度。OpenStack 社区很早就支持了 GPU 直通但直通意味着一个 GPU 只能给一台虚拟机用资源利用率很低。更好的方案是引入 Kubernetes GPU 共享调度。常见做法是在 OpenStack 的虚拟机之上再搭一层 K8s通过 device plugin 管理 GPU实现同一块 GPU 上跑多个推理任务。信创环境下的 K8s 部署有一点要特别注意镜像仓库和基础镜像必须全部换成 ARM64 或对应架构的版本否则 kubelet 启动时就会报exec format error。智能云平台这个方向也类似核心是把推理引擎、训练框架、数据标注工具统一纳管。如果项目方案里提到智能云平台建议明确你用的是基于 OpenStack 的虚拟化底座还是基于 K8s 的容器底座。两者各有优劣OpenStack 适合传统 VM 业务K8s 适合 AI 业务但 AI 业务里需要 GPU 直通时K8s 的调度灵活性明显更强。5. 信创云平台建设避坑指南5 条高频翻车记录5.1 现象安装 OpenStack 时提示 CPU 指令集不支持在飞腾或鲲鹏服务器上装 OpenStack偶尔会看到Illegal instruction或KVM: unknown symbol。原因是软件包在编译时启用了特定 CPU 指令集比如 AVX512而 ARM 平台上没有这个指令。更诡异的是同一个 RPM 包在 x86 的海光上没问题在 ARM 上就崩。原因是社区或厂商提供的二进制包并非严格针对你的目标芯片优化有些包是用镜像服务器的 CPU 特性编译的。解决方法是优先选用芯片厂商或操作系统厂商提供的适配包而不是从通用源里拉。如果必须从源码编译在CFLAGS里加上-mcpugeneric或-mtunegeneric来降低指令级要求。另一个检查点是内核版本ARM 平台建议内核不低于 4.19太老的内核对虚拟化特性支持不全。5.2 现象虚拟机网络不通但宿主机网络正常创建一个虚拟机后从外部 ping 不通但在宿主机上 ping 虚拟机的 IP 却通。这通常不是安全组的问题而是 Neutron 的网桥映射配错了。常见错误是在CONFIG_NEUTRON_OVS_BRIDGE_IFACES里只写了br-ex没有写物理网卡导致 br-ex 桥没有实际挂载到物理网络上。另一个原因是物理网卡被 NetworkManager 接管和 Open vSwitch 冲突。解决方法是先停用 NetworkManager 对业务网卡的管理再把网卡加入 OVS 桥。用ovs-vsctl show检查桥的状态如果Port eth1显示Interface eth1但状态是DOWN说明物理链路没有起来要检查网线或交换机配置。还有一个容易被忽略的细节VXLAN 需要 MTU 一致如果物理网络 MTU 是 1500而虚拟机接口设了 1450大包会丢但小包能通。5.3 现象存储性能与标称差距极大信创云平台经常配分布式存储但性能测试时 IOPS 只有标称的 30%。最常见的原因是存储网络和数据网络共用同一个千兆网卡Ceph 的副本同步流量和虚拟机的业务流量抢带宽。另一个原因是没有配置 NVMe 缓存层所有写操作都落到机械盘上。解决方法是给 Ceph 单独规划万兆网络并要求所有 OSD 节点使用 SSD/NVMe 作为日志盘。Ceph 的bluestore模式需要配置db设备如果没有单独分配性能会明显下降。调优时可以用ceph tell osd.* bench测单盘性能如果单盘 IOPS 足够那瓶颈就在网络或 PG 数量上。PG 数量可以按(OSD 数量 * 100) / 副本数的公式估算但不要一上来就设 4096PG 太多反而增加管理开销。5.4 现象迁移后应用时区错乱、字符集乱码把现有的 x86 虚拟机迁到信创云平台后有些应用的时间显示快了 8 小时或者日志里的中文变成问号。这通常不是云平台的问题而是迁移时没有保留系统的 locale 配置。新创建的虚拟机默认时区可能是 UTC而原系统是 CST。解决起来不复杂在模板镜像里预设好/etc/localtime软链接和/etc/sysconfig/clock文件。更稳妥的做法是使用完整镜像迁移而不是直接转换格式比如用qemu-img convert时保留原镜像的引导配置。字符集乱码则要检查/etc/profile和系统服务启动脚本里的LANG变量建议在镜像里统一设置为zh_CN.UTF-8或en_US.UTF-8避免服务启动时逐级继承默认值。5.5 现象镜像市场拉取失败或安装后启动不了很多团队喜欢搭建私有镜像仓库把常用系统镜像放进去。但拉取时有时报证书错误有时安装后虚拟机启动不了。证书错误通常是镜像仓库用了自签名证书需要在/etc/docker/certs.d或云平台的 truststore 里加入 CA。启动不了则要仔细检查镜像的格式有些镜像只支持 UEFI而云平台默认用 BIOS 引导需要额外指定启动参数。一个不容易发现的坑是镜像的「最小磁盘大小」标记。如果上传镜像时没有设置格式的虚拟大小而 Flavor 分配的磁盘比镜像要求的小实例会启动但写盘时空间不足。用qemu-img info查看镜像的virtual size再和 Flavor 的磁盘容量比对就能确认。6. 从方案到验收性能基线、自动化验证和一个小习惯方案写得好不好最终要看能不能通过验收。我在信创云平台项目里最常被验收方问到的是「你怎么证明这个平台能支撑业务」所以我的做法是在部署完成后立刻建立一套性能基线和自动验证脚本。性能基线通常包含 5 个指标虚拟机创建耗时从 API 请求到状态 ACTIVE、平均 CPU 使用率、内存分配比例、存储 IOPS、网络吞吐。分别用openstack server create、stress工具和iperf3来测。我一般会在方案里附一个表格写明目标值单台虚拟机创建不超过 60 秒块设备读延迟低于 2ms东西向网络吞吐不低于物理网卡的 70%。这些数字要提前定并留出 20% 的余量。自动化验证脚本我习惯放在控制节点上每天跑一遍输出结果到日志文件#!/bin/bash source /root/keystonerc_admin echo Cloud Health Check $(date) openstack service list | grep -E nova|neutron|glance|keystone | awk {print $2, $4} openstack host list openstack hypervisor stats show这个脚本只做了最基本的健康检查实际项目里我还会加上 API 响应时间的统计。还有一个我养成的习惯所有改过的 OpenStack 配置都放进版本管理不管是/etc/nova/nova.conf还是/etc/neutron/plugins/ml2/ml2_conf.ini每次变更都记录 diff。信创云平台的配置参数比普通私有云更多因为没有现成的经验可抄每一步都是试出来的不留记录三个月后连自己都看不懂当初为什么改这个值。如果只能给一条建议我会说不要把信创云平台当成一个一次性项目要用做产品的心态去沉淀部署脚本、配置清单和踩坑记录。这样下次项目启动你手里有了一份属于你自己的知识库而不是从零开始。希望我的这些经验能帮你在信创云平台建设这条路上少走几个坑。本文还有配套的精品资源点击获取