在OpenStack大家庭中，Nova是最年长的成员。从OpenStack诞生之日起，Nova这一OpenStack计算项目开始存在并发展。在OpenStack项目中，Nova是一个成熟而复杂的项目，而伴随着整个OpenStack技术框架日趋成熟，Nova的稳定性和采纳程度都在持续攀升。如果您一直关注Nova项目的发展，就会发现它一直处在不断演进的状态。作为OpenStack大家庭中最为成熟、应用最为广泛的子项目，Nova正在不断演化出新的功能和应用方式。

在Nova的诸多改进与优化中，除了之前介绍过的Nova Cells V2这一具有重大意义的创新功能外，在Mitaka版本中，Nova项目在虚拟机热迁移和调度功能方面也完成了新一轮的功能演进。

虚拟机热迁移

对于绝大多数的OpenStack用户来说，虚拟机热迁移都是一个经常会用到且重要的功能。如果我们对系统进行扩容，或者是有一些机器出现了问题需要进行维护，我们都需要对宿主机进行关机。这些宿主机通常运行着用户的虚拟机，其上很可能运行着客户的业务，在这种情况下，突然关闭宿主机对于用户来说是很难接受的。

而借助热迁移（Live Migration）的功能，我们在进行扩容或者运维操作时就会方便很多。热迁移不影响虚拟机内运行的业务，中断时间也非常短，对于用户的业务来说基本上是透明和无感知的。除了系统维护，我们通常还需要进行服务器的升级操作。特别是在升级宿主机的内核时，很多时候需要进行关机加内存的操作，这些都离不开热迁移的操作。

在于2016年4月发布的Mitaka版本中，OpenStack社区对于虚拟机热迁移进行的改进主要包括4个方面：

1. 提高了迁移的成功率

这方面社区进行的改进主要是提高了Libvirt和qemu的版本，同时改进了出错的回滚方法，确保了热迁移操作成功率的提升。

2. 易用性增强

在Liberty版本中，我们看到了许多有关热迁移的Commits，而在Mitaka版本中社区仍然进行了非常多的改进和优化。最大改进来自于热迁移的接口越来越简单，不需要输入太多的参数，输入简单的命令就可以完成。这些简化主要来自两个方面，第一是命令行参数的简化，第二是对API参数的简化。Nova项目通过一些新的逻辑，可以由Nova自行判断底层是否使用了共享存储、是否需要对系统盘做迁移。整个过程中，Nova的原则是尽可能地去自动判断，能够自动判断就不让用户输入相关的参数。

3. 提高可管理性

以前虚拟机的热迁移对于用户来说基本上是不可控和不透明的。你可以想象这样的一种场景，就好比你发动了一辆汽车，然后你从这辆车上下来，让汽车自己开向不知道的地方，这是怎样的一种体验？而在Mitaka版本之前，虚拟机的热迁移就是这样，我们不知道也无法确认迁移到底有没有出问题，以及什么时候能够完成，迁移的进度如何。

在Mitaka版本中，热迁移的功能进行了非常大的改进。首先，我们现在可以通过以下的命令查看迁移的进度了。

# nova server-migration-show <server id> <migration id>

通过这个命令，我们可以看到需要拷贝是数据是多少，拷贝了多少数据，还有多少数据没有拷贝。

Mitaka版本还提供了中止正在进行迁移的命令。如果你觉得迁移的时间过程，或者需要取消目前进行的迁移操作，都可以通过以下这个命令取消迁移。迁移操作取消后，它仍然在原来的节点上运行，不会影响到虚拟机的状态，后续如果你想继续迁移，可以再通过触发这个命令来执行迁移。

# nova server-migration-abort <server id> <migration id>

在某些情况下，你的期望是让虚拟机的迁移尽快结束。默认的迁移操作会做内存拷贝，如果你在原节点上，内存刷新率会很高，这个速率甚至会超过你的网络传输速率，这样的迁移操作是永远不会结束的。这时候要想加快迁移的速度，可以执行以下的命令，它会强制让原节点的虚拟机处于暂停的状态，这样只需要将其内存的数据拷贝到目的节点，然后再进行控制切换，就能够完成迁移操作了。对于运维人员来说，这个命令的非常有帮助的。在迁移时间过长，甚至是执行很长时间仍然没有结束的情况下，可以通过这一命令加速迁移的进度。

# nova server-migration-force-complete <server id> <migration id>

4. 使用专用的网络

在Mitaka版本中，热迁移操作可以将迁移的流量放置在专用的网络中。在此之前，如果没有指定，迁移操作主要依赖于你的Hostname的解析。默认情况下，如果是利用Libvirt+QEMU的方式，Libvirt会通过你的Hostname进行解析，找到目的节点，然后通过这个网络进行内存数据的拷贝。而通常情况下，为了便于管理，需要把Hostname的地址映射为管理网络的地址。这样造成的后果就是迁移的速度会非常慢。而借助这个新的特性，你可以通过如下的选项配置热迁移使用的网络，将迁移部分的流量切换到另一个速度更快的网络，从而保证迁移操作能够以更快的速度完成。

live_migration_inbound_addr: Live migration target ip or hostname

而除了以上我们提到的优化，在Mitaka版本中，OpenStack社区还进行很多新的、有益的探索。这里我们重点来谈谈虚拟机热迁移的拷贝功能。通常情况下，我们都是使用Pre Copy的方案。也就是说，在另外一个节点运行虚拟机之前，先需要做内存同步、磁盘同步，以及其他的资源同步操作，然后将两边的虚拟机暂停，将有差别的资源从原节点拷贝到目的节点进行切换，然后在目的节点启动虚拟机。这样做的迁移时间会比较长，具体的时间很难预计，因为与虚拟机中运行的应用、内存的刷新率、底层的数据同步网络都有关系。

针对这样的问题，QEMU提出了Post Copy的迁移方案。也就是说先把虚拟机迁移过去，先运行起来。如果要访问一些资源，比如数据，再从原节点把数据拷贝过来。这样做的优势在于，可以确保迁移在可控的时间内完成。但也会遇到一些问题，比如在新节点运行的应用，当虚拟机读取内存时，如果还没有拷贝过来，那么从原节点拷贝数据就会影响内存读取的速度，虚拟机的速度会受影响。而当迁移失败的情况发生时，你可能需要重启整个虚拟机。目前社区正在考虑支持Post Copy这一新的迁移方式，并且对其进行优化。

Nova Scheduler（调度）

如果大家长期关注Nova Scheduler（调度）服务的话，就会发现在近期的几个版本中，一直都在进行小的变更。这些变更主要涉及两个方面，即性能优化和架构的调整。

性能优化方面，目前有哪些因素制约着Nova Scheduler服务的性能呢？Nova Cells功能在设计时预想的部署规模为上千个物理节点。如此大规模的部署对于Nova Scheduler而言会形成非常大的性能瓶颈。在奥斯汀OpenStack Summit上，我们看到了许多与Nova Scheduler性能优化相关的话题。

现阶段，Nova Scheduler的性能瓶颈主要体现在，它每做一个决定，或者说每创建一个虚拟机的时候，都需要为虚拟机选择一个Host，而选择Host时都需要去读取数据库，这就是性能瓶颈的来源。有人做过一些模拟测试，如果对数据库的性能进行优化，Nova Scheduler的响应速度可以成倍提升。

那么如何优化Nova Scheduler的性能呢？

第一个方案就是给Nova Scheduler增加缓存，通过缓存来解决频繁访问数据库的问题。另一个方案是实现shared-state调度。通过这种方式来保证Nova Scheduler实例能够共享HostState信息，确保Nova Scheduler能够拥有全局信息，同时每一个Nova Scheduler服务都会从这种全局信息中拷贝一份，周期性地去获取这一共享信息。这样一来，我们不需要像以前那样，每一个服务直接去访问数据库，避免了相关的性能损耗。在Newton版本中，OpenStack社区正在积极展开Nova Scheduler性能优化的探索。

架构调整是Nova Scheduler近期变更的另一个重要方向。我们发现，在之前的几个版本中，Nova Scheduler的功能相对比较丰富。但是随着这一服务的不断演进，Nova Scheduler的功能却变得越来越单一。它目前只专注于一件事情，就是进行虚拟机的调度，其他的工作都交由nova-conductor来跟进和操作。

OpenStack社区近期的思路是，将Nova Scheduler抽象成一个独立的服务持续推进，明确Scheduler对外的服务接口，弱化各个服务对Scheduler的依赖和关联，同时把原来基于RPC的请求转变为基于REST API的服务。这样一来，能够很好地与Nova的现有代码进行解耦，并且将Nova Scheduler作为一个独立的服务来运行。此外，社区也开始在计算节点引入Resource Provider以便更好地跟踪资源分配情况。

演讲者简介：

刘家军，UnitedStack有云创始工程师、Nova组PTL，从2012年开始接触OpenStack项目，深度关注和研究的项目包括Nova、Neutron、Ironic等，同时拥有Puppet运维经验。目前主要专注于Nova研发方向，同时参与OpenStack集群架构设计的相关工作。

编者注：本文根据UnitedStack有云Nova PTL刘家军在2016年5月29日的“奔跑吧，OpenStack！——UnitedStack与您面对面·深圳站·奥斯汀分享专场”上的演讲整理而成。