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/

内容覆盖主流开源领域

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180927A09VEF00?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码关注腾讯云开发者

领取腾讯云代金券