OpenStack Karbor介绍

作者: 大老三 | 来源:发表于2019-03-18 17:30 被阅读0次

1. Karbor项目简介

Karbor在Newton版本被纳入OpenStack的官方项目，其目的主要是为了解决虚拟机备份难、无标准备份接口的现状。致力于制定OpenStack数据保护服务的接口标准，让多种数据保护软件通过标准接口接入OpenStack，为OpenStack所纳管的资源提供增强的备份、复制、迁移等数据保护服务（Data Protection as a Service）能力。
Karbor以插件方式集成数据保护软件，所集成的数据保护软件，可以是商业备份软件，如爱数、NBU等；也可以是OpenStack提供的原生数据保护能力接口，如Cinder Backup API，Snapshot等。

2. 可保护的资源

OpenStack云环境中的用户业务，如Web、App(基础应用)以及DB（数据库）等，都是用户需要保护的资源对象。其映射到OpenStack中的资源为虚拟机、网络拓扑、卷、镜像以及各种资源之间的依赖关系等。所以为了保护好图中所示的应用层资源，Karbor必须保护好上述所有OpenStack相关资源。

可保护资源视图

Karbor可以保护的资源类型，是由定义在Karbor中的Plugin引擎来定义，Plugin引擎会加载各种资源保护时所需的Plugin，通过创建保护计划来保护相关资源。可保护资源如下。
 卷：映射到虚拟机上的可进行读写的数据存储载体或设备。
 虚拟机：由元数据、配置、描述及相关依赖组成的业务部署单元。
 镜像：虚拟启动镜像或软件包。
 虚拟网络：虚拟机运行的通信网络。
 租户：一组虚拟机和相关卷、镜像、网络等资源组成的整体。

3. Karbor架构

Karbor从技术架构上来看，主要分为四个部分：API Service，Operation Engine Service,Protection Service， RPC。

技术结构图

3.1 API Service

该模块的目的是：提供标准北向API，以最大的灵活性，为任意一种资源提供任意的策略保护。API模块按照功能来分，主要包括以下部分：

API功能结构图

3.1.1 Resource(Protectable) API

查询可保护哪种资源的，解决可以保护（备份）哪些资源的问题。用户通过访问此接口，可以知道哪些资源类型可以被Karbor保护。并且可以获取每一种资源类型的附加信息，如虚拟机列表以及依赖。
其中，可保护哪些类型资源，是管理员在进行Karbor部署时，基于备份插件的实际能力进行配置。

protectable-list.png

每一种资源类型，都对应有可保护的资源列表，以卷类型为例：

protectable-list-instance.png

3.1.2 Protection Plan API

制定保护计划，解决如何保护（备份）问题。用户可以通过Plan API，注册保护计划，并进行Plan CRUD操作。可以对注册的Plan执行开始、挂起动作。
创建保护（备份）计划，必须指定对应的Provider，以及要进行保护的资源类型及资源实例。

3.1.3 Provider API

解决将资源保护（备份）到哪里，以及保护哪种资源的问题。
其中Protection Plugins & Bank部分的，提供查询系统中可用的保护机制，以及其对应的后端存储。

providers.png

图中的几个备份Provider分别对应：基于本地文件存储提供基础保护机制、基于S3对象存储接口提供的基础保护机制、系统默认的保护机制（对应Swift后端、Cinder Snapshot等）、K8S保护机制。
Checkpoint API则是说明哪些资源被保护了。创建Checkpoint，依托于已创建的保护（备份）计划，及使用的Provider。当一个新的Checkpoint被创建后，对应的保护（备份）动作就会被触发，当Checkpoint的状态变为可用状态后，说明对应的备份副本已经被创建成功。

3.1.4 Schedule Operation API

自定义保护策略，解决何时执行保护（备份）动作的问题。通过该接口可以创建触发器，并基于此触发器、保护计划以及Provider来创建指定资源的保护策略。
目前Karbor支持两种时间格式的触发器：Crontab格式及Calendar（日历）模式。

3.1.5 Restoration API

从已创建的备份或副本中，恢复被保护的资源。

3.2 Operation Engine Service

负责调度或编排Protection plan的执行，基于标准北向接口对接，可以被其他外部方案替代。
提供两种触发引擎：时间类型和事件类型，现在的实现主要是基于时间类型，支持Crontab及Canlendar格式。
同时，Karbor支持滚动式保护（备份）策略，可以指定最大的备份数，及间隔周期。当数据副本数，达到指定的最大备份数时，会自动删除最老的备份。

3.3 Protection Service

负责保护（备份）动作的执行以及Protection Provider的管理。
主要包括Workflow Engine，是一个任务流执行框架，定义了标准的任务执行机制；Protection Plugin，定义了执行具体保护（备份）操作时的逻辑流程；Protectable Plugin，定义可保护资源的依赖关系；Bank Plugin，定义了备份元数据及实体数据的存储后端。

3.4 RPC

与其他OpenStack组件相同，Karbor各个组件之间，通过RPC消息进行相互调用。

4 备份恢复流程

基于Karbor进行OpenStack资源的整体逻辑关系如图。

整体流程.png
其中，DB用来存储包括Quota、Plan、Trigger、Scheduler Operation、Operation LOG以及Service等信息。Bank部分默认采用Swift，可支持自定义Bank（目前已支持S3，File），主要用来存储Checkpoint信息。创建Checkpoint所产生的实际数据，则依赖于所采用的Plugin，或存储在Bank中，或存储在Plugin对应的后端存储系统中（如采用Cinder Backup时，会将备份存储在Cinder Backup对应的后端存储上）。
自定义备份任务、任务调度策略、依赖资源解析策略对所有资源都适用，本文档会挑选指定的资源进行说明。

4.1 卷备份

目前Karbor支持4种备份插件来进行卷数据的备份：Cinder Backup、Cinder Volume Snapshot、Freezer、Glance。

4.1.1 自定义备份任务

4.1.1.1 创建备份plan

karbor plan-create <plan-name> <provider-id> <resource-id>=<resource-type> =<name>

plan-create.png
创建完成后，Karbor会在数据库中增加一条plan记录，此时plan并不会被触发执行，所以是suspended状态。

4.1.1.2 创建触发器

karbor trigger-create <trigger-name> <type> pattern=<pattern>,format=<format>

trigger-create.png
命令表示，创建一个每间隔5分钟执行一次的触发器。
创建完成后，Karbor会在triggers表中，增加一条数据库记录。Operation Engine模块，会自动算出该trigger下一次需要执行的时间(execution_time)，并记录在trigger_executions表中。由于当前trigger并未关联任何数据保护（备份）计划，因此并不会触发保护（备份）动作。

trigger_executions.png

4.1.1.3 创建调度执行任务

karbor scheduledoperation-create <scheduled-operation-name> <scheduled-type> <trigger-id> plan_id=<plan_id>,provider_id=<provider_id>

scheduled-operation.png
调度任务创建完成后，当到达任务触发条件时，会调用checkpoint create API自动执行创建checkpoint的操作，可通过checkpoint list看到已创建的checkpoint。

checkpoint-list.png

4.1.2 自定义任务策略调度逻辑

operation-engine.png

创建Trigger后，会将Trigger信息保存至数据库中，并在Operation Engine模块进行注册，每个Trigger对应Operation Engine模块的一个协程，该协程会持续运行，通过Trigger定义获取其下次执行时间，并更新数据库；在到达执行时间后，执行与其关联的Operation动作。
创建Scheduled Operation后，会将Scheduled Operation信息保持在数据库中，并将其注册到所关联的Trigger上。当Trigger的执行时间到达后，会触发该Scheduled Operation操作。触发Scheduled Operation，是通过调用Checkpoint API来执行。

4.1.3 卷备份逻辑流程

Karbor中社区原生有多种卷备份插件。本小节以cinder backup及glance插件为例进行分析。

4.1.3.1 Cinder backup插件

基于Cinder backup插件进行卷备份时，涉及到包含DB、Bank、Cinder Backup后端存储在内的多种存储，关系图如下。

multi-storage.png

图中绿色部分为涉及到的存储系统。其中DB部分同OpenStack其他标准模块一样，主要用来存储Plan、Trigger、Scheduled Operation、Operation LOG、Quota等信息；Bank后端存储，主要用来存储Checkpoint信息，如Checkpoint的元数据（如果插件采用将数据读取到Bank存储的方式时，那么也会存储对应的备份数据），在采用Cinder Backup插件时，只用来存储Checkpoint元数据；Cinder Backup后端存储，与Bank后端存储独立。当都使用同一种存储接口时，Bank后端存储与Cinder Backup后端存储可以采用同一套存储系统，但需要注意的是，两者只是共用同一种存储系统，数据还是分开管理的。
使用Cinder backup插件创建checkpoint流程如下：

1.  调用API接口创建checkpoint，解析checkpoint信息
2.  通过rpc调用protection模块protect接口创建checkpoint
3.  在bank storage中写入checkpoint信息
4.  新建协程：获取资源依赖关系图，并依据关系图生成任务执行流程
5.  返回客户端成功
6.  调用Cinder backup插件执行备份动作
7.  插件：更新checkpoint状态为protecting
8.  插件：获取volume状态
9.  插件：在volume状态为可用状态前提下，调用cinder backup接口创建备份
10. 插件：创建backup结束后，保存resource metadata信息
11. 插件：更新checkpoint为available状态

4.1.3.2 Cinder Glance插件

基于Cinder Glance插件时，会将卷中的数据通过镜像的方式导出，并存储到Bank后端，涉及的存储关系如图示。

cinder-glance.png

在采用Cinder Glance插件时，备份过程中会通过Cinder的upload to image功能，将卷数据上传至Glance，然后再通过Glance API将数据读出，写入到Bank中。此插件中，checkpoint元数据，与备份产生的数据均会被写入到同一个Bank后端，并进行统一管理。
此插件的优缺点非常明显，优点是可以将卷数据到导出到系统外专门的备份存储系统上，安全性更高，而且可以方便的在其他集群中基于Karbor将数据读出，并在其他集群中恢复为一个新的卷，在跨集群备份恢复上，可以作为一种比较有效的方式；缺点是，通过glance做中转，数据读写路径较长，性能差，对于比较大的卷会更明显（目前无更好的解决方法，OpenStack原生模块，没有API可以将卷数据读出，而且通过这种方式，无法识别到卷中的有效数据（100G的卷，只是用100MB），默认会将整个卷都导出，效率不高。
使用Cinder Glance插件创建checkpoint流程如下：

1.  调用API接口创建checkpoint，解析checkpoint信息
2.  通过rpc调用protection模块protect接口创建checkpoint
3.  在bank storage中写入checkpoint信息
4.  新建协程：获取资源依赖关系图，并依据关系图生成任务执行流程
5.  返回客户端成功
6.  协程调用Cinder Glance插件执行备份动作
7.  插件：更新checkpoint状态为protecting
8.  插件：获取volume状态
9.  插件：在volume状态为可用状态前提下，为卷创建快照
10. 插件：基于快照创建临时卷
11. 插件：将临时卷上传至Glance，生成临时镜像
12. 插件：将临时镜像数据读出，写入到Bank后端存储
13. 插件：创建backup结束后，保存resource metadata信息
14. 插件：更新checkpoint为available状态
15. 插件：删除以上过程中创建的临时资源：临时快照、临时卷、临时镜像

4.1.3.4 卷恢复流程

Karbor原生插件，均采将备份资源恢复到新建资源的方法，来进行资源恢复。具体逻辑流程，可视为创建checkpoint的反向操作，以cinder glance插件为例进行分析，流程如下：

1.  调用API接口创建restore，将restore信息写入数据库
2.  通过rpc调用protection模块restore接口创建restore任务
3.  读取checkpoint信息、provider信息，进行相关校验操作
4.  新建协程：获取资源依赖关系图，并依据关系图生成任务执行流程
5.  返回成功
6.  协程调用Cinder Glance插件执行恢复动作
7.  插件：创建临时镜像
8.  插件：基于临时镜像创建卷
9.  插件：删除临时镜像

4.2 Server备份

在社区Karbor原生插件中，定义了Server保护插件。Server可以理解为一系列资源的合集：包括镜像、卷、网络、挂载关系等，这些信息共同构成了用户的一个虚拟服务器。自定义备份任务、自定义任务调度逻辑已经在卷备份章节进行了分析，所以本章节不再重复描述，只分析与Server资源联系较为紧密的依赖资源解析策略。

4.2.1 资源依赖视图

Karbor在定义可保护资源类型时，基于图的方式定义了资源之间的依赖关系，视图如下。

topology.png

其中Project为最上层的概念，对Project资源进行保护（备份）时，可以选择保护其下的Server、Volume、Glance、Network等资源。
Server的存在，依赖于Volume、Glance、Network（社区现版本强依赖关系已移除，以满足用户只需恢复虚拟机数据，而无需恢复到原有网络的场景；但用户可依然可以选择保护与对应Server相关联的Network）。
通过karbor protectable-show-instance命令，查看到的资源依赖如图：

protectable-show.png

4.2.2 Server备份逻辑流程

目前Karbor针对Server资源，只有一种备份插件，即nova protection plugin。以备份卷虚拟机为例，整体逻辑流程如图：

volume-boot-server.png

其中，当请求到达Protection Service后，会根据待保护资源类型，将保护任务进行拆分。由于Server资源依赖于Server元数据，Volume数据以及Neutron元数据，因此会分别调用3个插件进行对应资源的备份。
 Server Protection Plugin：主要备份虚拟机挂载信息、网络、浮动IP、flavor、安全组等元数据信息。
 Volume Protection Plugin: 主要备份卷数据（可以是任意一种卷备份插件）
 Neutron Protection Plugin：主要备份network、subnet、port、router、security-group等元数据信息。

4.2.3 恢复流程

在Karbor中，Server的恢复流程也包含了Server元数据、卷、网络的恢复流程，具体如下：

a)  解析恢复任务流程，分解恢复任务
b)  调用volume,neutron插件，分别恢复net、volume等信息
c)  调用server插件，通过备份计划获取备份名称
d)  通过备份的名称，从bank_section拿到备份的metadata
e)  获取恢复资源时使用的net id、flavor id，启动卷的id
f)  基于以上数据创建虚拟机
g)  等虚拟机变为ACTIVE状态后，恢复卷挂载关系
h)  恢复FIP绑定关系
i)  结束恢复流程

5 Karbor的优缺点分析

5.1 优点

统一北向API，易于备份服务化
插件化机制，易于集成多厂商备份能力
支持用户自定义备份服务，可灵活选择备份哪些资源、何时备份、备份到哪种后端存储
对社区掌控力强，易于加入新特性

5.2 缺点

不支持文件、数据库等非OpenStack纳管的资源类型
目前商业备份软件只支持爱数Driver，未与其他商业软件集成

6 最近发布亮点功能

支持Quota，可以定义用户允许的最大备份计划数量、任务数量等
支持回滚式备份恢复，自动删除最旧备份
跨OpenStack集群的备份与恢复
支持Manila Share备份恢复管理插件
支持K8S Pod备份恢复管理插件
支持备份副本校验
支持备份副本Copy API

7 Train版本重点规划

重构Bank概念，同时支持DB Driver及Object Driver。DB Driver主要用在，仅有自定义数据保护策略的场景，只涉及存储元数据，可以与OpenStack现有数据库表复用，避免依赖过多存储系统，从而造成系统复杂度过高
支持RBD driver
提升文档