简介这份《信创云平台建设方案》是一份面向信创产业服务保障基地建设的完整参考文档适合政企信息化规划人员、云平台架构师及信创项目招投标文案编写者使用。方案从入驻基地、搭建信创云到现场适配功能截图展示逐一展开并围绕项目改造意义、改造目标与改造内容进行说明同时梳理了国内信息技术自主创新云平台的发展现状与核心问题如核心技术受限于国外、业务环境不可控、安全能力不足、缺乏适配环境等还给出了需求分析要点。内容预览显示文档深入第4章云平台基础设施区设计覆盖计算资源池、存储资源池、云管理平台、云备份及云安全等模块并涉及自主可控、网络资源池、运维运营管理等子项结构完整、层级清晰适合直接参考或按需改编。资源为一个Word文档docx格式文件大小29.58MB已有1447人学习下载可帮助读者快速搭建信创云建设方案框架是撰写标书或内部规划时的优质范文模板。1. 信创云平台建设方案不是给 VMware 换皮是整套虚拟化栈重写接到「信创云平台建设方案.docx」这个标题时很多团队的第一反应是“把 VMware 的虚拟化换成 KVM把 CentOS 换成麒麟方案就写完了”。实际交付过的人都清楚信创云平台建设方案真正难的不是云平台本身而是“信创”两个字国产 CPU 的虚拟化特性差异、国产操作系统的内核补丁状态、中间件和数据库在新架构上的兼容性验证每一个都能把项目拖进适配泥潭。这个方案要解决的是在 arm64 或 x86 国产芯片上用国产 OS 加 OpenStack 或同类云管软件搭出可生产、可运维、能过密评和等保的虚拟化资源池。适合集成商、甲方基础设施团队和刚转向信创方向的一线工程师照着它能少走一半弯路。2. 信创云平台的技术底座国产 CPU 与操作系统选型为什么决定后续所有适配2.1 国产 CPU 三条路线ARM、x86 与自主指令集怎么选信创目录里的 CPU 大致分三类以鲲鹏、飞腾为代表的 ARM 路线以海光、兆芯为代表的 x86 路线以及龙芯、申威为代表的自主指令集路线。选型第一刀不是比性能参数而是看客户的业务负载。现有业务系统如果是纯 Java 中间件加 MySQL、RedisARM 路线基本无感迁移如果涉及 Windows 虚拟机、老旧 x86 内核模块或闭源驱动老老实实上海光兆芯这类 x86 兼容路线能省掉至少两个月的适配周期。ARM 路线的性能在 Web 服务和分布式计算场景下已经不输通用 x86 服务器但它的麻烦在次要路径办公终端插件、加密机驱动、老版本 Oracle、外设驱动这些往往没有 ARM 版本。x86 路线兼容性最好但在某些行业客户的“自主可控评分表”里拿的分数不如 ARM 或自主架构高。龙芯则是另一个极端自主程度最强但生态最薄适合完全新建的业务系统不适合存量迁移。选择逻辑我一般这样跟客户讲存量业务多、割接窗口小选海光新建业务、有长期自主化要求选鲲鹏或飞腾有极端自主化考核选龙芯但要做好部分商业软件不提供龙芯版本的准备。另外还要查信创目录产品名单不是送测过的芯片都能进目录客户招标文件里往往直接限定“目录内产品”这一步选错后面连投标资格都没有。2.2 国产操作系统与虚拟化组合为什么 OpenStack 在信创云里仍是主流底座CPU 定了操作系统无非麒麟、欧拉、UOS、龙蜥这几条线。做信创云平台的技术底座我建议把宿主机的 OS 和云平台的 OS 分开看宿主机用麒麟 V10 SP 或欧拉 22.03 LTS云平台内部业务虚机的镜像再按客户要求配。原因是麒麟和欧拉的内核都做了 openEuler 内核的长期维护KVM 和 QEMU 的补丁跟随较及时作为 Hypervisor 宿主比较稳。虚拟化底座层面OpenStack 仍是主流选择不是因为它最先进而是因为它是唯一一个把计算、网络、存储、镜像、认证这些云平台必备组件全部开源、且社区积累超过十年的方案。商用的云厂商自研 HCI 虚拟化平台也有不少信创版本但一旦用上网络策略、备份接口、监控告警全部跟着厂商走后期想扩第三方存储或迁移很被动。OpenStack 的 API 是标准化接口neutron、cinder、glance 这些组件即使换厂商发行版操作逻辑也变化不大这对甲方运维团队最友好也是集成商愿意交付的主要原因。底层的虚拟化组合在 x86 国产化路线上是 KVM QEMU libvirtARM 路线上同样有 KVM 的 ARM 移植版管理层面差别不大。真正需要提前验证的是嵌套虚拟化如果客户要求在这朵云里再跑 docker 或另一层虚机ARM 路线的嵌套虚拟化支持程度参差不齐一定要在选型阶段用一台样机实测别等部署到一半再翻车。2.3 信创适配与安全管理选型时就要先圈好边界信创云平台建设方案里“信创适配及安全管理”往往单独成章但一线工程师要清楚安全管理不是最后加几台防火墙就完事。虚拟化层的安全能力包括镜像签名校验、虚拟机的内存隔离、虚拟网络的防火墙策略、租户隔离以及日志审计。OpenStack 的 Glance 镜像服务支持 metadata 签名neutron 的 security group 能做到虚机级四层防护但这些组件默认配置下很多项是关闭的需要逐项打开并改默认密码。这里要提醒做投标方案的朋友招标文件里如果出现“信创安全工程师投标”或“信创适配及安全管理赛项”这类的字眼通常意味着客户不仅要求平台能跑还要求交付一套完整的安全配置基线。这套基线至少要覆盖管理网 VLAN 隔离、云平台各组件间的通信加密、数据库和消息队列的访问控制、以及运维操作审计。后文第 5 章里会给出我在实际项目中遇到的安全组件冲突案例那类问题在信创环境里比在通用 x86 环境更常见。3. 信创云平台架构设计从管控到存储的层次划分与资源池规划3.1 管控面与计算面拆开控制节点集群的容量规划信创云平台的架构设计与传统虚拟化项目有一个显著区别控制面组件更重。OpenStack 的 keystone、nova、neutron、cinder、glance 加上底层的 MySQL、RabbitMQ、Memcached全部集中在控制节点上任何一个组件假死都会让整个平台的管理面不可用。控制节点数量至少三台起这是高可用底线不是可选项。控制节点的资源配置我一般按这个基线走32 核起、64GB 内存以上、系统盘用两块 NVMe SSD 做 RAID1数据盘按日志保留周期折算容量。如果是规模超过 200 台物理机的资源池建议把 MySQL 和 RabbitMQ 单独拆出来跑不要和控制节点其它 API 服务混布否则一次突发流量就可能把数据库连接池打满控制面像雪崩一样逐个组件失联排查起来非常痛苦。控制节点的 OS 建议用与计算节点同一版本的国产 OS避免因为内核版本差异导致部分组件在某个节点上异常。另外控制节点不建议开启 CPU 超线程直通或抢占类配置它的任务就是稳定接管管理流量性能不是瓶颈稳定性才是。3.2 存储面选型Ceph 与集中式存储的取舍存储是信创云平台建设方案里最容易低估的部分也是实际交付后意见最多的部分。虚机能创建出来、网络能通但一跑业务就慢、一写数据库就卡问题多半出在存储设计和性能测试没做好。存储面基本两条路分布式存储典型是 Ceph和信创集中式存储阵列。Ceph 的优点是完全开源、无厂商锁定、容量和性能可以线性扩容非常适合对象存储和虚拟磁盘统一承载的中大规模资源池。它的代价是消耗计算节点的 CPU 和内存资源特别是 OSD 节点需要配置足够的内存来跑 Page Cache 和 PG 元数据并且对网络质量和延迟非常敏感。信创集中式存储阵列正好相反性能稳定、故障域清晰、有厂商技术支持但单价高且扩容受控。我的经验是如果资源池小于 48 台物理机且业务以传统 OA、电子公文等 IOPS 压力不大的系统为主可以做全 Ceph 方案三节点 OSD 起步。如果业务包含 Oracle 数据库、大规模视频存储或高并发交易类系统存储必须用集中式阵列虚拟化平台只做好 cinder 对接。混合方案也可行把高 IOPS 业务放阵列、普通虚拟机放 Ceph但需要客户接受两套存储成本。还有一个信创环境特有的点Ceph 的版本和国产 OS 内核之间的兼容性。有些国产 OS 自带的内核较旧与新版 Ceph 的 bluestore 后端存在兼容问题主要表现为 OSD 进程无故重启或 io_uring 报错。选型阶段要在真实硬件上跑一轮 ceph osd bench不要只看安装成功。3.3 网络平面划分VLAN、VXLAN 与三种网段的设计OpenStack 环境里网络平面建议至少分三类管理网、业务网、存储网条件允许再单独拉一张 PXE 部署网。管理网承载所有组件的 API 调用和 SSH 运维业务网承载虚机南北向流量和东西向互通存储网专跑副本复制和 iSCSI/VXLAN 流。三张网在物理上用 VLAN 隔离核心交换机做好端口隔离不要让存储流量和管理流量争抢链路带宽。VXLAN 的选择取决于业务网络规模。VLAN 模式在二层网络结构简单、虚机数量少的环境里最省事排障容易但在多租户场景下 VLAN ID 上限 4094 会成为瓶颈而且跨交换机扩展要改接入层配置。VXLAN 模式把二层网络封装到三层之上租户数可以到 1600 万个网络隔离能力好得多但需要额外维护 L2GW 或集中的二层网关OpenStack 里对应的是 neutron 的 L3 agent 和 openvswitch 机制驱动。信创环境下选 VXLAN 要注意交换机对 VXLAN 隧道终结的支持程度一些老旧国产交换机只支持基础 VXLAN 转发不支持 BGP-EVPN会限制后期的网络自动化能力。网络设计还有一个必须提前确认的参数MTU。VXLAN 封装后虚机网卡的 MTU 需要下调到 1400 或 1450否则虚机访问跨网段业务时会出现大包被丢弃、小包正常、网页打不开等诡异问题。这个参数不做全局统一规划后期排查会让你怀疑人生。4. 从零交付一套信创云硬件清单、部署步骤与关键参数4.1 最小可用硬件清单与 BIOS 设置如果手头没有真实信创服务器用通用 x86 服务器加国产 OS 也能在功能层面复现整个流程但生产交付一定要按信创整机来。最小可用的物理资源池至少包含3 台控制节点、3 台计算节点、3 台存储节点合计 9 台起步低于这个规模不建议上 OpenStack直接用单机虚拟化更划算。BIOS 设置是第一个坑点。无论是鲲鹏还是海光机型必须进 BIOS 确认虚拟化开关处于开启状态。ARM 机型上叫 Virtualizationx86 机型上叫 SVM Mode 或 VT-x名称因厂商而异默认就有部分是禁用的。还有一个容易忽略的是电源管理策略建议设置为 Performance 模式或最大性能模式否则 CPU 频率的动态调节会让基准测试数据忽高忽低验收时说不清楚。# 确认 CPU 虚拟化支持和当前 CPU 运行频率 lscpu | grep -E Virtualization|CPU max MHz|CPU min MHz # 检查 KVM 内核模块是否已加载 lsmod | grep kvm # 若 kvm 模块未加载对海光等 x86 平台执行 modprobe kvm_amd # 对鲲鹏等 ARM 平台执行 modprobe kvm先解释为什么先跑这三条命令lscpu 的输出能看到虚拟化类型是 AMD-V 还是 ARM 虚拟化扩展也能看到当前 CPU 的频率策略是否锁在较低档位。如果 Virtualization 一栏为空或显示“无”说明 BIOS 里没开后面装 OpenStack 计算服务必然失败。modprobe 是手动加载内核模块命令执行后可以再运行 lsmod 确认 kvm 模块状态为“已加载”。4.2 用 Kolla-Ansible 部署核心组件的最小流程部署 OpenStack 的常见做法是用 Kolla-Ansible它把各组件容器化用 Ansible 批量编排比手工部署可靠得多。信创环境里要注意 Kolla 镜像的获取可以直接从 Docker Hub 拉取通用镜像但更稳的是手动 build 一套基于国产 OS 基础镜像的组件镜像避免出现 glibc 版本不兼容。# 准备部署机环境以欧拉 22.03 为例 yum install -y python3-pip git ansible pip3 install kolla-ansible # 生成部署配置文件 cp -r /usr/share/kolla-ansible/etc_examples/kolla /etc/kolla/ cp /usr/share/kolla-ansible/ansible/inventory/multinode /etc/kolla/ # 修改 multinode 文件把控制节点和计算节点 IP 填进对应分组 # [control] 节点填 3 台控制节点 IP # [compute] 节点填 3 台计算节点 IP # [storage] 节点填 3 台存储节点 IP # 修改 globals.yml 核心参数 # kolla_base_distro: centos # 国产 OS 场景改为镜像源一致的基础系统 # kolla_internal_vip_address: 10.10.10.10 # 控制面虚拟 IP # network_interface: eth0 # 管理网卡名 # neutron_external_interface: eth1 # 外部网络网卡名这段配置里最关键的是 kolla_internal_vip_address这个地址需要提前在网络里预留三台控制节点会通过 Keepalived 争抢这个 VIP所有 API 请求都走它。network_interface 必须和控制节点、计算节点上实际的管理网卡名称一致否则部署阶段网络检测直接报错。neutron_external_interface 选一张空网卡后续给虚机提供外网访问能力不要和管理网复用否则路由会混乱。4.3 上传信创 OS 镜像并创建第一台虚机平台部署完成后第一步不是急着创建虚机而是先把国产 OS 的云镜像上传到 Glance并验证 cloud-init 是否能正常完成虚机初始化。信创 OS 厂商会提供 qcow2 格式的云镜像建议直接下载官方云镜像不要拿安装 ISO 手动制作否则 virtio 驱动和分区表都可能缺失。# 上传镜像到 Glance source /etc/kolla/admin-openrc.sh openstack image create --file ./Kylin-V10.qcow2 \ --disk-format qcow2 --container-format bare \ --property os_distroKylin --public Kylin-V10 # 创建外部网络VLAN 模式 openstack network create --provider-physical-network physnet1 \ --provider-network-type vlan --provider-segment 101 external-net openstack subnet create --subnet-range 192.168.100.0/24 \ --gateway 192.168.100.1 --network external-net external-subnet # 创建租户网络和路由器 openstack network create tenant-net openstack subnet create --subnet-range 10.10.0.0/24 --network tenant-net tenant-subnet openstack router create tenant-router openstack router set --external-gateway external-net tenant-router openstack router add subnet tenant-router tenant-subnet # 创建虛机规格和第一台虚机 openstack flavor create --ram 4096 --disk 40 --vcpus 4 m1.large openstack server create --flavor m1.large \ --image Kylin-V10 --network tenant-net \ --key-name my-key kylin-test-01参数里 --provider-segment 101 是 VLAN ID要和交换机上实际配置的 VLAN 一致物理交换机该端口必须放行对应 VLAN。router set --external-gateway 这一步是把租户网络的流量通过路由器转发到外部网络虚机才能访问外网。如果创建虚机后状态一直是 BUILD 而不是 ACTIVE多半是计算节点资源不足或镜像上传不完整先看 nova 的日志不要盲目重试。5. 信创云建设避坑清单兼容性、性能与安全的三类翻车现场5.1 虚拟机启动极慢或卡在 BUILD 状态现象执行 openstack server create 后虚机长时间停留在 BUILDhypervisor 日志里反复出现镜像拉取失败或卷创建超时。原因信创环境里最常见的是 Glance 存储后端与 Ceph 的认证配置不一致。Kolla-Ansible 部署时如果 cinder 和 glance 的 Ceph 密钥没有正确分发到计算节点计算节点就无法从 Ceph 读取镜像数据。解决逐一检查 /etc/kolla/ 下的 ceph 密钥确认计算节点上的 /var/lib/kolla/config_files/ 目录中存在对应 keyring 文件。另外检查 cinder 卷类型的后端名称很多国产 OS 的 initrd 里不带 Ceph 模块需要额外处理。5.2 信创 OS 镜像里的 virtio 驱动缺失导致蓝屏现象上传 Windows Server 信创定制版镜像启动虚机后卡在 Windows logo 界面或蓝屏无法进入桌面。原因镜像文件没有集成 virtio 驱动。Windows 默认不带 virtio 网卡和块设备驱动从 ISO 安装时用的是 IDE 模式上传到云平台后磁盘控制器切换成 virtio系统找不到引导盘。解决在制作镜像时用 virtio-win 驱动包预先注入。常见做法是先用 IDE 模式启动虚机手动安装 virtio 驱动再关闭虚机将磁盘控制器改为 virtio 后再启动。如果镜像已经定型可以直接用 virt-customize 离线注入驱动。5.3 安全组件拦截 neutron 的网络流量现象虚机创建成功但无法获取 DHCP 地址检查 neutron-dhcp-agent 日志正常安全组件日志显示大量拦截记录。原因信创环境普遍部署了主机安全 agent部分安全软件会把 dnsmasq 的 DHCP 响应包判定为异常行为直接拦截有的还会阻断 neutron 的 Open vSwitch 流表下发。解决在主机安全产品的白名单策略里放行 dnsmasq、ovs-vswitchd 和 nova-compute 进程。如果安全组件不允许按进程隔离就调整网络命名空间的流量审计模式把管理网网段加入信任域。和客户安全管理员提前沟通设备别等部署后扯皮。5.4 ARM 节点上虚拟化性能明显低于物理机现象跑 UnixBench 或sysbench虚机性能只有物理机的六成CPU 密集型的加解密任务表现尤为明显。原因QEMU 虚机 CPU 模式配置为默认的 qemu64 或自定义型号没有透传宿主 CPU 特性集。ARM 平台上的 KVM 虚拟化对 CPU 特性传递更敏感缺失硬件特性会导致内核加密模块回退到软件实现。解决在 nova 的 flavor 里显式配置 CPU 模式或者修改 nova-compute 的 virtcpu 配置。x86 平台可以用 host-passthroughARM 平台需要确认宿主内核支持的特性列表不要盲目套用同一个参数。CPU 虚拟化损耗控制在 10%-15% 是正常的超过 20% 一定要回查 CPU 特性配置。5.5 开源中间件在信创 OS 上依赖缺失现象客户运维团队在虚机里部署 RabbitMQ 或 Kafka启动成功但运行一段时间后随机崩溃日志提示缺少某个底层库。原因信创 OS 的软件仓库比 CentOS 更精简部分商业中间件需要特定版本的 libssl、libcurl 或 libaio仓库中没有对应包安装过程省略了依赖检查。解决在虚机模板中预装常用的兼容性库包并建立一个内部私有源把第三方依赖统一放到私有源上。麒麟和欧拉都提供了兼容性支持包遇到依赖缺失先查兼容性库是否可安装不要一上来就改中间件配置去绕开依赖。6. 信创云平台的适配验证与长期运行技巧从跑通到敢上生产平台跑通只是第一步敢把业务切上去还需要一套验证基线和长期运维手感。我的验证流程一般分三层先做硬件虚拟化损耗测试再做控制面高可用演练最后做业务链路的全流程验收。虚拟化损耗测试用 sysbench 和 UnixBench 分别跑物理机和虚机做同配置对比# 在物理机和虚机分别执行对比 CPU 事件吞吐 sysbench cpu --threads8 --time60 --events0 run # 对比内存读写带宽 sysbench memory --threads8 --time60 --memory-block-size1M \ --memory-total-size100G --memory-operread run物理机和虚机的数据差即是虚拟化损耗。CPU 事件吞吐和内存带宽损耗都在 10%-15% 范围属于正常超过 20% 说明 CPU 特性或 NUMA 配置有问题。存储性能用 fio 做顺序写和随机读两组注意队列深度不要设置太深否则容易压出 Ceph 的 OSD 瓶颈反而掩盖虚机层面的问题。控制面高可用演练不能只在部署商那里做要让客户运维团队全程参与。方法很简单选择业务低峰期直接重启一台控制节点观察 VIP 是否在 10 秒内切换到备用节点创建虚机的 API 是否持续可用。再拔掉网络节点的外网网卡确认浮动 IP 的 NAT 流量是否平滑转发。这两类演练做过一轮客户对平台的信任度会明显改观。长期运维里我的另一个习惯是每天固定看三张状态图ceph -s 的 PG 状态、RabbitMQ 的连接数、nova 的虚机分布。Ceph 的 PG 状态出现 degraded 或 misplaced 超过半小时要引起重视RabbitMQ 连接数上升到阈值附近就要排查是否有人重复注册了健康检查。信创平台的很多故障不是突发的而是从这些指标的小变化开始累积早发现远比事后抢救容易。这套方案前后交付过几个项目最大的教训是别拿通用 x86 的部署经验直接套信创环境ARM 平台的坑比预想的多而且很多坑出现得毫无规律。现在我做任何信创云项目都会坚持先拿一个小集群真实跑两周压测再做生产割接这个习惯救过我很多次。希望帮到你。本文还有配套的精品资源点击获取