Method, medium, product and device for access control of a shared storage cluster

Abstract

The application provides an access control method, medium, product and equipment of a shared storage cluster. The method comprises: obtaining a resource access request, the resource access request being used for controlling a target process to access a resource of the shared storage cluster, a private freeze marker being set in each process, and a global shared freeze marker being set in the shared storage cluster; determining a state of the target process according to the private freeze marker; in the case that the private freeze marker shows that the target process is in a frozen state, determining a state of the shared storage cluster according to the global shared freeze marker; and in the case that the global shared freeze marker shows that the shared storage cluster is in a thawed state, setting the private freeze marker corresponding to the target process to a thawed state, and continuing to process the resource access request. Through the method, the nodes and processes can always maintain a unified state view during the whole process of cluster change, and the consistency of resource access and the reliability of the system are significantly improved.

Description

Technical Field

[0001] This invention relates to the field of shared storage cluster technology, and in particular to an access control method, medium, product, and device for a shared storage cluster. Background Technology

[0002] Currently, in distributed system architectures, shared storage clusters are widely used to provide efficient and highly available global resource access services, typically employing a write-read-many cluster deployment model. When a node within the cluster needs to access a global resource, it generally calculates the corresponding resource's management node using a consistent hash ring and sends a request to that management node to complete the resource operation. Cluster member changes (nodes joining or leaving) are a common scenario in cluster operation. Without an effective access control mechanism, this process can easily lead to resource contention, data inconsistency, and even system crashes. Therefore, ensuring the consistency and security of resource access during cluster changes is a core requirement for the stable operation of shared storage clusters. Summary of the Invention

[0003] In view of the above problems, the present invention proposes an access control method, medium, product and device for a shared storage cluster that overcomes or at least partially solves the above problems.

[0004] One objective of this invention is to ensure the correct processing of resource access requests in a shared storage cluster.

[0005] A further objective of this invention is to ensure data consistency in a shared storage cluster during cluster member changes.

[0006] Specifically, the present invention provides an access control method for a shared storage cluster, comprising: Obtain resource access requests. Resource access requests are used to control the target process's access to resources in the shared storage cluster. Each process has a private freeze flag, which indicates that the corresponding process is in a frozen or unfrozen state. The shared storage cluster has a global shared freeze flag, which indicates that the entire shared storage cluster is in a frozen or unfrozen state. The state of the target process is determined based on the private freeze flag; When the private freeze flag indicates that the target process is in a frozen state, the state of the shared storage cluster is determined based on the global shared freeze flag. If the global shared freeze flag indicates that the shared storage cluster is in a thawed state, set the private freeze flag corresponding to the target process to a thawed state and continue processing resource access requests.

[0007] Optionally, the step of determining the state of the target process based on the private freeze flag further includes: Continue processing resource access requests even when the private freeze flag indicates that the target process is in an unfrozen state.

[0008] Optionally, the step of determining the state of the shared storage cluster based on the global shared freeze flag further includes: When the global shared freeze flag indicates that the shared storage cluster is in a frozen state, control the target process to enter a sleep state until it is thawed.

[0009] Optionally, it also includes: When a change in cluster members is detected in the shared storage cluster, the global shared freeze flag is set to a frozen state; A freeze notification is broadcast to all nodes in the shared storage cluster, and each node sets the private freeze flag corresponding to all its internal processes to the freeze state.

[0010] Optionally, it also includes: After detecting that the cluster member changes in the shared storage cluster are completed, the shared unfreeze flag in the shared storage cluster is set to the unfreeze state. The shared unfreeze flag is used to indicate whether the shared storage cluster is in the unfreeze state or not in the unfreeze state. Set the global shared freeze flag in the shared storage cluster to the unfrozen state; Send unfreeze notifications to nodes in the shared storage cluster via broadcast; Upon receiving the unfreeze notification, the node sets its local cached global shared freeze flag to the unfrozen state and notifies all processes within the node to set their corresponding private freeze flags to the unfrozen state. At the same time, it wakes up processes that are in a sleeping state to continue processing resource access requests.

[0011] Optionally, the steps for processing a resource access request include: Send a resource access request to the resource management node of the shared storage cluster; The status of the shared storage cluster is determined by the resource management node based on the global shared freeze flag. When the global shared freeze flag indicates that the shared storage cluster is in a frozen state, the status of the shared storage cluster is determined based on the shared unfreeze flag. Continue processing resource access requests even when the shared storage cluster is in a thawing state indicated by the shared thaw flag.

[0012] Optionally, the step of determining the state of the shared storage cluster based on the shared unfreeze flag further includes: If the shared storage cluster is in a non-thawed state as indicated by the shared thaw flag, ignore resource access requests.

[0013] According to another aspect of the present invention, a computer-readable storage medium is also provided, on which a computer program is stored, wherein the computer program, when executed by a processor, implements the steps of the access control method for any of the above-described shared storage clusters.

[0014] According to another aspect of the present invention, a computer program product is also provided, comprising a computer program that, when executed by a processor, implements the steps of the access control method for any of the above-described shared memory clusters.

[0015] According to another aspect of the present invention, a computer device is also provided, including a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor computer program is a step of implementing the access control method of any of the above-described shared memory clusters.

[0016] The access control method for a shared storage cluster of the present invention, after obtaining a resource access request, uses the resource access request to control the access of a target process to resources of the shared storage cluster. Each process has a private freeze flag, which indicates whether the corresponding process is in a frozen or thawed state. The shared storage cluster has a global shared freeze flag, which indicates whether the entire shared storage cluster is in a frozen or thawed state. First, the state of the target process is determined based on the private freeze flag. If the private freeze flag indicates that the target process is in a frozen state, the state of the shared storage cluster is determined based on the global shared freeze flag. If the global shared freeze flag indicates that the shared storage cluster is in a thawed state, the private freeze flag corresponding to the target process is set to the thawed state, and the resource access request continues to be processed. Through this method, a two-layer verification mechanism based on private and global shared freeze flags can ensure that all nodes and processes maintain a unified state view throughout the entire cluster change process, significantly improving the consistency of resource access and the reliability of request processing.

[0017] Furthermore, in the access control method for the shared storage cluster of the present invention, when a change in cluster members is detected in the shared storage cluster, a global shared freeze flag is set to a frozen state; then a freeze notification is broadcast to all nodes in the shared storage cluster, and each node sets its own private freeze flag corresponding to all processes to a frozen state; after the change in cluster members in the shared storage cluster is detected, a shared unfreeze flag in the shared storage cluster is set to an unfreeze state, which indicates whether the shared storage cluster is in an unfreeze state or not; then the global shared freeze flag in the shared storage cluster is set to an unfreeze state; an unfreeze notification is broadcast to the nodes in the shared storage cluster; the node receiving the unfreeze notification sets its own locally cached global shared freeze flag to an unfreeze state, and notifies all processes within the node to set their own corresponding private freeze flags to an unfreeze state, while waking up processes in a sleeping state to continue processing resource access requests. This method enables globally unified freeze and unfreeze synchronization control throughout the entire lifecycle of cluster member changes, ensuring that the states of all nodes and processes are strictly consistent and the request sequence is orderly. It completely avoids data anomalies and request loss caused by state asynchrony, guarantees the validity and consistency of all requests, and improves system stability.

[0018] The above and other objects, advantages and features of the present invention will become more apparent to those skilled in the art from the following detailed description of specific embodiments of the invention in conjunction with the accompanying drawings. Attached Figure Description

[0019] The following sections will describe some specific embodiments of the invention in detail by way of example and not limitation, with reference to the accompanying drawings. The same reference numerals in the drawings denote the same or similar parts or portions. Those skilled in the art should understand that these drawings are not necessarily drawn to scale. In the drawings: Figure 1 This is a flowchart illustrating an access control method for a shared storage cluster according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the processing flow when cluster members change in the access control method for a shared storage cluster according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the processing flow after the cluster members have been changed in the access control method for a shared storage cluster according to an embodiment of the present invention; Figure 4 This is a schematic diagram of the resource access request processing flow after the cluster members have been changed in the access control method for a shared storage cluster according to an embodiment of the present invention. Figure 5 This is a schematic diagram of a computer program product according to an embodiment of the present invention; Figure 6This is a schematic diagram of a computer-readable storage medium according to an embodiment of the present invention; and Figure 7 This is a schematic diagram of a computer device according to an embodiment of the present invention. Detailed Implementation

[0020] Those skilled in the art should understand that the embodiments described below are merely a part of the embodiments of the present invention, and not all of the embodiments of the present invention. These partial embodiments are intended to explain the technical principles of the present invention and are not intended to limit the scope of protection of the present invention. Based on the embodiments provided by the present invention, all other embodiments obtained by those skilled in the art without creative effort should still fall within the scope of protection of the present invention.

[0021] It should be noted that the logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be specifically implemented in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0022] In shared storage cluster environments, write-read-multiple clusters are typically used to provide efficient resource access services. When a node needs to access a global resource, it often needs to use a consistent hash ring to calculate the management node for that resource and send a request to that management node to complete the resource operation. Ensuring resource consistency and security is a critical issue when cluster membership changes (nodes joining or leaving). If this process is not properly controlled, it can lead to resource contention, data inconsistency, or even system crashes.

[0023] Furthermore, when a process requests global resources, it checks the cluster status. If it's undergoing changes, it sleeps and waits for the changes to complete before initiating the request. After the cluster change is complete, to ensure all nodes are running, the first request after the change confirms the cluster status with the cluster coordinator node, ensuring the request message isn't mistakenly ignored. While this initial request confirmation mechanism after a change ensures the request message isn't mistakenly discarded, it may lead to the following problems: 1. Additional messaging and state synchronization increase network overhead, especially in large-scale clusters.

[0024] 2. The performance of the coordinating node becomes a bottleneck, especially at the moment the change is completed, when there may be a large number of concurrent requests to the cluster state.

[0025] To address the above problems, this invention proposes an access control method for shared storage clusters. Figure 1 This is a flowchart illustrating an access control method for a shared storage cluster according to an embodiment of the present invention, as shown below. Figure 1 As shown, the access control method for the shared storage cluster includes at least the following steps S101 to S106.

[0026] Step S101: Obtain resource access requests. These resource access requests control access to resources within the shared storage cluster by the target process. Each process has a private freeze flag indicating whether it is in a frozen or thawed state. The shared storage cluster also has a global shared freeze flag indicating whether the entire shared storage cluster is in a frozen or thawed state.

[0027] Resource access requests are generally operation requests initiated by the requesting end to the shared storage cluster to access global resources of the shared storage cluster, including but not limited to read, write, modify, and delete operations on global resources. They are the execution carriers through which the shared storage cluster provides services. Before the execution of this method, the initialization configuration of the cluster marking system has been completed in advance, including at least two parts: First, for each running process in the cluster, a private freeze flag is configured in its independent private memory space, which is readable and writable only by that process. This private freeze flag is used to indicate whether the corresponding process is in a frozen or thawed state. This flag is a binary state identifier, with only two values: frozen and thawed. For example, when it is true, it can indicate that the process is in a frozen state, and when it is false, it can indicate that the process is in a thawed state. The initial state can generally be uniformly set to the thawed state, used to quickly identify whether a process needs to intercept resource access requests locally. The entire reading process only needs to access the process's local memory, without any network communication, cross-node or cross-process interaction. Secondly, in the distributed shared storage area of ​​the shared storage cluster, a globally shared freeze flag that can be securely accessed by all cluster nodes is configured. This flag is also a binary state identifier, with two values: frozen and thawed. The initial state can also be uniformly set to the thawed state. All nodes and processes read this flag based on the stored value in the distributed shared storage, ensuring the uniqueness of the cluster's global state from the root and avoiding state conflicts among multiple nodes.

[0028] Step S102: Determine the state of the target process based on the private freeze flag. This step is the first layer of pre-verification for the resource access request. The entire verification process is completed within the target process that initiated the request. It only needs to read the private freeze flag in the process's private memory to complete the initial state determination, without any additional system overhead or network interaction.

[0029] This step, as a pre-verification step, is designed to address the performance overhead and network costs associated with each request requiring access to the coordinating node to confirm the status. In most normal cluster operation scenarios, there are no member changes, and all processes' private freeze flags remain thawed. By performing local memory verification in this step, it can be directly determined that the process has normal access rights without any additional network interaction. This reduces the time spent on status verification in typical scenarios to the level of memory access, significantly improving the response efficiency of resource access and completely avoiding the problem of massive requests converging on the coordinating node.

[0030] The determination result of this step is divided into two branches: if the private freeze mark is in the unfrozen state, it means that the target process currently has no access restrictions and can directly enter the subsequent request processing stage; if the private freeze mark is in the frozen state, it means that the target process may be in the freeze control period of cluster member change, and needs to enter the second layer of verification stage to further confirm the running status of the cluster and avoid the request being mistakenly intercepted due to the inconsistency between the local mark and the global state of the cluster.

[0031] Step S103: If the shared storage cluster is determined to be in a frozen state in step S102, the state of the shared storage cluster is determined based on the global shared freeze flag.

[0032] This step is the second layer of verification for resource access requests. It is triggered only when the first-layer pre-verification determines that the state is frozen, thus minimizing the frequency of access to the globally shared freeze flag. After triggering, the target process accesses the cluster's distributed shared storage area to read the current value of the globally shared freeze flag and obtain the overall operating status of the cluster.

[0033] The core design objective of this step is to address the timing difference issue in state synchronization between nodes and processes in a distributed cluster environment. Freezing and unfreezing notifications for cluster member changes are sent via cluster broadcast. Different nodes and processes may experience millisecond-level timing differences in receiving these notifications, easily leading to situations where the cluster has completed member changes and the global state has been restored to unfrozen, but some processes' local private freeze flags remain frozen. If only the private freeze flag is used for single verification, it can result in false interceptions where the cluster has resumed normal operation, but processes are still unable to initiate resource access, causing cluster service anomalies.

[0034] This step reads the cluster's unique globally shared freeze flag and uses the cluster's global state as the final determination basis. This retains the efficiency of local verification in conventional scenarios while completely solving the consistency problem of state asynchrony in a distributed environment, ensuring the accuracy of state determination.

[0035] The determination result of this step is divided into two branches: if the global shared freeze flag is in a frozen state, it means that the cluster is still in a sensitive period of member change and the current request needs to be intercepted and controlled; if the global shared freeze flag is in a thawed state, it means that the cluster has completed the member change and has returned to normal operation, and the private freeze flag of the process local needs to be synchronously corrected.

[0036] Step S104: If the cluster is confirmed to be in a frozen state in step S103, the target process is controlled to enter a sleep state until it is unfrozen. This step is the request interception and suspension processing stage when the cluster is frozen. When it is confirmed through two layers of verification that the cluster is still in a frozen state, the target process suspends the execution of the current resource access request, enters a blocking sleep state, and adds itself to the waiting queue for the cluster unfreezing event. It will only be awakened and removed from the waiting queue and resume request execution when it receives the unfreezing notification broadcast by the cluster.

[0037] This step is designed with dual value: First, it ensures resource consistency and security during cluster member changes. When cluster members change, the ownership of the global resource management node may be reassigned. If processes are allowed to arbitrarily access resources at this time, problems such as resource write errors, data inconsistency, and multi-node resource contention can easily occur, and in severe cases, even cause cluster crashes. Through the request suspension control in this step, all unnecessary resource access requests can be intercepted from the request initiating end during the change period, eliminating abnormal access at the root. Second, it improves the continuity and reliability of request processing. Compared with the processing method of directly rejecting requests and requiring manual retrying on the user side, this step completely preserves the execution context of the request by suspending the process through sleep. After the cluster is unfrozen, execution can be resumed directly without any retry operation on the user side. This avoids the problem of request loss and greatly optimizes the user experience of cluster services.

[0038] Step S105: If the target process is determined to be in a thawed state in step S103, set the private freeze flag corresponding to the target process to the thawed state.

[0039] This step is the autonomous synchronization and correction of the process's local private freeze flag. When the second-level verification confirms that the cluster is in a thawed state, but the process's local private freeze flag is still frozen, the target process autonomously resets its own private freeze flag to a thawed state, thus completing the synchronization and alignment between the local state and the cluster's global state.

[0040] The purpose of this step is to completely resolve the timing discrepancies and packet loss risks associated with broadcast notifications in distributed clusters. When cluster unfreezing notifications are broadcast, some processes may not receive the notification in a timely manner, notification processing may be delayed, or even packet loss may occur in extreme scenarios, leading to long-term inconsistencies between the process's local flag and the cluster's global state. This step's self-correction mechanism eliminates the need for passive synchronization via broadcast notifications; processes can proactively synchronize their state when initiating a request, completely avoiding the long-term false interception of requests due to notification anomalies. Furthermore, after self-correction, all subsequent resource access requests initiated by the process can pass directly through the pre-verification in step S102 without needing to access the globally shared freeze flag again. This prevents the performance overhead of subsequent requests from increasing due to a single state synchronization, fully guaranteeing the long-term access efficiency of the cluster.

[0041] Step S106: If the state is determined to be unfrozen in step S102 or step S105 is completed, continue processing the resource access request.

[0042] This step is the final execution stage of the resource access request. When the process is confirmed to have compliant resource access permissions through pre-verification, the target process sends a resource access request to the resource management node corresponding to the shared storage cluster, completes the target operations such as reading and writing resources, and then sends a response to the requesting end to realize the core service capabilities of the shared storage cluster.

[0043] This step covers two compliant business scenarios: The first is the normal operating scenario where step S102 verifies that the private frozen flag is in an unfrozen state. In this scenario, the request is processed directly, which corresponds to the unchanging operating cycle of the cluster and maximizes the access efficiency in the normal scenario. The second is the synchronization scenario after step S105 completes the self-correction of the private flag. This corresponds to the abnormal scenario where the cluster has just been unfrozen and the process local flag has not been synchronized in time. After the state synchronization is completed, the request is processed, which not only ensures the global consistency of the cluster state, but also avoids the problem of request misinterpretation.

[0044] In summary, the method of this invention achieves distributed and localized status verification of resource access requests through a two-layer verification system consisting of private freeze markers and globally shared freeze markers. It eliminates the need to initiate status confirmation with the coordinating node for each request, thereby quickly freezing and unfreezing resource access, significantly reducing the network communication overhead of the cluster, and completely avoiding the performance bottleneck problem of the coordinating node. At the same time, the self-correction mechanism of process-local markers ensures both state consistency and request processing reliability in a distributed cluster environment.

[0045] Figure 2This is a schematic diagram of the processing flow when cluster members change in the access control method of a shared storage cluster according to an embodiment of the present invention. This embodiment corresponds to the entire process of freezing triggering in the scenario of cluster member change. This process, through cluster-level state updates and distributed synchronization, completes the access freeze control of the entire cluster before the sensitive period of cluster member change is initiated, thereby fundamentally avoiding the risks of resource competition and data inconsistency during the change period. Figure 2 As shown, the process includes at least the following steps S201 to S204.

[0046] Step S201: A change in cluster members was detected in the shared storage cluster.

[0047] This step is the trigger entry point for the entire freeze control process, and the execution entity is the change coordination node of the shared storage cluster. Cluster member changes are a common scenario in the operation of a shared storage cluster, which generally includes cluster node joining events and cluster node leaving events. Examples of node leaving events include: normal node offline, node failure offline, node network disconnection, and any other scenario that causes changes in the cluster member topology. The detection methods in this step include, but are not limited to, cluster node heartbeat status detection, cluster member list change event listening, and node registration / deregistration event capture.

[0048] The purpose of this step is to accurately pinpoint the start time of sensitive periods in the cluster state. When a real change occurs in the cluster member topology, the subsequent freeze control process is triggered to avoid meaningless freeze operations affecting the normal service capabilities of the cluster. At the same time, by coordinating the unified detection of nodes, it is ensured that there is only one source of change event triggering in the entire cluster, avoiding state chaos caused by repeated triggering or erroneous triggering by multiple nodes, and providing a unified timing benchmark for the consistency management of the entire cluster state in the future.

[0049] Step S202: Set the globally shared freeze flag to the frozen state.

[0050] This step is the state update phase of the freeze control process. The execution entity remains the cluster change coordinating node. Upon detecting a legitimate cluster member change event, the coordinating node prioritizes modifying the globally shared freeze flag stored in the cluster's distributed shared storage area via an atomic write operation, updating it from an unfrozen state to a frozen state. This step follows the distributed system design principle of updating the globally shared freeze flag first, followed by synchronously executing actions. Its core design logic and necessity lie in the fact that the globally shared freeze flag is the sole basis for the cluster's operating state. Only by completing this state update first can we ensure that the state synchronization of all subsequent nodes and processes is based on the same global benchmark, completely avoiding timing discrepancies and state splitting problems in a distributed environment.

[0051] This step, through the atomic operations provided by distributed shared storage, ensures that modifications to the globally shared freeze marker are atomic and unique, preventing data anomalies caused by concurrent modifications and avoiding any impact on the execution efficiency of the change process.

[0052] Step S203: Broadcast a freeze notification to all nodes in the shared storage cluster.

[0053] This step is the core of synchronizing the frozen state to the entire cluster. The main body responsible for this is usually the cluster change coordination node. After completing the atomic modification of the globally shared freeze flag, the coordination node sends a freeze notification to all online cluster nodes through the cluster broadcast mechanism, notifying the cluster that it has entered a member change cycle and that the globally shared freeze flag has been updated to the frozen state.

[0054] The core design logic of this step is a targeted optimization to address the core defects of existing technologies. Its design necessity and technical advantages are as follows: In general, the coordinating node in a cluster needs to communicate and interact directly with a massive number of processes, which can easily lead to a performance bottleneck in the coordinating node; while in the method of this invention, the coordinating node only needs to communicate with a limited number of cluster nodes and does not need to directly connect to a massive number of business processes. This can reduce the network communication overhead and concurrent processing pressure of the coordinating node by several orders of magnitude, and completely solve the performance bottleneck problem of the coordinating node from the root of the architecture.

[0055] This step enables efficient, full-cluster synchronization of freeze commands while minimizing the performance overhead of coordinating nodes, ensuring the efficiency of cluster change processes.

[0056] In step S204, each node sets the private freeze flag corresponding to all processes within itself to the frozen state.

[0057] This step is the final execution stage of the freeze control command on the local node. The execution entity is each cluster node that receives the freeze notification. After receiving the freeze notification, the node sends the freeze command to all business processes running within the node through the local inter-process communication mechanism, and uniformly sets the private freeze flag stored in the private memory space of each process to the frozen state, thus completing the access freeze control for the entire node.

[0058] The core design logic of this step is to adopt a distributed task allocation model, which synchronizes the state of massive processes and distributes them to each node for local execution. Its advantages are: the cluster node, as the running host of the processes, has complete management rights over all processes within its node. Through native operating system capabilities such as local inter-process communication and system signal notifications, it can quickly modify the private freeze flag of all processes within its node without any cross-node network communication, and the execution efficiency is far higher than that of remote command issuance across nodes. At the same time, each node is only responsible for managing its own internal processes, and the management pressure of the coordinating node is completely distributed among the nodes, which further enhances the scalability of the cluster. Even if the cluster scales up to hundreds of nodes and hundreds of thousands of processes, there will be no management performance bottleneck.

[0059] This step enables rapid synchronization of the frozen state of all business processes across the entire cluster, ensuring that no resource access requests are initiated during cluster member changes, thus eliminating the risk of resource contention and data inconsistency during the change period.

[0060] This method enables efficient freeze management of the entire cluster during cluster member changes. It not only completely solves the core defects of existing technologies, such as high network overhead and performance bottlenecks of coordinating nodes, but also ensures the consistency of the entire cluster state through strict timing control and authoritative state management, providing a complete solution for resource security and data stability during cluster member changes.

[0061] Figure 3 This is a schematic diagram of the processing flow after cluster member changes are completed in the access control method for a shared storage cluster according to an embodiment of the present invention. This embodiment corresponds to the entire unfreezing and synchronization process after cluster member changes are completed, forming a complete full lifecycle management system with the aforementioned cluster change freezing process and resource request verification process. It specifically addresses core issues in existing technologies such as high overhead for state synchronization after cluster changes, performance bottlenecks in coordination nodes, request misjudgment and loss due to asynchronous states between nodes, and data inconsistency. It achieves efficient and lossless service recovery while ensuring global consistency of the cluster state. Figure 3 As shown, the specific steps include S301 to S307.

[0062] Step S301: The completion of cluster member changes in the shared storage cluster is detected. This step is the trigger entry point for the entire unfreeze synchronization process. The executing entity is consistent with the aforementioned freeze trigger process, which is the change coordination node of the shared storage cluster. This ensures that the entire process of cluster member changes is controlled by a single node, fundamentally avoiding timing errors and state splits caused by multiple node triggers. The completion of cluster member changes means that the cluster has completed all member updates and resource reallocation actions. For example, nodes have completed joining or leaving operations and will no longer affect the cluster's operating state. Only after all sensitive operations of cluster member changes are completely completed and the cluster topology and resource ownership are completely stable will the subsequent unfreeze process be initiated. This completely avoids resource access errors and data inconsistencies caused by premature unfreezing before changes are completed. Simultaneously, through unified detection by the change coordination node, it is ensured that there is only one unfreeze trigger source in the entire cluster, providing a unified timing benchmark for subsequent state synchronization of the entire cluster and guaranteeing global consistency throughout the unfreeze process.

[0063] Step S302: Set the shared thaw flag in the shared storage cluster to a thawing state. The shared thaw flag is a cluster-level authoritative state flag specifically introduced in this invention to solve the problem of distributed cluster thaw synchronization. It is stored in the cluster's distributed shared storage area and can be securely accessed by all cluster nodes through atomic operations. This flag is a binary state identifier, with only two values: thawing and not thawed, used to indicate whether the shared storage cluster is in a thawing or not thawed state. The initial state can generally be set to not thawed, specifically used to identify whether the cluster is in a thaw synchronization transition period after a change has been completed, providing a unified state transition benchmark for all cluster nodes and resource management nodes.

[0064] After confirming the cluster member changes, this step prioritizes updating the shared unfreeze flag from a non-unfreeze state to an unfreeze state via an atomic write operation. The necessity and core function of this design lies in the fact that in a distributed cluster environment, when unfreeze notifications are broadcast, there is a natural millisecond-level time difference in the time it takes for different nodes to receive the notification. Without a unified unfreeze transition status identifier, scenarios may occur where some nodes have completed unfreezing and started initiating resource requests, while other nodes remain in a frozen state, and the resource management node still marks the cluster as frozen. This could lead to the resource management node mistakenly classifying legitimate new requests as expired requests and discarding them, resulting in request loss and service anomalies.

[0065] This step, by pre-setting a shared unfreeze flag, declares the entire cluster to have entered the unfreeze transition period. This provides a unified timing benchmark for subsequent node state synchronization and a clear judgment basis for request verification by resource management nodes. It completely solves the problem of request misjudgment caused by timing differences, ensures the atomicity and uniqueness of flag modification, and will not have any impact on unfreeze efficiency. It solves the problem of state inconsistency caused by distributed timing differences from an architectural perspective.

[0066] Step S303: Set the global shared freeze flag in the shared storage cluster to the unfrozen state.

[0067] After atomically updating the shared thaw flag, this step modifies the global shared freeze flag stored in the cluster's distributed shared storage area through an atomic write operation, updating it from a frozen state to a thawed state. The necessity and timing logic of this design lie in the fact that the shared thaw flag must be set first, and then the global shared freeze flag updated. This ensures that before the global freeze state is officially lifted, the entire cluster is clearly aware that it is currently in a thaw transition period. Resource management nodes can then identify legitimate requests based on the shared thaw flag, completely avoiding misjudgments of requests caused by differences in state update timing.

[0068] Step S304: Send an unfreeze notification to nodes in the shared storage cluster via broadcast. This step is the core link in synchronizing the unfreeze status from the coordinating node to the entire cluster. The coordinating node is responsible for execution. After completing the atomic modification of the global shared freeze flag, it sends an unfreeze notification to all online cluster nodes through the cluster's reliable broadcast mechanism. The notification clearly states that the cluster has completed the member change, the shared unfreeze flag has been set to the unfreeze state, and the global shared freeze flag has been updated to the unfreeze state.

[0069] This step is a targeted optimization addressing the core shortcomings of existing technologies. Its advantages lie in: adopting a first-level broadcast mode from the coordinating node to the cluster nodes. The coordinating node only needs to communicate with a limited number of dozens to hundreds of nodes within the cluster, without directly interacting with tens to hundreds of thousands of business processes within the nodes. This reduces the network communication overhead and concurrent processing pressure of the coordinating node by several orders of magnitude, fundamentally resolving the performance bottleneck caused by massive requests converging on the coordinating node. This ensures that all online cluster nodes can receive the unfreezing notification completely and accurately. This achieves efficient, full-cluster synchronization of unfreezing commands while minimizing the performance overhead of the coordinating node, guaranteeing efficient cluster service recovery.

[0070] Step S305: The node receiving the unfreeze notification sets its locally cached globally shared freeze flag to the unfrozen state. This step is the synchronization and implementation of the unfrozen state on the node's local machine, and the execution entity is each cluster node that received the unfreeze notification. In distributed cluster operation, to avoid the performance overhead caused by remotely accessing the distributed shared storage for each process status verification, each cluster node maintains a cached copy of the globally shared freeze flag in its local memory for fast local reading and verification. After receiving the unfreeze notification, the node first updates its locally cached globally shared freeze flag from the frozen state to the unfrozen state, completing the synchronization and alignment between the node's local state and the cluster's global authoritative state.

[0071] The first step in this process involves updating the global authority marker on the coordinating node to establish the final authority state of the cluster. The second step involves synchronizing the local cache copies of the cluster nodes to ensure that the local state benchmark of the nodes is completely consistent with the global authority, which is a prerequisite for the subsequent node management process state.

[0072] This step only requires modifying the cached value in the node's local memory, incurring no network communication overhead, and can be completed within microseconds. This step ensures that the node's local state is completely consistent with the cluster's global state, providing an accurate baseline for subsequent process state synchronization, while also guaranteeing the efficiency and accuracy of local state verification when subsequent processes initiate requests.

[0073] Step S306: Notify all processes within the node to set their corresponding private freeze flag to the unfrozen state.

[0074] This step is the local implementation of the unfreezing control command on the node. The execution entity is each cluster node that has completed local state synchronization. The node sends the unfreezing command to all business processes running within the node through the local inter-process communication mechanism, and updates the private freeze mark stored in the private memory space of each process from the frozen state to the unfrozen state, thereby completing the removal of access restrictions for the entire node.

[0075] This step employs a distributed task allocation model, completely distributing the state synchronization work of massive processes to each node for local execution. Its advantages are: the cluster node, as the running host of the processes, has complete management authority over all processes within its node. Through native inter-process communication and system signal notifications from the operating system, the private freeze flag modification of all processes within the node can be completed in a short time without any cross-node network communication, resulting in execution efficiency far exceeding that of cross-node remote command issuance; at the same time, the management and control pressure of the coordinating node is completely distributed, further enhancing the scalability of the cluster. Even if the cluster size is greatly expanded, there will be no management and control performance bottleneck.

[0076] Step S307: Wake up processes that are in a sleeping state to continue processing resource access requests. After updating the private freeze flags of all processes on the node, the node uses the process wake-up mechanism to wake up all processes that entered a sleep waiting state during the cluster freeze from the blocked waiting queue and resume the execution of previously suspended resource access requests.

[0077] During cluster freeze, this invention employs a process sleep suspension approach for resource requests that need to be intercepted, fully preserving the execution context and business data of the requests. Without terminating the requests, the processes can be actively resumed from their suspended positions through this step, eliminating the need for any retry operations on the user side. This achieves complete business transparency regarding cluster changes and ensures that all resource requests suspended during cluster freeze can be processed completely and continuously, thoroughly avoiding request loss and business interruption issues, and significantly improving the reliability of cluster services and user experience.

[0078] In summary, the method of this invention achieves efficient, consistent, and lossless unfreezing after cluster changes through full-process control of "unified detection of change completion → pre-unfreezing state setting → global freeze state unfreezing → node broadcast synchronization → node local state alignment → process state update → sleep process wake-up and recovery". It not only completely solves the core defects of large network overhead and performance bottleneck of coordination nodes caused by state confirmation after change from an architectural perspective, but also completely solves the problems of request misjudgment and state inconsistency caused by the time difference of unfreezing in a distributed environment through the transition state design of shared unfreezing mark and dual state synchronization guarantee mechanism.

[0079] Figure 4 This is a schematic diagram of the resource access request processing flow after cluster member changes are completed in the access control method for a shared storage cluster according to an embodiment of the present invention. This embodiment corresponds to the full-process verification and processing logic of shared storage cluster resource access requests on the resource management node side, specifically solving the problem of data inconsistency caused by misjudged and discarded requests within the cluster change time window and illegal writing of expired requests. Figure 4 As shown, the specific steps include S401 to S405.

[0080] Step S401: Send a resource access request to the resource management node of the shared storage cluster. This step is the entry point for the server-side processing flow. The execution entity is the business process within the cluster that initiated the resource access, mainly targeting the sleep process that is awakened and resumes execution of the request after the cluster is unfrozen.

[0081] Step S402: The resource management node determines the status of the shared storage cluster based on the globally shared freeze flag. This step is the first layer of verification for resource access requests by the server. The execution entity is the resource management node that receives the request. After receiving the resource access request after being woken up, the resource management node first accesses the distributed shared storage area of ​​the cluster, reads the current value of the globally shared freeze flag, and completes the first layer of judgment on the legality of the request based on the globally unique status of the cluster.

[0082] The resource management node is the ultimate executor of global resource operations. Its processing of requests must be solely based on the authoritative state of the entire cluster, not the local state of the requesting process or even the local cache state of the resource management node. This fundamentally avoids the risk of illegal write requests caused by state inconsistencies in a distributed environment. Furthermore, this step employs a global state-first verification design, adapting to most normal cluster operation scenarios: when the cluster has no member changes and is in a stable operating state, the globally shared freeze flag is always thawed. A single verification in this step is sufficient to determine the request's legitimacy and proceed to subsequent processing. The entire verification process requires only one distributed shared storage read operation, without additional network communication or interaction with the coordinating node, completely avoiding the performance overhead and bottleneck issues caused by needing to confirm the state with the coordinating node for each request.

[0083] Step S403: If the shared storage cluster is determined to be in a frozen state in step S402, the state is determined based on the shared thaw flag. This step is triggered only when the first-level verification determines that the global shared freeze flag is in a frozen state. The execution entity is the resource management node. After triggering, the resource management node continues to access the distributed shared storage area of ​​the cluster, reads the current value of the shared thaw flag, and further determines the current lifecycle stage of the cluster.

[0084] This is because in a distributed cluster environment, cluster unfreezing notifications are broadcast, and there is a natural millisecond-level time difference in the time it takes for different nodes to receive the notification and complete state synchronization. This easily leads to scenarios where the coordinating node has completed the global state update, some nodes have completed unfreezing and initiated legitimate requests, but the resource management node has not yet synchronized the latest global state and still judges the cluster to be in a frozen state. If it is impossible to distinguish between legitimate new requests and expired requests from before the change in this scenario, the only solution is to have the requesting party confirm the status with the coordinating node a second time, which brings huge network overhead and is also prone to being wrongly judged and discarded. This step introduces a secondary verification of the shared unfreezing flag, which can accurately distinguish between the two scenarios: if the shared unfreezing flag is in the unfreezing state, it means that the cluster has completed the member change and is in the transition window of unfreezing synchronization, and the current request is a legitimate new request initiated by a node that has completed unfreezing; if the shared unfreezing flag is not in the unfreezing state, it means that the cluster is in the process of executing the member change, and the current request is an expired request issued before the change or an illegal request that has not completed the freeze synchronization.

[0085] This step can completely solve the problem of request misjudgment caused by distributed time difference. Without increasing the overhead of additional status confirmation, it can accurately distinguish between legitimate requests during the freeze transition window and expired requests during the change period. This not only ensures the security of cluster data, but also completely avoids the problem of legitimate requests being discarded by mistake, and greatly improves the reliability and continuity of cluster services.

[0086] Step S404: If step S403 determines that the resource access request is not in a thawing state, ignore the resource access request. This step is the interception and processing stage for illegal / expired requests. The execution entity is the resource management node. When two layers of verification confirm that the global shared freeze flag is frozen and the shared thawing flag is not in a thawing state, it indicates that the cluster is in a sensitive execution cycle of member changes. The ownership of the resource management node and the cluster topology are still in a dynamic process. Processing the request at this time would cause serious consistency problems such as resource contention, double data writing, and incorrect ownership of the management node. Therefore, the resource management node directly ignores the current resource access request.

[0087] This step establishes a final safety net for resource data security during cluster changes, forming a dual protection mechanism with the request-side freeze interception mechanism: even in extreme scenarios where some nodes fail to complete freeze synchronization or processes initiate resource access requests in violation of regulations, the server can use this step to complete the final interception, completely eliminating illegal resource operations during changes and preventing resource contention, data inconsistency, or even system crashes from the root.

[0088] In step S405, if the resource access request is determined to be in a thawed state in step S402 or in a thawing state in step S403, the resource access request continues to be processed.

[0089] This step is the final execution stage for legitimate requests on the server side. The execution entity is the resource management node. This step covers two fully compliant request processing scenarios: The first is the normal scenario where step S402 verifies that the globally shared freeze mark has been thawed, corresponding to most periods of stable cluster operation, and the request is processed normally directly. The second is the transitional scenario where step S403 verifies that the shared thaw mark has been thawed, corresponding to the thaw synchronization window after cluster changes are completed, and the request is processed normally after being determined to be a legitimate new request. After processing, the resource management node returns the processing result to the business process that initiated the request through the cluster's internal communication link, completing the entire process of processing the resource access request.

[0090] The design logic of this step forms a complete closed loop with all the aforementioned processes. It ensures service efficiency under normal cluster operation scenarios and resolves the service continuity issue during the cluster change unfreezing window, completely avoiding the service interruption problem that requires waiting for the entire cluster state to be fully synchronized after a node change. This step is implemented based on the mature resource management and operation mechanisms of shared storage clusters, enabling stable and accurate completion of various resource operations and ensuring that all compliant resource access requests are processed normally and efficiently. This guarantees service performance under normal cluster operation and achieves lossless and continuous service recovery before and after cluster changes, significantly optimizing the service quality and user experience of shared storage clusters.

[0091] In summary, the method of this invention achieves accurate verification and secure processing of resource access requests without increasing any coordination node interaction overhead. It not only completely solves the problem of request misjudgment and loss caused by distributed time sequence differences, but also provides the final guarantee for resource data consistency during cluster changes, thereby improving system stability.

[0092] The flowchart provided in this embodiment is not intended to indicate that the operations of the method will be performed in any particular order, or that all operations of the method are included in every case. Furthermore, the method may include additional operations. Within the scope of the technical concept provided by the method in this embodiment, additional variations can be made to the above method.

[0093] It should be understood that in some embodiments, the components may be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods may be implemented using software or firmware stored in memory and executed by a suitable instruction execution system.

[0094] This embodiment also provides a computer program product 10, a computer-readable storage medium 20, and a computer device 30. Figure 5 This is a schematic diagram of a computer program product 10 according to an embodiment of the present invention. Figure 6This is a schematic diagram of a computer-readable storage medium 20 according to an embodiment of the present invention. Figure 7 This is a schematic diagram of a computer device 30 according to an embodiment of the present invention. The computer program product 10 includes a computer program 11, which, when executed by the processor 32, implements the steps of the access control method for the shared memory cluster described above. A computer-readable storage medium 20 stores the computer program 11 thereon, which, when executed by the processor 32, implements the steps of the access control method for the shared memory cluster described above. The computer device 30 may include a memory 31, a processor 32, and the computer program 11 stored on the memory 31 and running on the processor 32.

[0095] The computer program 11 used to perform the operations of this invention may be assembly instructions, Instruction Set Architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, integrated circuit configuration data, or source code or object code written in any combination of one or more programming languages ​​and procedural programming languages. The computer program 11 may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, including a Local Area Network (LAN) or Wide Area Network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, to perform aspects of this invention, electronic circuits, including, for example, programmable logic circuits, Field-Programmable Gate Arrays (FPGAs), or Programmable Logic Arrays (PLAs), may execute computer-readable program instructions to personalize the electronic circuits by utilizing state information from computer-readable program instructions.

[0096] For the purposes of this embodiment, computer program product 10 is a related product containing computer program 11. For the purposes of this embodiment, computer-readable storage medium 20 is a tangible device capable of holding and storing computer program 11, and can be any device capable of containing, storing, communicating, propagating, or transmitting program 11 for use by or in conjunction with an instruction execution system, apparatus, or device. More specific examples (a non-exhaustive list) of computer-readable storage medium 20 include: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable optical disc read-only memory (CD-ROM), digital versatile disc (DVD), memory stick, floppy disk, mechanical encoding device, and any suitable combination thereof.

[0097] Computer device 30 can be, for example, a server, desktop computer, laptop computer, tablet computer, or smartphone. In some examples, computer device 30 can be a cloud computing node. Computer device 30 can be described in the general context of computer system executable instructions (such as program modules) executed by a computer system. Typically, program modules can include routines, programs, object programs, components, logic, data structures, etc., that perform specific tasks or implement specific abstract data types. Computer device 30 can be implemented in a distributed cloud computing environment where tasks are performed by remote processing devices linked through a communication network. In a distributed cloud computing environment, program modules can reside on local or remote computing system storage media, including storage devices.

[0098] Computer device 30 may include a processor 32 adapted to execute stored instructions and a memory 31 that provides temporary storage space for the operation of said instructions during operation. The processor 32 may be a single-core processor, a multi-core processor, a computing cluster, or any other configuration. The memory 31 may include random access memory (RAM), read-only memory, flash memory, or any other suitable storage system.

[0099] Computer device 30 may also include a network adapter / interface and an input / output (I / O) interface. The I / O interface allows external devices that can be connected to the computer device to input and output data. The network adapter / interface provides communication between the computer device and a network, typically represented as a communication network.

[0100] Therefore, those skilled in the art should recognize that although numerous exemplary embodiments of the present invention have been shown and described in detail herein, many other variations or modifications conforming to the principles of the present invention can be directly determined or derived from the disclosure of the present invention without departing from the spirit and scope of the invention. Thus, the scope of the present invention should be understood and construed as covering all such other variations or modifications.

Claims

1. An access control method for a shared storage cluster, comprising: Obtain a resource access request, which is used to control the target process to access the resources of the shared storage cluster. Each process has a private freeze flag, which is used to indicate that the corresponding process is in a frozen or unfrozen state. The shared storage cluster has a global shared freeze flag, which is used to indicate that the shared storage cluster as a whole is in a frozen or unfrozen state. The state of the target process is determined based on the private freeze flag; When the private freeze flag indicates that the target process is in a frozen state, the state of the shared storage cluster is determined according to the global shared freeze flag; If the global shared freeze flag indicates that the shared storage cluster is in a thawed state, the private freeze flag corresponding to the target process is set to a thawed state, and the resource access request continues to be processed.

2. The access control method for a shared storage cluster according to claim 1, wherein, The step of determining the state of the target process based on the private freeze flag further includes: If the private freeze flag indicates that the target process is in a thawed state, continue processing the resource access request.

3. The access control method for a shared storage cluster according to claim 1, wherein, Following the step of determining the state of the shared storage cluster based on the global shared freeze flag, the method further includes: When the global shared freeze flag indicates that the shared storage cluster is in a frozen state, the target process is controlled to enter a sleep state until it is thawed.

4. The access control method for a shared storage cluster according to claim 1 further includes: When a change in cluster members is detected in the shared storage cluster, the global shared freeze flag is set to a frozen state; A freeze notification is broadcast to all nodes in the shared storage cluster, and each node sets the private freeze flag corresponding to all processes within its own system to the frozen state.

5. The access control method for a shared storage cluster according to claim 4 further includes: After detecting that the cluster member changes in the shared storage cluster are completed, the shared unfreeze flag in the shared storage cluster is set to the unfreeze state. The shared unfreeze flag is used to indicate whether the shared storage cluster is in the unfreeze state or not in the unfreeze state. Set the global shared freeze flag in the shared storage cluster to the unfrozen state; Send unfreezing notifications to nodes in the shared storage cluster via broadcast; Upon receiving the unfreeze notification, the node sets its locally cached global shared freeze flag to an unfrozen state and notifies all processes within the node to set their corresponding private freeze flags to an unfrozen state. Simultaneously, it wakes up processes that are in a sleeping state to continue processing the resource access request.

6. The access control method for a shared storage cluster according to claim 5, wherein, The steps for processing the resource access request include: Send the resource access request to the resource management node of the shared storage cluster; The resource management node determines the status of the shared storage cluster based on the global shared freeze flag. When the global shared freeze flag indicates that the shared storage cluster is in a frozen state, the state of the shared storage cluster is determined according to the shared unfreeze flag; If the shared thaw flag indicates that the shared storage cluster is in a thawing state, continue processing the resource access request.

7. The access control method for a shared storage cluster according to claim 6, wherein, Following the step of determining the state of the shared storage cluster based on the shared thaw marker, the method further includes: If the shared storage cluster is in a non-thawed state as indicated by the shared thaw flag, the resource access request is ignored.

8. A computer-readable storage medium having a computer program stored thereon, the computer program being executed by a processor to implement the steps of the access control method for a shared storage cluster according to any one of claims 1 to 7.

9. A computer program product comprising a computer program that, when executed by a processor, implements the steps of the access control method for a shared storage cluster as described in any one of claims 1 to 7.

10. A computer device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor, when executing the computer program, implements the steps of the access control method for a shared storage cluster according to any one of claims 1 to 7.

Images