OpenStack计算节点高可用和物理机容灾调度初步调研

前言

为了调研容灾调度，搜到了腾讯云的这篇文章：2017 Openstack Days China | 腾讯的Openstack实践与创新

在这篇文章中，提到了腾讯在OpenStack应用落地中的创新点：

1. 支持虚拟机、容器和裸机管理。容器管理底层用的是内部自研的飞象系统（K8S+Docker）， 并集成Sriov 、Numa技术来为大型应用保驾护航，同时使用Ceph作为镜像、虚拟机、云硬盘的后端存储；异构平台的管理技术，将大量存量Xen虚拟机，完全无中断地纳管到TStack平台。
2. Nova在线资源限制技术，为保障平台的稳定性，需要对虚拟机进行资源限制， OpenStack原生是利用Flavor来实现，由于和Flavor绑定，无法针对虚拟机来进行限速策略，不符合内部业务需求， 因此腾讯开发了在线虚拟机资源限制技术， 在系统高峰时期启用限速策略，非高峰时期解除，从而使得中间业务不中断，实时生效；
3. 定制基于业务类型的虚拟机调度策略，根据业务类型，将虚拟机调度的到不同宿主机，实现高可用；
4. 自动化容灾设计，为了避免业务监控的不准确，采用计算节点分布式心跳，从业务网，管理网，带外网等进行多维度监控，故障出现自动迁移，无需人工干预；
5. 虚拟机迁移植入动态自适应压缩迁移技术，节省了带宽，迁移时间平均缩短50%；
6. Ceph底层开启压缩存储，对象存储性能平均提升43%，日志存储性能提升110%,此特性比社区早一年推出，功能更强大；

在这本篇文章中，给我们三个启发：

1. 虚机调度策略是要基于业务类型，即需要产品和研发一起定制策略，如什么是大客户专区，完全预留计算节点并单独划分AZ，还是可使用更低的超配比进行资源共享等。
2. 自动化的容灾设计，在多维度监控的基础上，进行故障下的自动迁移，无需人工干预——这正是我们需要有的东西，与物理机容灾调度大有相关。
3. 对虚机迁移和Ceph底层开启压缩技术，节省贷款、存储性能等。

物理机容灾调度

这里的物理机容灾调度是指计算节点所在的物理机由于宕机、负载压力过大或者各种网络抖动、延迟等影响服务正常可用的因素时，能够将该物理机（宿主机）上的虚机自动/手动迁移到可用的节点上。也可以理解为计算节点的高可用。说白了就两件事：

1. 容灾恢复
2. 平衡计算节点压力

注：高可用和容灾，粗略来说不区分彼此亦无不可。高可用（High Available），目的维持业务周期内的更长的运行时间；容灾（Disaster Recovery），字面意思是灾难恢复，指的是保障灾难情况下系统和业务的正常运行。如果需要更好地细分和理解，那么高可用注重的是维持业务在周期内更长的可运行时间，而容灾注重的是极端情况下的业务恢复。

目前了解到这边的做法是基于zabbix做监控，但是没有办法做到自动迁移，只有出现问题的时候，由运维手动迁移（evacuate、live-migration）。这就出现了第一个痛点：需要实现基于监控的自动化容灾调度，主要包含两部分内容：

1. 如何实现自动化
2. 如何使迁移调度精准

实现自动化容灾的方式，咨询了运维同事，之前的经验是通过Python脚本实现，但是很容易遇到上面的第二个问题，因为影响因素比较多，有时候可能网络因素占大多数，脚本很容易误判，造成虚拟机在各个节点之间飘来飘去。所以需要综合各种监控，正如腾讯的做法，采用计算节点分布式心跳，从业务网，管理网，带外网等进行多维度监控。

如果要做自动化容灾的方式，IMHO，如果没有更好的工具，出路必定是自研的方式：

1. 结合各种带外工具，梳理目前各项监控指标，构造监控模型，不限于宕机检测、网络延迟检测等
2. 选择实现方式：Python脚本或者单独的功能系统
3. 分析、设计及开发

OpenStack目前的容灾/高可用手段

首先，先来看下OpenStack中目前提供的一些容灾和高可用手段。

Evacuate

如果因为硬件故障或者其他错误导致计算节点宕机，可以通过evacuate使节点上的虚拟机再次可用。

# nova help evacuate
usage: nova evacuate [--password <password>] [--force] <server> [<host>]

Evacuate server from failed host.

Positional arguments:
  <server>               Name or ID of server.
  <host>                 Name or ID of the target host. If no host is
                         specified, the scheduler will choose one.

Optional arguments:
  --password <password>  Set the provided admin password on the evacuated
                         server. Not applicable if the server is on shared
                         storage.
  --force                Force to not verify the scheduler if a host is
                         provided. (Supported by API versions '2.29' -
                         '2.latest')

在执行evacuate时，可以指定目标节点，如果不指定，则scheduler会为我们选择一个。 为了保留用户数据，需要在目标节点上配置共享存储。在执行evacuate时，计算服务会检测在目标节点上贡献存储是否可用。另外，必须要校验当前虚机所在的宿主节点是不可操作的，否则疏散失败。

我们来看下代码的调用关系：

->nova.api.openstack.compute.evacuate.EvacuateController#_evacuate
 ->nova.compute.api.API#evacuate
  ->nova.conductor.api.ComputeTaskAPI#rebuild_instance
   ->nova.conductor.rpcapi.ComputeTaskAPI#rebuild_instance
    ->nova.conductor.manager.ComputeTaskManager#rebuild_instance
     ->nova.compute.rpcapi.ComputeAPI#rebuild_instance
      ->nova.compute.manager.ComputeManager#rebuild_instance

可以看到evacuate实际上会触发的是rebuild_instance的操作。

Migrate

migrate，迁移，或称为“冷迁移”，是将虚拟机从一个计算节点移动到其他计算节点上，迁移过程中需要虚机处于关机状态。所以，IMHO，相比于热迁移，冷迁移的使用频次应该不会很多，多数会在机房迁移、断电迁移等公告通知用户的情形下。

其调用关系如下：

->nova.api.openstack.compute.migrate_server.MigrateServerController#_migrate
 ->nova.compute.api.API#resize
  ->nova.conductor.api.ComputeTaskAPI#resize_instance
   ->nova.conductor.rpcapi.ComputeTaskAPI#migrate_server
    ->nova.conductor.manager.ComputeTaskManager#migrate_server
     ->nova.conductor.manager.ComputeTaskManager#_cold_migrate
      ->nova.conductor.tasks.migrate.MigrationTask#_execute
       ->nova.compute.rpcapi.ComputeAPI#prep_resize
        ->nova.compute.manager.ComputeManager#prep_resize
         ->nova.compute.manager.ComputeManager#_prep_resize
          ->nova.compute.rpcapi.ComputeAPI#resize_instance
           ->nova.compute.manager.ComputeManager#resize_instance

可以看到冷迁移是调用了resize_instance的操作，即一个没有flavor变化的resize操作。

详细解析，可参见：OpenStack Nova虚拟机冷迁移流程解析。

Live migrate

live migrate，又称为在线迁移，热迁移。即虚拟机保存/恢复(Save/Restore)——将整个虚拟机的运行状态完整保存下来，同时可以快速的恢复到原有硬件平台甚至是不同硬件平台上。恢复以后，虚拟机仍旧平滑运行，用户不会察觉到任何差异。在我看来，热迁移可以非常灵活的用在平衡计算节点压力上，比如某几个计算节点上的虚机太多，负载和压力过高，可以使用热迁移在用户无感知的情况下降虚机迁走。不过换个角度讲，这种处理本身就是很灵活的一件事情，灵活就意味着有很多潜在的风险，比如造成系统的“雪崩”。

其调用关系，后面会有单独的文章进行梳理。

->nova.api.openstack.compute.migrate_server.MigrateServerController#_migrate_live
 ->...
  ->nova.compute.manager.ComputeManager#live_migration
   ->...

以上就是OpenStack提供的迁移、疏散相关的方法，容灾和高可用的方案说白了就是如何合理的使用这些方法，我们可以参考一下业内大厂的一些做法。

业内大厂的容灾/HA方案

红帽：Red Hat OpenStack Platform 10 High Availability for_Compute Instances en US

ZTE：虚拟机自动上电、自愈、重生是怎么触发的

CMCC：CMCC计算节点高可用程序详细设计v1.0.pdf

参考

[1].Live-migrate instances
[2].Configure live migrations
[3].Evacuate instances
[4].OpenStack热迁移和冷迁移
[5].OpenStack Nova虚拟机冷迁移流程解析