A resource timing snapshot and backup implementation method based on a cloud platform workflow

Abstract

The application provides a kind of resource timing snapshot and backup implementation method based on cloud platform workflow, including through cron-trigger in Mistral of Openstack, specified action is specified, input parameter is received, and timing execution strategy is constructed;Custom action is created to execute snapshot or backup;According to the four kinds of implementation logic of action designed according to the custom access scheme provided by Mistral: volume timing backup;Volume timing snapshot;Instance timing snapshot;File sharing timing snapshot.The application can realize the demand of timing task in cloud platform, including realizing the timing execution strategy of four kinds of resources of timing volume timing snapshot, volume timing backup, instance timing snapshot, file sharing timing backup, and users can select execution period to realize the periodic backup or snapshot of cloud platform resources, to realize the automatic process of cloud platform resource backup and snapshot.

Description

Technical Field

[0001] This invention relates to the field of cloud computing platform technology, and more specifically, to a method for implementing scheduled resource snapshots and backups based on cloud platform workflows. Background Technology

[0002] OpenStack is an open-source cloud computing management platform project, a combination of a series of open-source software projects. OpenStack consists of several main components that work together to perform specific tasks, aiming to provide scalable and elastic cloud computing services for private and public clouds.

[0003] OpenStack covers various aspects including networking, virtualization, operating systems, and servers. It is a cloud computing platform project under development, which is broken down into core projects, incubation projects, support projects, and related projects based on their maturity and importance. Moreover, each project is not static; for example, incubation projects can be transformed into core projects based on their maturity and importance.

[0004] Mistrial is a workflow component developed by mirantis for OpenStack, providing WorkFlowasaservice. Typical user use cases include cloud platform task scheduling services (Cloud Cron), task scheduling, and complex, long-running business process services.

[0005] The main technical terms in Mistrial and their meanings include:

[0006] Task: This refers to the specific steps in the workflow. It can be a collection of actions.

[0007] Action: This is the smallest unit of a Mistral, specifically referring to a particular task, such as sending an HTTP request or running a command.

[0008] Flow: Workflow refers to how tasks are executed, task dependencies are resolved, etc., in the Mistral system so that tasks can be successfully completed and return a status.

[0009] WorkFlowExecution: Workflow execution record. It refers to a specific Flow. The WorkFlowExecution generated by each Task execution is permanently stored in the database for easy retrieval or re-execution of the Flow.

[0010] However, as users spend more time using cloud platforms, the need for data backup and recovery arises, including volume backup and volume snapshots, instance backup, and file share backup. Currently, without platform-level support for block storage backup, file storage backup, and instance recovery, users primarily perform business-related data backups. Summary of the Invention

[0011] Therefore, the purpose of this invention is to address the need for scheduled backup and snapshots of cloud platform resources, including four types: scheduled snapshots of cloud hosts, scheduled backups of cloud disks, scheduled snapshots of cloud disks, and scheduled snapshots of file sharing. The scheduled execution period can be specified through the panel, and the periodic tasks can be executed periodically through custom actions and specified inputs on the user's front-end panel.

[0012] To facilitate backup or snapshotting of resources at these levels and to enable planned backup and snapshot tasks, this invention proposes customized action and workflow development tasks for instance snapshots, volume backups, volume snapshots, and file-shared snapshots, thereby meeting users' needs for planned backup and snapshotting of different resources.

[0013] The main implementation of this invention utilizes the cron-trigger from the OpenStack community project Mistral in conjunction with a workflow to achieve the function of scheduled execution strategies. Additionally, the workflow requires specifying a particular action and receiving input parameters, including but not limited to type (repeated execution or execution only N times), execution count (effective only when execution only N times is selected), execution frequency (period and time), retention rules (by quantity or permanent retention), and retention quantity (effective only when the retention rule is retention by quantity). The action is used to execute snapshots or backups; that is, a custom action that deletes the least timely snapshot or backup resource when the snapshot or backup reaches the user-specified limit.

[0014] This invention provides a method for implementing scheduled resource snapshots and backups based on cloud platform workflows, comprising the following steps:

[0015] S1. Using the cron-trigger in the Mistral project of the OpenStack community in conjunction with the workflow, specify a specific action, add input parameters to the action attribute, and build a scheduled execution strategy;

[0016] S2. Create a custom action that performs snapshots or backups and deletes the worst-timed snapshot or backup resource when the snapshot or backup reaches the user-specified limit.

[0017] S3. Based on the custom access scheme provided by the Mistral project, design the implementation logic of the action. The implementation logic of the action includes the following four types:

[0018] (1) Implementation logic for scheduled volume backup action;

[0019] (2) Volume timed snapshot action implementation logic;

[0020] (3) Implementation logic for instance timed snapshot action;

[0021] (4) File sharing timed snapshot action implementation logic.

[0022] Furthermore, the volume timed backup action implementation logic in step S3 includes the following steps:

[0023] S311. Create a backup strategy in the mistral project. Implement a maximum of one backup strategy per volume cloud disk through a specific naming method. Define a scheduled workflow for creating a backup strategy through the UI interface.

[0024] S312. Check if the volume cloud disk exists and the status of the volume. Query the database to see if the volume_id of the volume exists. If the volume_id does not exist, return an error; if it exists, continue to check the status of the volume. Only volumes in-use and available can be backed up.

[0025] S313. Distinguish between user-created backups and backups created by backup policies, so that user-created backups are not deleted when old backups are deleted. Add metadata “created_by_policy” = “True” to the backups created by the backup policies, so that the backups created by the backup policies have this metadata, while the backups created by the users do not.

[0026] S314. Create a backup using a backup strategy and obtain the returned result data. The result data includes backup information, and the backup status can be determined using the backup information.

[0027] S315. Determine if max_backups is None. If it is None, it will be permanently retained. There is no need to check the number of backups or delete old backups.

[0028] If max_backups is not None, then the number of backups to retain is determined; if the maximum number of backups is exceeded, then the corresponding old backups are deleted (this logic only takes effect if the user selects a retention rule based on quantity); the logic for cleaning up redundant backups is to query all backups in the database by calling the Cinder API, and use metadata and status filtering conditions to obtain a list of all successful backups created by the current backup strategy, sorted in descending order by time, called backup_list (all backups have the status of available);

[0029] If only one backup strategy has successfully created a backup at this time, at least one successful backup must be retained, and the deletion operation cannot be performed.

[0030] If two or more backup strategies have successfully created backups at this time, the list length and max_backups are compared. If the list length is greater than max_backups, then redundancy = len(backup_list) - max_backups. The redundancy record records the number of old backups that should be deleted. A for loop pop(backup_list) is used to get the data that should be deleted. At the same time, the Cinder API is called to delete the popped data in the for loop. When the for loop ends, the number of backups in the database is restored to max_backups.

[0031] Furthermore, the implementation logic of the volume timed snapshot action in step S3 includes:

[0032] The only difference between the implementation logic of the volume timed snapshot action and the implementation logic of the volume timed backup action is that the metadata of the implementation logic of the volume timed snapshot action is "volume_time_snapshot": "True", which is used to distinguish between user-created snapshots and snapshots automatically created by the timed policy, in order to maintain the maximum number of snapshots.

[0033] The rest of the logic for the volume timed snapshot action is the same as the logic for the volume timed backup action.

[0034] Furthermore, the instance timed snapshot action implementation logic in step S3 includes the following steps:

[0035] S321. Implement a timed snapshot strategy for an instance using a specific naming method;

[0036] S322. Obtain the instance in nova based on the instance parameter passed from the front end, and implement the shutdown operation logic of the instance based on the instance status and the instance_stop parameter.

[0037] S323. Determine whether to perform snapshot operation only on the root disk based on root_disk_only. If to perform snapshot operation only on the root disk, call the Cinder API to fulfill the requirement of creating a snapshot (similar to the task that implements the logic of volume timed snapshot action. To easily distinguish between user-created instance timed snapshots and policy task-created instance timed snapshots, metadata is still used here to differentiate them).

[0038] S324. The subsequent logic is consistent with the volume timed snapshot action implementation logic, only maintaining the number of Cinder snapshots; if root_disk_only = False, then call the Nova API to create an instance image to implement the instance snapshot function. The image created by Nova needs to be queried using the Glance API.

[0039] If a maximum number limit is passed in, the host snapshot list is obtained by filtering through metadata and sorting in reverse chronological order. The host snapshot list with a successful status is filtered out, and it is determined whether the host is booting BFI from an image or BFV from a volume. If the host is booting BFV from a volume, the number of Cinder snapshots and Glance images needs to be maintained.

[0040] If the host boots BFI from an image, then you only need to delete the glance image.

[0041] Furthermore, the file-sharing timed snapshot action implementation logic in step S3 includes:

[0042] S331. Implement a shared file sharing strategy with at most one scheduled snapshot through a specific naming method;

[0043] S332. Based on the share ID passed from the front end, call the Manila API to find the corresponding file share, and call the Manila API to create a file share snapshot. Unlike the volume timed snapshot action implementation logic, Manila file share snapshots do not support the metadata option, so description="created_by_policy" is used here to distinguish between user-created timed file share snapshots and policy-created timed file share snapshots.

[0044] S333. After snapshot creation, determine whether redundant snapshots need to be deleted based on max_snapshots. If max_snapshots is None, no snapshots need to be deleted (user-selected to retain them permanently). If max_snapshots is not None, list all snapshots for the current shareid using manilaapi, filter the successful snapshot list by description and status, and perform cleanup logic. The cleanup logic must retain at least one snapshot in a successful state.

[0045] Further, the input parameters in step S1 include:

[0046] A combination of one or more of the following: type (repeated execution or execution only N times), number of executions (effective only if execution only N times is selected), execution frequency (period and time), retention rule (by quantity or permanent retention), and retention quantity (effective only if the retention rule is retention by quantity).

[0047] Furthermore, the parameters received by the action of the instance timed snapshot policy in step S321 include:

[0048] The parameters include: instance (representing the instance to be periodically snapshotted, receiving an ID), image_name (user-specified instance snapshot name, can be empty and will be automatically generated), max_snapshots (user-selected maximum number of snapshots to retain, default value is 5), root_disk_only (default value is False, if True will only perform snapshot operation on the system disk, if False will perform image operation on the entire machine), instance_stop (whether to shut down, default value is False), action_region, and other necessary parameters.

[0049] Furthermore, the parameters received by the action of the file-sharing timed snapshot policy in step S331 include:

[0050] The necessary parameters include share (file share ID), name (default is None, users can specify the name of the file share snapshot created by the strategy), force (the option to force snapshots in glanceapi), max_snapshots (maximum number of file share snapshots, default value is 5), and action_region.

[0051] The key technical point of this invention is to use Mistral's cron-trigger in conjunction with WorkFlow to implement periodic resource backup or snapshot tasks. In order to match the business, a custom action is designed to implement one of the tasks in the periodic task.

[0052] The present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the resource timed snapshot and backup implementation method based on cloud platform workflow as described above.

[0053] The present invention also provides a computer device, the computer device including a memory, a processor and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, it implements the resource timed snapshot and backup implementation method based on cloud platform workflow as described above.

[0054] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0055] This invention can meet the needs of scheduled tasks in cloud platforms, including the implementation of four scheduled execution strategies for resources: scheduled volume snapshots, scheduled volume backups, scheduled instance snapshots, and scheduled file share backups. Users can choose the execution period to achieve periodic backups or snapshots of cloud platform resources, thus automating the process of cloud platform resource backup and snapshots. Attached Figure Description

[0056] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention.

[0057] In the attached diagram:

[0058] Figure 1 This is a flowchart illustrating a method for implementing scheduled resource snapshots and backups based on cloud platform workflow according to the present invention.

[0059] Figure 2 This is a flowchart illustrating the logic of the volume timed backup action implementation in an embodiment of the present invention.

[0060] Figure 3 This is a flowchart illustrating the implementation logic of the timed snapshot action in an embodiment of the present invention.

[0061] Figure 4 This is a flowchart illustrating the implementation logic of the file sharing timed snapshot action in an embodiment of the present invention.

[0062] Figure 5 This is a flowchart illustrating the creation of a timing strategy according to an embodiment of the present invention.

[0063] Figure 6 This is a flowchart illustrating the volume timed backup action logic of an embodiment of the present invention.

[0064] Figure 7 This is a flowchart illustrating the volume timed snapshot action logic of an embodiment of the present invention.

[0065] Figure 8 This is a flowchart illustrating the timed snapshot action logic of an embodiment of the present invention.

[0066] Figure 9 This is a flowchart illustrating the file sharing timed snapshot action logic of an embodiment of the present invention.

[0067] Figure 10 This is a schematic diagram of the configuration of a computer device according to an embodiment of the present invention. Detailed Implementation

[0068] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and products consistent with some aspects of this disclosure as detailed in the appended claims.

[0069] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The singular forms “a,” “the,” and “the” as used in this disclosure and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.

[0070] It should be understood that although the terms first, second, third, etc., may be used in this disclosure to describe various information, such information should not be limited to these terms. These terms are used only to distinguish information of the same type from one another. For example, without departing from the scope of this disclosure, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."

[0071] The embodiments of the present invention will be further described in detail below with reference to the accompanying drawings.

[0072] This invention provides a method for implementing scheduled resource snapshots and backups based on cloud platform workflows. See [link to relevant documentation]. Figure 1 As shown, it includes the following steps:

[0073] S1. Using the cron-trigger in the Mistral project of the OpenStack community in conjunction with the workflow, specify a specific action, add input parameters to the action attribute, and build a scheduled execution strategy;

[0074] In this embodiment, the input parameters include:

[0075] Type (repeated execution or execution only N times), number of executions (only effective if execution only N times is selected), execution frequency (cycle and time), retention rule (by quantity or permanent retention), number of retentions (only effective if the retention rule is retention by quantity).

[0076] See Figure 5 The diagram shows the process for creating a timed execution strategy in this embodiment;

[0077] S2. Create a custom action that performs snapshots or backups and deletes the worst-timed snapshot or backup resource when the snapshot or backup reaches the user-specified limit.

[0078] S3. Based on the custom access scheme provided by the Mistral project, design the implementation logic of the action. The implementation logic of the action includes the following four types:

[0079] (1) Implementation logic for scheduled volume backup action;

[0080] (2) Volume timed snapshot action implementation logic;

[0081] (3) Implementation logic for instance timed snapshot action;

[0082] (4) File sharing timed snapshot action implementation logic.

[0083] The logic for the volume timed backup action is described in [reference]. Figure 2 As shown, it includes the following steps:

[0084] S311. Create a backup strategy in the mistral project. Implement a maximum of one backup strategy per volume cloud disk through a specific naming method. Define a scheduled workflow for creating a backup strategy through the UI interface.

[0085] S312. Check if the volume cloud disk exists and the status of the volume. Query the database to see if the volume_id of the volume exists. If the volume_id does not exist, return an error; if it exists, continue to check the status of the volume. Only volumes in-use and available can be backed up.

[0086] S313. Distinguish between user-created backups and backups created by backup policies. Add metadata “created_by_policy” = “True” to the backups created by the backup policies, so that the backups created by the backup policies have this metadata, while the backups created by users do not have this metadata.

[0087] S314. Create a backup using a backup strategy and obtain the returned result data. The result data includes backup information, and the backup status can be determined using the backup information.

[0088] S315. Determine if max_backups is None. If it is None, it will be permanently retained. There is no need to check the number of backups or delete old backups.

[0089] If max_backups is not None, then the number of backups to retain is determined; if the maximum number of backups is exceeded, then the corresponding old backups are deleted (this logic only takes effect if the user selects a retention rule based on quantity); the logic for cleaning up redundant backups is to query all backups in the database by calling the Cinder API, and use metadata and status filtering conditions to obtain a list of all successful backups created by the current backup strategy, sorted in descending order by time, called backup_list (all backups have the status of available);

[0090] If only one backup strategy has successfully created a backup at this time, at least one successful backup must be retained, and the deletion operation cannot be performed.

[0091] If two or more backup strategies have successfully created backups at this time, the list length and max_backups are compared. If the list length is greater than max_backups, then redundancy = len(backup_list) - max_backups. The redundancy record records the number of old backups that should be deleted. A for loop pop(backup_list) is used to get the data that should be deleted. At the same time, the Cinder API is called to delete the popped data in the for loop. When the for loop ends, the number of backups in the database is restored to max_backups.

[0092] See Figure 6 The following is the logic flow of the volume timed backup action in this embodiment.

[0093] The logic for implementing the volume timed snapshot action includes:

[0094] The only difference between the implementation logic of the volume timed snapshot action and the implementation logic of the volume timed backup action is that the metadata of the implementation logic of the volume timed snapshot action is "volume_time_snapshot": "True", which is used to distinguish between user-created snapshots and snapshots automatically created by the timed policy, in order to maintain the maximum number of snapshots.

[0095] The rest of the logic for the volume timed snapshot action is the same as the logic for the volume timed backup action.

[0096] See Figure 7 The following is the volume timed snapshot action logic flow of this embodiment.

[0097] The implementation logic of the instance's timed snapshot action can be found in [link / reference]. Figure 3 As shown, it includes the following steps:

[0098] S321. Implement a timed snapshot strategy for an instance using a specific naming method;

[0099] The parameters that the Action receives are:

[0100] The instance's ID (representing the instance to be periodically snapshotted; receives an ID).

[0101] image_name (user-specified instance snapshot name, can be empty and will be automatically generated),

[0102] max_snapshots (the maximum number of snapshots to retain, default value is 5)

[0103] rootdisk_only (default value is False. If True, snapshot operations will only be performed on the system disk; if False, the entire machine will be imaged.)

[0104] Some necessary parameters include instance_stop (whether to shut down, defaults to False) and action_region;

[0105] S322. Obtain the instance in nova based on the instance parameter passed from the front end, and implement the shutdown operation logic of the instance based on the instance status and the instance_stop parameter.

[0106] S323. Determine whether to perform snapshot operation only on the root disk based on root_disk_only. If to perform snapshot operation only on the root disk, call the Cinder API to fulfill the requirement of creating a snapshot (similar to the task that implements the logic of volume timed snapshot action. To easily distinguish between user-created instance timed snapshots and policy task-created instance timed snapshots, metadata is still used here to differentiate them).

[0107] S324. The subsequent logic is consistent with the volume timed snapshot action implementation logic, only maintaining the number of Cinder snapshots; if root_disk_only = False, then call the Nova API to create an instance image to implement the instance snapshot function. The image created by Nova needs to be queried using the Glance API.

[0108] If a maximum number limit is passed in, the host snapshot list is obtained by filtering through metadata and sorting in reverse chronological order. The host snapshot list with a successful status is filtered out, and it is determined whether the host is booting BFI from an image or BFV from a volume. If the host is booting BFV from a volume, the number of Cinder snapshots and Glance images needs to be maintained.

[0109] If the host boots BFI from an image, then you only need to delete the glance image.

[0110] See Figure 8 The following is the instance timed snapshot action logic flow of this embodiment.

[0111] The implementation logic for the file sharing timed snapshot action is described in [link / reference]. Figure 4 As shown, it includes the following steps:

[0112] S331. Implement a shared file sharing strategy with at most one scheduled snapshot through a specific naming method;

[0113] The parameters accepted by the file sharing timed snapshot action are:

[0114] The ID of the share (the ID of the file share)

[0115] name (defaults to None; users can specify the name of the file-sharing snapshot created by the policy),

[0116] `force` (an option in `glanceapi` to force a snapshot), `max_snapshots` (the maximum number of file-shared snapshots, default value is 5).

[0117] Some necessary parameters, such as action_region;

[0118] S332. Based on the share ID passed from the front end, call the Manila API to find the corresponding file share, and call the Manila API to create a file share snapshot. Unlike the volume timed snapshot action implementation logic, Manila file share snapshots do not support the metadata option, so description="created_by_policy" is used here to distinguish between user-created timed file share snapshots and policy-created timed file share snapshots.

[0119] S333. After snapshot creation, determine whether redundant snapshots need to be deleted based on max_snapshots. If max_snapshots is None, no snapshots need to be deleted (user-selected to retain them permanently). If max_snapshots is not None, list all snapshots for the current shareid using manilaapi, filter the successful snapshot list by description and status, and perform cleanup logic. The cleanup logic must retain at least one snapshot in a successful state.

[0120] See Figure 9 The following is the logical flow of the file sharing timed snapshot action in this embodiment.

[0121] This invention also provides a computer device. Figure 10 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention; see the accompanying drawings. Figure 10As shown, the computer device includes: an input device 23, an output device 24, a memory 22, and a processor 21; the memory 22 is used to store one or more programs; when the one or more programs are executed by the one or more processors 21, the one or more processors 21 implement the resource timed snapshot and backup implementation method based on OpenStack Mistral provided in the above embodiments; wherein the input device 23, the output device 24, the memory 22, and the processor 21 can be connected via a bus or other means. Figure 10 Taking the example of a connection between China and Israel via a bus.

[0122] The memory 22, as a read / write storage medium for a computing device, can be used to store software programs and computer-executable programs, such as the program instructions corresponding to the resource timed snapshot and backup implementation method based on OpenStack Mistral described in this embodiment of the invention. The memory 22 may mainly include a program storage area and a data storage area. The program storage area may store the operating system and at least one application program required for a function; the data storage area may store data created according to the use of the device, etc. Furthermore, the memory 22 may include high-speed random access memory and non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some instances, the memory 22 may further include memory remotely located relative to the processor 21, and these remote memories can be connected to the device via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0123] Input device 23 can be used to receive input digital or character information, and generate key signal inputs related to user settings and function control of the device; output device 24 may include display devices such as a display screen.

[0124] The processor 21 executes various functional applications and data processing of the device by running software programs, instructions and modules stored in the memory 22, thereby realizing the above-mentioned resource timed snapshot and backup implementation method based on OpenStackMistral.

[0125] The computer equipment provided above can be used to execute the resource timed snapshot and backup implementation method based on OpenStack Mistral provided in the above embodiments, and has corresponding functions and beneficial effects.

[0126] This invention also provides a storage medium containing computer-executable instructions, which, when executed by a computer processor, are used to execute the resource timed snapshot and backup implementation method based on OpenStack Mistral provided in the above embodiments. The storage medium can be any type of memory device or storage device, including: mounting media such as CD-ROM, floppy disk, or magnetic tape; computer system memory or random access memory such as DRAM, DDRRAM, SRAM, EDORAM, Rambus RAM, etc.; non-volatile memory such as flash memory, magnetic media (e.g., hard disk or optical storage); registers or other similar types of memory elements; the storage medium may also include other types of memory or combinations thereof; furthermore, the storage medium may reside in a first computer system in which the program is executed, or it may reside in a different second computer system connected to the first computer system via a network (such as the Internet); the second computer system can provide program instructions to the first computer for execution. The storage medium includes two or more storage media that can reside in different locations (e.g., in different computer systems connected via a network). The storage medium can store program instructions (e.g., specifically implemented as a computer program) executable by one or more processors.

[0127] Of course, the computer-executable instructions provided in the embodiments of the present invention are not limited to the resource timed snapshot and backup implementation method based on OpenStackMistral as described in the above embodiments, but can also execute related operations in the resource timed snapshot and backup implementation method based on OpenStackMistral provided in any embodiment of the present invention.

[0128] The technical solution of the present invention has been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it will be readily understood by those skilled in the art that the scope of protection of the present invention is obviously not limited to these specific embodiments. Without departing from the principles of the present invention, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after these changes or substitutions will all fall within the scope of protection of the present invention.

[0129] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for implementing scheduled resource snapshots and backups based on cloud platform workflows, characterized in that, Includes the following steps: S1. Using the cron-trigger in the Mistral project of the OpenStack community in conjunction with the workflow, specify a specific action, add input parameters to the action attribute, and build a scheduled execution strategy; S2. Create a custom action that performs snapshots or backups and deletes the worst-timed snapshot or backup resource when the snapshot or backup reaches the user-specified limit. S3. Based on the custom access scheme provided by the Mistral project, design the implementation logic of the action. The implementation logic of the action includes the following four types: (1) Implementation logic for scheduled volume backup action; (2) Volume timed snapshot action implementation logic; (3) Implementation logic for instance timed snapshot action; (4) File sharing timed snapshot action implementation logic; The volume timed backup action implementation logic in step S3 includes the following steps: S311. Create a backup strategy in the mistral project. Implement a maximum of one backup strategy per volume cloud disk through a specific naming method. Define a scheduled workflow for creating a backup strategy through the UI interface. S312. Check if the volume cloud disk exists and the status of the volume. Query the database to see if the volume_id of the volume exists. If the volume_id does not exist, return an error; if it exists, continue to check the status of the volume. Only volumes in-use and available can be backed up. S313. Distinguish between user-created backups and backups created by backup policies. Add metadata “created_by_policy” = “True” to the backups created by the backup policies, so that the backups created by the backup policies have this metadata, while the backups created by users do not have this metadata. S314. Create a backup using a backup strategy and obtain the returned result data. The result data includes backup information, and the backup status can be determined using the backup information. S315. Determine if max_backups is None. If it is None, it will be permanently retained. There is no need to check the number of backups or delete old backups. If max_backups is not None, then the number of backups to retain is determined; if the maximum number of backups is exceeded, then the corresponding old backups are deleted; the logic for cleaning up redundant backups is to query all backups in the database by calling the Cinder API, and use metadata and status filtering conditions to obtain a list of all successful backups created by the current backup strategy, which is sorted in descending order by time: backup_list. If only one backup strategy has successfully created a backup at this time, at least one successful backup must be retained, and the deletion operation cannot be performed. If two or more backup strategies have successfully created backups at this time, the list length and max_backups are compared. If the list length is greater than max_backups, then redundancy = len(backup_list) - max_backups. The redundancy record records the number of old backups that should be deleted. A for loop pop(backup_list) is used to get the data that should be deleted. At the same time, the Cinder API is called to delete the popped data in the for loop. When the for loop ends, the number of backups in the database is restored to max_backups. The implementation logic of the volume timed snapshot action in step S3 includes: The only difference between the implementation logic of the volume timed snapshot action and the implementation logic of the volume timed backup action is that the metadata of the implementation logic of the volume timed snapshot action is "volume_time_snapshot": "True", which is used to distinguish between user-created snapshots and snapshots automatically created by the timed policy, in order to maintain the maximum number of snapshots. The other logic of the volume timed snapshot action is the same as the logic of the volume timed backup action. The instance timed snapshot action implementation logic in step S3 includes the following steps: S321. Implement a timed snapshot strategy for an instance by using a specific naming method; S322. Obtain the instance in nova based on the instance parameter passed from the front end, and implement the shutdown operation logic of the instance based on the instance status and the instance_stop parameter. S323. Determine whether to perform snapshot operation only on the root disk based on root_disk_only. If to perform snapshot operation only on the root disk, call the Cinder API to fulfill the requirement of creating a snapshot. S324. The subsequent logic is consistent with the volume timed snapshot action implementation logic, only maintaining the number of Cinder snapshots; if root_disk_only = False, then call the Nova API to create an instance image to implement the instance snapshot function. The image created by Nova needs to be queried using the Glance API. If a maximum number limit is passed in, the host snapshot list is obtained by filtering through metadata and sorting in reverse chronological order. The host snapshot list with a successful status is filtered out, and it is determined whether the host is booting BFI from an image or BFV from a volume. If the host is booting BFV from a volume, the number of Cinder snapshots and Glance images needs to be maintained. If the host boots BFI from an image, then you only need to delete the glance image; The file-sharing timed snapshot action implementation logic in step S3 includes: S331. Implement a timed snapshot strategy for a shared file system by using a specific naming method, where a shared file system can have at most one shared file system. S332. Based on the share ID passed from the front end, call the Manila API to find the corresponding file share, call the Manila API to create a file share snapshot, and use description="created_by_policy" to distinguish between user-created timed file share snapshots and policy-created timed file share snapshots. S333. After snapshot creation, determine whether redundant snapshots need to be deleted based on max_snapshots. If max_snapshots is None, no snapshots need to be deleted. If max_snapshots is not None, list all snapshots for the current shareid using manilaapi, filter the list of successful snapshots by description and status, and perform cleanup logic. The cleanup logic must retain at least one snapshot in a successful state.

2. The method for implementing scheduled resource snapshots and backups based on cloud platform workflows according to claim 1, characterized in that, The input parameters for step S1 include: A combination of one or more of the following: type, number of executions, execution frequency, retention rules, and retention quantity.

3. The method for implementing scheduled resource snapshots and backups based on cloud platform workflows according to claim 1, characterized in that, The parameters received by the action of the instance timed snapshot policy in step S321 include: Instance's id, image_name, max_snapshots, root_disk_only, instance_stop, action_region.

4. The method for implementing scheduled resource snapshots and backups based on cloud platform workflows according to claim 1, characterized in that, The parameters received by the action of the file-sharing timed snapshot policy in step S331 include: share's id, name, force, max_snapshots, action_region.

5. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the resource timed snapshot and backup method based on cloud platform workflow as described in any one of claims 1-4.

6. A computer device, the computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the resource timed snapshot and backup method based on cloud platform workflow as described in any one of claims 1-4.

Images