A method and apparatus for automatically monitoring and locating failed hard drives through osd

Abstract

The application discloses a method and device for automatically monitoring and positioning a fault hard disk through an osd, and the method comprises the following steps: obtaining the server address where the osd is located through a ceph osd tree, and storing the osd and the corresponding server address into a list; cyclically reading the list list_osd to log in to the server, and checking the mounting point path matched with the osd number on the server through df; finding the corresponding block path through the mounting point path, and querying the id corresponding to the block path by using dmsetup table; obtaining the id number according to the path output in the last step, and again querying the id corresponding to the block path by using dmsetup table; converting the id into a format recognizable by ls-l / dev / sd*; querying the hard disk position corresponding to the id through ls-l / dev / sd*, and comparing the output content in the last step, and storing the qualified one into a list list_first; determining the osd state once through ceph osd tree|grep down|wc-l in a fixed time period. The method and device shorten the time for positioning the fault hard disk position when the osd is abnormal, and improve the fault discovery efficiency by monitoring and positioning the specific hard disk position corresponding to the osd.

Description

Technical Field

[0001] This invention relates to the field of fault location, and in particular to a method and apparatus for automatically monitoring and locating faulty hard drives using OSD. Background Technology

[0002] OSD: Object Storage Device, is a daemon process primarily responsible for responding to client requests and returning specific data. A typical Ceph cluster (Ceph is a unified, distributed file storage system designed for excellent performance, reliability, and scalability) consists of multiple OSDs. Each hard drive or partition corresponds to one OSD daemon process. Because each OSD daemon process is directly associated with its local hard drive, operations such as OSD failure, OSD configuration, or OSD restart must be performed on the server where the corresponding hard drive of the OSD resides. For example, OSDs 0, 1, and 2 exist on vms81, and OSDs 0, 1, and 2 exist on vms82. OSDs are designated as 3, 4, and 5. Operations on OSD0 can only be performed by logging into vms81, and operations on OSD5 can only be performed by logging into vms82. For example, if an OSD malfunctions, the first step is to locate the server where the OSD resides, and then further locate whether the hard drive corresponding to the OSD has failed. Because multiple hard drives may fail simultaneously on the server, or the OSD may have automatically migrated to other servers, the location information needs to consider multiple dimensions. Therefore, how to monitor and locate the specific hard drive corresponding to an OSD in real time and accurately, shorten the time for locating the faulty hard drive when an OSD malfunctions, and improve the efficiency of fault detection is the problem that this solution needs to solve. Summary of the Invention

[0003] To address the problems existing in the prior art, this invention provides a method and apparatus for automatically monitoring and locating faulty hard drives using OSDs. By accurately monitoring and locating the specific hard drive location corresponding to the OSD in real time, the time required to locate the faulty hard drive when the OSD malfunctions is shortened, thereby improving the efficiency of fault detection.

[0004] To achieve the above objectives, the present invention adopts the following technical solution:

[0005] In one embodiment of the present invention, a method for automatically monitoring and locating faulty hard drives using OSD is proposed, the method comprising:

[0006] S01. Obtain the server address where the OSD is located through the ceph OSD tree, and store the OSD and its corresponding server address in a list;

[0007] S02. Loop through the list list_osd and log in to the server. Taking vms81 as an example, use df to view the mount point path that matches the OSD number on the server.

[0008] S03. Find the corresponding block path through the queried mount point path, and use dmsetup table to query the id corresponding to the block path;

[0009] S04. Obtain the id number according to the path output in the previous step, and use dmsetup table to query the id corresponding to the block path again;

[0010] S05. Convert the id to a format recognizable by ls -l / dev / sd*;

[0011] S06. Query vms81 through ls -l / dev / sd* to obtain the hard disk location corresponding to the id, compare with the content output in S05, and store the qualified ones into the list list_first;

[0012] For example, compare 8,32 in osd.0:up:vms81: / var / lib / ceph-0:8,32 output in S05 and 8,32 in brw-rw---- 1 root disk 8,32 Feb 16 2021 / dev / sdb output by ls -l / dev / sd* in S06. If they are the same, intercept the hard disk location and store it in the list.

[0013] S07. Determine the osd status once every fixed period through ceph osd tree | grep down | wc -l.

[0014] Further, the qualification condition in S06 is: compare the content output in S05 and the content output in S06. If they are the same, intercept the hard disk location and store it in the list.

[0015] Further, S07 includes:

[0016] S071. When the osd status is all up, cyclically read the list_first list at a fixed period, and re-obtain the corresponding information according to the steps of S02 - S06 to update the list_first list;

[0017] S072. If there is a down osd status, immediately trigger a query to update the list_first list.

[0018] In an embodiment of the present invention, a device for automatically monitoring and locating a faulty hard disk through osd is also proposed. The device includes:

[0019] An address reading module, which obtains the server address where the osd is located through ceph osd tree, and stores the osd and the corresponding server address into a list;

[0020] The list reading module reads the list list_osd in a loop and logs into the server. It uses df to view the mount point path that matches the OSD number on the server.

[0021] The module reads the ID once, finds the corresponding block path through the queried mount point path, and uses dmsetuptable to query the ID corresponding to the block path;

[0022] The ID secondary reading module retrieves the ID number based on the path output in the previous step, and then uses the dmsetup table to query the ID corresponding to the block path again;

[0023] The ID conversion module converts IDs into a format that can be recognized by ls -l / dev / sd*.

[0024] The comparison and writing module retrieves the hard disk location corresponding to the ID by querying / dev / sd* using ls -l / dev / sd*, compares the output of the ID conversion module, and stores the matching items into the list list_first;

[0025] The OSD status determination module determines the OSD status once every fixed time period using ceph osd tree|grep down|wc -l.

[0026] Furthermore, the condition in the comparison and writing module is: the content output by the ID conversion module and the content output by the comparison and writing module are compared, and if they are the same, the hard disk location is extracted and stored in a list.

[0027] Furthermore, the OSD status determination module includes:

[0028] The OSD status is always up. The module reads the list_first list in a fixed time period. The module reads the list, reads the ID once, reads the ID twice, converts the ID, compares and writes the ID, and determines the OSD status to re-acquire the corresponding information and update the list_first list.

[0029] If the OSD status shows a down module, immediately trigger a query to update the list_first list.

[0030] In one embodiment of the present invention, a computer device is also proposed, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the aforementioned method for automatically monitoring and locating faulty hard drives via OSD.

[0031] In one embodiment of the present invention, a computer-readable storage medium is also provided, which stores a computer program that executes a method for automatically monitoring and locating faulty hard disks via OSD.

[0032] Beneficial effects:

[0033] This invention uses `df` to view the mount point path matching the OSD number on the server, then views the block path corresponding to the mount point path, and then uses `dmsetup table` to view the marker corresponding to the path. By converting the marker format and comparing it, the hard disk location corresponding to the OSD can be determined. The problem that this solution aims to solve is to shorten the time to locate the faulty hard disk when the OSD is abnormal and improve the efficiency of fault detection by accurately monitoring and locating the specific hard disk location corresponding to the OSD in real time. Attached Figure Description

[0034] Figure 1 This is a flowchart illustrating an embodiment of the method for automatically monitoring and locating faulty hard drives using OSD according to the present invention;

[0035] Figure 2 This is a schematic diagram of the device structure for automatically monitoring and locating faulty hard drives using OSD, as per the present invention.

[0036] Figure 3 This is a schematic diagram of a computer device structure according to an embodiment of the present invention. Detailed Implementation

[0037] The principles and spirit of the present invention will now be described with reference to several exemplary embodiments. It should be understood that these embodiments are provided merely to enable those skilled in the art to better understand and implement the present invention, and are not intended to limit the scope of the present invention in any way. Rather, these embodiments are provided to make this disclosure more thorough and complete, and to fully convey the scope of this disclosure to those skilled in the art.

[0038] The technical terms involved in this invention and their explanations are as follows:

[0039] ceph osd tree: View the status of OSDs and the servers they reside on;

[0040] Df: Checks the disk space usage of the file system and can display the disk mount point path;

[0041] Block: storage block (space);

[0042] dmsetup table: This command displays the mapping table from physical devices to virtual devices.

[0043] `ls -l / dev / `: View files in the ` / dev` directory.

[0044] `ceph osd tree|grep down|wc -l`: Query whether an OSD is down (an anomaly).

[0045] Those skilled in the art will recognize that embodiments of the present invention can be implemented as a system, apparatus, device, method, or computer program product. Therefore, this disclosure can be specifically implemented in the following forms: entirely hardware, entirely software (including firmware, resident software, microcode, etc.), or a combination of hardware and software.

[0046] According to an embodiment of the present invention, a method and apparatus for automatically monitoring and locating faulty hard drives using OSD are proposed. By accurately monitoring and locating the specific hard drive location corresponding to the OSD in real time, the time for locating the faulty hard drive when the OSD is abnormal is shortened, and the fault detection efficiency is improved.

[0047] The principles and spirit of the present invention will be explained in detail below with reference to several representative embodiments.

[0048] The method includes:

[0049] S01. Obtain the server address where the OSD is located through the ceph OSD tree, and store the OSD and its corresponding server address in a list;

[0050] S02. Loop through the list list_osd and log in to the server. Taking vms81 as an example, use df to view the mount point path that matches the OSD number on the server.

[0051] S03. Find the corresponding block path through the queried mount point path, and use the dmsetup table to query the ID corresponding to the block path;

[0052] S04. Obtain the ID number based on the path output in the previous step, and use dmsetup table again to query the ID corresponding to the block path;

[0053] S05. Convert the ID to a format that ls -l / dev / sd* can recognize;

[0054] S06. Use `ls -l / dev / sd*` to query `vms81` to get the hard disk location corresponding to the ID, compare it with the output of S05, and store the ones that meet the conditions into the list `list_first`.

[0055] Compare the 8,32 in osd.0:up:vms81: / var / lib / ceph-0:8,32 output by S05 and the 8,32 in brw-rw----1 root disk 8,32 Feb 16 2021 / dev / sdb output by ls -l / dev / sd* in S06. If they are the same, intercept the hard disk location and store it in a list.

[0056] S07: Determine the osd status once within a fixed time period by ceph osd tree | grep down | wc -l.

[0057] Further, the condition in S06 is: Compare the content output by S05 and the content output by S06. If they are the same, intercept the hard disk location and store it in a list.

[0058] Further, S07 includes:

[0059] S071: When the osd status is all up, cyclically read the list_first list within a fixed time period, and re-obtain the corresponding information according to the steps of S02 - S06 to update the list_first list;

[0060] S072: If there is an osd with a down status, immediately trigger a query to update the list_first list.

[0061] It should be noted that although the operations of the method of the present invention are described in a specific order in the above embodiments and accompanying drawings, this does not require or imply that these operations must be performed in this specific order, or that all the shown operations must be performed to achieve the desired result. Additionally or alternatively, some steps may be omitted, multiple steps may be combined into one step for execution, and / or one step may be decomposed into multiple steps for execution.

[0062] To more clearly explain the above method for automatically monitoring and locating faulty hard disks through osd, the following will be described in conjunction with a specific embodiment. However, it should be noted that this embodiment is only for better explaining the present invention and does not constitute an improper limitation of the present invention.

[0063] As Figure 1 shown:

[0064] S01: Obtain the server address where the osd is located through ceph osd tree, and store the osd and the corresponding server address in a list

[0065]

[0066] Store the osd and the corresponding server address in the list list_osd:

[0067] ['osd.0:up:vms81','osd.1:up:vms81','osd.2:up:vms81','osd.3:up:vms82','osd.4:up:vms82','osd.5:up:vms82']

[0068] S02: Loop through the list `list_osd` to log in to the server. Taking `vms81` as an example, use `df` to view the mount point path that matches the OSD number on the server.

[0069]

[0070]

[0071] Get the mount point path matching the OSD ID:

[0072] osd.0:up:vms81: / var / lib / ceph-0

[0073] osd.1:up:vms81: / var / lib / ceph-1

[0074] osd.2:up:vms81: / var / lib / ceph-2

[0075] S03: Locate the corresponding block path using the found mount point path, and then use the dmsetup table to query the ID corresponding to the block path:

[0076] [root@vms81~]#ls-l / var / lib / ceph-0|grep block

[0077] lrwxrwxrwx 1ceph ceph 93 Aug 17 15:52block-> / dev / ceph-e9c466ad-7fb5-4773-9665-6cb444c65d6d / osd-block-f1b5a8b5-0bc7-431b-b392-2640ccf3ef20

[0078] [root@vms81~]#ls-l / var / lib / ceph-1|grep block

[0079] lrwxrwxrwx 1ceph ceph 93 Aug 17 15:53block-> / dev / ceph-e9c496ad-8fb5-4773-9664-7cb4u4c65d6d / osd-block-g1b5a8b5-0bc7-831b-b392-2640ccf3ef21

[0080] [root@vms81~]#ls-l / var / lib / ceph-2|grep block

[0081] lrwxrwxrwx 1ceph ceph 93 Aug 17 15:53block-> / dev / ceph-e9c496ad-8fb5-4773-9664-7cu4u4c6dd6d / osd-block-gu b5a8b5-0bc7-931b-4392-2y40ccf3ef22

[0082] S04: Based on the output of S03, further query the ID corresponding to the block path using the dmsetup table:

[0083] [root@vms81~]#dmsetup table / dev / ceph-e9c466ad-7fb5-4773-9665-6cb444c65d6d / osd-block-f1b5a8b5-0bc7-431b-b392-2640ccf3ef20

[0084] 041934848linear 8:322048 / / id number is 8:32

[0085] [root@vms81~]#dmsetup table / dev / ceph-e9c496ad-8fb5-4773-9664-7cb4u4c65d6d / osd-block-g1b5a8b5-0bc7-831b-b392-2640ccf3ef21

[0086] 041934848linear 8:332048 / / id number is 8:33

[0087] [root@vms81~]#dmsetup table / dev / ceph-e9c496ad-8fb5-4773-9664-7cu4u4c6dd6d / osd-block-gu b5a8b5-0bc7-931b-4392-2y40ccf3ef22

[0088] 041934848linear 8:372048 / / id number is 8:37

[0089] S05: Convert the ID to a format that ls -l / dev / sd* can recognize:

[0090] osd.0:up:vms81: / var / lib / ceph-0:8,32

[0091] osd.1:up:vms81: / var / lib / ceph-1:8,33

[0092] osd.2:up:vms81: / var / lib / ceph-2:8,37

[0093] S06: Use `ls -l / dev / sd*` to retrieve the hard drive location corresponding to the ID, compare it with the output of S05, and store the matching entries into the list `list_first`.

[0094] [root@vms81~]#ls -l / dev / sd*

[0095] brw-rw----1root disk 8, February 162021 / dev / sda

[0096] brw-rw----1root disk 8, December 162021 / dev / sda1

[0097] brw-rw----1root disk 8,22 month 162021 / dev / sda2

[0098] brw-rw----1root disk 8,322 month 162021 / dev / sdb

[0099] brw-rw----1root disk 8,332 month 162021 / dev / sdc

[0100] brw-rw----1root disk 8,372month162021 / dev / sdd

[0101] [root@vms81~]#

[0102] Store in list_first:

[0103] ['osd.0:up:vms81: / var / lib / ceph-0:8,32: / dev / sdb', osd.1:up:vms81: / var / lib / ceph-1:8,

[0104] 33: / dev / sdc', osd.2:up:vms81: / var / lib / ceph-2:8,37: / dev / sdc']

[0105] Similarly, log in to vms82 to obtain the corresponding information, and finally the output is as follows:

[0106] ['osd.0:up:vms81: / var / lib / ceph-0:8,32: / dev / sdb', osd.1:up:vms81: / var / lib / ceph-1:8,

[0107] 33: / dev / sdc', osd.2:up:vms81: / var / lib / ceph-2:8,37: / dev / sdc', 'osd.3:up:vms82: / var / lib / ceph-0:8,32: / dev / sdb', osd.4:up:vms82: / var / lib / ceph-1:8,33: / dev / sdc', osd.5:up:vms82: / var / l ib / ceph-2:8,37: / dev / sdc']

[0108] Compare the 8,32 in osd.0:up:vms81: / var / lib / ceph-0:8,32 with the 8,32 in brw-rw---- 1 root disk 8,32 Feb 16 2021 / dev / sdb output by ls -l / dev / sd* in S06. If they are the same, intercept the hard disk location and store it in the list.

[0109] S07: Determine the osd status once every 30 seconds through ceph osd tree | grep down | wc -l. If the status is all up, read the list_first list every five minutes and re-obtain the corresponding information according to the above process to update the list_first list. If the status is down, immediately trigger a query to update the list_first list. Take osd.0 of vms81 as an example.

[0110] [root@vms81 init.d]#ceph osd tree | grep -E vms|down

[0111] -3 0.05800 host vms81

[0112] 0hdd 0.01900 osd.0 down 1.000001.00000

[0113] [root@vms81 init.d]#

[0114] Retrieve the OSD ID and server address that went down as vms81 and store them in the list list_osd

[0115] ['osd.0:down:vms81']

[0116] Re-query and update the list_first list following steps S02 to S06:

[0117] ['osd.0:down:vms81: / var / lib / ceph-0:8,32: / dev / sdb',osd.1:up:vms81: / var / lib / ceph-1:8,

[0118] 33: / dev / sdc',osd.2:up:vms81: / var / lib / ceph-2:8,37: / dev / sdc','osd.3:up:vms82: / var / lib / ce ph-0:8,32: / dev / sdb',osd.4:up:vms82: / var / lib / ceph-1:8,33: / dev / sdc',osd.5:up:vms82: / var / l ib / ceph-2:8,37: / dev / sdc']

[0119] Based on the same inventive concept, this invention also proposes a device for automatically monitoring and locating faulty hard drives via OSD. The implementation of this device can refer to the implementation of the method described above, and repeated details will not be elaborated further. The term "module" as used below can refer to a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0120] Figure 2 This is a schematic diagram of the device structure for automatically monitoring and locating faulty hard drives using an OSD, as per the present invention. Figure 2 As shown, the device includes:

[0121] Address reading module 110: Obtains the server address where the OSD is located through the Ceph OSD tree, and stores the OSD and the corresponding server address in a list;

[0122] The list reading module 120 reads the list list_osd in a loop. Log in to the server and use df to view the mount point path that matches the OSD number on the server.

[0123] The ID is read once by module 130. The corresponding block path is found by querying the mount point path, and the ID corresponding to the block path is queried using the dmsetup table.

[0124] ID secondary reading module 140: Obtain the ID number based on the path output in the previous step, and use dmsetuptable again to query the ID corresponding to the block path;

[0125] ID conversion module 150 converts IDs to a format that can be recognized by ls -l / dev / sd*;

[0126] Compare and write module 160, query the hard disk location corresponding to the ID by ls -l / dev / sd*, compare with the output of S05, and store the matching conditions into the list list_first;

[0127] The OSD status determination module 170 determines the OSD status once at a fixed time interval using ceph osd tree|grep down|wc -l.

[0128] The condition for the comparison and write module 160 is: the content output by the ID conversion module 150 and the content output by the comparison and write module 160 are compared. If they are the same, the hard disk location is extracted and stored in a list.

[0129] The OSD status determination module 170 includes:

[0130] The OSD status is always up. Module 171 reads the list_first list in a fixed time period and re-acquires the corresponding information to update the list_first list according to steps S02-S06.

[0131] If the OSD status is down (module 172), immediately trigger a query to update the list_first list.

[0132] It should be noted that although several modules of the device for automatically monitoring and locating faulty hard drives via OSD have been mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of the invention, the features and functions of two or more modules described above can be embodied in a single module. Conversely, the features and functions of a single module described above can be further divided and embodied by multiple modules.

[0133] Based on the aforementioned inventive concept, such as Figure 3 As shown, the present invention also proposes a computer device 200, including a memory 210, a processor 220, and a computer program 230 stored in the memory 210 and executable on the processor 220. When the processor 220 executes the computer program 230, it implements the aforementioned method for automatically monitoring and locating faulty hard disks via OSD.

[0134] Based on the aforementioned inventive concept, the present invention also proposes a computer-readable storage medium storing a computer program that executes the aforementioned method for automatically monitoring and locating faulty hard drives via OSD.

[0135] The present invention proposes a method and apparatus for automatically monitoring and locating faulty hard drives using OSDs. This involves using `df` to view the mount point path matching the OSD number on the server, examining the corresponding block path, and then using `dmsetuptable` to view the markers corresponding to that path. By converting the markers to a different format and comparing them, the location of the hard drive corresponding to the OSD can be determined. The solution aims to shorten the time required to locate faulty hard drives when OSDs malfunction, thereby improving fault detection efficiency through real-time and accurate monitoring and location of the specific hard drive corresponding to the OSD.

[0136] While the spirit and principles of the invention have been described with reference to several specific embodiments, it should be understood that the invention is not limited to the disclosed specific embodiments, and the division of aspects does not imply that features in these aspects cannot be combined for benefit; such division is merely for ease of description. The invention is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.

[0137] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0138] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0139] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0140] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0141] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with embodiments of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0142] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0143] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0144] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

[0145] Regarding the limitation of the scope of protection of this invention, those skilled in the art should understand that various modifications or variations that can be made by those skilled in the art without creative effort based on the technical solution of this invention are still within the scope of protection of this invention.

Claims

1. A method for automatically monitoring and locating faulty hard drives using OSD, characterized in that, The method includes: S01. Obtain the server address where the OSD is located through the ceph OSD tree, and store the OSD and its corresponding server address in a list; S02. Loop through the list list_osd to log in to the server, and use df to view the mount point path that matches the OSD number on the server; S03. Find the corresponding block path through the queried mount point path, and use the dmsetup table to query the ID corresponding to the block path; S04. Obtain the ID number based on the path output in the previous step, and use dmsetup table again to query the ID corresponding to the block path; S05. Convert the ID to a format that ls -l / dev / sd* can recognize; S06. Use `ls -l / dev / sd*` to retrieve the hard disk location corresponding to the ID, compare it with the output of S05, and store the matching results into the list `list_first`. The matching condition is: compare the output of S05 and the output of S06, and if they are the same, extract the hard disk location and store it into the list. S07. At fixed time intervals, determine the OSD status once using ceph osd tree | grep down | wc -l.

2. The method for automatically monitoring and locating faulty hard drives via OSD according to claim 1, characterized in that, S07 includes: S071, both OSD status are up, the list_first list is read in a loop for a fixed time period, and the corresponding information is retrieved and the list_first list is updated again according to steps S02-S06; S072. If the OSD status is down, a query to update the list_first list will be triggered immediately.

3. A device for automatically monitoring and locating faulty hard drives via OSD, characterized in that, The device includes: Address reading module 110: Obtains the server address where the OSD is located through the Ceph OSD tree, and stores the OSD and the corresponding server address in a list; The list reading module 120 reads the list list_osd in a loop. Log in to the server and use df to view the mount point path that matches the OSD number on the server. The ID is read once by module 130. The corresponding block path is found by querying the mount point path, and the ID corresponding to the block path is queried using dmsetuptable. ID secondary reading module 140: Obtain the ID number based on the path output in the previous step, and use dmsetup table again to query the ID corresponding to the block path; ID conversion module 150 converts IDs to a format that can be recognized by ls -l / dev / sd*; The comparison and writing module 160 retrieves the hard disk location corresponding to the ID by querying / dev / sd* using ls -l / dev / sd*, compares it with the output of S05, and stores the matching conditions into the list list_first; the matching conditions are: comparing the output of ID conversion module 150 with the output of comparison and writing module 160, and if they are the same, the hard disk location is extracted and stored in the list. The OSD status determination module 170 determines the OSD status once at a fixed time interval using the command `ceph osd tree | grep down | wc -l`.

4. The device for automatically monitoring and locating faulty hard drives via OSD according to claim 3, characterized in that, The OSD status determination module 170 includes: The OSD status is always up. Module 171 reads the list_first list in a fixed time period and re-acquires the corresponding information to update the list_first list according to steps S02-S06. If the OSD status is down (module 172), immediately trigger a query to update the list_first list.

5. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method according to any one of claims 1-2.

6. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that performs the method according to any one of claims 1-2.

Images