Distributed storage logical volume data recovery method and device, equipment and medium

Abstract

The embodiment of the invention provides a logical volume data recovery method and device for distributed storage, equipment and a medium, the method is applied to a storage node of a distributed storage system, and a logical volume corresponds to physical storage equipment. The method comprises the steps that under the condition that a logical volume is in a normal use state, target data of a preset size at the head of a physical storage device is written into a first set file; the target data comprises metadata of a physical volume, metadata of a volume group and metadata of a logical volume; and under the condition that the logical volume is in the fault state, writing the target data in the first set file into the head of the physical storage device. According to the embodiment of the invention, the data recovery of the logical volume can be realized, and after the data recovery of the logical volume, the normal mounting use of the logical volume and the normal starting of the OSD can be realized, so that the data integrity and consistency in the distributed storage system are improved.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of distributed storage technology, and in particular to a method, apparatus, device, and medium for recovering logical volume data of distributed storage. Background Art

[0002] In a Ceph-based distributed storage system, OSD (Object Storage Device) is responsible for operations such as storing, reading, and maintaining data consistency. It stores data on physical storage devices such as disks. LV (Logical Volume) is a storage unit obtained by abstracting and dividing the storage space of a physical storage device, and it relies on the physical storage device to exist. PV (Physical Volume) directly corresponds to a portion of the storage space on a physical storage device. Logical volumes provide flexible management methods for data storage by dividing the storage space of physical volumes. The size of the storage space corresponding to the logical volume can be dynamically adjusted by the user. OSD organizes and manages data based on the storage space provided by the logical volume, and allocates data to different storage spaces of the physical storage device, making data storage and access more efficient and orderly.

[0003] However, in the actual operation of distributed storage systems, when servers, as storage nodes, perform operations such as power on and off, hot swapping disks, or encounter hardware failures or operational errors, there is a probability that logical volumes on physical storage devices will be lost or damaged.

[0004] Once the logical volume is damaged, the OSD will be unable to start, and the data stored on the logical volume will be unreadable and unwritable. The risk of losing this data will increase, and the business related to this data may also be interrupted. Summary of the Invention

[0005] An embodiment of the present application provides a distributed storage logical volume data recovery method, which can realize logical volume data recovery. After the logical volume data is recovered, the logical volume can be normally mounted and used and the OSD can be normally started, thereby improving the data integrity and consistency in the distributed storage system.

[0006] Correspondingly, an embodiment of the present application also provides a distributed storage logical volume data recovery device, an electronic device and a machine-readable medium to ensure the implementation and application of the above method.

[0007] To solve the above problems, an embodiment of the present application discloses a method for recovering logical volume data in distributed storage. The method is applied to a storage node of a distributed storage system, where the logical volume corresponds to a physical storage device. The method includes:

[0008] When the logical volume is in normal use, target data of a preset size at the head of the physical storage device is written into a first setting file; the target data includes metadata of the physical volume, metadata of the volume group, and metadata of the logical volume;

[0009] When the logical volume is in a failed state, the target data in the first setting file is written into the header of the physical storage device.

[0010] To solve the above problems, an embodiment of the present application discloses a distributed storage logical volume data recovery device, which is applied to a storage node of a distributed storage system, wherein the logical volume corresponds to a physical storage device; the device includes:

[0011] A first target data processing module is configured to write target data of a preset size at the header of the physical storage device into a first setting file when the logical volume is in normal use; the target data includes metadata of the physical volume, metadata of the volume group, and metadata of the logical volume;

[0012] The second target data processing module is configured to write the target data in the first setting file into the header of the physical storage device when the logical volume is in a fault state.

[0013] Optionally, the device further comprises:

[0014] a startup detection module, configured to restart the object storage device if the object storage device cannot be started and detect the status of the object storage device before writing the target data in the first setting file to the header of the physical storage device when the logical volume is in a faulty state;

[0015] The fault determination module is configured to determine that the logical volume is in a fault state if the state of the object storage device is a state in which the device cannot be started normally.

[0016] Optionally, the preset size is N megabytes, where N is a positive integer.

[0017] Optionally, the second target data processing module includes:

[0018] The target data copy module is used to use the file copy command to read data of a preset size from the first setting file according to the preset block size, and write the read data into the head of the physical storage device.

[0019] Optionally, the second target data processing module includes:

[0020] A recovery module, configured to recover the physical volume and the volume group based on the universal unique identifier of the physical volume, the metadata of the physical volume, and the metadata of the volume group provided by the logical volume management mechanism when the logical volume is in a fault state;

[0021] A status detection module is used to detect the status of the object storage device after the volume group is activated after recovery;

[0022] The target data writing module is configured to write the target data in the first setting file into the header of the physical storage device if the state of the object storage device is a state in which the device cannot be started normally.

[0023] Optionally, the device further comprises:

[0024] a configuration file processing module, configured to provide the physical volume's universally unique identifier, the physical volume's metadata, and the volume group's metadata in the operating system's configuration file for the logical volume management mechanism when the logical volume is in normal use; and / or

[0025] The query result processing module is used to obtain a query result obtained by a command provided by the logical volume management mechanism when the logical volume is in normal use, obtain the universal unique identifier of the physical volume, the metadata of the physical volume, and the metadata of the volume group from the query result, and write the obtained universal unique identifier of the physical volume, the metadata of the physical volume, and the metadata of the volume group into a second setting file.

[0026] Optionally, the recovery module includes:

[0027] a physical volume recovery module, configured to create a target physical volume corresponding to the universal unique identifier on the physical storage device, and set metadata of the target physical volume using metadata of the physical volume;

[0028] The volume group recovery module is used to recover the volume group where the target physical volume is located according to the metadata of the volume group.

[0029] An embodiment of the present application further discloses an electronic device, comprising: a processor; and a memory on which executable code is stored. When the executable code is executed, the processor executes the method described in the embodiment of the present application.

[0030] The embodiment of the present application further discloses a machine-readable medium having executable code stored thereon. When the executable code is executed, the processor executes the method described in the embodiment of the present application.

[0031] The embodiments of the present application include the following advantages:

[0032] In the technical solution of an embodiment of the present application, when the logical volume is in normal use, the target data of a preset size at the head of the physical storage device is written into the first setting file, and when the logical volume is in a faulty state, the target data in the first setting file is written into the head of the physical storage device.

[0033] The above target data specifically includes: metadata of the physical volume, metadata of the volume group and metadata of the logical volume. These metadata contain complete description information of the logical volume in the distributed storage system.

[0034] Among them, the metadata of the logical volume records key information such as the name, size, location, file system type, etc. of the logical volume. This information allows the distributed storage system to accurately find the starting and ending positions of the logical volume in the physical storage, as well as identify its file system format, so as to correctly mount and access the data on the logical volume.

[0035] The volume group metadata includes the volume group name, status, physical volume list, etc. With this information, the distributed storage system can understand the volume group to which the logical volume belongs, the physical volumes that make up the volume group, and thus clearly identify the physical volumes on which the logical volume data is distributed.

[0036] The physical volume metadata records information such as the physical storage device identifier, capacity, and partition layout corresponding to the physical volume. This helps the distributed storage system determine each physical volume's available space, allocated space, and its relationship to logical volumes and volume groups. Based on this information, the distributed storage system can read data from the correct physical volume location to restore the logical volume.

[0037] Therefore, by writing the metadata for each physical volume, volume group, and logical volume into the physical storage device header, the distributed storage system can reconstruct the mapping relationship between the logical volume and the storage space of the physical storage device using this metadata recorded in the storage device header. Based on this mapping relationship, the distributed storage system can locate the data storage location of the logical volume and read the data stored on the logical volume, thereby successfully achieving data recovery of the logical volume.

[0038] Moreover, based on this mapping relationship, the OSD in the distributed storage system can correctly identify the location of the logical volume and its data on the physical storage device, and then perform normal operations such as reading data and initializing the storage device. Therefore, the embodiment of the present application can achieve normal startup of the OSD.

[0039] In summary, the embodiments of the present application can be used to realize data recovery of logical volumes when the logical volumes are lost or damaged. After the logical volume data is recovered, the logical volumes can be mounted and used normally and the OSD can be started normally, thereby improving the data integrity and consistency in the distributed storage system. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Figure 1 This is a schematic diagram of the structure of the LVM architecture of an embodiment of the present application;

[0041] Figure 2 This is a schematic flow chart of the steps of a distributed storage logical volume data recovery method according to an embodiment of the present application;

[0042] Figure 3 This is a schematic flow chart of the steps of a distributed storage logical volume data recovery method according to an embodiment of the present application;

[0043] Figure 4 This is a schematic flow chart of the steps of a distributed storage logical volume data recovery method according to an embodiment of the present application;

[0044] Figure 5 This is a schematic diagram of the structure of a distributed storage logical volume data recovery device according to an embodiment of the present application;

[0045] Figure 6 It is a structural diagram of a device provided in one embodiment of the present application. DETAILED DESCRIPTION

[0046] In order to make the above-mentioned purposes, features and advantages of the present application more obvious and easy to understand, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0047] A distributed storage system usually includes multiple storage nodes. In the embodiment of the present application, LVM (Logical Volume Manager) is a mechanism for managing storage nodes in the Linux system. LVM first identifies the physical storage devices on the storage nodes and marks them as physical volumes; then it combines multiple physical volumes into volume groups, and then divides logical volumes from the volume groups; then, the logical volumes can be formatted into different file systems and can be used directly after being mounted to the operating system. This is an effective way to provide storage services to the outside world. LVM can adjust the size of the logical volume as needed, and also supports functions such as snapshots, which improves storage management efficiency and data security.

[0048] Reference Figure 1 , shows a structural diagram of the LVM architecture of an embodiment of the present application, which includes, from bottom to top, physical partitions, physical volumes, physical areas, volume groups, logical areas, logical volumes, and file systems.

[0049] Among them, PP (Physical Partition): located at the bottom layer of the LVM architecture, is a physical storage device or a partition divided from a physical storage device.

[0050] A physical volume is the basic logical unit of storage in LVM. It typically refers to a disk or a block device that is logically equivalent to a disk, such as a physical hard disk or RAID (Redundant Array of Independent Disks). Compared to ordinary physical storage devices, a physical volume contains LVM-specific management parameters to support LVM's flexible management and allocation of storage resources.

[0051] A physical extent (PE) is the smallest unit of storage that can be allocated within a physical volume. The size of a physical extent is specified when a volume group is created and cannot be changed. It is typically the same for all physical volumes within the same volume group. The physical extent size can be 1, 2, 4, 8, ..., 64 MB (megabyte), etc.

[0052] VG (Volume Group) is built on physical volumes. A volume group can include one or more physical volumes.

[0053] Logical volumes are created based on volume groups. Unallocated space in a volume group can be used to create new logical volumes. Once a logical volume is created, its space can be dynamically expanded or reduced.

[0054] LE (logical extent) is the smallest storage unit that can be used for allocation in a logical volume. The size of the logical area depends on the size of the physical area in the volume group where the logical volume is located.

[0055] A logical volume may be formatted with a file system, which is used to store and manage files.

[0056] In the embodiment of the present application, the situation where the logical volume on the physical storage device is lost or damaged may correspond to the following application scenarios:

[0057] Hardware failure: Hard disk damage or bad sectors may cause the logical volume on this hard disk to be damaged or lost, or the file system to be damaged, resulting in the OSD being unable to start.

[0058] Operational errors: Inadvertent operations such as deleting logical volumes, reinstalling the system, etc. will also cause the logical volumes to be lost and the OSD cannot be started.

[0059] Virus attacks: Sometimes they can cause logical volume or file system damage and data loss, which can lead to the inability to mount the file system and the inability to start the OSD.

[0060] In response to the technical problems of OSD startup failure, data loss and business interruption caused by logical volume damage in traditional technologies, an embodiment of the present application provides a distributed storage logical volume data recovery method, which is applied to the storage node of the distributed storage system, and the logical volume corresponds to the physical storage device; the method specifically includes: when the logical volume is in normal use, writing the target data of a preset size at the head of the physical storage device into a first setting file; the above-mentioned target data specifically includes: metadata of the physical volume, metadata of the volume group and metadata of the logical volume; when the logical volume is in a faulty state, writing the target data in the first setting file into the head of the physical storage device.

[0061] In an embodiment of the present application, when the logical volume is in normal use, target data of a preset size at the head of the physical storage device is written into a first setting file, and when the logical volume is in a fault state, the target data in the first setting file is written into the head of the physical storage device.

[0062] The above target data specifically includes: metadata of the physical volume, metadata of the volume group and metadata of the logical volume. These metadata contain complete description information of the logical volume in the distributed storage system.

[0063] Among them, the metadata of the logical volume records key information such as the name, size, location, file system type, etc. of the logical volume. This information allows the distributed storage system to accurately find the starting and ending positions of the logical volume in the physical storage, as well as identify its file system format, so as to correctly mount and access the data on the logical volume.

[0064] The volume group metadata records the volume group's name, status, physical volume list, etc. With this information, the distributed storage system can understand the volume group to which the logical volume belongs, the physical volumes that make up the volume group, and thus clearly identify the physical volumes on which the logical volume's data is distributed.

[0065] The physical volume metadata records information such as the physical storage device identifier, capacity, and partition layout corresponding to the physical volume. This helps the distributed storage system determine each physical volume's available space, allocated space, and its relationship to logical volumes and volume groups. Based on this information, the distributed storage system can read data from the correct physical volume location to restore the logical volume.

[0066] Therefore, by writing the metadata for each physical volume, volume group, and logical volume into the physical storage device header, the distributed storage system can reconstruct the mapping relationship between the logical volume and the storage space of the physical storage device using this metadata recorded in the storage device header. Based on this mapping relationship, the distributed storage system can locate the data storage location of the logical volume and read the data stored on the logical volume, thereby successfully achieving data recovery of the logical volume.

[0067] Moreover, based on this mapping relationship, the OSD in the distributed storage system can correctly identify the location of the logical volume and its data on the physical storage device, and then perform normal operations such as reading data and initializing the storage device. Therefore, the embodiment of the present application can achieve normal startup of the OSD.

[0068] In summary, the embodiments of the present application can be used to recover logical volume data when the logical volume is lost or damaged. After the logical volume data is recovered, the logical volume can be mounted and used normally and the OSD can be started normally, thereby improving the data integrity and consistency in the distributed storage system.

[0069] The following describes the distributed storage logical volume data recovery method of the embodiment of the present application through specific examples.

[0070] Method Example 1

[0071] Reference Figure 2 , shows a schematic flow chart of the steps of a method for recovering logical volume data of distributed storage according to an embodiment of the present application. The method is applied to a storage node of a distributed storage system, and the logical volume corresponds to a physical storage device. The method may specifically include the following steps:

[0072] Step 201: When the logical volume is in normal use, write target data of a preset size in the header of the physical storage device into a first setting file; the target data specifically includes: metadata of the physical volume, metadata of the volume group, and metadata of the logical volume;

[0073] Step 202: When the logical volume is in a fault state, write the target data in the first setting file into the header of the physical storage device.

[0074] The embodiments of the present application can be applied to any distributed storage system. For example, the distributed storage system may include Ceph, Hadoop HDFS (Hadoop Distributed File System), etc.

[0075] Among them, Ceph is an open source distributed storage platform that implements object storage on a unified distributed computer cluster and provides a three-in-one interface for object-level, block-level and file-level storage.

[0076] Hadoop HDFS distributes data across multiple nodes based on block storage and provides data redundancy and fault tolerance mechanisms to improve data reliability and availability.

[0077] A storage node in a distributed storage system is a physical or logical unit responsible for actual data storage and management within the distributed storage system. From a hardware perspective, a storage node is typically a server with a certain amount of storage capacity (such as physical storage devices like hard drives and solid-state drives), computing power, and network connectivity. From a software perspective, a storage node runs software components related to the distributed storage system. These software components are responsible for managing local storage resources, processing data read and write requests, and communicating and collaborating with other nodes to implement the functions of the entire distributed storage system. For example, in the Ceph storage system, the OSD daemon runs on the storage node, responsible for operations such as object storage, retrieval, and replication. Data is the information content that users actually need to store and manage, while objects are the logical units that Ceph uses to organize and manage data.

[0078] The status of a logical volume specifically includes: normal use status and fault status.

[0079] The normal usage status of a logical volume means that the logical volume can respond normally to various read and write requests, data can be stored and read correctly, and the storage node can stably run various applications and services based on the logical volume without any errors or abnormalities that affect its normal functions.

[0080] A faulty state refers to a configuration issue with the logical volume that prevents it from functioning properly or affects data integrity and availability. Configuration issues may include hardware failures (such as hard drive damage or controller failure), software errors (such as file system corruption or driver issues), logical errors (such as volume configuration errors or permissions issues), and other situations that may prevent the logical volume from providing services properly, such as data loss, mount failures, or read / write errors.

[0081] The embodiments of the present application do not limit the specific method for determining the state of a logical volume. For example, in a Linux system, a command line tool can be used to view logical volume information. The output of the command line tool can include: logical volume status information. If the logical volume status information is in an activated state, it indicates that the logical volume is in normal use; if the logical volume status information is in an inactivated state, it indicates that the logical volume is in a faulty state.

[0082] For another example, information about the logical volume status can be obtained from the system log. If the system log contains error information corresponding to the logical volume, it can be determined that the logical volume is in a faulty state. If the system log does not record any error information related to the logical volume, it can be determined that the logical volume is in a normal operating state.

[0083] For example, the embodiments of the present application can also use the file system mounting status (normal mounting and reading and writing are normal, otherwise there may be a fault), storage management tools (such as LVM), disk I / O (input and output, Input / Output) performance monitoring and hardware level inspection (check the disk array card indicator light, disk array management tool to detect disk health, etc. to determine the status of the physical storage device, and then infer the status of the logical volume) and other judgment methods to determine the status of the logical volume.

[0084] In step 201, when the logical volume is in normal use, the target data of the preset size in the head of the physical storage device is written into the first setting file. The file path of the first setting condition can be determined by those skilled in the art according to actual application requirements.

[0085] When the logical volume is in normal use, the embodiment of the present application can write target data of a preset size in the header of the physical storage device into the first setting file when a preset trigger condition is met.

[0086] For example, the preset trigger condition may be a periodic trigger condition. Specifically, the target data writing operation may be performed at fixed time intervals, such as once every hour, every day, or every week.

[0087] For another example, the preset trigger condition may be a data change trigger condition. Specifically, when the data on the physical storage device changes to a certain extent, a write operation of the target data is triggered. Whether the data on the physical storage device has changed can be determined by monitoring changes in the file system or I / O operations of the logical volume.

[0088] For example, when the change in the number of files or the change in the file size on the logical volume exceeds a certain threshold, the target data in the header of the physical storage device is written into the first setting file.

[0089] The above target data specifically includes: metadata of the physical volume, metadata of the volume group and metadata of the logical volume. These metadata contain complete description information of the logical volume in the distributed storage system.

[0090] Among them, the metadata of the logical volume records key information such as the name, size, location, file system type, etc. of the logical volume. This information allows the distributed storage system to accurately find the starting and ending positions of the logical volume in the physical storage, as well as identify its file system format, so as to correctly mount and access the data on the logical volume.

[0091] The volume group metadata records the volume group's name, status, physical volume list, etc. With this information, the distributed storage system can understand the volume group to which the logical volume belongs, the physical volumes that make up the volume group, and thus clearly identify the physical volumes on which the logical volume's data is distributed.

[0092] The physical volume metadata records information such as the physical storage device identifier, capacity, and partition layout corresponding to the physical volume. This helps the distributed storage system determine each physical volume's available space, allocated space, and its relationship to logical volumes and volume groups. Based on this information, the distributed storage system can read data from the correct physical volume location to restore the logical volume.

[0093] In a specific implementation, the preset size may be N megabytes, where N is a positive integer. Those skilled in the art may determine the value of N based on the specific storage space occupied by the target data. For example, N may be in the range of [2, 8]. For example, when the logical volume is in normal use, embodiments of the present application may write the first 4 megabytes of target data at the head of the physical storage device into the first setting file.

[0094] In actual applications, a file copy command may be used to read target data of a preset size from the header of the physical storage device, and write the target data into the first setting file.

[0095] The file copy command in Linux can be the dd command. For example, in "dd if= / dev / sdx of= / home / backup / metadata.imgoflag=direct", "if= / dev / sdx" specifies reading the target data from / dev / sdx (representing the physical storage device) as input, "of= / home / backup / metadata.img" indicates writing the read target data to the first setting file corresponding to " / home / backup / metadata.img" as output, and "oflag=direct" indicates enabling direct I / O (Input / Output) mode, allowing the target data to be transferred directly between user space and the device, reducing the number of memory copies and improving I / O performance.

[0096] In one implementation, before writing the target data in the first setting file to the header of the physical storage device when the logical volume is in a faulty state, the method of the embodiment of the present application may further include: if the object storage device cannot be started, restarting and detecting the status of the object storage device; if the status of the object storage device is a state that cannot be started normally, determining that the logical volume is in a faulty state.

[0097] In practice, you can use the OSD status query commands provided by the distributed storage system to query the OSD status. For example, the query results of the "ceph osd status" command in the Ceph distributed storage system include the number and status of each OSD. "Up" indicates normal operation, "Down" indicates non-operating or disconnected from the cluster, and "Unknown" indicates an uncertain status. "Down" can indicate a state in which the OSD cannot start normally.

[0098] In step 202, if the logical volume is in a faulty state, the target data in the first configuration file is written to the physical storage device header. Writing metadata for the physical volume, volume group, and logical volume to the physical storage device header allows the distributed storage system to reconstruct the mapping relationship between the logical volume and the storage space of the physical storage device using this metadata recorded in the storage device header. Based on this mapping relationship, the distributed storage system can locate the data storage location of the logical volume and read the data stored on the logical volume, thereby successfully achieving data recovery of the logical volume.

[0099] In a specific implementation, writing the target data in the first setting file to the header of the physical storage device may include: using a file copy command to read a preset size of data from the first setting file according to a preset block size, and writing the read data to the header of the physical storage device. The preset block size specifically refers to the amount of data read from the first setting file and written to the header of the physical storage device during each data copy operation.

[0100] For example, in the file copy command "dd if= / home / backup / metadata.img of= / dev / sdx iflag=directbs=1Mcount=4", "bs" is a parameter used to specify the preset block size. bs=1M means that the preset block size is 1 megabyte, that is, 1 megabyte of data is read from the first setting file " / home / backup / metadata.img" each time, and 1 megabyte of data is written to the physical storage device " / dev / sdx" each time; "count=4" means that a total of 4 such read and write operations are performed, so a total of 4 megabytes of data will be read from " / home / backup / metadata.img" and written to the header of the physical storage device; "iflag=direct" means using direct I / O mode, so that the target data is transferred directly between user space and the device.

[0101] After writing the target data in the first setting file into the physical storage device header, the volume group corresponding to the physical storage device can be activated, and after activating the volume group, the object storage device can be started; and after starting the object storage device, the status of the logical volume and the object storage device can be checked.

[0102] Among them, after the target data in the first setting file is written to the header of the physical storage device, the corresponding volume group is activated to enable the distributed storage system to recognize and use the logical volumes in the volume group to prepare for data reading and writing; then the object storage device is started to join the storage cluster and provide data storage and access services; the status of the logical volume and object storage device is checked to detect whether the entire distributed storage system has successfully restored normal operation. If there is an abnormality, return to execute steps 201 and 202 to perform data recovery, thereby improving the availability and stability of the distributed storage system.

[0103] A volume group is a concept in the Logical Volume Manager (LVM). It combines multiple physical storage devices into a single logical unit, facilitating storage space management and allocation. After activating the volume group corresponding to a physical storage device, the distributed storage system can identify and use the logical volumes within the volume group, preparing for subsequent data read and write operations.

[0104] In Linux, you can use the volume group activation command provided by the Logical Volume Manager to activate a volume group. For example, the "vgchange -ay vgtest" command is a volume group activation command. "vgchange" is used to change the attributes and status of a volume group; "-ay" is an option to the "vgchange" command, where "a" stands for activation and "y" indicates the default confirmation action; "vgtest" is the name of the volume group, which can be obtained from the volume group metadata. Therefore, "vgchange -ay vgtest" is used to activate the volume group named "vgtest."

[0105] Object storage devices are responsible for storing and managing data objects in a distributed storage system. Once started, an object storage device joins the storage cluster and begins providing data storage and access services, restoring the entire distributed storage system to normal operation.

[0106] In Linux, you can use the OSD startup command provided by the logical volume manager to start the OSD. Restart the OSD. For example, the "systemctl restart ceph-osd@xxx.service" command is used to restart the Ceph OSD service with a specified number. In this command, "systemctl" represents the command line tool of the systemd (system daemon) service manager in the Linux system; "restart" means restarting the service; "ceph-osd@xxx.service" represents the unit name of the OSD service in the Ceph distributed storage system, and "xxx" represents the OSD number. Therefore, the purpose of this command is to restart the Ceph OSD service with a specified number.

[0107] After starting the object storage device, check the status of the logical volumes and object storage devices to verify that the entire distributed storage system has been successfully restored and is functioning properly. Checking the status of the logical volumes confirms that they can be mounted and read / written normally; checking the status of the object storage devices confirms that they are communicating properly with the storage cluster. If the logical volumes are in the active state, you can confirm that they can be mounted and read / written normally. If the object storage device is in the "up" state, it indicates that the object storage device is functioning properly.

[0108] If both the logical volume status and the object storage device status are normal, the entire distributed storage system has successfully resumed normal operation. If either the logical volume status or the object storage device status is abnormal, the process returns to steps 201 and 202 for data recovery, thereby improving the availability and stability of the distributed storage system.

[0109] In summary, the distributed storage logical volume data recovery method of an embodiment of the present application writes target data of a preset size at the head of a physical storage device into a first setting file when the logical volume is in normal use, and writes the target data in the first setting file into the head of the physical storage device when the logical volume is in a faulty state.

[0110] The above target data specifically includes: metadata of the physical volume, metadata of the volume group and metadata of the logical volume. These metadata contain complete description information of the logical volume in the distributed storage system.

[0111] Among them, the metadata of the logical volume records key information such as the name, size, location, file system type, etc. of the logical volume. This information allows the distributed storage system to accurately find the starting and ending positions of the logical volume in the physical storage, as well as identify its file system format, so as to correctly mount and access the data on the logical volume.

[0112] The volume group metadata includes the volume group name, status, physical volume list, etc. With this information, the distributed storage system can understand the volume group to which the logical volume belongs, the physical volumes that make up the volume group, and thus clearly identify the physical volumes on which the logical volume data is distributed.

[0113] The physical volume metadata records information such as the physical storage device identifier, capacity, and partition layout corresponding to the physical volume. This helps the distributed storage system determine each physical volume's available space, allocated space, and its relationship to logical volumes and volume groups. Based on this information, the distributed storage system can read data from the correct physical volume location to restore the logical volume.

[0114] Therefore, by writing the metadata for each physical volume, volume group, and logical volume into the physical storage device header, the distributed storage system can reconstruct the mapping relationship between the logical volume and the storage space of the physical storage device using this metadata recorded in the storage device header. Based on this mapping relationship, the distributed storage system can locate the data storage location of the logical volume and read the data stored on the logical volume, thereby successfully achieving data recovery of the logical volume.

[0115] Moreover, based on this mapping relationship, the OSD in the distributed storage system can correctly identify the location of the logical volume and its data on the physical storage device, and then perform normal operations such as reading data and initializing the storage device. Therefore, the embodiment of the present application can achieve normal startup of the OSD.

[0116] In summary, the embodiments of the present application can be used to realize data recovery of logical volumes when the logical volumes are lost or damaged. After the logical volume data is recovered, the logical volumes can be mounted and used normally and the OSD can be started normally, thereby improving the data integrity and consistency in the distributed storage system.

[0117] The embodiments of the present application can be applied to the following application scenarios:

[0118] Hardware failure: In the case where a hardware failure causes the OSD to be unable to start, the embodiment of the present application can achieve normal mounting and use of the logical volume and normal startup of the OSD based on logical volume data recovery, thereby improving the data integrity and consistency in the distributed storage system.

[0119] Operational error: In the event that an OSD cannot be started due to an operational error, the embodiment of the present application can achieve normal mounting and use of the logical volume and normal startup of the OSD based on logical volume data recovery, thereby improving data integrity and consistency in the distributed storage system.

[0120] Virus attack: In the case where a virus attack causes the OSD to be unable to start, the embodiment of the present application can achieve normal mounting and use of the logical volume and normal startup of the OSD based on logical volume data recovery, thereby improving the data integrity and consistency in the distributed storage system.

[0121] Disaster recovery: When the disk logical volume data is damaged or lost due to environmental temperature, humidity or unexpected events, the embodiment of the present application can achieve normal mounting and use of the logical volume and normal startup of the OSD based on logical volume data recovery, thereby improving the data integrity and consistency in the distributed storage system.

[0122] System upgrade: During the operating system upgrade process, data incompatibility or logical damage may occur. The embodiment of the present application can realize the normal mounting and use of logical volumes and normal startup of OSD based on logical volume data recovery, and can realize a smooth upgrade of the operating system.

[0123] Data migration: During data center migration or cloud service migration, the embodiments of the present application can achieve normal mounting and use of logical volumes and normal startup of OSD based on logical volume data recovery, thereby improving data integrity and consistency in the distributed storage system.

[0124] Data security: In the event of data damage caused by a network attack or malware, the method of the embodiment of the present application can be used as part of a data security strategy to help recover the damaged data.

[0125] Business continuity plan: As part of a business continuity plan, the method of the embodiment of the present application can achieve rapid recovery of critical business data in the event of data loss or damage.

[0126] Method Example 2

[0127] Reference Figure 3 , shows a schematic flow chart of the steps of a method for recovering logical volume data of distributed storage according to an embodiment of the present application. The method is applied to a storage node of a distributed storage system, and the logical volume corresponds to a physical storage device. The method may specifically include the following steps:

[0128] Step 301: When the logical volume is in normal use, write target data of a preset size in the header of the physical storage device into a first setting file; the target data specifically includes: metadata of the physical volume, metadata of the volume group, and metadata of the logical volume;

[0129] Step 302: When the logical volume is in a faulty state, the physical volume and volume group are recovered based on the physical volume's universal unique identifier, the physical volume's metadata, and the volume group's metadata provided by the logical volume management mechanism to obtain a recovered volume group.

[0130] Step 303: After activating the restored volume group, detecting the status of the object storage device;

[0131] Step 304: If the state of the object storage device is a state where it cannot be started normally, the target data in the first setting file is written into the header of the physical storage device.

[0132] In an embodiment of the present application, when a logical volume of a distributed storage system fails, the physical volume universal unique identifier, physical volume metadata, and volume group metadata provided by the logical volume management mechanism are preferentially used to perform recovery operations on the physical volume and volume group. After successfully activating the restored volume group, the operating status of the object storage device is further detected. If the object storage device still cannot start normally, it indicates that the data recovery of the logical volume cannot be effectively achieved only through the recovery of the physical volume and volume group. At this time, the target data (including metadata of the physical volume, volume group, and logical volume) that was previously backed up in the first setting file will be called and written into the header of the physical storage device. By restoring the key metadata information, the logical volume data can be recovered, thereby achieving stable operation and data availability of the distributed storage system.

[0133] The embodiment of the present application can perform the following processing based on the physical volume universal unique identifier, physical volume metadata, and volume group metadata provided by the logical volume management mechanism:

[0134] Process 1: When the logical volume is in normal use, provide the physical volume's UUID (Universally Unique Identifier), the physical volume's metadata, and the volume group's metadata in the operating system's configuration file for the logical volume management mechanism; and / or

[0135] Process 2: When the logical volume is in normal use, obtain a query result obtained by a command provided by the logical volume management mechanism, obtain the universally unique identifier of the physical volume, the metadata of the physical volume, and the metadata of the volume group from the query result, and write the obtained universally unique identifier of the physical volume, the metadata of the physical volume, and the metadata of the volume group into a second setting file.

[0136] For process 1, when the logical volume is in normal use, the operating system's stability and data integrity ensure accurate configuration file writing. By providing the physical volume's universally unique identifier, physical volume metadata, and volume group metadata in the operating system's configuration file for the logical volume management mechanism, this metadata can be recorded at the system level, facilitating subsequent management and maintenance of the logical volume.

[0137] In the specific implementation, the operating system can call the relevant logical volume management mechanism to read the physical volume's universal unique identification code, physical volume metadata, and volume group metadata from the storage device or memory, and then accurately write this information into the operating system's configuration file specifically for the logical volume management mechanism to complete the storage and recording of the information.

[0138] For process 2, commands provided by the logical volume management mechanism can be used to obtain query results, which contain key information about the physical volume and volume group. When the logical volume is in normal use, the system is stable, enabling reliable query operations and the extraction of required data. The obtained physical volume's universally unique identifier, physical volume metadata, and volume group metadata are written to the second configuration file.

[0139] In a specific implementation, when the logical volume is in normal use, the operating system executes a configuration command provided by the logical volume management mechanism. This configuration command queries the storage device or a related database for information about the physical volume and volume group and generates a query result. The query result is then parsed to obtain the physical volume's universally unique identifier, physical volume metadata, and volume group metadata. This information is then written to the second configuration file, completing data backup and storage.

[0140] Examples of configuration commands include: pvs, vgs, and lvs. Among them, pvs is used to query information related to physical volumes, such as the physical volume's universal unique identifier, size, and used space, and the physical volume's metadata can be parsed from its query results; vgs is used to query information related to volume groups, such as the volume group's UUID, size, and number of physical volumes contained, to help obtain the volume group's metadata; and lvs is used to query information about logical volumes, which can be combined with physical volume and volume group information to assist in comprehensive data collection for the entire logical volume management system. These configuration commands can be executed through the operating system when the logical volume is in normal use, querying the required information from the storage device or related database and generating query results so that the physical volume's universal unique identifier, physical volume metadata, and volume group metadata can be subsequently written to the second configuration file.

[0141] In summary, process 1 is to write relevant information directly into the configuration file of the operating system for the logical volume management mechanism. This method is relatively fixed and may be limited by factors such as the configuration file format, permissions, and system stability. Process 2, on the other hand, obtains the query results obtained by the command provided by the logical volume management mechanism and writes the information into the second setting file. This can more conveniently customize the file content and format according to different needs and does not rely on a specific system configuration file structure. At the same time, process 2 is easier to adjust and expand when dealing with different logical volume management scenarios and changes in demand. For example, different query commands can be selected as needed to obtain richer or specific information, and the written second setting files can be of multiple types, which is more convenient for integration and data sharing with other systems or tools.

[0142] In a specific implementation, the above-mentioned process of recovering the physical volume and volume group based on the universal unique identifier of the physical volume, the metadata of the physical volume, and the metadata of the volume group provided by the logical volume management mechanism specifically includes: creating a target physical volume corresponding to the universal unique identifier on the physical storage device, and using the metadata of the physical volume to set the metadata of the target physical volume; and recovering the volume group where the target physical volume is located based on the metadata of the volume group.

[0143] In the logical volume management system, the physical volume is the basic unit for storing data, and the volume group is the logical aggregation of multiple physical volumes, which is used to efficiently manage and allocate storage resources. The physical volume's universal unique identifier can uniquely identify the physical volume globally. The physical volume's metadata records key information such as its properties, status, and layout. The volume group's metadata includes the volume group's composition structure, member physical volume information, and logical volume allocation. When restoring physical volumes and volume groups, creating a target physical volume based on the backed-up universal unique identifier can ensure its uniqueness and identity consistency. Using the physical volume's metadata to set the target physical volume's properties can make its function and configuration the same as the original physical volume. Restoring the volume group through the volume group's metadata can reconstruct the association between the volume group and the physical volume, as well as the allocation relationship of the logical volumes within the volume group, thereby restoring the logical structure and data layout of the entire distributed storage system to normal.

[0144] In a specific implementation, a physical volume creation command may be used to create a target physical volume corresponding to the universal unique identifier.

[0145] For example, the physical volume creation command "pvcreate / dev / vdx -u

[0146] M7pcgb-e7Jz-lwhz-U5md-zcgE-T2Zu-OmJQOG--restorefile

[0147] / etc / lvm / archive / ceph-014cb2e8-f103-49ff-8764-3131cf65772b_00000-1301699606.vg" is used to create a physical volume in the Linux system.

[0148] Among them, "pvcreate" is the command used to create a physical volume in the LVM tool set.

[0149] " / dev / vdx" is used to specify the device path of the physical volume to be created, specifically the file path of the physical storage device.

[0150] In "-u M7pcgb-e7Jz-lwhz-U5md-zcgE-T2Zu-OmJQOG", "-u" specifies the UUID of the physical volume, and "M7pcgb-e7Jz-lwhz-U5md-zcgE-T2Zu-OmJQOG" is the string corresponding to the UUID.

[0151] In the command "--restorefile / etc / lvm / archive / ceph-014cb2e8-f103-49ff-8764-3131cf65772b_00000-1301699606.vg", "--restorefile" indicates the pre-configured file where the physical volume metadata is located. " / etc / lvm / archive / ceph-014cb2e8-f103-49ff-8764-3131cf65772b_00000-1301699606.vg" is a configuration file in the LVM archive directory that records the metadata of a specific physical volume.

[0152] In the embodiment of the present application, a volume group recovery instruction may be used to recover the volume group where the target physical volume is located.

[0153] For example, the volume group recovery command "vgcfgrestore -f / etc / lvm / archive / ceph-014cb2e8-f103-49ff-8764-3131cf65772b_00000-1301699606.vg vgxxx" is used to restore the volume group configuration in the Linux system.

[0154] vgcfgrestore is used to read the volume group configuration information from the preconfiguration file and restore the information to the volume group.

[0155] "-f": is an option of the "vgcfgrestore" command, used to specify the preset file to be used.

[0156] / etc / lvm / archive / ceph-014cb2e8-f103-49ff-8764-3131cf65772b_00000-1301699606.vg: indicates the path of the pre-configured file.

[0157] "vgxxx" indicates the name of the volume group to be restored, that is, the volume group to which the configuration information in the preset file is to be restored.

[0158] It should be noted that the preset file used for physical volume recovery and volume group recovery in the embodiment of the present application can be a configuration file corresponding to physical 1 or a second setting file corresponding to physical 2.

[0159] After successfully activating the restored volume group, the operating status of the object storage device is further checked. If the object storage device still fails to start normally, it indicates that the logical volume data cannot be effectively restored by restoring only the physical volume and volume group. In this case, step 304 calls the target data (including metadata of the physical volume, volume group, and logical volume) previously backed up in the first configuration file and writes it to the physical storage device header. By restoring key metadata information, the logical volume data is restored, thereby ensuring stable operation and data availability of the distributed storage system.

[0160] Method Example 3

[0161] Reference Figure 4 , shows a schematic flow chart of the steps of a method for recovering logical volume data of distributed storage according to an embodiment of the present application. The method is applied to a storage node of a distributed storage system, and the logical volume corresponds to a physical storage device. The method may specifically include the following steps:

[0162] Step 401: When the logical volume is in normal use, write target data of a preset size in the header of the physical storage device into a first setting file; the target data specifically includes: metadata of the physical volume, metadata of the volume group, and metadata of the logical volume;

[0163] Step 402: If the logical volume is in a faulty state, restart the storage node where the logical volume is located and determine whether the logical volume is in an activated state. If so, execute step 403; otherwise, execute step 404.

[0164] Step 403: Determine whether the object storage device is started normally.

[0165] Step 404: Recover the physical volume and volume group based on the physical volume's universal unique identifier, the physical volume's metadata, and the volume group's metadata provided by the logical volume management mechanism.

[0166] Step 405: After activating the restored volume group, detecting the status of the object storage device;

[0167] Step 406: If the state of the object storage device is a state where it cannot be started normally, the target data in the first setting file is written into the header of the physical storage device.

[0168] In an embodiment of the present application, when the logical volume is in normal use, target data in the physical storage device header including metadata of the physical volume, volume group, and logical volume is written to a first setting file. When the logical volume is in a faulty state, the storage node is first restarted and the activation status of the logical volume is determined. If it is not activated, the physical volume and volume group are restored based on the metadata provided by the LVM mechanism. After the volume group is activated, the status of the object storage device is detected. If it cannot be started normally, the target data in the first setting file is written back to the physical storage device header to achieve recovery of the faulty logical volume and related storage components.

[0169] The embodiment of the present application utilizes a hierarchical recovery mechanism to implement data recovery of logical volumes.

[0170] The hierarchical recovery mechanism specifically includes:

[0171] When the logical volume enters the fault state (step 402), the storage node is first restarted and the activation state of the logical volume is determined. This is because the activation state of the logical volume can reflect the operation status of the logical volume.

[0172] The logical volume activation state is normal: If the logical volume is in the activated state (step 403), it can be preliminarily inferred that the object storage device is likely to be able to start normally, because the normal activation of the logical volume is one of the prerequisites for the normal operation of the object storage device.

[0173] Logical volume inactive: If the logical volume is inactive (step 404), the physical volume and volume group are restored based on the physical volume's universally unique identifier, physical volume metadata, and volume group metadata provided by the LVM mechanism. This metadata is the key basis for rebuilding the physical volume and volume group, and can be used to restore the physical volume and volume group to their previous normal configuration state.

[0174] Object storage device status detection and recovery: After the physical volumes and volume groups are restored and the volume groups are activated (step 405), the object storage device status is detected. If the object storage device cannot be started normally (step 406), it means that rebuilding the physical volumes and volume groups cannot restore the logical volumes. In this case, the target data backed up in the first configuration file is written to the physical storage device header to attempt to restore normal operation of the object storage device.

[0175] In the embodiment of the present application, when the logical volume is in a faulty state, a hierarchical logical volume data recovery operation is performed. First, an attempt is made to restart the storage node; if the logical volume still cannot be activated after restarting the storage node, the physical volume and volume group are restored based on the physical volume universal unique identifier, the physical volume metadata, and the volume group metadata. After the volume group is activated, the object storage device status is detected again. If the object storage device still cannot start normally, the target data in the first setting file is used to repair the physical storage device header information. This hierarchical processing method avoids the limitations of a single recovery method, accurately locates the problem and implements the corresponding recovery strategy, greatly improves the efficiency of fault recovery, reduces the unnecessary consumption of system resources during the recovery process, and effectively improves the security of data and the stability of the storage system, reduces the business interruption time caused by the fault, and ensures that the business can continue to run stably.

[0176] It should be noted that for the method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the embodiments of the present application are not limited by the order of the actions described, because according to the embodiments of the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of the present application.

[0177] Based on the above embodiment, this embodiment also provides a distributed storage logical volume data recovery device, referring to Figure 5 As shown in the structural diagram, the device is applied to a storage node of a distributed storage system, and the logical volume corresponds to a physical storage device; the device specifically includes the following modules:

[0178] The first target data processing module 501 is configured to write target data of a preset size at the header of the physical storage device into a first setting file when the logical volume is in normal use; the target data includes metadata of the physical volume, metadata of the volume group, and metadata of the logical volume;

[0179] The second target data processing module 502 is configured to write the target data in the first setting file into the header of the physical storage device when the logical volume is in a fault state.

[0180] Optionally, the device may further include:

[0181] a startup detection module, configured to restart the object storage device if the object storage device cannot be started and detect the status of the object storage device before writing the target data in the first setting file to the header of the physical storage device when the logical volume is in a faulty state;

[0182] The fault determination module is configured to determine that the logical volume is in a fault state if the state of the object storage device is a state in which the device cannot be started normally.

[0183] Optionally, the preset size may be N megabytes, where N is a positive integer.

[0184] Optionally, the second target data processing module includes:

[0185] The target data copy module is used to use the file copy command to read data of a preset size from the first setting file according to the preset block size, and write the read data into the head of the physical storage device.

[0186] Optionally, the second target data processing module includes:

[0187] A recovery module is used to recover the physical volume and volume group based on the universal unique identifier of the physical volume, the metadata of the physical volume, and the metadata of the volume group provided by the logical volume management mechanism when the logical volume is in a fault state, and obtain a recovered volume group;

[0188] A status detection module is used to detect the status of the object storage device after the volume group is activated after recovery;

[0189] The target data writing module is configured to write the target data in the first setting file into the header of the physical storage device if the state of the object storage device is a state in which the device cannot be started normally.

[0190] Optionally, the device further comprises:

[0191] a configuration file processing module, configured to provide the physical volume's universally unique identifier, the physical volume's metadata, and the volume group's metadata in the operating system's configuration file for the logical volume management mechanism when the logical volume is in normal use; and / or

[0192] The query result processing module is configured to, when the logical volume is in normal use, obtain a query result obtained by a command provided by the logical volume management mechanism, obtain a universally unique identifier of the physical volume, metadata of the physical volume, and metadata of the volume group from the query result, and write the obtained universally unique identifier of the physical volume, metadata of the physical volume, and metadata of the volume group into a second setting file; the second setting file is used for recovery of the physical volume and volume group.

[0193] Optionally, the recovery module includes:

[0194] a physical volume recovery module, configured to create a target physical volume corresponding to the universal unique identifier on the physical storage device, and set metadata of the target physical volume using metadata of the physical volume;

[0195] The volume group recovery module is used to recover the volume group where the target physical volume is located according to the metadata of the volume group.

[0196] An embodiment of the present application further provides a non-volatile readable storage medium, which stores one or more modules (programs). When the one or more modules are applied to a device, the device can execute instructions (instructions) of each method step in the embodiment of the present application.

[0197] The present application provides one or more machine-readable media having instructions stored thereon, which, when executed by one or more processors, cause an electronic device to perform one or more of the methods described in the above embodiments. In the present application, the electronic device includes various types of devices such as terminal devices and servers (clusters).

[0198] The embodiments of the present disclosure may be implemented as a device configured as desired using any appropriate hardware, firmware, software, or any combination thereof, and the device may include: a terminal device, a server (cluster), and other electronic devices. Figure 6 An exemplary apparatus 1100 that can be used to implement various embodiments described in this application is schematically illustrated.

[0199] For one embodiment, Figure 6 An exemplary apparatus 1100 is shown having one or more processors 1102, a control module (chip set) 1104 coupled to at least one of the processor(s) 1102, a memory 1106 coupled to the control module 1104, a non-volatile memory / storage device 1108 coupled to the control module 1104, one or more input / output devices 1110 coupled to the control module 1104, and a network interface 1112 coupled to the control module 1104.

[0200] The processor 1102 may include one or more single-core or multi-core processors, and the processor 1102 may include any combination of general-purpose processors or dedicated processors (e.g., graphics processors, application processors, baseband processors, etc.). In some embodiments, the apparatus 1100 can serve as a terminal device, server (cluster), or other device described in the embodiments of the present application.

[0201] In some embodiments, the apparatus 1100 may include one or more computer-readable media (e.g., memory 1106 or non-volatile memory / storage 1108) having instructions 1114 and one or more processors 1102 configured, in combination with the one or more computer-readable media, to execute the instructions 1114 to implement a module to perform the actions described in the present disclosure.

[0202] For one embodiment, the control module 1104 may include any suitable interface controller to provide any suitable interface to at least one of the processor(s) 1102 and / or any suitable device or component in communication with the control module 1104 .

[0203] The control module 1104 may include a memory controller module to provide an interface to the memory 1106. The memory controller module may be a hardware module, a software module, and / or a firmware module.

[0204] The memory 1106 may be used, for example, to load and store data and / or instructions 1114 for the device 1100. For one embodiment, the memory 1106 may include any suitable volatile memory, such as a suitable DRAM (Dynamic Random Access Memory). In some embodiments, the memory 1106 may include a double data rate type four synchronous dynamic random access memory.

[0205] For one embodiment, the control module 1104 may include one or more input / output controllers to provide an interface to the non-volatile memory / storage device 1108 and the input / output device(s) 1110 .

[0206] For example, the non-volatile memory / storage device 1108 may be used to store data and / or instructions 1114. The non-volatile memory / storage device 1108 may include any suitable non-volatile memory (e.g., flash memory) and / or may include any suitable non-volatile storage device(s) (e.g., one or more hard disk drives, one or more optical disk drives, and / or one or more digital versatile optical disk drives).

[0207] The non-volatile memory / storage device 1108 may include storage resources that are physically part of the device on which the apparatus 1100 is installed, or it may be accessible to the device without being part of the device. For example, the non-volatile memory / storage device 1108 may be accessed via one or more input / output devices 1110 over a network.

[0208] (One or more) input / output devices 1110 may provide an interface for apparatus 1100 to communicate with any other appropriate devices. Input / output devices 1110 may include communication components, audio components, sensor components, etc. Network interface 1112 may provide an interface for apparatus 1100 to communicate via one or more networks. Apparatus 1100 may wirelessly communicate with one or more components of a wireless network according to any of one or more wireless network standards and / or protocols, for example, accessing a wireless network based on a communication standard such as WiFi (Wireless Fidelity), 2G (2nd Generation Wireless Telephone Technology), 3G (3rd Generation Wireless Telephone Technology), 4G (4th Generation Wireless Telephone Technology), 5G (5th Generation Wireless Telephone Technology), etc., or a combination thereof for wireless communication.

[0209] For one embodiment, at least one of the processor(s) 1102 may be packaged together with the logic of one or more controllers (e.g., a memory controller module) of the control module 1104. For one embodiment, at least one of the processor(s) 1102 may be packaged together with the logic of one or more controllers of the control module 1104 to form a system-in-package. For one embodiment, at least one of the processor(s) 1102 may be integrated on the same die with the logic of one or more controllers of the control module 1104. For one embodiment, at least one of the processor(s) 1102 may be integrated on the same die with the logic of one or more controllers of the control module 1104 to form a system-on-chip.

[0210] In various embodiments, apparatus 1100 may be, but is not limited to, a terminal device such as a server, a desktop computing device, or a mobile computing device (e.g., a laptop computing device, a handheld computing device, a touchscreen device, a netbook, etc.). In various embodiments, apparatus 1100 may have more or fewer components and / or a different architecture. For example, in some embodiments, apparatus 1100 includes one or more cameras, a keyboard, an LCD screen (including a touchscreen display), a non-volatile memory port, multiple antennas, a graphics chip, an application-specific integrated circuit, and a speaker.

[0211] Among them, the main control chip can be used as a processor or control module in the detection device, sensor data, location information, etc. are stored in a memory or non-volatile memory / storage device, the sensor group can be used as an input / output device, and the communication interface can include a network interface.

[0212] As for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0213] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the various embodiments can be referenced to each other.

[0214] The present application embodiment is described with reference to the flow chart and / or block diagram of the method, terminal device (system), and computer program product according to the embodiment of the present application. It should be understood that each process and / or box in the flow chart and / or block diagram, and the combination of the process and / or box in the flow chart and / or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing terminal device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing terminal device produce a device for implementing the function specified in one process or multiple processes in the flow chart and / or one box or multiple boxes in the block diagram.

[0215] These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing terminal device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce a manufactured product including an instruction device that implements the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0216] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal device so that a series of operating steps are executed on the computer or other programmable terminal device to produce computer-implemented processing, so that the instructions executed on the computer or other programmable terminal device provide steps for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0217] Although preferred embodiments of the present invention have been described, those skilled in the art may make additional changes and modifications to these embodiments once they become aware of the basic inventive concepts. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the embodiments of the present invention.

[0218] Finally, it should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that includes 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 terminal device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article, or terminal device that includes the element.

[0219] The above is a detailed introduction to a distributed storage logical volume data recovery method and device, an electronic device and a machine-readable medium provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method of the present application and its core idea. At the same time, for general technical personnel in this field, based on the ideas of the present application, there will be changes in the specific implementation methods and application sets. In summary, the content of this specification should not be understood as a limitation on the present application.

Claims

1. A distributed storage logical volume data recovery method, characterized in that: The method is applied to a storage node of a distributed storage system, wherein the logical volume corresponds to a physical storage device; the method comprises: When the logical volume is in normal use, target data of a preset size at the head of the physical storage device is written into a first setting file; the target data includes metadata of the physical volume, metadata of the volume group, and metadata of the logical volume; When the logical volume is in a failed state, the target data in the first setting file is written into the header of the physical storage device.

2. The method according to claim 1, characterized in that Before writing the target data in the first setting file into the header of the physical storage device when the logical volume is in a fault state, the method further includes: If the object storage device cannot be started, restart it and check the status of the object storage device; If the object storage device is in a state of being unable to start normally, it is determined that the logical volume is in a faulty state.

3. The method according to claim 1, characterized in that The preset size is N megabytes, where N is a positive integer.

4. The method according to claim 1, wherein The step of writing the target data in the first setting file into the header of the physical storage device when the logical volume is in a fault state comprises: Using the file copy command, data of a preset size is read from the first setting file according to the preset block size, and the read data is written to the head of the physical storage device.

5. The method according to claim 1, wherein The step of writing the target data in the first setting file into the header of the physical storage device when the logical volume is in a fault state comprises: When the logical volume is in a faulty state, the physical volume and the volume group are recovered according to the universal unique identifier of the physical volume, the metadata of the physical volume, and the metadata of the volume group provided by the logical volume management mechanism to obtain a recovered volume group; After the volume group is activated after recovery, the status of the object storage device is detected; If the state of the object storage device is a state in which it cannot be started normally, the target data in the first setting file is written into the header of the physical storage device.

6. The method according to claim 5, characterized in that The method further comprises: When the logical volume is in normal use, providing the physical volume's universally unique identifier, the physical volume's metadata, and the volume group's metadata in the operating system's configuration file for the logical volume management mechanism; and / or When the logical volume is in normal use, a query result obtained by a command provided by the logical volume management mechanism is obtained, a universally unique identifier of the physical volume, metadata of the physical volume, and metadata of the volume group are obtained from the query result, and the obtained universally unique identifier of the physical volume, metadata of the physical volume, and metadata of the volume group are written into a second setting file; the second setting file is used for recovery of the physical volume and volume group.

7. The method according to claim 5, characterized in that The method of recovering the physical volume and the volume group based on the universal unique identifier of the physical volume, the metadata of the physical volume, and the metadata of the volume group provided by the logical volume management mechanism includes: Creating a target physical volume corresponding to the universal unique identifier on the physical storage device, and setting metadata of the target physical volume using metadata of the physical volume; The volume group where the target physical volume is located is restored according to the metadata of the volume group.

8. A distributed storage logical volume data recovery device, characterized in that: The device is applied to a storage node of a distributed storage system, wherein the logical volume corresponds to a physical storage device; the device comprises: A first target data processing module is configured to write target data of a preset size at the header of the physical storage device into a first setting file when the logical volume is in normal use; the target data includes metadata of the physical volume, metadata of the volume group, and metadata of the logical volume; The second target data processing module is configured to write the target data in the first setting file into the header of the physical storage device when the logical volume is in a fault state.

9. An electronic device, characterized in that: include: processor; and A memory having executable codes stored thereon, which, when executed, causes the processor to perform the method according to any one of claims 1 to 7.

10. A machine-readable medium having executable codes stored thereon, which, when executed, cause a processor to perform the method according to any one of claims 1 to 7.

Images