An iSCSI cache synchronization method and system based on configuration version control

Abstract

The application relates to the technical field of Internet resource cooperation, and provides an iSCSI cache synchronization method based on configuration version control, which comprises the following steps: S1, constructing an iSCSI service deployment architecture, which comprises a global control node and a storage access node; S2, generating a Config-Version through the global control node, and issuing a configuration update event and a corresponding Config-Version to the storage access node by means of an asynchronous message notification mechanism; S3, the storage access node performs version reconciliation operation based on the configuration update event and the Config-Version, judges whether the local cache is consistent with the central configuration of the global control node, and if not, triggers configuration pulling to update the local cache; and S4, when the storage access node is started, accesses a new configuration or detects cache loss / expiry, starting a cache preheating mechanism, preloading corresponding iSCSI configuration information into the local cache, and completing iSCSI cache synchronization. The system architecture, configuration version control and message synchronization mechanism are improved and optimized in a systematic way.

Description

Technical Field

[0001] This invention relates to the technical field of Internet resource collaboration, and in particular to an iSCSI cache synchronization method and system based on configuration version control. Background Technology

[0002] A distributed storage system is a storage architecture that distributes storage resources across multiple nodes, enabling them to work collaboratively through network communication. With the development of information technology, distributed storage systems are widely used in enterprise data centers, private clouds, and public clouds. Compared to traditional centralized storage, distributed systems offer higher scalability, fault tolerance, and performance elasticity. In such systems, each node may undertake different responsibilities such as data storage, data access, and metadata management, thus placing higher demands on the consistency of various configuration information (such as LUN mappings and permission policies) within the system.

[0003] iSCSI (Internet Small Computer System Interface) is a standard protocol for transmitting SCSI commands over IP networks, widely used in enterprise-level storage systems to provide block device access capabilities. The iSCSI protocol operates through an initiator and target model, where the initiator is typically deployed on the host and the target on the storage device. The target manages access permissions for multiple initiators and maintains LUN mappings to ensure the security and correctness of data access. In traditional centralized storage systems, this configuration information is centrally managed by a controller, with updates taking effect immediately and providing strong consistency guarantees.

[0004] In modern distributed storage systems, the iSCSI Target service is typically deployed across multiple distributed nodes (often called Access Servers or iSCSI Servers), with each node maintaining its own cached Target configuration information (such as LUN configuration tables, Initiator whitelists, CHAP verification information, etc.). In this case, the system faces the following challenges: (1) Configuration synchronization delay issue: Changes to the central configuration need to be distributed to all service nodes asynchronously, which results in a synchronization delay; (2) Cache inconsistency problem: The cache status of each node may be out of sync, which can easily lead to inconsistent access control behavior; (3) Cold start performance issues: If there is no cache preheating mechanism after the node is first loaded or after a crash recovery, the iSCSI login process will be prolonged and the connection performance will be reduced; (4) Lack of version management mechanism: Existing systems mostly use simple means such as update markers and timestamps to judge the configuration status, which cannot accurately reconcile whether the cache status is up-to-date or whether there is a cache inconsistency.

[0005] While some systems have attempted to mitigate these issues by introducing event-triggered mechanisms and periodic synchronization tasks, these solutions typically struggle to guarantee cache consistency and response performance under high concurrency or complex access scenarios. For example, when an Initiator logs into node A, if its permission configuration has not yet been synchronized to A, even if the central configuration has been updated, it may lead to connection failure or unauthorized access. Furthermore, the lack of a unified configuration version number across multiple nodes makes it difficult to implement reliable reconciliation logic and rapid judgment.

[0006] Therefore, existing technologies still have significant shortcomings in handling the iSCSI target configuration cache consistency problem in distributed environments, and a new method is urgently needed that can ensure consistency while also considering performance and reliability. This invention is proposed against this background, providing an iSCSI cache synchronization method based on configuration version control, aiming to improve the consistency and stability of iSCSI services in distributed storage systems. Summary of the Invention

[0007] To address the aforementioned issues, the present invention aims to provide an iSCSI cache synchronization method and system based on configuration version control. Addressing typical problems encountered in the actual deployment of current distributed storage products, such as inconsistent iSCSI configuration cache synchronization, delayed change response, and performance jitter during the login phase, the invention proposes a more universal and practical technical solution. It systematically improves and optimizes the system architecture, configuration version control, and message synchronization mechanism.

[0008] The above-mentioned objective of this invention is achieved through the following technical solutions: A configuration version control-based iSCSI cache synchronization method includes the following steps: S1: Construct an iSCSI service deployment architecture for a distributed storage system. The architecture includes a global control node and at least two storage access nodes, where each storage access node is an Access Server node, i.e., an iSCSI Server. S2: The global control node generates a configuration version number (Config-Version) and, using an asynchronous message notification mechanism, sends configuration update events and the corresponding Config-Version to each storage access node. S3: Each storage access node, based on the received configuration update event and Config-Version, performs a version reconciliation operation using a version control mechanism to determine if its local cache is consistent with the central configuration of the global control node. If inconsistent, it triggers configuration retrieval to update the local cache. S4: When a storage access node starts up, receives a new configuration, or detects a missing / expired cache, it initiates a cache preheating mechanism to preload the corresponding iSCSI configuration information into the local cache, completing iSCSI cache synchronization.

[0009] Furthermore, in step S1, the functions of the global control node and the storage access node are specifically as follows: The global control node is responsible for metadata management services, specifically including: The system maintains the configuration information of all iSCSI Targets, LUNs, Hosts, and Initiators; it interfaces with the cluster control plane, which includes a management platform and an API Server, to receive configuration update requests from the cluster control plane; it generates and allocates configuration version numbers (Config-Version) to identify the status of configuration information; it distributes configuration information and update notifications to downstream AccessServer nodes; it provides a configuration retrieval interface to support each storage access node in actively querying configurations as needed; the global control node acts as a configuration center and consistency anchor in the entire architecture; the storage access node, as a server component of the iSCSI Target, specifically includes: exposing iSCSI... The Target interface maintains the link and data path with the Initiator. Each storage access node has the following responsibilities: receiving Initiator login requests and determining their access permissions based on the local cache; maintaining the permission configuration cache of Target and LUN locally, including: the binding relationship between Target and Host; the Initiator whitelist including IQN and IP; the mapping relationship between LUN and Host / Target; responding to configuration update notifications from the global control node and deciding whether to refresh the local cache based on version information; actively performing configuration preheating when the node starts or accesses configuration to improve access response performance; having the ability to actively pull back to the origin in abnormal situations, including version reconciliation failure and configuration loss; Access Server nodes are independent of each other and do not share caches, but need to ensure consistency with the central configuration.

[0010] Furthermore, in step S2, using an asynchronous message notification mechanism, the configuration update event and the corresponding Config-Version are sent to each of the storage access nodes, specifically as follows: S21: When a user or management platform submits a configuration change request through the API Server, the global control node persists the modified target configuration to the database and updates the configuration version number Config-Version corresponding to the target configuration. The configuration change request includes changes such as modifying the initiator of any Host, modifying binding relationships, and modifying LUN mappings. S22: The global control node encapsulates the configuration change event into a notification message. The notification message includes the change object type and identifier, the latest configuration version number Config-Version, and the content of the change. The change object type and identifier includes information such as target_id and host_id. The content of the change includes information such as whether it involves changes to the client host group, whether it results in permission changes, and whether it requires a forced rebuild of the Target resource. S23: The notification message is sent to all the storage access nodes through an asynchronous message channel, which is a heartbeat message between the global control node and the storage access nodes. S24: After receiving the notification, the storage access node determines whether the local cache has hit the relevant configuration and verifies the version status of the Target object.

[0011] Further, in step S3, a version reconciliation operation is performed based on the version control mechanism to determine whether the local cache is consistent with the central configuration of the global control node. If they are inconsistent, a configuration fetch is triggered to update the local cache, specifically: S31: Version generation strategy. When any configuration object undergoes changes, including additions, deletions, and modifications, the global control node will assign it a new configuration version number, Config-Version. This value is a globally unique, monotonically increasing unsigned integer generated by the global control node. S32: Record node version. When the storage access node pulls the configuration, it records the locally cached configuration object and its corresponding configuration version number Config-Version based on the version control mechanism as the basis for subsequent judgment. The configuration object includes Host and Target. The LUN belongs to the Target resource and shares the same configuration version number Config-Version with the Target. S33: Trigger version reconciliation based on the version control mechanism. The triggering time for version reconciliation includes: the storage access node performing version comparison after receiving a notification message, the Initiator discovering that the target configuration item is not loaded or the version is abnormal when logging in, and performing batch reconciliation during scheduled health checks. When the session between the storage access node and the global control node is established and when the message notification verification version is inconsistent; S34: Execute reconciliation logic based on the version control mechanism. If the configuration version number Config-Version in the local cache is consistent with the target Config-Version in the global control node, no operation is performed; if the Config-Version in the local cache is lagging behind the target Config-Version, the storage access node enters the waiting state, triggers configuration refresh, and pulls the latest Target and Host resources from the global control node; if the Config-Version in the local cache is higher than the target Config-Version, an alarm or rollback strategy is triggered.

[0012] Furthermore, in step S4, the cache preheating mechanism includes an active preheating strategy, specifically: S411: When a storage access node starts up or joins a certain iSCSI Target configuration range, the storage access node immediately initiates a configuration pull request to the global control node. Scenarios for the storage access node joining the iSCSI Target configuration range include initial deployment and configuration allocation changes. S412: After receiving the configuration pull request, the global control node feeds back the Host configuration information, LUN configuration information, Initiator whitelist information, and the latest Config-Version related to the iSCSI Target to the storage access node. S413: The storage access node receives the feedback information and synchronously updates its local cache. S414: In the case of a cold start for the storage access node, a parallel pull and asynchronous initialization mechanism is adopted to accelerate the speed at which the storage access node enters the service state.

[0013] Furthermore, in step S4, the cache preheating mechanism includes an event-driven preheating strategy, specifically: S421: Monitor the running status of the storage access node in real time. When the storage access node receives a configuration change notification or discovers a cache missing or expired cache during version reconciliation based on the version control mechanism, determine that there is an inconsistency between the configuration of the storage access node and the global control node. S422: The storage access node triggers a configuration pull operation to request the latest iSCSI configuration information and the corresponding Config-Version from the global control node. S423: If the Initiator initiates a login request while the storage access node's cache is not hit, process the login request according to a preset deployment strategy. The processing methods include triggering configuration pull first and then responding to the login request, rejecting the login request and waiting for the cache to warm up before prompting the Initiator to retry. The processing is flexible according to the deployment strategy.

[0014] Furthermore, the iSCSI cache synchronization method based on configuration version control also includes: In step S2, the generation rule of the Config-Version is determined based on the version control mechanism as follows: when the content of the configuration object changes, the global control node assigns a new Config-Version to the configuration object. The changes in the content of the configuration object include adding, deleting, and modifying the configuration object. The Config-Version is a globally unique monotonically increasing unsigned integer. In step S3, each storage access node is independent of the others and does not share caches. It only needs to rely on the version control mechanism to ensure that it is consistent with the central configuration of the global control node. In step S4, the cache preheating mechanism can alleviate Initiator login jitter, reduce cache voids, and improve the overall system response performance. The relief of login jitter is achieved by preloading access permission data, and the reduction of cache voids is to reduce the first access failure caused by service restart or node addition.

[0015] A configuration-version-based iSCSI cache synchronization system for performing the configuration-version-based iSCSI cache synchronization method as described above, comprising: The iSCSI service architecture construction module builds the iSCSI service deployment architecture of the distributed storage system. This architecture includes a global control node and at least two storage access nodes, each of which is an Access Server node, i.e., an iSCSI Server. The version generation and message delivery module generates a configuration version number (Config-Version) through the global control node and, using an asynchronous message notification mechanism, sends configuration update events and the corresponding Config-Version to each storage access node. The version reconciliation and cache update module performs version reconciliation operations on each storage access node based on the received configuration update event and Config-Version, relying on a version control mechanism to determine if the local cache is consistent with the central configuration of the global control node. If inconsistent, it triggers configuration retrieval to update the local cache. The iSCSI configuration cache preheating module initiates a cache preheating mechanism when a storage access node starts up, receives a new configuration, or detects a missing / expired cache, preloading the corresponding iSCSI configuration information into the local cache to complete iSCSI cache synchronization.

[0016] A computer device includes a memory and one or more processors, the memory storing computer code that, when executed by the one or more processors, causes the one or more processors to perform the method described above.

[0017] A computer-readable storage medium storing computer code that, when executed, performs the method described above.

[0018] Compared with the prior art, the present invention has at least one of the following beneficial effects: (1) Solve core technical pain points and ensure configuration consistency: By introducing a configuration version control mechanism, a globally unique Config-Version identifier is assigned to iSCSI configurations (such as Target, Host, LUN). Access Server nodes can accurately determine whether the local cache and the central configuration are consistent by using version reconciliation. With the on-demand retrieval and automatic cache refresh mechanism, when a node finds that the local configuration version is lagging, missing, or the service is starting, it can actively pull the latest configuration update cache from the control node, effectively solving the problem of inconsistent iSCSI service configuration cache synchronization in the distributed storage system and avoiding risks such as access failure and unauthorized access caused by configuration deviation.

[0019] (2) Improve system response performance and optimize access experience: Relying on the pre-login cache warm-up mechanism, the node automatically loads relevant permission information such as Host, LUN, and Initiator whitelist when initializing or accessing new configurations, avoiding remote querying when the Initiator logs in, significantly reducing login latency and alleviating login jitter; at the same time, it reduces cache gaps caused by service restarts or new nodes, reduces the probability of first access failure, improves system connection success rate and overall response performance, and ensures service experience stability.

[0020] (3) Reduce system load and enhance operational stability: Compared with the traditional periodic polling or single-point pull method, this method transmits configuration update events through an asynchronous notification mechanism. The node only needs to decide whether to refresh the cache based on the version comparison result, avoiding redundant full synchronization operations, reducing invalid data interaction between the control node and the storage access node, and reducing the overall system load. In addition, in the case of configuration anomalies or loss, the node has the ability to actively retrieve the latest configuration to fix the problem, which significantly enhances the system's self-recovery capability and operational robustness.

[0021] (4) Adaptable to diverse deployment needs and has good versatility: By designing the consistency granularity based on iSCSI Target, the configuration synchronization and consistency maintenance unit is refined to the Target level, which can accurately control the cache range and adapt to the resource isolation requirements in multi-tenant scenarios. At the same time, the solution is not limited to specific distributed storage systems and can be applied to other similar distributed block storage environments, taking into account deployment efficiency, resource utilization and horizontal scaling capabilities, and has good engineering versatility and practical application value. Attached Figure Description

[0022] Figure 1 This is an overall flowchart of the iSCSI cache synchronization method based on configuration version control of the present invention; Figure 2 This is a schematic diagram of the deployment architecture of iSCSI service in a distributed storage system according to the present invention; Figure 3 This is a schematic diagram of the version control mechanism of the present invention; Figure 4 This is a schematic diagram of the corresponding ISCSI Target state machine introduced by the present invention based on version control; Figure 5 This is a diagram illustrating the overall structure of the iSCSI cache synchronization system based on configuration version control according to the present invention. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0024] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in this specification means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0025] This invention ensures consistency between the cache of each iSCSI Server node and the central configuration by introducing a configuration version identifier and reconciliation mechanism. Simultaneously, it improves system response performance and maintainability through asynchronous message notification mechanisms and pre-login cache warm-up methods. This solution not only addresses key pain points in current product practices but also possesses good versatility, making it applicable to other similar distributed block storage systems.

[0026] This invention effectively solves problems such as inconsistent iSCSI service configuration cache synchronization, high access latency, and poor system robustness in distributed storage systems by introducing mechanisms such as configuration version control, asynchronous notification, and cache preheating. Compared with traditional methods that rely on periodic polling or single-point fetching, this invention provides a lightweight, accurate, and efficient configuration synchronization method: by assigning a globally unique configuration version number to each target configuration object, it achieves accurate reconciliation and status awareness between storage access nodes and control nodes, thereby ensuring that cached content is always consistent with the central configuration. In configuration change scenarios, nodes can promptly learn of update events through asynchronous notification mechanisms and decide whether to refresh the cache based on version comparison results, avoiding redundant operations and reducing the pressure on control nodes. During service startup or access, nodes can proactively perform cache preheating, thereby avoiding Initiator login failures due to missing configurations or loading delays, effectively improving the system's connection success rate and response performance. Simultaneously, in scenarios such as configuration anomalies or loss, nodes have the ability to retrieve the latest configuration for repair, significantly enhancing the system's self-recovery capability and availability. Overall, this invention ensures system consistency and stability while also taking into account deployment efficiency, resource utilization, and horizontal scalability. It has good engineering versatility and practical application value, and is suitable for distributed storage environments under various protocol forms.

[0027] The following is an illustration through specific examples: First Embodiment like Figure 1 As shown, this embodiment provides an iSCSI cache synchronization method based on configuration version control, including the following steps: S1: Construct an iSCSI service deployment architecture for a distributed storage system. The architecture includes a global control node and at least two storage access nodes, where the storage access nodes are Access Server nodes, i.e., iSCSI Servers.

[0028] In this embodiment, as Figure 2 As shown, this invention provides a deployment architecture for iSCSI services in a distributed storage system. This architecture mainly consists of a global control node and the storage access node. The functions of the global control node and the storage access node are specifically as follows: The global control node is responsible for metadata management services, specifically including: The system maintains the configuration information of all iSCSI Targets, LUNs, Hosts, and Initiators; it interfaces with the cluster control plane, which includes a management platform and an API Server, to receive configuration update requests from the cluster control plane; it generates and allocates configuration version numbers (Config-Version) to identify the status of configuration information; it distributes configuration information and update notifications to downstream AccessServer nodes; it provides a configuration retrieval interface to support each storage access node in actively querying configurations as needed; the global control node acts as a configuration center and consistency anchor in the entire architecture; the storage access node, as a server component of the iSCSI Target, specifically includes: exposing iSCSI... The Target interface maintains the link and data path with the Initiator. Each storage access node has the following responsibilities: receiving Initiator login requests and determining their access permissions based on the local cache; maintaining the permission configuration cache of Target and LUN locally, including: the binding relationship between Target and Host; the Initiator whitelist including IQN and IP; the mapping relationship between LUN and Host / Target; responding to configuration update notifications from the global control node and deciding whether to refresh the local cache based on version information; actively performing configuration preheating when the node starts or accesses configuration to improve access response performance; having the ability to actively pull back to the origin in abnormal situations, including version reconciliation failure and configuration loss; Access Server nodes are independent of each other and do not share caches, but need to ensure consistency with the central configuration.

[0029] Based on the above storage node architecture, this invention proposes a version-controlled cache consistency model. The core idea of ​​this model is as follows: the global control node explicitly configures a version identifier (Config-Version) for each iSCSI Target. The Target Config-Version from the configuration center is propagated between the global control node and the storage access nodes via an asynchronous message notification mechanism. The storage access nodes perform version reconciliation to ensure cache consistency with the Target resources in the configuration center. A demand-based retrieval strategy enables rapid correction and efficient cache preheating. This model effectively improves the synchronization efficiency and consistency guarantee capability of iSCSI configuration in distributed storage systems, providing technical support for high availability and data access correctness.

[0030] Based on the above architecture, this invention proposes three key mechanisms: a message notification mechanism, a version control mechanism, and a cache preheating mechanism. These three mechanisms work together to form a complete iSCSI configuration cache consistency guarantee method. These are the contents of steps S2-S4 respectively. S2: The global control node generates a configuration version number Config-Version, and using an asynchronous message notification mechanism, sends the configuration update event and the corresponding Config-Version to each of the storage access nodes.

[0031] Message notification mechanism: This mechanism ensures that after the global control node detects a configuration change, it promptly and accurately notifies all affected storage access nodes of the relevant update event, preventing nodes from being in a state of configuration lag. The workflow includes: S21: When a user or management platform submits a configuration change request through the API Server, the global control node persists the modified target configuration to the database and updates the configuration version number Config-Version corresponding to the target configuration. The configuration change request includes changes such as modifying the initiator of any Host, modifying binding relationships, and modifying LUN mappings. S22: The global control node encapsulates the configuration change event into a notification message. The notification message includes the change object type and identifier, the latest configuration version number Config-Version, and the content of the change. The change object type and identifier includes information such as target_id and host_id. The content of the change includes information such as whether it involves changes to the client host group, whether it results in permission changes, and whether it requires a forced rebuild of the Target resource. S23: The notification message is sent to all the storage access nodes through an asynchronous message channel, which is a heartbeat message between the global control node and the storage access nodes. S24: After receiving the notification, the storage access node determines whether the local cache has hit the relevant configuration and verifies the version status of the Target object.

[0032] This mechanism ensures that configuration updates can be quickly and lightweightly delivered to relevant nodes, avoiding the load caused by frequent polling and reducing invalid configuration synchronization operations between nodes. S3: Each storage access node, based on the received configuration update event and Config-Version, performs a version reconciliation operation using the version control mechanism to determine whether the local cache is consistent with the central configuration of the global control node. If they are inconsistent, a configuration pull is triggered to update the local cache.

[0033] The core is Figure 3 Version control mechanism: The version control mechanism is the core mechanism for achieving cache consistency. Each cacheable configuration object (such as Host, Target, LUN belongs to the Target resource, therefore the Target resource itself and associated LUNs of the same Target share the Target's unique configuration version number) is associated with a configuration version number Config-Version to identify its current iteration state. Key points include: S31: Version generation strategy. When any configuration object undergoes changes, including additions, deletions, and modifications, the global control node will assign it a new configuration version number, Config-Version. This value is a globally unique, monotonically increasing unsigned integer generated by the global control node. S32: Record node version. When the storage access node pulls the configuration, it records the locally cached configuration object and its corresponding configuration version number Config-Version based on the version control mechanism as the basis for subsequent judgment. The configuration object includes Host and Target. The LUN belongs to the Target resource and shares the same configuration version number Config-Version with the Target. S33: Trigger version reconciliation based on the version control mechanism. The triggering time for version reconciliation includes: the storage access node performing version comparison after receiving a notification message, the Initiator discovering that the target configuration item is not loaded or the version is abnormal when logging in, and performing batch reconciliation during scheduled health checks. The scheduled health check occurs when the storage access node receives a notification message and performs version comparison; the storage access node discovers that the target configuration item is not loaded or the version is abnormal when logging in; and the storage access node performs batch reconciliation during scheduled health checks. When the session between the storage access node and the global control node is established and when the message notification verification version is inconsistent; S34: Execute reconciliation logic based on the version control mechanism. If the configuration version number Config-Version in the local cache is consistent with the target Config-Version in the global control node, no operation is performed; if the Config-Version in the local cache is lagging behind the target Config-Version, the storage access node enters the waiting state, triggers configuration refresh, and pulls the latest Target and Host resources from the global control node; if the Config-Version in the local cache is higher than the target Config-Version (which should not happen in theory), an alarm or rollback strategy is triggered.

[0034] With clear version identification and reconciliation rules, nodes can determine the validity of configurations at minimal cost, avoiding unnecessary full synchronization and improving system stability and consistency. S4: When the storage access node starts up, accesses a new configuration, or detects a missing / expired cache, a cache preheating mechanism is initiated to preload the corresponding iSCSI configuration information into the local cache, completing iSCSI cache synchronization.

[0035] like Figure 4 As shown, this is the corresponding ISCSI Target state machine introduced according to version control. The state machine, together with version control and cache preheating, achieves efficient cache synchronization.

[0036] Cache preheating mechanism: The cache preheating mechanism of the storage access node is used to improve the response performance of the Access Server node during configuration switching, service startup or target access process, and reduce the latency during Initiator login.

[0037] There are two main types of preheating strategies: (1) The cache preheating mechanism includes an active preheating strategy (preheating process), specifically: S411: When a storage access node starts up or joins a certain iSCSI Target configuration range, the storage access node immediately initiates a configuration pull request to the global control node. Scenarios for the storage access node joining the iSCSI Target configuration range include initial deployment and configuration allocation changes. S412: After receiving the configuration pull request, the global control node feeds back the Host configuration information, LUN configuration information, Initiator whitelist information, and the latest Config-Version related to the iSCSI Target to the storage access node. S413: The storage access node receives the feedback information and synchronously updates its local cache. S414: In the case of a cold start for the storage access node, a parallel pull and asynchronous initialization mechanism is adopted to accelerate the speed at which the storage access node enters the service state.

[0038] (2) The cache preheating mechanism includes an event-driven preheating strategy (fetch process), specifically: S421: Monitor the running status of the storage access node in real time. When the storage access node receives a configuration change notification or discovers a cache missing or expired cache during version reconciliation based on the version control mechanism, determine that there is an inconsistency between the configuration of the storage access node and the global control node. S422: The storage access node triggers a configuration pull operation to request the latest iSCSI configuration information and the corresponding Config-Version from the global control node. S423: If the Initiator initiates a login request while the storage access node's cache is not hit, process the login request according to a preset deployment strategy. The processing methods include triggering configuration pull first and then responding to the login request, rejecting the login request and waiting for the cache to warm up before prompting the Initiator to retry. The processing is flexible according to the deployment strategy.

[0039] In addition, the preheating mechanism has the following advantages: (1) Mitigating login jitter: Preload access permission data to avoid delayed retrieval during the login process; (2) Reduce cache voids: Reduce first-access failures caused by service restarts or new node additions; (3) Improve the overall system response performance and user experience stability.

[0040] Second Embodiment like Figure 5 As shown, this embodiment provides a configuration-version-controlled iSCSI cache synchronization system for executing the configuration-version-controlled iSCSI cache synchronization method as described in the first embodiment, comprising: iSCSI service architecture construction module 1 constructs the iSCSI service deployment architecture of the distributed storage system. The architecture includes a global control node and at least two storage access nodes, where the storage access nodes are Access Server nodes, i.e., iSCSI Servers. Version generation and message delivery module 2 generates a configuration version number Config-Version through the global control node and sends the configuration update event and the corresponding Config-Version to each of the storage access nodes using an asynchronous message notification mechanism. Version reconciliation and cache update module 3 performs version reconciliation operations on each of the storage access nodes based on the received configuration update event and Config-Version, relying on the version control mechanism to determine whether the local cache is consistent with the central configuration of the global control node. If they are inconsistent, configuration retrieval is triggered to update the local cache. iSCSI configuration cache preheating module 4 starts the cache preheating mechanism when a storage access node starts up, accesses a new configuration, or detects a missing / expired cache, preloading the corresponding iSCSI configuration information to the local cache to complete iSCSI cache synchronization.

[0041] A computer-readable storage medium stores computer code that, when executed, performs the methods described above. Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing related hardware. This program can be stored in a computer-readable storage medium, which may include: read-only memory (ROM), random access memory (RAM), a magnetic disk, or an optical disk, etc.

[0042] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

[0043] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0044] It should be noted that the above embodiments can be freely combined as needed. The above description is only a preferred embodiment of the present invention. It should be pointed out that for those skilled in the art, several improvements and modifications can be made without departing from the principle of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A method for synchronizing iSCSI cache based on configuration version control, characterized in that, Includes the following steps: S1: Construct an iSCSI service deployment architecture for a distributed storage system. The architecture includes a global control node and at least two storage access nodes, where the storage access nodes are Access Server nodes, i.e., iSCSI Servers. S2: Generate a configuration version number Config-Version through the global control node, and send the configuration update event and the corresponding Config-Version to each of the storage access nodes using an asynchronous message notification mechanism; S3: Each storage access node performs a version reconciliation operation based on the received configuration update event and Config-Version, relying on the version control mechanism, to determine whether the local cache is consistent with the central configuration of the global control node. If they are inconsistent, the configuration is pulled to update the local cache. S4: When the storage access node starts up, accesses a new configuration, or detects a missing / expired cache, start the cache preheating mechanism to preload the corresponding iSCSI configuration information to the local cache and complete the iSCSI cache synchronization.

2. The iSCSI cache synchronization method based on configuration version control according to claim 1, characterized in that, In step S1, the functions of the global control node and the storage access node are specifically as follows: The global control node is responsible for metadata management services, specifically including: The system maintains the configuration information of all iSCSI Targets, LUNs, Hosts, and Initiators; it interfaces with the cluster control plane, which includes a management platform and an API Server, to receive configuration update requests from the cluster control plane; it generates and allocates configuration version numbers (Config-Version) to identify the status of configuration information; it distributes configuration information and update notifications to downstream Access Server nodes; it provides a configuration retrieval interface to support each storage access node in actively querying configurations as needed; the global control node acts as a configuration center and consistency anchor in the entire architecture. The storage access node, as a server component of the iSCSI Target, specifically includes: The iSCSI Target interface is exposed externally, and the connection and data path with the Initiator are maintained. Each storage access node has the following responsibilities: receiving Initiator login requests and determining their access permissions based on the local cache; maintaining the permission configuration cache of Target and LUN locally, including: the binding relationship between Target and Host; the Initiator whitelist including IQN and IP; the mapping relationship between LUN and Host / Target; responding to configuration update notifications from the global control node and deciding whether to refresh the local cache based on the version information; actively performing configuration preheating when the node starts up or accesses the configuration to improve access response performance; having the ability to actively pull back to the origin in abnormal situations, including version reconciliation failure and configuration loss; Access Server nodes are independent of each other and do not share caches, but need to ensure consistency with the central configuration.

3. The iSCSI cache synchronization method based on configuration version control according to claim 1, characterized in that, In step S2, the configuration update event and the corresponding Config-Version are sent to each of the storage access nodes using an asynchronous message notification mechanism, specifically: S21: When a user or management platform submits a configuration change request through the API Server, the global control node persists the modified target configuration to the database and updates the configuration version number Config-Version corresponding to the target configuration. The configuration change request includes changes such as modifying the initiator of any Host, modifying binding relationships, and modifying LUN mappings. S22: The global control node encapsulates the configuration change event into a notification message. The notification message includes the change object type and identifier, the latest configuration version number Config-Version, and the content of the change. The change object type and identifier include information such as target_id and host_id. The content of the change includes information such as whether it involves changes to the client host group, whether it causes permission changes, and whether it is necessary to forcibly rebuild the Target resource. S23: Send a notification message to all the storage access nodes through an asynchronous message channel, wherein the asynchronous message channel is a heartbeat message of the Session between the global control node and the storage access node; S24: After receiving the notification, the storage access node determines whether the local cache has hit the relevant configuration and verifies the version status of the Target object.

4. The iSCSI cache synchronization method based on configuration version control according to claim 1, characterized in that, In step S3, a version reconciliation operation is performed based on the version control mechanism to determine whether the local cache is consistent with the central configuration of the global control node. If they are inconsistent, a configuration fetch is triggered to update the local cache. Specifically: S31: Version generation strategy. When any configuration object undergoes changes, including additions, deletions, and modifications, the global control node will assign a new configuration version number Config-Version. The newly assigned configuration version number Config-Version is a globally unique monotonically increasing unsigned integer generated by the global control node. S32: Perform node version recording. When the storage access node pulls the configuration, it records the local cached configuration object and its corresponding configuration version number Config-Version based on the version control mechanism as the basis for subsequent judgment. The configuration object includes Host and Target. The LUN belongs to the Target resource and shares the same configuration version number Config-Version with the Target. S33: Relying on the version control mechanism to trigger version reconciliation behavior, the triggering time of the version reconciliation behavior includes: the storage access node performs version comparison after receiving the notification message, the Initiator finds that the target configuration item is not loaded or the version is abnormal when logging in, and the batch reconciliation is performed in the scheduled health check. The scheduled health check occurs when the session between the storage access node and the global control node is established and when the message notification checks the version inconsistency. S34: Execute reconciliation logic based on version control mechanism. If the configuration version number Config-Version in the local cache is consistent with the target Config-Version in the global control node, no operation is performed. If the Config-Version in the local cache lags behind the target Config-Version, the storage access node enters the waiting state, triggers configuration refresh, and pulls the latest Target and Host resources from the global control node. If the Config-Version in the local cache is higher than the target Config-Version, an alarm or rollback strategy is triggered.

5. The iSCSI cache synchronization method based on configuration version control according to claim 1, characterized in that, In step S4, the cache preheating mechanism includes an active preheating strategy, specifically: S411: When a storage access node starts up or joins a certain iSCSI Target configuration range, the storage access node immediately initiates a configuration pull request to the global control node. The scenarios in which the storage access node joins the iSCSI Target configuration range include initial deployment and configuration allocation changes. S412: After receiving the configuration pull request, the global control node feeds back the Host configuration information, LUN configuration information, Initiator whitelist information and the latest Config-Version related to the iSCSI Target to the storage access node; S413: The storage access node receives feedback information and synchronously updates its local cache; S414: In the scenario of cold start of storage access node, a parallel fetching and asynchronous initialization mechanism is adopted to speed up the speed at which storage access node enters the service state.

6. The iSCSI cache synchronization method based on configuration version control according to claim 1, characterized in that, In step S4, the cache preheating mechanism includes an event-driven preheating strategy, specifically: S421: Monitor the running status of the storage access node in real time. When the storage access node receives a configuration change notification or discovers cache missing or cache expired during version reconciliation based on the version control mechanism, determine that there is an inconsistency between the configuration of the storage access node and the global control node. S422: The storage access node triggers a configuration pull operation, requesting the latest iSCSI configuration information and the corresponding Config-Version from the global control node; S423: If the Initiator initiates a login request while the storage access node cache is not hit, the login request is processed according to the preset deployment strategy. The processing of the login request includes triggering configuration retrieval first and then responding to the login request, rejecting the login request and waiting for the cache to warm up before prompting the Initiator to retry, and flexibly processing according to the deployment strategy.

7. The iSCSI cache synchronization method based on configuration version control according to claim 1, characterized in that, Also includes: In step S2, the generation rule of the Config-Version is determined based on the version control mechanism as follows: when the content of the configuration object changes, the global control node assigns a new Config-Version to the configuration object. The changes in the content of the configuration object include adding, deleting, and modifying the configuration object. The Config-Version is a globally unique monotonically increasing unsigned integer. In step S3, each storage access node is independent of the others and does not share caches. It only needs to rely on the version control mechanism to ensure that it is consistent with the central configuration of the global control node. In step S4, the cache preheating mechanism can alleviate Initiator login jitter, reduce cache voids, and improve the overall system response performance. The initiator login jitter is alleviated by preloading access permission data, and the cache voids are reduced by minimizing first access failures caused by service restarts or new node additions.

8. A configuration-version-controlled iSCSI cache synchronization system for executing the configuration-version-controlled iSCSI cache synchronization method as described in any one of claims 1-7, characterized in that, include: The iSCSI service architecture building module constructs the iSCSI service deployment architecture of the distributed storage system. The architecture includes a global control node and at least two storage access nodes, which are Access Server nodes, i.e., iSCSIServers. The version generation and message delivery module generates a configuration version number Config-Version through the global control node, and sends the configuration update event and the corresponding Config-Version to each of the storage access nodes through an asynchronous message notification mechanism. The version reconciliation and cache update module, each of the storage access nodes performs version reconciliation operations based on the received configuration update event and Config-Version, relying on the version control mechanism, to determine whether the local cache is consistent with the central configuration of the global control node. If they are inconsistent, the configuration is pulled to update the local cache. The iSCSI configuration cache preheating module starts the cache preheating mechanism when the storage access node starts up, accesses a new configuration, or detects a cache missing / expired cache. It preloads the corresponding iSCSI configuration information into the local cache to complete iSCSI cache synchronization.

9. A computer device comprising a memory and one or more processors, the memory storing computer code that, when executed by the one or more processors, causes the one or more processors to perform the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing computer code, wherein when the computer code is executed, the method of any one of claims 1 to 7 is performed.

Images