CN110737510B - block device management system - Google Patents

Abstract

The embodiments of the present disclosure disclose a block device management system. The block device management system includes: a client and an application program interface; the block device management system further includes: an executor configured to submit tasks to the block device service manager module and query submitted tasks, obtain tasks from an in-memory database and report tasks state; and an in-memory database configured to perform metadata storage, management jobs and tasks for device snapshots and data volumes. The block device management system improves the fault tolerance of block device management on the virtual machine side and reduces operation and maintenance costs.

Description

block device management system

technical field

The present disclosure relates to the field of computer technologies, in particular to the field of cloud computing technologies, and in particular to a block device management system.

Background technique

In cloud computing, virtual machine virtualization technology includes three parts: computing virtualization, storage virtualization and network virtualization. In terms of storage virtualization, the industry gradually adopts the method of realizing block device virtualization based on distributed storage systems. The management of block devices includes two parts: data management of block devices on the storage side, including cloud storage block data in distributed file systems. management; and block device management on the virtual machine side, including the life cycle and operation management of block devices.

The block device management on the virtual machine side involves relationship management between two resources, the virtual machine and the block device. For example, when a block device is bound and unbound in a virtual machine, if the respective states of the two cannot be accurately synchronized, the metadata of the virtual machine and the block device may be inconsistent; when the block device is used alone, there are many operations, and different operation requests need to have Good fault tolerance mechanism.

Specifically, the current implementation solution for managing block devices on the virtual machine side is a block device management system (Cinder) module in OpenStack. The Cinder module includes five components: application program interface (Cinder-API), scheduler (Cinder-Scheduler), local agent node (Cinder-Volume), relational database management system (MySQL) and client (Cinder Client). The communication between modules uses the AMQP protocol, and the technology is implemented as object-oriented message middleware (Qpid).

The five components of the Cinder module are described below:

The application program interface is used to accept the HTTP request initiated by the client and the computing server (Nova Computer) (importing the client module) to perform user identity verification and message distribution. It uses the Web Server Gateway Interface (WSGI) service to provide Web services, operating Core resources and extended resources, involving the interaction with the database (DB), data volume (Volume, referring to block devices) and scheduler (Scheduler).

The scheduler is used to process the message when the backend service is not specified, and schedule a qualified backend service for the message. The scheduling includes two processes of filter (Filters) and weighting (Weighting). The scheduler is also a WSGI service that consumes scheduling messages produced by the API from Qpid after startup.

For different types of block devices, the local proxy node loads the corresponding driver (Driver) according to the type of the data volume for adaptation regardless of whether it is connected using the Network File System (NFS) or iSCSI protocol. Requests include adding, deleting and expanding data volumes, mounting and unmounting, and creating and deleting snapshots.

MySQL and Cinder use databases to store runtime data, including back-end services, data volume-related data, mirror-related data, quota-related data, quality of service (QoS), and authentication-related data. Use the Object Relational Mapping (ORM) framework SQLAlchemy to connect and abstract (drive engine) back-end different database systems, and encapsulate the SQL toolkit based on the unified operation interface specified by Cinder/Cinder/db/api.py, and load it lazily at runtime Load the driver class corresponding to the database. (Cinder/db/sqlalchemy).

Client, encapsulates HTTP requests and provides command-line access to the application program interface, and provides two ways of using Shell and Python modules.

However, the above-mentioned implementation solution for managing block devices on the virtual machine side has the following problems:

The first is the problem of inter-service communication. Cinder uses HTTP protocol for external interaction, and AMQP (coexistence of asynchronous and synchronous communication) internally. Limited by the Qpid module, the positioning cost is relatively high when the Qpid message between the application program interface and the data volume times out. Internal communication also lacks a good retry fault tolerance mechanism. Once the communication fails, the business will feel it.

The second is the synchronization of resource state. The process of mounting and unmounting data volumes of a virtual machine is a transaction process, which involves the state machine flow (metadata update) of two resources in two modules (nova and Cinder). When the flow of one resource state machine is interrupted abnormally, it will trigger the state rollback process of another resource. In the end, it is necessary to ensure the correct association of the two resource states, and the cost of synchronization between modules is relatively high.

Again, it's a matter of functional boundaries. In the current environment, the management of some block devices has been completed in the virtual machine management service and the block device service. For example, the process of mounting and unmounting different back-end system disks, such as local system disks and cloud disks, has been implemented in the virtual machine management service. The block device service has implemented operations such as creating, deleting, and extending data volumes, mounting and unmounting data volumes, and creating, deleting, and rolling back snapshots.

Once again it is the version iteration problem of the database (DB). Migration controls the version of the database model (detailed changes caused by each version change are recorded in db/sqlalchemy/migrate_repo/versions/), and the version changes are recorded linearly in the form of 0xx_xxx. It is easy to cause conflict and lack of change records in multi-person collaborative development and response porting.

Finally, there is the issue of concurrency performance and foreign keys. Most of Cinder's tables have foreign keys, so when writing to the child table, a "shared lock" will be added to the parent table, thereby affecting the concurrent write performance of the parent table (without affecting the read performance). For example, when a data volume is created, the disk quota usage is calculated and the reservation information is updated. The two are the write operations to the user's disk quota usage information (quota_usages) and reservations (reservations) table, where the usage_id of the reservation table is a foreign key to the relative disk quota usage information. When a data volume creation request arrives, the disk quota usage information is written first, and then the reserved table is written. At this time, the table storage engine (InnoDB) locks the disk quota usage information and blocks the write request. When multiple data volume requests arrive, the above situation may easily lead to slow or even timeout of data volume creation.

SUMMARY OF THE INVENTION

Embodiments of the present disclosure provide a block device management system.

In a first aspect, an embodiment of the present disclosure provides a block device management system, including: a client and an application program interface; the block device management system further includes: an executor configured to submit tasks and queries to the block device service manager module Submitted tasks, fetching tasks and reporting task status from an in-memory database; and an in-memory database, configured to perform device snapshots and metadata storage for data volumes, and manage jobs and tasks.

In some embodiments, the in-memory database is further configured to: split various upstream requests into task lists, and assign the task lists to the executors for execution; the executors are further configured to: based on the tasks allocated from the in-memory database The task ID in the list tracks the status of the task indicated by the task ID in the client, including: if the task indicated by the task ID has not started, submit the task indicated by the task ID to the block device service manager, and track the task ID The status of the indicated task; if the task indicated by the task Id has been executed/completed, update the status of the task indicated by the task Id in the executor; and periodically report the heartbeat to the memory database, and the task Id in the memory of the executor is reported. The status of the indicated task is synchronized to the in-memory database.

In some embodiments, the state of the task in the executor includes: a task state identifier and a task action identifier; wherein, the task state identifier includes: not executed, in execution, execution failed, and executed successfully; the task action identifier includes: submit the task, Check tasks, empty.

In some embodiments, the executor is further configured to: before submitting the task indicated by the task Id, set the task status identifier of the task indicated by the task Id to not executed, and set the task action identifier of the task indicated by the task Id to be Empty; the task is acquired from an unexecuted queue, and the task action flag of the acquired task is set to submit the task, and the newly created coroutine is used to call the block device service client to submit the acquired task to the block device service manager; in response to the block device service client The returned submission result indicates that the task was submitted successfully, move the task indicated by the submission result from the unexecuted queue to the executing task queue, change the task status of the task indicated by the submission result to be under execution, and change the task indicated by the submission result. The action flag is empty; in response to the submission result returned by the block device service client indicating that the task submission failed, move the task indicated by the submission result from the unexecuted queue to the exit/failure queue, and retry submitting the submission result to the block device service manager. The indicated task; in response to the heartbeat response returned by the in-memory database indicating that the task has been consumed by the block device service but the status of the task has not been updated, and the task does not exist in the unprocessed task queue, add the task to the unprocessed task queue.

In some embodiments, in response to the submission result returned by the block device service client indicating that the task submission failed, moving the task from the unexecuted queue to the exit/failure queue, and retrying to submit the task to the block device service manager includes: responding to the block device service manager The submission result returned by the service client indicates that the task submission failed, the task indicated by the submission result is a task of creating a resource class, and the number of retries to submit the task indicated by the submission result to the block device service manager is less than the predetermined threshold, and the number of times indicated by the submission result is less than the predetermined threshold. Moves the tasks from the unexecuted queue to the exit/failure queue, retrying the task indicated by the commit result to the block device service manager.

In some embodiments, the executor is further configured to at least one of the following: in response to executing the timed polling task after submitting the task, set the task action flag of the submitted task to check the task, and send to the block device service manager A query request for the submitted task; in response to receiving the query result returned by the block device service manager based on the query request that the task is executing, keep the task status identifier of the submitted task unchanged, and set the task action of the submitted task The identification is empty; in response to receiving the query result returned by the block device service manager based on the query request, the task execution is successful, the task status identification of the submitted task is set to be executed successfully, and the task action identification of the submitted task is set to be empty; In response to receiving the query result returned by the block device service manager based on the query request that the task execution fails, the task status flag of the submitted task is set as execution failure, and the task action flag of the submitted task is set as null.

In some embodiments, the executor is further configured to: in response to the task submitted to the block device service manager being a preset task and the submission of the preset task is successful, set the task status flag of the submitted task to be executed successfully, and set the task status to be executed successfully. The task action identifier of the submitted task is empty; in response to the task submitted to the block device service manager being a preset task and the submission of the preset task fails, the task status identifier of the submitted task is set as execution failure, and the submitted task is set The task action ID of is empty.

In some embodiments, the executor is further configured to: send a heartbeat request to the in-memory database based on the pingpong mechanism, where the heartbeat request includes: a ping_id identifying the current number of requests, a synchronizing identifier identifying whether it is an initial request, identifying execution/successful execution/ The task list of tasks that failed to execute; the in-memory database is further configured to: return a heartbeat response to the executor, and the heartbeat response includes: pong_id identifying the number of next requests, unexecuted tasks/executing tasks, and exit/failed tasks corresponding to ping_id .

In some embodiments, the executor is further configured to perform at least one of the following: in response to receiving the heartbeat response, updating the ping_id to the pong_id in the heartbeat response, removing the exit/failure task identified in the heartbeat response from the exit/failure queue, responding to If there is no unexecuted task in the heartbeat response in the unexecuted queue in the executor, add the unexecuted task in the heartbeat response to the unexecuted queue in the executor; in response to the failure to send the heartbeat request, re-initiate the heartbeat to the in-memory database Request; in response to the successful sending of the heartbeat request but not receiving the heartbeat response within the preset time, use the ping_id of the heartbeat request that was successfully sent but did not receive the heartbeat response to re-send the heartbeat request to the in-memory database, and the re-sent heartbeat request identifies the execution The task list of tasks in progress/successfully executed/failed to execute is not necessarily the same as the task list of tasks in progress/successfully executed/failed to be identified in the heartbeat request sent successfully but no heartbeat response is received.

In some embodiments, the in-memory database is further configured to: cache a task list in the heartbeat request that identifies tasks in execution/successful/failed to be executed in the memory, in response to the ping_id of the received heartbeat request and the previously received heartbeat The ping_id of the request is the same, and it returns to the executor the task list of the previously received heartbeat request cached in memory.

In some embodiments, the executor is further configured to execute at least one of the following: use a newly created coroutine to obtain a task from an unexecuted queue; use the newly created coroutine to execute each timing task, and the timing task includes at least one of the following: timing: Report heartbeat, submit tasks regularly, and query task status regularly.

In some embodiments, RPC communication is used between the client and the application program interface, the in-memory database and the executor; HTTP communication is used between the client and the application program interface.

In some embodiments, the in-memory database includes: a service module of the block device management system, configured to receive heartbeat requests of the executor, data volumes of application programming interfaces, and snapshot operation requests; and a management module of the block device management system, configured to receive It can be used to process heartbeat requests of executors, data volumes of application programming interfaces, and snapshot operation requests.

In some embodiments, the in-memory database further includes: a service module for the data volume, a service module defined for the PB, and a CRUD interface for metadata of the data volume, configured to receive an operation request for the metadata of the data volume; The management module, managed by the database manager, is configured to persist operation requests for metadata of the data volume, and to store and update the metadata of the data volume.

In some embodiments, the in-memory database further includes: a service module for snapshots, a service module defined for PB, a CRUD interface for metadata of snapshots, configured to receive operation requests for metadata of snapshots; a management module for snapshots, composed of The database manager manages, is configured to persist operation requests on the metadata of the snapshot, stores and updates the metadata of the snapshot.

In a second aspect, embodiments of the present disclosure provide an electronic device/terminal/server, including: one or more processors; a storage device for storing one or more programs; The processor executes such that the one or more processors implement the block device management system as described in any of the above.

In a third aspect, an embodiment of the present disclosure provides a computer-readable medium on which a computer program is stored, and when the program is executed by a processor, implements the block device management system described above.

The block device management system provided by the embodiments of the present disclosure includes: a client and an application program interface; the block device management system further includes: an executor, configured to submit tasks to the block device service manager module and query the submitted tasks, from An in-memory database that captures tasks and reports task status; and an in-memory database that is configured to perform device snapshots and metadata storage for data volumes, and manage jobs and tasks. In this process, based on the client and application program interfaces included in the original block device management system, the newly added executor (Executor) is a stateless component, so all operations support fault tolerance. Based on this feature, the back-end system upgrade process can be insensitive to users; at the same time, the horizontal expansion of Executor can support larger-scale block device (data volume and snapshot) operation requests, making the system have good scalability. In comparison, the block device management system removes multiple components in OpenStack Cinder, uses an in-memory database (NovaMaster) to replace the MySQL component, and removes the foreign key dependency problem; removes the local agent node and scheduler of the block device management system, It reduces the deployment cost (machine and manpower) of the cluster construction process, enhances the stability of the block device management system, and makes changes to the enterprise-side (ToB) business more stable and transparent. In some embodiments, BaiduRPC is used instead of Qpid to improve the fault tolerance of inter-system communication.

Description of drawings

Other features, objects and advantages of the present disclosure will become more apparent upon reading the detailed description of non-limiting embodiments with reference to the following drawings:

FIG. 1 is an exemplary system architecture diagram to which the present disclosure may be applied;

2 is a schematic flowchart of an embodiment of a block device management system according to an embodiment of the present disclosure;

3 is a schematic flowchart of still another embodiment of a block device management system according to an embodiment of the present disclosure;

FIG. 4 is an exemplary structural diagram of one embodiment of the apparatus for assessing risk of the present disclosure;

FIG. 5 is a schematic structural diagram of a computer system suitable for implementing the server of an embodiment of the present disclosure.

Detailed ways

The present disclosure will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the related invention, but not to limit the invention. In addition, it should be noted that, for the convenience of description, only the parts related to the related invention are shown in the drawings.

It should be noted that the embodiments of the present disclosure and the features of the embodiments may be combined with each other under the condition of no conflict. The present disclosure will be described in detail below with reference to the accompanying drawings and in conjunction with embodiments.

FIG. 1 illustrates an exemplary system architecture 100 of an embodiment of a block device management system or apparatus for assessing risk to which the present disclosure may be applied.

As shown in FIG. 1 , the system architecture 100 may include terminal devices 101 , 102 , and 103 , a network 104 and a server 105 . The network 104 is a medium used to provide a communication link between the terminal devices 101 , 102 , 103 and the server 105 . The network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, among others.

The user can use the terminal devices 101, 102, 103 to interact with the server 105 through the network 104 to receive or send messages and the like. Various communication client applications may be installed on the terminal devices 101 , 102 and 103 , such as browser applications, shopping applications, search applications, instant communication tools, email clients, social platform software, and the like.

The terminal devices 101, 102, and 103 may be hardware or software. When the terminal devices 101, 102, and 103 are hardware, they can be various electronic devices that support browser applications, including but not limited to tablet computers, laptop computers, desktop computers, and the like. When the terminal devices 101, 102, and 103 are software, they can be installed in the electronic devices listed above. It can be implemented, for example, as multiple software or software modules for providing distributed services, or as a single software or software module. There is no specific limitation here.

The server 105 may be a server that provides various services, such as a background server that provides support for browser applications performed on the terminal devices 101 , 102 , and 103 . The background server can analyze and process the received request and other data, and feed back the processing result to the terminal device.

It should be noted that the server may be hardware or software. When the server is hardware, it can be implemented as a distributed server cluster composed of multiple servers, or can be implemented as a single server. When the server is software, it may be implemented as multiple software or software modules for providing distributed services, or may be implemented as a single software or software module. There is no specific limitation here.

In practice, the block device management system provided by the embodiments of the present disclosure may be provided in the terminal devices 101 , 102 , and 103 and/or the servers 105 and 106 .

It should be understood that the numbers of terminal devices, networks and servers in FIG. 1 are merely illustrative. There can be any number of terminal devices, networks and servers according to implementation needs.

Continuing to refer to FIG. 2, FIG. 2 illustrates an exemplary structural diagram 200 of one embodiment of a block device management system according to the present disclosure. The block device management system 200 includes: a client 210, an application program interface 220, and further includes: an executor 230, configured to submit tasks to the block device service manager module and query submitted tasks, and obtain tasks and reports from an in-memory database task status; and an in-memory database 240 configured to perform metadata storage, management jobs and tasks for device snapshots and data volumes.

In this embodiment, the execution body of the block device management system (for example, the terminal or the server shown in FIG. 1 ) may be provided with a client 210 , an application program interface 220 , an executor (Executer) 230 and an in-memory database (NovaMaster) 240 .

Among them, the block device management system (Cinder) introduces a layer of "logical storage volume" abstraction between virtual machines and specific storage devices. Cinder itself is not a storage technology, but only provides an intermediate abstraction layer. Cinder By calling the driver interfaces of different storage backend types to manage the corresponding backend storage, it provides users with a unified storage interface for volume-related operations.

The client (Cinder Client, that is, the Cinder client in the figure) 210 is configured such that the client encapsulates an HTTP request and provides a command-line access to the application program interface, and provides two usage modes of Shell and Python modules.

The application program interface 220 is used to accept the HTTP request initiated by the client and Nova Computer (import client module), perform user identity verification and message distribution, and use WSGI Service to provide Web services, operate core resources and extended resources, and relate to the database. , data volume and scheduler interaction. The current application program interface provides external interfaces as shown in the following table:

The above interface involves two functions: updating metadata and calling block device services. Updating metadata does not need to manage the system's data volume through the block device in the prior art; the non-tgt mount data volume operation ultimately submits a Job to the block device service (for more complex or longer-running operations, use Jobs instead of tasks) At this time, the data volume of the block device management system is the client role. Therefore, there are two types of roles based on functional division: metadata storage and task management. Task management requires a task submission and monitoring module, which can be implemented by the executor 230 , and the metadata storage function can be provided by the in-memory database 240 . The executor 230 may use the executor management module to complete the submission task and the monitoring module.

Therefore, on the basis of retaining the client 210 and the application program interface 220 of the block device management system, the above-mentioned execution body can set the executor 230 module to submit and monitor the submitted execution tasks; set the in-memory database 240 to execute the device snapshot and volume metadata data, management tasks.

In the block device management system shown in the above embodiments of this application, the newly added executor (Executor) is a stateless component, so all operations support fault tolerance. Based on this feature, the back-end system upgrade process can be insensitive to users; at the same time, the Executor level The expansion can support larger-scale block device (data volume and snapshot) operation requests, making the system have good scalability. In addition, compared with the existing technology, the block device management system removes multiple components in OpenStack Cinder, Using an in-memory database to replace the MySQL component removes the foreign key dependency problem; removes the local agent node and scheduler of the block device management system, reduces the deployment cost (machine and manpower) of the cluster building process, and enhances the stability of the block device management system This makes changes to business-oriented (ToB) services more stable and transparent.

In some optional implementations of the above embodiments, the in-memory database is further configured to: split various upstream requests into task lists, and assign the task lists to the executor for execution; the executor is further configured to: based on Track the status of the task indicated by the task ID in the client from the task ID in the task list allocated by the memory database, including: if the task indicated by the task ID has not started, submit the task ID to the block device service manager (CDSMaster) The indicated task, and track the status of the task indicated by the task Id; if the task indicated by the task Id has been executed/completed, update the status of the task indicated by the task Id in the executor; and periodically report the heartbeat to the in-memory database, Synchronize the status of the task indicated by the taskId in the executor memory to the in-memory database.

In this implementation manner, in order to cooperate with the operation of the executor to realize the corresponding function, the above-mentioned execution body sets the in-memory database to split various upstream requests into subtasks, and each subtask is assigned to the executor for execution. After the executor is started, it will track the status of the task in the client of the block device management system according to the task ID in the assigned task list. If the task has not started, submit the task to the block device service manager (CDSMaster), and keep track of the task status; if the task has been executed/completed, update the status of the task in the executor. The executor will periodically report to the in-memory database, and synchronize the task status in the executor's memory to the in-memory database in real time. In this way, the in-memory database is used to split tasks, and the executor is used to track the status of tasks in the client, which removes foreign key dependencies and enhances the stability of the block device management system.

In some optional implementations of the above embodiments, the status of the task in the executor includes: a task status identifier and a task action identifier; wherein, the task status identifier includes: not executing (ready), executing (running), execution failure (error), successfully executed (exited); task action identifiers include: submitting task (submitting), checking task (checking), and empty (none).

In this implementation, the Executor task has two fields to identify the state: task_state and action, the former indicates the state of the task, and the legal values are ready (not executing), running (executing), error (execution failure), exited ( Successful execution), the latter indicates the action being performed by the task. The legal values are submitting (submitting the task to the Master), checking (checking the task status), and none. By setting the status of the task including the task status flag and the task action flag, the current task execution situation can be refined, and the accuracy of the task status data can be improved.

In some optional implementations of this embodiment, the executor is further configured to: before submitting the task indicated by the task Id, set the task status flag of the task indicated by the task Id to not executed, and set the task state indicated by the task Id The task action ID of the task is empty; the task is acquired from the unexecuted queue, and the task action ID of the acquired task is set to submit the task, and the newly created coroutine is used to call the block device service client to submit the acquired task to the block device service manager; response If the submission result returned by the block device service client indicates that the task was submitted successfully, move the task indicated by the submission result from the unexecuted queue to the executing task queue, change the task status of the task indicated by the submission result to be under execution, and change the submission result. The task action identifier of the indicated task is empty; in response to the submission result returned by the block device service client indicating that the task submission failed, move the task indicated by the submission result from the unexecuted queue to the exit/failure queue, and retry to the block device service The manager submits the task indicated by the submission result; in response to the heartbeat response returned by the in-memory database, it indicates that the task has been consumed by the block device service but the status of the task has not been updated, and the task does not exist in the unprocessed task queue. add this task.

In this implementation manner, in a task submission cycle, the executor will traverse the ready_queue, and submit the task with state=ready and action=none to the block device service manager.

Specifically, the steps performed by the executor are as follows: as shown in Figure 3, first, in step 310, the executor traverses the ready_queue, selects the task status flag and sets it as not executed, and sets the task action flag to be empty (state=ready, action=none) task, before submitting, set the task action flag to submitting task (action is set to submitting); after that, the executor opens a new coroutine and calls the client to submit the task to the block device service manager; after that, receives the block The submission result returned by the device service client (block device_tool); then, in step 320, if the task submission is successful, the executor moves the task from the ready_queue into the running_queue, sets the task status flag to executing, and sets the task action flag to is empty (state=running, action=none); in step 330, if the task submission fails (the state of the task object is invalid, the task parameters are wrong, etc.), the executor moves the task from ready_queue to exited_error_queue, and changes the task status flag to execute On failure, the task action flag is set to null (state=error, action=none).

Among them, Coroutine (coroutine) is a lightweight thread in user mode, with the following characteristics: lightweight thread; non-preemptive multitasking, the coroutine actively hands over control; compiler/interpreter/virtual machine level tasks; multiple coroutines may run on one or more threads; subroutines are a special case of coroutines.

In addition to the steps performed by the executor above, when the executor submits a task to the client, the following exceptions may occur. The processing steps are as follows:

On the one hand, in the first three steps in the above process of submitting a task, it is possible to switch to another coroutine, which may report in the heartbeat, submit other tasks or query the status of the task. Among them, if the coroutine is reporting in the heartbeat, the heartbeat response returned by the in-memory database may indicate that the push has been consumed by the block device service (CDS), but the task status of the consumed task in the executor has not been updated. When the executor adds the consumed task to the to-be-executed task queue, it checks whether the consumed task already exists in the to-be-executed task queue. If the coroutine is submitting other tasks or querying the task status, it has no effect on the currently submitted task.

On the other hand, in the above process of submitting a task, there may be a situation where the submitted task times out or there is no response. At this time, since the block device JOB supports idempotency, you can simply retry the submission task.

In this implementation, the executor submits tasks. Each submission action will be executed in a new coroutine to ensure that the traversal will not be blocked. In addition, tasks can be submitted regularly, and the status of the tasks can be identified to further refine the current The status of task execution to improve the accuracy of task status data.

In some optional implementations of this embodiment, in response to the submission result returned by the block device service client indicating that the task submission failed, the task is moved from the unexecuted queue to the exit/failure (exited_error_queue) queue, and the task is retried to the block device service management Submitting a task to the server includes: in response to the submission result returned by the block device service client indicating that the task submission fails, the task indicated by the submission result is a task of creating a resource class, and the number of times that the task indicated by the submission result is retried to the block device service manager If the value is less than the predetermined threshold, the task indicated by the submission result is moved from the unexecuted queue to the exit/failure queue, and the task indicated by the submission result is retried to the block device service manager.

In this implementation manner, an upper predetermined threshold is set for the number of retries for creating a resource-type task, so as to avoid excessive retries for creating a resource-type task, thereby causing resource leakage.

In some optional implementations of this embodiment, the executor is further configured to at least one of the following: in response to executing the timed polling task after submitting the task, set the task action flag of the submitted task as a check task, and send The block device service manager sends a query request for the submitted task; in response to receiving the query result returned by the block device service manager based on the query request that the task is being executed, the task status identifier of the submitted task remains unchanged, and the setting is The task action flag of the submitted task is empty; in response to receiving the query result returned by the block device service manager based on the query request that the task is executed successfully, set the task status flag of the submitted task to be executed successfully, and set the The task action flag is empty; in response to receiving the query result returned by the block device service manager based on the query request that the task execution failed, set the task status flag of the submitted task as execution failure, and set the task action flag of the submitted task as null.

In this implementation, the executor periodically polls the task status. As shown in the optional implementation in FIG. 3, in optional step 340, first set the task action flag (task action) as the inspection task, and then send the The block device service manager (CDSMaster) sends a query request; in optional step 350, the CDSMaster returns the task status, the task is still executing, the task state remains unchanged, and the task action identifier is set to null (task state remains unchanged, action= none); in optional step 360, CDSMaster returns the task status, the task is successfully executed, the task status flag is set to execute successfully, and the task action flag is set to be empty (state=exited, action=none); in optional step 370 , the CDSMaster returns the task status, the task execution fails, the task status flag is set to execution failure, and the task action flag is set to null (taskstate=error, action=none).

The steps performed by the executor in this implementation manner determine the operations performed by the executor when periodically polling the task status, further refine the status information of the executor in the operation process, and improve the accuracy of the status information.

In some optional implementations of this embodiment, the executor is further configured to: in response to the task submitted to the block device service manager being a preset task and the preset task is submitted successfully, set a task status identifier of the submitted task For successful execution, set the task action flag of the submitted task to be empty; in response to the task submitted to the block device service manager being a preset task and the failure to submit the preset task, set the task status flag of the submitted task as execution failure , set the task action flag of the submitted task to null.

In this implementation manner, the preset task may be a task that is determined by those skilled in the art according to experience or application scenarios without polling the task status. For example, some tasks that are short-term/don't care about the execution result, specifically, can be stat_volume (query disk mount information), delete_volume (delete disk), delete_snapshot (delete snapshot), etc. These preset tasks can return the execution results after submission, and do not need to poll the task status. As shown in the optional implementation in FIG. 3, in optional step 380, if the preset task is submitted successfully, you can directly change task=exited, action=none; if the preset task submission fails (the block device service returns failure, not caused by environmental reasons), as shown in the above step 330, you can directly change task=error, action=none.

The operation flow of the preset task (eg Duan Qi/task that does not care about the execution result, etc.) executed by the executor in this implementation manner can reduce the polling process and improve the efficiency of executing the submitted task.

In some optional implementations of this embodiment, the executor is further configured to: send a heartbeat request to the in-memory database based on the pingpong mechanism, where the heartbeat request includes: a ping_id identifying the current number of requests, identifying whether it is a synchronization identifier for an initial request, identifying A task list of tasks in execution/execution success/execution failure; the in-memory database is further configured to: return a heartbeat response to the executor, where the heartbeat response includes: pong_id identifying the number of next requests, unexecuted tasks/executing tasks, corresponding to Exit/fail tasks for ping_id.

In this implementation, the executor starts, initializes various parameters, initializes the unexecuted queue (ready_queue), the executing task queue (running_queue), and the exit/failed task queue (exited_error_queue), which are used to store tasks in corresponding states respectively; , the executor reports the heartbeat to the in-memory database. During the initial report, ping_id=0, sync=true (representing the initial report), without any task information; after that, the in-memory database returns the status of the unexecuted task and/or the task being executed. (ready/running) task, pong_id=1, the value is the ping_id of the next reporting period, which is used to ensure that the heartbeat request is processed sequentially; after that, the executor stores the assigned task in the corresponding queue.

The parameters and processes included in the heartbeat request and the heartbeat response defined in this implementation method refine the data content carried by the heartbeat report and improve the accuracy of the data carried by the heartbeat report.

In some optional implementations of this embodiment, the executor is further configured to perform at least one of the following: in response to receiving the heartbeat response, update the ping_id to the pong_id in the heartbeat response, and remove the exit/failure task identified in the heartbeat response Exit/fail queue, in response to the unexecuted task in the heartbeat response not existing in the unexecuted queue in the executor, add the unexecuted task in the heartbeat response to the unexecuted queue in the executor; in response to the failure to send the heartbeat request, Re-initiate the heartbeat request to the in-memory database; in response to the heartbeat request being sent successfully but not receiving the heartbeat response within the preset time, use the ping_id of the heartbeat request that was successfully sent but not received the heartbeat response to re-initiate the heartbeat request to the in-memory database, and resend The task list that identifies tasks in execution/successful/failed in the heartbeat request is not necessarily the same as the task list that identifies tasks in execution/successful/failed in the heartbeat request sent successfully but no heartbeat response is received.

In this implementation, the executor reports the heartbeat to the in-memory database, ping_id=n represents the nth reporting cycle, sync=false represents non-initial reporting, tasks=running/exited/error: tasks that will be executed/executed successfully/failed Report to the in-memory database. After that, the in-memory database updates the task status, returns the unexecuted tasks, and the exited/error tasks reported this time. After that, the executor receives the heartbeat response, updates the ping_id, and removes the received exited/error tasks from the exit failure queue (exited_error_queue). Whether the received unexecuted task exists, if not, the unexecuted task will be added to the unexecuted queue.

During the above-mentioned operation of the executor reporting the heartbeat to the in-memory database, the following exceptions may also exist:

The first exception is that the heartbeat request is not sent normally (that is, the sending fails), then the executor can re-initiate the request at this time.

The second abnormality is that the heartbeat request is normal, and no heartbeat response is received (that is, the reception fails). At this time, the executor can re-initiate the request: the ping_id remains unchanged, and the tasks content may change; the in-memory database can receive the first request. After a ping_id request is made, the status data in the request is cached in the memory, so that the cached content is returned for the same ping_id request received subsequently.

The third exception is that between the first exception and the second exception, it may switch to another coroutine. The coroutine may report in the heartbeat of the next cycle. The ping_id is consistent with this report and will not cause any impact; the coroutine It may be submitting a task, but it will not affect it; the coroutine may also be querying the task status, and it will not affect it.

The fourth exception sets a timeout for the heartbeat request of the executor, and immediately resends the request after the timeout; the in-memory database returns a timeout heartbeat response, which will not affect the executor's reception and processing.

The method for reporting the heartbeat by the executor in this implementation mode solves various problems that are easy to occur in the process of reporting the heartbeat, and improves the stability of the system.

In some optional implementations of this embodiment, the in-memory database is further configured to: cache the task list in the heartbeat request that identifies the tasks in execution/successful/failed to be executed in the memory, and in response to the received ping_id of the heartbeat request The same as the ping_id of the previously received heartbeat request, return to the executor the task list of the previously received heartbeat request cached in memory.

In this implementation, in response to the heartbeat request being sent successfully but not receiving the heartbeat response within the preset time in the executor, the heartbeat request is re-initiated to the memory database using the ping_id of the heartbeat request that was successfully sent but the heartbeat response was not received, The task list that identifies tasks in execution/successful/failed in the resent heartbeat request is not necessarily the same as the task list that identifies tasks in execution/successful/failed in the heartbeat request sent successfully but no heartbeat response is received , the in-memory database can cache the status data in the request to memory after receiving the first ping_id request, and the subsequent same ping_id request will return the cached content, thus ensuring the consistency of the data returned by the same ping_id request before and after .

In some optional implementations of this embodiment, the executor is further configured to execute at least one of the following: using a newly created coroutine to obtain a task from an unexecuted queue; using the newly created coroutine to execute each timing task, and the timing task includes At least one of the following: report heartbeat regularly, submit tasks regularly, and query task status regularly.

In this implementation, there are three timing tasks started by the executor, and each timing task will open a new coroutine to execute: reporting heartbeat regularly; submitting tasks regularly; and querying task status regularly.

The block device management system of the above embodiments of the present disclosure makes the risk assessment information output by the risk control model more accurate, and improves the efficiency and accuracy of obtaining the risk assessment information.

With further reference to FIG. 4 , FIG. 4 shows an exemplary structural diagram of yet another embodiment of the block device management system according to the present disclosure.

As shown in FIG. 4 , in the block device management system 400 of this embodiment, on the basis of the block device management system shown in FIG. 2 , the memory database 240 includes: a service module (CinderService) 241 of the block device management system, which is configured with into receiving the heartbeat request of the executor, receiving the data volume of the application program interface, and the snapshot operation request; the management module (CinderManager) 242 of the block device management system is configured to process the heartbeat request of the executor, process the data volume of the application program interface, Snapshot operation request.

Alternatively or additionally, the in-memory database further includes: a data volume service module (VolumeService) 243, a service module defined for the PB, a CRUD interface for metadata of the data volume, configured to receive operations on the metadata of the data volume request; a data volume management module (VolumeManager) 244, managed by the database manager, is configured to persist operation requests for the metadata of the data volume, and to store and update the metadata of the data volume.

Alternatively or additionally, the in-memory database also includes: a snapshot service module 245 (SnapshotService), a service module defined for the PB, a CRUD interface for the snapshot metadata, configured to receive an operation request for the snapshot metadata; the snapshot The management module (SnapshotManager) 246, managed by the database manager, is configured to persist operation requests for the metadata of the snapshot, and store and update the metadata of the snapshot.

To sum up, three services are implemented in the in-memory database: metadata storage for data volumes, metadata storage for snapshots, and job and task management. The design of each component is shown in the following table:

In some optional implementation manners of this embodiment, RPC is used for communication between the client and the application program interface, the in-memory database, and the executor; HTTP communication is used between the client and the application program interface.

As shown in Figure 4, the dotted lines are RPC calls and the solid lines are function calls. The interaction between the object-oriented message middleware (Qpid, using AMQP protocol) and SQL between the original modules is modified to use RPC interaction. Here, the fault tolerance of inter-system communication is improved by using BaiduRPC instead of Qpid.

The block device management system in the embodiment in FIG. 4 of the present disclosure, on the basis of the block device management system shown in FIG. 2, refines the receiving request in the in-memory database for the block device management system, volume data and snapshots The service module and the management module for processing requests improve the service support capability of the in-memory database for the executor and improve the stability of the block device management system.

Referring next to FIG. 5 , it shows a schematic structural diagram of an electronic device (eg, the server or terminal device in FIG. 1 ) 500 suitable for implementing the embodiments of the present disclosure. Terminal devices in the embodiments of the present disclosure may include, but are not limited to, notebook computers, desktop computers, and the like. The terminal device/server shown in FIG. 5 is only an example, and should not impose any limitation on the function and scope of use of the embodiments of the present disclosure.

As shown in FIG. 5 , an electronic device 500 may include a processing device (eg, a central processing unit, a graphics processor, etc.) 501 that may be loaded into random access according to a program stored in a read only memory (ROM) 502 or from a storage device 508 Various appropriate actions and processes are executed by the programs in the memory (RAM) 503 . In the RAM 503, various programs and data necessary for the operation of the electronic device 500 are also stored. The processing device 501 , the ROM 502 , and the RAM 503 are connected to each other through a bus 504 . An input/output (I/O) interface 505 is also connected to bus 504 .

Typically, the following devices may be connected to the I/O interface 506: input devices 505 including, for example, a touch screen, touch pad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, etc.; including, for example, a liquid crystal display (LCD), speakers, vibration An output device 507 such as a computer; a storage device 508 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 509 . Communication means 509 may allow electronic device 500 to communicate wirelessly or by wire with other devices to exchange data. While FIG. 5 shows electronic device 500 having various means, it should be understood that not all of the illustrated means are required to be implemented or provided. More or fewer devices may alternatively be implemented or provided. Each block shown in FIG. 5 can represent one device, and can also represent multiple devices as required.

In particular, according to embodiments of the present disclosure, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the method illustrated in the flowchart. In such an embodiment, the computer program may be downloaded and installed from the network via the communication device 509 , or from the storage device 508 , or from the ROM 502 . When the computer program is executed by the processing device 501, the above-described functions defined in the methods of the embodiments of the present disclosure are performed. It should be noted that the computer-readable medium described in the embodiments of the present disclosure may be a computer-readable signal medium or a computer-readable storage medium, or any combination of the above two. The computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus or device, or a combination of any of the above. More specific examples of computer readable storage media may include, but are not limited to, electrical connections with one or more wires, portable computer disks, hard disks, random access memory (RAM), read only memory (ROM), erasable Programmable read only memory (EPROM or flash memory), fiber optics, portable compact disk read only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. In embodiments of the present disclosure, a computer-readable storage medium may be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. Rather, in embodiments of the present disclosure, a computer-readable signal medium may include a data signal in baseband or propagated as part of a carrier wave, carrying computer-readable program code therein. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the foregoing. A computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium that can transmit, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device . Program code embodied on a computer readable medium may be transmitted using any suitable medium including, but not limited to, electrical wire, optical fiber cable, RF (radio frequency), etc., or any suitable combination of the foregoing.

The above-mentioned computer-readable medium may be included in the above-mentioned electronic device; or may exist alone without being assembled into the electronic device. The above-mentioned computer-readable medium carries one or more programs, and when the above-mentioned one or more programs are executed by the electronic device, the electronic device is made to implement a block device management system, including: a client, an application program interface; a block device management system Also included: an executor configured to submit tasks and query submitted tasks to the block device service manager module, obtain tasks from an in-memory database and report task status; and an in-memory database configured to perform device snapshots and meta-volumes of data Data storage, management jobs and tasks.

Computer program code for carrying out operations of embodiments of the present disclosure may be written in one or more programming languages, including object-oriented programming languages—such as Java, Smalltalk, C++, or a combination thereof, Also included are conventional procedural programming languages - such as the "C" language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer, or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any kind of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (eg, using an Internet service provider to via Internet connection).

The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code that contains one or more logical functions for implementing the specified functions executable instructions. It should also be noted that, in some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It is also noted that each block of the block diagrams and/or flowchart illustrations, and combinations of blocks in the block diagrams and/or flowchart illustrations, can be implemented in dedicated hardware-based systems that perform the specified functions or operations , or can be implemented in a combination of dedicated hardware and computer instructions.

The modules and devices involved in the embodiments of the present disclosure may be implemented in software or hardware. The described module can also be set in the processor, for example, it can be described as: a processor implements a block device management system, including: a client, an application program interface; the processor implements a block device management system and further includes: an executor and Memory Database. Among them, the names of these modules and devices do not constitute restrictions on the modules and devices themselves, for example, the executor can also be described as "submit tasks to the block device service manager module and query submitted tasks. , and a device that retrieves tasks from an in-memory database and reports task status".

The above description is merely a preferred embodiment of the present disclosure and an illustration of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in the present disclosure is not limited to the technical solution formed by the specific combination of the above-mentioned technical features, and should also cover, without departing from the above-mentioned inventive concept, the above-mentioned technical features or Other technical solutions formed by any combination of its equivalent features. For example, a technical solution is formed by replacing the above features with the technical features disclosed in the present disclosure (but not limited to) with similar functions.

Claims (16)

1. A block device management system, comprising: a client, an application program interface; the block device management system further includes:

the executor is configured to submit tasks to the block equipment service manager module, inquire the submitted tasks, and acquire the tasks and report the task state from the memory database; and

the memory database is configured to execute metadata storage, management operation and task of the equipment snapshot and the data volume;

wherein the states of the tasks in the executor include: a task state identifier and a task action identifier; wherein, the task state identification comprises: not executed, in execution, failed in execution, successful in execution; the task action identification comprises the following steps: submitting a task, checking the task and emptying;

the actuator is further configured to:

before submitting a task indicated by a task Id, setting a task state identifier of the task indicated by the task Id as unexecuted, and setting a task action identifier of the task indicated by the task Id as null;

acquiring a task from an unexecuted queue, setting a task action identifier of the acquired task as a submitted task, and adopting a newly-built coroutine to call a block equipment service client to submit the acquired task to a block equipment service manager;

and in response to the fact that the submission result returned by the block equipment service client indicates that the submission of the task is successful, the task indicated by the submission result is moved from the unexecuted queue to the executing task queue, the task state of the task indicated by the change submission result is identified as being executing, and the task action for changing the task indicated by the submission result is identified as being empty.

2. The block device management system of claim 1, wherein the in-memory database is further configured to: splitting various upstream requests into task lists, and distributing the task lists to the actuators for execution;

the actuator is further configured to: tracking the state of the task indicated by the task Id in the client based on the task Id in the task list distributed from the in-memory database, wherein the tracking comprises the following steps:

if the task indicated by the task Id does not start, submitting the task indicated by the task Id to a block device service manager, and tracking the state of the task indicated by the task Id;

if the task indicated by the task Id is executed/completed, updating the state of the task indicated by the task Id in an actuator; and

and reporting heartbeat to a memory database at regular time, and synchronizing the state of the task indicated by the task Id in the memory of the actuator to the memory database.

3. The block device management system of claim 1, wherein the executor is further configured to:

in response to the submission result returned by the block equipment service client indicating that the submission of the task fails, moving the task indicated by the submission result from the unexecuted queue into a retirement/failure queue, and retrying to submit the task indicated by the submission result to the block equipment service manager;

and in response to the heartbeat response returned by the memory database indicating that the task is consumed by the block device service but the state of the task is not updated, and the task does not exist in the unprocessed task queue, adding the task to the unprocessed task queue.

4. The block device management system of claim 3, wherein responsive to the commit result returned by the block device service client indicating a failure to commit the task, moving the task from the unexecuted queue into the retirement/failure queue, and retrying to commit the task to the block device service manager comprises:

and in response to the submission result returned by the block equipment service client indicating that the submission of the task fails, the task indicated by the submission result is a task of creating a resource class, and the number of times of retrying to submit the task indicated by the submission result to the block equipment service manager is less than a preset threshold value, moving the task indicated by the submission result from the unexecuted queue into a retired/failed queue, and retrying to submit the task indicated by the submission result to the block equipment service manager.

5. The block device management system of claim 3, wherein the executor is further configured to at least one of:

in response to executing a timed polling task after submitting a task, setting a task action identifier of the submitted task as a check task, and sending a query request for the submitted task to the block device service manager;

in response to receiving that a query result returned by the block device service manager based on the query request is in task execution, keeping a task state identifier of the submitted task unchanged, and setting a task action identifier of the submitted task to be null;

in response to receiving that the query result returned by the block device service manager based on the query request is that the task is successfully executed, setting the task state identifier of the submitted task as successful execution, and setting the task action identifier of the submitted task as null;

and in response to receiving that the query result returned by the block device service manager based on the query request is a task execution failure, setting the task state identifier of the submitted task as the execution failure, and setting the task action identifier of the submitted task as null.

6. The block device management system of claim 3, wherein the executor is further configured to:

in response to the fact that the task submitted to the block equipment service manager is a preset task and the preset task is successfully submitted, setting a task state identifier of the submitted task as successful execution and setting a task action identifier of the submitted task as null;

and in response to the fact that the task submitted to the block equipment service manager is a preset task and the submission of the preset task fails, setting the task state identifier of the submitted task as an execution failure, and setting the task action identifier of the submitted task as null.

7. The block device management system of claim 3, wherein the executor is further configured to:

sending a heartbeat request to the memory database based on a pingpong mechanism, wherein the heartbeat request comprises: identifying ping _ id of current request times, identifying whether the current request is synchronous identification of an initial request, and identifying a task list of tasks which are executed/executed successfully/executed unsuccessfully;

the in-memory database further configured to: returning a heartbeat response to the executor, the heartbeat response including: and the pong _ id for identifying the next request times, the unexecuted task/the executed task and the quitting/failing task corresponding to the ping _ id.

8. The block device management system of claim 7, wherein the executor is further configured to perform at least one of:

in response to receiving the heartbeat response, updating the ping _ id to a pong _ id in the heartbeat response, removing a field-off/failed task identified in the heartbeat response from a field-off/failed queue, and in response to an unexecuted task in the heartbeat response not existing in an unexecuted queue in the executor, adding the unexecuted task in the heartbeat response to the unexecuted queue in the executor;

responding to the sending failure of the heartbeat request, and restarting the heartbeat request to a memory database;

responding to the successful sending of the heartbeat request but not receiving the heartbeat response within the preset time, and re-initiating the heartbeat request to the memory database by adopting the ping _ id of the heartbeat request which is successfully sent but not receiving the heartbeat response, wherein a task list which is used for identifying the task which is being executed/successfully executed/unsuccessfully executed in the re-sent heartbeat request is not necessarily the same as a task list which is used for identifying the task which is being executed/successfully executed/unsuccessfully executed in the heartbeat request which is successfully sent but not receiving the heartbeat response.

9. The block device management system of claim 8, wherein the in-memory database is further configured to:

and caching a task list of the task which identifies the task which is executed/executed successfully/executed unsuccessfully in the heartbeat request into a memory, and returning the task list of the task which is cached in the memory by the received heartbeat request to the executor in response to the fact that the ping _ id of the received heartbeat request is the same as the ping _ id of the received heartbeat request.

10. The block device management system of any of claims 1-9, wherein the executor is further configured to perform at least one of:

acquiring tasks from the unexecuted queue by adopting a newly-built coroutine;

executing each timing task by adopting the newly-built coroutine, wherein the timing task comprises at least one of the following items: reporting heartbeat regularly, submitting task regularly and inquiring task regularly.

11. The block device management system of claim 1, wherein the client and application program interface communicate with the in-memory database and the executor using RPC; and the client and the application program interface adopt HTTP communication.

12. The block device management system of claim 1, wherein the in-memory database comprises:

the service module of the block device management system is configured to receive a heartbeat request of an executor, receive a data volume of an application program interface and a snapshot operation request;

and the management module of the block device management system is configured to process heartbeat requests of the executor, process data volumes of the application program interface and snapshot operation requests.

13. The block device management system according to any one of claims 1 or 12, wherein the in-memory database further includes:

the service module of the data volume, the service module defined by PB, the CRUD interface of the metadata of the data volume, and the CRUD interface are configured to receive an operation request for the metadata of the data volume;

a management module for the data volume, managed by the database manager, is configured to persist operation requests for the metadata of the data volume, and to store and update the metadata of the data volume.

14. The block device management system according to any one of claims 1 and 12, wherein the in-memory database further includes:

the service module of the snapshot is defined by PB, and the CRUD interface of the metadata of the snapshot is configured to receive an operation request for the metadata of the snapshot;

and the management module of the snapshot is managed by the database manager and is configured to persist operation requests for the metadata of the snapshot and store and update the metadata of the snapshot.

15. An electronic device/terminal/server comprising:

one or more processors;

storage means for storing one or more programs;

when executed by the one or more processors, cause the one or more processors to implement the block device management system of any of claims 1-14.

16. A computer-readable medium, on which a computer program is stored which, when being executed by a processor, carries out a block device management system according to any one of claims 1-14.

Images