作者：联通云数据有限公司OpenStack研发工程师 李昆山
OpenStack是目前主流云计算管理平台，自2010年6月首次发布以来，受到了IT业界几乎所有主流厂商的关注和支持，在现有的私有云市场中，OpenStack厂商占比超70%，在未来几年市场规模也在不断增长。
openEuler 是一个在 2019 年开源的基于 Linux 稳定系统内核的服务器操作系统，致力于通过打造开源社区，与全球的开发者共同构建一个开放、多元和架构包容的 openEuler 软件生态体系。
在openEuler成立之初，中国联通作为OpenStack黄金会员，本着取之于社区、回馈社区的宗旨牵头成立了OpenStack SIG，旨在完善OpenStack在openEuler上 的适配，丰富openEuler在云平台领域的适应能力。
OpenStack适配openEuler的工作对双方而言均有着重要意义，一方面OpenStack适配openEuler能拓展OpenStack对多架构生态的支持，另一方面，也能增强OpenEuler社区在云计算领域的适应性。更为重要的是，OpenStack对openEuler的适配工作也为国产化云平台发展提供一种新的方案选择，为中国云计算国产化、信创云发展提供更有利条件。
OpenStack适配openEuler实践
作为OpenStack SIG首位Maintainer ，联通沃云是完全适配 OpenStack 工作的主要承担者。过去，联通完成了对鲲鹏计算平台的适配工作，同时即将为openEuler社区提供一个与CentOS/Ubuntu/SUSE等OS同样便捷完整的OpenStack部署方式：
• 重新编译OpenStack及相关组件rpm软件包（基于openEuler 20.09）
• 解决OpenStack各组件在编译、和安装过程中的依赖包问题
• openEuler社区代码仓库创建、补全，源码提交（Gitee）
在适配工作过程中，联通沃云对现有问题进行了针对性解决，存在问题：
• Python ABI版本问题（OpenStack 社区仅提供python3.6运行环境的rpm包，openEuler为python3.8）
• OpenStack组件间存在复杂的依赖
• OpenStack python依赖包与现存python-modules冲突问题
1、Python ABI版本问题解决思路
1) 梳理依赖关系
2) 重新在python3.8环境下构建rpm包及仓库
redhat、debain 等系统repos部署方式
2、OpenStack组件间存在复杂的依赖解决思路：
1) 梳理依赖关系
2) 重新在python3.8环境下构建rpm包及仓库
openEuler平台即将构建的repos
3、OpenStack python依赖包与现存python-modules冲突问题解决思路
1) 从现有的src.rpm中取得spec文件和源码修改后进行编译
2) 适用于python-modules、虚拟化组件、存储等包
3) SRC RPM主要来源：
a) Fedora Project
b) Redhat OpenStack Repository
c) OpenStack rpm-packages
4) 使用社区源码包，生成spec文件结合社区源码进行编译
截至目前，联通沃云主导的OpenStack适配openEuler的工作已取得许多阶段性成果：
1、已完成运行测试模块
a) nova
b) neutron
c) glance
d) keystone
e) cinder(LVM backend)
1、 社区提交
a) 完成仓库创建数量
b) 完成Code Pull Request
泰山服务器+openEuler+OpenStack
泰山服务器+openEuler+OpenStack
3、社区提交：
……
将为社区提交300个左右的python包；
在下一阶段的工作中，联通沃云将着重解决Victoria版完整功能适配、非核心组件适配等问题，同时在OpenStack层面会有一些针对最大限度挖掘openEuler平台性能的开发将持续展开 ，届时沃云希望邀请更多开发者加入OpenStack SIG中。
参与到 OpenStack SIG方式如下
Project Link：https://gitee.com/openeuler/community
新沃云平台国产化建设经验
中国联通是国内运营商中较早使用 OpenStack 开源框架的企业，并在2017年入选 OpenStack 基金会黄金会员。openEuler 操作系统的引入则为中国联通云计算在安可领域提供了更加多元化的应用运行环境。中国联通也基于此不断构筑新沃云从操作系统到云平台的完整技术栈，丰富新沃云硬件架构及自主可控能力。
系统/虚拟化方面
1、 OS、kernel
a) 中标麒麟V7SP（ARM、海光版）
b) 麒麟V10 & openEuler
2、QEMU-KVM组件重新编译
存储方面
1、Ceph分布式存储
a) Luminous版本
b) Nautilus版本
2、 对象存储
a) TiDB, TiKV重新编译
网络方面
1、负载均衡LVS适配开发
2、ipvs内核模块移植： 3.10 --> 4.19
中间件方面
1、基础中间件重新编译，包括MongoDB/Galera/JRE等
2、国产关系型数据库适配
OpenStack（compute）方面
1、加入国产CPU芯片识别
a) 定制cpu vendor/model信息
2、Multi-ISA支持
a) 计算节点cpu vendor/model配置
b) VM开通、热迁移兼容性改造
c) 混合平台OS_ARCH选择：ARM64/Hygon C86
d) 定制ARM64、海光C86版本镜像
裸金属方面
1、PXE启动同时支持UEFI+BIOS
2、改造Deploy Interface，支持文件系统方式直接部署，可在30s内完成OS安装
3、ARM64部署内核镜像重新打包，加入国产服务器对应内核及驱动
4、x86/aarch64多架构dnsmasq配置文件整合
5、ARM64+UEFI启动模式grub.cfg生成逻辑修改
资源部署方面
1、多架构自动化部署
a) 支持同集群内提供不同ISA计算节点
b) 根据宿主机ISA自动选择对应安装源、配置
c) 根据宿主机ISA自动生成对应配置
2、YUM源构建
a) aarch64基础YUM源构建及裁剪
b) OpenStack依赖组件rpm包梳理
云计算国产化面临的诸多挑战
作为科技自立自强重大发展战略的重要一环，云计算国产化不仅能有效保障信息安全，还能促进基础软硬件的成长。尤其是随着政务云建设需求不断上升，真正实现云计算国产化才能在彻底解决安全顾虑的同时，促进云计算产业茁壮成长和IT国产化替代工作的进步。
但我们需要看到，目前云计算国产化在基础性能、部署支持、迁移稳定等方面仍有着诸多挑战：如行业大规模部署案例有限、开源社区支持有限；计算及虚拟化性能与x86存在差距、加速芯片支持不足；现存业务迁移至国产化平台需要额外工作、运行稳定性有待验证等
这也需要更多云厂商参与到云计算国产化进程中来，通过与客户紧密合作，进行更广泛的业务场景适配、云厂商间进行更多合作，通过开放实验室进行软硬件匹配优化、以及共同开发及利用已有应用迁移工具，协助客户业务迁移实践。
云计算国产化之路道阻且长，还需中国本土云厂商上下求索。
