Method, device and equipment for detecting disk state and computer readable storage medium
By repeatedly acquiring the status and update information of the disk read process in the cloud computing environment, and combining the read time and process identifier, the problems of accuracy and timeliness of disk fault detection are solved, achieving low-cost and efficient disk status detection and reducing false positives.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- SHENZHEN HUAWEI CLOUD COMPUTING TECHNOLOGIES CO LTD
- Filing Date
- 2023-02-24
- Publication Date
- 2026-06-05
AI Technical Summary
In cloud computing, disk failures can cause services to malfunction, and existing technologies struggle to detect disk status in a timely and accurate manner, thus affecting the continuity of cloud computing services.
By acquiring the status and update information of the disk read process multiple times within the detection period, and combining the read time and process identifier, the status of the disk read process is analyzed to determine the disk status. Skip reads are used to reduce input and output resource consumption and avoid intrusive modifications.
It achieves low-cost, simple, and universal disk status detection, improves detection accuracy and tolerance for brief periods of unresponsiveness, and reduces false positives.
Smart Images

Figure CN116302811B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of cloud computing technology, and in particular to methods, apparatus, devices, and computer-readable storage media for detecting disk status. Background Technology
[0002] With the development of cloud computing technology, its data processing capabilities are becoming increasingly powerful, enabling the parallel processing of ever-growing amounts of data. This data can be stored on the disks of cloud databases. However, disk malfunctions such as unresponsiveness can occur, causing the disk to malfunction and impacting the normal operation of cloud computing services. Therefore, there is an urgent need for a disk status detection method to promptly and accurately assess disk conditions and ensure the smooth operation of cloud computing services. Summary of the Invention
[0003] This application provides a method, apparatus, device, and computer-readable storage medium for detecting disk status. The technical solution is as follows:
[0004] Firstly, a method for detecting disk status is provided. This method is used in a device providing cloud computing services. The method includes: acquiring the status of a disk reading process multiple times within a detection period, wherein the disk reading process is used to read data from the disk; acquiring update information of the disk reading process multiple times within the detection period, wherein the update information includes the data reading time, which indicates the time when the disk reading process reads data from the disk, and the two data read by two adjacent reading times have an interval space on the disk; and determining the disk status based on whether the acquired update information is the same and the multiple statuses of the disk reading process.
[0005] This application achieves detection by comparing whether multiple update information of the disk read process is the same and analyzing multiple states of the disk read process. The detection cost is low, the detection process is simple, the detection method is universal, and the accuracy of the determined disk state is high.
[0006] In one possible implementation, the update information also includes a process identifier of the disk read process, which identifies the disk read process reading disk data. Before determining the disk state based on whether multiple update information pieces are identical and multiple states of the disk read process, the process further includes: determining whether multiple update information pieces are identical based on multiple read times and multiple process identifiers. In addition to read times, the update information of the disk read process can also include the state of the disk read process. Determining whether multiple update information pieces are identical based on multiple states of the disk read process and multiple read times further ensures the accuracy of the disk state determined based on multiple update information pieces and multiple states of the disk read process.
[0007] In one possible implementation, based on multiple read times and multiple process identifiers, it is determined whether multiple update information entries are the same. This includes: determining that multiple update information entries are the same based on multiple read times being the same and multiple process identifiers being the same; or determining that multiple update information entries are not the same based on multiple read times not being completely identical and multiple process identifiers not being completely identical. If multiple read times are the same and multiple process identifiers are the same, it can be assumed that the multiple update information entries, including read times and process identifiers, have not changed, and thus it can be determined that the multiple update information entries are the same. If multiple read times are not completely identical and multiple process identifiers are not completely identical, it can be assumed that the multiple update information entries, including read times and process identifiers, have changed, and thus it can be determined that the multiple update information entries are not completely identical. Determining the disk status based on whether the determined multiple update information entries are the same ensures the accuracy of the detection results.
[0008] In one possible implementation, the disk state is determined based on whether multiple updated information entries are identical and multiple states of the disk read process. This includes determining the disk state as faulty based on the identical updated information entries and the fact that multiple states of the disk read process are all unresponsive. By combining multiple updated information entries and multiple states of the disk read process, and determining the disk state as faulty when multiple updated information entries are identical and multiple states of the disk read process are all unresponsive, the accuracy of detection can be improved by avoiding incorrect determination of the disk state based on a single piece of information.
[0009] In one possible implementation, the disk state is determined based on whether multiple updated information entries are identical and the multiple states of the disk read process. This includes determining the disk state as normal based on the fact that multiple updated information entries are not entirely identical and that a running state exists among the multiple states of the disk read process. By combining multiple updated information entries and the multiple states of the disk read process, even when multiple updated information entries are not entirely identical and a running state exists among the multiple states of the disk read process, the disk is considered to be operating normally, and the disk state is determined to be normal. This improves the tolerance for brief periods of unresponsiveness in the disk read process and enhances the accuracy of detection.
[0010] In one possible implementation, the time interval between two adjacent read times is a heartbeat cycle, and the read time is updated based on the time it takes for the disk read process to read data according to the heartbeat cycle. The disk read process reads data from the disk according to the heartbeat cycle and updates the read time based on the data read time, ensuring timely updates to the read time.
[0011] Secondly, a disk status detection device is provided. This device is used in devices providing cloud computing services. The device includes: an acquisition module, configured to acquire the status of a disk reading process multiple times within a detection period, the disk reading process being used to read data from the disk; the acquisition module is also configured to acquire update information of the disk reading process multiple times within the detection period, the update information including the data reading time, the data reading time indicating the time when the disk reading process reads data from the disk, and the two data read at two adjacent reading times having an interval space on the disk; and a determination module, configured to determine the disk status based on whether the acquired update information is the same and the multiple statuses of the disk reading process.
[0012] In one possible implementation, the update information also includes a process identifier of the disk read process, which is used to identify the disk read process that reads disk data; the determining module is also used to determine whether the multiple update information are the same based on the multiple read times and multiple process identifiers obtained.
[0013] In one possible implementation, the determining module is used to determine that multiple update information is the same based on multiple read times being the same and multiple process identifiers being the same; or, based on multiple read times not being completely the same and multiple process identifiers not being completely the same, to determine that multiple update information is not completely the same.
[0014] In one possible implementation, a determination module is used to determine the disk state as a fault state based on multiple identical update messages and multiple unresponsive states of the disk read process.
[0015] In one possible implementation, a determination module is used to determine the disk state as normal based on the fact that multiple update information is not completely identical and that there is a running state among multiple states of the disk read process.
[0016] In one possible implementation, the time interval between two adjacent read times is a heartbeat cycle, and the read time is updated based on the time when the disk read process reads data according to the heartbeat cycle.
[0017] Thirdly, a computing device cluster is provided, including at least one computing device, each computing device including a processor coupled to a memory; the processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the computing device cluster to perform a disk status detection method as provided in the first aspect or any possible implementation thereof.
[0018] Fourthly, a computer program product containing instructions is provided, which, when executed by a computing device cluster, causes the computing device cluster to perform a disk status detection method as provided in the first aspect or any possible implementation thereof. The computer program product can be a software installation package, which can be downloaded and executed on the computing device cluster when the aforementioned functionality of the computing device cluster is required.
[0019] Fifthly, a computer-readable storage medium is provided, including computer program instructions that, when executed by a cluster of computing devices, perform a disk status detection method as provided in the first aspect or any possible implementation thereof. The storage medium includes, but is not limited to, volatile memory, such as random access memory, and non-volatile memory, such as flash memory, hard disk drive (HDD), and solid-state drive (SSD).
[0020] It should be understood that the beneficial effects of the technical solutions and corresponding possible implementations of the second to fifth aspects of this application can be found in the above description of the technical effects of the first aspect and its corresponding possible implementations, and will not be repeated here. Attached Figure Description
[0021] Figure 1 A schematic diagram illustrating an implementation scenario provided in this application.
[0022] Figure 2 This is a schematic flowchart of a disk status detection method provided in an embodiment of this application;
[0023] Figure 3 This is a schematic diagram of a disk status detection process provided in an embodiment of this application;
[0024] Figure 4 This is a schematic diagram illustrating an exemplary implementation scenario provided in this application.
[0025] Figure 5 This is a schematic diagram of the structure of a disk status detection device provided in an embodiment of this application;
[0026] Figure 6 This is a schematic diagram of the hardware structure of a computing device provided in an embodiment of this application;
[0027] Figure 7 This is a schematic diagram of the structure of a computing device cluster provided in an embodiment of this application;
[0028] Figure 8This is a schematic diagram of a connection method for a computing device cluster provided in an embodiment of this application. Detailed Implementation
[0029] The terminology used in the implementation section of this application is for the purpose of explaining specific embodiments of this application only, and is not intended to limit this application.
[0030] In cloud environments where cloud computing technology is rapidly developing, its data processing capabilities are becoming increasingly powerful, enabling the parallel processing of ever-growing amounts of data. This data can be stored in cloud databases. Cloud databases can be, for example, relational database services (RDS), relational databases supporting structured query language (RDS for MySQL), or high-performance relational databases supporting PostgreSQL (RDS for PostgreSQL). Due to the large scale of cloud databases, they are typically divided into multiple cloud database instances in cloud applications, with each instance serving as a small management unit. Managing stored data through cloud database instances allows for more precise management of the data stored in the cloud database. A cloud database instance can contain multiple disks, whose storage space is used to store data. These disks can also be called data disks or data disks; in cloud environments, they can also be called cloud disks or cloud drives.
[0031] During disk operation, failures such as disk hangs can occur, causing disks to malfunction and impacting the normal operation of cloud computing services. For example, if a storage pool consisting of a group of disks storing user data loses power, each disk in the pool may become unresponsive, resulting in damage to the corresponding cloud computing services and preventing them from operating normally. As the number and scale of cloud database instances grow, disk failures within these instances are becoming increasingly common. Therefore, it is crucial to promptly monitor disk status and make timely decisions and implement repairs for the disks or the cloud database.
[0032] This application provides a method for detecting disk status, which can detect the disk status in a timely and accurate manner to ensure the normal operation of cloud computing services based on the data stored on the disk. See also Figure 1The diagram illustrates one implementation scenario. This scenario includes a reading module 11, a detection module 12, and a disk 13. The reading module 11 can be connected to both the detection module 12 and the disk 13. The reading module 11 and the detection module 12 can be integrated into the same computing device. In this computing device, the reading module 11 and the detection module 12 can be two logically separate modules or two physically separate modules; this embodiment does not limit this.
[0033] The reading module 11 can launch different processes by running different code; these processes can be disk reading processes or other processes. The detection module 12 can work in conjunction with the reading module 11 to detect the disk status of the disk 13 based on the execution results of different processes within the reading module 11. The disk 13 can be a physical disk or a virtual disk (VD), and there can be one or more disks 13. If there are multiple disks 13, the disk status detection method provided in this embodiment can perform serial detection on each of the multiple disks 13, or it can perform parallel detection on the multiple disks 13.
[0034] See Figure 2 This application provides a method for detecting disk status, which can be applied to... Figure 1 In the implementation scenario shown, the method may include the following steps S201 to S203.
[0035] S201: The status of the disk read process is obtained multiple times during the detection cycle. The disk read process is used to read data from the disk.
[0036] The detection cycle refers to the time interval within which a disk status check can be completed. This cycle can be set based on experience and application scenarios. It can also be sufficient time for the disk read process to complete multiple data reads under normal disk conditions, such as 1 minute or 85 seconds. If the detection cycle is set too long, disk fault conditions may not be detected and reported in a timely manner. If the detection cycle is set too short, the disk read process may read data less frequently within the cycle, leading to incorrect disk status determination based on the data read process. During a disk status check, there can be one or more detection cycles, and the number of times the disk read process reads data can also be set based on experience or application scenarios. Furthermore, the detection cycle can be the same or different when checking the status of different disks.
[0037] A disk read process is a process used to read data from the disk. For example, it can be a DD read process based on device driver (DD) commands or DD tools. A disk read process can be a child process of another process, which can be a control process that directs the disk read process to complete the read operation; for example, it can be a disk input / output (I / O) data read process. Disk read processes and other processes can reside in the same root directory or under the same root user, and both disk read processes and other processes can contain multiple different threads.
[0038] The states of a disk read process include, but are not limited to, running (R), sleeping (S), and disk sleep (D) states. The running state can also be called an executable state, the sleeping state can also be called an interruptible sleep state, and the disk sleep state can also be called an uninterruptible or uninterruptible sleep state. The state of the disk read process can be obtained by querying the operating system's process information file. The operating system refers to the operating system supported by the device in this embodiment, such as Linux or Windows. The operating system's process information file stores the running status and other information of each process in the operating system. By querying the disk read process status stored in the operating system's process information file, the detection module can obtain the state of the disk read process. For example, if the detection module finds that the disk read process in the operating system's process information file is in a running state, it can be determined that the disk read process is running normally. If the detection module finds that the disk read process in the operating system's process information file is in a disk sleep state, it can be determined that the disk read process is unresponsive.
[0039] After the disk read process starts, it can read data from the disk through the input / output interface of the disk to be tested. The data read can be disk input / output data or other data stored on the disk. After the disk read process completes one data read, it shuts down. In this embodiment, the state of the disk read process is the state from the start to the shutdown of the disk read process. Since the disk read process will start and shut down multiple times during the detection period, or in other words, there will be multiple different read processes, the states of the disk read process obtained multiple times during the detection period are the states of the disk read process during different read processes.
[0040] S202: Obtain update information of disk read process multiple times within the detection period.
[0041] Update information refers to the information updated after a disk read process completes a data read, or after the disk read process closes. Update information can also be called heartbeat information. Update information includes the data read time, which indicates the time it took for the disk read process to read data from the disk. Two adjacent read times represent two pieces of data with an interval on the disk. In some embodiments, the read time may also be referred to as a timestamp or heartbeat timestamp.
[0042] The time it takes for a data read can be the point in time when the disk read process begins reading data from the disk, the point in time when the disk read process ends reading data, or a period of time that includes the point in time when the disk read process begins reading data and the point in time when the disk read process ends reading data.
[0043] Two adjacent read times are both within the detection period, and the time interval between two adjacent read times is the heartbeat cycle. The read time is updated based on the time when the disk read process reads data according to the heartbeat cycle. The two pieces of data read in two adjacent read times can be located in different locations on the disk, and there is a gap between the two pieces of data. Because there is a gap between the two pieces of data read, the process of the disk read process reading data multiple times can be called skipping reads. For example, the disk read process can start reading the first piece of data at the first read time within the detection period, and after completing the reading of the first piece of data, the first read time is determined as the read time of one piece of data. The size of the first piece of data can be determined based on experience or work requirements, and can be a size that consumes less input / output resources, such as 4 kilo bits (Kbit). The disk read process can start reading the second piece of data at the second read time, and after completing the reading of the second piece of data, the second read time is determined as the read time of another piece of data. The second read time is the read time adjacent to the first read time after the disk read process completes the reading of the first piece of data, and the time interval between the second read time and the first read time is the heartbeat cycle. The heartbeat cycle can be set based on experience or work requirements, for example, it can be 10 milliseconds (ms). When the disk read process reads the second data, it can determine the position of the second data on the disk based on the position of the first data on the disk, which has a space interval from the position of the first data on the disk, and read the second data based on the position of the second data on the disk.
[0044] This application does not limit the size of the interval space. It can be determined based on the storage space of the detected disk, or it can be determined based on the storage space of the detected disk and a set number of reads. For example, determining it based on the storage space of the detected disk can be done by calculating the storage space corresponding to a proportion of the detected disk's storage space, and then defining the storage space corresponding to the calculated proportion as the interval space. For instance, if the detected disk's storage space is 10 megabits (Mbit) and the proportion is 10%, then the interval space size can be calculated to be 1 Mbit.
[0045] For example, the size of the interval space is determined based on the storage space of the disk being tested and the set number of reads. The interval space can be determined as the ratio of the storage space to the set number of reads. For instance, if the storage space of the disk being tested is 20 Mbit and the set number of reads is 20, then the size of the interval space can be determined to be 1 Mbit.
[0046] Alternatively, the size of the interval space can be determined based on experience or detection granularity. The interval space is positively correlated with the detection granularity; for example, the finer the required detection granularity, the smaller the interval space. In this embodiment, the size of the interval space can be determined first, and then the number of reads of the disk being detected can be determined. For example, if the storage space of the disk being detected is 50 Mbit, the set interval space size is 800 Kbit, and the size of the data read each time is 200 Kbit, then the number of reads can be determined to be 50.
[0047] After determining the interval space, number of reads, and heartbeat cycle, the disk read process performs multiple data reads on the detected disk according to the interval space, number of reads, and heartbeat cycle. After each read is completed, the disk read process updates its information. This process of the disk read process simulating other devices reading data stored on the disk through input / output interfaces is analogous to this process. However, because the disk read process in this embodiment can use a skip-read approach, it consumes fewer input / output resources, improves data reading efficiency, and reduces the time required for each data read.
[0048] For example, the update information in this embodiment can be stored on a different disk than the disk being detected. For instance, the update information can be stored on the disk where the reading module is located, thus avoiding dependency between the update information and the disk being detected. For example, if the update information is stored on the disk being detected, and the disk is in a faulty state, the detection module cannot obtain the update information through the input / output interface of the disk being detected, resulting in the inability to complete the detection. However, if the update information is stored on a different disk than the disk being detected, even if the disk being detected is in a faulty state, the detection module can still obtain the update information through the input / output interface of the disk storing the update information, thereby enabling the detection of the disk's status.
[0049] S203, determine the disk status based on whether the multiple update information obtained are the same and the multiple states of the disk read process.
[0050] In one possible implementation of this application, the update information may include not only the data read time but also the process identifier (PID) of the disk read process. The process identifier is used to identify the disk read process reading disk data; it can also be called a process control character or process number. If the disk read process is a DD process, then the process identifier can be DD PID.
[0051] After a disk read process starts, the system assigns it a process identifier. This process identifier is unique and immutable during the process's execution. After the disk read process shuts down, it releases its process identifier, which is then reclaimed by the system. For example, if the system assigns process identifier 6 to the disk read process upon startup, this identifier remains 6 throughout its execution. When the process shuts down, it releases process identifier 6, which the system reclaims and can assign to other processes running in the system. When the disk read process starts again, the system reassigns a new process identifier. This new identifier can be the same as or different from the previously assigned one. For example, it can reassign the same identifier as 6, or a different identifier, such as 15.
[0052] By repeatedly acquiring the read times and process identifiers of disk read processes, multiple read times and multiple process identifiers of disk read processes within a detection period can be obtained. Before determining the disk status based on whether the acquired multiple update information is the same and the multiple states of the disk read processes, the process also includes: determining whether the multiple update information is the same based on the acquired multiple read times and multiple process identifiers.
[0053] In one possible implementation, determining whether multiple update pieces of information are the same based on multiple read times and multiple process identifiers includes: determining that multiple update pieces of information are the same based on the fact that multiple read times are the same and multiple process identifiers are the same; or, determining that multiple update pieces of information are not the same based on the fact that multiple read times are not completely the same and multiple process identifiers are not completely the same. Determining whether multiple update pieces of information are the same based on multiple read times and multiple process identifiers includes the following case A1.
[0054] In scenario A1, the similarity of multiple update messages is determined by whether multiple read times and process identifiers are identical. In this case, if multiple read times and process identifiers are the same, the update messages are identical. If multiple read times are not identical, but multiple process identifiers are identical or not identical, it can be assumed that the disk read process completed multiple reads. However, because the system allocated multiple process identifiers to the disk read process, some process identifiers are the same, resulting in identical process identifiers among the obtained process identifiers. Therefore, it can be concluded that the update messages are not identical, or that the update messages have changed. If multiple read times are different, and multiple process identifiers are different, the update messages are different. If multiple read times are the same, but multiple process identifiers are different, it can be concluded that the obtained read times or process identifiers are incorrect, and it is impossible to determine whether the update messages are identical based on the obtained process identifiers and read times.
[0055] For example, if the detection module obtains 3 read times and 3 process identifiers within the detection period, and the 3 read times and 3 process identifiers are the same, then the 3 update information can be considered to be the same. If the 3 read times and 3 process identifiers are not completely the same, then the 3 update information can be considered to be not completely the same, or the update information can be considered to have changed.
[0056] In one possible implementation, it can also be determined whether multiple update messages of the disk read process are the same based on the following condition A2.
[0057] In scenario A2, the similarity of multiple update messages is determined by whether multiple read times are the same. In this case, if multiple read times are the same, the multiple update messages can be considered the same; if multiple read times are not exactly the same, the multiple update messages can be considered not exactly the same, or the update messages can be considered to have changed.
[0058] For example, if three read times are obtained, two of which are the same, and the third read time is different from the other two, then the three update information can be considered not to be completely the same, or the update information can be considered to have changed.
[0059] After determining whether multiple update information is the same based on the above two cases A1 and A2, the disk status can be determined based on whether the multiple update information is the same and the multiple states of the disk read process, including but not limited to the following two cases B1 and B2.
[0060] In case B1, based on the fact that multiple update messages are identical and multiple states of the disk read process are unresponsive, the disk status is determined to be a fault state.
[0061] If multiple update messages are identical and multiple states of the disk read process are unresponsive, it can be assumed that the disk read process did not start and stop multiple times during the detection period, and the disk read process remained unresponsive throughout the detection period. Since the disk read process did not read data from the disk multiple times through the disk's input / output interface, it indicates that the disk's input / output interface is faulty, and thus the disk's state can be determined as faulty.
[0062] If the disk read process can run successfully, it can read data through the disk's input / output interface. The update information will change as the disk read process reads data multiple times. Therefore, even if the disk read process has a running state that is not detected by the detection module during the detection period, since the update information has not changed, it can still be considered that the disk read process has failed to complete a data read, thus confirming that the disk is in a faulty state during the detection period.
[0063] In case B2, based on the fact that multiple update messages are not completely identical and that the disk read process exists in multiple states, the disk state is determined to be normal.
[0064] If multiple update messages are not completely identical and the disk read process is in a running state among multiple states, it can be assumed that the disk read process has successfully completed at least one data read within the detection period, and therefore the disk status can be determined to be normal.
[0065] Alternatively, if the disk's input / output interface happens to be briefly in a sleep or unresponsive state when the detection module acquires the disk read process status, causing the disk read process to also briefly enter a sleep or unresponsive state, and then returns to normal after the detection module acquires the disk read process status, allowing the disk read process to read data normally, then even if the detection module acquires multiple disk read process statuses as sleep or unresponsive, and the multiple update messages are not entirely identical, the disk status can still be determined as normal.
[0066] See Figure 3 This diagram illustrates a disk status detection process. After the control process in the read module starts, the system assigns a process identifier to it. During the operation of the control process, the disk read process, as a child process of the control process, will start multiple times. Before each disk read process starts, the system assigns a process identifier to it through the control process. The control process can record the current process identifier of the disk read process. During operation, the disk read process can read data from the disk to be detected. The disk to be detected can be disk 1, disk 2, and disk 3. Disks 1, 2, and 3 can be adjacent physical disks in the cloud database storage device, or they can be virtual disks divided according to storage areas within the storage space of a physical disk in the cloud database storage device. For example, disk 1, disk 2, and disk 3 can be the third virtual disk ( / dev / vdc), the fourth virtual disk ( / dev / vdd), and the fifth virtual disk ( / dev / vde) of a physical disk in the cloud database storage device, respectively, divided according to storage areas within the storage space.
[0067] After each read of data from the disk to be tested, the disk read process reports to the control process that a data read has been completed, closes the disk read process, and releases the process identifier of this disk read process.
[0068] After receiving feedback from the disk read process, the control process updates the read time. The detection module repeatedly obtains the process identifier of the control process, the read time, the process identifier of the disk read process, and the status of the disk read process within the detection period. If the detection module can obtain the process identifier of the control process, it means that the control process is running. However, if the control process is running, but multiple read times and multiple process identifiers of the disk read process do not change within the detection period, and the disk read process remains in a sleep or unresponsive state, it can be determined that the disk under test is no longer functioning properly, and the disk status of the disk under test is faulty.
[0069] See Figure 4 The diagram illustrates an exemplary implementation scenario, which includes a dual-machine cluster system (highly available, HA) server 41, a master instance node 42, and a slave instance node 43, wherein the HA server can connect to the master instance node 42 and the slave instance node 43, respectively.
[0070] The primary instance node 42 and the standby instance node 43 are distributed in the same cloud database instance. Both the primary instance node 42 and the standby instance node 43 contain at least one disk. Both the primary instance node 42 and the standby instance node 43 have an agent service module deployed. The primary instance node 42 can also be called the primary node instance or the primary node, and the standby instance node 43 can also be called the standby node instance or the standby node. The agent service module can also be called the agent module.
[0071] The proxy service module can integrate a detection module and a reading module. These modules are responsible for detecting the disk status and operating system (OS) status of the instance node where the proxy service module is currently located. The proxy service module then reports the detection results to the HA server. These results are used by the HA server and technical personnel to monitor and repair the instance nodes. Since each instance node resides within a cloud database instance, the proxy service module can report the disk status of the instance nodes by sending database (DB) status messages to the HA server.
[0072] When the detection module detects an anomaly or a disk failure in the database, the agent service module reports this information to the HA server. Based on the reported information and decision conditions, the HA server makes a decision, such as executing failover logic. This decision ensures that the cloud database instance is not affected by the disk failure. The decision conditions for executing failover logic include, but are not limited to, the following two points:
[0073] First point: A disk failure was detected on the primary instance node;
[0074] Second point: There is an available standby instance node in the cloud database instance where the primary instance node is located, and the disk status of the standby instance node is normal.
[0075] The database status messages reported by the proxy service module to the HA server may include the status information of each disk. The status information of each disk includes, but is not limited to, the disk's identity document (ID), disk type, and disk status. For example, the status information of each disk can be obtained using the function `diskStatus`. For instance, the status information of one disk in the primary instance node 42 can be obtained using the following code.
[0076]
[0077] As can be seen from the code above, the disk ID of primary instance node 42 is 17645, the disk type is a data disk, and the status is a breakdown. Therefore, it can be determined that one disk of primary instance node 42 is faulty, which meets the first condition of the decision condition for executing the switchover logic. Since there is a standby instance node 43 in the cloud database instance where primary instance node 42 resides, if the disk status of standby instance node 43 is normal, then the second condition of the decision condition for executing the switchover logic is also satisfied. Therefore, the switchover logic operation can be performed on primary instance node 42 and standby instance node 43: primary instance node 42 is demoted to standby, switching it to standby; standby instance node 43 is promoted to primary, switching it to primary. This ensures that the operation of the cloud database instance is not affected by the disk failure of the original primary instance node 42, improving the high availability of the cloud database instance.
[0078] In related technologies, disk malfunction is determined by repeatedly checking whether all processes or threads on each disk in the cloud database are in an unresponsive state. However, since normal disk processes or threads may also briefly enter an uninterruptible state multiple times before resuming, this technology may mistakenly identify normal disks with processes or threads briefly in an uninterruptible state as faulty disks, leading to misjudgments and making it difficult to guarantee the accuracy of the detection results.
[0079] This application embodiment determines the disk status by combining the read time, the disk read process status, and the process identifier of the disk read process. If the disk read process repeatedly enters a brief unresponsive state and then resumes, there is no false positive because the read time and the process identifier of the disk read process will be updated normally after the disk read process resumes, and the condition for determining the disk to be in a faulty state in this application embodiment will not be met. Therefore, a disk in a normal state will not be mistakenly identified as a faulty disk. Thus, this application embodiment can avoid classifying a normal disk that is briefly in an unresponsive state as a faulty disk, reducing the possibility of false positives and improving the accuracy of detection.
[0080] Another related technology involves invasively modifying the cloud database kernel by adding detection code to the code running the disk's processes. This allows the determination of whether the disk processes are in an uninterruptible state, thereby identifying disk failures. However, invasive modifications to cloud databases are costly and complex, and the detection method lacks universality for disks with different structures or specifications.
[0081] This application embodiment periodically reads the disk to be tested through a disk reading process, and reduces the amount and time of reading input and output data by skipping reads, thereby reducing the consumption of disk input and output resources and achieving efficient testing. Furthermore, it does not require intrusive modifications to cloud databases or cloud computing services, and the testing method is universal for disks of different structures or specifications.
[0082] In summary, this application achieves detection by comparing whether multiple updated information obtained are the same and analyzing multiple states of the disk read process. The detection cost is low, the detection process is simple, the detection method is universal, and the disk state determined based on the update information and state of the disk read process is accurate.
[0083] The disk status detection method provided in the embodiments of this application has been described above. Corresponding to the above method, the embodiments of this application also provide a disk status detection device. This device is applied to a device providing cloud computing services. The device is used to detect disk status through… Figure 5 Each module shown performs the above... Figure 2 The method shown. (As illustrated) Figure 5 As shown, the disk status detection device provided in this application embodiment includes the following modules.
[0084] The acquisition module 501 is used to acquire the status of the disk read process multiple times within the detection period. The disk read process is used to read data from the disk. The acquisition module 501 is also used to acquire the update information of the disk read process multiple times within the detection period. The update information includes the data read time, which indicates the time when the disk read process reads data from the disk. The two data read by two adjacent read times have an interval space on the disk. The determination module 502 is used to determine the disk status based on whether the acquired update information is the same and the multiple statuses of the disk read process.
[0085] In one possible implementation, the update information also includes a process identifier of the disk read process, which is used to identify the disk read process that reads disk data; the determining module 502 is also used to determine whether the multiple update information are the same based on the multiple read times and multiple process identifiers obtained.
[0086] In one possible implementation, the determining module 502 is used to determine that multiple update information is the same based on multiple read times being the same and multiple process identifiers being the same; or, based on multiple read times not being completely the same and multiple process identifiers not being completely the same, to determine that multiple update information is not completely the same.
[0087] In one possible implementation, the determining module 502 is used to determine the disk state as a fault state based on the fact that multiple update information are the same and multiple states of the disk read process are unresponsive.
[0088] In one possible implementation, the determining module 502 is used to determine the disk state as normal based on the fact that multiple update information is not completely identical and that there is a running state among multiple states of the disk read process.
[0089] In one possible implementation, the time interval between two adjacent read times is a heartbeat cycle, and the read time is updated based on the time when the disk read process reads data according to the heartbeat cycle.
[0090] It should be understood that the above Figure 5 The beneficial effects that the provided device possesses in performing its function are... Figure 2 The provided disk status detection methods offer the same beneficial effects, and will not be elaborated upon here. Additionally, Figure 5The provided device, in implementing its functions, is only illustrated by the division of the above-described functional modules. In practical applications, the functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. Furthermore, the device and method embodiments provided in the above embodiments belong to the same concept, and their specific implementation processes are detailed in the method embodiments, and will not be repeated here.
[0091] Furthermore, in the aforementioned disk status detection device, both the acquisition module 501 and the determination module 502 can be implemented in software or in hardware. For example, the implementation of the acquisition module 501 will be described below. Similarly, the implementation of the determination module 502 and other modules can refer to the implementation of the acquisition module 501.
[0092] As an example of a software functional unit, module 501 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, or a container. Further, the aforementioned computing instance may be one or more. For example, module 501 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed within the same region or in different regions. Further, the multiple hosts / virtual machines / containers used to run the code may be distributed within the same availability zone (AZ) or in different AZs, each AZ including one or more geographically proximate data centers. Typically, a region may include multiple AZs.
[0093] Similarly, multiple hosts / virtual machines / containers used to run this code can be distributed within the same Virtual Private Cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Communication between two VPCs within the same region, as well as between VPCs in different regions, requires a communication gateway to be set up within each VPC to enable interconnection between VPCs.
[0094] As an example of a hardware functional unit, the acquisition module 501 may include at least one computing device. Alternatively, the acquisition module 501 may also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be implemented using a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), or any combination thereof.
[0095] The multiple computing devices included in the acquisition module 501 can be distributed in the same region or in different regions. Similarly, the multiple computing devices included in the acquisition module 501 can be distributed in the same Availability Zone (AZ) or in different AZs. Likewise, the multiple computing devices included in the acquisition module 501 can be distributed in the same VPC or in multiple VPCs. These multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.
[0096] It should be noted that, in other embodiments, the acquisition module 501 can be used to execute any step in the disk status detection method. That is, the steps implemented by the acquisition module 501 and the determination module 502 can be specified as needed. The acquisition module 501 and the determination module 502 respectively implement different steps in the disk status detection method to achieve all the functions of the disk status detection device. Furthermore, the disk status detection device and the disk status detection method embodiments provided in the above embodiments belong to the same concept, and their specific implementation process is detailed in the method embodiments, which will not be repeated here.
[0097] This application also provides a computing device that can be configured as the device in the above-described implementation scenario. (Reference) Figure 6 , Figure 6 This is a schematic diagram of the hardware structure of a computing device provided in an embodiment of this application. Figure 6 As shown, the computing device 600 includes a bus 602, a processor 604, a memory 606, and a communication interface 608. The processor 604, the memory 606, and the communication interface 608 communicate with each other via the bus 602. It should be understood that this application does not limit the number of processors and memories in the computing device 600.
[0098] Bus 602 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be divided into address buses, data buses, control buses, etc. For ease of representation, Figure 6 The bus 602 may be represented by a single line, but this does not mean that there is only one bus or one type of bus. The bus 602 may include a path for transmitting information between various components of the computing device 600 (e.g., memory 606, processor 604, communication interface 608).
[0099] Processor 604 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).
[0100] Memory 606 may include volatile memory, such as random access memory (RAM). Processor 604 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).
[0101] The memory 606 stores executable program code, which the processor 604 executes to implement the functions of the aforementioned acquisition module 501 and determination module 502, thereby realizing the disk status detection method. In other words, the memory 606 stores instructions for executing the disk status detection method.
[0102] The communication interface 608 uses transceiver modules, such as, but not limited to, network interface cards and transceivers, to enable communication between the computing device 600 and other devices or communication networks.
[0103] This application also provides a computing device cluster. The computing device cluster includes at least one computing device. This computing device can be configured as the device described in the above-described implementation scenario.
[0104] Figure 7This is a schematic diagram of the structure of a computing device cluster provided in an embodiment of this application. For example... Figure 7 As shown, the computing device cluster includes at least one computing device 600. The memory 606 of one or more computing devices 600 in the computing device cluster may store the same instructions for performing a disk status detection method.
[0105] In some possible implementations, the memory 606 of one or more computing devices 600 in the computing device cluster may also store partial instructions for executing a disk status detection method. In other words, a combination of one or more computing devices 600 can jointly execute instructions for executing a disk status detection method.
[0106] It should be noted that the memory 606 in different computing devices 600 within the computing device cluster can store different instructions, each used to execute a portion of the functions of the disk status detection device. That is, the instructions stored in the memory 606 of different computing devices 600 can implement the functions of one or more modules in the acquisition module 501 and the determination module 502.
[0107] In some embodiments, one or more computing devices in a computing device cluster can be connected via a network. This network can be a wide area network (WAN) or a local area network (LAN), etc. Figure 8 This is a schematic diagram illustrating a connection method for a computing device cluster provided in an embodiment of this application. For example... Figure 8 As shown, the two computing devices 600 are connected via a network. Specifically, they are connected to the network through the communication interfaces in each computing device.
[0108] It should be understood that, Figure 8 The functions of the computing device 600 shown can also be performed by multiple computing devices 600.
[0109] In an exemplary embodiment, a computer program product containing instructions is provided that, when executed by a cluster of computing devices, causes the cluster of computing devices to perform actions such as... Figure 2 The disk status detection method is shown. This computer program product can be a software installation package. When the functionality of the aforementioned computing device cluster needs to be implemented, this computer program product can be downloaded and executed on the computing device cluster.
[0110] In an exemplary embodiment, a computer-readable storage medium is provided, including computer program instructions that, when executed by a cluster of computing devices, perform actions such as... Figure 2The method for detecting disk status is shown. The storage medium includes, but is not limited to, volatile memory, such as random access memory, and non-volatile memory, such as flash memory, hard disk, and solid-state drive.
[0111] In an exemplary embodiment, a computing device cluster is provided, including at least one computing device, each computing device including a processor coupled to a memory; the processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device, causing the computing device cluster to perform, for example... Figure 2 The disk status detection method is shown.
[0112] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive).
[0113] In this application, the terms "first," "second," etc., are used to distinguish identical or similar items with substantially the same function. It should be understood that there is no logical or temporal dependency between "first," "second," and "nth," nor does it limit the quantity or order of execution. It should also be understood that although the following description uses the terms "first," "second," etc., to describe various elements, these elements should not be limited by the terms. These terms are merely used to distinguish one element from another.
[0114] It should also be understood that, in the various embodiments of this application, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.
[0115] In this application, the term "at least one" means one or more, and the term "multiple" means two or more. For example, multiple second devices means two or more second devices. The terms "system" and "network" are often used interchangeably herein.
[0116] It should be understood that the terminology used in the description of the various examples herein is for the purpose of describing particular examples only and is not intended to be limiting. As used in the description of the various examples and the appended claims, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise.
[0117] It should also be understood that the term "and / or" as used herein refers to and covers any and all possible combinations of one or more of the associated listed items. The term "and / or" describes an association between related objects, indicating that three relationships can exist; for example, A and / or B can represent: A alone, A and B simultaneously, or B alone. Additionally, the character " / " in this application generally indicates that the preceding and following related objects are in an "or" relationship.
[0118] It should be noted that all information, data, and signals involved in this application have been authorized by the user or by all parties in full, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, the updated information involved in this application was obtained with full authorization.
[0119] It should also be understood that the terms “if” and “if” can be interpreted as meaning “when” or “upon”, or “in response to determination” or “in response to detection”. Similarly, depending on the context, the phrases “if determination…” or “if detection [the stated condition or event]” can be interpreted as meaning “when determination…”, or “in response to determination…”, or “when detection [the stated condition or event]” or “in response to detection [the stated condition or event]”.
[0120] The above description is merely an embodiment of this application and is not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the protection scope of this application.
Claims
1. A method for detecting disk status, characterized in that, The method is used for a device providing cloud computing services, and the method includes: The status of the disk read process is acquired multiple times during the detection period. The disk read process is used to read data from the disk. The status of the disk read process is the state from the start of the disk read process to the shutdown of the disk read process. The status of the disk read process includes running state, sleeping state or unresponsive state. The disk read process performs multiple data reads from the disk according to the interval space, the number of reads, and the heartbeat cycle. After each read is completed, the update information of the disk read process is updated. The heartbeat cycle is the time difference between two adjacent data reads, and the interval space is the interval between two adjacent data reads on the disk. The update information of the disk reading process is acquired multiple times during the detection period. The update information includes the data reading time and the process identifier of the disk reading process. The data reading time is used to indicate the time when the disk reading process reads data from the disk, and the process identifier is used to identify the disk reading process that reads disk data. Based on the fact that the multiple update messages are identical and the multiple states of the disk read process are all unresponsive, the disk state is determined to be a fault state; or, based on the fact that the multiple update messages are not completely identical and the existence of a running state among the multiple states of the disk read process, the disk state is determined to be a normal state.
2. The method according to claim 1, characterized in that, Before determining the disk state based on whether multiple updated information entries are identical and the multiple states of the disk read process, the method further includes: Based on the acquired multiple read times and multiple process identifiers, it is determined whether the multiple update information are the same.
3. The method according to claim 2, characterized in that, The step of determining whether the multiple update information items are the same based on the acquired multiple read times and multiple process identifiers includes: Based on the fact that the multiple read times are the same and the multiple process identifiers are the same, it is determined that the multiple update information is the same; Alternatively, based on the fact that the multiple read times are not exactly the same and the multiple process identifiers are not exactly the same, it can be determined that the multiple update information is not exactly the same.
4. The method according to any one of claims 1-3, characterized in that, The time interval between two adjacent read times is a heartbeat cycle, and the read time is based on the time update of the disk read process reading the data according to the heartbeat cycle.
5. A disk status detection device, characterized in that, The apparatus is a device for providing cloud computing services, the apparatus comprising: The acquisition module is used to acquire the status of the disk read process multiple times within the detection period. The disk read process is used to read data from the disk. The status of the disk read process is the status from the start of the disk read process to the shutdown. The status of the disk read process includes running status, sleeping status, or unresponsive status. The data reading module is also used to perform multiple data reads on the disk through the disk reading process according to the interval space, the number of reads and the heartbeat cycle, and update the update information of the disk reading process after each read is completed. The heartbeat cycle is the time difference between two adjacent data reads. The acquisition module is also used to acquire the update information of the disk reading process multiple times within the detection period. The update information includes the data reading time and the process identifier of the disk reading process. The data reading time is used to indicate the time when the disk reading process reads data from the disk. The interval between two data read by two adjacent reading times in the disk is the interval space. The process identifier is used to identify the disk reading process that reads disk data. The determination module is used to determine the disk status as a fault state based on the fact that the multiple update information is the same and that the multiple states of the disk read process are all unresponsive; or, based on the fact that the multiple update information is not completely the same and that there is a running state among the multiple states of the disk read process, the disk status is determined as a normal state.
6. The apparatus according to claim 5, characterized in that, The determining module is further configured to determine whether the multiple update information is the same based on the acquired multiple read times and multiple process identifiers.
7. The apparatus according to claim 6, characterized in that, The determining module is configured to determine that the multiple update information is the same based on the fact that the multiple read times are the same and the multiple process identifiers are the same; or, to determine that the multiple update information is not the same based on the fact that the multiple read times are not completely the same and the multiple process identifiers are not completely the same.
8. The apparatus according to any one of claims 5-7, characterized in that, The time interval between two adjacent read times is a heartbeat cycle, and the read time is based on the time update of the disk read process reading the data according to the heartbeat cycle.
9. A computing device cluster, characterized in that, It includes at least one computing device, each computing device including a processor coupled to memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the computing device cluster to perform the disk status detection method as described in any one of claims 1-4.
10. A computer program product containing instructions, characterized in that, When the instruction is executed by the computing device cluster, the computing device cluster performs the disk status detection method as described in any one of claims 1-4.
11. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes computer program instructions that, when executed by a cluster of computing devices, enable the cluster of computing devices to perform a disk status detection method as described in any one of claims 1-4.