A method, device, terminal and medium for preventing data loss in peering process

Abstract

The present invention relates to a method, device, terminal and medium for avoiding data loss in a peering process. Before an OSD in a down state in a placement group starts up and enters the peering process, a historical epoch sequence is calculated, and by judging whether the historical epoch sequence contains an abandoned OSDmap version, it is determined whether data writing occurs in the placement group during the period of the historical epoch sequence, thereby avoiding the situation where data writing cannot be judged when data is written to the abandoned OSDmap version. The analyzed historical epoch sequence of data writing is not less than the actual situation, thereby avoiding missing data writing of the placement group. When an OSD in the placement group that has data writing during the down state starts up and enters the peering process, the status of the remaining OSDs in the placement group is detected. If the remaining OSDs are all in the down state, the peering process of the OSD is suspended, and the peering process is completed only after the remaining OSDs are started up, thereby avoiding data loss caused by the OSD completing the peering process alone when data is written to the placement group during the down state.

Description

Technical Field

[0001] The present invention relates to the technical field of improving distributed storage peering processes, and in particular to a method, device, terminal, and medium for preventing data loss in peering processes. Background Art

[0002] Distributed storage systems can consist of anywhere from a few to thousands of nodes. Their decentralization and multi-replica storage ensure high availability. Ceph achieves decentralization using the CRUSH algorithm. Both Ceph clients and OSD daemons use the CRUSH algorithm to efficiently calculate the location of object storage, rather than relying on a centralized lookup table. Furthermore, as the OSD daemon topology changes, such as when new nodes join or old ones leave, the CRUSH algorithm redistributes data across the OSDs, preventing the failure of a single OSD from impacting the entire cluster's storage. For each piece of data a user provides, Ceph automatically stores multiple copies (typically three) in the background, ensuring that data is not lost and can even remain online in the event of hard drive failure, server failure, or cabinet power outage. Ceph's responsibility is to promptly recover from failures and replace lost copies of data to maintain high data reliability.

[0003] During system initialization, when the OSD restarts, causing the placement group to be reloaded, or when a new placement group is created, the placement group initiates a peering process. When an OSD fails, or the addition or removal of an OSD causes the placement group's acting set to change, the placement group will re-initiate the peering process. This triggers the peering process, which enables the OSDs within a placement group to reach a consistent state. Once the master and slave replicas reach a consistent state, the placement group becomes active, and the peering process ends. However, at this point, the data on the three OSD replicas of the PG is not completely consistent. When the peering process actually begins, the past_interval is calculated and generated. The past_interval is closely related to the OSDmap version, but the OSDmap is not permanently saved. Under the current mechanism, only the most recent 500 OSDmap versions are retained if the cluster is operating properly. If an OSD that has been down for a long time is started up, it may cause the following problems: after the OSD that has been down for a long time is started up, the OSDmap version of the cluster may have changed many times. The OSDmap received by this OSD after startup is discontinuous, which will cause the calculated past_interval to be incorrect. If other members of this placement group are also in the down state, then this OSD may complete the peering process independently and become a new master. After other OSDs in the placement group are started, the new master will still be the OSD that has been down for a long time. This is the peering process after other OSDs are started. When other OSDs synchronize data with the master OSD, the data written during the OSD's down state will be deleted, causing serious data loss. Summary of the Invention

[0004] In order to solve the above technical problem or at least partially solve the above technical problem, the present invention provides a method, device, terminal and medium for avoiding peering process data loss.

[0005] In a first aspect, the present invention provides a method for preventing data loss in a peering process, comprising:

[0006] Before the OSD in the placement group that is in the down state starts and enters the peering process, the historical epoch sequence is calculated and it is determined whether the historical epoch sequence contains the abandoned OSDmap version. If it does, it is determined that data was written during the period when the placement group was in the historical epoch sequence while the OSD was in the down state;

[0007] When the OSD to which data is written to the placement group while it is in the down state starts and enters the peering process, it detects the status of the remaining OSDs in the placement group. If the remaining OSDs are all in the down state, the peering process of the OSD is suspended and the peering process is completed only after the remaining OSDs start. This avoids data loss caused by the OSD completing the peering process alone when data is written to the placement group while it is in the down state.

[0008] Furthermore, the abandoned OSDmap version is recorded in the OSD local maintenance; the monitor pushes the OSDmap version changed due to the OSD failure to the OSD in the placement group. After receiving the OSDmap version pushed by the monitor, the OSD determines whether the OSDmap version recorded in its local maintenance and the issued OSDmap version are continuous. If not, it means that the OSDmap version has been abandoned, and the abandoned OSDmap version is updated.

[0009] Furthermore, a method is added to determine whether data writing occurs by judging whether the historical epoch sequence contains the abandoned OSDmap version: each historical epoch sequence is traversed to see whether it contains the recorded abandoned OSDmap version. If the traversed historical epoch sequence contains the abandoned OSPmap version, it is determined that data writing occurs during the period when the placement group is in the historical epoch sequence while the OSD is in the down state.

[0010] Furthermore, when it is determined that data is written during the period when the placement group is in the historical epoch sequence while the OSD is in the down state, a write mark is added; when the OSD to which data is written during the placement group in the down state is started and enters the peering process, it is detected whether there is a write mark to determine whether data writing occurs.

[0011] Furthermore, the OSD where the data writing occurred is determined based on the up status of each OSD in the placement group during the historical epoch sequence period where the data writing occurred, and the status of the OSD where the data writing was determined to have occurred in the placement group is detected. If it is determined that the OSDs where the data writing occurred are all in the down status, the peering process of the OSD is suspended, and the peering process is completed only after the OSD where the data writing was determined to have occurred is started.

[0012] Furthermore, the OSDs that retain complete data are analyzed based on the OSDs that are in the up state in the placement group during all historical epoch sequence periods where data writes occurred; after the OSDs that retain complete data are restarted, the peering process is performed.

[0013] In a second aspect, the present invention provides an apparatus for preventing data loss in a peering process, comprising: a data write judgment module, wherein the data write judgment module calculates a historical epoch sequence before an OSD in a down state starts and enters the peering process, and determines whether the historical epoch sequence contains an abandoned OSDmap version. If so, the module determines that data writing occurs during a period when the placement group is in the historical epoch sequence during the period when the OSD is in the down state;

[0014] The peering process control module detects the status of the remaining OSDs in the placement group when the OSD to which data is written is started while the placement group is in the down state and enters the peering process. If the remaining OSDs are all in the down state, the peering process of the OSD is suspended and the peering process is completed only after the remaining OSDs are started.

[0015] Furthermore, the device for avoiding data loss in the peering process also includes: an abandoned OSDmap version maintenance module. When the monitor pushes the OSDmap version changed due to an OSD failure to the OSD in the placement group, the abandoned OSDmap version maintenance module receives the OSDmap version pushed by the monitor, determines whether the OSDmap version of its own local maintenance record and the issued OSDmap version are continuous, and if not continuous, it means that the OSDmap version has been abandoned, and updates the record of the abandoned OSDmap version.

[0016] In a third aspect, the present invention provides a terminal for avoiding data loss in a peering process, comprising: a processing unit, a bus unit, and a storage unit, wherein the bus unit connects the storage unit and the processing unit, the storage unit stores a computer program, and when the computer program is executed by the processing unit, the method for avoiding data loss in the peering process is implemented.

[0017] In a fourth aspect, the present invention provides a storage medium for implementing a method for avoiding data loss in a peering process, wherein the storage medium stores a computer program, and when the computer program is executed by a processor, the method for avoiding data loss in a peering process is implemented.

[0018] The above technical solution provided by the embodiment of the present invention has the following advantages compared with the prior art:

[0019] This application maintains abandoned OSDmap versions to ensure that there are no errors or incompleteness when calculating historical epoch sequences. Accurate calculation of historical epoch sequences ensures accurate analysis when determining whether data writes have occurred in a placement group. Furthermore, determining whether data writes have occurred in a placement group is achieved by determining whether the historical epoch sequence contains abandoned OSDmap versions. This avoids the situation where data write determination cannot be made when data is written to the abandoned OSDmap. The analyzed historical epoch sequence where data writes occurred is no less than the historical epoch sequence where data writes actually occurred, thereby avoiding the situation where missed determinations occur when determining whether data writes have occurred in a placement group. If it is included, it is determined that data writing occurs during the period when the placement group is in the historical epoch sequence while the OSD is in the down state; when the OSD to which data writing occurs in the placement group during the down state starts and enters the peering process, the status of the remaining OSDs in the placement group is detected. If the remaining OSDs are all in the down state, the peering process of the OSD is suspended, and the peering process is completed only after the remaining OSDs are started, so as to avoid data loss caused by the OSD completing the peering process alone when data is written to the placement group during the down state. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0021] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0022] Figure 1 A flowchart of a method for avoiding data loss in a peering process provided by an embodiment of the present invention;

[0023] Figure 2 A flowchart of an embodiment of the present invention providing a response to an OSDmap version pushed by a monitor for abandonment judgment and OSDmap version processing;

[0024] Figure 3 A schematic diagram of a historical epoch sequence set and a historical epoch sequence provided by an embodiment of the present invention;

[0025] Figure 4 A flowchart for determining whether data writing occurs in a historical epoch sequence provided by an embodiment of the present invention;

[0026] Figure 5 A schematic diagram of a device for preventing data loss in a peering process provided by an embodiment of the present invention;

[0027] Figure 6 A schematic diagram of a terminal for preventing data loss in a peering process provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0028] To make the purpose, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative efforts shall fall within the scope of protection of the present invention.

[0029] It should be noted that, in this document, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or apparatus comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or apparatus comprising the element.

[0030] The following are the meanings of the following terms, English terms, or abbreviations used in this article: OSD (Object-based Storage Device); Placement Group (PG), a logical unit of data distribution; MON (monitor), a storage system monitor; peering, the state in the placement group state machine that corresponds to the process of bringing the OSDs within the same placement group to a consistent state. When the master and slave replicas reach a consensus, peering ends and the placement group becomes active. The acting set is an ordered list of OSDs containing replicas for a placement group, with the first OSD being the primary. If the acting set for a placement group is [0, 1, 2], and OSD0 fails, the CRUSH algorithm reassigns the placement group's acting set to [3, 1, 2]. OSD3 now becomes the primary OSD for the placement group, but cannot handle read operations for the placement group because it currently has no data. Therefore, a temporary placement group is requested from the monitor, with OSD1 as the primary OSD for the temporary placement group. At this point, the acting set remains [0, 1, 2], and the up set becomes [1, 3, 2]. When OSD3 is populated with data, the up set of the placement group returns to the acting set, meaning both the acting set and the up set are [0, 1, 2].

[0031] Example 1

[0032] See Figure 1 As shown, the present invention provides a method for avoiding data loss in a peering process, comprising:

[0033] Respond to the OSDmap version pushed by the monitor to perform abandonment judgment and OSDmap version processing. Figure 2 As shown, the abandoned OSDmap version determination and OSDmap version processing in response to the monitor's push includes: after the storage system's monitor detects an OSD failure, it changes the OSDmap version and pushes the OSDmap version changed due to the OSD failure to the OSDs in the placement group. After receiving the OSDmap version pushed by the storage system's monitor, the OSD determines whether the OSDmap version locally maintained and recorded by the OSD and the OSDmap version pushed by the monitor are continuous. If not, it indicates that the OSDmap version has been abandoned, and the abandoned OSDmap version is updated. If they are continuous, it indicates that the OSDmap version has not been abandoned. The OSDmap version locally maintained and recorded by the OSD is updated.

[0034] Generates placement group state machine events based on the OSDmap version pushed by the monitor, triggering the peering process of the placement group. Before entering the peering process, calculates the historical epoch sequence set (past_intervals). Figure 3 As shown, the historical epoch sequence set is the set of historical epoch sequences (past_interval). A historical epoch sequence is a sequence of epochs from the OSDmapepoch within a placement group. The members of the placement group's acting set and up set for each epoch within the historical epoch sequence are consistent. The failure of an OSD outside the placement group does not change the placement group. However, the failure of an OSD within a placement group causes a change in the OSDs within the placement group, resulting in a different historical epoch sequence.

[0035] In the specific implementation process, please refer to Figure 4 As shown, before the OSD in the down state in the placement group is started and enters the peering process, the historical epoch sequence is calculated. After the historical epoch sequence is calculated, it is determined whether the historical epoch sequence contains the abandoned OSDmap version. If it is contained, it is determined that data writing occurs during the period when the placement group is in the historical epoch sequence during the period when the OSD is in the down state. Of course, if data writing is recorded in the non-abandoned OSDmap version, it is determined that data writing occurs during the placement group during the corresponding historical epoch sequence. Specifically, when determining whether the historical epoch sequence contains the abandoned OSDmap version, each historical epoch sequence is traversed to determine whether it contains the recorded abandoned OSDmap version. If the traversed historical epoch sequence contains the abandoned OSPmap version, it is determined that data writing occurs during the period when the placement group is in the historical epoch sequence during the period when the OSD is in the down state.

[0036] In a feasible implementation, when it is determined that data writing occurs during the period when the placement group is in a historical epoch sequence while the OSD is in a down state, a corresponding write mark is added to the historical epoch sequence; when the OSD to which data writing occurs during the placement group in the down state starts and enters the peering process, it is detected whether there is a write mark in its historical epoch sequence to determine whether data writing occurs.

[0037] When an OSD that has data written to a placement group while it is down starts up and enters the peering process, it checks the status of the remaining OSDs in the placement group. If all other OSDs are down, the peering process for that OSD is paused and the peering process is completed only after the remaining OSDs start up. This prevents data loss caused by an OSD completing the peering process alone when data is written to the placement group while it is down. If the remaining OSDs are up, the peering process continues.

[0038] In one feasible implementation, the OSD where the data was written is determined based on the up status of each OSD in the placement group during the historical epoch sequence period where the data was written. The status of the OSD where the data was written is detected in the current placement group. If all the OSDs where the data was written are in the down state, the peering process for the OSD is suspended until the OSD where the data was written is started up before completing the peering process.

[0039] In a feasible implementation, the OSDs that retain complete data are analyzed based on the OSDs in the up state in the placement group during all historical epoch sequence periods where data writing occurs; after the OSDs that retain complete data are restarted, the peering process is performed.

[0040] Example 2

[0041] See Figure 5 As shown, an embodiment of the present invention provides a device for preventing data loss in a peering process, including:

[0042] The abandoned OSDmap version maintenance module receives the OSDmap version pushed by the monitor due to an OSD failure to the OSDs in the placement group. It determines whether the OSDmap version maintained locally and the delivered OSDmap version are continuous. If not, it indicates that the OSDmap version has been abandoned. The module updates the abandoned OSDmap version. If they are continuous, it indicates that the OSDmap version has not been abandoned. The OSDmap version maintained locally by the OSD is updated.

[0043] A data write judgment module calculates the historical epoch sequence before the OSD in the down state starts and enters the peering process, and determines whether the historical epoch sequence contains the abandoned OSDmap version. If it does, it determines that data writing occurs during the period when the placement group is in the historical epoch sequence while the OSD is in the down state.

[0044] The peering process control module detects the status of the remaining OSDs in the placement group when the OSD to which data is written is started while the placement group is in the down state and enters the peering process. If the remaining OSDs are all in the down state, the peering process of the OSD is suspended and the peering process is completed only after the remaining OSDs are started.

[0045] This application maintains abandoned OSDmap versions to ensure that there are no errors or incompleteness when calculating historical epoch sequences. Accurate calculation of historical epoch sequences ensures accurate analysis when determining whether data writes have occurred in a placement group. Furthermore, determining whether data writes have occurred in a placement group is achieved by determining whether the historical epoch sequence contains abandoned OSDmap versions. This avoids the situation where data write determination cannot be made when data is written to the abandoned OSDmap. The analyzed historical epoch sequence where data writes occurred is no less than the historical epoch sequence where data writes actually occurred, thereby avoiding the situation where missed determinations occur when determining whether data writes have occurred in a placement group. If it is included, it is determined that data writing occurs during the period when the placement group is in the historical epoch sequence while the OSD is in the down state; when the OSD to which data writing occurs in the placement group during the down state starts and enters the peering process, the status of the remaining OSDs in the placement group is detected. If the remaining OSDs are all in the down state, the peering process of the OSD is suspended, and the peering process is completed only after the remaining OSDs are started, so as to avoid data loss caused by the OSD completing the peering process alone when data is written to the placement group during the down state.

[0046] Example 3

[0047] See Figure 6 As shown, an embodiment of the present invention provides a terminal for avoiding data loss in a peering process, comprising: a processing unit, a bus unit, and a storage unit, wherein the bus unit is connected to the storage unit and the processing unit, and the storage unit stores a computer program. When the computer program is executed by the processing unit, the method for avoiding data loss in the peering process is implemented.

[0048] Example 4

[0049] An embodiment of the present invention provides a storage medium for implementing a method for avoiding data loss in a peering process. The storage medium stores a computer program, and when the computer program is executed by a processor, the method for avoiding data loss in a peering process is implemented.

[0050] In the embodiments provided by the present invention, it should be understood that the disclosed structures and methods can be implemented in other ways. For example, the structural embodiments described above are merely illustrative. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interface, structure or unit, which can be electrical, mechanical or other forms.

[0051] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0052] In addition, the functional units in the various embodiments of the present invention may be integrated into a single processing unit, each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.

[0053] The foregoing description is intended only to provide specific embodiments of the present invention, which will enable those skilled in the art to understand and implement the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention is not intended to be limited to the embodiments shown herein, but is intended to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A method for avoiding data loss in peering process, characterized in that: include: Before the OSD in the down state in the placement group starts and enters the peering process, the historical epoch sequence is calculated. When determining whether data write occurs, the historical epoch sequence is increased to determine whether it contains the abandoned OSDmap version. If it does, it is determined that data write occurred in the placement group during the period of the historical epoch sequence when the OSD was in the down state. While in the down state, when the OSD to which data is written to the placement group starts and enters the peering process, the status of the remaining OSDs in the placement group is detected. If the remaining OSDs are all in the down state, the peering process of the OSD is suspended and the peering process is completed only after the remaining OSDs start. This avoids data loss caused by the OSD completing the peering process alone when data is written to the placement group during the down state.

2. The method for avoiding peering process data loss according to claim 1, characterized in that: The abandoned OSDmap version is recorded in the OSD local maintenance; the monitor pushes the OSDmap version changed due to the OSD failure to the OSD in the placement group. After receiving the OSDmap version pushed by the monitor, the OSD determines whether the OSDmap version recorded in its local maintenance record and the issued OSDmap version are continuous. If not, it means that the OSDmap version has been abandoned, and the abandoned OSDmap version is updated.

3. The method for avoiding peering process data loss according to claim 2, characterized in that: Add a method to determine whether data writing occurs by judging whether the historical epoch sequence contains the abandoned OSDmap version: traverse each historical epoch sequence to see if it contains the recorded abandoned OSDmap version. If the traversed historical epoch sequence contains the abandoned OSPmap version, determine whether data writing occurs in the placement group during the period of the historical epoch sequence when the OSD is in the down state.

4. The method for avoiding peering process data loss according to claim 1, characterized in that: Determine if data is written to the placement group during the historical epoch sequence while the OSD is in the down state, and add a write mark. When the OSD to which data is written to the placement group during the down state starts and enters the peering process, check whether the write mark exists to determine whether data is written.

5. The method for avoiding peering process data loss according to claim 1, characterized in that: Based on the up status of each OSD in the placement group during the historical epoch sequence period where data writing occurred, the OSD where data writing occurred is determined, and the status of the OSD where data writing is determined to have occurred in the placement group is detected. If it is determined that all OSDs where data writing has occurred are in the down state, the peering process of the OSD is suspended, and the peering process is completed only after the OSD where data writing is determined to have occurred is started.

6. The method for avoiding peering process data loss according to claim 5, characterized in that: In the placement group, the OSDs that retain complete data are analyzed based on the OSDs that are in the up state during all historical epoch sequence periods where data writes occurred. After the OSDs that retain complete data are restarted, the peering process is performed.

7. A device for preventing data loss in peering process, characterized in that: include: A data writing judgment module, which calculates the historical epoch sequence before the OSD in the down state starts and enters the peering process, and determines whether the historical epoch sequence contains the abandoned OSDmap version. If so, it is determined that data writing occurs in the placement group during the period of the historical epoch sequence when the OSD is in the down state; The peering process control module detects the status of the remaining OSDs in the placement group when the OSD to which data is written is started and enters the peering process during the period when the peering process is in the down state. If the remaining OSDs are all in the down state, the peering process of the OSD is suspended and the peering process is completed only after the remaining OSDs are started.

8. The device for preventing peering process data loss according to claim 7, characterized in that: Also includes: Abandoned OSDmap version maintenance module. When the monitor pushes the OSDmap version changed due to OSD failure to the OSD in the placement group, the abandoned OSDmap version maintenance module receives the OSDmap version pushed by the monitor, and determines whether the OSDmap version recorded in its own local maintenance record and the issued OSDmap version are continuous. If not, it means that the OSDmap version has been abandoned, and the abandoned OSDmap version is updated.

9. A terminal for preventing data loss in peering process, characterized in that: include: A processing unit, a bus unit and a storage unit, wherein the bus unit connects the storage unit and the processing unit, the storage unit stores a computer program, and when the computer program is executed by the processing unit, the method for avoiding data loss in the peering process according to any one of claims 1 to 6 is implemented.

10. A storage medium for implementing a method for avoiding data loss in a peering process, wherein the storage medium stores a computer program, characterized in that: When the computer program is executed by a processor, the method for avoiding peering process data loss according to any one of claims 1 to 6 is implemented.

Images