可扩展备份服务¶
https://blueprints.launchpad.net/cinder/+spec/scalable-backup-service
由于 cinder 备份工作负载作为专用服务运行，因此它们有可能独立于其他 cinder 卷服务运行。理想情况下，备份服务应根据生成的备份工作负载按需在云端启动，并在工作负载消失时弹性地退役。理想情况下，备份任务应分配给可用备份服务中负载最轻的服务。
今天，cinder 备份服务与 cinder 卷服务的紧密耦合阻碍了追求这一理想。
本规范致力于打破 cinder 备份和卷服务之间的这种紧密耦合。
这是朝着真正弹性、水平可扩展的备份服务迈出的第一步。当这种耦合被放松后，可以同时启动多个备份服务并运行，而无需要求它们与卷服务或彼此共置。
我们预计后续工作将解决后续步骤，例如备份任务的调度器支持以及使用虚拟机或容器而不是专用物理节点动态生成备份服务进程，但这些主题将在后续规范中解决，此处不在范围内。
一次做一件事。
问题描述¶
当备份服务备份或恢复卷时，它会使用特定于所选和配置的备份存储库的备份驱动程序来与例如 swift 或 Ceph 对象存储、NFS、glusterfs 或通用 POSIX 文件系统或 Tivoli Storage Manager 交互。此备份驱动程序插入备份管理器，并提供将数据放入备份存储库或从存储库中检索数据的功能。特定的备份服务进程只有一个备份驱动程序，因此只有一个备份存储库。但是，它可以对任何已启用后端处理的卷执行备份和恢复操作。
备份服务需要特定于后端的函数才能附加到任何特定的卷，以便读取备份或写入恢复。
今天，这种特定于后端的的信息按如下方式提供。当备份服务进程启动时，备份管理器会加载 cinder.conf 中配置的每个已启用后端对应的卷管理器模块。当 OpenStack 租户或管理员发出从 cinder 卷备份或恢复到 cinder 卷的请求时，备份 api 会查看卷的 host 字段，并将备份或恢复操作的 rpc 指向该节点上的备份管理器。在那里，备份管理器选择相关卷后端的 volume 管理器，并调用其 driver 的 backup_volume 或 restore_volume 方法，并将备份 对象和配置的备份存储库的备份 驱动程序（swift、ceph、NFS 等）传递给该方法。然后，卷驱动程序附加到相应的卷，打开它，并使用来自 卷驱动程序的附加和打开操作的文件句柄调用备份驱动程序的 backup 或 restore 方法。
因此，今天备份管理器不会直接调用其备份驱动程序的方法；它通过适当的卷管理器找到合适的卷驱动程序，并且卷驱动程序调用合适的备份驱动程序。卷驱动程序按定义在运行相关后端卷服务的 cinder 节点上运行，因此由于备份管理器、卷驱动程序和备份驱动程序代码都在单个节点的单个操作系统进程的上下文中运行，因此备份服务必然与也运行卷服务的节点绑定。
当多个池和后端在同一节点上运行时，这意味着并发备份最终会遇到单个节点的资源限制。由于备份任务不通过调度器，因此它们通常也受到单个操作系统进程的资源限制。
用例¶
OpenStack 租户或管理员需要按计划进行备份或按需进行恢复，以便及时完成工作，需要并发运行许多备份和恢复。
处理峰值备份和恢复负载所需的资源超过了标准物理节点的功能。
请注意，对并发备份和恢复操作的需求，尤其是针对同一后端的需求，可能由于缺乏对实时备份的支持而人为地受到抑制。我们预计现在支持备份正在使用的卷 ([3] [5]) 后，这种需求将显著增加。
提议的变更¶
利用远程附加功能将卷驱动程序提供的功能移动到备份管理器中。这样，备份管理器就可以直接调用备份驱动程序，而无需在启动时加载卷管理器并运行相关的卷管理器驱动程序。
如今，附加卷是通过使用构建适当 connector 进行附加的 brick 库完成的，该库根据通过运行卷驱动程序的 initialize_connection 方法获得的信息（iSCSI、FibreChannel、NFS 等）。在远程附加的情况下，initialize_connection 通过 rpc 调用。这是工作流程中实际需要卷服务的唯一部分，由于它可以是 rpc 调用，这意味着备份服务本身可以消除加载卷管理器和卷驱动程序的直接负载，并且备份服务因此可以在与后端卷服务的节点不同的节点上运行。
现在支持备份正在使用的卷，卷驱动程序可以提供 attach_snapshot 方法，然后将其用作优化，而不是附加源卷的临时卷副本。在初始实现 [6] 中，添加了一个仅允许本地附加的 attach_snapshot 方法，并且参考 lvm driver 在获取用于备份操作的卷时显式使用 local_path [5]。作为实施本蓝图规范的工作的一部分，我们需要重新审视快照附加以允许远程附加。像 lvm driver 这样的无法支持快照远程附加的驱动程序需要回退到使用临时卷 [5]。 * 从原始卷创建临时卷。 * 备份临时卷。 * 清理临时卷。
备选方案¶
保留现有方案。备份服务继续工作，但无法扩展。
运行备份服务的节点必须扩展以处理预计的峰值备份工作负载，并且很可能在大多数实际备份工作负载下利用率不足或功能不足。
与其直接从备份管理器加载卷管理器，不如在卷管理器中公开
backup_volume和restore_volume方法，让这些方法调用相同的名称的相应卷驱动程序的方法，并让备份管理器使用 rpc 到卷服务以触发卷管理器的backup_volume和restore_volume方法。这种方法将减少备份服务进程的内存需求，因为它不再加载所有已启用后端的卷管理器。并且备份管理器与卷服务之间的链接现在松散耦合。但是，大部分工作 - 数据传输、加密、压缩 - 都是由备份驱动程序完成的，而备份驱动程序仍然与卷服务紧密耦合。
此规范未解决的问题¶
一个备份任务调度器。
备份 api 进程可以从数据库获取活动备份服务的列表，并选择一个 rpc 目标，例如第一个服务，进行随机选择，或在这些选择中进行轮询。未来可以在这里调用调度器，但调度器本身不在本规范的范围内。
弹性备份服务放置。
备份服务将或多或少地由管理员手动启动或配置为在节点启动时启动。可以想象一种动态机制，用于根据工作负载到达情况触发服务 VM 或容器的启动。通过本规范解决的备份和卷服务之间的解耦是实现这种弹性备份服务放置能力的前提条件，但它只是实现这种能力的一小步。
服务 init_host 清理¶
在启动时，当前的备份服务代码会尝试发现并清理孤立的、不完整的备份和恢复操作（例如，它们在备份进程本身终止时正在进行）。备份服务假定它是唯一的备份进程，因此如果它在启动时发现处于创建或恢复状态的备份，它可以安全地重置其状态并分离正在备份或恢复的卷。
如果可以并发运行多个备份进程，并且在不同的节点上，则此假设是不安全的。在启动时，备份服务需要区分由另一个备份服务实例拥有的正在进行的操作和孤立的操作。
最终，备份服务进程清理由其早期实例或其他异常终止的备份进程留下的内容是有意义的。但是，解决此一般问题的解决方案需要可靠的能力，在连接丢失时自动隔离自身，作为 cinder 卷服务 Active-Active HA 解决方案的一部分正在开发 [7]。
在这里，我们将与 Mitaka 设计峰会的社区决策保持一致，即推迟自动隔离能力，并开始针对 cinder 卷服务进行 Active-Active HA，而无需自动清理，方法是将备份服务初始化清理限制为来自同一备份服务的遗留项。
备份对象的 host 字段将设置为备份操作投递到的备份服务的 host。备份状态更新和 host 更新将在一个事务中处理。初始化清理可以限制为通过其相应的备份对象链接到与自身匹配的 host 字段的遗留对象。将使用比较和交换 DB 操作来防止竞争条件。
例如，对于由在节点 A 上处理后端的卷服务的卷，其中备份服务进程在节点 B 和节点 C 上运行，当使用节点 B 上的服务创建备份时，备份对象的 host 字段将设置为 B。当使用节点 C 上的备份服务从该备份恢复时，备份对象的 host 字段将设置为 C。
将通过 rpc 到适当的卷服务 host 来完成关联卷、临时卷和临时快照的清理。
请注意，备份对象包含备份卷的 volume_id 字段，以及实时备份的 temp_volume_id 和 temp_snapshot_id 字段，但当前不保留恢复备份的卷的 id。我们需要添加此字段才能确定孤立的恢复操作卷。
特殊卷驱动程序备份/恢复注意事项¶
由于当前卷驱动程序的 backup_volume 和 restore_backup 方法的功能将在此提案中移动到备份管理器，因此不再需要这些方法，可以从代码库中删除。也就是说，一些卷驱动程序会用似乎比仅仅将其卷呈现为块设备具有更多“特殊功能”的方法覆盖这些方法。
我们需要分析代码库以找出这些方法，并确定如何适应任何特殊需求。
一个例子是 vmware 卷驱动程序 [4]，其中为 cinder 卷创建“backing”和临时 vmdk 文件，并且临时 vmdk 文件用作备份源。我们需要确定是否所有这些都可以在卷驱动程序的 initialize_connection 方法中完成，在 attach 期间，或者是否需要额外的 rpc 钩子到 prepare_backup_volume 方法或此类卷驱动程序。
数据模型影响¶
无。
REST API 影响¶
无。
安全影响¶
待定。
我们需要了解在运行备份和恢复操作时提升权限的确切位置，并确保没有不必要地高于请求这些操作的管理员或租户的正常权限的提升。
通知影响¶
我们应该能够执行与现在相同的备份服务通知。
其他最终用户影响¶
功能或客户端交互没有变化。
性能影响¶
备份过程将更轻量级，因为不再加载卷管理器和驱动程序。
所提出的更改允许根据需要运行多个备份进程。
其他部署者影响¶
备份服务现在可以在多个节点上运行，不再需要与处理卷后端的卷服务位于同一节点上。
开发人员影响¶
启用潜在的有价值的未来功能，例如备份调度器或弹性备份服务放置。
实现¶
负责人¶
主要负责人
Tom Barron (tbarron, tpb@dyncloud.net)
其他贡献者：* LisaLi (lixiaoy11, xiaoyan.li@intel.com) * Huang Zhiteng (winston-d, winston.d@gmail.com)
工作项¶
编写代码。现在已经有POC可用 [1]。
确定并解决对现有卷驱动程序的影响，这些驱动程序拥有自己的备份或恢复方法。
在多个节点上运行/测试新代码，同时运行多个备份进程，而不仅仅是在启用后端服务的节点上运行。
依赖项¶
无
测试¶
将扩展单元测试以涵盖新备份代码，用于以前由卷驱动程序提供的功能。
将修改备份管理器和卷驱动程序的单元测试，以反映从备份服务中移除的代码，用于加载卷管理器、运行卷驱动程序等，以及从卷驱动程序中移除的代码，用于运行备份和恢复操作。
现有的tempest测试应该提供足够的覆盖率，以确保当前功能不会退化。可以添加潜在的新多节点tempest测试来验证分布式交互。我们应该抓住机会扩展当前tempest的备份覆盖范围，并在可行的情况下添加备份功能测试。
文档影响¶
使用新的部署选项进行更新。
