Interaction method and device of OCFS2 cluster service and block storage service

Abstract

The embodiment of the invention discloses an interaction method and device for an OCFS2 cluster service and a block storage service, and the method comprises the steps: receiving a volume operation request through the block storage service, carrying out the analysis of the volume operation request, and determining a request type and a resource identifier; initiating a corresponding lock request to a distributed lock manager of any OCFS2 cluster service through the block storage service according to the request type; performing lock conflict detection on the lock request through the distributed lock manager, and granting a corresponding lock permission to the target resource when a lock conflict detection result is no conflict; executing a corresponding target operation on the target resource through the block storage service according to the lock permission and the resource identifier; according to the scheme, the problem that the interaction reliability of the cloud operating system is low is solved, the OCFS2 cluster service of any node can execute the target operation on the target resource in the OCFS2 cluster file system based on the volume operation request, normal interaction of other nodes is not affected by a single node fault, and the interaction reliability in the cloud operating system is remarkably improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method and apparatus for interaction between OCFS2 cluster service and block storage service. Background Technology

[0002] In the distributed architecture of OpenStack (a cloud operating system), data write and read operations between multiple nodes (including compute nodes and storage nodes) are the core foundation supporting virtual machine operation, application deployment, and business continuity. As cloud computing scales up, clusters often contain dozens to hundreds of nodes. These nodes need to achieve collaborative data access through shared storage. For example, compute nodes need to read and write volume data provided by storage nodes in real time to support virtual machine disk operations. Currently, the Cinder component of OpenStack (cloud operating system) serves as a block storage service. During the data writing and reading interaction between multiple nodes, if a single node fails, other nodes cannot take over the mounted block device, resulting in the inability to write and read the volume data corresponding to that block device, thus affecting the normal operation of the cloud operating system.

[0003] Therefore, the interaction method of existing block storage services in cloud operating systems has low reliability. Summary of the Invention This application provides a method and apparatus for interaction between OCFS2 cluster service and block storage service, which can solve the technical problem of low interaction reliability of block storage service in cloud operating system. Based on volume operation request, the corresponding target operation can be performed on the target resource in OCFS2 cluster file system in cloud operating system through the OCFS2 cluster service of any node. The failure of a single node does not affect the normal interaction of other nodes, which significantly improves the interaction reliability of block storage service in cloud operating system.

[0004] In a first aspect, embodiments of this application provide an interaction method between an OCFS2 cluster service and a block storage service, used in a cloud operating system. The cloud operating system includes a block storage service, and all nodes in the cloud operating system are mounted with corresponding OCFS2 cluster services. Each node has a corresponding distributed lock manager, and a corresponding OCFS2 cluster file system is created in the cloud operating system. Each node's OCFS2 cluster service can perform corresponding volume operations on the OCFS2 cluster file system through a mount connection. The interaction method between the OCFS2 cluster service and the block storage service includes: The block storage service receives volume operation requests and parses and processes them to determine the request type and resource identifier. The request type includes volume creation request, volume read request, volume write request, volume snapshot request, and volume delete request. The resource identifier is the identifier of the target resource in the OCFS2 cluster file system corresponding to the volume operation to be performed. Based on the request type, the block storage service initiates a corresponding lock request to the distributed lock manager of any OCFS2 cluster service. The lock request can be an exclusive lock request or a shared lock request, and the lock request includes a resource identifier. The distributed lock manager performs lock conflict detection on lock requests, and grants the corresponding lock permission to the target resource when the lock conflict detection result is no conflict. The block storage service performs the corresponding target operation on the target resource based on lock permissions and resource identifier. After the target operation is completed, a lock release request based on the target resource is sent to the distributed lock manager through the block storage service, so that the distributed lock manager updates the lock state based on the lock release request and synchronizes the lock state to the OCFS2 cluster service of all nodes.

[0005] Furthermore, the block storage service receives volume operation requests and parses them to determine the request type and resource identifier, including: Receive volume operation requests through block storage service; The block storage service parses and processes volume operation requests to determine the request type and corresponding request parameters. When the request type is a volume read request or a volume snapshot request, the block storage service determines the corresponding resource identifier based on the request parameters, which include the volume file path and the node identifier of the target OCFS2 cluster service. Accordingly, the block storage service initiates a corresponding lock request to the distributed lock manager of any OCFS2 cluster service based on the request type, including: When the request type is a volume read request or a volume snapshot request, a shared lock request is initiated to the distributed lock manager of any OCFS2 cluster service through the block storage service.

[0006] Furthermore, the block storage service performs corresponding target operations on the target resource based on lock permissions and resource identifiers, including: When the request type is a volume snapshot request, a blank snapshot copy file is created in the OCFS2 cluster file system via the block storage service; The target resource in the OCFS2 cluster file system is determined by the resource identifier through the block storage service. The block storage service requests shared locks based on the target resource and exclusive locks based on snapshot copy files from the distributed lock manager of any OCFS2 cluster service according to the lock permissions. After the distributed lock manager grants the target resource a shared lock and an exclusive lock on the snapshot copy file, the data of the target resource is synchronized to the snapshot copy file through the block storage service to generate a read-only snapshot copy. Accordingly, after the target operation is completed, a lock release request is sent to the distributed lock manager through the block storage service, including: After synchronization is complete, the first association information between the snapshot copy and the target resource is recorded through the block storage service, and the first association information is updated to the database of the cloud operating system. The block storage service sends a lock release request based on the target resource to the distributed lock manager, so that the distributed lock manager releases the shared lock of the target resource based on the lock release request.

[0007] Furthermore, the block storage service receives volume operation requests and parses them to determine the request type and resource identifier, including: Receive volume operation requests through block storage service; The block storage service parses and processes volume operation requests to determine the request type and corresponding request parameters. When the request type is a volume creation request, volume write request, or volume delete request, the block storage service determines the corresponding resource identifier based on the request parameters. The request parameters include the volume file path, operation transaction ID, node identifier of the target OCFS2 cluster service, and node timeout threshold. Accordingly, the block storage service initiates a corresponding lock request to the distributed lock manager of the OCFS2 cluster service based on the request type, including: When the request type is a volume creation request, volume write request, or volume delete request, an exclusive lock request is initiated to the distributed lock manager of any OCFS2 cluster service through the block storage service.

[0008] Furthermore, the block storage service performs corresponding target operations on the target resource based on lock permissions and resource identifiers, including: When the request type is a volume creation request, after the target resource has acquired exclusive lock permissions, the block storage service sends a volume file creation instruction to the OCFS2 cluster file system based on the lock permissions. The volume file creation instruction includes volume capacity, storage path and file system block size information. The OCFS2 cluster file system creates a blank volume file of the corresponding size in the corresponding shared storage space according to the volume file creation instruction, and returns the resource identifier corresponding to the blank volume file to the block storage service. The resource identifier and volume metadata are associated through the block storage service to obtain the corresponding second association information, and the second association information is updated to the database of the cloud operating system.

[0009] Furthermore, the block storage service performs corresponding target operations on the target resource based on lock permissions and resource identifiers, including: When the request type is a volume write request, after the target resource acquires the exclusive lock, the block storage service sends a cache invalidation instruction to other nodes based on the lock privileges, so that other nodes mark the corresponding file cache as invalid based on the cache invalidation instruction; The block storage service writes the received data to the corresponding target resource in the OCFS2 cluster file system according to the resource identifier. After the writing is completed, the local cache is updated through the OCFS2 cluster file system and synchronized to the corresponding shared storage space. The block storage service is then notified of the successful operation. After receiving the operation success notification, the block storage service sends a cache refresh notification to all nodes.

[0010] Furthermore, lock conflict detection is performed on lock requests through a distributed lock manager, including: The current lock status of the target resource corresponding to the resource identifier in the OCFS2 cluster file system is determined by querying the current lock record table through the distributed lock manager. When the lock request is a shared lock request and the current lock state is either unlocked or only a shared lock, the lock conflict detection result is determined to be conflict-free. When the lock request is an exclusive lock request and the current lock state is unlocked, the lock conflict detection result is determined to be no conflict.

[0011] In a second aspect, embodiments of this application provide an interaction device for OCFS2 cluster services and block storage services, used in a cloud operating system. The cloud operating system includes a block storage service, and all nodes in the cloud operating system are mounted with corresponding OCFS2 cluster services. Each node has a corresponding distributed lock manager, and a corresponding OCFS2 cluster file system is created in the cloud operating system. Each node's OCFS2 cluster service can perform corresponding volume operations on the OCFS2 cluster file system through a mount connection. This interaction device for OCFS2 cluster services and block storage services includes: The volume operation request receiving module is used to receive volume operation requests through the block storage service; The request parsing module is used to parse and process volume operation requests, determine the request type and resource identifier, where the request types include volume creation request, volume read request, volume write request, volume snapshot request and volume delete request, and the resource identifier is the identifier of the target resource in the OCFS2 cluster file system corresponding to the volume operation to be performed. The lock request initiation module is used to initiate a corresponding lock request to the distributed lock manager of any OCFS2 cluster service through the block storage service according to the request type. The lock request is either an exclusive lock request or a shared lock request, and the lock request includes a resource identifier. The lock conflict detection module is used to detect lock conflicts in lock requests through a distributed lock manager; The lock permission granting module is used to grant lock permissions to the target resource when the lock conflict detection result is no conflict; The operation execution module is used to perform the corresponding target operation on the target resource based on the lock permission and resource identifier through the block storage service; The lock release module is used to send a lock release request based on the target resource to the distributed lock manager through the block storage service after the target operation is completed. This allows the distributed lock manager to update the lock state based on the lock release request and synchronize the lock state to the OCFS2 cluster service of all nodes.

[0012] In a third aspect, embodiments of this application provide an interaction device for OCFS2 cluster services and block storage services, comprising: Memory and one or more processors; Memory, used to store one or more programs; When one or more programs are executed by one or more processors, the one or more processors implement the interaction method between the OCFS2 cluster service and the block storage service as described in the first aspect.

[0013] In a fourth aspect, embodiments of this application provide a storage medium for storing computer-executable instructions, which, when executed by a computer processor, are used to perform an interaction method between the OCFS2 cluster service and the block storage service as described in the first aspect.

[0014] This embodiment of the application, during the interaction between the OCFS2 cluster service and the block storage service, involves the block storage service receiving volume operation requests, parsing the requests to determine the request type and resource identifier, and then initiating a corresponding lock request to the distributed lock management of any OCFS2 cluster service based on the request type. The distributed lock manager performs lock conflict detection on the lock requests, and if no conflict is detected, grants lock permissions to the target resource in the OCFS2 cluster file system. The block storage service then performs the corresponding target operation on the target resource based on the lock permissions and resource identifier. After the target operation is completed, the block storage service sends a lock release request based on the target resource to the distributed lock manager, enabling the distributed lock manager to update the lock state based on the lock release request and synchronize the lock state to the OCFS2 cluster services on all nodes. By employing the above technical means, any node's OCFS2 cluster service can execute the corresponding target operation on the target resource in the OCFS2 cluster file system within the cloud operating system based on the volume operation request. This avoids the technical problem of low interaction reliability of the block storage service in the cloud operating system, as the failure of a single node does not affect the normal interaction of other nodes, thereby improving the interaction reliability of the block storage service in the cloud operating system.

[0015] The beneficial effects of the interaction device, equipment, and storage medium for the OCFS2 cluster service and block storage service provided above can be referenced from the beneficial effects of the interaction method for the OCFS2 cluster service and block storage service. Attached Figure Description

[0016] Figure 1 This is a schematic diagram illustrating a scenario of interaction between OCFS2 cluster service and block storage service provided in an embodiment of this application; Figure 2 This is a flowchart illustrating an interaction method between an OCFS2 cluster service and a block storage service, as provided in an embodiment of this application. Figure 3 This is a flowchart illustrating another interaction method between OCFS2 cluster service and block storage service provided in an embodiment of this application. Figure 4 This is a flowchart illustrating another interaction method between OCFS2 cluster service and block storage service provided in this application embodiment; Figure 5 This is a flowchart illustrating another interaction method between OCFS2 cluster service and block storage service provided in an embodiment of this application. Figure 6 This is a flowchart illustrating another interaction method between OCFS2 cluster service and block storage service provided in this application embodiment; Figure 7This is a flowchart illustrating another interaction method between OCFS2 cluster service and block storage service provided in an embodiment of this application. Figure 8 This is a schematic diagram of the structure of an interaction device between OCFS2 cluster service and block storage service provided in an embodiment of this application; Figure 9 This is a schematic diagram of the structure of an interactive device for OCFS2 cluster service and block storage service provided in an embodiment of this application. Detailed Implementation

[0017] To make the objectives, technical solutions, and advantages of this application clearer, specific embodiments of this application will be described in further detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely for explaining this application and not for limiting it. It should also be noted that, for ease of description, only the parts relevant to this application are shown in the drawings, not all of them. Before discussing exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe operations (or steps) as sequential processes, many of these operations can be performed in parallel, concurrently, or simultaneously. Furthermore, the order of the operations can be rearranged. The process can be terminated when its operation is completed, but may also have additional steps not included in the drawings. The process can correspond to a method, function, procedure, subroutine, subprogram, etc.

[0018] Currently, the Cinder component of OpenStack (a cloud operating system) serves as a block storage service. During data write and read interactions across multiple nodes, if a single node fails, other nodes cannot take over the mounted block devices. This prevents the corresponding volume data from being written or read, impacting the normal operation of the cloud operating system. Therefore, the existing block storage service interaction method in cloud operating systems has low reliability.

[0019] Based on this, this application provides an interaction method and apparatus for OCFS2 cluster service and block storage service, which aims to receive volume operation requests through the block storage service during the interaction process between the OCFS2 cluster service and the block storage service, parse and process the volume operation requests to determine the request type and resource identifier, initiate a corresponding lock request to the distributed lock management of any OCFS2 cluster service according to the request type through the block storage service, perform lock conflict detection on the lock request through the distributed lock manager, and grant lock permissions corresponding to the target resource of the OCFS2 cluster file system when the lock conflict detection result is no conflict, perform the corresponding target operation on the target resource in the OCFS2 cluster file system through the block storage service according to the lock permissions and resource identifier, and send a lock release request based on the target resource to the distributed lock manager through the block storage service after the target operation is completed, so that the distributed lock manager updates the lock state based on the lock release request and synchronizes the lock state to the OCFS2 cluster service of all nodes. By employing the aforementioned technical means, the OCFS2 cluster service of any node can perform corresponding target operations on the target resources in the OCFS2 cluster file system of the cloud operating system based on volume operation requests. Compared to the existing interaction process where other nodes cannot take over the mounted block devices and thus cannot read or write when a single node fails, this embodiment allows other nodes to still perform corresponding target operations on the target resources in the OCFS2 cluster file system of the cloud operating system based on volume operation requests even when a single node fails. This ensures that a single node failure does not affect the normal interaction of other nodes, thereby improving the interaction reliability of the block storage service in the cloud operating system.

[0020] Figure 1 This is a schematic diagram illustrating a scenario of interaction between OCFS2 cluster service and block storage service provided in an embodiment of this application. (Refer to...) Figure 1 The interaction method between the OCFS2 cluster service and the block storage service is used in a cloud operating system 10, which includes a block storage service 11 and at least one node. Each node mounts a corresponding OCFS2 cluster service and has a distributed lock manager 12. The distributed lock manager 12 of any node can handle tasks such as receiving lock requests, granting locks, and changing lock states. The cloud operating system 10 also creates an OCFS2 cluster file system 13, and the OCFS2 cluster service of each node can perform corresponding volume operations on the OCFS2 cluster file system 13 through a mount connection. The block storage service 11 communicates with each node, meaning it communicates with the OCFS2 cluster service and the distributed lock manager 12 of each node. Figure 1As shown, the block storage service 11 communicates with OCFS2 cluster service 1 and distributed lock manager 12 on node 1, OCFS2 cluster service 2 and distributed lock manager 12 on node 2, and OCFS2 cluster service 3 and distributed lock manager 12 on node 3. The block storage service 11 also communicates with OCFS2 cluster file system 13. The block storage service 11 (e.g., OpenStackCinder) is the core of the block storage management of the cloud operating system 10. Its function is to interface with the underlying storage resources and provide standardized volume lifecycle management capabilities to the upper layers, including volume operation scheduling, distributed coordination, metadata management, and high availability adaptation. Volume operation scheduling is achieved by receiving and parsing volume operation requests from the cloud operating system 10 and calling the corresponding driver interface according to the request type (create, read / write, or delete, etc.). Distributed collaboration involves interacting with the OCFS2 cluster service to complete lock requests, permission verification, and resource identifier mapping (such as binding the volume ID to the OCFS2 file (i.e., the target resource) path in the OCFS2 cluster file system 13), ensuring the orderliness of multi-node operations. Metadata management maintains metadata such as volume status (available, in use, and snapshots), capacity, and relationships, and supports upper-layer scheduling decisions through the cloud operating system 10's database (such as the Cinder database). High availability adaptation leverages the cluster characteristics of the OCFS2 cluster service to enable automatic takeover of volumes in case of node failure (e.g., after a node crashes, other nodes can continue to access volume data through the OCFS2 lock mechanism), solving the single point of failure problem in the traditional cloud operating system 10 architecture. The core function of the OCFS2 cluster service deployed on each node (including the o2cb cluster service and the dlm distributed lock service, etc.) is to realize inter-node communication and lock collaboration, ensuring cluster consistency. The OCFS2 cluster file system 13, as the underlying shared storage file system layer, provides cross-node file-level shared access capabilities, providing a storage medium for volume data. By formatting the underlying block device as an OCFS2 cluster file system 13, nodes can mount and access the same set of files (such as volume files or snapshot files) through a unified path. The OCFS2 cluster file system 13, in collaboration with the distributed lock manager 12, implements file-level or block-level lock control (such as exclusive locks for write operations and shared locks for read operations), preventing data corruption caused by concurrent read / write operations on multiple nodes. The OCFS2 cluster file system 13 supports direct I / O and caching mechanisms, improving volume data read / write performance while ensuring data consistency. The OCFS2 cluster file system 13 provides file-level quota and capacity statistics (such as total capacity and remaining space), feeding back storage status to the block storage service 11 through tools, and supports capacity verification during volume creation.Volume operations are lifecycle management behaviors of storage resources that are jointly completed by the block storage service 11 and the OCFS2 cluster service in the cloud operating system 10. Volume operations include volume creation, volume reading, volume writing, volume snapshot and volume deletion.

[0021] As described above, the block storage service 11 acts as the decision-maker, responsible for scheduling volume operations and managing metadata. The OCFS2 cluster service in the node acts as the coordinator, ensuring orderly interaction among multiple nodes through a locking mechanism. The OCFS2 cluster file system 13 acts as the carrier, providing shared storage capabilities. The combination of these three components enables high availability and high concurrency management of volumes in the cloud operating system 10, solving the problem of data unavailability caused by node failures in traditional architectures. The architecture of the cloud operating system 10 provided in this embodiment can achieve normal interaction of other nodes without the failure of a single node, significantly improving the interaction reliability of the block storage service 11 in the cloud operating system 10.

[0022] Figure 2 A flowchart of an interaction method between an OCFS2 cluster service and a block storage service, according to an embodiment of this application, is provided. This interaction method can be executed by an interaction device for the OCFS2 cluster service and block storage service. This interaction device can be implemented through software and / or hardware. The interaction device can consist of two or more physical entities, or it can consist of a single physical entity. Generally, the interaction device for the OCFS2 cluster service and block storage service can be a computer device.

[0023] The following description uses a computer device as the primary example to illustrate the interaction method between OCFS2 cluster services and block storage services. (Refer to...) Figure 2 The interaction method between the OCFS2 cluster service and the block storage service is used in the aforementioned cloud operating system. Specifically, the interaction method includes: S101. Receive volume operation requests through the block storage service, parse and process the volume operation requests, and determine the request type and resource identifier. The request type includes volume creation request, volume read request, volume write request, volume snapshot request, and volume delete request. The resource identifier is the identifier of the target resource in the OCFS2 cluster file system corresponding to the volume operation to be performed.

[0024] Based on the communication connection between the block storage service (such as OpenStack Cinder) and the OCFS2 cluster service, when other components of the block storage service initiate volume operations on the OCFS2 cluster file system, they can generate corresponding volume operation requests and send these requests to the block storage service. These other components initiating the volume operation requests can be compute services (such as Nova), console services (such as Horizon), or container services (such as Kuryr), etc., which send volume operation requests to the block storage service due to business needs (such as virtual machine disk mounting or user-created volumes). The block storage service receives the volume operation requests sent by the corresponding components. For example, the block storage service can receive volume operation requests from other components through a message queue. The format of the volume operation request can be a JSON object, containing fields such as request type and resource identifier.

[0025] After receiving a volume operation request, the block storage service parses the request to obtain the request type and resource identifier. The request type includes volume creation request, volume read request, volume write request, volume snapshot request, and volume delete request. The resource identifier is the identifier of the target resource in the OCFS2 cluster file system corresponding to the volume operation to be performed. For example, upon receiving a volume operation request, the block storage service parses the request to determine the corresponding request type field (e.g., the `operation_type` field) and resource identifier field (e.g., the `resource_id` field). Based on the request type field, it determines the request type of the current volume operation request, which can be one of volume creation, volume read, volume write, volume snapshot, or volume delete requests. Based on the resource identifier field, it determines the resource identifier of the target resource. As described above, based on the block storage service receiving volume operation requests from other components, subsequent volume operations can be performed on any node's OCFS2 cluster service based on the volume operation request, enabling concurrent access from multiple nodes. Compared to the traditional single-node exclusive approach, this significantly improves the interaction flexibility between the OCFS2 cluster service and the block storage service.

[0026] S102. Initiate a corresponding lock request to the distributed lock manager of any OCFS2 cluster service through the block storage service according to the request type. The lock request is either an exclusive lock request or a shared lock request. The lock request includes a resource identifier.

[0027] After the block storage service determines the request type and resource identifier of the volume operation request, it initiates a corresponding lock request to the distributed lock manager of any OCFS2 cluster service based on the request type. The lock request can be an exclusive lock request or a shared lock request, and includes the resource identifier. The lock request is used to request the granting of an exclusive or shared lock corresponding to the target resource. For example, the corresponding lock request can be initiated first to the distributed lock manager of the target OCFS2 cluster service (i.e., the OCFS2 cluster service corresponding to the node identifier in the volume operation request). For example, when the request type is a volume creation request, volume write request, or volume delete request, the block storage service initiates a corresponding exclusive lock request to the distributed lock manager of any OCFS2 cluster service based on the request type. When the request type is a volume read request or volume snapshot request, the block storage service initiates a corresponding shared lock request to the distributed lock manager of any OCFS2 cluster service based on the request type. As described above, the block storage service initiates a corresponding exclusive lock request or shared lock request to the distributed lock manager of any OCFS2 cluster service based on the request type. The shared lock request allows multiple nodes to perform the corresponding volume operation simultaneously, improving the concurrency of volume operations; while the exclusive lock request ensures that only one node modifies the data at the same time, guaranteeing data consistency and avoiding unnecessary blocking.

[0028] S103. The distributed lock manager performs lock conflict detection on lock requests. When the lock conflict detection result is no conflict, the lock permission corresponding to the target resource is granted.

[0029] After the lock request is initiated through the block storage service in step S102, the distributed lock manager receives the corresponding lock request and performs lock conflict detection. During lock conflict detection, the distributed lock manager can query the current lock record table, which records the current lock status of all resources. Based on the lock status of the target resource in the query table, it can be determined whether there is a lock conflict with the aforementioned lock request. If a lock conflict exists, the lock request is placed in a waiting queue until there is no conflict, and then processed accordingly; or the lock request is rejected. If no lock conflict exists, the distributed lock manager grants the target resource corresponding to the resource identifier lock permissions, where the lock permissions are either exclusive lock permissions or shared lock permissions.

[0030] For example, during lock conflict detection, the distributed lock manager queries the current lock record table to determine the current lock status of the target resource corresponding to the resource identifier. The current lock record table records information such as the resource identifier, the type of currently held lock (lockless, shared, or exclusive), the list of nodes holding the lock, and the lock's effective time. Based on the resource identifier carried in the lock request, the distributed lock manager performs an index match in the current lock record table to extract the lock status information corresponding to that resource identifier. This lock status information includes the current lock type and the holding node, and serves as the basis for lock conflict detection.

[0031] In one embodiment, when the lock request is a shared lock request, the distributed manager can perform lock conflict detection based on the current lock state of the target resource. If the current lock state of the target resource is unlocked, it means that the target resource is not currently locked by any node, and the new shared lock can pass directly, thus determining that the lock conflict detection result is conflict-free. If the current lock state of the target resource is a shared lock only, since the characteristic of a shared lock is that it "allows multiple nodes to hold it simultaneously," such as "read-read without conflict," even if the target resource is already held by other nodes with a shared lock, the new shared lock request can still pass, thus determining that the lock conflict detection result is conflict-free. If the current lock state of the target resource is an exclusive lock, based on the conflict between exclusive locks and shared locks, such as "read-write conflict," the lock conflict detection result is determined to be a lock conflict, and the shared lock request is placed in a waiting queue until there is no conflict before being processed accordingly; or the shared lock request is rejected.

[0032] In one embodiment, when the lock request is an exclusive lock request, the distributed manager can perform lock conflict detection based on the current lock state of the target resource. If the current lock state of the target resource is unlocked, it means that the target resource is not locked by any node, and the exclusive lock request can pass, thus determining that the lock conflict detection result is conflict-free. If the current lock state of the target resource is a shared lock, and there is a conflict between the exclusive lock and the shared lock, such as a "write-read conflict," then the lock conflict detection result is determined to be a lock conflict. In this case, the exclusive lock request is placed in a waiting queue, and after there is no conflict, the corresponding processing is performed; or the exclusive lock request is rejected. If the current lock state of the target resource is an exclusive lock, and there is a conflict between the exclusive lock and the exclusive lock, such as a "write-write conflict," then the lock conflict detection result is determined to be a lock conflict. In this case, the exclusive lock request is placed in a waiting queue, and after there is no conflict, the corresponding processing is performed; or the exclusive lock request is rejected.

[0033] As described above, by strictly distinguishing the conflict rules of shared locks and exclusive locks, the corresponding target operation is only executed when the lock conflict detection result is non-conflictful. This fundamentally avoids the data inconsistency problem caused by multiple nodes operating on the target resource simultaneously, thereby improving the accuracy of controlling concurrent access and ensuring data consistency. Shared locks allow multiple nodes to execute corresponding volume operations simultaneously, avoiding unnecessary blocking between volume operations and significantly improving concurrency efficiency in volume operation-intensive scenarios. Exclusive lock requests are only allowed to acquire when the lock is unlocked, ensuring the atomicity of volume operations while reducing unnecessary waiting, balancing data security and operational security, greatly improving the interaction performance between the OCFS2 cluster service and the block storage service, and significantly increasing system throughput. Furthermore, shared lock requests are allowed directly when only a shared lock exists, without waiting for other operations to complete, reducing blocking time; exclusive lock requests are allowed only when the lock is unlocked, avoiding conflict waiting and ensuring the efficient execution of the corresponding target operation, thereby improving the resource utilization efficiency of the OCFS2 cluster service.

[0034] As described above, the distributed lock manager performs lock conflict detection on lock requests. When the lock conflict detection result is no conflict, the lock permission corresponding to the target resource is granted. Instead of a fixed node, when a node fails, other nodes can re-apply for the lock and take over the operation, ensuring business continuity and realizing seamless lock permission migration, thereby improving the interaction flexibility and reliability of OCFS2 cluster services and block storage services.

[0035] S104. Execute the corresponding target operation on the target resource based on the lock permissions and resource identifier through the block storage service.

[0036] After granting the lock permission corresponding to the target resource in S103, the block storage service determines the matching between the lock type and the operation type based on the lock permission, and checks the validity period of the lock permission. After confirming that the lock type and operation type match and that the lock permission is within the validity period, the corresponding target operation is executed on the target resource in the OCFS2 cluster file system according to the resource identifier. The target operation is the operation corresponding to the aforementioned volume operation request. For example, if the request type of the volume operation request is a volume creation request, the corresponding target operation is volume creation; if the request type of the volume operation request is a volume read request, the corresponding target operation is volume read; if the request type of the volume operation request is a volume write request, the corresponding target operation is volume write; if the request type of the volume operation request is a volume snapshot request, the corresponding target operation is volume snapshot; if the request type of the volume operation request is a volume delete request, the corresponding target operation is volume delete. As described above, based on the request type of the volume operation request, the corresponding lock permission is granted to the target resource. The block storage service then performs the corresponding target operation on the target resource in the OCFS2 cluster file system according to the lock permission and resource identifier. When a single node fails, other nodes can interact with the block storage service based on the volume operation request and perform the corresponding target operation on the OCFS2 cluster file system based on the volume operation request. This avoids the problem of being unable to perform volume operations on the OCFS2 cluster file system due to a single node failure, thereby improving the flexibility and reliability of the interaction between the OCFS2 cluster service and the block storage service.

[0037] S105. After the target operation is completed, a lock release request based on the target resource is sent to the distributed lock manager through the block storage service, so that the distributed lock manager updates the lock state based on the lock release request and synchronizes the lock state to the OCFS2 cluster service of all nodes.

[0038] After the block storage service performs the corresponding target operation on the target resource in the OCFS2 cluster file system based on lock permissions and resource identifier, once the target operation is completed (i.e., the corresponding volume operation's business logic is finished), such as data writing or snapshot copy file data synchronization, a lock release request based on the target resource is sent to the distributed lock manager via the block storage service. The lock release request includes parameters such as lock ID (lock identifier), lock holder node (identifier), and operation result. Upon receiving the lock release request based on the target resource, the distributed manager verifies its validity. During validity verification, it checks whether the lock ID exists and belongs to the lock holder node, and whether the lock is in the "granted" state. If the lock ID exists and belongs to the lock holder node, and the lock is in the "granted" state, the lock release request passes validity verification. After the lock release request passes the validity verification, the distributed lock manager updates the lock state based on the lock release request. This involves releasing the lock on the target resource, removing the lock (exclusive or shared lock) corresponding to the target resource from the current lock list, and recording information such as the release time. After the lock is released, the current lock list is updated to update the lock state. After updating the lock state, the distributed lock manager synchronizes the updated lock state to the OCFS2 cluster service on all nodes, so that all nodes' OCFS2 cluster services are aware of the latest lock state, facilitating subsequent volume operation requests to the target resource. For example, the distributed lock manager only synchronizes a portion of the lock state update to the OCFS2 cluster service on all nodes, not the entire lock list. During lock state synchronization, the distributed lock manager can use UDP multicast for synchronization, with each node updating its local cache upon receiving the lock state; alternatively, the distributed lock manager can use the Gossip protocol to allow nodes to randomly exchange states, ensuring eventual consistency.

[0039] In one embodiment, after the block storage service performs the corresponding target operation on the target resource in the OCFS2 cluster file system according to the lock permissions and resource identifier, if the target operation times out or throws an exception, the lock is forcibly released through the finally block (final code block) in the cloud operating system to ensure that the target resource is not permanently locked. After forcibly releasing the lock, the current lock list is updated to update the lock state. After updating the lock state, the updated lock state is synchronized to the OCFS2 cluster service of all nodes through the distributed lock manager, so that the OCFS2 cluster service of all nodes knows the latest lock state, which facilitates subsequent initiation of corresponding volume operation requests based on the target resource. The above-mentioned forced timeout release mechanism avoids permanent lock holding caused by program exceptions, realizes deadlock prevention, and improves resource utilization.

[0040] As described above, by releasing the lock immediately after the target operation is completed, the waiting time of other nodes is reduced, and the lock turnover speed is improved, thereby improving the interaction efficiency between the OCFS2 cluster service and the block storage service. After the lock is released, other nodes are notified to update the cache in a timely manner to avoid dirty reads, thereby improving read operation consistency and enhancing the consistency of interactive data during the interaction between the OCFS2 cluster service and the block storage service. The lock state synchronization mechanism supports the expansion of the cluster scale to multiple nodes (hundreds of nodes), realizes distributed collaboration, and improves the scalability of the interaction between the OCFS2 cluster service and the block storage service.

[0041] As described above, during the interaction between the OCFS2 cluster service and the block storage service, the block storage service receives volume operation requests sent by other components, parses and processes these requests to determine the request type and resource identifier, and then initiates a corresponding lock request to the distributed lock management of any OCFS2 cluster service based on the request type. The distributed lock manager performs lock conflict detection on the lock requests, and if the lock conflict detection result is no conflict, it grants lock permissions to the target resource in the OCFS2 cluster file system. The block storage service then performs the corresponding target operation on the target resource in the OCFS2 cluster file system based on the lock permissions and resource identifier. After the target operation is completed, the block storage service sends a lock release request based on the target resource to the distributed lock manager, so that the distributed lock manager updates the lock state based on the lock release request and transmits the lock state to all nodes of the OCFS2 cluster service. By employing the aforementioned technical means, the OCFS2 cluster service of any node can perform corresponding target operations on the target resources in the OCFS2 cluster file system of the cloud operating system based on volume operation requests. Compared to the existing interaction process where other nodes cannot take over the mounted block devices and thus cannot read or write when a single node fails, this embodiment allows other nodes to still perform corresponding target operations on the target resources in the OCFS2 cluster file system of the cloud operating system based on volume operation requests even when a single node fails. This ensures that a single node failure does not affect the normal interaction of other nodes, thereby improving the interaction reliability of the block storage service in the cloud operating system.

[0042] Figure 3 This is a flowchart illustrating another interaction method between OCFS2 cluster service and block storage service provided in this application embodiment. (Refer to...) Figure 3 The specific interaction methods between the OCFS2 cluster service and the block storage service include: S201. Receive volume operation requests through the block storage service.

[0043] Based on the communication connection between the block storage service (such as OpenStack Cinder) and the OCFS2 cluster service, when other components of the block storage service initiate volume operations on the OCFS2 cluster file system, they can generate corresponding volume operation requests and send these requests to the block storage service. These other components initiating the volume operation requests can be compute services (such as Nova), console services (such as Horizon), or container services (such as Kuryr), etc., which send volume operation requests to the block storage service due to business needs (such as virtual machine disk mounting or user-created volumes). The block storage service receives the volume operation requests sent by the corresponding components. For example, the block storage service can receive volume operation requests from other components through a message queue. The format of the volume operation request can be a JSON object, containing fields such as request type and resource identifier.

[0044] S202. The block storage service parses and processes the volume operation request to determine the request type and corresponding request parameters.

[0045] After receiving a corresponding volume operation request, the block storage service parses and processes the request to determine its type and parameters. The request type includes volume creation, volume read, volume write, volume snapshot, and volume delete requests. For example, upon receiving a volume operation request, the block storage service parses it to determine the corresponding request type field (e.g., the `operation_type` field). Based on this field, it determines the request type of the current volume operation request, which can be one of the following: volume creation, volume read, volume write, volume snapshot, or volume delete.

[0046] S203. When the request type is a volume read request, the corresponding resource identifier is determined by the block storage service based on the request parameters. The request parameters include the volume file path and the node identifier of the target OCFS2 cluster service.

[0047] After determining the request type as described above, if the request type is a volume read request, the corresponding request parameters can be determined, including the volume file path and the node identifier of the target OCFS2 cluster service. Then, the block storage service determines the corresponding resource identifier based on the request parameters (the volume file path). Here, the target OCFS2 cluster service can be understood as the OCFS2 cluster service that intends to request lock permissions.

[0048] S204. Initiate a shared lock request to the distributed lock manager of any OCFS2 cluster service through the block storage service.

[0049] After determining the corresponding resource identifier based on the request type being a volume read request, a shared lock request is initiated to the distributed lock manager of any OCFS2 cluster service via the block storage service. The shared lock request includes parameters such as lock type (shared lock), resource identifier, and timeout. When sending the shared lock request, the block storage service forwards the shared lock request to the corresponding distributed lock manager through the local proxy of the OCFS2 cluster service. The distributed lock managers are deployed distributedly across each node, and any distributed lock manager on any node can handle the corresponding lock request. For example, the block storage service prioritizes sending the shared lock request to the distributed lock manager on the node corresponding to the target OCFS2 cluster service based on the node identifier of the target OCFS2 cluster service in the request parameters.

[0050] S205. The distributed lock manager performs lock conflict detection on the shared lock request. When the lock conflict detection result is no conflict, the permission of the shared lock corresponding to the target resource is granted.

[0051] After S204 initiates a shared lock request to the distributed lock manager of any OCFS2 cluster service through the block storage service, the corresponding distributed lock manager requests a shared lock and performs lock conflict detection. During lock conflict detection, the distributed lock manager queries the current lock record table to determine the current lock status of the target resource corresponding to the resource identifier in the OCFS2 cluster file system. The current lock record table records information such as the resource identifier, the type of currently held lock (unlocked, shared lock, or exclusive lock), the list of nodes holding the lock, and the lock's effective time. Based on the resource identifier carried in the lock request, the distributed lock manager performs an index match in the current lock record table to extract the lock status information of the target resource corresponding to that resource identifier. This lock status information includes the current lock type and the holding node, and serves as the basis for lock conflict detection. When the lock request is a shared lock request, the distributed manager can perform lock conflict detection based on the current lock status of the target resource. If the current lock status of the target resource is unlocked, it means that the target resource is not currently locked by any node, and a new shared lock can pass directly; therefore, the lock conflict detection result is determined to be conflict-free. If the target resource's current lock state is a shared lock only, since the characteristic of shared locks is that "multiple nodes can hold them simultaneously," such as "read-read no conflict," even if other nodes already hold a shared lock on the target resource, a new shared lock request can still pass, thus determining that the lock conflict detection result is conflict-free. If the target resource's current lock state is an exclusive lock, based on the conflict between exclusive locks and shared locks, such as "read-write conflict," the lock conflict detection result is determined to be a lock conflict. Therefore, the shared lock request is placed in a waiting queue, and processed accordingly after no conflict occurs; or the shared lock request is rejected. When the lock conflict detection result is determined to be conflict-free, the distributed lock manager grants the target resource the permission to use a shared lock.

[0052] S206. Perform the corresponding volume read on the target resource using the block storage service based on the permissions of the shared lock and the resource identifier.

[0053] After granting the corresponding target resource in the OCFS2 cluster file system the permission to use the shared lock, the block storage service performs a volume read on the target resource in the OCFS2 cluster file system based on the permissions of the shared lock and the resource identifier. For example, when performing a volume read, the block storage service can open the corresponding target resource (i.e., the volume file) through the interface of the OCFS2 cluster file system, read data from the specified offset into the local cache of the corresponding component (i.e., the component that sent the volume operation request), and release the file handle after the data read is complete.

[0054] S207. After the volume read is completed, a lock release request based on the target resource is sent to the distributed lock manager through the block storage service, so that the distributed lock manager updates the lock state based on the lock release request and synchronizes the lock state to the OCFS2 cluster service of all nodes.

[0055] After the aforementioned volume read is completed, a lock release request based on the target resource is sent to the distributed lock manager via the block storage service. The lock release request includes parameters such as the lock ID, the lock holder node (identifier), and the operation result. Upon receiving the lock release request, the distributed lock manager verifies its validity. The steps for validating the lock release request are the same as described above and will not be repeated here. After the lock release request passes the validity verification, the distributed lock manager updates the lock state based on the lock release request. This involves releasing the shared lock for the target resource, removing the corresponding shared lock from the current lock list, and recording information such as the release time. After the lock is released, the current lock list is updated to update the lock state. After updating the lock state, the distributed lock manager synchronizes the updated lock state to the OCFS2 cluster service on all nodes, so that all nodes' OCFS2 cluster services are aware of the latest lock state, facilitating subsequent initiation of corresponding volume operation requests. For example, the distributed lock manager only synchronizes a portion of the lock state update to the OCFS2 cluster service on all nodes, not the entire lock list.

[0056] As described above, when making a volume read request, the mutual exclusion mechanism of shared locks and exclusive locks ensures that no other nodes write during the read process, avoiding dirty reads, that is, avoiding reading data that has not been fully written, so as to ensure data consistency; based on the shared lock, multiple nodes are allowed to read the same volume (i.e., the target resource) at the same time, realizing parallel reading by multiple nodes, thereby improving the throughput of data reading.

[0057] As described above, any node's OCFS2 cluster service can perform volume read operations on the target resource in the OCFS2 cluster file system of the cloud operating system based on a volume read request. Compared with the existing interaction process where other nodes cannot perform volume reads when a single node fails, this embodiment allows other nodes to still perform volume reads on the target resource in the OCFS2 cluster file system of the cloud operating system based on a volume read request when a single node fails. This achieves interaction where a single node failure does not affect the volume reads of other nodes, significantly improving the interaction reliability of block storage services in the cloud operating system, thereby enhancing the overall user experience.

[0058] Figure 4 This is a flowchart illustrating another interaction method between OCFS2 cluster service and block storage service provided in this application embodiment. (Refer to...) Figure 4 The specific interaction methods between the OCFS2 cluster service and the block storage service include: S301, Receive volume operation requests through block storage service.

[0059] S302. The block storage service parses and processes the volume operation request to determine the request type and corresponding request parameters.

[0060] S303. When the request type is a volume snapshot request, the block storage service determines the corresponding resource identifier based on the request parameters. The request parameters include the volume file path and the node identifier of the target OCFS2 cluster service.

[0061] After determining the request type, if the request type is a volume snapshot request, the corresponding request parameters include the volume file path and the node identifier of the target OCFS2 cluster service. Then, the block storage service determines the corresponding resource identifier based on the request parameters (the volume file path). The resource identifier includes the source volume resource identifier (i.e., the source volume path) of the target resource in the OCFS2 cluster file system and the snapshot resource identifier (i.e., the snapshot path) of the snapshot copy file to be created. The target OCFS2 cluster service can be understood as the OCFS2 cluster service that intends to request lock permissions.

[0062] S304. Initiate a shared lock request to the distributed lock manager of any OCFS2 cluster service through the block storage service.

[0063] After determining the corresponding resource identifier based on the request type being a volume snapshot request, a shared lock request is initiated to the distributed lock manager of any OCFS2 cluster service through the block storage service. The steps for initiating the shared lock request are the same as those in S204 above, and will not be repeated here.

[0064] S305. The distributed lock manager performs lock conflict detection on shared lock requests. When the lock conflict detection result is no conflict, the shared lock permission corresponding to the target resource is granted.

[0065] After the aforementioned S304 sends a shared lock request to the distributed lock manager of any OCFS2 cluster service through the block storage service, the corresponding distributed lock manager, upon receiving the shared lock request, performs lock conflict detection on the shared lock request. The specific lock conflict detection is the same as in S205 mentioned above, and will not be repeated here. If the lock conflict detection result is determined to be conflict-free, the distributed lock manager grants the corresponding shared lock permission to the target resource.

[0066] S306. Create a blank snapshot copy file in the OCFS2 cluster file system using the block storage service.

[0067] After confirming that there is no lock conflict during the lock conflict detection process, a blank snapshot copy file is created in the OCFS2 cluster file system using the block storage service. When creating the blank snapshot copy file, a snapshot target path can be generated based on the previously determined snapshot resource identifier. A blank snapshot copy file is then created at the corresponding location in the OCFS2 cluster file system according to the snapshot target path, and basic metadata, such as creation time and source volume ID, is written to it.

[0068] S307. Determine the target resource in the OCFS2 cluster file system based on the resource identifier through the block storage service.

[0069] After creating the blank snapshot copy file, the block storage service determines the target resource (also known as the target file) in the OCFS2 cluster file system based on the resource identifier (source volume resource identifier). Based on the determined target resource, source volume data is provided for subsequent data synchronization of the snapshot copy file.

[0070] S308. Request an exclusive lock request based on a snapshot copy file from the distributed lock manager of any OCFS2 cluster service through the block storage service, according to the permissions of the shared lock.

[0071] After creating the aforementioned blank snapshot copy file, the block storage service grants the source volume (i.e., the target resource in the OCFS2 cluster file system) the permission to use a shared lock based on the previously determined volume snapshot request. Before synchronizing the data of the snapshot copy file, the block storage service sends an exclusive lock request for the snapshot copy file to the distributed lock manager of any OCFS2 cluster service. For example, the block storage service prioritizes sending the shared lock request to the distributed lock manager of the node corresponding to the target OCFS2 cluster service based on the node identifier of the target OCFS2 cluster service in the request parameters.

[0072] S309. After the distributed lock manager grants exclusive lock permissions to the snapshot copy file, the data of the target resource is synchronized to the snapshot copy file through the block storage service to generate a read-only snapshot copy.

[0073] The corresponding distributed lock manager grants shared lock permissions to the source volume (i.e., the target resource in the OCFS2 cluster file system) based on the received shared lock request, and grants exclusive lock permissions to the snapshot copy file based on the received exclusive lock request. Then, the data of the target resource is synchronized (copied) to the snapshot copy file through the block storage service, generating a read-only snapshot copy. For example, during data synchronization, block-level replication can be performed through the block storage service via the OCFS2 cluster file system interface, using a COW (Copy-on-Write) strategy. Only the initial data blocks are copied; subsequent modifications to the source volume (i.e., the target resource) do not affect the data in the snapshot copy. Furthermore, during synchronization, dual locks are maintained: the source volume (i.e., the target resource in the OCFS2 cluster file system) retains a shared lock permission, and the snapshot copy file retains an exclusive lock permission, thereby ensuring the consistency of the synchronized data.

[0074] S310. After synchronization is complete, the first association information between the snapshot copy and the target resource is recorded through the block storage service, and the first association information is updated to the database of the cloud operating system.

[0075] The aforementioned block storage service synchronizes the data of the target resource to the snapshot copy file. After synchronization is complete, the block storage service records the first association information between the snapshot copy and the target resource, updates the first association information to the database of the cloud operating system (e.g., MySQL database), and creates an index. Subsequently, the first association information can be queried in the database of the cloud operating system based on the index.

[0076] S311. Send a lock release request based on the target resource to the distributed lock manager through the block storage service, so that the distributed lock manager releases the shared lock of the target resource based on the lock release request.

[0077] The aforementioned block storage service synchronizes the data of the target resource to the snapshot copy file. After synchronization, the block storage service sends a lock release request based on the target resource to the distributed lock manager, enabling the distributed lock manager to release the shared lock on the target resource. For example, after synchronization, the exclusive lock on the snapshot copy (file) is released first to allow other operations to access it, and then the shared lock on the source volume (i.e., the target resource) is released to allow other nodes to modify the source volume (i.e., the target resource). After releasing the shared lock on the target resource, the current lock list is updated to update the lock state. After updating the lock state, the distributed lock manager synchronizes the updated lock state to the OCFS2 cluster service on all nodes, so that the OCFS2 cluster service on all nodes knows the latest lock state, facilitating subsequent initiation of corresponding volume operation requests.

[0078] As described above, a shared lock on the source volume (i.e., the target resource) ensures that the snapshot captures complete data at a specific moment, thus guaranteeing data consistency. Furthermore, by copying only the initial data blocks, subsequent modifications to the source volume (i.e., the target data) do not affect the snapshot copy file, avoiding data splitting and further ensuring data consistency. Through dual-lock coordination, modifications to the source volume (i.e., the target data) are prevented, while exclusive write access to the snapshot copy file is guaranteed.

[0079] As described above, volume snapshots can be performed on the target resources in the OCFS2 cluster file system of the cloud operating system based on volume snapshot requests through the OCFS2 cluster service of any node. Compared with the existing interaction process where other nodes cannot perform volume snapshots when a single node fails, this embodiment allows other nodes to still perform volume snapshots on the target resources in the OCFS2 cluster file system of the cloud operating system based on volume snapshot requests through the OCFS2 cluster service when a single node fails. This achieves the interaction of volume snapshots of other nodes without being affected by the failure of a single node, significantly improving the interaction reliability of block storage services in the cloud operating system, and thus improving the overall user experience.

[0080] Figure 5 This is a flowchart illustrating another interaction method between OCFS2 cluster service and block storage service provided in this application embodiment. (Refer to...) Figure 5 The specific interaction methods between the OCFS2 cluster service and the block storage service include: S401, Receive volume operation requests through block storage service.

[0081] S402. The block storage service parses and processes the volume operation request to determine the request type and corresponding request parameters.

[0082] S403. When the request type is a volume creation request, the corresponding resource identifier is determined by the block storage service based on the request parameters. The request parameters include the volume file path, operation transaction ID, node identifier of the target OCFS2 cluster service, and node timeout threshold.

[0083] After determining the request type, if it is a volume creation request, the corresponding request parameters can be determined, including the volume file path, operation transaction ID, node identifier of the target OCFS2 cluster service, and node timeout threshold. Then, the block storage service determines the corresponding resource identifier based on the request parameters (volume file path). The target OCFS2 cluster service can be understood as the OCFS2 cluster service that intends to request lock permissions.

[0084] S404. Initiate an exclusive lock request to the distributed lock manager of any OCFS2 cluster service through the block storage service.

[0085] After determining the corresponding resource identifier based on the request type being a volume creation request, an exclusive lock request for the target resource is initiated through the block storage service to the distributed lock manager of any OCFS2 cluster service. The exclusive lock request includes parameters such as lock type (exclusive lock), resource identifier, and timeout. When sending the exclusive lock request, the block storage service forwards the request to the corresponding distributed lock manager via its local proxy within the OCFS2 cluster service. The distributed lock managers are deployed distributedly across each node, and any distributed lock manager on any node can handle the corresponding lock request. For example, the block storage service prioritizes sending the exclusive lock request to the distributed lock manager on the node corresponding to the target OCFS2 cluster service based on the node identifier of the target OCFS2 cluster service in the request parameters.

[0086] S405. The distributed lock manager performs lock conflict detection on exclusive lock requests. When the lock conflict detection result is no conflict, the exclusive lock permission corresponding to the target resource is granted.

[0087] After S404 initiates an exclusive lock request to the distributed lock manager of any OCFS2 cluster service through the block storage service, the corresponding distributed lock manager, upon receiving the exclusive lock request, performs lock conflict detection. During lock conflict detection, the distributed lock manager queries the current lock record table to determine the current lock status of the target resource corresponding to the resource identifier in the OCFS2 cluster file system. The current lock record table records information such as the resource identifier, the type of currently held lock (unlocked, shared, or exclusive), the list of nodes holding the lock, and the lock's effective time. Based on the resource identifier carried in the lock request, the distributed lock manager performs index matching in the current lock record table to extract the lock status information of the target resource corresponding to that resource identifier. This lock status information includes the current lock type and the holding node, and serves as the basis for lock conflict detection. When the lock request is an exclusive lock request, the distributed manager can perform lock conflict detection based on the queried current lock status of the target resource. If the current lock state of the target resource is unlocked, it means that the target resource is not locked by any node, and the exclusive lock request can pass. Therefore, the lock conflict detection result is determined to be conflict-free. If the current lock state of the target resource is a shared lock, and there is a conflict between the exclusive lock and the shared lock, the lock conflict detection result is determined to be a lock conflict. In this case, the exclusive lock request is placed in a waiting queue, and will be processed accordingly after there is no conflict; or the exclusive lock request is rejected. If the current lock state of the target resource is an exclusive lock, and there is a conflict between the exclusive lock and the exclusive lock, the lock conflict detection result is determined to be a lock conflict. In this case, the exclusive lock request is placed in a waiting queue, and will be processed accordingly after there is no conflict; or the exclusive lock request is rejected. When the lock conflict detection result is determined to be conflict-free, the corresponding shared lock permission for the target resource is granted through the distributed lock manager.

[0088] S406. After obtaining exclusive lock permissions for the corresponding target resource, a volume file creation instruction is sent to the OCFS2 cluster file system through the block storage service based on the exclusive lock permissions. The volume file creation instruction includes volume capacity, storage path, and file system block size information.

[0089] After granting exclusive lock permissions to the corresponding target resource in the OCFS2 cluster file system, the block storage service sends a volume file creation instruction to the OCFS2 cluster file system based on the exclusive lock permissions. This volume file creation instruction includes information about the volume capacity, storage path, and file system block size. The volume file creation instruction controls the OCFS2 cluster file system to perform the corresponding volume creation.

[0090] S407. Using the OCFS2 cluster file system, create a blank volume file of the corresponding size in the corresponding shared storage space according to the volume file creation instruction, and return the resource identifier corresponding to the blank volume file to the block storage service.

[0091] After receiving a volume file creation command from the block storage service, the OCFS2 cluster file system creates a blank volume file of the corresponding size in the corresponding shared storage space based on the command. Upon completion, it returns the resource identifier corresponding to the blank volume file to the block storage service. For example, the OCFS2 cluster file system determines the storage location of the blank volume file in the corresponding shared storage space based on the storage path in the volume file creation command. It then creates the blank volume file at that storage location according to the volume capacity and file system block size information in the command. Volume metadata is written to the created blank volume file, including node information (i.e., the node information of the OCFS2 cluster service that initiated the volume creation request) and access control list information. After writing the volume metadata, the blank volume file creation is complete. A corresponding resource identifier is generated based on the volume path of the blank volume file, and this resource identifier is returned to the block storage service.

[0092] S408. The resource identifier and volume metadata are associated through the block storage service to obtain the corresponding second association information, and the second association information is updated to the database of the cloud operating system.

[0093] After the creation of a blank volume file via the OCFS2 cluster file system is completed and the resource identifier corresponding to the blank volume file is returned to the block storage service, the block storage service associates the resource identifier corresponding to the blank volume file with the volume metadata of the blank volume file to obtain the corresponding second association information. The second association information is then updated in the database of the cloud operating system (e.g., MySQL database) and an index is created. Subsequently, the second association information can be queried in the database of the cloud operating system based on the index.

[0094] S409. After the volume is created, a lock release request based on the target resource is sent to the distributed lock manager through the block storage service, so that the distributed lock manager releases the exclusive lock of the target resource based on the lock release request.

[0095] After the volume is created, i.e., after the blank volume file is created, a lock release request based on the target resource is sent to the distributed lock manager through the block storage service. This allows the distributed lock manager to release the exclusive lock on the target resource based on the lock release request. After releasing the exclusive lock on the target resource, the current lock list is updated to update the lock state. After updating the lock state, the distributed lock manager synchronizes the updated lock state to the OCFS2 cluster service on all nodes, so that the OCFS2 cluster service on all nodes knows the latest lock state, facilitating subsequent initiation of corresponding volume operation requests.

[0096] As described above, exclusive locks ensure that the volume creation process is not interfered with by other operations, preventing file system corruption. For example, it can prevent two nodes from creating volumes with the same name simultaneously, achieving atomic volume creation operations and thus improving the reliability of volume creation. Furthermore, by recording secondary association information in the cloud operating system, the origin of volume files is traced, improving the traceability of volume creation.

[0097] As described above, any node's OCFS2 cluster service can perform volume creation operations on the corresponding target resource in the OCFS2 cluster file system in the cloud operating system based on a volume creation request. Compared to the existing interaction process where other nodes cannot perform volume creation when a single node fails, this embodiment allows other nodes to still perform volume creation on the corresponding target resource in the OCFS2 cluster file system in the cloud operating system based on a volume creation request even when a single node fails. This achieves interaction where a single node failure does not affect the volume creation of other nodes, significantly improving the interaction reliability of block storage services in the cloud operating system, thereby enhancing the overall user experience.

[0098] Figure 6 This is a flowchart illustrating another interaction method between OCFS2 cluster service and block storage service provided in this application embodiment. (Refer to...) Figure 6The specific interaction methods between the OCFS2 cluster service and the block storage service include: S501, Receive volume operation requests through block storage service.

[0099] S502. The block storage service parses and processes the volume operation request to determine the request type and corresponding request parameters.

[0100] S503. When the request type is a volume write request, the corresponding resource identifier is determined by the block storage service based on the request parameters. The request parameters include the volume file path, the operation transaction ID, the node identifier of the target OCFS2 cluster service, and the node timeout threshold.

[0101] After determining the request type, if it is a volume write request, the corresponding request parameters—volume file path, operation transaction ID, node identifier of the target OCFS2 cluster service, and node timeout threshold—can be determined. Then, the block storage service determines the corresponding resource identifier based on the request parameters (volume file path). The target OCFS2 cluster service can be understood as the OCFS2 cluster service that intends to request lock permissions.

[0102] S504. Initiate an exclusive lock request to the distributed lock manager of any OCFS2 cluster service through the block storage service.

[0103] After determining the corresponding resource identifier based on the request type being a volume write request, an exclusive lock request for the target resource is initiated through the block storage service to the distributed lock manager of any OCFS2 cluster service. The specific steps for initiating the exclusive lock request are the same as those in S404 above, and will not be repeated here.

[0104] S505. The distributed lock manager performs lock conflict detection on exclusive lock requests. When the lock conflict detection result is no conflict, the exclusive lock permission corresponding to the target resource is granted.

[0105] The distributed lock manager performs lock conflict detection for exclusive lock requests in the same way as described in S405 above, and will not be repeated here. When the lock conflict detection result indicates no conflict, the distributed lock manager grants the target resource the permission to use the shared lock.

[0106] S506. After acquiring the exclusive lock permission for the corresponding target resource, the block storage service sends a cache invalidation instruction to other nodes based on the exclusive lock permission, so that other nodes mark the corresponding file cache as invalid based on the cache invalidation instruction.

[0107] After granting exclusive lock permissions to the corresponding target resource in the OCFS2 cluster file system, the block storage service sends a cache invalidation command to other nodes (the OCFS2 cluster service) based on the exclusive lock permissions. This causes the other nodes to mark the corresponding file cache (i.e., the cache of the target resource) as invalid based on the cache invalidation command. Here, "other nodes" refers to nodes other than the node that sent the volume write request. Since other nodes may have cached existing data for the volume (i.e., the target resource), without invalidation, new data written to them would result in corrupted data. Therefore, it is necessary to invalidate the caches of other nodes first to ensure the consistency of subsequent data reads and improve the reliability of data interaction in the cloud operating system.

[0108] S507. The received data is written to the corresponding target resource in the OCFS2 cluster file system according to the resource identifier through the block storage service. After the writing is completed, the local cache is updated through the OCFS2 cluster file system and synchronized to the corresponding shared storage space. The block storage service is then notified of the successful operation.

[0109] After sending the cache invalidation command through the block storage service, the block storage service determines the target resource in the OCFS2 cluster file system based on the resource identifier. The block storage service writes the data received from other components (i.e., the component that initiated the volume write request) into the target resource. After the write is completed, the local cache is updated through the OCFS2 cluster file system and synchronized to the corresponding shared storage space. The block storage service is then notified of the successful operation.

[0110] S508. After the block storage service receives the operation success notification, it sends a cache refresh notification to all nodes.

[0111] After receiving the operation success notification, the block storage service sends a cache refresh notification to the OCFS2 cluster service on all nodes to inform other nodes that the target resource has been updated and that they can reload the latest data into their local cache, avoiding frequent access to shared storage space during subsequent reads. For example, the block storage service can broadcast the cache refresh notification to all nodes. Other nodes can then load the corresponding range of data for the target resource into their own caches as needed.

[0112] S509. After the volume write is completed, a lock release request based on the target resource is sent to the distributed lock manager through the block storage service, so that the distributed lock manager releases the exclusive lock of the target resource based on the lock release request.

[0113] After the volume write is complete, i.e., after sending a cache refresh notification to all nodes via the block storage service, a lock release request based on the target resource is sent to the distributed lock manager via the block storage service. This allows the distributed lock manager to release the exclusive lock on the target resource based on the lock release request. After releasing the exclusive lock on the target resource, the current lock list is updated to update the lock state. After updating the lock state, the distributed lock manager synchronizes the updated lock state to the OCFS2 cluster service on all nodes, so that the OCFS2 cluster service on all nodes knows the latest lock state, facilitating subsequent initiation of corresponding volume operation requests.

[0114] The above-mentioned exclusive locking mechanism ensures that only one node can write to the target volume (i.e., the target resource) at a time, avoiding data overwriting errors caused by concurrent writes from multiple nodes, thus improving data write consistency and security. Before writing data, marking the old caches of other nodes as invalid and notifying a refresh after writing data avoids dirty reads and ensures data consistency across all nodes. Figure 1 To the point of being responsive.

[0115] As described above, volume write operations can be performed on the target resources in the OCFS2 cluster file system in the cloud operating system based on volume write requests through the OCFS2 cluster service of any node. Compared with the existing interaction process where other nodes cannot perform volume writes when a single node fails, this embodiment allows other nodes to still perform volume writes on the target resources in the OCFS2 cluster file system in the cloud operating system based on volume write requests through the OCFS2 cluster service when a single node fails. This achieves interaction where the failure of a single node does not affect the volume write of other nodes, significantly improving the interaction reliability of block storage services in the cloud operating system, thereby improving the overall user experience.

[0116] Figure 7 This is a flowchart illustrating another interaction method between OCFS2 cluster service and block storage service provided in this application embodiment. (Refer to...) Figure 7 The specific interaction methods between the OCFS2 cluster service and the block storage service include: S601, Receive volume operation requests through block storage service.

[0117] S602. The block storage service parses and processes the volume operation request to determine the request type and corresponding request parameters.

[0118] S603. When the request type is a volume deletion request, the corresponding resource identifier is determined by the block storage service based on the request parameters. The request parameters include the volume file path, the operation transaction ID, the node identifier of the target OCFS2 cluster service, and the node timeout threshold.

[0119] After determining the request type, if it is a volume deletion request, the corresponding request parameters—volume file path, operation transaction ID, target OCFS2 cluster service node identifier, and node timeout threshold—can be determined. Then, the block storage service determines the corresponding resource identifier based on the request parameters (volume file path). The target OCFS2 cluster service can be understood as the OCFS2 cluster service intending to request lock permissions.

[0120] S604. Initiate an exclusive lock request to the distributed lock manager of any OCFS2 cluster service through the block storage service.

[0121] After determining the corresponding resource identifier based on the request type being a volume deletion request, an exclusive lock request for the target resource is initiated through the block storage service to the distributed lock manager of any OCFS2 cluster service. The specific steps for initiating the exclusive lock request are the same as those described in S404 above, and will not be repeated here.

[0122] S605. The distributed lock manager performs lock conflict detection on exclusive lock requests. When the lock conflict detection result is no conflict, the exclusive lock permission corresponding to the target resource is granted.

[0123] The distributed lock manager performs lock conflict detection for exclusive lock requests in the same way as described in S405 above, and will not be repeated here. When the lock conflict detection result indicates no conflict, the distributed lock manager grants the target resource the permission to use the shared lock.

[0124] S606. Based on the exclusive lock permissions and resource identifier, the block storage service performs the corresponding volume deletion on the target resource in the OCFS2 cluster file system.

[0125] After granting exclusive lock permissions to the corresponding target resource in the OCFS2 cluster file system, the block storage service performs volume deletion on the target resource in the OCFS2 cluster file system based on the exclusive lock permissions and resource identifier. For example, during volume deletion, the block storage service verifies the volume status, i.e., verifies the current lock status of the target resource, based on the exclusive lock permissions, to prevent other operations from modifying the target resource during lock waiting. After verifying that there are no lock conflicts in the volume status, the volume is deleted. The corresponding target resource (i.e., the target file) can be removed through the file deletion interface of the OCFS2 cluster file system, clearing the internal metadata of the target resource in the OCFS2 cluster file system, such as node conclusions and block mapping tables, and marking the physical space occupied by the volume (i.e., the target resource) as available. After the volume deletion operation is completed, a deletion success notification is returned to the block storage service.

[0126] S607. After the volume deletion is completed, a lock release request based on the target resource is sent to the distributed lock manager through the block storage service, so that the distributed lock manager releases the exclusive lock of the target resource based on the lock release request.

[0127] After the volume deletion is complete, i.e., after the OCFS2 cluster file system returns a successful deletion notification to the block storage service, a lock release request based on the target resource is sent to the distributed lock manager through the block storage service. This allows the distributed lock manager to release the exclusive lock on the target resource based on the lock release request. After releasing the exclusive lock on the target resource, the current lock list is updated to update the lock state. After updating the lock state, the distributed lock manager synchronizes the updated lock state to the OCFS2 cluster service on all nodes, so that the OCFS2 cluster service on all nodes is aware of the latest lock state, facilitating subsequent initiation of corresponding volume operation requests.

[0128] As described above, during the volume deletion operation, exclusive locks prevent other nodes from performing any operations (i.e., read operations, write operations, or snapshot operations, etc.) on the volume (i.e., the target resource), avoiding resource residue caused by interference from other operations during the deletion process and improving the reliability of the volume deletion operation. Furthermore, the physical space is immediately marked as available after the volume deletion is completed, allowing it to be allocated to a new volume without manual intervention, thus improving the storage resource utilization of the OCFS2 cluster file system.

[0129] As described above, the OCFS2 cluster service of any node can perform volume deletion operations on the corresponding target resource in the OCFS2 cluster file system in the cloud operating system based on a volume deletion request. Compared with the existing interaction process where other nodes cannot perform volume deletion when a single node fails, this embodiment allows other nodes to still perform volume deletion on the corresponding target resource in the OCFS2 cluster file system in the cloud operating system based on a volume deletion request when a single node fails. This achieves interaction where the failure of a single node does not affect the volume writing of other nodes, significantly improving the interaction reliability of block storage services in the cloud operating system, thereby improving the overall user experience.

[0130] Based on the above embodiments, Figure 8 This is a schematic diagram illustrating the structure of an interaction device for OCFS2 cluster service and block storage service provided in an embodiment of this application. (Reference) Figure 8The interaction device between the OCFS2 cluster service and the block storage service provided in this embodiment is used in a cloud operating system. The cloud operating system is equipped with a block storage service. All nodes in the cloud operating system are mounted with corresponding OCFS2 cluster services. Each node is equipped with a distributed lock manager. A corresponding OCFS2 cluster file system is created in the cloud operating system. The OCFS2 cluster service of each node can perform corresponding volume operations on the OCFS2 cluster file system through the mounted connection. The interaction device between the OCFS2 cluster service and the block storage service specifically includes: a volume operation request receiving module 21, a request parsing module 22, a lock request initiation module 23, a lock conflict detection module 24, a lock permission granting module 25, an operation execution module 26, and a lock release module 27.

[0131] The volume operation request receiving module 21 is used to receive volume operation requests through the block storage service. The request parsing module 22 is used to parse and process volume operation requests, determine the request type and resource identifier. The request types include volume creation request, volume read request, volume write request, volume snapshot request and volume deletion request. The resource identifier is the identifier of the target resource in the OCFS2 cluster file system corresponding to the volume operation to be performed. The lock request initiation module 23 is used to initiate a corresponding lock request to the distributed lock manager of any OCFS2 cluster service through the block storage service according to the request type. The lock request is either an exclusive lock request or a shared lock request. The lock request includes a resource identifier and is used to request the granting of an exclusive lock or a shared lock to the target resource. Lock conflict detection module 24 is used to detect lock conflicts in lock requests through a distributed lock manager; The lock permission granting module 25 is used to grant lock permissions to the target resource when the lock conflict detection result is no conflict; Operation execution module 26 is used to perform the corresponding target operation on the target resource according to the lock permission and resource identifier through the block storage service; The lock release module 27 is used to send a lock release request based on the target resource to the distributed lock manager through the block storage service after the target operation is completed, so that the distributed lock manager updates the lock state based on the lock release request and synchronizes the lock state to the OCFS2 cluster service of all nodes.

[0132] In one embodiment, the request parsing module 22 includes: a volume operation request sending submodule, a request parsing submodule, and a resource identifier determination submodule; The volume operation request sending submodule is used to receive volume operation requests through the block storage service; The request parsing submodule is used to parse and process volume operation requests through the block storage service to determine the request type and corresponding request parameters; The resource identifier determination submodule is used to determine the corresponding resource identifier based on the request parameters through the block storage service when the request type is a volume read request or a volume snapshot request. The request parameters include the volume file path and the node identifier of the target OCFS2 cluster service. Based on the above implementation, the lock request initiation module 23 is also used to initiate a shared lock request to the distributed lock manager of any OCFS2 cluster service through the block storage service when the request type is a volume read request or a volume snapshot request.

[0133] In one embodiment, the operation execution module 26 includes: a snapshot file creation submodule, a target resource determination submodule, a lock request submodule, and a snapshot execution submodule; The snapshot file creation submodule is used to create a blank snapshot copy file in the OCFS2 cluster file system through the block storage service when the request type is a volume snapshot request; The target resource determination submodule is used to determine the target resource in the OCFS2 cluster file system based on the resource identifier through the block storage service. The lock request submodule is used to request shared lock requests based on the target resource and exclusive lock requests based on snapshot copy files from the distributed lock manager of any OCFS2 cluster service through the block storage service according to the lock permissions. The snapshot execution submodule is used to synchronize the data of the target resource to the snapshot copy file through the block storage service after the distributed lock manager grants the target resource a shared lock and an exclusive lock on the snapshot copy file, generating a read-only snapshot copy. Based on the above implementation, the lock release module 27 includes: a first association information recording submodule, a first association information storage submodule, and a lock release request submodule; The first association information recording submodule is used to record the first association information between the snapshot copy and the target resource through the block storage service after synchronization is completed; The first associated information storage submodule is used to update the first associated information to the database of the cloud operating system; The lock release request submodule is used to send a lock release request based on the target resource to the distributed lock manager through the block storage service, so that the distributed lock manager releases the shared lock of the target resource based on the lock release request.

[0134] Based on the above embodiments, the volume operation request sending submodule is also used to receive volume operation requests through the block storage service; The request parsing submodule is also used to parse and process volume operation requests through the block storage service to determine the request type and corresponding request parameters; The resource identifier determination submodule is also used to determine the corresponding resource identifier through the block storage service based on the request parameters when the request type is a volume creation request, volume write request, or volume delete request. The request parameters include the volume file path, operation transaction ID, node identifier of the target OCFS2 cluster service, and node timeout threshold. Based on the above implementation, the lock request initiation module 23 is also used to initiate an exclusive lock request to the distributed lock manager of any OCFS2 cluster service through the block storage service when the request type is a volume creation request, a volume write request, or a volume deletion request.

[0135] In one embodiment, the operation execution module 26 includes: a file creation instruction sending submodule, a file creation submodule, a resource identifier return submodule, a second association information determination submodule, and a second association information storage submodule; The file creation instruction sending submodule is used to send a volume file creation instruction to the OCFS2 cluster file system through the block storage service based on the lock permission when the request type is a volume creation request and after the target resource has acquired the exclusive lock permission. The volume file creation instruction includes volume capacity, storage path and file system block size information. The file creation submodule is used to create blank volume files of the corresponding size in the corresponding shared storage space according to the volume file creation instructions through the OCFS2 cluster file system. The resource identifier return submodule is used to return the resource identifier corresponding to the blank volume file to the block storage service; The second association information determination submodule is used to associate the resource identifier and volume metadata through the block storage service to obtain the corresponding second association information; The second associated information storage submodule is used to update the second associated information to the database of the cloud operating system.

[0136] In one embodiment, the operation execution module 26 includes: a cache invalidation instruction sending submodule, a data writing submodule, a cache update submodule, a success notification feedback submodule, and a cache refresh notification submodule; The cache invalidation instruction sending submodule is used to send a cache invalidation instruction to other nodes based on the lock permissions through the block storage service when the request type is a volume write request, after the target resource has acquired the exclusive lock permission. This enables other nodes to mark the corresponding file cache as invalid based on the cache invalidation instruction. The data writing submodule is used to write the received data into the corresponding target resource in the OCFS2 cluster file system according to the resource identifier through the block storage service. The cache update submodule is used to update the local cache and synchronize it to the corresponding shared storage space through the OCFS2 cluster file system after the write is completed; The success notification feedback submodule is used to send a success notification to the block storage service. The cache refresh notification submodule is used to send a cache refresh notification to all nodes after the block storage service receives a successful operation notification.

[0137] In one embodiment, the lock conflict detection module 24 includes: a current lock state determination submodule, a first detection result determination submodule, and a second detection result determination submodule; The current lock state determination submodule is used to query the current lock record table through the distributed lock manager to determine the current lock state of the target resource corresponding to the resource identifier in the OCFS2 cluster file system; The first detection result determination submodule is used to determine that there is no conflict when the lock request is a shared lock request and the current lock state is unlocked or only a shared lock. The second detection result determination submodule is used to determine that there is no conflict when the lock request is an exclusive lock request and the current lock state is unlocked.

[0138] The interaction device for OCFS2 cluster service and block storage service provided in this application embodiment can be used to execute the interaction method of OCFS2 cluster service and block storage service provided in the above embodiment, and has corresponding functions and beneficial effects.

[0139] This application provides an interactive device for OCFS2 cluster service and block storage service, referring to... Figure 9 The interaction device between the OCFS2 cluster service and the block storage service includes: a processor 31, a memory 32, a communication module 33, an input device 34, and an output device 35. The number of processors and the number of memories in the interaction device can both be one and more. The processor, memory, communication module, input device, and output device of the interaction device can be connected via a bus or other means.

[0140] The memory 32, as a computer-readable storage medium, can be used to store software programs, computer-executable programs, and modules, such as program instructions / modules corresponding to the interaction method between the OCFS2 cluster service and block storage service described in any embodiment of this application (e.g., the volume operation request receiving module, request parsing module, lock request initiation module, lock conflict detection module, lock permission granting module, operation execution module, and lock release module in the interaction device between the OCFS2 cluster service and block storage service). The memory may mainly include a program storage area and a data storage area, wherein 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. In addition, the memory may include high-speed random access memory, and may also include 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 may further include memory remotely located relative to the processor, and these remote memories can be connected to the device via a network. Examples of the above-mentioned networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0141] The communication module 33 is used for data transmission.

[0142] The processor 31 executes various functional applications and data processing of the device by running software programs, instructions and modules stored in the memory, thereby realizing the above-mentioned interaction method between OCFS2 cluster service and block storage service.

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

[0144] The interaction device for the OCFS2 cluster service and block storage service provided above can be used to execute the interaction method for the OCFS2 cluster service and block storage service provided in the above embodiments, and has corresponding functions and beneficial effects.

[0145] This application embodiment also provides a storage medium for storing computer-executable instructions. When executed by a computer processor, the computer-executable instructions are used to perform an interaction method between an OCFS2 cluster service and a block storage service. This interaction method includes: receiving a volume operation request through the block storage service, parsing the volume operation request, and determining the request type and resource identifier. The request type includes volume creation requests, volume read requests, volume write requests, volume snapshot requests, and volume deletion requests. The resource identifier is the identifier of the target resource in the OCFS2 cluster file system corresponding to the volume operation to be performed. The block storage service root... Based on the request type, a corresponding lock request is initiated to the distributed lock manager of any OCFS2 cluster service. The lock request can be an exclusive lock request or a shared lock request, and includes a resource identifier. The distributed lock manager performs lock conflict detection on the lock request. If the lock conflict detection result is no conflict, the lock permission corresponding to the target resource is granted. The block storage service executes the corresponding target operation on the target resource according to the lock permission and the resource identifier. After the target operation is completed, the block storage service sends a lock release request based on the target resource to the distributed lock manager, so that the distributed lock manager updates the lock state based on the lock release request and synchronizes the lock state to the OCFS2 cluster service on all nodes.

[0146] Storage medium – any type of memory device or storage device. The term “storage medium” is intended to include: mounting media, such as CD-ROM, floppy disk, or magnetic tape devices; computer system memory or random access memory, such as DRAM, DDR RAM, SRAM, EDO RAM, 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, etc. Storage medium may also include other types of memory or combinations thereof. Furthermore, 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 term “storage medium” can include two or more storage media residing in different locations (e.g., in different computer systems connected via a network). Storage medium may store program instructions (e.g., specifically implemented as a computer program) executable by one or more processors.

[0147] Of course, the computer-executable instructions provided in the embodiments of this application are not limited to the interaction method between OCFS2 cluster service and block storage service as described above, but can also execute related operations in the interaction method between OCFS2 cluster service and block storage service provided in any embodiment of this application.

[0148] The interaction device, storage medium, and interaction equipment for OCFS2 cluster service and block storage service provided in the above embodiments can execute the interaction method for OCFS2 cluster service and block storage service provided in any embodiment of this application. For technical details not described in detail in the above embodiments, please refer to the interaction method for OCFS2 cluster service and block storage service provided in any embodiment of this application.

[0149] The above description is merely a preferred embodiment and the technical principles employed in this application. This application is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions that can be made by those skilled in the art will not depart from the scope of protection of this application. Therefore, although this application has been described in detail through the above embodiments, this application is not limited to the above embodiments, and may include more other equivalent embodiments without departing from the concept of this application, the scope of which is determined by the scope of the claims.

Claims

1. A method for interaction between OCFS2 cluster service and block storage service, characterized in that, For use in a cloud operating system, the cloud operating system is equipped with the block storage service, all nodes in the cloud operating system are mounted with corresponding OCFS2 cluster services, each node is equipped with a distributed lock manager, the cloud operating system creates a corresponding OCFS2 cluster file system, and the OCFS2 cluster service of each node can perform corresponding volume operations on the OCFS2 cluster file system through the mount connection, the method includes: The block storage service receives volume operation requests and parses and processes them to determine the request type and resource identifier. The request type includes volume creation request, volume read request, volume write request, volume snapshot request, and volume delete request. The resource identifier is the identifier of the target resource in the OCFS2 cluster file system corresponding to the volume operation to be performed. The block storage service initiates a corresponding lock request to the distributed lock manager of any of the OCFS2 cluster services according to the request type. The lock request is either an exclusive lock request or a shared lock request, and the lock request includes the resource identifier. The distributed lock manager performs lock conflict detection on the lock request, and grants the lock permission corresponding to the target resource when the lock conflict detection result is no conflict; The block storage service performs the corresponding target operation on the target resource based on the lock permission and the resource identifier. After the target operation is completed, the block storage service sends a lock release request based on the target resource to the distributed lock manager, so that the distributed lock manager updates the lock state based on the lock release request and synchronizes the lock state to the OCFS2 cluster service of all nodes.

2. The method according to claim 1, characterized in that, The step of receiving volume operation requests through the block storage service and parsing the volume operation requests to determine the request type and resource identifier includes: Receive volume operation requests through the block storage service; The block storage service parses and processes the volume operation request to determine the request type and corresponding request parameters. When the request type is a volume read request or a volume snapshot request, the block storage service determines the corresponding resource identifier based on the request parameters, which include the volume file path and the node identifier of the target OCFS2 cluster service. Accordingly, the step of initiating a corresponding lock request to the distributed lock manager of any of the OCFS2 cluster services through the block storage service according to the request type includes: When the request type is a volume read request or a volume snapshot request, a shared lock request is initiated to the distributed lock manager of any of the OCFS2 cluster services through the block storage service.

3. The method according to claim 2, characterized in that, The step of performing the corresponding target operation on the target resource through the block storage service based on the lock permission and the resource identifier includes: When the request type is a volume snapshot request, a blank snapshot copy file is created in the OCFS2 cluster file system through the block storage service; The target resource in the OCFS2 cluster file system is determined by the block storage service based on the resource identifier; The block storage service requests a shared lock request based on the target resource and an exclusive lock request based on the snapshot copy file from the distributed lock manager of any of the OCFS2 cluster services according to the lock permissions. After the distributed lock manager grants the target resource a shared lock and the snapshot copy file an exclusive lock, the data of the target resource is synchronized to the snapshot copy file through the block storage service to generate a read-only snapshot copy. Accordingly, after the target operation is completed, sending a lock release request to the distributed lock manager through the block storage service includes: After synchronization is complete, the first association information between the snapshot copy and the target resource is recorded through the block storage service, and the first association information is updated to the database of the cloud operating system; The block storage service sends a lock release request based on the target resource to the distributed lock manager, so that the distributed lock manager releases the shared lock of the target resource based on the lock release request.

4. The method according to claim 1, characterized in that, The step of receiving volume operation requests through the block storage service and parsing the volume operation requests to determine the request type and resource identifier includes: Receive volume operation requests through the block storage service; The block storage service parses and processes the volume operation request to determine the request type and corresponding request parameters. When the request type is a volume creation request, a volume write request, or a volume deletion request, the block storage service determines the corresponding resource identifier based on the request parameters. The request parameters include the volume file path, the operation transaction ID, the node identifier of the target OCFS2 cluster service, and the node timeout threshold. Accordingly, the step of initiating a corresponding lock request to the distributed lock manager of the OCFS2 cluster service through the block storage service based on the request type includes: When the request type is a volume creation request, a volume write request, or a volume deletion request, an exclusive lock request is initiated to the distributed lock manager of any of the OCFS2 cluster services through the block storage service.

5. The method according to claim 4, characterized in that, The step of performing the corresponding target operation on the target resource through the block storage service based on the lock permission and the resource identifier includes: When the request type is a volume creation request, after the target resource obtains the exclusive lock permission, the block storage service sends a volume file creation instruction to the OCFS2 cluster file system based on the lock permission. The volume file creation instruction includes volume capacity, storage path and file system block size information. The OCFS2 cluster file system creates a blank volume file of the corresponding size in the corresponding shared storage space according to the volume file creation instruction, and returns the resource identifier corresponding to the blank volume file to the block storage service. The resource identifier and volume metadata are associated through the block storage service to obtain the corresponding second association information, and the second association information is updated to the database of the cloud operating system.

6. The method according to claim 4, characterized in that, The step of performing the corresponding target operation on the target resource through the block storage service based on the lock permission and the resource identifier includes: When the request type is a volume write request, after the target resource acquires the exclusive lock permission, the block storage service sends a cache invalidation instruction to other nodes based on the lock permission, so that other nodes mark the corresponding file cache as invalid based on the cache invalidation instruction; The block storage service writes the received data into the corresponding target resource in the OCFS2 cluster file system according to the resource identifier. After the writing is completed, the local cache is updated and synchronized to the corresponding shared storage space through the OCFS2 cluster file system, and a successful operation notification is sent to the block storage service. After the block storage service receives the successful operation notification, it sends a cache refresh notification to all nodes.

7. The method according to claim 1, characterized in that, The step of detecting lock conflicts in the lock request through the distributed lock manager includes: The current lock status of the target resource corresponding to the resource identifier in the OCFS2 cluster file system is determined by querying the current lock record table through the distributed lock manager. When the lock request is a shared lock request and the current lock state is unlocked or only a shared lock, the lock conflict detection result is determined to be conflict-free; When the lock request is an exclusive lock request and the current lock state is unlocked, the lock conflict detection result is determined to be conflict-free.

8. An interaction device for OCFS2 cluster service and block storage service, characterized in that, For use in a cloud operating system, the cloud operating system is equipped with the block storage service, all nodes in the cloud operating system are mounted with corresponding OCFS2 cluster services, each node is equipped with a distributed lock manager, the cloud operating system creates a corresponding OCFS2 cluster file system, and the OCFS2 cluster service of each node can perform corresponding volume operations on the OCFS2 cluster file system through the mount connection, the device includes: A volume operation request receiving module is used to receive volume operation requests through the block storage service. The request parsing module is used to parse and process the volume operation request, determine the request type and resource identifier. The request type includes volume creation request, volume read request, volume write request, volume snapshot request and volume delete request. The resource identifier is the identifier of the target resource in the OCFS2 cluster file system corresponding to the volume operation to be performed. The lock request initiation module is used to initiate a corresponding lock request to any distributed lock manager of the OCFS2 cluster service through the block storage service according to the request type. The lock request is either an exclusive lock request or a shared lock request, and the lock request includes the resource identifier. The lock conflict detection module is used to perform lock conflict detection on the lock request through the distributed lock manager; The lock permission granting module is used to grant the lock permission corresponding to the target resource when the lock conflict detection result is no conflict; The operation execution module is used to perform a corresponding target operation on the target resource through the block storage service based on the lock permission and the resource identifier; The lock release module is used to send a lock release request based on the target resource to the distributed lock manager through the block storage service after the target operation is completed, so that the distributed lock manager updates the lock state based on the lock release request and synchronizes the lock state to the OCFS2 cluster service of all nodes.

9. An interactive device for OCFS2 cluster service and block storage service, characterized in that, include: Memory and one or more processors; The memory is used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-7.

10. A storage medium for storing computer-executable instructions, characterized in that, The computer-executable instructions, when executed by a processor, are used to perform the method as described in any one of claims 1-7.

Images