A multi-host management system and control method

Abstract

The application discloses a multi-host management system and a control method, relates to the technical field of computer storage, and solves the problems of possible simultaneous writing of an original host and a second host after host exception and misuse of incomplete submission records by revoking the access relationship of an abnormal host first and then determining the takeover by the second host or the recoverable position according to the consistency check of the management page and the submission log page in the persistent memory section. The multi-host management system comprises a management device, a plurality of hosts, a first driving device, a second driving device, an access control device and a persistent memory pool device. The management device is connected with the hosts, the access control device and the persistent memory pool device respectively. The access control device is arranged on an access path between the hosts and the persistent memory pool device. The first driving device is arranged in a first host of the plurality of hosts, and the second driving device is arranged in a second host of the plurality of hosts.

Description

Technical Field

[0001] This application relates to the field of computer storage technology, and in particular to a multi-host management system and control method. Background Technology

[0002] With the development of persistent memory and high-speed interconnect technologies, persistent memory combines memory-level access speed with the characteristic of data retention after power failure, making it suitable for storing database logs, checkpoint data, and other data requiring rapid recovery. Meanwhile, high-speed interconnect technologies, such as Compute Express Link (CXL), enable multiple hosts to access remote memory devices through switching devices and organize multiple memory devices into a unified memory pool. When persistent memory is included in the memory pool, multiple hosts can share the storage resources within the same persistent memory pool, thereby improving memory utilization and reducing system costs.

[0003] In persistent memory pooling applications, persistent memory pools are typically divided into multiple persistent memory segments, which are allocated to different hosts by a pooling management service. Existing memory pooling solutions focus more on shared access to memory resources and address forwarding, and their management objects are mainly volatile memory. They do not address the ownership confirmation and access relationship revocation of persistent memory segments after host failure. Furthermore, existing persistent memory management solutions focus more on data caching, log recording, or underlying storage writing, and their persistent memory is usually used as a buffer space within a single host, without addressing segment lease management when multiple hosts share the same persistent memory pool. Summary of the Invention

[0004] This application provides a multi-host management system and control method to at least solve the problems that, in persistent memory pooling scenarios, persistent memory segments may be repeatedly accessed by the original host and the recovered host after the host heartbeat is interrupted, restarted, or the access link is disconnected, and it is difficult to confirm the last valid commit position of the segment.

[0005] This application provides a multi-host management system, which includes: a management device, multiple hosts, a first driving device, a second driving device, an access control device, and a persistent memory pool device. The management device is connected to the hosts, the access control device, and the persistent memory pool device. The access control device is located on the access path between the hosts and the persistent memory pool device. The first driving device is located in a first host of the multiple hosts, and the second driving device is located in a second host of the multiple hosts. The persistent memory pool device includes multiple persistent memory segments, each persistent memory segment including a management page and a commit log page. The management device is used to allocate persistent memory to the first hosts. The system writes lease information to the management page and establishes an access relationship between the first host and the persistent memory segment through the access control device. The first driving device writes write commit records to the commit log page while the first host is using the persistent memory segment. The management device is also used to revoke the access relationship of the first host when an anomaly is detected, and then read the management page and commit log page of the persistent memory segment. If the most recent commit sequence number matches the most recent valid commit record in the commit log page, the persistent memory segment is handed over to the second host for takeover. If they do not match, the persistent memory segment remains unallocatable, and the recoverable location is determined according to the previous valid commit record.

[0006] This application also provides a control method for a multi-host management system, comprising: dividing a persistent memory pool into multiple persistent memory segments, each persistent memory segment including a management page and a commit log page; when allocating a persistent memory segment to a first host, generating lease information and writing the lease information to the management page of the persistent memory segment, establishing an access relationship between the first host and the persistent memory segment through an access control device, so that the first host writes commit records to the commit log page of the persistent memory segment during the use of the persistent memory segment; when an anomaly of the first host is detected, firstly revoking the access relationship of the first host, and then reading the management page and commit log page of the persistent memory segment; if the most recent commit sequence number in the management page is consistent with the most recent valid commit record in the commit log page, then the persistent memory segment is handed over to the second host for takeover; if they are inconsistent, the persistent memory segment remains unallocable, and a recoverable location is determined based on the previous valid commit record in the commit log page.

[0007] In this application, the multi-host management system achieves secure takeover and consistent recovery of persistent memory segments after host failure through the coordinated operation of the management device, driver device, and access control device. The multi-host management system first writes lease information to the management page when allocating a persistent memory segment to the first host, and establishes the first host's access relationship to the persistent memory segment through the access control device. During the first host's use of the persistent memory segment, the driver device writes write commit records to the commit log page. When a first host failure is detected, the management device first revokes the first host's access relationship, then reads the management page and commit log page of the persistent memory segment. If the most recent commit sequence number matches the most recent valid commit record in the commit log page, the persistent memory segment is handed over to the second host for takeover, thus preventing the original host and the second host from simultaneously writing to the same persistent memory segment. If they do not match, the persistent memory segment remains unallocable, and the recoverable location is determined according to the previous valid commit record, thus preventing incompletely written records from being used as valid data. This enables the system to effectively avoid the risk of duplicate writes caused by the failure of old access relationships after a host failure, and to accurately determine the recoverable location when records within a segment are inconsistent. Thus, it achieves accurate and reliable fault takeover and data recovery under the complex conditions of multiple hosts sharing a persistent memory pool. Attached Figure Description

[0008] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0009] Figure 1 A schematic diagram of a multi-host management system provided in an embodiment of this disclosure; Figure 2 A schematic diagram of another multi-host management system provided in an embodiment of this disclosure; Figure 3 A schematic diagram of a multi-host management system provided in this embodiment of the present disclosure; Figure 4 A flowchart illustrating a multi-host management system control method provided in this embodiment of the disclosure.

[0010] The above-mentioned figures include the following reference numerals: 1, management device; 2, multiple hosts; 21, first host; 22, second host; 23, third host; 3, first drive device; 4, second drive device; 5, third drive device; 6, access control device; 7, persistent memory pool device; 8, pooled index device; 9, high-speed interconnect switching device; 100, multi-host management system. Detailed Implementation

[0011] 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, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0012] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0013] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0014] In persistent memory pooling applications, persistent memory pools are typically divided into multiple persistent memory segments, which are allocated to different hosts by a pooling management service. Unlike ordinary volatile memory, data in persistent memory is retained after a host loses power or restarts. Therefore, during persistent memory segment allocation, host switching, and fault recovery, it is necessary not only to handle the transfer of access permissions but also to confirm the ownership of the original data and the last valid write location. When the original host experiences a heartbeat interruption, restart, or access link disconnection, the pooling management service needs to determine whether the persistent memory segment occupied by that host can be taken over by another host, and where to continue processing data after takeover.

[0015] Existing memory pooling solutions focus primarily on shared access and address forwarding of memory resources, mainly managing volatile memory. They do not address the ownership confirmation and access revocation of persistent memory segments after host failure. When the original host's heartbeat is interrupted, restarted, or access link is broken, if the management server does not revoke the original host's access to the persistent memory segment first, the original host may continue writing to the old address after coming back online. Meanwhile, the recovered host may already be using the same segment, causing both hosts to write to the same persistent memory segment simultaneously, resulting in data being overwritten or corrupted.

[0016] Furthermore, existing persistent memory management solutions focus more on data caching, log recording, or underlying storage writing. Persistent memory is usually used as a buffer space within a single host and does not address segment lease management when multiple hosts share the same persistent memory pool. If the management server only reallocates persistent memory segments based on its own stored index information without verifying the management pages and commit log pages within the segment, it may use a record that has not been fully written as a valid record, causing the recovery host to read only half of the data and resulting in recovery errors.

[0017] Furthermore, existing solutions typically rely directly on the index information stored by the management server itself for segment reallocation during fault recovery, lacking verification of the management pages and commit log pages within the segments. If the management server's index becomes inconsistent with the actual records in persistent memory due to network latency, power outages, or untimely updates, an incorrect takeover decision may be made. In addition, existing solutions lack a mechanism to verify the integrity of the management page header before takeover. If the management page header is damaged due to power failure during writing, the management server may read incorrect information, further reducing the reliability of the takeover decision.

[0018] Based on this, this application provides a multi-host management system, such as... Figure 1 As shown, the multi-host management system 100 includes: a management device 1, multiple hosts 2, a first drive device 3, a second drive device 4, an access control device 6, and a persistent memory pool device 7.

[0019] The management device 1 is connected to the host, the access control device 6, and the persistent memory pool device 7 respectively; the access control device 6 is located on the access path between the host and the persistent memory pool device 7.

[0020] The first drive device 3 is located in the first host 21 of the plurality of hosts 2, and the second drive device 4 is located in the second host 22 of the plurality of hosts 2; the persistent memory pool device 7 includes a plurality of persistent memory segments, each persistent memory segment including a management page and a commit log page.

[0021] The management device 1 is used to allocate a persistent memory segment to the first host 21, write lease information to the management page, and establish the access relationship of the first host 21 to the persistent memory segment through the access control device 6; the first drive device 3 is used to write write commit records to the commit log page during the period when the first host 21 uses the persistent memory segment.

[0022] The management device 1 is also used to, when an anomaly is detected in the first host 21, first revoke the access relationship of the first host 21, and then read the management page and commit log page of the persistent memory segment; if the most recent commit sequence number is consistent with the most recent valid commit record in the commit log page, then the persistent memory segment is handed over to the second host 22 for takeover; if they are inconsistent, the persistent memory segment is kept unallocable, and the recoverable location is determined according to the previous valid commit record.

[0023] like Figure 2 As shown, in some embodiments, it further includes a third host 23 and a third drive device 5.

[0024] The third host 23 is a regular business host in the multi-host management system 100. It is neither the first host 21 currently occupying the segment to be taken over, nor the second host 22 preparing to take over the segment. It represents other hosts in the system besides the first host 21 and the second host 22, and is used to demonstrate that the system supports multiple hosts to access the same persistent memory pool.

[0025] The third drive unit 5 is located in the third main unit 23 and functions similarly to the first drive unit 3 and the second drive unit 4, mainly including: The persistent memory segment allocated by the management device 1 to the third host 23 is mapped to the business process of the third host 23 for use; while the third host 23 is using the persistent memory segment it allocated, the third driver device 5 writes the write commit record to the commit log page of the segment; the third driver device 5 receives the segment address, segment length and lease information returned by the management device 1, and after confirming that the lease information is consistent with the record in the management page, maps the persistent memory segment to the business process.

[0026] In some embodiments, management device 1 may be a management server, management node, or management virtual machine independent of each host, or it may be performed by a single host.

[0027] Management device 1 is responsible for management functions such as persistent memory segment allocation, lease information generation, access relationship establishment and revocation, anomaly detection, and takeover determination. In specific implementations, management device 1 can be a software module running on the processor, or a hardware device consisting of a processor, memory, and a communication interface; this embodiment does not limit this.

[0028] Multiple hosts 2 refer to multiple computer devices that access the same persistent memory pool through a high-speed interconnection network, including the first host 21 and the second host 22.

[0029] The first host 21 refers to the host currently occupying the persistent memory segment, and the second host 22 refers to the host that is about to take over the persistent memory segment after the first host 21 fails. The first host 21 and the second host 22 are not fixed. At different times or in different segments, the same host can be either the first host 21 or the second host 22.

[0030] A driver is a software module or a combination of hardware and software that is located in the host and is used to map persistent memory segments to business processes and to write commit records.

[0031] The first drive device 3 is located in the first host 21, and the second drive device 4 is located in the second host 22. The first drive device 3 is used to write the write commit record to the commit log page during the period when the first host 21 uses the persistent memory segment, and to perform cache write-back and write order guarantee operations after the first host 21 completes the persistent write. The second drive device 4 is used to map the persistent memory segment to the recovery process of the second host 22 after the second host 22 takes over the persistent memory segment.

[0032] The driving device can be implemented in the form of a driver, kernel module or user-space library, and this embodiment does not limit it.

[0033] Access control device 6 refers to a device used to record and control the host's access permissions to persistent memory segments. In specific implementations, access control device 6 can be implemented by a port access table, memory window configuration table, or host input / output memory management unit page table in high-speed interconnect switching device 9, or by other hardware or hardware / software hybrid modules capable of establishing or revoking access relationships between the host and persistent memory segments.

[0034] The persistent memory pool device 7 refers to a storage resource pool composed of multiple persistent memory devices; the persistent memory devices can be persistent memory modules, non-volatile memory modules, or memory devices that support persistent storage; the persistent memory pool device 7 is divided into multiple persistent memory segments, each of which can be independently allocated to a host; the persistent memory pool device 7 can be connected to multiple hosts through a high-speed interconnect switching device 9, enabling multiple hosts to share access to the storage resources in the persistent memory pool device 7.

[0035] A management page is a storage area for management information located in each persistent memory segment.

[0036] In some embodiments, the management page is used to record the segment identifier, the currently occupying host identifier, lease information, segment occupancy flag, and header checksum; the lease information includes the lease code and lease round.

[0037] The management page is equivalent to the identity file of the persistent memory segment, enabling the persistent memory segment itself to describe its ownership and status.

[0038] The segment identifier and the currently occupying host identifier enable each persistent memory segment to uniquely identify itself and record the current owner host; after the management device 1 detects an anomaly in the first host 21, it can accurately determine the persistent memory segment to be processed and the original occupying host, providing a clear object for revoking the access relationship of the first host 21 and determining whether the segment can be taken over by the second host 22, thus avoiding segment mismatch or erroneous takeover.

[0039] In some embodiments, the segment occupancy flag may include four values: unoccupied, occupied, under takeover, and isolated.

[0040] Unoccupied means the persistent memory segment can be allocated; Occupied means a host is already using the persistent memory segment; Under Takeover means the access relationship of the first host has been revoked, and the management device is checking the commit records in the persistent memory segment. At this time, the persistent memory segment does not grant write permissions to the second host; Isolated means the management page or commit log page fails the verification, and the persistent memory segment will not be allocated temporarily.

[0041] The management device can detect anomalies in the first host through a heartbeat mechanism. For example, if the first host sends a heartbeat once per second and the management device fails to receive a heartbeat three times in a row, it will begin to process the persistent memory segment occupied by the first host.

[0042] After revoking the access relationship of the first host, the management device can still read the count of incomplete transactions in the high-speed interconnection switching equipment. If the count of incomplete transactions is zero, it means that the first host has no read or write transactions in progress and can continue to read the management page and commit log page. If the count of incomplete transactions is not zero within a preset time, the persistent memory segment will continue to be under takeover and will not grant write access to the second host.

[0043] When the access control device is implemented by the host input / output memory management unit page table, after the management device deletes the page table mapping corresponding to the first host, it also invalidates the relevant address translation cache to ensure that the first host can no longer access the persistent memory segment through the old mapping in the cache.

[0044] Regarding lease information, namely lease code and lease round, the lease code is used to distinguish different allocation instances, and the lease round is used to distinguish different allocation cycles of the same persistent memory segment. Through the lease code and lease round, the management device 1 can determine whether the lease carried by the first host 21 when it comes back online is still valid. If the lease rounds are inconsistent, or the persistent memory segment has been taken over by the second host 22, the first host 21 is denied write access to the original persistent memory segment, thereby preventing the old host from continuing to write according to the old mapping after coming back online, and avoiding the first host 21 and the second host 22 from writing to the same persistent memory segment at the same time.

[0045] The segment occupancy marker enables the management device 1 to quickly identify whether a persistent memory segment has been occupied, thus avoiding the duplicate allocation of already allocated segments. When an anomaly is detected in the first host 21, the persistent memory segment can be marked as unallocable to facilitate subsequent secure takeover, or the recoverable location can be determined based on the previous valid commit record.

[0046] The header checksum enables the management page header to have integrity verification capabilities. Before taking over a persistent memory segment, management device 1 can first verify the header checksum; if the verification fails, the persistent memory segment will not be directly allocated to other hosts, thereby avoiding incorrect takeover decisions due to corrupted management page headers.

[0047] The aforementioned fields enable persistent memory segments to possess ownership descriptions, lease management, occupancy status indicators, and integrity verification capabilities. Management device 1 can confirm segment ownership, lease validity, and management page trustworthiness without relying entirely on external indexes, thereby achieving secure takeover after host failure and preventing double writes and misuse of incomplete records.

[0048] A commit log page is a commit record storage area set in each persistent memory segment, used to record the host's write commit records for that persistent memory segment.

[0049] In some embodiments, each commit record in the commit log page includes a commit sequence number, lease round, write start offset, write length, commit flag, and record check value.

[0050] The first driving device 3 is used to write the submission sequence number, lease round, writing start offset and writing length first when writing the submission record, then write the record verification value, and finally write the submission flag.

[0051] The submission number is used to compare with the most recent submission number in the management page to determine whether the last submission was complete.

[0052] The lease round is used to identify the allocation period to which the commit record belongs, preventing commit records from being mistakenly identified as currently valid records under older lease periods.

[0053] The write start offset and write length are used to determine the specific location and range of this write in the persistent memory segment, providing a basis for determining the recoverable location based on the previous valid commit record after an exception.

[0054] The record check value is used to verify whether the submission record itself is complete and undamaged; the submission flag is used to indicate whether the submission record has been successfully submitted.

[0055] With the above fields, each submission record in the submission log page has the ability to be verified, located, and traced, enabling management device 1 to accurately determine which record is the last valid submission record after the host malfunctions.

[0056] Meanwhile, since the commit flag is the last field written, if the first host 21 loses power or restarts during the writing of the commit record, the commit record will not be considered a valid commit record if the commit flag has not yet been written; even if the descriptive field has been written, the management device 1 will not process it as a complete commit; thus, an incomplete commit record will not be mistakenly considered a valid record because some fields have been written.

[0057] The record check value is written before the submission flag, so that when the management device 1 reads the submission record later, it can first check the record check value and then check the submission flag. If the record check value fails to be checked, it means that the submission record itself is damaged. Even if the submission flag has been written, the record can be determined to be untrustworthy. Only if the record check value passes the check and the submission flag is valid is the submission record considered to be a valid submission record.

[0058] When management device 1 reads the commit log page after detecting an anomaly in the first host 21, it can accurately identify the most recent valid commit record from the commit log page based on the aforementioned fields and writing order. If the most recent valid commit record matches the most recent commit sequence number in the management page, it indicates that the last commit has been completely written, and management device 1 can hand over the persistent memory segment to the second host 22 for takeover. If they do not match, it indicates that the last commit was not completely written, and management device 1 can keep the persistent memory segment unallocable and determine the recoverable location based on the write start offset and write length of the previous valid commit record. Thus, the system can avoid using incompletely written records as valid data, thereby improving the reliability of fault takeover and data recovery.

[0059] In some embodiments, the commit log page can be divided into multiple commit records aligned to a fixed length and used in a cyclic manner; when the record space in the log page is exhausted, the first drive device rewrites from the first record and determines the order of the records by the commit sequence number.

[0060] Therefore, during fault recovery, the physical location recorded in the log page is not used as the sole criterion for order; instead, the submission sequence number is compared first. The first driver can provide a mapping interface to the business process through a character device. The management page and the submission log page are not directly mapped to ordinary business threads, but are read and written by the first driver, thereby preventing business programs from accidentally modifying management information.

[0061] In some embodiments, the first host 21 abnormality includes first host heartbeat interruption, first host restart, and first host access link disconnection.

[0062] Revoking the access relationship of the first host 21 includes removing the access relationship of the first host 21 to the persistent memory segment it occupies from the access control device 6, or closing the access window of the corresponding host port in the high-speed interconnect switching device 9.

[0063] The interruption of the first host heartbeat corresponds to the interruption of communication between the host and the persistent memory pool device 7; the restart of the first host corresponds to the restart of the host itself; and the disconnection of the first host access link corresponds to different fault modes such as the disconnection of the physical or logical access path.

[0064] The management device 1 can trigger subsequent access revocation and takeover judgment processes under various actual fault scenarios, avoiding omissions of fault situations that should be handled due to overly narrow exception type definitions, thereby improving the comprehensiveness of fault detection.

[0065] Removing the access relationship from the access control device 6 is equivalent to revoking the first host 21's access rights to the persistent memory segment, preventing the first host 21 from accessing the persistent memory segment through the access relationship; closing the access window of the corresponding host port in the high-speed interconnect switching device 9 is equivalent to cutting off the access path between the first host 21 and the persistent memory pool device 7 at the hardware or link level, preventing the first host 21 from writing data to the persistent memory segment through the port.

[0066] The two methods described above can be used individually or in combination, thus providing a concrete and feasible means to revoke the access relationship of the first host 21.

[0067] In summary, by clearly defining the specific type of the first host 21's anomaly and the specific method of revoking the access relationship, the management device 1 can reliably cut off the first host 21's access path to the persistent memory segment under various fault scenarios. This prevents the first host 21 from continuing to write after the anomaly, prevents the first host 21 and the second host 22 from writing to the same persistent memory segment at the same time, and provides a safe and stable premise for subsequent reading of the management page and commit log page, determining whether takeover is possible, and identifying the recoverable location.

[0068] The most recently committed sequence number refers to the sequence number recorded in the management page that the management device 1 considers to be the last successfully committed persistent memory segment; this sequence number is used to compare with the commit record in the commit log page to determine whether the last commit was complete.

[0069] The most recently valid commit record refers to the last commit record in the commit log page that has passed validation and whose commit flag is valid; this record represents the last piece of data that was actually written completely in the persistent memory segment.

[0070] The previous valid commit record refers to the commit record in the commit log page that precedes the most recent valid commit record, has passed verification, and has a valid commit flag, when the most recent valid commit record does not match the most recent commit sequence number on the management page. The previous valid commit record is used to determine the recoverable location.

[0071] A recoverable position refers to the starting point for data recovery determined based on the write start offset and write length of the previous valid commit record. The second host 22 continues processing from this position, thus avoiding the use of incompletely written data.

[0072] In some application scenarios, the primary host can run a database, and the database logs can be appended to.

[0073] When the first host fails and the most recent valid commit record in the commit log page is inconsistent with the most recent commit sequence number in the management page, the management device searches backward for the previous valid commit record and determines the recoverable position based on the write start offset and write length in that record. The second host only considers the data before the recoverable position as valid data, and the data after the recoverable position that has not been confirmed by a valid commit record is not used for recovery.

[0074] The persistent memory pool device can consist of one or more persistent memory devices. The management device can divide the allocatable space in the persistent memory pool device into multiple persistent memory segments according to a preset size, and reserve management pages and commit log pages at the beginning of each persistent memory segment, with the remaining space used as a data area.

[0075] The multi-host management system 100 in this embodiment achieves secure takeover and consistent recovery of persistent memory segments after host failure through the coordinated operation of management device 1, first driving device 3, second driving device 4, access control device 6 and persistent memory pool device 7.

[0076] First, the persistent memory pool device 7 includes multiple persistent memory segments, each of which includes a management page and a commit log page. Since the management page and commit log page are set within the persistent memory segment itself, rather than being stored only in the management device 1 or the host, even if the index information stored by the management device 1 itself is inconsistent with the actual state due to network latency, power failure, or untimely updates, the management device 1 can still obtain the real ownership information and write records by reading the management page and commit log page inside the persistent memory segment.

[0077] When allocating a persistent memory segment to the first host 21, the management device 1 writes the lease information into the management page and establishes the access relationship of the first host 21 to the persistent memory segment through the access control device 6. Since the lease information is written into the management page inside the persistent memory segment and the access relationship is established separately through the access control device 6, the ownership and access permissions of the persistent memory segment are two independent and separately controllable pieces of information. The ownership information is recorded inside the persistent memory segment, and the access permissions are recorded in the access control device 6. The two work together so that when the management device 1 needs to revoke the access permissions of the first host 21, it can directly revoke the access relationship through the access control device 6 without relying on the cooperation of the first host 21, thus providing a basis for rapid isolation in abnormal situations.

[0078] During the period when the first host 21 uses the persistent memory segment, the first driving device 3 writes the write commit record to the commit log page. Since the commit record is written to the commit log page of the persistent memory segment itself, rather than being stored only locally on the first host 21 or in the management device 1, even after the first host 21 is abnormal, the write history in the commit log page is still retained in the persistent memory segment. This allows the management device 1 to obtain the last write commit record of the first host 21 by reading the commit log page after detecting the first host 21 is abnormal, thus providing a data basis for subsequent consistency judgment.

[0079] When the management device 1 detects an anomaly in the first host 21, it first revokes the access relationship of the first host 21, and then reads the management page and commit log page of the persistent memory segment. Since the action of revoking the access relationship occurs before reading the management page and commit log page, the first host 21 cannot continue to write to the persistent memory segment after the access relationship is revoked. Meanwhile, the management device 1 can read the management page and commit log page inside the persistent memory segment without being disturbed by the first host 21. This avoids the problem of inconsistent states of the read management page and commit log page due to the first host 21 still writing. At the same time, since the access relationship of the first host 21 is revoked first, even if the first host 21 comes back online, it cannot continue to write at the old address, thereby avoiding the situation where the first host 21 and the second host 22 write to the same persistent memory segment at the same time.

[0080] After reading the management page and the commit log page, management device 1 compares the most recent commit sequence number in the management page with the most recent valid commit record in the commit log page. Since the most recent commit sequence number represents the last successful commit as determined by management device 1, and the most recent valid commit record represents the last record that was actually written completely in the persistent memory segment, if the two match, it means that the last commit has been completely written to persistent memory and the data state is clean. If the two do not match, it means that the last commit may have only been written halfway and the data state is incomplete. Through this comparison, management device 1 can determine whether the last commit is complete based solely on the records within the persistent memory segment without relying on external indexes.

[0081] Based on this, if the most recent commit number matches the most recent valid commit record, management device 1 hands over the persistent memory segment to the second host 22 for takeover. Since the data state is clean at this time, the second host 22 can directly read data from the persistent memory segment and continue processing after taking over, without reading data that has not been fully written. If they do not match, management device 1 keeps the persistent memory segment unallocable and determines the recoverable location according to the previous valid commit record.

[0082] Since the previous valid commit record was verified and its commit flag was valid, the recoverable position determined by its write start offset and write length is safe. The second host 22 can continue processing from this position, avoiding the use of incompletely written data. Therefore, it can quickly complete takeover when the data is complete and accurately determine the recovery position when the data is incomplete, thus achieving accurate and reliable fault takeover and data recovery under the complex conditions of multiple hosts sharing a persistent memory pool.

[0083] In some embodiments, the management device 1 is further configured to, after receiving a re-online request from the first host 21, compare the lease code and lease round carried in the re-online request with the record in the management page of the corresponding persistent memory segment.

[0084] If the lease rounds are consistent and the persistent memory segment has not been taken over by the second host 22, then the first host 21 is allowed to re-access the persistent memory segment.

[0085] If the lease rounds are inconsistent, or if the persistent memory segment has been taken over by the second host 22, then the first host 21's write access to the original persistent memory segment will be denied.

[0086] A reconnection request refers to a request sent by the first host 21 to the management device 1 when it resumes operation and requests to continue accessing the persistent memory segment it originally occupied after a heartbeat interruption, restart, or access link disconnection.

[0087] The request carries the lease code and lease round obtained by the first host 21 from the management device 1 during the previous allocation. The purpose of the first host 21 sending the re-online request is to ask the management device 1 to allow it to continue using the original persistent memory segment, instead of having it taken over by the second host 22.

[0088] Allowing the first host 21 to re-access the persistent memory segment means that, after confirming that the lease of the first host 21 is still valid and that the persistent memory segment has not been taken over by the second host 22, the management device 1 allows the first host 21 to re-establish the access relationship to the persistent memory segment, so that the first host 21 can continue to perform read and write operations on the persistent memory segment.

[0089] Denying write access to the original persistent memory segment by the first host 21 means that when the management device 1 confirms that the lease of the first host 21 has expired or the persistent memory segment has been taken over by the second host 22, it does not allow the first host 21 to perform write operations on the persistent memory segment. Denying write access can be manifested as not establishing an access relationship between the first host 21 and the persistent memory segment through the access control device 6, or it can be manifested as closing the access window corresponding to the first host 21 through the access control device 6, or it can be manifested as returning a denial response to the first host 21.

[0090] The multi-host management system 100 in this embodiment, upon receiving a request for the first host 21 to come back online, compares the lease code and lease round carried in the request with the record in the management page of the corresponding persistent memory segment, thereby verifying the lease validity of the re-online host. If the lease round is consistent and the persistent memory segment has not been taken over by the second host 22, the first host 21 is allowed to access it again, enabling it to continue using the original persistent memory segment after fault recovery, avoiding unnecessary data migration and reallocation. If the lease round is inconsistent, or the persistent memory segment has been taken over by the second host 22, the first host 21's write access to the original persistent memory segment is denied, thereby preventing the old host from continuing to write according to the old mapping after coming back online, preventing the first host 21 and the second host 22 from writing to the same persistent memory segment at the same time, and improving the security of the multi-host shared persistent memory pool during fault recovery.

[0091] like Figure 3 As shown, in some embodiments, it further includes a pooling indexing device 8, which is connected to the management device 1.

[0092] The pooled index device 8 is used to store the pooled index table, which records the persistent memory segment identifier, the currently occupying host identifier, lease information, and the most recently committed sequence number.

[0093] When the records in the pooled index table are inconsistent with the records in the management page of the persistent memory segment, the management device 1 uses the records that have passed verification in the management page and the commit log page as the basis for recovery.

[0094] Pooled index device 8 refers to a device connected to management device 1 for storing pooled index tables; pooled index device 8 can be understood as an external index used by management device 1 for quickly querying persistent memory segment allocation.

[0095] The pooled indexing device 8 can be a storage device independent of the management device 1, or it can be a storage area within the management device 1, or it can be a database, key-value store, or other device capable of storing index information.

[0096] The connection between the pooling indexing device 8 and the management device 1 can be a wired connection or a wireless connection, and this embodiment does not limit this.

[0097] The pooled index table refers to the index table stored in the pooled index device 8, which is used to record persistent memory segment identifiers, currently occupying host identifiers, lease information, and the most recently committed sequence number.

[0098] Each record in the pooled index table corresponds to a persistent memory segment. The purpose of the pooled index table is to enable management device 1 to avoid reading the management pages inside the persistent memory segment every time it performs normal allocation and query, thereby improving management efficiency.

[0099] This embodiment adds a pooled index device 8 connected to the management device 1. The pooled index device 8 stores a pooled index table containing persistent memory segment identifiers, currently occupying host identifiers, lease information, and the most recently committed sequence number. This allows the management device 1 to prioritize querying the pooled index table during normal allocation and querying, improving management efficiency. Furthermore, considering that the pooled index table may differ from the actual state within the persistent memory segment due to network latency, power outages, or incomplete updates, when the records in the pooled index table and the persistent memory segment management page are inconsistent, the management device 1 uses the verified records in the management page and the commit log page as the basis for recovery when discrepancies arise. Cross-validation is performed using the header checksum of the management page and the checksum and commit flag of the commit records in the commit log page to exclude corrupted or incompletely written records. The decision to hand over the persistent memory segment to the second host 22 or to keep it unallocatable and determine the recoverable location based on the last valid commit record is made based on whether the most recent commit sequence number matches the most recent valid commit record. In the end, this approach preserves the efficient query capability of the pooled index table during normal operation and avoids erroneous takeover decisions caused by expired or unupdated external indexes, thereby improving the reliability and accuracy of the multi-host shared persistent memory pool during fault recovery.

[0100] like Figure 4As shown, in some embodiments, a high-speed interconnect switching device 9 is also included, which is connected between the host and the persistent memory pool device 7.

[0101] Access control device 6 is installed in high-speed interconnect switching device 9 and is implemented using port access table, memory window configuration table or host input / output memory management unit page table in high-speed interconnect switching device 9; management device 1 is used to close the access window corresponding to the first host 21 after detecting an abnormality in the first host 21, and then read the management page and commit log page of the corresponding persistent memory segment.

[0102] High-speed interconnect switching device 9 refers to a switching device connected between a host and a persistent memory pool device 7, used to enable the host to access persistent memory segments in the persistent memory pool device 7. High-speed interconnect switching device 9 can be understood as a communication hub between multiple hosts and persistent memory pool device 7, through which the hosts access remote persistent memory.

[0103] For example, the high-speed interconnect switching device 9 may be a switching device that supports the CXL protocol, PCIe protocol or other high-speed interconnect protocols; the high-speed interconnect switching device 9 may include multiple ports, each of which can connect to a host or a persistent memory device, thereby establishing a data access path between the host and the persistent memory pool device 7.

[0104] The port access table refers to the entries in the high-speed interconnect switching device 9 used to record the access permissions of each port; by configuring the port access table, the management device 1 can allow or prohibit a host from accessing a certain persistent memory segment through the corresponding port.

[0105] The memory window configuration table refers to the table entries in the high-speed interconnect switching device 9 used to configure memory windows. By configuring memory windows, the management device 1 can establish or cancel the address mapping relationship between the host and the persistent memory segment. When the memory window is closed, the host cannot access the corresponding persistent memory segment through the window.

[0106] The host input / output memory management unit page table refers to the page table used by the input / output memory management unit in the host. It is used to translate the input / output addresses on the host side into physical addresses on the persistent memory pool device 7 side. By configuring the host input / output memory management unit page table, the management device 1 can restrict the host's access to persistent memory segments. When the corresponding mapping entry in the page table is removed or marked as invalid, the host can no longer access the persistent memory segment through the input / output memory management unit.

[0107] An access window refers to a logical or physical channel through which a host accesses a persistent memory segment. An access window can be implemented by an entry in the port access table, a window in the memory window configuration table, or a mapping entry in the host input / output memory management unit page table. Closing the access window corresponding to the first host 21 can be understood as preventing the first host 21 from accessing the corresponding persistent memory segment through that window.

[0108] This embodiment adds a high-speed interconnect switching device 9 connected between the host and the persistent memory pool device 7. The access control device 6 is set in the high-speed interconnect switching device 9 and implemented using a port access table, memory window configuration table, or host input / output memory management unit page table. This allows the management device 1 to close the access window corresponding to the first host 21 at the hardware level after detecting an anomaly in the first host 21, and then read the management page and commit log page of the corresponding persistent memory segment. Since closing the access window occurs before reading the management page and commit log page, the first host 21 cannot continue writing after the anomaly. The most recent commit sequence number in the management page and the most recent valid commit record in the commit log page can reflect the true state of the first host 21 before the anomaly, thereby avoiding the first host 21 and the second host 22 from writing to the same persistent memory segment at the same time. This provides a safe and stable premise for subsequent determination of whether the persistent memory segment can be taken over by the second host 22 or for determining a recoverable location based on the previous valid commit record.

[0109] In some embodiments, the management device 1 is further configured to, when determining whether a persistent memory segment can be taken over, read the segment occupancy flag, header checksum, and most recently committed sequence number in the management page, and first check the header checksum.

[0110] If header verification fails, the persistent memory segment will not be allocated to other hosts.

[0111] If the header verification is successful and the commit sequence number of the most recent valid commit record in the commit log page matches the most recent commit sequence number in the management page, the second host 22 is allowed to take over the persistent memory segment.

[0112] The header checksum is the checksum calculated from the header record area in the management page. The header record area includes fields such as segment identifier, currently occupying host identifier, lease information, segment occupancy flag, and most recently committed sequence number. The header checksum is used to verify whether the header record area is complete and undamaged. Before taking over the persistent memory segment, management device 1 checks the header checksum to determine whether the management page header is trustworthy.

[0113] A successful header verification means that the verification value recalculated by management device 1 based on the header record area of ​​the management page is consistent with the verification value stored in the header verification area; a successful header verification indicates that the header record area of ​​the management page is intact and has not been damaged.

[0114] A header verification failure means that the verification value recalculated by management device 1 based on the header record area of ​​the management page is inconsistent with the verification value stored in the header verification area. A header verification failure indicates that the header record area of ​​the management page may be corrupted, and fields such as segment identifier, currently occupying host identifier, lease information, segment occupancy flag, and most recently submitted sequence number may be unreliable.

[0115] First, when determining whether a persistent memory segment can be taken over, management device 1 reads the segment occupancy flag, header checksum, and most recently committed sequence number from the management page. Since the segment occupancy flag indicates whether the persistent memory segment is currently occupied, management device 1 can quickly determine whether the persistent memory segment is in an allocated state by reading the segment occupancy flag, thus initially determining whether the persistent memory segment meets the prerequisites for takeover. Since the header checksum is used to verify the integrity of the management page header record area, management device 1 can prepare to verify the management page header by reading the header checksum. Since the most recently committed sequence number is used to compare with the commit records in the commit log page, management device 1 can prepare to perform a consistency check by reading the most recently committed sequence number.

[0116] Then, management device 1 first verifies the header check value. Since the header check value is calculated based on the header record area of ​​the management page, and the header record area of ​​the management page contains key fields such as segment identifier, currently occupying host identifier, lease information, segment occupancy mark and most recently submitted sequence number, the header check value can reflect whether the header record area of ​​the management page is complete and undamaged.

[0117] After reading the header checksum, management device 1 recalculates the checksum based on the header record area and compares it with the checksum stored in the header checksum area. If they match, it indicates that the header record area of ​​the management page is complete and that fields such as the segment occupancy mark and the most recently submitted sequence number are reliable. If they do not match, it indicates that the header record area of ​​the management page may be corrupted and that the fields therein may be unreliable. Through this verification, management device 1 can confirm the reliability of the management page itself before using the information in the management page.

[0118] When header verification fails, management device 1 does not allocate the persistent memory segment to other hosts. Since header verification failure indicates that the management page header record area may be corrupted, fields such as segment identifier, currently occupying host identifier, lease information, segment occupancy flag, and most recently committed sequence number may be unreliable. If management device 1 still allocates the persistent memory segment to other hosts based on these fields, it may lead to segment mismatch, incorrect lease information, or incorrect takeover judgment. Therefore, when header verification fails, management device 1 does not allocate the persistent memory segment to other hosts, thereby avoiding erroneous takeover decisions due to corrupted management page headers.

[0119] In some embodiments, the management device 1 is further configured to mark a persistent memory segment as unallocatable when the most recent valid commit record in the commit log page is inconsistent with the most recent commit sequence number in the management page, and to determine a recoverable position based on the write start offset and write length of the previous valid commit record in the commit log page, and to notify the second host 22 to continue processing from the recoverable position.

[0120] The most recent valid commit record refers to the last commit record in the commit log page that passes validation and has a valid commit flag. This record represents the last piece of data that was actually written completely in the persistent memory segment.

[0121] A discrepancy between the most recent valid commit record and the most recent commit number in the management page means that the commit number of the most recent valid commit record in the commit log page is not equal to the most recent commit number in the management page. This discrepancy indicates that the last successful commit as perceived by management device 1 does not match the last record actually written completely in the persistent memory segment; this situation occurs when the first host 21 experienced a power outage or restart during the writing of the last commit record, resulting in the last commit record not being completely written.

[0122] The previous valid commit record refers to the commit record in the commit log page that is located before the most recent valid commit record, has passed verification, and has a valid commit flag, when the most recent valid commit record is inconsistent with the most recent commit sequence number in the management page; the previous valid commit record is the basis for determining the recoverable location.

[0123] The write start offset refers to the starting position of the data write operation corresponding to the previous valid committed record in the data area of ​​the persistent memory segment.

[0124] Write length refers to the data length of the data write operation corresponding to the previous valid commit record. Based on the write start offset and write length, the data range corresponding to the previous valid commit record can be determined. That is, the data starting from the write start offset and with a length equal to the write length is complete and valid.

[0125] A recoverable position refers to the starting point for data recovery determined based on the write start offset and write length of the previous valid commit record. A recoverable position can be the end position of the data range corresponding to the previous valid commit record, that is, the second host 22 continues to process data from this position. A recoverable position is used to allow the second host 22 to skip the data corresponding to the last commit record that was not fully written and continue processing from the data of the previous fully committed record, thereby avoiding the use of data that was not fully written and without losing data that has been fully committed.

[0126] Marking a persistent memory segment as unallocable means that the management device 1 sets the status of the persistent memory segment to be disallowed from being allocated to other hosts. Marking it as unallocable can be done by setting the corresponding status in the segment occupancy flag of the management page, or by recording the corresponding status in the pooling index table of the management device 1. The purpose of marking it as unallocable is to prevent the persistent memory segment from being directly allocated to the second host 22 or other hosts if the last commit record has not been fully written.

[0127] Notifying the second host 22 to continue processing from a recoverable location means that after the management device 1 determines a recoverable location, it sends a notification to the second host 22, so that the second host 22 can continue processing the data in the persistent memory segment from that recoverable location. The second host 22 can receive the notification through the second drive device 4 and map the persistent memory segment to the recovery process for use, so that the recovery process can continue processing the data from the recoverable location.

[0128] In this embodiment, when the most recent valid commit record in the commit log page is inconsistent with the most recent commit sequence number in the management page, the management device 1 marks the persistent memory segment as unallocable, and determines the recoverable position based on the write start offset and write length of the previous valid commit record in the commit log page. The second host 22 is then notified to continue processing from the recoverable position, thereby achieving safe recovery even when the last commit record has not been fully written. This avoids using incompletely written data as valid data and does not lose fully committed data, improving the data consistency and reliability of the multi-host shared persistent memory pool during fault recovery.

[0129] In some embodiments, the management page is set at the beginning of a persistent memory segment and includes at least a fixed-length header record area and a header check area.

[0130] The header checksum area is used to store the checksum calculated based on the header record area; the management device 1 is used to check the header checksum before taking over the persistent memory segment, and not to directly allocate the persistent memory segment to other hosts if the checksum fails.

[0131] Setting the management page at the beginning of a persistent memory segment means that the management page is located at the very beginning of the persistent memory segment.

[0132] The starting address can be either the physical starting address of the persistent memory segment or the logical starting address of the persistent memory segment; this embodiment does not limit this.

[0133] This embodiment sets the management page at the beginning of the persistent memory segment and includes at least a fixed-length header record area and a header verification area. The header verification area stores the verification value calculated based on the header record area, enabling the management page header to have self-verification capability and allowing the management device 1 to read quickly at a fixed offset.

[0134] Before taking over a persistent memory segment, management device 1 first verifies the header checksum. If the verification is successful, it continues to use information such as the segment occupancy flag and the most recently committed sequence number in the management page to determine the takeover. If the verification fails, the persistent memory segment will not be directly allocated to other hosts because the header record area may be damaged. This avoids segment mismatch, lease information errors, or incorrect takeover caused by damage to the management page header, and improves the reliability of the multi-host shared persistent memory pool during the fault recovery process.

[0135] In some embodiments, the first driving device 3 is further configured to perform a cache write-back on the data range written for the business after the first host 21 completes a persistent write.

[0136] After the cache write-back is completed, write the commit record; perform a cache write-back on the cache line containing the commit record; perform write order guarantee operation; and after confirming that the commit record has been written to persistent memory, notify management device 1 of the commit sequence number.

[0137] Persistent writing refers to the write operation in which the first host 21 writes business data into a persistent memory segment and retains the data even after power failure.

[0138] Persistent writing requires that the data eventually fall into the persistent memory segment, and the data still exists after power failure. In this embodiment, the first host 21 completes a persistent write, which means that the business data has been written into the data area of ​​the persistent memory segment, and the write commit record is subsequently used to mark that the write has been completed.

[0139] The data range written by the business refers to the address range covered by the data actually written to the persistent memory segment by the first host 21 in this persistent write.

[0140] The data range written by the business can be understood as a segment of the data area involved in this write; the first driving device 3 performs a cache write-back on the data range, the purpose of which is to write the data in the data range back from the host cache to the persistent memory segment, so that it is still retained after power failure.

[0141] Cache write-back refers to the operation of writing data from the host cache back to the persistent memory segment. When the host writes data, the data may first be written to the processor's cache instead of being immediately written to persistent memory. The purpose of cache write-back is to ensure that the data in the cache falls into the persistent memory segment, so that the data will not be lost after power failure.

[0142] The cache write-back can be performed on the range of data written by the business or on the cache line where the submitted record is located; this embodiment does not limit this.

[0143] A commit record is a record written to the commit log page to mark that a certain write to a persistent memory segment by the first host 21 has been completed. The commit record includes the commit sequence number, lease round number, write start offset, write length, commit flag, and record check value.

[0144] In this embodiment, the first driving device 3 writes a commit record after the cache write-back is completed. The purpose is to record that the write is completed after the business data has been written back to persistent memory.

[0145] The cache line containing the commit record refers to the processor cache line occupied by the commit record when it is written. Since the commit record may enter the processor cache first instead of being written to persistent memory immediately, it is necessary to perform a cache write-back on the cache line containing the commit record so that the commit record falls into the persistent memory segment.

[0146] Performing a cache write-back on the cache line containing the commit record can be understood as writing the entire cache line containing the commit record back to persistent memory, thereby ensuring that the commit record is not lost due to power failure.

[0147] Write order guarantee operations are used to ensure that previous cache write-back operations have been completed and that subsequent operations will not occur prematurely due to out-of-order processor execution. Write order guarantee operations ensure that write-back operations before the barrier have been completed before read or write operations after the barrier can continue.

[0148] By performing a write order guarantee operation, the first driving device 3 can confirm that the data range and commit records written by the business have been written to persistent memory, thereby ensuring that the commit records will not fall into persistent memory before the business data.

[0149] Confirming that the commit record has been written to persistent memory means that the first driver device 3 ensures that the operation confirms that the commit record has fallen into the persistent memory segment, rather than still remaining in the processor cache, by writing in the correct order. Only after confirming that the commit record has been written to persistent memory will the first driver device 3 notify the management device 1 of the commit sequence number. This ensures that the commit sequence number received by the management device 1 corresponds to the commit record that has been persisted, rather than a record that has not yet been written.

[0150] Notifying the management device 1 of the submission sequence number means that after the first driving device 3 confirms that the submission record has been written to the persistent memory, it sends the submission sequence number to the management device 1, so that the management device 1 can update the most recent submission sequence number in the management page.

[0151] After receiving the submission number, management device 1 writes it to the management page, so that the most recent submission number in the management page is consistent with the most recent valid submission record in the submission log page.

[0152] In summary, this embodiment, after the first host 21 completes a persistent write, the first driving device 3 sequentially performs cache write-back on the data range written by the business, writes a commit record after the cache write-back is completed, performs cache write-back on the cache line where the commit record is located, performs write order guarantee operation, and only notifies the management device 1 of the commit sequence number after confirming that the commit record has been written to persistent memory. This ensures that business data is persisted before the commit record, and the commit record is persisted before the notification, avoiding misjudgment of the commit status by the management device 1 due to the commit record being persisted before the business data. This also ensures that the most recent commit sequence number in the management page is consistent with the most recent valid commit record in the commit log page, providing an accurate basis for subsequent takeover judgment and improving the reliability and accuracy of the multi-host shared persistent memory pool during fault recovery.

[0153] In some embodiments, the first host 21 includes a processor; cache write-back is performed by the first driving device 3 through a cache line write-back instruction or a cache line refresh optimization instruction provided by the processor, and the write order guarantee operation is performed by the first driving device 3 through a storage fence instruction.

[0154] With the support of enhanced asynchronous data refresh protection, the first driving device 3 is used to replace the line-by-line cache write-back of the business data range with the persistent order guarantee mechanism provided by the platform, and the commit flag is still written last.

[0155] The processor refers to the hardware component located in the first host 21 that is used to execute instructions and process data. The processor can execute cache line write-back instructions, cache line refresh optimization instructions and storage fence instructions issued by the first driving device 3 to achieve the persistence of business data and submission records.

[0156] Cache line write-back instructions are processor-provided instructions used to write data from a specified cache line back to persistent memory.

[0157] The first driving device 3 can write back the data range or the cache line containing the commit record from the processor cache to the persistent memory area by executing the cache line write-back instruction. After the cache line write-back instruction is executed, the data in the corresponding cache line is written back to the persistent memory, but the cache line is still retained in the processor cache, and its state can be marked as unmodified.

[0158] Cache line flushing optimization instructions are processor-provided instructions used to write data from a specified cache line back to persistent memory and invalidate that cache line.

[0159] The first driving device 3 can write the data range or the cache line containing the commit record written by the business back from the processor cache to the persistent memory segment by executing the cache line refresh optimization instruction, and invalidate the cache line in the processor cache, thereby forcing a re-read from persistent memory during subsequent accesses.

[0160] Storage fence instructions are processor-provided instructions used to guarantee the order of storage operations. All storage operations that occur before a storage fence instruction must be completed before the storage fence instruction; and storage operations that occur after a storage fence instruction must begin after the storage fence instruction.

[0161] The first drive unit 3 can ensure that the cache line write-back operation performed before the storage fence instruction has been completed by executing the storage fence instruction, so that the business data and the commit record have been written to persistent memory. The storage fence instruction can guarantee the writing order, but it does not perform the cache write-back operation itself. The cache write-back still needs to be completed by the cache line write-back instruction or the cache line refresh optimization instruction.

[0162] Enhanced asynchronous data refresh protection refers to a persistent protection mechanism provided by the platform. On platforms that support enhanced asynchronous data refresh protection, data in the processor cache can be automatically written back to persistent memory under certain conditions, without the need for the software to execute cache write-back instructions line by line.

[0163] The persistence order guarantee mechanism refers to the mechanism provided by the platform to guarantee the persistence order on a platform that supports enhanced asynchronous data refresh protection. The persistence order guarantee mechanism can replace the software in executing cache write-back instructions and storage fence instructions line by line, and the platform automatically guarantees that business data and commit records are written to persistent memory in a predetermined order.

[0164] Line-by-line cache write-back refers to the operation in which the first driving device 3 executes cache write-back instructions or cache line refresh optimization instructions one by one for each cache line within the data range written by the business. Line-by-line cache write-back can be understood as the software writing the data in the cache back to persistent memory line by line. On platforms that support enhanced asynchronous data refresh protection, the platform-provided persistence order guarantee mechanism can be used to replace line-by-line cache write-back, thereby reducing software overhead.

[0165] The commit flag is still written last, meaning that when the platform-provided persistence order guarantee mechanism is used instead of line-by-line cache write-back, the commit flag in the commit record is still written after all other fields. The fact that the commit flag is still written last ensures that an incomplete commit record will not be considered a valid record because some fields have already been written.

[0166] In this embodiment, the first driving device 3 first uses a cache line write-back instruction or a cache line refresh optimization instruction provided by the processor to write the data range written by the business and the cache line where the commit record is located from the processor cache back to persistent memory. Then, it uses a storage fence instruction to ensure that the aforementioned write-back operation has been completed, thereby confirming that the commit record has been written to persistent memory. When enhanced asynchronous data refresh protection is supported, the first driving device 3 uses the persistent order guarantee mechanism provided by the platform to replace the line-by-line cache write-back of the business data range to reduce software overhead. At the same time, the commit flag is still written last, so that incomplete commit records will not be considered valid records because some fields have been written. Thus, cache write-back and order guarantee are achieved.

[0167] In some embodiments, when allocating a persistent memory segment to the first host 21, the management device 1 selects a target segment from unoccupied persistent memory segments, generates lease information, writes the lease information to the management page of the target segment, writes the first host 21 to the access control device 6, and updates the pooling index device 8.

[0168] Unoccupied persistent memory segments refer to persistent memory segments in persistent memory pool device 7 that are not currently occupied by any host and can be allocated to a host.

[0169] Management device 1 can determine whether a persistent memory segment is not occupied by reading the segment occupancy flag in the management page or by querying the currently occupying host identifier in the pooling index table.

[0170] The target segment refers to the persistent memory segment that the management device 1 selects from a plurality of unoccupied persistent memory segments and prepares to allocate to the first host 21.

[0171] The management device 1 can select a target segment from multiple unoccupied persistent memory segments based on the segment numbering order, load balancing strategy, segment health status, or other allocation strategies. This embodiment does not limit this.

[0172] Updating the pooled index device 8 refers to the management device 1 updating the pooled index table stored in the pooled index device 8 after completing the allocation of the target segment. The pooled index table records the persistent memory segment identifier, the currently occupying host identifier, lease information, and the most recently committed sequence number. Updating the pooled index device 8 allows the management device 1 to prioritize querying the pooled index table during subsequent normal allocations and queries, instead of reading the management page every time.

[0173] In this embodiment, when the management device 1 allocates a persistent memory segment to the first host 21, it first selects the target segment from multiple unoccupied persistent memory segments, then generates lease information containing the lease code and lease round, and writes the lease information into the management page of the target segment itself. Then, it writes the first host 21 into the access control device 6 to establish the access relationship between the first host 21 and the target segment at the hardware or firmware level. Finally, it updates the pooled index device 8 to register the allocation result. This achieves the synchronous establishment of lease information, access relationship and index record during the allocation stage, which not only avoids the duplicate allocation of allocated segments, but also enables the target segment to have self-description capability, and provides a complete and consistent basis for subsequent revocation of access relationship, abnormal takeover judgment and cross-verification when the external index and the internal record of the segment are inconsistent.

[0174] In some embodiments, after the second host 22 takes over the persistent memory segment, the management device 1 updates the occupier identifier and lease information recorded in the management page of the persistent memory segment, and establishes the access relationship between the second host 22 and the persistent memory segment through the access control device 6, while the access relationship between the first host 21 and the persistent memory segment has been revoked.

[0175] The second host 22 taking over the persistent memory segment refers to the operation by which the management device 1, after confirming that the persistent memory segment can be taken over, transfers the access permissions and ownership information of the persistent memory segment from the first host 21 to the second host 22; after the second host 22 takes over, the second host 22 becomes the current host occupying the persistent memory segment, and can access and continue to process the data in the persistent memory segment.

[0176] Updating the host identifier recorded in the management page means that the management device 1 changes the currently occupied host identifier recorded in the management page of the persistent memory segment from the first host 21 identifier to the second host 22 identifier.

[0177] Updating the lease information recorded in the management page means that the management device 1 generates new lease information for the second host 22 to take over the persistent memory segment and writes the new lease information into the management page.

[0178] The new lease information includes a new lease code and a new lease round; the lease round can be incremented based on the original lease round of the first host 21, thereby invalidating the old lease information held by the first host 21.

[0179] Establishing an access relationship between the second host 22 and the persistent memory segment through the access control device 6 means that the management device 1 establishes an access relationship between the second host 22 and the persistent memory segment in the access control device 6, so that the second host 22 can actually access the persistent memory segment.

[0180] For example, establishing an access relationship can be manifested as adding an entry to the port access table that allows the second host 22 to access the persistent memory segment, opening a window for the second host 22 to access the persistent memory segment in the memory window configuration table, or establishing a mapping entry for the second host 22 to access the persistent memory segment in the host input / output memory management unit page table.

[0181] The revocation of the first host 21's access to the persistent memory segment means that before the second host 22 takes over the persistent memory segment, the management device 1 has revoked the first host 21's access to the persistent memory segment through the access control device 6.

[0182] For example, revocation can be manifested as removing the entry from the port access table that allows the first host 21 to access the persistent memory segment, closing the window in the memory window configuration table that allows the first host 21 to access the persistent memory segment, or removing the mapping entry in the host input / output memory management unit page table that allows the first host 21 to access the persistent memory segment. If the access relationship of the first host 21 has been revoked, it means that the first host 21 can no longer access the persistent memory segment.

[0183] In this embodiment, after the second host 22 takes over the persistent memory segment, the management device 1 first updates the host identifier and lease information recorded in the persistent memory segment management page. The lease rounds are incremented to invalidate the old lease of the first host 21. Then, the access control device 6 establishes the access relationship of the second host 22 to the persistent memory segment. At the same time, the access relationship of the first host 21 to the persistent memory segment has been revoked in the previous exception handling. Thus, the ownership record update, lease update and access permission transfer are completed in sequence, so that the second host 22 becomes the legitimate host occupying the persistent memory segment in terms of ownership, lease and access permission. This ensures that the second host 22 can access and continue to process data normally, and also ensures that the first host 21 cannot rewrite based on the old lease or old access relationship, thereby avoiding the first host 21 and the second host 22 from accessing the same persistent memory segment at the same time.

[0184] like Figure 4 As shown in the figure, embodiments of this application also provide a control method for a multi-host management system, the control method comprising: S1. Divide the persistent memory pool into multiple persistent memory segments, each of which includes a management page and a commit log page.

[0185] S2. When allocating a persistent memory segment to the first host 21, lease information is generated and written to the management page of the persistent memory segment. The access control device 6 establishes an access relationship between the first host 21 and the persistent memory segment, so that the first host 21 writes the write commit record to the commit log page of the persistent memory segment during the use of the persistent memory segment.

[0186] S3. When an anomaly is detected in the first host 21, first revoke the access relationship of the first host 21, and then read the management page and commit log page of the persistent memory segment.

[0187] S4. If the latest commit sequence number in the management page matches the latest valid commit record in the commit log page, then the persistent memory segment is handed over to the second host 22 for management.

[0188] S5. If there is a discrepancy, the persistent memory segment remains unallocatable, and the recoverable location is determined based on the previous valid commit record in the commit log page.

[0189] In step S1, the management device 1 divides the persistent memory pool device 7 into multiple independently allocable persistent memory segments, and sets up a management page and a commit log page in each persistent memory segment. The management page is used to record lease information and the most recent commit sequence number, and the commit log page is used to record the host's write commit records for the persistent memory segment. Since the management page and the commit log page are set inside the persistent memory segment itself, each persistent memory segment has self-description capability and can describe its own ownership and write history without relying on the external index of the management device 1.

[0190] In step S2, management device 1 generates lease information and writes it to the management page, enabling the persistent memory segment to record the lease status of this allocation. Access control device 6 establishes an access relationship for the first host 21, granting it access privileges. The writing of lease information to the management page and the establishment of the access relationship are independent yet complementary: ownership and lease records are stored within the persistent memory segment, while access privileges are recorded in the access control device 6. During the use of the persistent memory segment, the first driver device 3 writes write commit records to the commit log page.

[0191] In step S3, after detecting an anomaly in the first host 21, the first action of management device 1 is not to read data, but to revoke the access relationship of the first host 21. Since data remains in persistent memory after power loss, the first host 21 may only be in a state of apparent failure. If the access relationship is not revoked first, the first host 21 may continue writing to the old address after reconnecting, while the second host 22 may simultaneously write to the same persistent memory segment. Revoking the access relationship first blocks the write path of the first host 21 at the access control level, ensuring that subsequent reads represent the true state before the anomaly. After revoking the access relationship, management device 1 then reads the management page and commit log page to obtain the basis for subsequent consistency judgments.

[0192] In step S4, the most recent commit number in the management page represents the last successful commit as determined by management device 1, and the most recent valid commit record in the commit log page represents the last record that was actually written completely in the persistent memory segment. If both are consistent, it indicates that the last commit by the first host 21 has been completely written to persistent memory, the data state is clean, and the persistent memory segment can be safely handed over to the second host 22 for management. The second host 22 can then directly read and continue processing the data.

[0193] In step S5, the inconsistency between the two indicates that the first host 21 experienced a power outage or restart during the writing of the last commit record, resulting in the last commit record not being fully written and the data state being incomplete. If the persistent memory segment is directly allocated to the second host 22 at this time, the second host 22 may read only half of the data. Therefore, the management device 1 keeps the persistent memory segment unallocable and rolls back the previous valid commit record. Based on its write start offset and write length, it determines the recoverable position, allowing the second host 22 to continue processing from that position. This avoids using incompletely written data without losing the data that has already been fully committed.

[0194] The multi-host management system control method of this embodiment divides the persistent memory pool into persistent memory segments including management pages and commit log pages. During allocation, lease information is written to the management page and access relationships are established through the access control device 6. When an anomaly is detected in the first host 21, the access relationship is revoked first, and then the management page and commit log page are read. The second host 22 is given control based on whether the most recent commit sequence number is consistent with the most recent valid commit record, or the recoverable position is determined based on the previous valid commit record. This achieves self-description of persistent memory segments, independent control of access permissions, and secure takeover and consistency recovery after anomalies. It avoids the first host 21 and the second host 22 from writing to the same persistent memory segment at the same time due to the old access relationship not being invalid, and it also avoids using incompletely written records as valid data, thereby improving the security and reliability of the multi-host shared persistent memory pool during the fault recovery process.

[0195] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the control process of any of the above-described multi-host management systems during operation.

[0196] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0197] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the control process of any of the aforementioned multi-host management systems during operation.

[0198] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the control process of any of the above-described multi-host management systems during operation.

[0199] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0200] The foregoing has provided a detailed description of the multi-host management system, storage medium, and computer program product provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to aid in understanding the methods and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A multi-host management system, characterized in that, include: Management device, multiple hosts, first drive device, second drive device, access control device and persistent memory pool device; The management device is connected to the host, the access control device, and the persistent memory pool device respectively; the access control device is located on the access path between the host and the persistent memory pool device; the first driver device is located in a first host of the plurality of hosts, and the second driver device is located in a second host of the plurality of hosts; The persistent memory pool device includes multiple persistent memory segments, each of which includes a management page and a commit log page; The management device is used to allocate persistent memory segments to the first host, write lease information into the management page, and establish the access relationship of the first host to the persistent memory segment through the access control device. The first driver is used to write a write commit record to the commit log page during the period when the first host uses a persistent memory segment; The management device is also used to, when detecting an anomaly in the first host, first revoke the access relationship of the first host, and then read the management page and commit log page of the persistent memory segment; If the most recent commit sequence number matches the most recent valid commit record in the commit log page, then the persistent memory segment is handed over to the second host for management. If there is a discrepancy, the persistent memory segment remains unallocatable, and the recoverable location is determined based on the previous valid commit record.

2. The multi-host management system according to claim 1, characterized in that, The management device is also used to compare the lease code and lease round carried in the re-online request with the record in the management page of the corresponding persistent memory segment after receiving the first host re-online request; If the lease rounds are consistent and the persistent memory segment has not been taken over by the second host, then the first host is allowed to re-access the persistent memory segment; If the lease rounds are inconsistent, or if the persistent memory segment has been taken over by the second host, then the first host's write access to the original persistent memory segment is denied.

3. The multi-host management system according to claim 1, characterized in that, Also includes: A pooled indexing device, which is connected to the management device; The pooling index device is used to store the pooling index table, which records persistent memory segment identifiers, currently occupying host identifiers, lease information, and most recently committed sequence numbers. When the records in the pooling index table are inconsistent with the records in the management page of the persistent memory segment, the management device uses the records that have passed verification in the management page and the commit log page as the basis for recovery.

4. The multi-host management system according to claim 1, characterized in that, It also includes a high-speed interconnect switching device, which is connected between the host and the persistent memory pool device; The access control device is located in the high-speed interconnect switching device and is implemented using the port access table, memory window configuration table, or host input / output memory management unit page table in the high-speed interconnect switching device; the management device is used to close the access window corresponding to the first host after detecting an anomaly of the first host, and then read the management page and commit log page of the corresponding persistent memory segment.

5. The multi-host management system according to claim 1, characterized in that, The management device is also used to determine whether the persistent memory segment can be taken over by reading the segment occupancy flag, header checksum and the most recently committed sequence number in the management page, and first verifying the header checksum. If the header verification fails, the persistent memory segment will not be allocated to other hosts; If the header verification is successful, and the commit sequence number of the most recent valid commit record in the commit log page matches the most recent commit sequence number in the management page, the second host is allowed to take over the persistent memory segment.

6. The multi-host management system according to claim 5, characterized in that, The management device is further configured to mark the persistent memory segment as unallocatable when the most recent valid commit record in the commit log page is inconsistent with the most recent commit sequence number in the management page, and to determine a recoverable position based on the write start offset and write length of the previous valid commit record in the commit log page, and to notify the second host to continue processing from the recoverable position.

7. The multi-host management system according to claim 6, characterized in that, The management page is set at the beginning of the persistent memory segment and includes at least a fixed-length header record area and a header check area. The header verification area is used to store the verification value calculated based on the header record area; the management device is used to verify the header verification value before taking over the persistent memory segment, and not to directly allocate the persistent memory segment to other hosts if the verification fails.

8. The multi-host management system according to claim 1, characterized in that, Each commit record in the commit log page includes a commit sequence number, lease round, write start offset, write length, commit flag, and record check value; The first driving device is used to write the submission sequence number, the lease round, the write start offset and the write length first when writing the submission record, then write the record verification value, and finally write the submission flag.

9. The multi-host management system according to claim 8, characterized in that, The first driving device is also used to perform a cache write-back on the data range written by the business after the first host completes a persistent write; Write the commit record after the cache write-back is complete; Perform a cache write-back on the cache line containing the submitted record; Perform write order guarantee operation; After confirming that the submission record has been written to persistent memory, the submission sequence number is notified to the management device.

10. The multi-host management system according to claim 9, characterized in that, The first host includes a processor; the cache write-back is executed by the first driver device through a cache line write-back instruction or a cache line refresh optimization instruction provided by the processor, and the write order guarantee operation is executed by the first driver device through a storage fence instruction; With enhanced asynchronous data refresh protection, the first driver is used to replace the line-by-line cache write-back of the business data range with the persistent order guarantee mechanism provided by the platform, and the commit flag is still written last.

11. The multi-host management system according to claim 3, characterized in that, When allocating a persistent memory segment to the first host, the management device selects a target segment from unoccupied persistent memory segments, generates lease information, writes the lease information to the management page of the target segment, writes the first host to the access control device, and updates the pooling index device.

12. The multi-host management system according to claim 1, characterized in that, After the second host takes over the persistent memory segment, the management device updates the occupier identifier and lease information recorded in the management page of the persistent memory segment, and establishes the access relationship between the second host and the persistent memory segment through the access control device, while the access relationship between the first host and the persistent memory segment has been revoked.

13. The multi-host management system according to claim 1, characterized in that, The first host anomaly includes the first host heartbeat interruption, the first host restart, and the first host access link being disconnected; Revoking the access relationship of the first host includes removing the access relationship of the first host to the persistent memory segment it occupies from the access control device, or closing the access window of the corresponding host port in the high-speed interconnect switching device.

14. The multi-host management system according to claim 1, characterized in that, The management page is used to record the segment identifier, the currently occupying host identifier, lease information, segment occupancy marker, and header checksum. The lease information includes the lease code and the lease round.

15. A control method for a multi-host management system, characterized in that, The method, applied to the multi-host management system as described in any one of claims 1-12, comprises: The persistent memory pool is divided into multiple persistent memory segments, each of which includes a management page and a commit log page; When allocating a persistent memory segment to the first host, lease information is generated and written to the management page of the persistent memory segment. An access relationship between the first host and the persistent memory segment is established through an access control device, so that the first host writes a write commit record to the commit log page of the persistent memory segment during the use of the persistent memory segment. When an anomaly is detected in the first host, the access relationship of the first host is revoked first, and then the management page and commit log page of the persistent memory segment are read. If the most recent commit number in the management page matches the most recent valid commit record in the commit log page, then the persistent memory segment is handed over to the second host for management. If there is a discrepancy, the persistent memory segment remains unallocatable, and the recoverable location is determined based on the previous valid commit record in the commit log page.

Images