CN116893932A - 一种基于云平台工作流的资源定时快照与备份实现方法 - Google Patents

一种基于云平台工作流的资源定时快照与备份实现方法 Download PDF

Info

Publication number
CN116893932A
CN116893932A CN202310906932.1A CN202310906932A CN116893932A CN 116893932 A CN116893932 A CN 116893932A CN 202310906932 A CN202310906932 A CN 202310906932A CN 116893932 A CN116893932 A CN 116893932A
Authority
CN
China
Prior art keywords
snapshot
backup
timing
volume
action
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202310906932.1A
Other languages
English (en)
Inventor
焦鹏辉
姚宁
张幸
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Tongfang Youyun Beijing Technology Co ltd
Original Assignee
Tongfang Youyun Beijing Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tongfang Youyun Beijing Technology Co ltd filed Critical Tongfang Youyun Beijing Technology Co ltd
Priority to CN202310906932.1A priority Critical patent/CN116893932A/zh
Publication of CN116893932A publication Critical patent/CN116893932A/zh
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1448—Management of the data involved in backup or backup restore
    • G06F11/1453—Management of the data involved in backup or backup restore using de-duplication of the data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/11—File system administration, e.g. details of archiving or snapshots
    • G06F16/128—Details of file system snapshots on the file-level, e.g. snapshot creation, administration, deletion
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Abstract

本发明提供一种基于云平台工作流的资源定时快照与备份实现方法，包括通过Openstack的Mistral中的cron‑trigger配合workflow，指定特定的action，添加接收输入参数，构建定时执行策略；创建自定义action执行快照或备份；根据Mistral提供的自定义接入方案，设计action的四种实现逻辑：卷定时备份；卷定时快照；实例定时快照；文件共享定时快照。本发明能够实现云平台中定时任务的需求，包括实现定时卷定时快照、卷定时备份、实例定时快照、文件共享定时备份四种资源的定时执行策略，用户可选择执行周期实现云平台资源的周期性备份或快照，实现云平台资源备份与快照的自动化过程。

Description

一种基于云平台工作流的资源定时快照与备份实现方法
技术领域
本发明涉及云计算平台技术领域，具体而言，涉及一种基于云平台工作流的资源定时快照与备份实现方法。
背景技术
Openstack是一个开源的云计算管理平台项目，是一系列软件开源项目的组合，Openstack由几个主要的组件组合起来完成一些具体的工作，旨在为私有云和公有云提供可扩展的弹性的云计算服务。
OpenStack覆盖了网络、虚拟化、操作系统、服务器等各个方面。它是一个正在开发中的云计算平台项目，根据成熟及重要程度的不同，被分解成核心项目、孵化项目，以及支持项目和相关项目。而且每个项目都不是一成不变的，比如孵化项目可以根据发展的成熟度和重要性，转变为核心项目。
Mistrial是mirantis公司为OpenStack开发的工作流组件，提供WorkFlowasaservice工作流服务。典型的用户用例包括云平台的任务计划服务(Cloud Cron)，任务调度(TaskScheduling)，复杂的运行时间长的业务流程服务。
Mistrial中的主要技术术语及其含义包括：
Task：即工作流的具体步骤。可以是action的集合。
Action：是Mistral的最小单位，特指一个具体的工作，比如说发送一个HTTP请求，或者运行某条命令。
Flow：工作流，指的是Mistral系统中如何执行task，解析task的依赖关系等等，从而让task顺利结束，并返回状态。
WorkFlowExecution：工作流执行纪录。就是指某次具体的Flow，每次执行Task产成的WorkFlowExecution会永久保存在数据库中，方便后续查询，或者重新执行Flow。
然而，随着用户使用云平台时间的增长，随之而来的会有一些数据备份和恢复的需求，包括：卷备份与卷快照、实例备份以及文件共享备份。其中，在没有平台层面的针对块存储备份、文件存储备份以及实例恢复的能力支持下，用户侧更多的是去做业务方面的数据备份，现阶段
发明内容
鉴于此，本发明的目的在于解决云平台资源定时备份和定时快照的需求，包括云主机定时快照、云硬盘定时备份、云硬盘定快照以及文件共享定时快照四种，可通过面板指定定时执行周期，通过自定义action和用户前端面板的指定输入来定期执行周期任务。
本发明为方便对这几个层面的资源进行备份或快照，并且能够做有计划的备份、快照任务，因此提出实例快照、卷备份、卷快照以及文件共享快照的定制化action和工作流开发任务，以此满足用户对不同资源的计划备份与快照的需求。
本发明的主要实现是通过Openstack社区项目Mistral中的cron-trigger配合workflow来实现定时执行策略的功能，另外，workflow需要指定特定的action，接收输入参数，参数包括但不限于类型(重复执行或仅执行N次)、执行次数(当且仅当选择仅执行N次时生效)、执行频率(周期和时间)，保留规则(按数量或永久保留)、保留数量(当且仅当保留规则为按数量保留时生效)。Action用于执行快照或备份，即为自定义的action并在快照或备份达到用户指定的上限时删除时效性最差的快照或备份资源。
本发明提供一种基于云平台工作流的资源定时快照与备份实现方法，包括以下步骤：
S1、通过Openstack社区的Mistral项目中的cron-trigger触发器配合workflow工作流，指定特定的action，action属性添加接收输入参数，构建定时执行策略；
S2、创建自定义action，所述自定义action执行快照或备份，并在快照或备份达到用户指定的上限时删除时效性最差的快照或备份资源；
S3、根据所述Mistral项目提供的自定义接入方案，设计action的实现逻辑，所述action的实现逻辑包括以下四种：
(1)卷定时备份action实现逻辑；
(2)卷定时快照action实现逻辑；
(3)实例定时快照action实现逻辑；
(4)文件共享定时快照action实现逻辑。
进一步地，所述S3步骤的卷定时备份action实现逻辑包括以下步骤：
S311、创建mistral项目中的备份策略，通过特定命名方式实现一个volume云盘至多有一个备份策略，通过ui界面创建备份策略定义一个定时执行的workflow工作流；
S312、检查volume云盘是否存在以及volume的状态，通过查询数据库查询此所述volume的volume_id是否存在，如果volume_id不存在，则返回错误；如果存在，则继续判断volume的状态，只有in-use和available状态的卷能够备份操作；
S313、对用户创建的备份、备份策略创建的备份进行区分，以在删除旧备份的时候不删除用户创建的备份，将所述备份策略创建的备份加上metadata元数据”created_by_policy”＝”True”，使得所述备份策略创建的备份有该metadata，所述用户创建的备份无此metadata；
S314、通过备份策略创建一个备份拿到返回的result数据，所述result数据包括备份的信息，使用所述备份的信息能够判断备份状态；
S315、判断max_backups是否为None，如果为None，则为永久保留，无需进行备份数量判断操作，也无需删除旧备份；
如果max_backups不为None，则进行保留数量判断；如果超过最大备份数量，则删除相应的旧的备份(此部分逻辑当且仅当用户选择的保留规则是按数量保留时生效)；清理冗余备份的逻辑为，通过调用cinder的api查询数据库中的所有备份，使用metadata以及status过滤条件得到备份策略自动创建的备份按照时间降序排列得到一个所有当前备份策略所创建的成功备份列表backup_list(backup的status均为available)；
如果此时只有一个备份策略自动创建成功的备份，需至少保留一个成功的备份，则不能进行删除操作；
如果此时有两个以上备份策略自动创建成功的备份，则对列表长度和max_backups进行比较，如果列表长度大于max_backups，则redundancy＝len(backup_list)-max_backups，所述redundancy记录应当删除掉的旧备份数量，使用for循环pop(backup_list)得到应当删除的数据，同时调用cinder的api在for循环中删除掉pop出的数据，for循环结束数据库中的备份数量恢复为max_backups。
进一步地，所述S3步骤的所述卷定时快照action实现逻辑包括：
所述卷定时快照action实现逻辑与所述卷定时备份action的实现逻辑的不同点仅在于：所述卷定时快照action实现逻辑的metadata元数据为”volume_time_snapshot”:”True”，以用于区分用户创建的snapshot和定时策略自动创建的snapshot，以维护snapshot的最大数量；
所述卷定时快照action实现逻辑的其他逻辑与所述卷定时备份action的实现逻辑相同。
进一步地，所述S3步骤的所述实例定时快照action实现逻辑包括以下步骤：
S321、通过特定命名方式实现一个instance实例至多有一个定时快照策略；
S322、根据前端传入的instance参数获取nova中的实例，根据instance的状态以及instance_stop参数来实现实例的关机操作逻辑；
S323、根据root_disk_only判断是否仅对根磁盘进行快照操作，如果仅对根磁盘进行快照操作，则调用cinder的api实现创建快照的需求(与卷定时快照action实现逻辑的任务一样，为了方便区分用户创建的实例定时快照与策略任务创建的实例定时快照，这里仍然使用metadata来区别)；
S324、之后的逻辑与所述卷定时快照action实现逻辑保持一致，仅维护cinder的snapshot数量；如果root_disk_only＝False，则调用nova的api创建instanceimage，实现instance的快照功能，nova创建的image需要使用glance的api查询；
如果传入了最大数量限制，则通过metadata过滤并按照时间倒序排列后得到主机快照列表，过滤出状态为成功的主机快照列表，判断主机是从镜像启动bfi还是从卷启动bfv，如果主机是从卷启动bfv，则需要维护cinder的snapshot和glance的image两种资源数量；
如果主机是从镜像启动bfi，则只需要删除掉glance的image。
进一步地，所述S3步骤的文件共享定时快照action实现逻辑包括：
S331、通过特定命名方式实现一个share文件共享至多有一个定时快照策略；
S332、根据前端传入的share的id调用manila的api查找到对应的文件共享，调用manila的api创建文件共享快照，与卷定时快照action实现逻辑不同的是manila文件共享快照并不支持metadata选项，所以这里使用description＝”created_by_policy”来区别用户创建的文件共享定时快照与策略创建的文件共享定时快照；
S333、快照创建完成后根据max_snapshots来判断是否需要进行删除冗余快照的逻辑，如果max_snapshots为None，则不需要删除任何快照(用户选择的永久保留)，如果max_snapshots不为None，则需要通过manilaapi来list出所有当前shareid的snapshots列表，通过description和状态过滤出成功的快照列表，进行清理逻辑的处理，清理逻辑需要至少保留一个成功状态的快照。
进一步地，所述S1步骤的所述输入参数包括：
类型(重复执行或仅执行N次)、执行次数(当且仅当选择仅执行N次时生效)、执行频率(周期和时间)、保留规则(按数量或永久保留)、保留数量(当且仅当保留规则为按数量保留时生效)中的一种或多种的组合。
进一步地，所述S321步骤的所述实例定时快照策略的action接收的参数包括：
instance(代表要进行定时快照的instance,接收一个id)、image_name(用户指定的实例快照名，可以为空将自动生成)、max_snapshots(用户选定的快照保留最大数量，默认值为5)、root_disk_only(默认值为False，如果为True则将仅对系统盘执行快照操作，如果为False将对整个机器进行镜像操作)、instance_stop(是否关机，默认为False)、action_region等一些必要参数。
进一步地，所述S331步骤的所述文件共享定时快照策略的action接收的参数包括：
share(文件共享的id)、name(默认为None，用户可以指定策略创建的文件共享快照的名)、force(glanceapi中强制快照的选项)、max_snapshots(文件共享快照的最大数量限制，默认值为5)、action_region等一些必要参数。
本发明的关键技术点是使用Mistral的cron-trigger结合WorkFlow实现周期性资源备份或快照任务，为了与业务相匹配，进而设计自定义action来实现周期性任务中一个任务。
本发明还提供一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时实现如上述所述的基于云平台工作流的资源定时快照与备份实现方法。
本发明还提供一种计算机设备，所述计算机设备包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现如上述所述的基于云平台工作流的资源定时快照与备份实现方法。
与现有技术相比，本发明的有益效果在于：
本发明能够实现云平台中定时任务的需求，包括实现定时卷定时快照、卷定时备份、实例定时快照、文件共享定时备份四种资源的定时执行策略，用户可选择执行周期实现云平台资源的周期性备份或快照，实现了云平台资源备份与快照的自动化过程。
附图说明
通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。
在附图中：
图1为本发明一种基于云平台工作流的资源定时快照与备份实现方法的流程示意图；
图2为本发明实施例的卷定时备份action实现逻辑的流程示意图；
图3为本发明实施例的实例定时快照action实现逻辑的流程示意图；
图4为本发明实施例的文件共享定时快照action实现逻辑的流程示意图；
图5为本发明实施例的创建定时策略流程图；
图6为本发明实施例的卷定时备份action逻辑流程图；
图7为本发明实施例的卷定时快照action逻辑流程图；
图8为本发明实施例的实例定时快照action逻辑流程图；
图9为本发明实施例的文件共享定时快照action逻辑流程图；
图10为本发明实施例计算机设备的构成示意图。
具体实施方式
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开的一些方面相一致的装置和产品的例子。
在本公开使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本公开。在本公开和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。
应当理解，尽管在本公开可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本公开范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。
下面结合附图对本发明实施例作进一步详细说明。
本发明实施例提供一种基于云平台工作流的资源定时快照与备份实现方法，参见图1所示，包括如下步骤：
S1、通过Openstack社区的Mistral项目中的cron-trigger触发器配合workflow工作流，指定特定的action，action属性添加接收输入参数，构建定时执行策略；
本实施例中，所述输入参数包括：
类型(重复执行或仅执行N次)、执行次数(当且仅当选择仅执行N次时生效)、执行频率(周期和时间)、保留规则(按数量或永久保留)、保留数量(当且仅当保留规则为按数量保留时生效)。
参见图5所示为本实施例创建定时执行策略的流程；
S2、创建自定义action，所述自定义action执行快照或备份，并在快照或备份达到用户指定的上限时删除时效性最差的快照或备份资源；
S3、根据所述Mistral项目提供的自定义接入方案，设计action的实现逻辑，所述action的实现逻辑包括以下四种：
(1)卷定时备份action实现逻辑；
(2)卷定时快照action实现逻辑；
(3)实例定时快照action实现逻辑；
(4)文件共享定时快照action实现逻辑。
所述卷定时备份action实现逻辑，参见图2所示，包括以下步骤：
S311、创建mistral项目中的备份策略，通过特定命名方式实现一个volume云盘至多有一个备份策略，通过ui界面创建备份策略定义一个定时执行的workflow工作流；
S312、检查volume云盘是否存在以及volume的状态，通过查询数据库查询此所述volume的volume_id是否存在，如果volume_id不存在，则返回错误；如果存在，则继续判断volume的状态，只有in-use和available状态的卷能够备份操作；
S313、对用户创建的备份、备份策略创建的备份进行区分，将所述备份策略创建的备份加上metadata元数据”created_by_policy”＝”True”，使得所述备份策略创建的备份有该metadata，所述用户创建的备份无此metadata；
S314、通过备份策略创建一个备份拿到返回的result数据，所述result数据包括备份的信息，使用所述备份的信息能够判断备份状态；
S315、判断max_backups是否为None，如果为None，则为永久保留，无需进行备份数量判断操作，也无需删除旧备份；
如果max_backups不为None，则进行保留数量判断；如果超过最大备份数量，则删除相应的旧的备份(此部分逻辑当且仅当用户选择的保留规则是按数量保留时生效)；清理冗余备份的逻辑为，通过调用cinder的api查询数据库中的所有备份，使用metadata以及status过滤条件得到备份策略自动创建的备份按照时间降序排列得到一个所有当前备份策略所创建的成功备份列表backup_list(backup的status均为available)；
如果此时只有一个备份策略自动创建成功的备份，需至少保留一个成功的备份，则不能进行删除操作；
如果此时有两个以上备份策略自动创建成功的备份，则对列表长度和max_backups进行比较，如果列表长度大于max_backups，则redundancy＝len(backup_list)-max_backups，所述redundancy记录应当删除掉的旧备份数量，使用for循环pop(backup_list)得到应当删除的数据，同时调用cinder的api在for循环中删除掉pop出的数据，for循环结束数据库中的备份数量恢复为max_backups。
参见图6所示为本实施例的卷定时备份action逻辑流程。
所述卷定时快照action实现逻辑包括：
所述卷定时快照action实现逻辑与所述卷定时备份action的实现逻辑的不同点仅在于：所述卷定时快照action实现逻辑的metadata元数据为”volume_time_snapshot”:”True”，以用于区分用户创建的snapshot和定时策略自动创建的snapshot，以维护snapshot的最大数量；
所述卷定时快照action实现逻辑的其他逻辑与所述卷定时备份action的实现逻辑相同。
参见图7所示为本实施例的卷定时快照action逻辑流程。
所述实例定时快照action实现逻辑，参见图3所示，包括以下步骤：
S321、通过特定命名方式实现一个instance实例至多有一个定时快照策略；
Action接收的参数有：
instance的id(代表要进行定时快照的instance,接收一个id)、
image_name(用户指定的实例快照名，可以为空将自动生成)、
max_snapshots(用户选定的快照保留最大数量，默认值为5)、
root_disk_only(默认值为False，如果为True则将仅对系统盘执行快照操作，如果为False将对整个机器进行镜像操作)、
instance_stop(是否关机，默认为False)、action_region等一些必要参数；
S322、根据前端传入的instance参数获取nova中的实例，根据instance的状态以及instance_stop参数来实现实例的关机操作逻辑；
S323、根据root_disk_only判断是否仅对根磁盘进行快照操作，如果仅对根磁盘进行快照操作，则调用cinder的api实现创建快照的需求(与卷定时快照action实现逻辑的任务一样，为了方便区分用户创建的实例定时快照与策略任务创建的实例定时快照，这里仍然使用metadata来区别)；
S324、之后的逻辑与所述卷定时快照action实现逻辑保持一致，仅维护cinder的snapshot数量；如果root_disk_only＝False，则调用nova的api创建instanceimage，实现instance的快照功能，nova创建的image需要使用glance的api查询；
如果传入了最大数量限制，则通过metadata过滤并按照时间倒序排列后得到主机快照列表，过滤出状态为成功的主机快照列表，判断主机是从镜像启动bfi还是从卷启动bfv，如果主机是从卷启动bfv，则需要维护cinder的snapshot和glance的image两种资源数量；
如果主机是从镜像启动bfi，则只需要删除掉glance的image。
参见图8所示为本实施例的实例定时快照action逻辑流程。
所述文件共享定时快照action实现逻辑，参见图4所示，包括以下步骤：
S331、通过特定命名方式实现一个share文件共享至多有一个定时快照策略；
文件共享定时快照action接受的参数有：
share的id(文件共享的id)、
name(默认为None，用户可以指定策略创建的文件共享快照的名)、
force(glanceapi中强制快照的选项)、max_snapshots(文件共享快照的最大数量限制，默认值为5)、
action_region等一些必要参数；
S332、根据前端传入的share的id调用manila的api查找到对应的文件共享，调用manila的api创建文件共享快照，与卷定时快照action实现逻辑不同的是manila文件共享快照并不支持metadata选项，所以这里使用description＝”created_by_policy”来区别用户创建的文件共享定时快照与策略创建的文件共享定时快照；
S333、快照创建完成后根据max_snapshots来判断是否需要进行删除冗余快照的逻辑，如果max_snapshots为None，则不需要删除任何快照(用户选择的永久保留)，如果max_snapshots不为None，则需要通过manilaapi来list出所有当前shareid的snapshots列表，通过description和状态过滤出成功的快照列表，进行清理逻辑的处理，清理逻辑需要至少保留一个成功状态的快照。
参见图9所示为本实施例的文件共享定时快照action逻辑流程。
本发明实施例还提供一种计算机设备，图10是本发明实施例提供的一种计算机设备的结构示意图；参见附图图10所示，该计算机设备包括：输入装置23、输出装置24、存储器22和处理器21；所述存储器22，用于存储一个或多个程序；当所述一个或多个程序被所述一个或多个处理器21执行，使得所述一个或多个处理器21实现如上述实施例提供的基于OpenStackMistral的资源定时快照与备份实现方法；其中输入装置23、输出装置24、存储器22和处理器21可以通过总线或者其他方式连接，图10中以通过总线连接为例。
存储器22作为一种计算设备可读写存储介质，可用于存储软件程序、计算机可执行程序，如本发明实施例所述的基于OpenStackMistral的资源定时快照与备份实现方法对应的程序指令；存储器22可主要包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需的应用程序；存储数据区可存储根据设备的使用所创建的数据等；此外，存储器22可以包括高速随机存取存储器，还可以包括非易失性存储器，例如至少一个磁盘存储器件、闪存器件、或其他非易失性固态存储器件；在一些实例中，存储器22可进一步包括相对于处理器21远程设置的存储器，这些远程存储器可以通过网络连接至设备。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。
输入装置23可用于接收输入的数字或字符信息，以及产生与设备的用户设置以及功能控制有关的键信号输入；输出装置24可包括显示屏等显示设备。
处理器21通过运行存储在存储器22中的软件程序、指令以及模块，从而执行设备的各种功能应用以及数据处理，即实现上述的基于OpenStackMistral的资源定时快照与备份实现方法。
上述提供的计算机设备可用于执行上述实施例提供的基于OpenStack Mistral的资源定时快照与备份实现方法，具备相应的功能和有益效果。
本发明实施例还提供一种包含计算机可执行指令的存储介质，所述计算机可执行指令在由计算机处理器执行时用于执行如上述实施例提供的基于OpenStackMistral的资源定时快照与备份实现方法，存储介质是任何的各种类型的存储器设备或存储设备，存储介质包括：安装介质，例如CD-ROM、软盘或磁带装置；计算机系统存储器或随机存取存储器，诸如DRAM、DDRRAM、SRAM、EDORAM，兰巴斯(Rambus)RAM等；非易失性存储器，诸如闪存、磁介质(例如硬盘或光存储)；寄存器或其它相似类型的存储器元件等；存储介质可以还包括其它类型的存储器或其组合；另外，存储介质可以位于程序在其中被执行的第一计算机系统中，或者可以位于不同的第二计算机系统中，第二计算机系统通过网络(诸如因特网)连接到第一计算机系统；第二计算机系统可以提供程序指令给第一计算机用于执行。存储介质包括可以驻留在不同位置中(例如在通过网络连接的不同计算机系统中)的两个或更多存储介质。存储介质可以存储可由一个或多个处理器执行的程序指令(例如具体实现为计算机程序)。
当然，本发明实施例所提供的一种包含计算机可执行指令的存储介质，其计算机可执行指令不限于如上实施例所述的基于OpenStackMistral的资源定时快照与备份实现方法，还可以执行本发明任意实施例所提供的基于OpenStackMistral的资源定时快照与备份实现方法中的相关操作。
至此，已经结合附图所示的优选实施方式描述了本发明的技术方案，但是，本领域技术人员容易理解的是，本发明的保护范围显然不局限于这些具体实施方式。在不偏离本发明的原理的前提下，本领域技术人员可以对相关技术特征做出等同的更改或替换，这些更改或替换之后的技术方案都将落入本发明的保护范围之内。
以上所述仅为本发明的优选实施例，并不用于限制本发明；对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种基于云平台工作流的资源定时快照与备份实现方法，其特征在于，包括以下步骤：
S1、通过Openstack社区的Mistral项目中的cron-trigger触发器配合workflow工作流，指定特定的action，action属性添加接收输入参数，构建定时执行策略；
S2、创建自定义action，所述自定义action执行快照或备份，并在快照或备份达到用户指定的上限时删除时效性最差的快照或备份资源；
S3、根据所述Mistral项目提供的自定义接入方案，设计action的实现逻辑，所述action的实现逻辑包括以下四种：
(1)卷定时备份action实现逻辑；
(2)卷定时快照action实现逻辑；
(3)实例定时快照action实现逻辑；
(4)文件共享定时快照action实现逻辑。
2.根据权利要求1所述的基于云平台工作流的资源定时快照与备份实现方法，其特征在于，所述S3步骤的卷定时备份action实现逻辑包括以下步骤：
S311、创建mistral项目中的备份策略，通过特定命名方式实现一个volume云盘至多有一个备份策略，通过ui界面创建备份策略定义一个定时执行的workflow工作流；
S312、检查volume云盘是否存在以及volume的状态，通过查询数据库查询此所述volume的volume_id是否存在，如果volume_id不存在，则返回错误；如果存在，则继续判断volume的状态，只有in-use和available状态的卷能够备份操作；
S313、对用户创建的备份、备份策略创建的备份进行区分，将所述备份策略创建的备份加上metadata元数据”created_by_policy”＝”True”，使得所述备份策略创建的备份有该metadata，所述用户创建的备份无此metadata；
S314、通过备份策略创建一个备份拿到返回的result数据，所述result数据包括备份的信息，使用所述备份的信息能够判断备份状态；
S315、判断max_backups是否为None，如果为None，则为永久保留，无需进行备份数量判断操作，也无需删除旧备份；
如果max_backups不为None，则进行保留数量判断；如果超过最大备份数量，则删除相应的旧的备份；清理冗余备份的逻辑为，通过调用cinder的api查询数据库中的所有备份，使用metadata以及status过滤条件得到备份策略自动创建的备份按照时间降序排列得到一个所有当前备份策略所创建的成功备份列表backup_list；
如果此时只有一个备份策略自动创建成功的备份，需至少保留一个成功的备份，则不能进行删除操作；
如果此时有两个以上备份策略自动创建成功的备份，则对列表长度和max_backups进行比较，如果列表长度大于max_backups，则redundancy＝len(backup_list)-max_backups，所述redundancy记录应当删除掉的旧备份数量，使用for循环pop(backup_list)得到应当删除的数据，同时调用cinder的api在for循环中删除掉pop出的数据，for循环结束数据库中的备份数量恢复为max_backups。
3.根据权利要求2所述的基于云平台工作流的资源定时快照与备份实现方法，其特征在于，所述S3步骤的所述卷定时快照action实现逻辑包括：
所述卷定时快照action实现逻辑与所述卷定时备份action的实现逻辑的不同点仅在于：所述卷定时快照action实现逻辑的metadata元数据为”volume_time_snapshot”:”True”，以用于区分用户创建的snapshot和定时策略自动创建的snapshot，以维护snapshot的最大数量；
所述卷定时快照action实现逻辑的其他逻辑与所述卷定时备份action的实现逻辑相同。
4.根据权利要求3所述的基于云平台工作流的资源定时快照与备份实现方法，其特征在于，所述S3步骤的所述实例定时快照action实现逻辑包括以下步骤：
S321、通过特定命名方式实现一个instance实例至多有一个实例定时快照策略；
S322、根据前端传入的instance参数获取nova中的实例，根据instance的状态以及instance_stop参数来实现实例的关机操作逻辑；
S323、根据root_disk_only判断是否仅对根磁盘进行快照操作，如果仅对根磁盘进行快照操作，则调用cinder的api实现创建快照的需求；
S324、之后的逻辑与所述卷定时快照action实现逻辑保持一致，仅维护cinder的snapshot数量；如果root_disk_only＝False，则调用nova的api创建instance image，实现instance的快照功能，nova创建的image需要使用glance的api查询；
如果传入了最大数量限制，则通过metadata过滤并按照时间倒序排列后得到主机快照列表，过滤出状态为成功的主机快照列表，判断主机是从镜像启动bfi还是从卷启动bfv，如果主机是从卷启动bfv，则需要维护cinder的snapshot和glance的image两种资源数量；
如果主机是从镜像启动bfi，则只需要删除掉glance的image。
5.根据权利要求4所述的基于云平台工作流的资源定时快照与备份实现方法，其特征在于，所述S3步骤的文件共享定时快照action实现逻辑包括：
S331、通过特定命名方式实现一个share文件共享至多有一个文件共享定时快照策略；
S332、根据前端传入的share的id调用manila的api查找到对应的文件共享，调用manila的api创建文件共享快照，使用description＝”created_by_policy”来区别用户创建的文件共享定时快照与策略创建的文件共享定时快照；
S333、快照创建完成后根据max_snapshots来判断是否需要进行删除冗余快照的逻辑，如果max_snapshots为None，则不需要删除任何快照，如果max_snapshots不为None，则需要通过manila api来list出所有当前share id的snapshots列表，通过description和状态过滤出成功的快照列表，进行清理逻辑的处理，清理逻辑需要至少保留一个成功状态的快照。
6.根据权利要求1所述的基于云平台工作流的资源定时快照与备份实现方法，其特征在于，所述S1步骤的所述输入参数包括：
类型、执行次数、执行频率、保留规则、保留数量中的一种或多种的组合。
7.根据权利要求4所述的基于云平台工作流的资源定时快照与备份实现方法，其特征在于，所述S321步骤的所述实例定时快照策略的action接收的参数包括：
Instance的id、image_name、max_snapshots、root_disk_only、instance_stop、action_region。
8.根据权利要求5所述的基于云平台工作流的资源定时快照与备份实现方法，其特征在于，所述S331步骤的所述文件共享定时快照策略的action接收的参数包括：
share的id、name、force、max_snapshots、action_region。
9.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述程序被处理器执行时实现权利要求1-8任一项所述的基于云平台工作流的资源定时快照与备份实现方法。
10.一种计算机设备，所述计算机设备包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现如权利要求1-8任一项所述的基于云平台工作流的资源定时快照与备份实现方法。
CN202310906932.1A 2023-07-24 2023-07-24 一种基于云平台工作流的资源定时快照与备份实现方法 Pending CN116893932A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310906932.1A CN116893932A (zh) 2023-07-24 2023-07-24 一种基于云平台工作流的资源定时快照与备份实现方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310906932.1A CN116893932A (zh) 2023-07-24 2023-07-24 一种基于云平台工作流的资源定时快照与备份实现方法

Publications (1)

Publication Number Publication Date
CN116893932A true CN116893932A (zh) 2023-10-17

Family

ID=88310588

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310906932.1A Pending CN116893932A (zh) 2023-07-24 2023-07-24 一种基于云平台工作流的资源定时快照与备份实现方法

Country Status (1)

Country Link
CN (1) CN116893932A (zh)

Similar Documents

Publication Publication Date Title
CN108683516B (zh) 一种应用实例的升级方法、装置和系统
US10572156B2 (en) Capacity forecasting based on capacity policies and transactions
US9852204B2 (en) Read-only operations processing in a paxos replication system
CN111143133B (zh) 虚拟机备份方法和备份虚拟机恢复方法
CN110427258B (zh) 基于云平台的资源调度控制方法及装置
CN112463450A (zh) 一种增量备份管理方法、系统、电子设备及存储介质
CN113760513A (zh) 一种分布式任务调度方法、装置、设备和介质
CN106874343B (zh) 一种时序数据库的数据删除方法及系统
CN109902028A (zh) Acl特性的自动化测试方法、装置、设备及存储介质
CN109697112B (zh) 分布式集约化一站式作业系统和实现方法
CN113515317A (zh) 数据恢复的方法、装置
WO2000063801A1 (en) Managed remote virtual mass storage for client data terminal
CN107632926B (zh) 业务数量统计方法、装置、设备及计算机可读存储介质
CN116701063B (zh) 数联网数据语用内存状态数据的持久化方法、装置及系统
CN116881012A (zh) 一种容器应用垂直扩容方法、装置、设备及可读存储介质
KR101888131B1 (ko) Dds-dbms 연동 도구의 실시간 변경 데이터 발간 서비스 수행 방법
CN116893932A (zh) 一种基于云平台工作流的资源定时快照与备份实现方法
CN114201284A (zh) 定时任务管理方法及系统
JPH06214809A (ja) 計算機システム
US11687269B2 (en) Determining data copy resources
CN114327414B (zh) 节点可插拨的触发器实现方法及计算机可读存储介质
CN115964353B (zh) 一种分布式文件系统及其访问计量方法
WO2024078211A1 (zh) 业务集群实例的备份和恢复方法以及相关设备
CN115202979A (zh) 一种sql实时监控方法、系统、电子设备及存储介质
JP2016088057A (ja) 情報処理装置、情報処理装置の制御方法、及びプログラム

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination