gushiren

  博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

前言

为了调研容灾调度,搜到了腾讯云的这篇文章: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虚拟机冷迁移流程解析

posted on 2018-09-05 16:36  gushiren  阅读(134)  评论(0编辑  收藏  举报