CloudStack 4.3功能前瞻-InfoQ

抖音技术能力大揭密！钜惠大礼、深度体验，尽在火山引擎增长沙龙，就等你来！立即报名>> 了解详情 



 写点什么

本则新闻由 CloudStack Committer 李学辉撰写，CloudStack 中国社区的白清杰推荐，最初发布于 CloudStack 中国社区官方博客。CloudStack 最早是由 VMOps 公司开发的开源虚拟化环境管理软件，之后该公司被思杰收购。2012 年 4 月，思杰决定将 CloudStack 贡献给 Apache 软件基金会，成为 Apache 孵化项目之一。现在，CloudStack 常被作为 IT 基础架构的综合管理系统用于搭建企业内部的私有云。

CloudStack 4.3 已经 Feature Freeze 了，不会再有新功能加入到这个版本里。我们也可以坐下来看看哪些功能是值得期待的。首先，4.3 的 UI 也秉承扁平化设计，看着更加简洁清爽。见下图：

接下来我们从 CloudStack4.3 的设计文档出发，来了解一下这个版本的功能有哪些。

1. 数据库的高可用性

当前 CloudStack 的数据库的备份方案基本上是使用 Mysql 的 backup-standby 方案，同时只会有一个 DB 是激活状态，如果遇到问题，需要切换到备份服务器，主数据库的稳定性尤其重要。而数据库的高可用则是想达到“双活”的数据库群集效应，也就是同时有多个数据库是主控的。在经过一系列调研后，从 MariaDB, Percona Xtra DB, SkySql 和 Mysql 中选择使用 Mysql 的双活设置。Mysql 的双向复制需要在连接器上配置在 Mysql 集群中主控服务器宕机后，从 Slave 服务器上读写数据，因此相应的管理端的程序要做相应改变。

由于数据库相对稳定，并且当前大多数部署规模单节点数据库服务器的 I/O 都足够应付，而数据库的备份也有相应方案避免数据丢失，新的数据库 HA 在公有云或企业内部私有云上都会有需求，不过这会增加管理服务器的复杂性，所以我认为这个功能期待指数三星半。

2. 动态调整计算资源方案

我经常被问到一个事情：从模板创建的虚机能否将系统盘（根卷）进行扩展？之前的回答也一直是不可以。在 4.3 中，用户创建虚机时不仅可以对根卷进行扩展，还能指定任意的 CPU 和内存的数量，这比从管理员提前预置的计算方案里选择要灵活的多，这个功能不管是在私有云还是公有云都有广泛的需求。中国用户也特别喜欢类似阿里云的根据一定的步长任意设置各种资源的公有云自服务门户。不过从设计文档来看，网络带宽还没法任意设置，估计要等以后版本了。

这个功能很适用，尤其是扩充根卷，这样在制作模板的时候就可以尽可能地小了，当然任意指定 CPU 和内存也是相当受欢迎的，综合评定这个功能很期待。

3. 客户虚机支持 GPU/vGPU

现在的物理服务器都有强大的显卡，特别是一些图形工作站的机器，甚至比 CPU 的计算能力还强，因此，如果可以利用显卡的 GPU 进行计算，那将会极大的提高资源的利用率。另一方面，很多应用对于显示的要求都比较高，比如 PhotoShop，AutoCAD 以及一些 3D 游戏等，这些应用很多也都可以在虚机里运行，只是很难达到物理机上的效果。为了使性能有所提升，让虚机跳过 Hypervisor 直连 GPU 是个不错的想法。

GPU 也属于计算资源，它不像 CPU 那样，可以超配；也就是说一个拥有 4 个 GPU 模块的主机，同时只能为其上的 4 个虚机提供 GPU 直连服务。另外，GPU 编程还是比较复杂的，这里需要 Hypervisor 的支持，此功能目前在设计里也只会支持 XenServer。要使用的朋友还是要特别留意一下。如果考虑 CloudStack 本身的服务器虚拟化而非桌面虚拟化的特性，这种应用上的需求应该不是很广泛。

4. Hyper-V Server 2012 的支持

Hyper-V 是微软的虚拟化技术，记得早在 CloudStack4.0 版本时期就是要支持 Hyper-V，根据国内 Hyper-V 的市场占有情况，这个功能在当时也是非常期待的。但开源就是这样，由于种种原因，这个功能一直到 4.2 版本里也没能支持。在解决了集成 API 的许可问题后，目前来看 4.3 是很有可能支持 Hyper-V 了。

CloudStack 对于 Hyper-V 的支持将会采用与 KVM Agent 类似的方式，通过 WMI 来与 Hyper-V 主机通信，从而控制虚拟机。应该来说新的 Hypervisor 的支持都是一个很大的功能模块，它要考虑整个云平台各 Hypervisor 的能用功能，还要考虑各个 Hypervisor 自身的功能特点，这包括网络和存储的功能及硬件的支持。不管怎么说，如果 CloudStack 能支持 Hyper-V 并稳定运行，那对于它自己无疑是个巨大的加分。相信很多基于 CloudStack 的 ISV 都在等待这个功能。

5. KVM 支持 Linux 本地 VxLAN

CloudStack 中高级资源域通常使用 VLAN 进行隔离（虽然 4.2 版本以后也支持安全组）；VLAN 的硬伤是协议本身的限制：<=4095 的 VLAN ID。那么当为了隔离每个账户使用一个 VLAN ID 时，一个资源域最多的账户数就有极大的限制；而实际上你能使用的 VLAN ID 要远小于 4095，因为如果真的配置交换机 4095 个 VLAN，那它将疲于奔命。一般情况下，一个数据中心等同于一个资源域，可想而知，大规模部署 VLAN 的限制问题将会显现。VxLAN 就是在这个背景下应运而生的。你可以认为 VxLAN 是 VLAN 在二层的基础上对报文进行 UDP 的封装；它最多可支持超过 1600 万个隔离网络，这在一个数据中心里应该是足够用了。由于 NTT 一直在使用 CloudStack，他们这种规模的公司对于 VxLAN 是有迫切的需求的，因此他们的工程师完成了 VxLAN 的功能并贡献给 Apache 社区。其功能的实现上也于 VLAN 相似。在添加资源域时网络设置使用 VXLAN 隔离来宾网络，在设置来宾网络 vNet（相当于 VLAN ID）范围时，也不用考虑 4095 的限制。

由于这个功能是 CloudStack 的一个功能，它不依赖于像 Nexus 1000v 这样支持 VxLAN 的设备，所以这个功能需要 Hypervisor 的支持。CloudStack4.3 只会先针对 KVM 的 Hypervisor 支持这个功能，并且 Linux 的 Kernel 版本要高于 3.7；在配置 KVM 主机是要使用 Linux 本地的 Birdge 而非 Open vSwitch。由于这些限制，这些功能在 4.3 里使用应该还是有点复杂度，给四星。

6. 增强的系统虚拟机升级策略

系统虚拟机在 CloudStack 里扮演重要角色，从功能上讲，系统虚拟机分成二级存储系统虚机，控制台系统虚机以及虚拟路由器；它们分别用来完成模板、镜像、ISO 的下载，基于 Web 的虚机控制台和客户虚机的网络功能。对于不同的 Hypervisor，系统虚机的模板不同，但同一个模板可以配置成不同的角色来完成上述三种虚机的功能。如果是小规模的部署，由于系统虚机无状态的特性，可以上传新的模板，破坏掉当前的系统虚拟机，它会自动重建。当然整个过程不仅较慢，且问题时有发生；也没有很好的指导文档或常见问题说明。试想大型生产环境里更新系统虚机特别是虚拟路由器还是挺有风险的，因为用户的服务会中断，不是逼不得已不会有人想这么做。4.3 里将提供新的 API 用于系统虚机模板的升级，你只要提供相应的信息，要升级的资源域，等信息即可。

由于本身系统虚机是一个相对稳定的单位，从以往来看 CloudStack 的升级伴随需要系统虚机的升级并不多（4.0 到 4.2 之间的变化需要升级系统虚机），这个功能应该不会有太多人用到。评定三星半。

7. 重构测试框架 Marvin

如果大家知道 Apache CloudStack 的吉祥物：踩在云中的猴子，知道 Cloudmonkey；那么对于 Marvin 应该不陌生。Cloudmonkey 强大的功能是基于 Marvin 实现的，Marvin 是 CloudStack 里用 Python 实现的测试框架，包括完整的 API 封装并完成相应的单元测试。这个功能的重构与稍后提到的 Spring 模块化相关。对于 API 的测试是整个框架的核心，新的设计将采用 XML/JSON 的方式定义 API 的发送和响应，针对每个 API，可以用单独的一组发送 / 接收脚本处理，这也体现的模块化的思想。另外一个功能是异常和断言，计划使用 DSL 的形式，由于本人对 DSL 不了解，无法给出更详细的说明，感兴趣的朋友可以在 wiki 上查找一下：Domain Specification Language。不从事 CloudStack 开发的人对这部分内容可以忽略。

8. 迁移 NFS 二级存储到对象存储上

在 CloudStack4.2 上已经支持使用对象存储 Amazon S3 或 OpenStack Swift 作为二级存储，对整个云环境提供模板，快照和 ISO 的服务。CloudStack 在设计上也尽量保证与 Amazon EC2/S3 在 API 上的兼容，以便企业客户可以无缝地从 Amazon 转到 CloudStack。但是当时缺少一个方便的功能：如何将现有客户环境从 NFS 二级存储迁到对象存储上。这个功能的基本思路是 NFS 二级存储与对象存储共同存在，新的资源（包括快照，模板等）都会在对象存储上创建；只有读和删除操作会在 NFS 二级存储中执行，模板，卷的复制也只会在对象存储上，这样就保证二级存储在资源域的范围内，而对象存储是整个云环境。这样，存储在对象存储的模板，快照等，将不需要跨资源域的复制功能。

国内对于 Amazon 的使用并不普遍，对象存储目前也都是在试水阶段，用户使用对象存储的话要单独配置。在 4.3 里，并没有提供将 NFS 二级存储的所有内容迁移到对象存储的功能，也就是说，用户还是需要乃至 NFS 的二级存储。对于很大规模的部署，可以考虑一下，对于小规模的建议还是不要等待这个功能。

9. 模块化 Spring 标准框架的使用

如果最一开始 CloudStack 广受争议的是其模块耦合度太高，新手难以开发，那从 4.1 到 4.2，CloudStack 在努力做出改变，而 4.3 上面改的更彻底，要添加新的插件或 API 也非常容易上手，只要对 Spring 框架熟悉，你对整个启动和初始化过程会很快上手。而国内熟悉 SSH 的是相当庞大的一群人，CloudStack 采用标准化框架会使更多人聚拢在其周围。这一框架的调整带来很多开发的便利，何乐而不为呢？唯一的问题是基于之前 CloudStack 版本（4.0 版本或更早）的 ISV，如果维护自己的版本，那代码合并的工作量挺大。我稍后也会专门写一篇文章来看下如何在 CloudStack4.3 上开发一个新的 API。

10. 监测虚拟路由器的状态

前面提到的系统虚拟机的升级实际上可以包含这个功能，我们知道虚拟路由器上很多进程在提供各种各样的服务：dnsmasq 用于 DHCP，haproxy 用于 LB，Apache Web 服务器，sshd 等。这些服务的监测可以保证：1、实时检测服务的状态；2、收集告警回送给接收器，通常是管理服务器。这些监控软件在发现服务进程异常时不仅会发送告警给管理端，还会根据设置对服务进程进行重启操作，并且这些都会在事件服务器里记录。相信以后遇到虚拟路由器的问题会大大减少。

11. VPC 里的 VPN 远程访问

在 4.2 及之前的版本里，虚拟路由器一直提供用户远程 VPN 的接入操作，在 4.3 里，使用 VPC 网络的用户也可以远程接入 VPC 的虚拟路由器，然后设置网络 ACL 来控制接入的用户对 VPC 里某些网络分层（Network Tier）或所有的网络层的虚机进行访问。

12. 报告物理 CPU 个数

如果你注意到最开始提供的仪表板截图出现的“Sockets”，那就是指云环境里物理 CPU 个数的指标。这是一个比较小的功能增强，相信以后每个版本都会丰富这些统计数据。像这样的统计功能，当然是多多益善了。

13. 虚拟路由器站到站的 VPN 连接

从设计上来看，这个功能是针对 VPC 网络的；站到站的 VPN，即 Site-to-Site VPN，这个功能在两个 VPC 网络上使用是极其便利的，它可以在任何两个 VPC 环境中设置，而不是限定在一个数据中心或一个区域，甚至是一个云平台中。参见下图，注意左下角的 SITE-TO-SITE VPNS: