再得中国第一 解读浪潮云海在OpenStack W版本的社区贡献

文章作者：浪潮云海OS技术研发团队张百林

“千淘万漉虽辛苦，吹尽狂沙始到金”。

经历十年磨炼，OpenStack成功吸引了来自世界范围内50多个国家、近200个不同组织中近万位开发人员的代码贡献，是金融、通信等多个重要领域上云的事实标准，在关键行业落地并承载核心生产业务。

浪潮作为OIF基金会的创始黄金会员，始终秉承“源于开源，馈于开源”的宗旨，多年来持续投入社区贡献。凭借着在代码提交数、完成蓝图数、补丁修复数等方面的突出表现，浪潮在社区最新发布的W版本中继续保持领先，继V版本以来社区贡献蝉联中国第一，成为OpenStack全球重要的技术引领者。

据悉，在新发布的W版本中，浪潮云海主要聚焦Nova、Cyborg、Manila、Ironic、关键中间件等核心项目，补足核心功能并进行大量的优化工作，有效提高了OpenStack的成熟度。
那么在这些核心项目中，浪潮云海究竟做了哪些重要的优化工作？具体来看！

「Cyborg优化」

作为智能硬件加速设备管理项目，通过采用Cyborg可以在云平台上方便使用GPU、vGPU、FPGA、SSD、SR-IOV等智能设备，有效优化加速设备（例如，GPU、vGPU、SR-IOV等）在Nova项目的配置复杂，使用不便以及难以运维等问题。

在最新发布的W版本中，浪潮云海OS技术团队在Cyborg项目引入了Inspur NVMe SSD 驱动，可以做到自动发现OpenStack平台上的Inspur NVMe SSD设备并自动上报到资源管理系统，用户在创建云主机时便可使用。

图1 Inspur NVMe SSD设备驱动实现原理

一直以来，浪潮云海OS研发团队都秉承用户至上的原则，从功能易用性和稳定性的角度开发支持了在线绑定/解绑硬件加速设备的功能，包括GPU、vGPU、Inspur NVMe SSD等加速设备，有效提升了操作的便捷性，降低了运维管理的难度，提高了 GPU、vGPU、NVMe SSD、FPGA等硬件加速设备的使用效率。

「Nova优化」

Nova项目作为OpenStack项目的核心模块，负责计算资源调度管理，例如云主机的创建、调度、生命周期管理等功能。早在U版本中已经实现了Nova和Cyborg的交互机制，支持在创建云主机时指定GPU、FPGA、NVMe SSD等加速器设备，以此来提升云主机图形图像处理、FPGA编程、IO读写的能力，同时也丰富了云主机设备使用的多样性。

“在最新的Wallaby版本中，我们完善了对绑定加速器设备云主机的操作，完成了对加速器云主机的搁置和取消搁置功能，弥补了加速器云主机的高级特性。如图2所示在搁置过程中，我们需要销毁云主机，同时释放加速器设备以提高加速器设备的利用率。”

图2 搁置加速器云主机实现原理

图3 取消搁置加速器云主机操作实现原理

如图3表示，在取消搁置过程恰恰与此相反，需重新调度物理主机，以获取满足加速器设备的物理主机，然后请求Cyborg创建加速器设备的映射关系，以重新绑定加速器设备。“我们还在持续完善加速器云主机的挂起/恢复、在线/离线迁移、调整配置等高级特性，以方便用户高效使用云平台的加速设备，持续贡献社区，让更多人受益。”

「Masakari优化」

Masakari项目是专注于OpenStack云平台高可用的开源项目，实现了云主机、关键进程和物理机三个不同层次的高可用，主要通过Monitor检测云主机、关键进程和物理主机的故障，一旦检测到故障，就触发故障恢复机制，恢复云主机和物理主机的重要业务。

浪潮云海OS研发团队则通过客户诉求、现场问题反馈等方式，有针对性的对Masakari项目进行深入研究和探讨，设计了针对云主机、关键进程和物理机等多层面故障检测、判断处理矩阵，能有效应对云平台可能触发的故障场景。

在最新的Wallaby版本，技术团队在主机状态检测机制的基础上进行创新，提出并实现了主机连续检测机制，通过检测主机的网络连接状态以确定主机是否故障，并设定故障节点云主机的疏散策略，增强了云平台的高可靠性。

图4中（左）为Masakari项目原故障检测机制，Monitor只探测一次，当云平台存在网络抖动时存在误判风险；图4（右）为改进后的故障检测机制，通过多次探测平滑预测物理主机的节点状态，管理员可设定Monitor探测阈值，仅当连续检测到节点故障时才会触发主机故障的高可用事件，提高主机故障检测的可靠性。

图4 主机状态连续检测实现机制

“同时我们还优化了计算节点高可用功能，支持对高可用集群设置禁用和启用状态。当对云平台进行维护时，运维人员可以将高可用集群置于维护模式中，而不必再对每台物理主机单独设置维护状态。”

「Memcached优化」

Memcached作为一套分布式的高速缓存系统，为OpenStack云平台提供数据缓存服务和高效的数据访问能力，有效减轻了数据库的访问压力，但是Memcached缺乏认证以及安全机制。对此浪潮云海OS研发团队针对Memcached提出了SASL（全称Simple Authentication and Security Layer，是一种用来扩充C/S模式验证能力的机制）认证机制，以弥补Memcached在OpenStack云平台数据缓存方面的不足，有效避免由于Memcached认证机制缺失造成其他客户端可以随意访问Memcached缓存数据的风险，提高OpenStack云平台数据访问的安全性。

其中SASL验证机制能够规范Client与Server之间的应答过程以及传输内容的编码， SASL验证架构决定服务器本身如何存储客户端的身份证书以及如何核验客户端提供的密码。如果客户端能成功通过验证，服务器端便能够确定用户的身份，以此来确保用户数据的安全性。

  如图5所示，浪潮云海OS研发团队通过在Oslo.cache和Keystonemiddleware中间组件中增加对SASL进行认证的客户端，并通过启用配置文件设置相应的用户名和密码，开启SASL的访问认证来提高Memcached缓存服务的安全性。

图5 基于SASL认证访问的Memcached实现

研发团队表示：“在大量应用及测试过程中，我们发现挂载云硬盘出现重复请求的问题，造成此问题的根本原因是在Nova项目中挂载云硬盘过程是分两部分来完成且缺少异步消息检测机制。”

如图6所示，社区原云硬盘挂载功能设计的核心思想是在Nova生成云主机和块设备的映射关系并记录数据库，然后执行挂载云硬盘的请求，通过Cinder完成云硬盘和云主机的映射关系，修改云硬盘状态；但此过程中容易出现挂载超时，云主机再次发送云硬盘挂载请求造成消息阻塞以至等待超时，导致云主机挂载云硬盘信息不一致的问题。

图6 开源社区云硬盘挂载流程   

如图7 ，浪潮云海OS研发团队针对上述云硬盘挂载逻辑进行优化，核心思想是取消第一次的RPC同步消息请求，整个云硬盘挂载流程中只保留一次RPC异步消息请求，将生成的块备映射表信息放到RPC异步消息处理流程中来处理，来保证连续挂载云硬盘操作的健壮性，有效提高云平台的高可用性和稳定性。

图7 优化之后的云硬盘挂载流程

「Ironic优化」

Ironic项目是当前开源社区最热的裸金属管理项目，浪潮云海OS研发团队在开发新特性贡献Ironic项目的同时，极力推动AEP（全称Apache Pass，Intel推出的一种新型的非易失Memory设备，是持久化内存的一种。）设备在Ironic项目上的适配。

如图8所示，团队通过研究裸金属CPU高级特性以及针对高级特性的裸金属调度实践并加以创新，适配新型的非易性失持久内存设备，弥补裸金属对持久性内存设备的支持能力，在Ironic开源社区以提交了相关议题及实现。

“在未来版本中，我们将持续贡献Ironic开源项目，将iSCSI/FC-SAN云硬盘挂载、裸金属RAID配置、裸金属检查定制化、多架构适配和裸金属智能网卡等高级特性贡献社区，造福更多用户和开源爱好者。”

图8 AEP设备裸金属验证环境拓扑

「Cinder优化」

众所周知Cinder项目为OpenStack云平台提供块存储服务，云硬盘快照作为一种数据快速备份的方式，但当前在Cinder社区并不支持对云硬盘中间时刻的快照进行回滚，只能做到对最近一次创建的快照进行回滚，这在一定程度上降低了快照回滚功能的易用性。

基于此如图9所示，浪潮云海OS研发团队通过对比多种存储，提炼了它们的公共特性，优化了云硬盘快照的恢复逻辑，在实现了任意快照回滚的同时确保了数据的安全性、快照功能的易用性。

图9 云硬盘自动快照实现原理

「Manila优化」

针对为OpenStack云平台提供文件存储服务的Manila项目，浪潮云海OS研发团队在最新的Wallaby版本中，在文件存储类型扩展规格中新增限制共享容量的特性。如图10所示，该特性通过使用键值对来限制文件存储创建、扩容、纳管操作的最大和最小容量，可适应更多的场景，能够为不同的用户提供个性化的服务，极大程度提高了云平台的安全性，提升了云平台的智能化运维能力。

图10 文件存储共享类型容量限制设计原理

总结一下，社区贡献引领的背后，除了具备强大的研发能力之外，还要求企业拥有丰富的实践积累。浪潮基于OpenStack开发的企业发行版，即浪潮云海OS，对开源版本进行了深度优化，建设了中国最大的金融生产云、亚洲最大的广电云，并联合国家相关行业信息化主管部门制定了云计算行业商用大规模上云标准、实践白皮书等。

浪潮信息副总裁张东表示，作为OIF基金会创始黄金会员，浪潮积极投入开源社区建设，尤其在Nova(计算)、Cinder（块存储）、Cyborg（硬件加速）、Masakari（高可靠）等核心项目中贡献突出，提升了开源版本的产品化能力，持续引领OpenStack不断走向成熟完善。