Dual-active storage implementation method, device, equipment and readable storage medium

Abstract

The application provides a dual-active storage implementation method, device and equipment and a readable storage medium. Any storage device in the application constructs a candidate LUN ID set after receiving a dual-active LUN mapping request, and negotiates with another storage device based on a currently attempted pre-occupied LUN ID through a pre-occupation mechanism, so that another storage device decides whether to allow the storage device receiving the dual-active LUN mapping request to perform mapping processing based on the pre-occupied LUN ID based on a local resource state, thereby obtaining a LUN ID for assigning to a dual-active LUN pair based on a decision result, realizing dual-active LUN ID allocation without conflict between two storage devices, and both of the two storage devices in the embodiment can be used to deploy a primary LUN of the dual-active LUN pair, further realizing balanced deployment of the primary LUN across devices, and avoiding performance bottlenecks caused by the fact that I / O traffic of a computing node accessing the primary LUN is concentrated on a single storage device.

Description

Technical Field

[0001] This application relates to the field of data storage technology, and in particular to a dual-active storage implementation method, apparatus, device, and readable storage medium. Background Technology

[0002] In a cloud platform environment, the storage system authorizes LUNs on storage devices to be used by hosts through I_T_L (Initiator_Target_LUN, host_port_logical unit number) mapping. Active-active storage technology further enhances business continuity by deploying a consistent primary LUN and a mirrored LUN on two independent storage devices, providing read and write services simultaneously. When performing I_T_L mapping in an active-active LUN scenario, the cloud platform requires that the active-active primary LUN and mirrored LUN distributed across the two storage devices be assigned the same LUN ID.

[0003] To address this, relevant technologies generally employ a centralized LUN ID allocation mechanism on the master end. This involves pre-designating one of the two storage devices as the master storage device (referred to as the master). All primary LUNs for dual-active LUNs are deployed on this master, and all dual-active LUN mapping requests are handled uniformly by the master. The master queries its own free LUN IDs and the other storage device on the other end of the two storage devices, calculates the intersection of the free LUN IDs on both ends, and selects one LUN ID from the intersection as the LUN ID to be allocated to the dual-active LUN.

[0004] While this approach can guarantee ID consistency, all active-active LUNs are centrally deployed on a pre-designated master device. All read and write requests must be processed through the master device, resulting in long-term high load or even overload on critical resources such as the master device's CPU, memory cache, and network bandwidth. Meanwhile, the peer storage device is relatively idle, leading to uneven resource utilization. The master device becomes a performance bottleneck and a single point of dependence, which restricts the performance of the active-active storage system and makes it difficult to meet the comprehensive requirements of modern data centers for high performance, high reliability, and adaptive scheduling. Summary of the Invention

[0005] In view of this, in order to solve the above-mentioned technical problems, this application provides a dual-active storage implementation method, apparatus, device and readable storage medium, which realizes the balanced deployment of the primary LUN of dual-active LUN across devices. The primary LUN can be deployed on either of the two independent storage devices and the received dual-active LUN mapping request can be processed to ensure that the dual-active LUN is assigned the same LUN ID on the two storage devices, while improving the overall I / O throughput and resource utilization of the system.

[0006] Specifically, this application is implemented through the following technical solution: According to a first aspect of the embodiments of this application, a dual-active storage implementation method is provided, applied to a first storage device where the primary LUN of a dual-active LUN pair is located; the first storage device is any one of two independent physical storage devices; the dual-active LUN consists of a primary LUN and a mirror LUN; the mirror LUN is deployed on a second storage device other than the first storage device among the two independent physical storage devices; the method includes: A dual-active LUN mapping request is received, and a candidate LUN ID set is determined based on the dual-active LUN mapping request; wherein, the dual-active LUN mapping request is used to indicate that the same LUN ID is allocated to the dual-active LUN pair; the candidate LUN ID set includes candidate LUN IDs that meet the following conditions: they are within the range of LUN IDs supported by both the first storage device and the second storage device, and the LUN ID is in a state of not being mapped and not being pre-occupied on both the first storage device and the second storage device; Select a LUN ID from the unselected candidate LUN IDs in the candidate LUN ID set as the pre-occupied LUN ID, and send a pre-occupancy request for the pre-occupied LUN ID to the second storage device; The system receives the decision result returned by the second storage device in response to the pre-occupancy request. If the decision result indicates that the first storage device is allowed to perform mapping processing based on the pre-occupancy LUN ID, then the system allocates the pre-occupancy LUN ID to the primary LUN and the mirror LUN in the dual-active LUN pair. If the decision result indicates that the first storage device is prohibited from performing mapping processing based on the pre-occupancy LUN ID, then the system returns to the step of selecting a LUN ID as the pre-occupancy LUN ID from the unselected candidate LUN IDs in the candidate LUN ID set.

[0007] Optionally, the second storage device returns the decision result in the following manner: The second storage device receives the pre-occupancy request and, based on whether the pre-occupancy LUN ID in the pre-occupancy request is in a pre-occupancy state locally in the second storage device, decides whether to allow the first storage device to perform mapping processing based on the pre-occupancy LUN ID, and returns the corresponding decision result to the first storage device.

[0008] Optionally, the decision on whether to allow the first storage device to perform mapping processing based on the pre-occupied LUN ID includes: If the pre-occupied LUN ID is not in a pre-occupied state locally in the second storage device, a decision result indicating that the first storage device is allowed to perform mapping processing based on the pre-occupied LUN ID is returned to the first storage device; otherwise, the pre-occupied type of the pre-occupied LUN ID in the second storage device is further determined; if the pre-occupied type indicates that it belongs to the pre-occupied type of non-dual-active LUN, a decision result indicating that the first storage device is prohibited from performing mapping processing based on the pre-occupied LUN ID is returned to the first storage device.

[0009] Optionally, the method further includes: If the pre-occupancy type indicates that it belongs to the pre-occupancy of a dual-active LUN type, then obtain the first pre-occupancy time of the pre-occupancy LUN ID in the first storage device from the pre-occupancy request, and query the second pre-occupancy time of the LUN ID with the same pre-occupancy LUN ID in the second storage device. If the first pre-occupancy time is earlier than the second pre-occupancy time, a decision result indicating that the first storage device is allowed to perform mapping processing based on the pre-occupancy LUN ID is returned to the first storage device; If the first pre-occupancy time is later than the second pre-occupancy time, a decision result indicating that the first storage device should not perform mapping processing based on the pre-occupancy LUN ID is returned to the first storage device.

[0010] Optionally, the method further includes: If the first pre-occupancy time and the second pre-occupancy time are the same, obtain the first complete serial number of the first storage device from the pre-occupancy request, and obtain the second complete serial number of the pre-occupancy initiating device of the same LUN ID as the pre-occupancy LUN ID in the second storage device; If the first complete machine serial number is less than the second complete machine serial number, a decision result indicating that the first storage device is allowed to perform mapping processing based on the pre-occupied LUN ID is returned to the first storage device; otherwise, a decision result indicating that the first storage device is prohibited from performing mapping processing based on the pre-occupied LUN ID is returned to the first storage device.

[0011] Optionally, the pre-occupancy request carries pre-occupancy information; the pre-occupancy information includes at least: a pre-occupancy LUNID, a first pre-occupancy time of the pre-occupancy LUNID in the first storage device, a first system serial number of the first storage device, and a pre-occupancy type; the pre-occupancy type is used to indicate whether the pre-occupancy LUNID belongs to the pre-occupancy of a dual-active LUN type; After the second storage device returns a decision result to the first storage device indicating that the first storage device is allowed to perform mapping processing based on the pre-occupied LUN ID, the method further includes: maintaining local occupancy information of the pre-occupied LUN ID in the second storage device based on the pre-occupancy information in the pre-occupancy request.

[0012] Optionally, the method further includes: When the first storage device receives the dual-active LUN mapping request, it acquires an operation mutex maintained by the first storage device; the operation mutex is used to maintain the atomicity of processing the dual-active LUN mapping request; the operation mutex is released when any of the following conditions are met; wherein, the conditions include: the mapping operation based on the pre-occupied LUN ID is completed; or, all candidate LUN IDs in the candidate LUN ID set have been traversed.

[0013] Optionally, determining the candidate LUN ID set based on the dual-active LUN mapping request includes: Obtain all LUN IDs within the LUN ID range supported by the first storage device that are in a state of being neither mapped nor pre-occupied, to obtain a first LUN ID set; send a LUN ID query request to the second storage device to obtain a second LUN ID set corresponding to each LUN ID within the LUN ID range supported by the second storage device that is in a state of being neither mapped nor pre-occupied; obtain the candidate LUNID set based on the intersection of the first LUN ID set and the second LUN ID set.

[0014] According to a second aspect of the present application, a dual-active storage implementation apparatus is provided, applied to a first storage device where the primary LUN of a dual-active LUN pair is located; the first storage device is either one of two independent physical storage devices; the dual-active LUN consists of a primary LUN and a mirrored LUN; the mirrored LUN is deployed on a second storage device other than the first storage device among the two independent physical storage devices; the apparatus includes: The candidate LUN ID acquisition module is configured to receive a dual-active LUN mapping request and determine a candidate LUN ID set based on the dual-active LUN mapping request; wherein, the dual-active LUN mapping request is used to indicate that the same LUN ID is allocated to the dual-active LUN pair; the candidate LUN ID set includes candidate LUN IDs that meet the following conditions: they are within the range of LUN IDs supported by both the first storage device and the second storage device, and the LUN ID is in a state of not being mapped and not being pre-occupied on both the first storage device and the second storage device; The pre-occupancy negotiation module is configured to select a LUN ID as a pre-occupancy LUN ID from the unselected candidate LUN IDs in the candidate LUN ID set, and send a pre-occupancy request for the pre-occupancy LUN ID to the second storage device; The active-active LUN ID mapping module is configured to receive a decision result returned by the second storage device in response to the pre-occupancy request. If the decision result indicates that the first storage device is allowed to perform mapping processing based on the pre-occupancy LUN ID, then the pre-occupancy LUN ID is allocated to the primary LUN and the mirror LUN in the active-active LUN pair. If the decision result indicates that the first storage device is prohibited from performing mapping processing based on the pre-occupancy LUN ID, then the step of selecting a LUN ID as the pre-occupancy LUN ID from the unselected candidate LUN IDs in the candidate LUN ID set is returned.

[0015] Optionally, the second storage device returns the decision result in the following manner: the second storage device receives the pre-occupancy request, and based on whether the pre-occupancy LUN ID in the pre-occupancy request is in a pre-occupancy state locally in the second storage device, decides whether to allow the first storage device to perform mapping processing based on the pre-occupancy LUN ID, and returns the corresponding decision result to the first storage device.

[0016] Optionally, when deciding whether to allow the first storage device to perform mapping processing based on the pre-occupied LUN ID, the second storage device includes: If the pre-occupied LUN ID is not in a pre-occupied state locally in the second storage device, a decision result indicating that the first storage device is allowed to perform mapping processing based on the pre-occupied LUN ID is returned to the first storage device; otherwise, the pre-occupied type of the pre-occupied LUN ID in the second storage device is further determined; if the pre-occupied type indicates that it belongs to the pre-occupied type of non-dual-active LUN, a decision result indicating that the first storage device is prohibited from performing mapping processing based on the pre-occupied LUN ID is returned to the first storage device.

[0017] Optionally, when deciding whether to allow the first storage device to perform mapping processing based on the pre-occupied LUN ID, the second storage device further includes: If the pre-occupancy type indicates that it belongs to the pre-occupancy of a dual-active LUN type, then obtain the first pre-occupancy time of the pre-occupancy LUN ID in the first storage device from the pre-occupancy request, and query the second pre-occupancy time of the LUN ID with the same pre-occupancy LUN ID in the second storage device. If the first pre-occupancy time is earlier than the second pre-occupancy time, a decision result indicating that the first storage device is allowed to perform mapping processing based on the pre-occupancy LUN ID is returned to the first storage device; If the first pre-occupancy time is later than the second pre-occupancy time, a decision result indicating that the first storage device should not perform mapping processing based on the pre-occupancy LUN ID is returned to the first storage device.

[0018] Optionally, when deciding whether to allow the first storage device to perform mapping processing based on the pre-occupied LUN ID, the second storage device further includes: When the first pre-occupancy time and the second pre-occupancy time are the same, the first complete serial number of the first storage device is obtained from the pre-occupancy request, and the second complete serial number of the pre-occupancy initiating device with the same LUN ID as the pre-occupancy LUN ID in the second storage device is obtained; If the first complete machine serial number is less than the second complete machine serial number, a decision result indicating that the first storage device is allowed to perform mapping processing based on the pre-occupied LUN ID is returned to the first storage device; otherwise, a decision result indicating that the first storage device is prohibited from performing mapping processing based on the pre-occupied LUN ID is returned to the first storage device.

[0019] Optionally, the pre-occupancy request carries pre-occupancy information; the pre-occupancy information includes at least: a pre-occupancy LUNID, a first pre-occupancy time of the pre-occupancy LUNID in the first storage device, a first system serial number of the first storage device, and a pre-occupancy type; the pre-occupancy type is used to indicate whether the pre-occupancy LUNID belongs to the pre-occupancy of a dual-active LUN type; After the second storage device returns a decision result to the first storage device indicating that the first storage device is allowed to perform mapping processing based on the pre-occupied LUN ID, the device further includes: maintaining local occupancy information of the pre-occupied LUN ID in the second storage device based on the pre-occupancy information in the pre-occupancy request.

[0020] Optionally, the device further includes: The mutex lock acquisition and release module is configured to acquire an operation mutex lock maintained by the first storage device when the dual-active LUN mapping request is received; the operation mutex lock is used to maintain the atomicity of processing the dual-active LUN mapping request; and release the operation mutex lock when any of the following conditions are met; wherein the conditions include: the mapping operation based on the pre-occupied LUNID is completed; or, all candidate LUN IDs in the candidate LUN ID set have been traversed.

[0021] Optionally, when the pre-occupancy negotiation module is configured to determine the candidate LUN ID set based on the dual-active LUN mapping request, it includes: Obtain all LUN IDs within the LUN ID range supported by the first storage device that are in a state of being neither mapped nor pre-occupied, to obtain a first LUN ID set; send a LUN ID query request to the second storage device to obtain a second LUN ID set corresponding to each LUN ID within the LUN ID range supported by the second storage device that is in a state of being neither mapped nor pre-occupied; obtain the candidate LUNID set based on the intersection of the first LUN ID set and the second LUN ID set.

[0022] According to a third aspect of the embodiments of this application, an electronic device is provided, the electronic device comprising: a memory and a processor; the memory being used to store a computer program; the processor being used to execute the above-described dual-active storage implementation method by invoking the computer program.

[0023] According to a fourth aspect of the embodiments of this application, a computer-readable storage medium is provided, on which a computer program is stored, wherein the program, when executed by a processor, implements the above-described dual-active storage implementation method.

[0024] The technical solutions provided in this application embodiment may include the following beneficial effects: In the technical solution provided in this application, both storage devices can be used to deploy the primary LUN of a dual-active LUN pair. After receiving a dual-active LUN mapping request, each storage device constructs a candidate LUN ID set and negotiates with the other storage device based on the currently attempted pre-occupied LUN ID through the pre-occupied mechanism provided in this embodiment. This allows the other storage device to decide whether to allow the storage device receiving the dual-active LUN mapping request to perform mapping processing based on the pre-occupied LUN ID based on its local resource status. Thus, based on the decision result of the other storage device, the LUN ID used to allocate to the dual-active LUN pair is obtained, realizing conflict-free dual-active LUN ID allocation between the two storage devices. While ensuring that the LUN IDs at both ends of the dual-active LUN are completely consistent, the cross-device balanced deployment of the primary LUN is achieved, avoiding the bottleneck problem of single point of access in related technologies and improving the overall I / O throughput and resource utilization of the system.

[0025] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this application. Furthermore, no embodiment in this application needs to achieve all the effects described above. Attached Figure Description

[0026] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0027] Figure 1 This is an exemplary flowchart of a dual-active LUN ID allocation process based on centralized computing at the master end in a related technology. Figure 2A This is a schematic diagram illustrating the main interaction of a dual-active storage implementation method according to an exemplary embodiment of this application; Figure 2B This is a flowchart illustrating an exemplary embodiment of a dual-active storage implementation method according to this application; Figure 3A This is an exemplary embodiment of the present application illustrating a decision flowchart of a second storage device deciding whether to allow the first storage device to perform mapping processing based on the pre-occupied LUN ID; Figure 3B This is a flowchart illustrating the steps of a second storage device decision-making process based on the pre-occupancy LUNID in the pre-occupancy operation context information of the first storage device, as shown in an exemplary embodiment of this application. Figure 4 This is a schematic diagram of the structure of a dual-active storage implementation device shown in an exemplary embodiment of this application; Figure 5 This is a hardware schematic diagram of an electronic device illustrated in an exemplary embodiment of this application. Detailed Implementation

[0028] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims. It should be understood that although the terms first, second, third, etc., may be used in this application to describe various information, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another.

[0029] With the rapid development of technologies such as cloud computing, big data, and artificial intelligence, enterprises are increasingly demanding higher availability, business continuity, and performance from their data storage systems. Active-active storage systems, as an advanced data protection and disaster recovery architecture, are widely used in critical business scenarios such as finance, telecommunications, government, and the internet.

[0030] Active-active storage systems, also known simply as dual-active, are positioned for data protection and business continuity. Building upon cross-device mirroring, they support simultaneous service provision from both LUN pairs within the mirrored system. In an active-active storage system, both data centers (or two independent LUNs) are active and simultaneously provide read and write services. Data is synchronized in real-time between the two ends. If either end fails, the other end can seamlessly take over the service, achieving zero-interruption failover. This architecture not only possesses the data protection capabilities of traditional disaster recovery systems but also effectively improves resource utilization and overall system performance, meeting the high-concurrency, low-latency access requirements of modern businesses.

[0031] To facilitate understanding of the technical solution of this invention, the key terms involved are defined and explained below: LUN (Logical Unit Number): A LUN is a logical storage space provided by a storage device to a cloud platform node (such as an application server). In a SAN (Storage Area Network) environment, the LUN is the basic addressing unit in the SCSI protocol, allocated and mapped by the controller to designated cloud platform nodes. By allocating LUNs, administrators can flexibly manage storage resources, allocate large-capacity storage to different servers on demand, and control access permissions.

[0032] LUN ID (LUN Identifier): A unique identifier for a logical storage unit that can be accessed under a target. It is used to uniquely identify different LUNs under the same target and is typically an integer between 0 and 255. Multiple LUNs can be provided under a single target, and each LUN has a unique identifier called a LUN ID to distinguish different storage volumes under the same target.

[0033] Active-active LUN: A high-availability storage resource consisting of two LUNs: a primary LUN and a mirror LUN. The primary and mirror LUNs are deployed on two physically independent storage devices and support simultaneous read / write requests or rapid failover at both ends. In normal operation, one replica acts as the primary LUN, providing read / write access services; the other replica acts as the mirror LUN (or secondary LUN), maintaining data consistency with the primary LUN in real time through a data synchronization mechanism. To ensure system redundancy and disaster recovery capabilities, the primary and mirror LUNs are deployed on two physically independent, mutually backup storage devices, avoiding single-point-of-failure risks.

[0034] Initiator: Refers to the cloud platform node or host (such as a database server or virtual machine host) that initiates the storage access request, actively sending SCSI commands to the storage device through the HBA card or iSCSI interface.

[0035] Target: Refers to a logical or physical port on the storage device used to receive connection requests from the Initiator and respond to I / O operations. In FC SAN (Fibre Channel), the Target is typically a Fibre Channel Port (WWPN). In iSCSI SAN, the Target is a combination of an iSCSI name (such as iqn.2000-01.com.example:storage.target1) and an IP address.

[0036] I_T_L mapping, also known as LUN Masking, defines a triplet access rule: only a specified server (Initiator) can access a specified storage space (LUN) through a specified storage port (Target). After configuring the I_T_L triplet, the host / cloud platform node can access the corresponding LUN. I_T_L mapping is configured step-by-step as follows: establish I_T mapping to allow a cloud platform node (Initiator) to connect to a specific storage port (Target); based on the I_T connection, specify which LUN(s) this cloud platform node can access.

[0037] Based on this, in cloud platform environments, storage systems typically use an I_T_L mapping mechanism to authorize specific hosts to access logical units (LUNs) on storage devices. Hosts identify LUNs as block devices through this mapping and, combined with multi-path software, aggregate access paths from different physical links to achieve high availability and automatic failover. To further improve business continuity and data reliability, active-active storage technology has emerged. This involves deploying a primary LUN and a mirror LUN in two independent data centers, respectively, ensuring real-time content synchronization and complete data consistency. This forms an active-active LUN pair, which can simultaneously provide read and write services.

[0038] When implementing I_T_L mapping in a dual-active LUN scenario, the cloud platform requires that the primary LUN and the mirror LUN in the same dual-active LUN pair must be assigned the same LUN ID. To meet this consistency requirement, existing technologies generally adopt a centralized LUN ID allocation mechanism on the master side to avoid LUN ID allocation conflicts. That is, one of the two storage devices is pre-designated as the master storage device, and the primary LUN of all dual-active LUNs is forced to be deployed on this master, and all dual-active LUN mapping requests are handled uniformly by this master.

[0039] See Figure 1 An exemplary flowchart of a dual-active LUN ID allocation process based on centralized computing at the master end is shown below: S101, the dual-active LUN mapping requests of the cloud platform nodes are uniformly sent to the preset primary storage device (such as device A); this dual-active LUN... UN Mapping requests are used to indicate the allocation of LUN IDs for a dual-active LUN pair; S102, the master queries the local list of free LUN IDs and initiates a query to the peer storage device (such as device B) to obtain its set of free LUN IDs; S103, the master calculates the intersection of the two and selects a LUN ID (such as the minimum value or round-robin method) as the allocation result; S104, the master end assigns LUN IDs to the primary LUN and mirror LUN in the dual-active LUN pair based on the selected LUN ID.

[0040] Under the LUN ID allocation method described above, if both ends are allowed to independently calculate and allocate LUN IDs, when two storage devices concurrently receive mapping requests for different active-active LUNs, they may assign the same free LUN ID to two different active-active LUN pairs. Since I_T_L mapping requires that LUN IDs be globally unique within the same I_T context composed of the same Initiator and Target, if both ends allocate the same LUN ID to different active-active LUN pairs, it will lead to LUN ID conflicts, causing I_T_L mapping configuration failures or abnormal device identification on the host side. To avoid such concurrent conflict risks, existing technologies employ a centralized processing mode on the master side.

[0041] However, in large-scale cloud environments, this method forces all primary LUNs to be centralized on a single primary device. Regardless of which storage device the host is physically close to, all host I / O requests must be processed through this primary device. This results in the primary storage device's CPU, memory cache, internal bus, and network bandwidth being under high load or even overload for extended periods. Consequently, the primary storage device becomes a performance bottleneck and a potential single point of failure, limiting the performance, flexibility, and scalability of the active-active storage system and making it difficult to meet the comprehensive requirements of modern data centers for high performance, high reliability, and adaptive scheduling.

[0042] In view of this, this application proposes a dual-active storage implementation method, which is applicable to high-availability storage systems that need to implement LUNID consistency management across storage devices. This method can achieve consistent LUNID allocation and concurrent access control across storage devices without the need for a pre-defined master node.

[0043] Unlike existing technologies where primary LUNs are centrally deployed on a designated primary storage device and handled by that primary storage device for dual-active LUN mapping requests, this embodiment presents two storage devices with equal status, both supporting the deployment of primary LUNs for dual-active LUN pairs. In other words, a cloud platform node can dynamically select one of the two storage devices associated with it as the deployment device for the primary LUN of a dual-active LUN pair based on actual needs. During the selection process, the cloud platform node can make decisions based on various strategies. For example, it can prioritize the storage device with fewer primary LUNs based on the primary LUN deployment status of each of the two storage devices, thus balancing the cross-device deployment of primary LUNs and effectively avoiding performance bottlenecks caused by requests concentrated on a single device. Alternatively, it can evaluate the current load of the two storage devices (such as CPU utilization, I / O latency, cache utilization, front-end port bandwidth usage, etc.) and prioritize the storage device with lower load. In addition, other factors can be considered for a comprehensive judgment, such as device health status, network connectivity quality, historical response time, resource availability (e.g., the number of available LUN IDs), or cloud platform policy configuration instructions, to make a flexible selection.

[0044] After receiving a dual-active LUN mapping request for a dual-active LUN pair, any storage device constructs a candidate LUN ID set and negotiates with another storage device based on the currently attempted pre-occupied LUN ID through the pre-occupancy mechanism provided in this embodiment. This allows the other storage device to determine whether to allow LUN mapping based on the pre-occupied LUN ID based on its local resource status. This ensures that the two LUNs deployed on different storage devices in the dual-active LUN pair are assigned the same LUN ID, and achieves cross-device balanced deployment of the primary LUN. This avoids the bottleneck problem of single point of access in related technologies and improves the overall I / O throughput and resource utilization of the system.

[0045] Based on this, see Figure 2AThis illustrative diagram illustrates the interaction between the main entities involved in a dual-active storage implementation method. The dual-active storage implementation method provided in this embodiment involves three interacting entities: a cloud platform node initiating a dual-active LUN mapping request, and two independent storage devices providing dual-active LUN storage capabilities to the cloud platform node. The two storage devices, as independent physical storage nodes, exchange data synchronization and control signaling through a dedicated internal communication link. For example, they can achieve state coordination and resource negotiation through a high-speed network connection, such as using XAN (eXchange Area Network) for interconnection. XAN is a high-performance private network architecture in the Hongshan Technology storage system dedicated to inter-device communication, supporting key functions such as cross-device data mirroring, metadata synchronization, heartbeat detection, and distributed lock coordination, ensuring the high availability and consistency of the dual-active system.

[0046] In this embodiment, both storage devices are capable of receiving and processing active-active LUN mapping requests, and jointly complete the resource allocation and state synchronization of active-active LUNs through the pre-occupancy coordination mechanism provided in this embodiment. That is, regardless of which storage device receives the active-active LUN mapping request, that storage device can actively initiate the construction of a candidate LUN ID set, pre-occupancy negotiation, and active-active LUN ID mapping operation, while the other storage device participates in verification and response as a collaborator.

[0047] In this embodiment, the primary LUN in any active-active LUN pair can be deployed on either of the two independent storage devices. The cloud platform node can send an active-active LUN mapping request to the storage device with the primary LUN deployed (i.e., the first storage device). The first storage device responds to the active-active LUN mapping request, while the other storage device storing the mirror LUN of the active-active LUN pair participates in the LUN ID collaborative operation as the second storage device. Through the pre-occupancy collaborative method provided in this embodiment, the two storage devices complete the cross-device LUN ID resource contention judgment and consistent allocation without relying on a global central controller. The first storage device generates a candidate LUN ID set based on unmapped and unpre-occupied LUN IDs in its local and peer (i.e., the second storage device) locations. It then selects a candidate LUN ID from this set to initiate a pre-occupancy request. The second storage device returns a decision based on its local state, allowing or prohibiting the first storage device from mapping based on the pre-occupied candidate LUN ID. Both devices advance the LUN ID allocation for the active-active LUN pair or rollback the process of traversing the candidate LUN ID set to select a candidate LUN ID to initiate a pre-occupancy request. This pre-occupancy mechanism facilitates cross-device LUN ID negotiation with the second storage device, resulting in a LUN ID that is confirmed as idle by both devices and available for active-active LUN ID allocation. Based on this LUN ID, the same LUN ID is allocated to the active-active LUN pair.

[0048] This approach achieves strong consistency and conflict-free guarantee in LUN ID allocation for two independent storage devices in a dual-active LUN pair. It also supports the deployment of primary LUNs on both independent storage devices, enabling the primary LUN in a dual-active LUN pair to be deployed across both storage devices in a distributed and balanced manner. This effectively supports the cloud platform's load balancing scheduling requirements for storage resources, avoids the performance bottleneck caused by the concentration of I / O traffic from compute nodes accessing the primary LUN on a single storage device, and improves the overall system throughput and response performance.

[0049] Based on this, see Figure 2BThe illustrative flowchart illustrates a method for implementing active-active storage. This method is applied to a first storage device where the primary LUN of the active-active LUN pair resides. The first storage device is either one of two independent physical storage devices. The active-active LUN consists of a primary LUN and a mirrored LUN. The mirrored LUN is deployed on the second storage device, which is the other of the two independent physical storage devices besides the first storage device. It is understood that the distinction between the first and second storage devices is merely for describing the role relationship during the interaction process and is not intended to limit the physical attributes or permanent roles of the storage devices, nor does it imply any long-term attribution of master / slave, priority, or control. The active-active storage implementation method provided in this embodiment may include at least the following steps: S201, Receive a dual-active LUN mapping request, and determine a candidate LUN ID set based on the dual-active LUN mapping request; wherein, the dual-active LUN mapping request is used to indicate that the same LUN ID is allocated to the dual-active LUN pair; the candidate LUN ID set includes candidate LUN IDs that meet the following conditions: they are within the range of LUN IDs supported by both the first storage device and the second storage device, and the LUN ID is in a state of not being mapped and not being pre-occupied on both the first storage device and the second storage device; A dual-active LUN mapping request is a control command initiated by a cloud platform node to the storage device where the primary LUN resides in a dual-active storage system. Its core purpose is to establish I_T mappings between the target Initiator and the Target on both storage devices, and to assign identical LUN IDs to the same dual-active LUN pair within these two I_T mappings. The target Initiator is the resource user of the dual-active LUN pair for which the LUN ID is to be assigned. In other words, the dual-active LUN mapping request is used to collaboratively select and assign a LUN ID that is not used in either I_T context on two independent storage devices for the same Initiator, preventing concurrent conflicts.

[0050] For a dual-active LUN pair with a LUN ID to be assigned, the cloud platform node sends a dual-active LUN mapping request to the first storage device where the primary LUN in the dual-active LUN pair resides, so as to trigger the first storage device to work with the second storage device to complete the consistent allocation of LUN ID and I_T_L mapping configuration.

[0051] The candidate LUN ID set includes one or more candidate LUN IDs. The candidate LUN ID is a LUN ID that is present on both the first storage device and the second storage device, and the LUN ID satisfies the following conditions on both the first storage device and the second storage device: the LUN ID has not been allocated or marked as pre-occupied in the I_T mapping context formed by the target initiator and the target on the first storage device, and in the I_T mapping context formed by the target initiator and the target on the second storage device.

[0052] After receiving the dual-active LUN mapping request from the cloud platform node, the first storage device initiates a resource preparation process. First, based on the idle LUN ID information of the local and peer devices, it constructs a set of candidate LUN IDs that can be used for this mapping. A LUN ID is considered an idle LUN ID and included in the candidate LUN ID set only if it simultaneously meets the following conditions: The LUN ID is within the valid range of LUN IDs supported by both the first and second storage devices; For the initiator specified in the dual-active LUN mapping request, the LUN ID has not yet been assigned to the initiator for use in the I_T mapping context of the first and second storage devices; the LUN ID is not marked as pre-occupied on either the first or second storage device.

[0053] Pre-occupancy can be understood as a lightweight resource locking mechanism used to temporarily lock a certain LUN ID before the I_T_L mapping is officially completed, preventing multiple concurrent mapping requests from the same Initiator from selecting the same LUN ID, thereby ensuring that the active-active LUN pair allocates completely consistent LUN IDs to the same Initiator at both ends, avoiding resource conflicts.

[0054] It is important to note that the LUN ID is not an inherent attribute of the LUN, but rather a logical identifier dynamically assigned during I_T_L mapping. The same LUN can be mapped to multiple different Initiators (i.e., shared across multiple hosts). To determine if a LUN ID is available, it is necessary to check whether the LUN ID has already been used within the I_T mapping scope formed by the Initiator and its corresponding Target associated with the active-active LUN mapping request. For example, if Initiator A is assigned LUN ID=100 in I_T mapping (A, Target_M1), Initiator B can also be assigned LUN ID=100 in I_T mapping (B, Target_M1). This means they belong to different I_T contexts, and assigning the same LUN ID does not affect each other. Furthermore, active-active LUN pairs are not bound to LUN IDs themselves; LUN IDs are only assigned when mapped to a specific Initiator. The same active-active LUN pair can be assigned different LUN IDs when mapped to different Initiators.

[0055] Based on this, when determining the candidate LUN ID set, the first storage device can first scan all its local LUN resources to filter out all LUNs that meet the idle condition and collect their corresponding LUN IDs. It can then obtain each LUN ID within the LUN ID range supported by the first storage device that is in an unmapped and unoccupied state, thus obtaining the first LUN ID set. Further, the first storage device can send a LUN ID query request to the second storage device through its connection channel with the second storage device to obtain the second LUN ID set composed of the LIN IDs corresponding to each LUN ID within the LUN ID range supported by the second storage device that is in an unmapped and unoccupied state. Based on the intersection of the first LUN ID set and the second LUN ID set, the candidate LUN ID set is obtained. The LUN IDs belonging to the intersection are those that exist on both the first and second storage devices and are in an unused and unoccupied state on both storage devices. Upon receiving the LUN ID query request, the second storage device performs a local idle LUN ID check and packages the LUN IDs that are unused and not pre-occupied back to the first storage device, forming a second LUN ID set. This candidate LUN ID set ensures that the selected IDs have the basic conditions for consistent deployment across devices, avoiding dual-active LUN ID mapping failures due to resource mismatches.

[0056] For example, suppose a dual-active storage system contains two storage devices M1 and M2. In the I_T mapping formed by any Initiator and any Target, the range of LUN IDs that can be allocated is 0 to 255 (multiple I_T_L mappings may exist in the system, and each mapping uses this number range independently). Assuming that in the I_T mapping context formed by the target Initiator and the Target on the first storage device, the LUN IDs currently in an unmapped and unpre-occupied state in M1 are {1,3,5,7,24,31,36,40,99,108,126,200}, and similarly, in the I_T mapping context formed by the target Initiator and the Target on the second storage device, the LUN IDs currently in an unmapped and unpre-occupied state in M2 are {3,5,6,8,31,39,45,99,126,200}, when the cloud platform node sends a dual-active LUN mapping request to M1, with M1 as the first storage device and M2 as the second storage device, the candidate LUN ID set is obtained through the following steps: M1 obtains the local idle LUN ID → resulting in Set_A={1,3,5,7,24,31,36,40,99,108,126,200}; M1 sends a LUN ID query request to M2, and receives the idle LUN ID returned by M2. → M1 receives Set_B={3,5,6,8,31,39,45,99,126,200} M1 calculates the intersection to obtain a candidate LUN ID set = Set_A∩Set_B= {3, 5, 31, 99, 126,200}, which is represented as {3, 5, 31, 99, 126, 200}. The allocation status of any candidate LUN ID in this candidate LUN ID set in the I_T context simultaneously satisfies the following conditions: it is not mapped and not pre-occupied in the I_T mapping context between the target Initiator and M1; it is not mapped and not pre-occupied in the I_T mapping context between the target Initiator and M2. The subsequent pre-occupancy operation initiated by the first storage device will select a LUN ID from this candidate LUN ID set.

[0057] To further prevent interference caused by concurrent execution of multiple active-active LUN mapping requests from the same cloud platform node, the first storage device acquires an operation mutex lock locally maintained by itself when it receives an active-active LUN mapping request. This operation mutex lock maintains the atomicity of processing a single active-active LUN mapping request within the first storage device. For example, if the cloud platform node continuously initiates active-active LUN mapping requests Req1 and Req2, it waits for Req1 to be fully processed (regardless of success or failure) and release the operation mutex lock before starting execution of Req2.

[0058] The operation mutex is not held permanently and is automatically released when any of the following conditions are met: The following conditions mark the end of the lifecycle of this active-active LUN mapping request, so the operation mutex can be safely released, allowing the next active-active LUN mapping request of the cloud platform node to enter the processing queue. The conditions may include at least: (1) The mapping operation based on the pre-occupied LUN ID is completed, that is, the current request has successfully negotiated a pre-occupied LUN ID and completed the I_T_L mapping configuration on the first and second storage devices based on the pre-occupied LUN ID; or, (2) All candidate LUN IDs in the candidate LUN ID set have been traversed and failed to complete the mapping allocation, that is, the first storage device has tried all available LUN IDs for pre-occupancy negotiation, but all of them are rejected by the second storage device (such as being mapped or pre-occupied), and the active-active LUN mapping request is determined to have failed.

[0059] This embodiment strictly binds the lifecycle of the operation mutex lock with the processing flow of the dual-active LUN mapping request, thereby achieving atomicity in the processing of the dual-active LUN mapping request. This ensures that each dual-active LUN mapping request completes the LUN ID allocation and mapping configuration completely and atomically in its I_T context, avoiding ID conflicts or mapping inconsistencies caused by concurrency.

[0060] S202, select a LUN ID from the unselected candidate LUN IDs in the candidate LUN ID set as the pre-occupied LUN ID, and send a pre-occupancy request for the pre-occupied LUN ID to the second storage device; A pre-occupied LUN ID refers to a candidate LUN ID that is temporarily locked during the cross-device resource negotiation phase before the official allocation of LUN IDs for a dual-active LUN pair. This pre-occupied LUN ID has been selected by the first storage device to initiate a pre-occupancy request to the second storage device to confirm whether the candidate LUN ID can be used for LUN ID allocation for the dual-active LUN pair. At this time, the LUN ID is marked as temporarily pre-occupied on the first storage device, indicating that it has been included in the processing flow of the current dual-active LUN mapping request. This prevents other concurrent mapping requests from reusing the same LUN ID for the same initiator, thereby avoiding I_T_L mapping conflicts and ensuring the consistency and atomicity of LUN ID allocation.

[0061] Furthermore, the candidate LUN IDs that have not been selected in the candidate LUN ID set represent LUN IDs that have not yet been used by the first storage device to initiate a pre-occupancy request in the dual-active LUN mapping request response process based on this candidate LUN ID set. Specifically, during the process of the first storage device retrying multiple times based on this candidate LUN ID set to complete the negotiation, if a candidate LUN ID has already been attempted to send a pre-occupancy request to the second storage device, then this candidate LUN ID is considered a "selected candidate LUN ID" and will not be retried subsequently, avoiding infinite loops or invalid communication. Therefore, when selecting a pre-occupancy LUN ID each time, the first storage device only selects candidate LUN IDs that have not yet been attempted to be pre-occupied from the candidate LUN ID set, ensuring that the entire negotiation process has a clear direction and termination, and improving system response efficiency and stability.

[0062] The pre-occupancy request is a control signaling sent by the first storage device to the second storage device. It is used to announce that the first storage device intends to use the pre-occupied LUN ID for dual-active LUN ID mapping configuration in the local I_T mapping context of the target Initiator associated with the dual-active LUN mapping request, and to request the second storage device to verify whether the LUN ID is also available in its local corresponding I_T mapping context. It is a key coordination message to achieve dual-end collaboration and ensure that consistent LUN IDs are allocated to the same Initiator.

[0063] In this implementation step, after determining the candidate LUN ID set, the first storage device enters the resource negotiation phase. Specifically, the first storage device selects one candidate LUN ID from those that have not yet been attempted as a pre-occupied LUN ID, and uses this selected candidate LUN ID as the pre-occupied LUN ID for this negotiation. It can also perform a status marking operation on the selected LUN ID locally to prevent repeated pre-occupancy requests for the same candidate LUN ID during the current pre-occupancy negotiation process. For example, the first storage device can perform either of the following processing on the selected candidate LUN ID: add a flag indicating the pre-occupancy status to the selected candidate LUN ID, such as setting the flag pre_occupied=true; or, it can add the selected candidate LUN ID to the pre-occupancy queue. Subsequently, the first storage device sends a pre-occupancy request for the pre-occupied LUN ID to the second storage device to initiate cross-device state consistency verification and resource contention arbitration. The first storage device can select a pre-occupied LUN ID from the candidate LUN ID set in a variety of ways, such as by traversing the candidate LUN IDs in ascending / descending order, or by selecting randomly.

[0064] When selecting a LUN ID as a pre-occupied LUN ID, the first storage device can also generate pre-occupied information for the pre-occupied LUN ID. This pre-occupied information includes complete context information describing the pre-occupied operation of the pre-occupied LUN ID, and may include at least, but is not limited to, the pre-occupied LUN ID, the first pre-occupied time of the pre-occupied LUN ID in the first storage device, the device serial number of the first storage device, and the pre-occupied type. The pre-occupied type is used to indicate whether the pre-occupied LUN ID belongs to the pre-occupied type of dual-active LUN. Wherein, the pre-occupied LUN ID represents the LUN ID currently requested for pre-occupancy, such as LUN ID=99; the first occupancy time represents the timestamp at which the first storage device sets the selected candidate LUN ID as the pre-occupied LUN ID, indicating the specific time information of the first storage device applying for the selected candidate LUN ID as the pre-occupied LUN ID for dual-active LUN ID mapping, used for time priority determination in the event of a conflict where the second storage device simultaneously applies for the selected candidate LUN ID for dual-active LUN ID mapping; the device serial number of the first storage device identifies the unique hardware number of the first storage device, such as SN=M1-2025XXXXXX, used to distinguish the identities of different storage devices; the pre-occupancy type is used to indicate the purpose of this pre-occupancy, such as dual-active LUN type or non-dual-active LUN type. In the pre-occupancy information of the pre-occupied LUN ID in the steps of this embodiment, the pre-occupancy type points to the dual-active LUN type.

[0065] The pre-occupancy information together constitutes a traceable, comparable, and arbitrable resource request certificate. Furthermore, the pre-occupancy request can carry the pre-occupancy information of the pre-occupancy LUN ID, so as to provide a decision basis for the second storage device to determine whether to allow the first storage device to perform mapping processing based on the pre-occupancy LUN ID; at the same time, it provides an update basis for the second storage device to maintain the status record of the pre-occupancy LUN ID in its local storage, thereby ensuring the consistency and synchronization of information about the pre-occupancy status between the first storage device and the second storage device.

[0066] For example, the pre-occupancy request can be encapsulated in a message body with the following structure and sent to the second storage device via a dedicated high-speed network such as the XAN network or other dedicated channels: { "pre_occupy_lun_id": 99, / / Pre-occupied LUN ID "first_pre_occupy_time": 2024-11-07 10:00:00 UTC, / / First occupancy time "first_device_sn": "M1-2025A1B2C3D4", / / Device serial number "pre_occupy_type": "DualActive_LUN_Map" / / Pre-occupy type - Dual-Active } The second storage device receives the pre-occupancy request and, based on whether the pre-occupancy LUN ID in the pre-occupancy request is in a pre-occupancy state locally in the second storage device, decides whether to allow the first storage device to perform mapping processing based on the pre-occupancy LUN ID, and returns the corresponding decision result to the first storage device.

[0067] Since the second storage device, as an independently operating physical node, may simultaneously serve multiple different cloud platform nodes and supports various types of I_T_L mapping operations, such as local LUN mapping and other dual-active LUN mappings, special attention must be paid to the status of that LUN ID in the current I_T mapping context formed by the target Initiator and the Target of the second storage device when the first storage device initiates a pre-occupancy request for a specific LUN ID. Specifically, if the LUN ID has already been assigned to other mapping requests (whether ordinary LUN mapping or other dual-active LUN mappings) on the second storage device, then the LUN ID will be considered unavailable in this I_T context, thus rejecting the pre-occupancy request.

[0068] For example, after the candidate LUN ID set is generated, if the same target Initiator initiates another ordinary LUN mapping request to the second storage device and successfully allocates LUN ID=99, or if another concurrent request of the Initiator has completed cross-device negotiation for the LUN ID during the processing of the current dual-active mapping request, then LUN ID=99 will be in a pre-occupied or mapped state in the I_T mapping context corresponding to the Initiator.

[0069] Therefore, to avoid resource conflicts and ensure data consistency and system reliability, the second storage device can maintain a complete LUN status view locally, recording the current usage status of each LUN ID (such as idle, pre-occupied, mapped and processed) and related context information (such as the cloud platform node to which it belongs, pre-occupancy time, device identity, etc.).

[0070] When a new pre-occupancy request is received, the second storage device can query the status view to determine whether the pre-occupancy LUN ID is in a pre-occupancy state locally on the second storage device. If it is not pre-occupied, the resource of the pre-occupied LUN ID is considered available, and the first storage device can be allowed to perform mapping processing based on the pre-occupied LUN ID. If it is already pre-occupied, there is resource contention for the pre-occupied LUN ID, and further priority comparison (such as arbitration rules based on timestamps, device identity, etc.) is required to decide whether to allow the first storage device to perform mapping processing based on the pre-occupied LUN ID. In other words, the second storage device does not unconditionally accept any pre-occupancy request, but makes autonomous, reliable, and auditable access control decisions based on the actual state of its local resources, ensuring the independence and security of its own resource management.

[0071] Subsequently, the second storage device can return a pre-occupancy response to the first storage device, carrying a decision on whether the first storage device is allowed to perform mapping processing based on the pre-occupancy LUN ID. For example, the decision returned by the second storage device can be encapsulated in a message body with the following structure: ALLOWED indicates that the second storage device confirms that the pre-occupancy LUN ID can be used for mapping processing; DENIED indicates that the second storage device prohibits the first storage device from performing mapping processing based on the pre-occupancy LUN ID. { "pre_occupy_lun_id": 99, / / Pre-occupied LUN ID "decision_result": "ALLOWED" / / or DENIED } Through the LUN ID allocation negotiation method based on pre-occupancy requests described above, two independent storage devices can achieve dual-active LUN ID allocation in an environment without a global lock controller, without relying on a third-party coordination node. This enables consistency coordination and conflict avoidance in the LUN ID allocation of dual-active LUN ID pairs, ensuring the reliability and efficiency of the I_T_L mapping process.

[0072] S203, receive the decision result returned by the second storage device for the pre-occupancy request. If the decision result indicates that the first storage device is allowed to perform mapping processing based on the pre-occupancy LUN ID, then allocate the pre-occupancy LUN ID to the primary LUN and the mirror LUN in the dual-active LUN pair. If the decision result indicates that the first storage device is prohibited from performing mapping processing based on the pre-occupancy LUN ID, then return to the step of selecting a LUN ID as the pre-occupancy LUN ID from the unselected candidate LUN IDs in the candidate LUN ID set.

[0073] The decision result has two possible values: ① Allow the first storage device to perform mapping processing based on the pre-occupied LUN ID; ② Prohibit the first storage device from performing mapping processing based on the pre-occupied LUN ID. The first storage device receives the decision result returned by the second storage device in response to the pre-occupied request, and executes different processing paths according to the decision result.

[0074] Based on this, when the second storage device returns a decision allowing the first storage device to perform mapping processing based on the pre-occupied LUN ID, it indicates that the pre-occupied LUN ID is available on both the first and second storage devices, satisfying the consistency requirement of active-active LUN mapping. At this time, the first storage device can perform the following operations: in the I_T mapping formed by the target Initiator associated with the active-active LUN mapping request and the first storage device Target locally on the first storage device, assign the pre-occupied LUN ID to the active-active LUN pair associated with the active-active LUN mapping request and establish an I_T_L mapping; and send a mapping confirmation instruction to the second storage device, notifying it to establish the corresponding I_T_L mapping using the same LUN ID in the I_T mapping formed by the same target Initiator and the second storage device Target; after both I_T_L mappings are successfully configured, return a mapping success response to the cloud platform node and release the operation mutex lock, allowing subsequent active-active LUN mapping requests to enter the processing queue.

[0075] When the second storage device returns a decision prohibiting the first storage device from performing mapping processing based on the pre-occupied LUN ID, it indicates that the pre-occupied LUN ID has been occupied on the second storage device and cannot be used for the mapping operation of this dual-active LUN mapping request. At this time, the first storage device should release the pre-occupied state of the pre-occupied LUN ID on the first storage device and return to the step S203 of selecting a LUN ID as the pre-occupied LUN ID from the candidate LUN ID set that has not been selected, and sending a pre-occupied request for the pre-occupied LUN ID to the second storage device, until the decision result returned by the second storage device indicates that the first storage device is allowed to perform mapping processing based on the pre-occupied LUN ID (i.e., until the first storage device completes the LUN ID allocation operation for the dual-active LUN pair based on the pre-occupied LUN ID), or until the candidate LUN ID set has been completely traversed.

[0076] To prevent the accidental release of pre-occupied records not held by the current transaction, the first storage device must perform identity verification before releasing the pre-occupied state of the pre-occupied LUN ID. Specifically, the operation of releasing the pre-occupied LUN ID includes the following steps: detecting whether the device serial number in the pre-occupied information corresponding to the pre-occupied LUN ID matches the device serial number of the first storage device; if they match, the first storage device releases the pre-occupied LUN ID; otherwise, the pre-occupied state of the pre-occupied LUN ID remains unchanged.

[0077] Assuming the primary LUN of a dual-active LUN pair is deployed on storage device M1 and the mirrored LUN is deployed on storage device M2, a cloud platform node initiates a dual-active LUN mapping request to M1. Storage device M1 is the first storage device, and storage device M2 is the second storage device. The first storage device has already acquired a set of candidate LUN IDs {3, 5, 31, 99, 126, 200}. Then: (1) M1 uses LUN ID=3 as the pre-occupied LUN ID and generates pre-occupied information: { "pre_occupy_lun_id": 3, "first_pre_occupy_time":2024-11-07 9:58:32 UTC, "first_device_sn": "M1-2025A1B2C3D4", "pre_occupy_type": "DualActive_LUN_Map" } M1 sends a pre-occupancy request to M2; If the M2 query finds that LUN ID=3 has been pre-occupied or mapped by another local non-active LUN mapping request of the target Initiator associated with the dual-active LUN mapping request on the M2 device, then the decision result of prohibiting the first storage device from performing mapping processing based on the pre-occupied LUN ID is returned. M1 receives the decision result returned by M2, releases the pre-occupancy of LUN ID=3, and enters the next round of pre-occupancy LUNID selection.

[0078] (2) M1 selects a candidate LUN ID from the candidate LUN ID set that has not been selected before as the pre-occupied LUN ID, such as selecting LUN ID=5 as the pre-occupied LUN ID; After a similar processing flow, M1 receives the decision from M2 prohibiting the first storage device from performing mapping processing based on the pre-occupied LUNID. Then, it releases the pre-occupancy of LUN ID=5 again and enters the next round of pre-occupied LUNID selection.

[0079] (3) M1 selects a candidate LUN ID that has not been selected before from the candidate LUN ID set as the pre-occupied LUN ID, such as selecting LUN ID=31 as the pre-occupied LUN ID; After a similar processing flow as described above, M1 receives a decision result from M2 that allows the first storage device to perform mapping processing based on the pre-occupied LUNID; Subsequently, M1 establishes an I_T_L mapping based on LUN ID = 31 in the I_T mapping formed by the target Initiator and M1's Target locally; at the same time, M1 notifies M2 to establish a corresponding I_T_L mapping using the same LUN ID = 31 in the I_T mapping formed by the target Initiator and M2's Target locally.

[0080] Compared to existing technologies that only allow the master device to handle dual-active LUN mapping requests and force the centralized deployment of the master LUN on the master storage device, this embodiment allows the deployment of the master LUN in a dual-active LUN pair on either of the two storage devices without forcibly binding it to a single device as the master. This breaks the traditional centralized model where a single master device dominates LUN ID calculation and the master LUN is centrally distributed on a single master device. By constructing a cross-device resource negotiation mechanism based on a set of candidate LUN IDs, in a loosely coupled environment without global distributed lock support, the two storage devices can independently but collaboratively allocate consistent LUN IDs to dual-active LUN pairs with the same target Initiator, ensuring that they obtain the same LUN ID in the I_T mapping context at both ends, and realizing the distributed deployment of the master LUN and data flow load balancing between the two storage devices.

[0081] In this embodiment, any storage device can be used to deploy the primary LUN and can receive and process dual-active LUN mapping requests sent by cloud platform nodes, improving system flexibility and disaster recovery capabilities. Furthermore, since the determination of the LUNID relies on a negotiation process jointly participated in by both ends rather than unilateral computation, by constructing a cross-device resource negotiation mechanism based on a candidate LUN ID set, even when multiple LUN mapping requests from the same Initiator arrive concurrently on different storage devices, a pre-occupancy mechanism can prevent duplicate LUN ID allocation. This achieves the allocation of completely consistent LUN IDs for the same dual-active LUN pair in the I_T mapping context of the two storage devices, thus avoiding dual-end conflicts. Additionally, in this embodiment, the primary LUN can be dynamically distributed across the first and second storage devices, no longer limited to deployment on a single designated primary node. This effectively distributes the cloud platform's read / write I / O traffic across the two physical storage devices, achieving balanced distribution of primary and secondary LUNs across devices and load balancing at the data path level. This alleviates the performance bottleneck and resource overload problems caused by all I / O being forced through a single primary device in traditional centralized architectures.

[0082] In some embodiments, to improve the security and fairness of resource allocation in high-concurrency scenarios of dual-active storage systems, this embodiment proposes a hierarchical and multi-dimensional refined decision-making mechanism for the judgment process of the second storage device in the aforementioned embodiments regarding whether the first storage device is allowed to perform mapping processing based on the pre-occupied LUN ID. This mechanism not only considers whether the resource is pre-occupied, but also combines factors such as pre-occupancy type and operation context information to achieve accurate identification and reasonable arbitration of resource contention situations. This avoids dual-active LUN ID mapping failure due to simple rejection, thereby improving the mapping success rate of dual-active LUN types and the overall availability of the system.

[0083] See Figure 3AAn exemplary flowchart illustrates a decision process by which a second storage device decides whether to allow a first storage device to perform mapping processing based on the pre-occupied LUN ID, including: S310, detect whether the pre-occupancy LUN ID in the pre-occupancy request is in a pre-occupancy state locally on the second storage device; The pre-occupied LUN ID in the pre-occupancy request is only used to declare to the second storage device that the LUN ID has been pre-occupied locally on the first storage device. The purpose of the first storage device sending this pre-occupancy request is to enable the second storage device to detect the current usage status of the same LUN ID existing locally. That is, after receiving the pre-occupancy request, the second storage device needs to check whether the pre-occupied LUN ID is in any of the following states in the I_T mapping context formed by the same target Initiator and its local Target on the second storage device: it has been assigned to the Initiator (i.e., an I_T_L mapping already exists); or it has been pre-occupied by other concurrent mapping requests of the Initiator. The usage status of the LUN ID can include idle, pre-occupied, or mapped and used, and for pre-occupied / mapped and used, contextual information can be attached to describe the detailed event information of the operation of the pre-occupancy or mapped and used.

[0084] Based on this, whether the pre-occupied LUN ID is in a pre-occupied state in the local storage device can be understood as: detecting whether the LUN ID with the same pre-occupied LUN ID in the local storage device has been used as the object of other pre-occupied operations, that is, whether the LUN ID has been set to a pre-occupied state, for example by setting a status flag, registering it to the pre-occupied context table, or adding it to the pre-occupied queue.

[0085] The second storage device can maintain a LUN ID usage status table indexed by Initiator identifier, recording the current status (e.g., idle, pre-occupied, mapped) of each LUN ID in its I_T context for each Initiator. When a pre-occupancy request is received, the second storage device extracts the target Initiator identifier and the pre-occupied LUN ID from the table, queries the status record corresponding to that Initiator, and determines whether the LUN ID can be used for this mapping. Assuming M2 is the second storage device, its locally maintained LUN ID usage status table under the I_T mapping context of the target Initiator is as follows: At this point, M1 sends a pre-occupy request with pre_occupy_lun_id = 99. M2 performs S310 detection: it searches for the record with local LUN ID=99 and finds that its status is "Pre-occupied", which means it is in a pre-occupied state. Then it proceeds to S330 for further judgment.

[0086] S320, if no, that is, the pre-occupied LUN ID is not in a pre-occupied state locally in the second storage device, then return a decision result to the first storage device indicating that the first storage device is allowed to perform mapping processing based on the pre-occupied LUN ID; Taking the aforementioned status table maintained locally by M2 as an example, if the pre-occupancy request of M1 is for LUN ID=31, then M2 performs the S310 check: search for LUN ID=31 locally in M2; if its status is "Free" or there is no record, it is considered that the LUN ID is not in a pre-occupancy state locally on the second storage device, and then enters the processing flow of step S320, that is, returns a decision result to the first storage device indicating that the first storage device is allowed to perform mapping processing based on the pre-occupancy LUN ID, so that M1 allocates LUN IDs for the primary LUN and mirror LUN in the dual-active LUN pair based on the pre-occupancy LUN ID=31.

[0087] Furthermore, when determining whether a pre-occupied LUN ID is available, the second storage device needs to consider the status of that LUN ID in the I_T mapping context corresponding to the target Initiator associated with the current active-active LUN mapping request. Therefore, upon receiving a pre-occupancy request, the second storage device performs the following judgment: if the LUN ID is in an idle state in the I_T mapping context formed by the current target Initiator and its local Target (i.e., no I_T_L mapping has been established, and it has not been pre-occupied by other concurrent requests of the Initiator), then it returns an allow decision to the first storage device. Through this embodiment, without the support of a global lock mechanism, the risk of LUN ID conflict under the same Initiator can be accurately identified, avoiding the problem of repeated I_T_L allocation caused by concurrent mapping, thus improving the security and reliability of the active-active LUN ID mapping process.

[0088] S330, if yes, meaning the pre-occupied LUN ID is in a pre-occupied state locally in the second storage device, then further obtain the pre-occupied type of the pre-occupied LUN ID in the second storage device to detect whether the pre-occupied type indicates a pre-occupied state belonging to a dual-active LUN type: S340, if no, that is, the pre-occupancy type indicates that the pre-occupancy belongs to the non-dual-active LUN type, then return a decision result to the first storage device indicating that the first storage device is prohibited from performing mapping processing based on the pre-occupancy LUN ID.

[0089] S350, if so, that is, the pre-occupancy type indicates that the pre-occupancy belongs to the dual-active LUN type, then further decide whether to allow the first storage device to perform mapping processing based on the pre-occupancy LUN ID according to the pre-occupancy operation context information in the first storage device.

[0090] Different types of pre-occupancy have different priorities or mutual exclusion rules. For example, in this embodiment, local LUN mapping should be prohibited from being preempted by dual-active LUN mapping requests, and vice versa. Therefore, if a LUN ID with the same pre-occupancy LUNID is in a pre-occupancy state in the second storage device, it can be determined whether the current pre-occupancy is reserved specifically for dual-active scenarios by string comparison or enumeration value comparison.

[0091] Taking the aforementioned locally maintained status table of M2 as an example, the pre-occupancy type field corresponding to the LUN ID with the same pre-occupancy LUN ID is read from the local status table of the second storage device, and its value is determined to be equal to "dual-active LUN type" or an equivalent identifier. If not, it indicates that the LUN ID with the same pre-occupancy LUN ID in the second storage device has been used for non-dual-active purposes and should be considered non-preemptible to ensure the continuity of existing services. A decision result is returned prohibiting the first storage device from performing mapping processing based on the pre-occupancy LUN ID. Furthermore, a field explaining the reason for rejection can be included in the decision result of prohibition.

[0092] If so, it indicates that other pre-occupancy operations of the same LUN ID as the pre-occupancy LUN ID in the second storage device are also for dual-active LUN ID mapping services, and a more refined conflict arbitration process is required. That is, based on the pre-occupancy operation context information of the pre-occupancy LUN ID in the first storage device, a decision is made on whether the first storage device is allowed to perform mapping processing based on the pre-occupancy LUN ID.

[0093] In this embodiment, by introducing comprehensive judgment logic on the second storage device side regarding pre-occupancy status, pre-occupancy type, and operation context information, cross-device resource contention identification and reasonable arbitration are achieved, ensuring that the same active-active LUN is assigned the same LUN ID on both independent storage devices. Furthermore, this decision-making method can prevent LUN ID conflicts caused by concurrent requests and distinguish the resource occupation behavior of active-active LUN mappings from other local storage tasks, avoiding misuse or overwriting of critical business resources, and significantly improving system data security and operational reliability.

[0094] Regarding the pre-occupancy operation context information of the pre-occupancy LUN ID in the first storage device as described in the foregoing embodiments, it may at least include the pre-occupancy time during which the pre-occupancy operation occurred, and the device serial number that initiated the pre-occupancy operation of the pre-occupancy LUN ID. Based on this, see... Figure 3B An exemplary flowchart illustrates the steps of a second storage device decision-making process based on the pre-occupancy LUN ID in the pre-occupancy operation context information of the first storage device, in the case where the pre-occupancy type indicates a pre-occupancy belonging to the dual-active LUN type: S360, obtain the first pre-occupancy time of the pre-occupancy LUN ID in the first storage device from the pre-occupancy request, and query the second pre-occupancy time of the LUN ID with the same pre-occupancy LUN ID in the second storage device; The first pre-occupancy time represents the timestamp at which the first storage device initiates the pre-occupancy operation for the pre-occupancy LUN ID locally. It is typically a millisecond-level time value under UTC or the system's unified clock, marking the start time of this pre-occupancy request. For example, if the first storage device selects candidate LUN ID=99 as the pre-occupancy LUN ID at 10:01:33 on 2024-11-07, then the first pre-occupancy time of this pre-occupancy LUN ID in the first storage device is 10:01:33 on 2024-11-07.

[0095] The second pre-occupancy time represents the timestamp on the second storage device at which the pre-occupancy LUN ID is set to the pre-occupancy state for the target Initiator associated with the current active-active LUN mapping request. This timestamp reflects the specific moment when the LUN ID enters the temporary pre-occupancy state in the I_T mapping context of the current Initiator. For example, if the second storage device, as the first storage device in a certain active-active LUN mapping process, actively sets the LUNID to the pre-occupancy state for the target Initiator, then the second pre-occupancy time is the timestamp on the second storage device locally for performing the pre-occupancy operation for the Initiator.

[0096] The second storage device locally maintains the current usage status and related operation context information of each LUN ID. Therefore, it is possible to directly query the second pre-occupancy time of the LUN ID that is the same as the pre-occupied LUN ID corresponding to the current target Initiator from the second storage device.

[0097] S370, compare the first pre-occupancy time with the second pre-occupancy time, and detect whether the first pre-occupancy time is earlier than the second pre-occupancy time: S371, if the first pre-occupancy time is earlier than the second pre-occupancy time, then return a decision result to the first storage device indicating that the first storage device is allowed to perform mapping processing based on the pre-occupancy LUN ID; S372, if the first pre-occupancy time is later than the second pre-occupancy time, then return a decision result to the first storage device indicating that the first storage device is prohibited from performing mapping processing based on the pre-occupancy LUN ID.

[0098] This embodiment follows the principle of prioritizing pre-occupancy time, allowing active-active LUN mapping requests with earlier pre-occupancy operations to gain priority in using LUN ID resources. By comparing the pre-occupancy times recorded locally on both ends, fair arbitration is achieved in a decentralized environment. Even if two storage devices initiate pre-occupancy requests for the same LUN ID almost simultaneously, the order can be determined based on the actual timestamp information, avoiding misjudgments of "last-come-first-served" due to network transmission delays or reversed message arrival order.

[0099] For example, M1 might select a LUN ID as its pre-occupancy LUN ID and send a pre-occupancy request earlier locally, but due to network latency, its pre-occupancy request might be received by M2 later. Meanwhile, M2's own pre-occupancy request on the same LUN ID might be slightly later. If only the message arrival order is considered, M2 might mistakenly believe its pre-occupancy request was earlier, thus rejecting M1's legitimate application. Through the timestamp comparison mechanism in this embodiment, M2 can identify that M1's actual pre-occupancy time was earlier and should still allow it to use the LUN ID, ensuring the fairness and consistency of resource scheduling and avoiding resource preemption chaos caused by network jitter or processing delays.

[0100] Furthermore, considering that even in a high-precision clock synchronization environment, there is still a very low probability event: the timestamps of the first and second storage devices initiating pre-occupancy requests for the same LUN ID are exactly the same, i.e., the first pre-occupancy time and the second pre-occupancy time are equal. In this case, relying solely on the order of time is insufficient to determine resource priority. Arbitrarily rejecting either request may lead to uncertain system behavior or unfair resource allocation. To resolve this arbitration deadlock in this boundary scenario, this embodiment introduces a decision rule based on the unique identifier of the device to ensure that a deterministic and repeatable decision result can still be generated when time information cannot distinguish between superior and inferior requests.

[0101] Therefore, when the first pre-occupancy time and the second pre-occupancy time are the same, it is also possible to: S373, obtain the first complete machine serial number of the first storage device from the pre-occupancy request, and obtain the second complete machine serial number of the pre-occupancy initiating device of the second storage device with the same LUN ID as the pre-occupancy LUN ID; The first complete machine serial number represents the globally unique hardware identifier of the first storage device. It is usually burned into the motherboard or controller by the manufacturer and is in the format of alphanumeric combination (such as M1A2B3C4D5E6). It is unique and immutable in the entire storage network and represents the actual device identity of the pre-occupancy operation of the pre-occupancy LUN ID in the first storage device.

[0102] The second whole machine serial number represents the whole machine serial number of the device that has performed a pre-occupancy operation on the same LUN ID as the pre-occupancy LUNID in the local record of the second storage device. This information is recorded, maintained and saved along with the pre-occupancy status to identify which storage device it is. For example, if the second storage device itself marks the LUN ID as pre-occupancy, then the second whole machine serial number is the whole machine serial number of the second storage device.

[0103] S374, if the first system serial number is less than the second system serial number, then return a decision result to the first storage device indicating that the first storage device is allowed to perform mapping processing based on the pre-occupied LUN ID; otherwise... S375, return a decision result to the first storage device indicating that the first storage device is prohibited from performing mapping processing based on the pre-occupied LUN ID.

[0104] For example, if the first complete machine serial number of the first storage device is 2025A1B2C3D4, and the second complete machine serial number of the device initiating the pre-occupancy request for the same LUN ID in the local storage device is 2025X7Y8Z9W0, then the two complete machine serial numbers can be compared lexicographically, and the device with the larger complete machine serial number is given priority to obtain the pre-occupancy permission for the LUN ID in the second storage device that is the same as the pre-occupancy LUN ID in the pre-occupancy request sent by the first storage device. For example, M1-2025A1B2C3D4 is smaller than M3-2025X7Y8Z9W0, so the second storage device allows the first storage device to perform mapping processing based on LUN ID=99, while simultaneously returning a decision result indicating that mapping processing based on LUN ID=99 is prohibited to another pre-occupancy request competing for LUN ID=99.

[0105] In this embodiment, when the pre-occupancy time is exactly the same, traditional methods may randomly reject requests or cause deadlocks. However, this embodiment introduces a comparison rule for the whole machine serial number to ensure that the comparison result between any two devices is unique and repeatable, completely eliminating decision uncertainty and ensuring predictable system behavior. Even in high-load environments such as high-frequency dual-active LUN ID mapping and large-scale deployment, where multiple dual-active tasks start almost simultaneously, resource allocation can still be completed smoothly. This avoids dual-active LUN ID mapping failure due to rare time collisions, improving the success rate of dual-active LUN ID mapping processing and system availability.

[0106] In the above embodiment, after the second storage device returns a decision result indicating that the first storage device is allowed to perform mapping processing based on the pre-occupied LUN ID to the first storage device, the method further includes: maintaining local occupancy information of the pre-occupied LUN ID in the second storage device based on the pre-occupancy information in the pre-occupancy request. Specifically, when the pre-occupied LUN ID is not in a pre-occupied state in the second storage device, local occupancy information is created for the pre-occupied LUN ID in the second storage device, and the content of the local occupancy information is consistent with the pre-occupancy information in the pre-occupancy request; when the pre-occupied LUN ID is in a pre-occupied state in the second storage device, the local occupancy information for the pre-occupied LUN ID in the second storage device is updated to the pre-occupancy information in the pre-occupancy request, so as to ensure that the context state of the dual-active LUN is consistent between the two storage devices, and to provide a unified and reliable state basis for subsequent dual-active LUN ID mapping, configuration synchronization, and failover operations. This embodiment achieves consistency of state collaboration and continuity of resource management across devices by immediately synchronizing and maintaining the local occupancy information of the second storage device after the second storage device makes a decision to allow it.

[0107] To enable those skilled in the art to better understand the implementation method of negotiating between the first and second storage devices based on a pre-occupancy mechanism to obtain a LUN ID that can be used for dual-active LUN mapping processing as described in this embodiment, the following example is provided for explanation: Assuming the candidate LUNID set, consisting of LUN IDs that exist on both storage devices M1 and M2 and are currently idle, is {1, 2, 3, 4, 5, 9}, the first storage device repeatedly executes the following steps until storage device M2 returns a decision indicating that the first storage device M1 is allowed to perform mapping processing based on the pre-occupied LUN IDs, or the candidate LUN ID set is exhausted: (1) Select the current LUN ID from the candidate set.

[0108] (2) Pre-occupy the current LUN ID in the first storage device.

[0109] (3) Initiate a pre-occupancy request to the second storage device for the current LUN ID; (4) If the storage device returns a decision result indicating that the first storage device is allowed to perform mapping processing based on the current LUN ID, then the mapping processing is performed based on the current LUN ID; if the storage device returns a decision result indicating that the first storage device is prohibited from performing mapping processing based on the current LUN ID, then the locally pre-occupied LUN ID is released, and the current LUN ID is selected from the candidate set.

[0110] For example, select a current LUN ID, such as LUN ID=3; use this current LUN ID as the pre-occupied LUN ID, and generate pre-occupied information for LUN ID 3, including a timestamp (e.g., 2025-04-05 10:00:00), the device serial number (e.g., SN-A123), and the pre-occupied type pointing to the dual-active LUN type; send a pre-occupied request to the second storage device to announce that the LUN ID to be pre-occupied by the first storage device is 3, and the pre-occupied request carries the pre-occupied information for LUN ID 3.

[0111] The second storage device handles pre-occupancy requests: (1) If LUN ID 3 in the second storage device is not mapped and not pre-occupied in the I_T mapping context between the target Initiator and the second storage device, then return the allowed decision result (i.e., the decision result that allows the first storage device to perform mapping processing based on the current LUN ID). (2) If LUN ID 3 has already been pre-occupied: ① If the pre-occupancy of LUN ID 3 in the second storage device is a non-dual-active LUN type, then a decision result of prohibition is returned (that is, the decision result of prohibiting the first storage device from performing mapping processing based on the current LUN ID). ② If the pre-occupancy of LUN ID 3 in the second storage device is a dual-active LUN type, the pre-occupancy timestamp is compared first. If the pre-occupancy time on the first storage device is earlier, the decision result of allowing is returned to the first storage device; otherwise, the decision result of prohibition is returned. Furthermore, if the pre-occupancy timestamps are consistent, the device serial numbers are compared. If the serial number on the first storage device is smaller, an allowed decision is returned to the first storage device; otherwise, a prohibited decision is returned.

[0112] Corresponding to the aforementioned embodiments of the dual-active storage implementation method, see [link to relevant documentation]. Figure 4As shown, this application also provides an embodiment of a dual-active storage implementation device, applied to a first storage device where the primary LUN of the dual-active LUN pair is located; the first storage device is either one of two independent physical storage devices; the dual-active LUN consists of a primary LUN and a mirrored LUN; the mirrored LUN is deployed on a second storage device other than the first storage device among the two independent physical storage devices; the device includes: The candidate LUN ID acquisition module 401 is configured to receive a dual-active LUN mapping request and determine a candidate LUN ID set based on the dual-active LUN mapping request; wherein, the dual-active LUN mapping request is used to indicate that the same LUN ID is allocated to the dual-active LUN pair; the candidate LUN ID set includes candidate LUN IDs that meet the following conditions: they are within the range of LUN IDs supported by both the first storage device and the second storage device, and the LUN ID is in a state of not being mapped and not being pre-occupied on both the first storage device and the second storage device; The pre-occupancy negotiation module 402 is configured to select a LUN ID as a pre-occupancy LUN ID from the unselected candidate LUN IDs in the candidate LUN ID set, and send a pre-occupancy request for the pre-occupancy LUN ID to the second storage device. The dual-active LUN ID mapping module 403 is configured to receive the decision result returned by the second storage device in response to the pre-occupancy request. If the decision result indicates that the first storage device is allowed to perform mapping processing based on the pre-occupancy LUN ID, then the pre-occupancy LUN ID is allocated to the primary LUN and the mirror LUN in the dual-active LUN pair. If the decision result indicates that the first storage device is prohibited from performing mapping processing based on the pre-occupancy LUN ID, then the step of selecting a LUN ID as the pre-occupancy LUN ID from the unselected candidate LUN IDs in the candidate LUN ID set is returned.

[0113] In some embodiments, the second storage device returns the decision result in the following manner: the second storage device receives the pre-occupancy request, and based on whether the pre-occupancy LUN ID in the pre-occupancy request is in a pre-occupancy state locally in the second storage device, decides whether to allow the first storage device to perform mapping processing based on the pre-occupancy LUN ID, and returns the corresponding decision result to the first storage device.

[0114] In some embodiments, when the second storage device decides whether to allow the first storage device to perform mapping processing based on the pre-occupied LUN ID, it includes: If the pre-occupied LUN ID is not in a pre-occupied state locally on the second storage device, a decision result indicating that the first storage device is allowed to perform mapping processing based on the pre-occupied LUN ID is returned to the first storage device; otherwise... Further determine the pre-occupancy type of the pre-occupancy LUN ID in the second storage device; If the pre-occupancy type indicates that the pre-occupancy is of a non-dual-active LUN type, then a decision result indicating that the first storage device is prohibited from performing mapping processing based on the pre-occupancy LUN ID is returned to the first storage device.

[0115] In some embodiments, when deciding whether to allow the first storage device to perform mapping processing based on the pre-occupied LUN ID, the second storage device further includes: If the pre-occupancy type indicates that it belongs to the pre-occupancy of a dual-active LUN type, then obtain the first pre-occupancy time of the pre-occupancy LUN ID in the first storage device from the pre-occupancy request, and query the second pre-occupancy time of the LUN ID with the same pre-occupancy LUN ID in the second storage device. If the first pre-occupancy time is earlier than the second pre-occupancy time, a decision result indicating that the first storage device is allowed to perform mapping processing based on the pre-occupancy LUN ID is returned to the first storage device; If the first pre-occupancy time is later than the second pre-occupancy time, a decision result indicating that the first storage device should not perform mapping processing based on the pre-occupancy LUN ID is returned to the first storage device.

[0116] In some embodiments, when deciding whether to allow the first storage device to perform mapping processing based on the pre-occupied LUN ID, the second storage device further includes: When the first pre-occupancy time and the second pre-occupancy time are the same, the first complete serial number of the first storage device is obtained from the pre-occupancy request, and the second complete serial number of the pre-occupancy initiating device with the same LUN ID as the pre-occupancy LUN ID in the second storage device is obtained; If the first system serial number is less than the second system serial number, then a decision result indicating that the first storage device is allowed to perform mapping processing based on the pre-occupied LUN ID is returned to the first storage device; otherwise... Return a decision result to the first storage device that indicates that the first storage device should not perform mapping processing based on the pre-occupied LUN ID.

[0117] In some embodiments, the pre-occupancy request carries pre-occupancy information; the pre-occupancy information includes at least: a pre-occupancy LUN ID, a first pre-occupancy time of the pre-occupancy LUN ID in the first storage device, a first system serial number of the first storage device, and a pre-occupancy type; the pre-occupancy type is used to indicate whether the pre-occupancy LUN ID belongs to a dual-active LUN type pre-occupancy. After the second storage device returns a decision result to the first storage device indicating that the first storage device is allowed to perform mapping processing based on the pre-occupied LUN ID, the device further includes: maintaining local occupancy information of the pre-occupied LUN ID in the second storage device based on the pre-occupancy information in the pre-occupancy request.

[0118] In some embodiments, the device further includes: The mutex lock acquisition and release module is configured such that when the first storage device receives the dual-active LUN mapping request, it acquires an operation mutex lock maintained by the first storage device; the operation mutex lock is used to maintain the atomicity of processing the dual-active LUN mapping request; and the operation mutex lock is released when any of the following conditions are met; wherein the conditions include: the mapping operation based on the pre-occupied LUN ID is completed; or, all candidate LUN IDs in the candidate LUN ID set have been traversed.

[0119] In some embodiments, when the pre-occupancy negotiation module is configured to determine a set of candidate LUN IDs based on the dual-active LUN mapping request, it includes: Obtain all LUN IDs within the LUN ID range supported by the first storage device that are in a state of being neither mapped nor pre-occupied, to obtain a first LUN ID set; send a LUN ID query request to the second storage device to obtain a second LUN ID set corresponding to each LUN ID within the LUN ID range supported by the second storage device that is in a state of being neither mapped nor pre-occupied; obtain the candidate LUNID set based on the intersection of the first LUN ID set and the second LUN ID set.

[0120] The specific implementation process of the functions and roles of each unit in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0121] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this application according to actual needs. Those skilled in the art can understand and implement this without any inventive effort.

[0122] This application also provides an electronic device, the structural schematic diagram of which is shown below. Figure 5 As shown, the electronic device 500 includes at least one processor 501, a memory 502, and a bus 503. At least one processor 501 is electrically connected to the memory 502. The memory 502 is configured to store at least one computer-executable instruction, and the processor 501 is configured to execute the at least one computer-executable instruction, thereby performing the steps of any dual-active memory implementation method provided in any embodiment or optional implementation of this application.

[0123] Furthermore, the processor 501 can be an FPGA (Field-Programmable Gate Array) or other devices with logic processing capabilities, such as an MCU (Microcontroller Unit) or a CPU (Central Processing Unit).

[0124] This application also provides another readable storage medium storing a computer program that, when executed by a processor, implements the steps of any dual-active storage implementation method provided in any embodiment or optional implementation of this application.

[0125] The readable storage media provided in this application include, but are not limited to, any type of disk (including floppy disk, hard disk, optical disk, CD-ROM, and magneto-optical disk), ROM (Read-Only Memory), RAM (Random Access Memory), EPROM (Erasable Programmable Read-Only Memory), EEPROM (Electrically Erasable Programmable Read-Only Memory), flash memory, magnetic cards, or optical cards. In other words, readable storage media include any medium by which a device (e.g., a computer) stores or transmits information in a readable form.

[0126] Thus, specific embodiments of the subject matter have been described. Other embodiments are within the scope of the appended claims. In some cases, the actions recited in the claims may be performed in a different order and still achieve the desired result. Furthermore, the processes depicted in the drawings are not necessarily shown in a specific order or sequence to achieve the desired result. In some implementations, multitasking and parallel processing may be advantageous.

[0127] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for implementing dual-active storage, characterized in that, The method is applied to the first storage device where the primary LUN of a dual-active LUN pair resides; the first storage device is either one of two independent physical storage devices; the dual-active LUN consists of a primary LUN and a mirrored LUN; the mirrored LUN is deployed on the second storage device other than the first storage device among the two independent physical storage devices; the method includes: A dual-active LUN mapping request is received, and a candidate LUN ID set is determined based on the dual-active LUN mapping request; wherein, the dual-active LUN mapping request is used to indicate that the same LUN ID is allocated to the dual-active LUN pair; the candidate LUN ID set includes candidate LUN IDs that meet the following conditions: they are within the range of LUN IDs supported by both the first storage device and the second storage device, and the LUN ID is in a state of not being mapped and not being pre-occupied on both the first storage device and the second storage device; Select a LUN ID from the unselected candidate LUN IDs in the candidate LUN ID set as the pre-occupied LUN ID, and send a pre-occupancy request for the pre-occupied LUN ID to the second storage device; The system receives the decision result returned by the second storage device in response to the pre-occupancy request. If the decision result indicates that the first storage device is allowed to perform mapping processing based on the pre-occupancy LUN ID, then the system allocates the pre-occupancy LUN ID to the primary LUN and the mirror LUN in the dual-active LUN pair. If the decision result indicates that the first storage device is prohibited from performing mapping processing based on the pre-occupancy LUN ID, then the system returns to the step of selecting a LUN ID as the pre-occupancy LUN ID from the unselected candidate LUN IDs in the candidate LUN ID set. The second storage device returns the decision result in the following manner: The second storage device receives the pre-occupancy request. If the pre-occupancy LUN ID is not in a pre-occupancy state locally on the second storage device, it returns a decision result to the first storage device indicating that the first storage device is allowed to perform mapping processing based on the pre-occupancy LUN ID; otherwise, it returns a decision result to the first storage device. Further determine the pre-occupancy type of the pre-occupancy LUN ID in the second storage device; If the pre-occupancy type indicates that the pre-occupancy is of the non-dual-active LUN type, then a decision result indicating that the first storage device is prohibited from performing mapping processing based on the pre-occupancy LUN ID is returned to the first storage device; If the pre-occupancy type indicates that it belongs to the pre-occupancy of a dual-active LUN type, then obtain the first pre-occupancy time of the pre-occupancy LUNID in the first storage device from the pre-occupancy request, and query the second pre-occupancy time of the LUN ID with the same pre-occupancy LUN ID in the second storage device. If the first pre-occupancy time is earlier than the second pre-occupancy time, a decision result indicating that the first storage device is allowed to perform mapping processing based on the pre-occupancy LUN ID is returned to the first storage device; If the first pre-occupancy time is later than the second pre-occupancy time, a decision result indicating that the first storage device should not perform mapping processing based on the pre-occupancy LUN ID is returned to the first storage device.

2. The method according to claim 1, characterized in that, The method further includes: If the first pre-occupancy time is the same as the second pre-occupancy time, the first whole machine serial number of the first storage device is obtained from the pre-occupancy request, and the second whole machine serial number of the pre-occupancy initiating device with the same LUN ID as the pre-occupancy LUN ID in the second storage device is obtained; If the first complete machine serial number is less than the second complete machine serial number, a decision result indicating that the first storage device is allowed to perform mapping processing based on the pre-occupied LUN ID is returned to the first storage device; otherwise, a decision result indicating that the first storage device is prohibited from performing mapping processing based on the pre-occupied LUN ID is returned to the first storage device.

3. The method according to any one of claims 1-2, characterized in that, The pre-occupancy request carries pre-occupancy information; The pre-occupancy information includes at least: a pre-occupancy LUN ID, a first pre-occupancy time of the pre-occupancy LUN ID in the first storage device, a first system serial number of the first storage device, and a pre-occupancy type; the pre-occupancy type is used to indicate whether the pre-occupancy LUN ID belongs to a dual-active LUN type pre-occupancy. After the second storage device returns a decision result to the first storage device indicating that the first storage device is allowed to perform mapping processing based on the pre-occupied LUN ID, the method further includes: maintaining local occupancy information of the pre-occupied LUN ID in the second storage device based on the pre-occupancy information in the pre-occupancy request.

4. The method according to claim 1, characterized in that, The method further includes: Upon receiving the dual-active LUN mapping request, an operation mutex lock maintained by the first storage device is acquired; the operation mutex lock is used to maintain the atomicity of processing the dual-active LUN mapping request. The operation mutex is released when any of the following conditions are met: the operation of mapping based on the pre-occupied LUNID is completed; or all candidate LUN IDs in the candidate LUN ID set have been traversed.

5. The method according to claim 1, characterized in that, Determining the candidate LUNID set based on the dual-active LUN mapping request includes: Obtain all LUN IDs within the LUN ID range supported by the first storage device that are in a state of not being mapped and not being pre-occupied, and obtain the first LUN ID set; Send a LUN ID query request to the second storage device to obtain the second LUN ID set corresponding to each LUN ID in the LUN ID range supported by the second storage device that is in a state of not being mapped and not being pre-occupied; The candidate LUN ID set is obtained based on the intersection of the first LUN ID set and the second LUN ID set.

6. A dual-active storage implementation device, characterized in that, An apparatus is applied to a first storage device where the primary LUN of a dual-active LUN pair resides; the first storage device is either one of two independent physical storage devices; the dual-active LUN consists of a primary LUN and a mirrored LUN; the mirrored LUN is deployed on a second storage device other than the first storage device among the two independent physical storage devices; the apparatus includes: The candidate LUN ID acquisition module is configured to receive a dual-active LUN mapping request and determine a candidate LUN ID set based on the dual-active LUN mapping request; wherein, the dual-active LUN mapping request is used to indicate that the same LUN ID is allocated to the dual-active LUN pair; the candidate LUN ID set includes candidate LUN IDs that meet the following conditions: they are within the range of LUN IDs supported by both the first storage device and the second storage device, and the LUN ID is in a state of not being mapped and not being pre-occupied on both the first storage device and the second storage device; The pre-occupancy negotiation module is configured to select a LUN ID as a pre-occupancy LUN ID from the unselected candidate LUN IDs in the candidate LUN ID set, and send a pre-occupancy request for the pre-occupancy LUN ID to the second storage device; The active-active LUN ID mapping module is configured to receive a decision result returned by the second storage device in response to a pre-occupancy request. If the decision result indicates that the first storage device is allowed to perform mapping processing based on the pre-occupancy LUN ID, then the pre-occupancy LUN ID is allocated to the primary LUN and the mirror LUN in the active-active LUN pair. If the decision result indicates that the first storage device is prohibited from performing mapping processing based on the pre-occupancy LUN ID, then the step of selecting a LUN ID as the pre-occupancy LUN ID from the unselected candidate LUN IDs in the candidate LUN ID set is returned. The second storage device returns the decision result in the following manner: The second storage device receives the pre-occupancy request. If the pre-occupancy LUN ID is not in a pre-occupancy state locally on the second storage device, it returns a decision result to the first storage device indicating that the first storage device is allowed to perform mapping processing based on the pre-occupancy LUN ID; otherwise, it returns a decision result to the first storage device. Further determine the pre-occupancy type of the pre-occupancy LUN ID in the second storage device; If the pre-occupancy type indicates that the pre-occupancy is of the non-dual-active LUN type, then a decision result indicating that the first storage device is prohibited from performing mapping processing based on the pre-occupancy LUN ID is returned to the first storage device; If the pre-occupancy type indicates that it belongs to the pre-occupancy of a dual-active LUN type, then obtain the first pre-occupancy time of the pre-occupancy LUNID in the first storage device from the pre-occupancy request, and query the second pre-occupancy time of the LUN ID with the same pre-occupancy LUN ID in the second storage device. If the first pre-occupancy time is earlier than the second pre-occupancy time, a decision result indicating that the first storage device is allowed to perform mapping processing based on the pre-occupancy LUN ID is returned to the first storage device; If the first pre-occupancy time is later than the second pre-occupancy time, a decision result indicating that the first storage device should not perform mapping processing based on the pre-occupancy LUN ID is returned to the first storage device.

7. An electronic device, characterized in that, include: Memory, processor; The memory is used to store computer programs; The processor is configured to invoke the computer program to implement the method as described in any one of claims 1-5.

8. A readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1-5.

Images