ARM是如何成为OpenStack一等公民的

在过去两年中，Linaro的软件定义基础设施（SDI）团队致力于成功交付运行在Armv8-A AArch64（Arm64）硬件上的云——它可与任何OpenStack云互操作。

为了衡量与其他OpenStack云的互操作性，我们使用OpenStack互操作指南作为基准。自2016年以来，我们针对不同的OpenStack版本进行测试（Newton、Queens和Rocky）。使用Rocky，Arm64硬件上的OpenStack通过了2018.02指南中100％的测试，启用了足够的项目，Linaro的Kolla部署和kolla-ansible符合要求。这是一项重大成就。Linaro现在能够提供在Arm64硬件上运行时完全可互操作的云（从用户角度来看）。

那么我们到底做了什么让ARM成为OpenStack的一等公民呢？

Linaro Reference Architecture：一个简单OpenStack多节点部署

我们从一些Arm64服务器开始，在它们上面安装了Debian / CentOS，并尝试使用发行版软件包来创建一个非常基本的OpenStack多节点部署（当时版本是Mikata）。我们一直在寻找并修复bug，试图同时在上游和Linaro的设置上做出贡献，解决所有需要的后移问题。最后，我们决定从OpenStack master（后来成为Newton）构建自己的包，并开始在发现问题时测试/修复问题。

这是一个非常简单的三节点控制平面、N节点计算加上Ceph用于存储虚拟机和卷的部署。它被称为Linaro Reference Architecture，以确保所有Linaro工程师远程生成测试结果，并能够准确地重现故障。

Linaro Developer Cloud生成数据中心

2016年，ARM硬件非常稀缺且难以管理。因此，该团队建立了三个数据中心（美国、中国和英国），以便Linaro成员工程师更容易共享硬件和自动化工作负载。

在Newton期间，Linaro连接服务器，安装操作系统（几乎是从本地PXE服务器手动），并尝试使用我们编写的Ansible脚本安装/运行OpenStack master来安装我们的软件包。使用这种基本工具在英国安装了一个云，几个月后我们参加了OpenStack Summit Barcelona，并在OpenStack Interoperability Challenge 2016期间进行了演示。

这些都是Linaro云产品的早期阶段，工作负载非常简单（LAMP），但是它驱动了五个虚拟机，并在带有Ceph后端的多节点Newton Arm64云上运行——成功且完全自动化，无需任何特定于架构的更改。Linaro的云构建在Linaro成员捐赠的硬件上，来自云的功能在Linaro Developer Cloud下为Arm64支持的特定开源项目做出了贡献。

在Interoperability Challenge之后，一个不到五人的团队研究Newton版本，修复整个堆栈（内核、qemu、libvirt、OpenStack）上的bug并跟上新的OpenStack功能。对于我们使用的每个新版本，互操作的门槛都被提高：我们正在测试移动目标、互操作指南和OpenStack本身。

参与上游：Kolla

在Pike期间，我们决定用Kolla迁移到容器，而不是构建自己的容器。这意味着我们的容器可供其他人使用，从一开始就可以生产就绪。考虑到这一目标，我们加入了Kolla团队，并与已经构建的容器一起构建Arm64容器。我们的目标是修复脚本以支持多体系结构，并确保我们可以根据需要构建尽可能多的容器来运行生产云。Kolla构建了许多我们没有真正使用或在我们的基本设置上测试的容器，所以我们只启用了它们的一部分。Kolla团队认为我们的容器将基于Debian，因此我们将Debian支持添加到Kolla中（当时没有人负责维护它，因此有可能被弃用）。

Queens是我们可以用kolla-ansible安装的第一个版本。Rocky是第一个与其他OpenStack部署真正可互操作的产品。在Pike期间，由于缺乏测试人力，我们没有对象存储支持。在Queens期间，我们添加了这一支持，并作为UK Developer Cloud服务的一部分启用。

一旦Linaro拥有容器并使用kolla-ansible手册进行部署，我们就开始将Linaro Developer Cloud从Newton自建软件包迁移到基于Kolla的部署中。

作为上游Kolla工作的一部分，我们也测试了我们编写的代码。这是我们已经开始做的事情，但还有更多的工作需要完成。作为第一步，Linaro已在其China Cloud中为OpenStack-Infra提供可用性，而infra团队最有帮助的是在Arm64上提供所有工具。在与需要解决的其他OpenStack Foundation基础设施“交谈”时，此云存在连接挑战。与此同时，Linaro已授权OpenStack-Infra访问英国云。

英国Linaro Developer Cloud在Queens版本时就就可用于生产，后来升级为Rocky。这意味着它将是Linaro的第一个可与其他OpenStack云完全互操作的可用区域。其他区域将很快升级为基于Kolla的Rocky部署。

以下是我们想要强调的启用Arm64 OpenStack云所必需的一些变化：

•确保在UEFI模式下启动镜像

•能够使用NVRAM删除实例

•添加virtio-mmio支持

•添加图形控制台

•使PCIe端口的数量可配置

•启用Swift

•更新文档

我们还提供了其他一些不一定与架构相关但与Linaro Developer Cloud的日常运维相关的更改。例如，我们向Kolla添加了一些监控更改，以提高部署监控的能力。根据Stackalytics的数据，在Rocky版本中，Linaro是Kolla项目的第五个贡献者。

下一步是什么？

一旦Linaro Developer Cloud在OpenStack-Infra上完全正常运行，我们就能够为Arm64镜像添加门控作业并部署到Kolla门。目前这一工作正在进行中。与Infra达成的协议是，如果需要，任何想要在Arm64上运行的项目也可以在Linaro Developer Cloud上运行测试。这使OpenStack社区中的任何人都可以在Arm64上运行测试。Linaro仍在努力增加足够的容量，以便在高峰测试期间实现这一目标。

结论

这是一个有趣的旅程，特别是当工程师询问我们是否在Raspberry Pi上运行OpenStack时！我们的回答一直是：“我们在真正的服务器上运行OpenStack，包括IPMI、多个硬盘、合理的内存和Arm64 CPU！”

我们正在积极使用带有Cavium、HiSilicon、Qualcomm等处理器的服务器。我们还发现并修复了内核、服务器固件、libvirt中的bug，并添加了一些功能，如访客控制台。Libvirt在第三版时进行了多项架构改进（在过去的版本中，我们一直跟上libvirt，特别是在Arm64改进的时候）。要libvirt完全能够应对Arm64服务器和硬件配置，存在一些问题。我们正在研究堆栈中所需的所有缺失部分，以便在不同的供应商之间实时迁移。

与任何首次部署一样，我们在生产中运行Linaro Developer Cloud时发现Ceph和OpenStack存在问题，因为在测试云上运行测试并不等同于拥有一个长期存在的云，其中VM可以在主机重启和升级后继续运行。随后，我们不得不提高Arm64的可维护性和可调试性。在我们的18.06版本中（我们生成了一个Enterprise Reference Platform，为感兴趣的人提供了最新软件包的预览），我们在内核中添加了一些补丁，允许我们在出现问题时获得故障转移。

我们目前正在与OpenStack-Helm和LOCI团队合作，看看是否可以在Arm64上顺利部署Kubernetes。

如果你有兴趣在Arm64上运行你的项目，请与我们联系！

http://superuser.openstack.org/articles/arm-interop-openstack/

内容覆盖主流开源领域