CN118170571A - Fault processing method and computing device - Google Patents
Fault processing method and computing device Download PDFInfo
- Publication number
- CN118170571A CN118170571A CN202410132852.XA CN202410132852A CN118170571A CN 118170571 A CN118170571 A CN 118170571A CN 202410132852 A CN202410132852 A CN 202410132852A CN 118170571 A CN118170571 A CN 118170571A
- Authority
- CN
- China
- Prior art keywords
- node
- shared
- file system
- nodes
- shared file
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000003672 processing method Methods 0.000 title claims abstract description 11
- 238000000034 method Methods 0.000 claims abstract description 143
- 230000008569 process Effects 0.000 claims abstract description 102
- 238000002955 isolation Methods 0.000 claims abstract description 38
- 238000004891 communication Methods 0.000 claims abstract description 28
- 230000006870 function Effects 0.000 description 20
- 238000010586 diagram Methods 0.000 description 14
- 238000012545 processing Methods 0.000 description 10
- 238000011084 recovery Methods 0.000 description 8
- 230000007246 mechanism Effects 0.000 description 7
- 230000004048 modification Effects 0.000 description 6
- 238000012986 modification Methods 0.000 description 6
- 230000004044 response Effects 0.000 description 5
- 238000004590 computer program Methods 0.000 description 4
- 230000009471 action Effects 0.000 description 3
- 238000013461 design Methods 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 230000003993 interaction Effects 0.000 description 3
- 238000012423 maintenance Methods 0.000 description 3
- 230000002159 abnormal effect Effects 0.000 description 2
- 230000008901 benefit Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 230000007717 exclusion Effects 0.000 description 2
- 102100029074 Exostosin-2 Human genes 0.000 description 1
- 101000918275 Homo sapiens Exostosin-2 Proteins 0.000 description 1
- 230000004075 alteration Effects 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 238000012217 deletion Methods 0.000 description 1
- 230000037430 deletion Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 239000002245 particle Substances 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0793—Remedial or corrective actions
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0709—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/17—Details of further file system functions
- G06F16/176—Support for shared access to files; File sharing support
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Data Mining & Analysis (AREA)
- Databases & Information Systems (AREA)
- Computer Hardware Design (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Hardware Redundancy (AREA)
Abstract
The embodiment of the application provides a fault processing method and computing equipment, relates to the technical field of computing equipment, and can perform fault isolation on a shared file system under the condition that a node is not reset, so that the normal operation of other services on the node is prevented from being influenced. The method can be applied to a first node in a shared cluster, each node in the shared cluster is configured with a shared file system, and the shared file system is used for accessing shared data corresponding to the shared cluster by the node; the method comprises the following steps: when the shared file system of the first node fails, the first node disconnects communication with other nodes; configuring node states of other nodes configured on the first node as a first state; the other nodes are nodes except the first node in the shared cluster; and under the condition that other nodes in the shared cluster are in the first state, performing fault isolation on the shared file system. The embodiment of the application can be used in the process of maintaining the computing equipment.
Description
Technical Field
The embodiment of the application relates to the technical field of computing equipment, in particular to a fault processing method and computing equipment.
Background
A shared file system is a file system that is applied to a multi-node environment. Multiple nodes read and write the same data (such as shared data) in parallel through a shared file system, and each piece of data in the shared data is stored in different nodes in a stripe form and the like.
The current fault handling mechanism of the shared file system is that when the shared file system on a certain node fails, the node is reset to stop the operation of the shared file system, so that other nodes can occupy the shared resources used by the node when accessing the shared data. However, one node includes not only shared data but also distributed resource data, local resource data, and the like. If the whole node is directly reset, the distributed resource data on the node and the service corresponding to the local resource data are influenced, so that the influence range of fault processing is larger.
Disclosure of Invention
The embodiment of the application provides a fault processing method and computing equipment, which can perform fault isolation on a shared file system under the condition that a node is not reset, and avoid affecting the normal operation of other services on the node.
In a first aspect, an embodiment of the present application provides a fault handling method, which is applied to a first node in a shared cluster, where each node in the shared cluster is configured with a shared file system, where the shared file system is used by a node to access shared data corresponding to the shared cluster; the method comprises the following steps: when the shared file system of the first node fails, the first node disconnects communication with other nodes; configuring node states of other nodes configured on the first node as a first state; the other nodes are nodes except the first node in the shared cluster; the first state is used for indicating that the shared file system on the node stops running; and under the condition that other nodes in the shared cluster are in the first state, performing fault isolation on the shared file system.
According to the fault processing method provided by the embodiment of the application, when the shared file system of the first node fails, the node states of other nodes configured on the first node are configured to be the first state, and the first state is used for indicating that the shared file system on the node stops running. By disconnecting the first node from communication with other nodes and configuring other nodes on the first node to be offline (i.e. the shared file system stops running), the first node can confirm that the first node is the only node in the shared cluster, so that the first node does not need to negotiate with other nodes when the shared file system fails, and can realize fault isolation of the shared file system without restarting the whole node. Therefore, the problem that other services are affected due to the fact that the whole node is reset when faults occur in the current scheme can be effectively solved, and the influence caused by faults of the shared file system is reduced.
In a possible implementation manner, configuring node states of other nodes configured on the first node to be a first state includes: in the target configuration file, configuring node states of other nodes into a first state; the target configuration file is a file for configuring operation parameters of the shared file system, wherein the operation parameters comprise node states of all nodes in the shared cluster. It should be appreciated that by modifying the target configuration file on the first node, it may be possible to simulate that other nodes exit the shared cluster on the first node, thereby ensuring that the first node can normally offload the shared file system without affecting normal use of the other nodes.
In another possible implementation manner, the shared file system operates in a kernel mode, and the first node further includes a process management program operating in a user mode; the process management program is used for managing all processes in the node; under the condition that other nodes in the shared cluster are in the first state, performing fault isolation on the shared file system, wherein the fault isolation comprises the following steps: under the condition that other nodes in the shared cluster are in a first state, the shared file system is operated to send a first indication message to the process management program; the first indication message is used for indicating to uninstall the shared file system; in response to the first indication message, the shared file system is uninstalled by the process manager to perform fault isolation on the shared file system.
In yet another possible implementation, unloading the shared file system by the process manager includes: determining a target process in the first node; the target process is a process which depends on a shared file system in the first node; stopping the target process by the process management program; in the event that the target process has stopped running, the shared file system is uninstalled by the process manager. It should be appreciated that the shared file system is a kernel-mode program that cannot be forced to stop running. The scheme realizes that the shared file system can be normally unloaded by ending the process of relying on the shared file system.
In yet another possible implementation manner, when the shared file system of the first node fails, the method further includes: configuring read-write state parameters of a shared file system in a first node to be in an unwritable state; the non-writable state is used to indicate that the first node is prohibited from writing data to the shared data. It should be appreciated that configuring to the non-writable state may avoid that erroneous data due to a failure has a greater impact on the shared file system and shared data.
In yet another possible implementation, the method further includes: after the fault of the shared file system of the first node is recovered, the first node establishes communication connection with other nodes and de-isolates the shared file system; configuring node states of other nodes configured on the first node as a second state; the second state is used to indicate that the shared file system on the node is operating properly.
In yet another possible implementation, the method further includes: accessing shared data based on the first shared resource when it is determined that the communication connection between the first node and the second node of the other nodes is broken; the first shared resource includes a second shared resource, which is a resource occupied by the second node accessing the shared data. It should be appreciated that by occupying the shared resources of the failed node, the impact of a node failure on the traffic of the shared cluster may be reduced.
In yet another possible implementation, the method further includes: receiving an instruction when the shared file system of the first node is not failed; the instructions are for instructing to offload the shared file system on the first node; responsive to the instruction, releasing the second shared resource by interacting with the other node in response to the instruction; the second shared resource is a resource occupied by the first node for accessing the shared data; and unloading the shared file system on the first node under the condition that the first node releases the two shared resources. It should be understood that when the shared file system is unloaded under normal conditions, other nodes occupy the shared resources in time through interaction, so that the continuity of the service can be ensured.
In yet another possible implementation, each node is configured with a disk, and the disks of different nodes are used to store different portions of each piece of data in the shared data.
In a second aspect, an embodiment of the present application provides a fault handling apparatus, including: a configuration module and an isolation module; the configuration module is used for disconnecting communication connection with other nodes; the configuration module is further configured to configure node states of other nodes configured on the first node as a first state when the shared file system of the first node fails; the other nodes are nodes except the first node in the shared cluster; the first state is used for indicating that the shared file system on the node stops running; the isolation module is used for carrying out fault isolation on the shared file system under the condition that other nodes in the shared cluster are in a first state.
In a possible implementation manner, the configuration module is specifically configured to configure, in a target configuration file, a node state of the other node to the first state; the target configuration file is a file configured for operating parameters of the shared file system, and the operating parameters include node states of all nodes in the shared cluster.
In another possible implementation manner, the shared file system operates in a kernel mode, and the first node further includes a process management program operating in a user mode; the process management program is used for managing all processes in the node; the unloading module is specifically configured to operate the shared file system to send a first indication message to the process management program when all other nodes in the shared cluster are in a first state; the first indication message is used for indicating to uninstall the shared file system; in response to the first indication message, the shared file system is offloaded by the process manager.
In another possible implementation manner, the unloading module is specifically configured to determine a target process in the first node; the target process is a process which depends on a shared file system in the first node; ending the target process through the process management program; in the event that the target process has stopped running, the shared file system is uninstalled by the process manager.
In another possible implementation manner, the configuration module is further configured to configure a read-write status parameter of the shared file system in the first node to be an unwritable status; the non-writable state is used to indicate that the first node is prohibited from writing data to the shared data.
In another possible implementation manner, the configuration module is further configured to establish a communication connection with another node, and de-isolate the shared file system; configuring node states of other nodes configured on the first node as a second state; the second state is used to indicate that the shared file system on the node is operating properly.
In another possible implementation manner, the apparatus further includes: and accessing the module. The access module is used for accessing the shared data based on the first shared resource when the communication connection between the first node and the second node in other nodes is determined to be disconnected; the first shared resource includes a resource occupied by the second node accessing the shared data.
In another possible implementation manner, the apparatus further includes: a receiving module and a transmitting module; the receiving module is used for receiving an instruction when the shared file system of the first node is not failed; the instructions are for instructing to offload the shared file system on the first node; the sending module is used for responding to the instruction and releasing the second shared resource by interacting with other nodes; the second shared resource is a resource occupied by the first node accessing the shared data; the unloading module is used for unloading the shared file system on the first node under the condition that the resources occupied by the first node for accessing the shared data are released.
In yet another possible implementation, each node is configured with a disk, and the disks of different nodes are used to store different portions of each piece of data in the shared data.
In a third aspect, embodiments of the present application provide a computing device comprising a processor and a memory; the processor is coupled with the memory; the memory is used to store computer instructions that are loaded and executed by the processor to cause the computing device to implement the method of the first aspect described above.
In a fourth aspect, embodiments of the present application provide a computer-readable storage medium comprising: computer software instructions; the computer software instructions, when executed in a computing device, cause the computing device to implement the method of the first aspect described above.
In a fifth aspect, embodiments of the present application provide a computer program product which, when run on a computing device, causes the computing device to perform the steps of the related method described in the first aspect above, to carry out the method of the first aspect above.
Advantageous effects of the second aspect to the fifth aspect described above may refer to corresponding descriptions of the first aspect, and are not repeated.
Drawings
FIG. 1 is a schematic diagram of a local file system according to an embodiment of the present application;
FIG. 2 is a schematic diagram of a shared cluster architecture according to an embodiment of the present application;
FIG. 3 is a schematic diagram of resource distribution in a node according to an embodiment of the present application;
FIG. 4 is a schematic diagram of a computing device according to an embodiment of the present application;
FIG. 5 is a schematic diagram of a software module involved in a fault handling process according to an embodiment of the present application;
FIG. 6 is a schematic flow chart of a fault handling method according to an embodiment of the present application;
FIG. 7 is a schematic flow chart of another fault handling method according to an embodiment of the present application;
FIG. 8 is a flowchart illustrating another fault handling method according to an embodiment of the present application;
FIG. 9 is a flowchart of another fault handling method according to an embodiment of the present application;
FIG. 10 is a flowchart illustrating another fault handling method according to an embodiment of the present application;
FIG. 11 is a schematic flow chart of fault handling according to an embodiment of the present application;
Fig. 12 is a schematic diagram of a fault handling apparatus according to an embodiment of the present application;
fig. 13 is a schematic diagram of a computing device according to an embodiment of the present application.
Detailed Description
The following description of the embodiments of the present application will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present application, but not all embodiments. All other embodiments, which can be made by those skilled in the art based on the embodiments of the application without making any inventive effort, are intended to be within the scope of the application.
It should be noted that, in the embodiments of the present application, words such as "exemplary" or "such as" are used to mean serving as an example, instance, or illustration. Any embodiment or design described herein as "exemplary" or "for example" is not necessarily to be construed as preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary" or "such as" is intended to present related concepts in a concrete fashion.
In order to clearly describe the technical solution of the embodiments of the present application, in the embodiments of the present application, the terms "first", "second", etc. are used to distinguish the same item or similar items having substantially the same function and effect, and those skilled in the art will understand that the terms "first", "second", etc. are not limited in number and execution order.
Technical terms related to the embodiments of the present application are briefly described below:
1. And (3) node: in the field of computing devices, a node is a separate device in a network, each node having a unique identifier to identify itself in the network. In the embodiment of the application, in a shared cluster formed by a plurality of computing devices, one computing device can be called one node.
2. The shared cluster is a cluster formed by a plurality of computing devices, and physical storage (such as magnetic disks) of each computing device is integrated through a shared file system among the computing devices to form a single directory space for storing data. Any one computing device, when accessing data from the directory space, does not need to be concerned about whether the data is stored in its own node or other nodes, thereby enabling any one node to access data in the physical storage of other computing devices as if it had accessed data in its own physical storage. The data in the integrated physical storage may be referred to as shared data. The shared file system may be OCFS2, GFS, VMFS, etc.
For implementations of file management in computing devices, both local file system based implementations and shared file system based implementations are generally included.
In a local file system based implementation, a physical storage (e.g., a disk) in a node for storing data is coupled to a processor in the node. Processors in the nodes access data in the physical storage by running a local file system. For example, the local file system may be a file allocation table 16/32 (file allocation table/32, FAT 16/32), a new technology file system (new technology FILE SYSTEM, NTFS), a 2/3/4 generation extended file system (2/3/4extended filesystem,EXT2/3/4), and the like. Fig. 1 is a schematic diagram of a local file system according to an embodiment of the present application, where, as shown in fig. 1, a processor of each node is connected to a corresponding disk through a respective file system, and different nodes cannot access contents in the corresponding disks of other nodes (for example, processor 1 of node 1 cannot access disk 2 corresponding to node 2), and cannot operate on data in the corresponding disks of other nodes.
In shared file system based implementations, multiple nodes may read and write their shared data in parallel through the shared file system. Fig. 2 is a schematic diagram of a shared cluster provided in an embodiment of the present application, as shown in fig. 2, processors of each of a plurality of nodes read and write the same shared data in parallel through the same set of shared file systems (each node is configured with a shared file system, each shared file system reads a disk corresponding to a respective node, the plurality of shared file systems integrate data of disks of each node through a network to form a single directory space, and for each node, all data accessed through the shared file system are in the same directory space, so that the configuration shared file systems in the plurality of nodes can be regarded as the same set of shared file systems), that is, the processors of each node can perform read and write operations on data in all disks (such as disks 1-3 in fig. 2) through own input/output (I/O) interfaces.
Each piece of data in the shared data is stored in the disks of different I/Os (namely, the disks of different nodes) in a stripe form. Striping refers to splitting a complete piece of data into multiple parts, each of which is stored scattered on disks of different nodes. Thus, when each node in the plurality of nodes reads data, a plurality of processes can be created to realize simultaneous access to the disks of different nodes, so that the data access efficiency is improved.
The shared file system has the following characteristics:
1. and the shared data is read and written in parallel among a plurality of nodes.
2. In order to protect data, mutual exclusion protection is needed between nodes for shared data, that is, for a certain piece of data in the shared data, only a process of one node is allowed to access the data at the same time. Where mutual exclusion protection as referred to herein may be implemented by a protection lock, which is a mechanism in a shared file system to protect data from accidental modification or deletion by other nodes. When a certain piece of data in the shared data is accessed by a node, the node sharing file system configures parameters such as an access main body, access time and the like for the data, and the parameters are used for indicating that only the node indicated by the access main body can access the file in the access time, so that the data configuration protection lock is realized. Because of the existence of the protection lock, when other nodes request to access the data through the shared file system, the shared file system determines that the protection lock of the data exists, and then the other nodes are refused to access, so that the data is prevented from being modified by a plurality of nodes at the same time to cause data collision.
3. If a certain node fails (for example, a shared file system in the node cannot be used), other nodes capable of normally accessing shared data can preempt the shared resource of the abnormal node, where the shared resource refers to a resource (for example, a protection lock, a data copy, etc.) used by the node when accessing the shared data, for example, a normal node can determine the protection lock belonging to the failed node through the shared file system, and the access subject specified by the protection locks is modified from the failed node to the normal node to replace the file protected by the continued access protection lock by the failed node, so that the preemption of the shared resource is realized. For another example, when the failed node accesses the shared data, some temporary data (i.e. the data copy) may be generated to be written to the disk, and the normal node may read the temporary data through the shared file system and perform the action of writing to the disk instead of the failed node, so as to realize preemption of the shared resource.
4. If a node, such as the first node, fails in the shared file system of the first node (such as a network failure, a read-write failure), it may not be possible to continue to access the shared data. In this case, the first node is required to stop running the shared file system so that the first node exits the shared cluster. Because the shared resource occupied by the first node at this time can affect other nodes to access the shared data, the first node can stop the operation of the shared file system after releasing the shared resource used by the first node. In this process, the first node needs to negotiate with other nodes, so that the other nodes preempt the shared resources that need to be released. However, the shared file system of the first node has failed, such as a network failure, so that the negotiation process cannot be performed, that is, the first node cannot stop the operation of the shared file system. Thus, in the event of a failure of the first node's shared file system, the first node's processor will instruct the node to reset (i.e., restart) to force the operation of the shared file system to cease. In addition, since a plurality of nodes form a sharing cluster based on a sharing file system, each node informs itself of the online condition by continuously sending heartbeat signals to other nodes. Therefore, when the shared file system of a certain node stops running, heartbeat signals are not continuously sent to other nodes, so that other nodes can sense that the node stops running and can preempt shared resources occupied by the node.
As described above, the processing manner after the failure of the shared file system in the node is to reset the whole node, and in general, not only a service relying on shared data but also a service relying on other types of data are operated on one node. If the node is reset due to the reason of sharing the file system, the service running on the node based on other types of data can be affected. Fig. 3 is a schematic diagram of resource distribution in a node according to an embodiment of the present application. As shown in fig. 3, each node includes 3 nodes, and each node is deployed with a service depending on distributed resource data, a service depending on local resource data, and a service depending on shared data. If the shared file system in the node 1 fails, the node 1 will automatically reset based on the current failure handling mechanism of the shared file system. However, the service that depends on the distributed resource data and the service that depends on the local resource data, which normally run on the node 1, are also affected by the reset of the node 1, so that in the current shared file system, the scope of influence of fault handling is larger and unreasonable.
In summary, how to ensure that the failure handling mechanism of the shared file system does not affect the normal operation of other services on the node is a problem to be solved.
The embodiment of the application provides a fault processing method, wherein when a shared file system of a first node fails, node states of other nodes configured on the first node are configured to be a first state, and the first state is used for indicating that the shared file system on the node stops running. By disconnecting the first node from communication with other nodes and configuring other nodes on the first node to be offline (i.e. the shared file system stops running), the first node can confirm that the first node is the only node in the shared file system, so that the first node does not need to negotiate with other nodes when the shared file system fails, and can realize fault isolation of the shared file system without restarting the whole node. Therefore, the problem that other services are affected due to the fact that the whole node is reset when faults occur in the current scheme can be effectively solved, and the influence caused by faults of the shared file system is reduced.
The following describes the scheme provided by the embodiment of the application in detail with reference to the attached drawings.
The technical scheme provided by the embodiment of the application can be applied to computing equipment, and the computing equipment can be a blade server, a high-density server, a rack server or a high-performance server, or a general server, a graphics processor (graphics processing unit, GPU) server, a data processor (data processing unit, DPU) server and the like. FIG. 4 is a schematic diagram of a system architecture of a computing device, as shown in FIG. 4, with hardware of the computing device including a processor, an out-of-band controller, a storage, and a memory. The software includes an out-of-band management module and an Operating System (OS).
Wherein the out-of-band management module operates within the out-of-band controller and the OS operates on the processor (as shown in fig. 4).
The out-of-band management module may be a management unit of a non-business module. For example, an out-of-band management module, which may be completely independent of the operating system of the computing device, may communicate with a basic input output system (basic input output system, BIOS) and an OS through an out-of-band management interface of the computing device, may remotely maintain and manage the computing device via a dedicated data channel.
By way of example, the out-of-band management module may include a management unit that calculates the operating state of the device, a management system in a management chip external to the processor, a computing device baseboard management controller (baseboard management controller, BMC), a system management module (SYSTEM MANAGEMENT mode, SMM), and the like. It should be noted that, the embodiment of the present application is not limited to the specific form of the out-of-band management module, and the above is only exemplary.
Memory, also known as internal memory or main memory, is installed in memory slots on the motherboard of a computing device, with the memory and memory controller communicating via a memory channel (channel). The memory has at least one memory rank (rank), each memory rank is located on a face of the memory respectively, each memory rank includes at least one sub-memory rank (subrank), the memory rank or sub-memory rank includes a plurality of memory chips (devices), each memory chip is divided into a plurality of memory array groups (bankgroup), each memory array group includes a plurality of memory arrays (banks), each memory array is divided into a plurality of memory cells (cells), each memory cell has a row (row) address and a column (column) address, each memory cell includes one or more bits. In one division manner, the memory can be sequentially divided into a memory chip, a memory array group, a memory array, a memory row/memory column, a memory unit and a bit from an upper level to a lower level, wherein the addresses of the memory particles, the memory array group, the memory array, the memory row, the memory column, the memory unit and the bit on the memory are real physical addresses. In another division manner, the CPU divides the memory chip into a plurality of memory pages (pages) based on a paging mechanism, where addresses of the memory pages are virtual addresses, and the virtual addresses are converted into real physical addresses.
The memory may be a magnetic disk equipped on a computing device, a smart memory card (SMART MEDIA CARD, SMC), a Secure Digital (SD) card, a flash memory card (FLASH CARD), or the like, or may be an external storage device such as a usb disk, or the like.
In the embodiment of the application, the driver corresponding to the shared file system is stored in the memory, and the processor can run the shared file system to read the shared data in the memory through the shared file system.
It should be noted that, the system architecture and the application scenario described in the embodiments of the present application are for more clearly describing the technical solution of the embodiments of the present application, and do not constitute a limitation on the technical solution provided by the embodiments of the present application, and those skilled in the art can know that, with the evolution of the system architecture and the appearance of the new service scenario, the technical solution provided by the embodiments of the present application is also applicable to similar technical problems.
Fig. 5 is a schematic architecture diagram of a software module involved in a fault handling process according to an embodiment of the present application. As shown in fig. 5, two levels are shown, kernel mode and user mode, respectively. The kernel mode and the user mode are two running states of the operating system, and the main difference of the kernel mode and the user mode is the difference of access rights.
Kernel mode, also referred to as privileged mode, refers to the execution mode in a computing device that has the highest authority. Kernel mode is mainly used for processing system-level tasks such as device drivers, file management, etc.
The kernel mode includes a shared function module 501, a fault handling module 502 and a fault notifying module 503, and the function modules shown in the kernel mode are function modules in the shared file system. The sharing function module 501 is configured to perform some functions in the current shared file system, such as a read-write function, a resource mutex function, and a failure detection function of the shared file system. The fault handling module 502 is configured to disconnect communication with other nodes when the shared file system fault is detected by the sharing function module 501, and simulate the other nodes on the target node (the node running the fault handling module) to stop running the shared file system, so as to exit the shared cluster. The failure notification module 503 is configured to notify the user-state failure isolation module 504 to uninstall the shared file system to perform failure isolation on the shared file system (i.e., the failed node cannot access the shared resource through the shared file system and cannot interact with other nodes through the shared file system).
The user state, also referred to as a non-privileged state, refers to a lower-privilege mode of execution in a computing device, typically used by an application. The user mode is mainly used for executing application programs such as a browser, an editor, a game, and the like. Because the authority corresponding to the user mode is low, the application program running in the user mode can only execute some characteristic instructions and access some limited data, so that the damage of the malicious application program to the computing equipment is avoided.
Included in the user state is a fault isolation module 504, which is a functional module in the process manager running in the node. The fault isolation module 504 is configured to receive a message sent by the fault notification module 503 in the kernel mode, offload the shared file system, so that a node with a fault cannot access the shared resource, and can be regarded as the node has exited the shared cluster, thereby implementing fault isolation between the faulty node and other normal nodes.
Fig. 6 is a schematic flow chart of a fault handling method according to an embodiment of the present application. The fault processing method provided by the embodiment of the application can be applied to a first node in a sharing cluster, each node in the sharing cluster is configured with a sharing file system, and the sharing file system is used for accessing sharing data corresponding to the sharing cluster by the node. For example, nodes 1-3 of fig. 2 constitute a shared cluster, and the method may be applied to any of the nodes of fig. 2.
As shown in fig. 6, the fault handling method provided by the embodiment of the present application may specifically include the following steps:
s601, when a shared file system of a first node fails, the first node disconnects communication with other nodes.
If the shared file system on the first node fails, an error instruction may be generated during the running process of the first node. Because of the interaction of the nodes in the shared cluster, the error instructions may be sent to other nodes in the shared cluster, so that the normal operation of the other nodes is affected. Thus, in the event of a failure of the shared file system of the first node, a message indicating disconnection of the communication may be sent to the other nodes to disconnect the communication of the first node with the other nodes.
It should be understood that when the shared file system fails, the first node timely disconnects communication with other nodes, so that on one hand, the first node can be prevented from generating wrong instructions to affect other nodes, on the other hand, the other nodes can sense that the first node is offline in time, and can preempt shared resources used by the first node to ensure operation of the service.
S602, configuring node states of other nodes configured on the first node as a first state.
The other nodes are nodes except the first node in the shared cluster, and the first state is used for indicating that the shared file system on the node stops running.
S603, under the condition that other nodes in the shared cluster are in the first state, the first node performs fault isolation on the shared file system.
Further, as described above, when the sharing function module of the shared file system detects a failure, it needs to negotiate with other nodes to release the shared resource occupied by itself, so that the first node can normally stop the operation of the shared file system to realize failure isolation. But the negotiation process cannot be performed due to the existence of a fault. Thus, the current failure handling mechanism is to reset the entire node to stop the operation of the shared file system.
Therefore, in the embodiment of the present application, when the shared file system of the first node fails, the first node may configure the node states of other nodes configured on the first node to be the first state, that is, the state in which the shared file system stops running. Thus, the first node considers the current moment to be the only node in the shared cluster, and therefore, the first node does not need to perform negotiation with other nodes when stopping the operation of the shared file system.
Further, when the first node confirms that other nodes in the shared cluster are in the first state, the first node may uninstall its own shared file system to implement fault isolation for the shared file system.
It should be appreciated that configuring the other nodes on the first node to be in the first state is herein described as simulating for the first node that the other nodes exit the shared cluster. Because the communication connection between the first node and other nodes is disconnected, the modification of the node state does not affect other nodes, namely, the other nodes do not exit the shared cluster in practice, and the method has the advantages that the first node can normally unload the shared file system, and meanwhile, the normal operation of the other nodes is not affected, so that the other nodes can be ensured to preempt the shared resources of the first node.
In the embodiment of the present application, as shown in fig. 7, in the step S602, the node states of other nodes configured on the first node are configured as the first state, which may be implemented as follows:
s6021, in the target configuration file, the node states of other nodes are configured to be the first state.
The target configuration file is a file for configuring operation parameters of the shared file system, wherein the operation parameters comprise node states of all nodes in the shared cluster.
Taking the shared file system as OCFS2 for example, the target configuration file is typically located in the node's configuration file directory. The target configuration file is mainly used for defining information of each node in the shared cluster, and the information comprises at least one of the following items: the address of the node, the identity of the node, the number of nodes, the node status of the node. That is, the target configuration file may implement functions of adding nodes or deleting nodes in the shared cluster, or modifying an address, an identifier, a node status, and the like of a certain node.
The shared file system on the first node operates depending on the configuration information in the target configuration file, or, part of parameters required by the operation of the shared file system are stored in the target configuration file. For example, the shared file system accesses a node based on addresses of other nodes in the target configuration file to read or write data from or to the node's disk. The size of the shared resource is determined for management based on the number of nodes in the target profile. And determining whether each node is online or not and is in the process of running based on the node state of the node in the target configuration file.
The first node may determine the location of the target configuration file, and modify the node states of other nodes except the first node in the target configuration file to be the first state (may also be described as the offline state or the offline state) so as to simulate that the other nodes exit the shared cluster on the first node.
Illustratively, the shared function module needs to rely on node information configured by the target configuration file to operate, and the shared function module is configured with location information of the target configuration file. The fault processing module requests the position information of the target configuration file from the sharing function module, or determines the position of the target configuration file according to the position information (such as the index of the configuration file catalog) of the target configuration file which is pre-configured by the fault processing module, further determines the target configuration file according to the address, and modifies the node states of other nodes in the target configuration file.
In the embodiment of the present application, the shared file system may operate in a kernel mode, and the first node further includes a process management program that operates in a user mode, where the process management program is used to manage processes in the node. As shown in fig. 8, S603 may also be implemented as follows:
And S6031, under the condition that other nodes in the shared cluster are in a first state, the first node operates the shared file system to send a first indication message to the process management program.
The first indication message is used for indicating to uninstall the shared file system.
S6032, responding to the first indication message, the first node runs the process management program to unload the shared file system so as to perform fault isolation on the shared file system.
For the above S6031 and S6032, the first node may run the shared file system in the kernel state and send a first indication message to the process management program in the user state to indicate to uninstall the shared file system when confirming that the other nodes are in the first state. Further, in response to the message, the first node uninstalls the shared file system through the process manager (the first node may execute an umount command, where the umount command is a command instructing the process manager to uninstall the shared file system), so as to enable the first node to exit the shared cluster, and enable fault isolation between the shared file system of the first node and other nodes.
The fault notification module in the kernel mode may send a first indication message to the fault isolation module in the user mode according to feedback from the fault handling module when it is confirmed that the other nodes are in the first state. Correspondingly, the fault isolation module unloads the shared file system to realize fault isolation.
Alternatively, the first indication message may be a netlink message. Wherein, netlink is a communication mechanism used between kernel mode and user mode. The netlink message may be sent through a kernel module or application and may be multicast or unicast to one or more recipients. In the embodiment of the application, the shared file management system in the kernel state is a sender of a netlink message, and the user-state process management program is a receiver of the netlink message. The embodiment of the application does not limit the specific content and the form of the netlink message, and can realize the instruction of unloading the shared file system.
It should be appreciated that the shared file system is in kernel mode and can directly access data in disk. The shared file system is therefore the kernel module with the highest access rights to the computing device. Unlike other user-mode programs (e.g., browsers, games, etc.), the shared file system cannot stop running by forced ending, because there may be a need for other user-mode programs' processes to rely on accessing data in disk with the shared file system. In order to enable the shared file system to be normally unloaded, the technical scheme provided by the embodiment of the application further comprises the following contents:
In one implementation manner, the unloading of the shared file system by the process management program in S6022 may be implemented as the following steps a-c:
and a, the first node determines a target process in the first node. The target process is a process which depends on the shared file system in the first node.
B, the first node runs a process management program to stop a target process;
And c, under the condition that the target process stops running, the first node runs the process management program to unload the shared file system.
The process manager may manage each process in the node, i.e., the process manager may determine the data accessed by each process based on the information of each process. Therefore, the process management program can determine that the target parameter points to the process sharing the data in the process managed by the process management program, namely the process relying on the shared file system. The target parameters here may be disk I/O, file descriptors, etc. Where disk I/O is an instruction sent by a processor to a disk when a process accesses the disk to indicate the location of the data to be accessed in the disk. The file descriptor is an index returned by the processor to the process when the process accesses a certain file, and is used for indicating the accessed file. After the target process is determined, the process manager stops the running of the target process. After the target processes are stopped, the process management program can normally execute the process of unloading the shared file system.
In the embodiment of the present application, when the shared file system of the first node fails, the failure processing method provided by the embodiment of the present application further includes: and configuring read-write state parameters of the shared file system in the first node to be in an unwritable state. Wherein the non-writable state is used to indicate that the first node is prohibited from writing data to the shared data.
It should be appreciated that the role of the shared file system is to support the reading and writing of shared data by the first node. When the shared file system fails, the first node may generate some error data to pollute the shared data in the process of writing the data, and other nodes may access the polluted shared data, so that the failure of the first node also affects other nodes in the shared cluster. Therefore, when the fault is detected, the first node configures the read-write state parameter of the shared file system to be in an unwritable state, and the first node is forbidden to write data through the shared file system, so that the shared file system and the shared data are prevented from being greatly influenced.
In some scenarios, after S603, if the failure of the shared file system is recovered, as shown in fig. 9, the first node may further perform the following:
S604, after the fault of the shared file system of the first node is recovered, the first node establishes communication connection with other nodes and releases the isolated shared file system.
S605, the node states of other nodes configured on the first node are configured to be second states.
The second state is used for indicating that the shared file system on the node operates normally.
It should be understood that after the failure recovery of the shared file system, the first node may establish a communication connection by sending a message for establishing a connection to other nodes, and de-isolate the shared file system, and restore the node states of the other nodes to the second state by configuring the target configuration file, so as to ensure that the node states of each node in the shared cluster are normal after the failure recovery, and normal interaction between the nodes is possible, thereby ensuring normal operation of the shared cluster.
In addition, for the problem of fault recovery of the shared file system, the fault recovery can be realized by restarting the file system, or restarting the file system after the operation and maintenance personnel participate in repairing (for example, modifying parameter configuration, etc.). In this way, the first node can be added into the shared cluster again after the fault is solved, so that the performance of the shared cluster processing service is ensured. Illustratively, the first node may mount the shared file system by the process manager (i.e., the first node executes a mount command, which is a command instructing the process manager to mount the shared file system) to effect the restart.
The above description is illustrative of the actions performed by the first node when the shared file system fails. The actions that the first node may perform when the shared file system of the first node is not down are described below.
The technical scheme provided by the embodiment of the application further comprises the following steps: upon determining that the communication connection between the first node and the second one of the other nodes is broken, the shared data is accessed based on the first shared resource. The first shared resource comprises a resource occupied by the second node currently accessing the shared data.
As mentioned above, the shared resource used by a node is common to all nodes in the shared cluster based on the characteristics of the shared file system. Therefore, before the notification is run, the shared file system of the node interacts with other nodes in the shared cluster to determine how the shared resources used by the node are allocated (the shared file system can be allocated according to the network condition, the memory use condition and the like of each node). Therefore, after the first node determines that the communication connection between the second node and the first node in the shared cluster is disconnected, the first node can preempt the shared resource occupied by the second node. It should be appreciated that by occupying the shared resources of the failed node, the impact of a node failure on the traffic of the shared cluster may be reduced.
For example, taking the shared resource as a lock resource, when the second node accesses the file a in the shared data, a protection lock is configured on the file a, so that other nodes cannot access the file a at present. If the second node is disconnected suddenly due to a fault and the protection lock for the file A is not released in time, the first node can acquire the protection lock and configure the protection lock to allow the second node to continue to access the file A, so that the preemption of the shared resource is realized. Or the first node can acquire the protection lock, delete the protection lock under the requirement that the first node does not continuously access the file A, so that other nodes can normally access the file A, and the situation that the protection lock is not released yet and other nodes cannot normally access data corresponding to the protection lock due to abnormal offline of the second node is avoided.
In some scenarios, when the shared file system is not down, as shown in fig. 10, the operation of the shared file system may be ended by the following steps.
S1001, receiving an instruction when the shared file system of the first node is not failed.
Wherein the instruction is to instruct offloading the shared file system on the first node.
S1002, responding to the instruction, and releasing the second shared resource by interacting with other nodes.
The second shared resource is a resource occupied by the first node to access the shared data.
S1003, unloading the shared file system on the first node under the condition that the first node releases the second shared resource.
For S1001-S1003 described above, the first node may receive an instruction to uninstall the shared file system when the shared file system of the first node is operating normally. The instruction may be an instruction configured between the operation and maintenance personnel on the first node, or may be an instruction that the first node generates autonomously from other devices (for example, user side devices of the operation and maintenance personnel) through a network, or may be an instruction that the first node generates autonomously (for example, stopping the operation of the shared file system in a preset time period configured in advance). The embodiment of the application does not limit the specific content of the instruction and the specific implementation mode of the first node receiving the instruction.
Further, the first node may interact with other nodes such that the other nodes may preempt the second shared resource. Other nodes can allocate the shared resources of the first node according to the function of the shared file system, so that the shared resources occupied by the first node are released. The first node can normally uninstall the shared file system, so that the first node can be disconnected from the shared cluster.
Fig. 11 is a schematic flow chart of fault handling according to an embodiment of the present application. As shown in fig. 11, 1, the shared file system detects a failure occurrence during operation, 2. 3. And (4) performing fault processing (namely, configuring other nodes to be offline in the first node in the step S602), and notifying a fault isolation module in a user state through a fault notification module. 5. The fault isolation module performs fault isolation.
According to the fault processing method provided by the embodiment of the application, when the shared file system of the first node fails, the node states of other nodes configured on the first node are configured to be the first state, and the first state is used for indicating that the shared file system on the node stops running. By disconnecting the first node from communication with other nodes and configuring other nodes on the first node to be offline (i.e. the shared file system stops running), the first node can confirm that the first node is the only node in the shared file system, so that the first node does not need to negotiate with other nodes when the shared file system fails, and can realize fault isolation of the shared file system without restarting the whole node. Therefore, the problem that other services are affected due to the fact that the whole node is reset when faults occur in the current scheme can be effectively solved, and the influence caused by faults of the shared file system is reduced.
Furthermore, when the shared file system fails, communication connection between the failed node and other nodes is timely disconnected, so that the influence of error data generated by the failed node on other nodes can be avoided, the other nodes can timely sense the node failure, the shared resource is preempted, the continuity of the service is ensured, and the method and the device can be applied to most scenes.
It can be seen that the foregoing description of the solution provided by the embodiments of the present application has been presented mainly from a method perspective. To achieve the above-mentioned functions, embodiments of the present application provide corresponding hardware structures and/or software modules that perform the respective functions. Those of skill in the art will readily appreciate that the various illustrative modules and algorithm steps described in connection with the embodiments disclosed herein may be implemented as hardware or combinations of hardware and computer software. Whether a function is implemented as hardware or computer software driven hardware depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.
In an exemplary embodiment, the embodiment of the application further provides a fault processing device. The fault handling means may be the aforementioned computing device or may be a processor in the computing device. The fault handling apparatus may comprise one or more functional modules for implementing the fault handling method of the above method embodiments.
For example, fig. 12 is a schematic diagram of a fault handling apparatus according to an embodiment of the present application. As shown in fig. 12, the fault handling apparatus includes: a configuration module 1201 and an isolation module 1202. The configuration module 1201 and the isolation module 1202 are interconnected.
The configuration module 1201 is configured to disconnect communication with other nodes when the shared file system of the first node fails.
The configuration module 1201 is further configured to configure node states of other nodes configured on the first node to be a first state; the other nodes are nodes except the first node in the shared cluster; the first state is used to indicate that the shared file system on the node is out of operation.
The isolation module 1202 is configured to perform fault isolation on the shared file system when all other nodes in the shared cluster are in the first state.
In a possible implementation manner, the configuration module 1201 is specifically configured to configure node states of other nodes to be a first state in the target configuration file; the target configuration file is a file for configuring operation parameters of the shared file system, wherein the operation parameters comprise node states of all nodes in the shared cluster.
In another possible implementation manner, the shared file system operates in a kernel mode, and the first node further includes a process management program operating in a user mode; the process management program is used for managing all processes in the node; the isolation module 1202 is specifically configured to operate the shared file system to send a first indication message to the process management program when all other nodes in the shared cluster are in a first state; the first indication message is used for indicating to uninstall the shared file system; in response to the first indication message, the shared file system is offloaded by the process manager.
In yet another possible implementation, the isolation module 1202 is specifically configured to determine a target process in the first node; the target process is a process which depends on a shared file system in the first node; ending the target process through the process management program; in the event that the target process has stopped running, the shared file system is uninstalled by the process manager.
In another possible implementation manner, the configuration module 1201 is further configured to configure a read-write status parameter of the shared file system in the first node to be in an unwritable status; the non-writable state is used to indicate that the first node is prohibited from writing data to the shared data.
In yet another possible implementation, the configuration module 1201 is further configured to establish a communication connection with another node; configuring node states of other nodes configured on the first node as a second state; the second state is used to indicate that the shared file system on the node is operating properly.
In another possible implementation manner, the apparatus further includes: the module 1203 is accessed. The access module 1203 is configured to access shared data based on the first shared resource when it is determined that the communication connection between the first node and the second node in the other nodes is disconnected; the first shared resource includes a resource occupied by the second node currently accessing the shared data.
In another possible implementation manner, the apparatus further includes: a receiving module 1204 and a transmitting module 1205; the receiving module 1204 is configured to receive an instruction when the shared file system of the first node is not failed; the instructions are for instructing to offload the shared file system on the first node; the sending module 1205 is configured to respond to the instruction by interacting with other nodes to release the second shared resource; the second shared resource is a resource occupied by the first node for accessing shared data; the uninstall module 1202 is configured to uninstall the shared file system on the first node if resources occupied by the first node currently accessing the shared data are released.
In yet another possible implementation, each node is configured with a disk, and the disks of different nodes are used to store different portions of each piece of data in the shared data.
In an exemplary embodiment, the present application further provides a computing device. Fig. 13 is a schematic diagram of a computing device according to an embodiment of the present application. As shown in fig. 13, the computing device may include: a processor 1301 and a memory 1302; memory 1302 stores instructions executable by processor 1301; processor 1301, when configured to execute instructions, causes the computing device to implement the method as described in the foregoing method embodiments.
The embodiment of the application also provides a computer readable storage medium. All or part of the flow in the above method embodiments may be implemented by computer instructions to instruct related hardware, and the program may be stored in the above computer readable storage medium, and the program may include the flow in the above method embodiments when executed. The computer readable storage medium may be any of the foregoing embodiments or memory. The computer-readable storage medium may be an external storage device of the recovery apparatus, for example, a plug-in hard disk, a smart card (SMART MEDIA CARD, SMC), a Secure Digital (SD) card, or a flash memory card (FLASH CARD) provided in the recovery apparatus. Further, the computer readable storage medium may further include both an internal storage unit and an external storage device of the recovery apparatus. The computer-readable storage medium is used for storing the computer program and other programs and data required by the recovery device. The above-described computer-readable storage medium may also be used to temporarily store data that has been output or is to be output.
Embodiments of the present application also provide a computer program product comprising a computer program which, when run on a computer, causes the computer to perform the fault handling method described in any one of the embodiments provided above.
Although the application is described herein in connection with various embodiments, other variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed application, from a study of the drawings, the disclosure, and the appended claims. In the claims, the term "comprising" (Comprising) does not exclude other elements or steps, and "a" or "an" does not exclude a plurality. A single processor or other unit may fulfill the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage.
Although the application has been described in connection with specific features and embodiments thereof, it will be apparent that various modifications and combinations can be made without departing from the spirit and scope of the application. Accordingly, the specification and drawings are merely exemplary illustrations of the present application as defined in the appended claims and are considered to cover any and all modifications, variations, combinations, or equivalents that fall within the scope of the application. It will be apparent to those skilled in the art that various modifications and variations can be made to the present application without departing from the spirit or scope of the application. Thus, it is intended that the present application also include such modifications and alterations insofar as they come within the scope of the appended claims or the equivalents thereof.
The present application is not limited to the above embodiments, and any changes or substitutions within the technical scope of the present application should be covered by the scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.
Claims (10)
1. The fault processing method is characterized by being applied to a first node in a sharing cluster, wherein each node in the sharing cluster is configured with a sharing file system, and the sharing file system is used for the node to access sharing data corresponding to the sharing cluster; the method comprises the following steps:
When the shared file system of the first node fails, the first node disconnects communication with other nodes;
Configuring node states of other nodes configured on the first node as a first state; the other nodes are nodes except the first node in the shared cluster; the first state is used for indicating that the shared file system on the node stops running;
In case the other nodes in the shared cluster are all in the first state,
And performing fault isolation on the shared file system.
2. The method of claim 1, wherein configuring the node state of the other nodes configured on the first node as a first state comprises:
In the target configuration file, configuring the node states of the other nodes into the first state; the target configuration file is a file configured for operating parameters of the shared file system, and the operating parameters include node states of all nodes in the shared cluster.
3. The method of any of claims 1-2, wherein the shared file system is running in kernel mode, and wherein the first node further comprises a process manager running in user mode; the process management program is used for managing all processes in the node;
And performing fault isolation on the shared file system under the condition that the other nodes in the shared cluster are in the first state, including:
operating the shared file system to send a first indication message to the process management program under the condition that all other nodes in the shared cluster are in the first state; the first indication message is used for indicating to uninstall the shared file system;
And responding to the first indication message, running the process management program to unload the shared file system so as to perform fault isolation on the shared file system.
4. The method of claim 3, wherein the running the process manager to uninstall the shared file system comprises:
Determining a target process in the first node; the target process is a process which depends on the shared file system in the first node;
stopping the target process by the process manager;
And running the process management program to unload the shared file system under the condition that the target process stops running.
5. The method of any of claims 1-4, wherein upon failure of the shared file system of the first node, the method further comprises:
Configuring read-write state parameters of a shared file system in the first node to be in an unwritable state; the non-writable state is to indicate that the first node is prohibited from writing data to the shared data.
6. The method according to any one of claims 1-5, further comprising:
after the fault of the shared file system of the first node is recovered, the first node establishes communication connection with other nodes;
Configuring node states of other nodes configured on the first node as a second state; the second state is used for indicating that the shared file system on the node operates normally.
7. The method according to any one of claims 1-6, further comprising:
Accessing the shared data based on a first shared resource upon determining that a communication connection between the first node and a second one of the other nodes is broken; the first shared resource includes a resource occupied by the second node accessing the shared data.
8. The method according to any one of claims 1-7, further comprising:
receiving an instruction when the shared file system of the first node is not failed; the instructions are for instructing to offload the shared file system on the first node;
Responsive to the instruction, releasing the second shared resource by interacting with the other node; the second shared resource is a resource occupied by the first node accessing the shared data;
Unloading the shared file system on the first node if the first node has released the two shared resources.
9. The method of any of claims 1-8, wherein disks are configured in the respective nodes, the disks of different nodes being used to store different portions of each piece of data in the shared data.
10. A computing device, the computing device comprising a processor and a memory; the processor is coupled with the memory; the memory is configured to store computer instructions that are loaded and executed by the processor to cause the computing device to implement the fault handling method of any of claims 1-9.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410132852.XA CN118170571A (en) | 2024-01-30 | 2024-01-30 | Fault processing method and computing device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202410132852.XA CN118170571A (en) | 2024-01-30 | 2024-01-30 | Fault processing method and computing device |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN118170571A true CN118170571A (en) | 2024-06-11 |
Family
ID=91353448
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202410132852.XA Pending CN118170571A (en) | 2024-01-30 | 2024-01-30 | Fault processing method and computing device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN118170571A (en) |
-
2024
- 2024-01-30 CN CN202410132852.XA patent/CN118170571A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9519795B2 (en) | Interconnect partition binding API, allocation and management of application-specific partitions | |
| JP4001877B2 (en) | Automatic recovery from hardware errors in the I / O fabric | |
| US9619270B2 (en) | Remote-direct-memory-access-based virtual machine live migration | |
| US10509686B2 (en) | Distributable computational units in a continuous computing fabric environment | |
| US10592434B2 (en) | Hypervisor-enforced self encrypting memory in computing fabric | |
| JP4576398B2 (en) | System for controlling I / O devices of a multi-partition computer system | |
| EP4083786A1 (en) | Cloud operating system management method and apparatus, server, management system, and medium | |
| CN101211289B (en) | Recovery action management system and method | |
| US8001322B2 (en) | Notifying software components using a shared physical storage medium | |
| US9354907B1 (en) | Optimized restore of virtual machine and virtual disk data | |
| US8006254B2 (en) | Bequeathing privilege to a dynamically loaded module | |
| US11163597B2 (en) | Persistent guest and software-defined storage in computing fabric | |
| CN107526653B (en) | Virtual machine management method and server | |
| EP3311272B1 (en) | A method of live migration | |
| US20120151095A1 (en) | Enforcing logical unit (lu) persistent reservations upon a shared virtual storage device | |
| CN106777394B (en) | Cluster file system | |
| JP2011527047A (en) | Method and system for execution of applications associated with distributed RAID | |
| US9804877B2 (en) | Reset of single root PCI manager and physical functions within a fabric | |
| JP2016197360A (en) | Information processing device, control program of information processing device, and method for controlling information processing device | |
| US9952941B2 (en) | Elastic virtual multipath resource access using sequestered partitions | |
| CN118170571A (en) | Fault processing method and computing device | |
| CN110825487B (en) | Management method for preventing split brain of virtual machine and main server | |
| CN114115703A (en) | Bare metal server online migration method and system | |
| US9143410B1 (en) | Techniques for monitoring guest domains configured with alternate I/O domains | |
| US10509662B1 (en) | Virtual devices in a reliable distributed computing system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |