Distributed job system control method, device, equipment, medium and program product

Abstract

The present disclosure provides a distributed job system control method, device, equipment, medium and program product, relates to the technical field of computer application, and particularly relates to the technical field of distributed job. The specific implementation scheme is: for a first container carrying a first process, in response to detecting that the first process is triggered to terminate based on the first container failing, determining a current failure type of the first container; if the current failure type is consistent with a target failure type, rebuilding the first container, and restarting the first process based on the rebuilt first container. The present disclosure can rebuild the container for the failure type that can successfully rebuild the container, and does not rebuild the container for the failure type that cannot successfully rebuild the container, so as to save the system operation cost and meet the job demand.

Description

Technical Field

[0001] This disclosure relates to the field of computer application technology, and more particularly to the field of distributed operation technology. Background Technology

[0002] A distributed job system is used to execute distributed jobs. It uses one or more containers to host the corresponding processes of the distributed jobs. Furthermore, the job result is obtained from the execution results of the corresponding processes. Summary of the Invention

[0003] This disclosure provides a distributed operating system control method, apparatus, equipment, medium, and program product.

[0004] According to one aspect of this disclosure, a distributed job system control method is provided, the method comprising:

[0005] For the first container carrying the first process, in response to detecting that the first process is terminated due to a failure of the first container, the current failure type of the first container is determined; if the current failure type is consistent with the target failure type, the first container is rebuilt, and the first process is restarted based on the rebuilt first container; wherein, the target failure type is a failure type applicable to the reconstruction of each container in the distributed job system to which the first container belongs.

[0006] According to another aspect of this disclosure, a distributed operating system control device is provided, the device comprising:

[0007] A detection module is used to detect, for a first container carrying a first process, that the first process is terminated due to a failure of the first container; a determination module is used to determine the current fault type of the first container in response to detecting that the first process is terminated due to a failure of the first container; and a processing module is used to rebuild the first container and restart the first process based on the rebuilt first container if the current fault type is consistent with the target fault type; wherein, the target fault type is a fault type applicable to the reconstruction of each container in the distributed operating system to which the first container belongs.

[0008] According to another aspect of this disclosure, an electronic device is provided, comprising:

[0009] At least one processor; and

[0010] A memory communicatively connected to the at least one processor; wherein,

[0011] The memory stores instructions that can be executed by the at least one processor, which, when executed, enable the at least one processor to perform the distributed operating system control method described above.

[0012] According to another aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause the computer to perform the distributed operating system control method described above.

[0013] According to another aspect of this disclosure, a computer program product is provided, including a computer program that is executed by a processor using the distributed operating system control method described above.

[0014] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0015] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein:

[0016] Figure 1 This is a flowchart illustrating the distributed operating system control method according to this disclosure;

[0017] Figure 2 This is a flowchart illustrating the process of determining whether the current fault type matches the target fault type according to this disclosure;

[0018] Figure 3 This is another flowchart illustrating the process of determining whether the current fault type matches the target fault type according to this disclosure;

[0019] Figure 4 This is a flowchart illustrating another distributed operating system control method according to this disclosure;

[0020] Figure 5 This is yet another flowchart illustrating a distributed operating system control method according to this disclosure;

[0021] Figure 6 It is a block diagram of a distributed operating system control device based on this disclosure.

[0022] Figure 7 This is a block diagram of an electronic device used to implement the distributed operating system control method of the embodiments of this disclosure. Detailed Implementation

[0023] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0024] The distributed job system control method provided in this disclosure can be applied to distributed job scenarios. For example, it can be applied to scenarios where artificial intelligence (AI) training is performed through distributed jobs.

[0025] Distributed job systems are used to execute distributed jobs, which use one or more containers to host the corresponding processes of the distributed jobs. In related technologies, during the execution of distributed jobs, the containers hosting the corresponding processes may fail. If a container fails, the processes hosted by the failed container will be terminated, and the corresponding job content cannot be completed. In related technologies, to obtain the execution result of a process forced to terminate due to container failure, the failed container is typically rebuilt, and the previously terminated process is restarted using the rebuilt container.

[0026] Typically, container failures fall into several categories, including those applicable to rebuilding containers within a distributed job system (e.g., system failures caused by the failed container itself) and those not applicable (e.g., code failures caused by program errors). For failure types applicable to container rebuilding, the distributed job system can rebuild the failed container; however, for failure types not applicable, the distributed job system cannot successfully rebuild the failed container.

[0027] In related technologies, there is no distinction made between container reconstruction scenarios based on the type of container failure. Regardless of the type of failure, the distributed job system will reconstruct the container. Therefore, if the failure type of the failed container is not applicable to the reconstruction of containers in the distributed job system, not only will the execution result of the process carried by the failed container be unavailable, but the overall job cycle of the distributed job will also be prolonged as the distributed job system continuously waits for the container reconstruction to complete. This method cannot meet the job requirements of a distributed job system.

[0028] This disclosure provides a distributed job system control method that, in the event of a container failure, determines the current failure type of the container and matches it with a target failure type. Further, if the current failure type matches the target failure type, the failed container is rebuilt. Since the target failure type is applicable to the rebuilding of all containers in the distributed job system, the distributed job system can successfully complete the container rebuilding process. Based on this, after the failed container is rebuilt, the previously terminated process is restarted, and the execution result is merged into the job result of the process, thus meeting job requirements.

[0029] For ease of description, the container that malfunctions will be referred to as the first container, and the process that is terminated due to the failure of the first container will be referred to as the first process. It is understood that the first process is the process carried by the first container.

[0030] Figure 1 This is a flowchart illustrating the distributed operating system control method disclosed herein, such as... Figure 1 As shown, it includes the following steps.

[0031] In step S101, in response to detecting that the first process was terminated due to a failure of the first container, the current failure type of the first container is determined.

[0032] In step S102a, if the current fault type is consistent with the target fault type, the first container is rebuilt, and the first process is restarted based on the rebuilt first container.

[0033] In this embodiment of the disclosure, the target fault type is a fault type applicable to the reconstruction of each container in the distributed job system. In other words, a container experiencing a fault of the target fault type indicates that the container can be successfully reconstructed. For example, the reconstruction result corresponding to the container when different fault types occur can be determined in advance (for example, the reconstruction result includes successful reconstruction and / or failed reconstruction). Further, based on the reconstruction result, the fault type applicable to the reconstruction of each container in the distributed job system is determined, and the target fault type is set accordingly.

[0034] For example, in a scenario where the current fault type matches the target fault type, it is determined that the first container can be successfully rebuilt. In this case, the first container is rebuilt, and the first process is restarted using the rebuilt first container. Based on this, the execution result of the first process can be obtained, and subsequently, the execution result of the first process is added to the job result of the job to which the first process belongs, which can meet the job requirements.

[0035] In step S102b, if the current fault type is inconsistent with the target fault type, the first container is not rebuilt.

[0036] For example, in scenarios where the current fault type does not match the target fault type, the first container is not rebuilt. In one implementation, for this situation where the first container is not rebuilt, the first process can be discarded, and the final job result of the job to which the first process belongs can be obtained, provided that the job flexibility of the job to which the first process belongs meets the requirements. In another implementation, the job result of the job to which the first process belongs can be determined as a job failure, or directly determined as a job failure, provided that the job flexibility of the job to which the first process belongs does not meet the requirements. Furthermore, depending on subsequent actual needs, the job can be either discarded or re-executed with the complete process. The job flexibility mentioned in the above embodiments is used to characterize the correctness of the job result of the job to which the first process belongs without supplementing the execution result of the first process.

[0037] The distributed job system control method provided in this disclosure, when the current fault type matches the target fault type, rebuilds the fault container and restarts the terminated process, thus obtaining the execution result corresponding to the previously terminated process and meeting job requirements. When the current fault type does not match the target fault type, container rebuilding can be avoided, reducing the possibility of an excessively long overall job cycle due to the inability to complete the restart and rebuild process, and thus meeting job requirements.

[0038] For example, corresponding flags can be set for the current fault type and the target fault type. Based on this, it can be achieved by determining whether the current fault type and the target fault type are consistent, according to the corresponding flags set for the current fault type and the target fault type.

[0039] For ease of description, the identifier set according to the target fault type will be referred to as the first identifier, and the identifier set according to the current fault type occurring in the container will be referred to as the second identifier.

[0040] Figure 2 This is a flowchart illustrating the process of determining whether the current fault type matches the target fault type, as per this disclosure. Figure 2 As shown, it includes the following steps.

[0041] For example, a first identifier representing the target fault type can be pre-set and stored in the distributed job system. Based on this, it can be determined that the current fault type matches the target fault type in the following way.

[0042] In step S201, a second identifier representing the current fault type is obtained.

[0043] In step S202, it is determined that the first identifier matches the second identifier.

[0044] For example, the first identifier and / or the second identifier can be set in a way that achieves type matching, such as by identifier code, instruction or judgment condition. This disclosure does not specifically limit the way the first identifier and / or the second identifier are set.

[0045] The distributed job system control method provided in this disclosure determines the fault type by identifier matching, which is convenient, quick, easy to implement, and can meet job requirements.

[0046] Typically, containers generate exit codes when a process terminates. These exit codes are numerical codes ranging from 0 to 255. For example, for process termination triggered upon process completion, the container generates an exit code of 0. As another example, for process termination due to a container failure, the container generates an exit code matching the type of failure (in the example of a container failure, the generated exit code would be any value between 1 and 255).

[0047] In one implementation, the exit code inherent to the container, generated upon a failure, can be used as a second identifier to characterize the current failure type of the container. Correspondingly, for failure types applicable to container reconstruction in a distributed job system, the exit code generated when such a failure occurs can be used as a first identifier. Based on this, the failure type of the container and whether container restart is possible can be identified using identifiers inherently generated by the distributed job system. This method requires no additional identifier settings and can meet user configuration requirements.

[0048] For ease of description, the following disclosure refers to the exit code that characterizes the fault type applicable to the reconstruction of each container in a distributed operating system as the first exit code, and the exit code that characterizes the current fault type of the first container as the second exit code.

[0049] Figure 3 This is another flowchart illustrating the process of determining whether the current fault type matches the target fault type according to this disclosure, such as... Figure 3 As shown, it includes the following steps.

[0050] In step S301, the second exit code generated by the first container based on the current fault type is obtained.

[0051] In this embodiment, the distributed operating system can identify the type of fault occurring in the container, and the container can generate an exit code with a corresponding value for the identified fault type. Identifying the fault type can employ conventional methods found in existing technologies. For example, if the distributed operating system has a first number of resource cards, and only a second number (in this example, the second number is less than the first number) of resource cards are currently detected, then it can be determined that the fault type currently occurring in the container is a system script card drop fault. Furthermore, similar to the above method, other fault types such as video memory faults, computing power faults, and code faults can also be detected, which will not be elaborated upon here.

[0052] In step S302, it is determined that the first exit code matches the second exit code.

[0053] For example, if the first exit code matches the second exit code, then the type of failure currently occurring in the container can be determined to be a type of failure applicable to the rebuilding of containers in a distributed job system. Based on this, subsequent steps such as container rebuilding and process restart can be performed.

[0054] Typically, distributed job systems cannot retain intermediate results during the job process. For distributed jobs that require intermediate results to calculate the final result, rebuilding the failed container and restarting the terminated process to obtain the process execution result cannot simply fill in the completed job result. In this case, even if the failed container is rebuilt and the terminated process is restarted to obtain the process execution result, the correct job result cannot be obtained.

[0055] In this embodiment of the disclosure, to ensure the correctness of the job results, container reconstruction information matching the distributed job can be configured in the distributed job system. This information is used to indicate the container to be rebuilt when a container fails. Furthermore, in the event of a container failure, container reconstruction information matching the job to which the failed container belongs can be obtained, and the container to be rebuilt matching the container reconstruction information can be determined and rebuilt using the obtained container reconstruction information.

[0056] In one implementation, if the container to be rebuilt is determined to include the first container through container reconstruction information, the first container that failed can be rebuilt. Subsequently, the process execution result can be obtained by restarting the process, and then the correct job result can be obtained by supplementing the process execution result.

[0057] Figure 4 This is a flowchart illustrating another distributed operating system control method according to this disclosure, such as... Figure 4 As shown, step S401 in this embodiment of the present disclosure is... Figure 1 The implementation process of step S101 is similar and will not be described in detail here.

[0058] In step S402, if the current fault type is consistent with the target fault type, container reconstruction information is obtained, and the container to be reconstructed is determined based on the container reconstruction information.

[0059] In step S403, if the container to be rebuilt includes the first container, then the first container is rebuilt, and the first process is restarted based on the rebuilt first container.

[0060] In another implementation, if it is determined through container reconstruction information that the containers to be reconstructed include not only the first container, all containers to be reconstructed that match the container reconstruction information can be restarted.

[0061] Figure 5 This is another flowchart illustrating a distributed operating system control method according to this disclosure, such as... Figure 5 As shown, steps S501 and S502 in this embodiment of the present disclosure are... Figure 4 The implementation processes of steps S401 and S402 are similar and will not be described in detail here.

[0062] In step S503, if the container to be rebuilt includes a first container and a second container, then the first container and the second container are rebuilt, and the first process is restarted based on the rebuilt first container, and the second process is restarted based on the rebuilt second container.

[0063] For example, the second container may include at least one of the following containers:

[0064] (1) Containers in the copy set to which the first container belongs.

[0065] (2) Containers in a replica set that are associated with the replica set to which the first container belongs.

[0066] (3) The container in the operation to which the first container belongs.

[0067] In this embodiment of the disclosure, the second container included in the container reconstruction information is used to jointly re-execute their respective processes with the first container, so that the correct intermediate results can be obtained during the job process, and thus the correct job result can be obtained. For example, for case (1), rebuilding the first container and the second container and restarting the corresponding processes is equivalent to re-executing the replica set, thereby obtaining the correct execution result matching the replica set. As another example, for case (3), rebuilding the first container and the second container and restarting the corresponding processes is equivalent to re-executing the job to which the first container belongs, thereby obtaining the correct job result matching the job. It should be noted that this disclosure can rebuild any number of any containers according to actual usage needs, and the above-mentioned cases (1) to (3) are only reference examples.

[0068] The distributed system control method provided in this disclosure can perform container reconstruction at different granularities for containers, meeting the container reconstruction needs for different scenarios.

[0069] For example, in addition to the container reconstruction information and the first identifier mentioned above, this disclosure can also configure, according to job requirements, the distributed job system with, for example, reconstruction strategy information, event information, and / or reconstruction time information. The reconstruction strategy information represents the on / off command for rebuilding containers. Users can "one-click disable" container reconstruction by setting the reconstruction strategy information. In this case, the distributed job system will not trigger container reconstruction for any type of container failure, thus meeting the user's personalized configuration needs for different job scenarios. Event information can be understood as information representing the corresponding status parameters of the distributed job system, such as machine status, number of available nodes, and their locations. Reconstruction time information represents the time limit for the "container reconstruction" event. For example, if the reconstruction time of a failed container exceeds the corresponding time, the reconstruction process can be terminated, and the job can be ended.

[0070] For example, in a distributed job scenario where a container fails, the current state of the container can be synchronized in real time using a state machine. For instance, when a container fails and the process terminates, the job's state can be changed from running to terminating. Furthermore, during container reconstruction, the container's state is changed from terminating to restarting, and after reconstruction is complete and the corresponding process is restarted, the container's state is changed from restarting back to running. The distributed job system control method provided in this disclosure, by displaying the corresponding container state through a state machine, allows the distributed job system or user to promptly perceive the container state and meet job requirements.

[0071] Based on the same concept, embodiments of this disclosure also provide a distributed operating system control device.

[0072] It is understood that the name apparatus provided in this disclosure, in order to achieve the above-described functions, includes hardware structures and / or software modules corresponding to the execution of each function. In conjunction with the modules and algorithm steps of the various examples disclosed in this disclosure, this disclosure can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of the technical solutions of this disclosure.

[0073] Figure 6 This is a block diagram of a distributed operating system control device based on this disclosure. (Refer to...) Figure 6 The device 600 includes a detection module 601, a determination module 602, and a processing module 603.

[0074] The detection module 601 is used to detect, for the first container carrying the first process, whether the first process has been terminated due to a failure in the first container. The determination module 602, in response to detecting that the first process has been terminated due to a failure in the first container, determines the current fault type of the first container. The processing module 603 is used to rebuild the first container if the current fault type matches the target fault type, and restart the first process based on the rebuilt first container. The target fault type is a fault type applicable to the reconstruction of all containers in the distributed operating system to which the first container belongs.

[0075] In one implementation, the target fault type is represented by a first identifier. The determining module 602 determines that the current fault type matches the target fault type by: acquiring a second identifier representing the current fault type; and determining that the first identifier matches the second identifier.

[0076] In one implementation, the first identifier includes a first exit code generated by the first container when the first container experiences a fault of the target fault type. The determining module 602 obtains a second identifier representing the current fault type by obtaining a second exit code generated by the first container based on the current fault type. The determining module 602 determines that the first identifier and the second identifier match by determining that the first exit code matches the second exit code.

[0077] In one embodiment, the determining module 602 is further configured to: obtain container reconstruction information before rebuilding the first container, the container reconstruction information being used to indicate the container to be rebuilt when the container fails, and determine, based on the container reconstruction information, that the container to be rebuilt includes the first container.

[0078] In one embodiment, the determining module 602 is further configured to: if it is determined based on container reconstruction information that the container to be rebuilt includes a second container, then reconstruct the second container and restart the second process carried by the second container based on the reconstructed second container. The second container is at least one of the following: a container in the replica set to which the first container belongs; a container in a replica set that is associated with the replica set to which the first container belongs; or a container in the job to which the first container belongs.

[0079] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0080] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0081] Figure 7 A schematic block diagram of an example electronic device 700 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0082] like Figure 7 As shown, device 700 includes a computing unit 701, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 702 or a computer program loaded from storage unit 708 into random access memory (RAM) 703. RAM 703 may also store various programs and data required for the operation of device 700. The computing unit 701, ROM 702, and RAM 703 are interconnected via bus 704. Input / output (I / O) interface 705 is also connected to bus 704.

[0083] Multiple components in device 700 are connected to I / O interface 705, including: input unit 706, such as keyboard, mouse, etc.; output unit 707, such as various types of monitors, speakers, etc.; storage unit 708, such as disk, optical disk, etc.; and communication unit 709, such as network card, modem, wireless transceiver, etc. Communication unit 709 allows device 700 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0084] The computing unit 701 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 701 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 701 performs the various methods and processes described above, such as distributed operating system control methods. For example, in some embodiments, the distributed operating system control method can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 708. In some embodiments, part or all of the computer program can be loaded and / or installed on device 700 via ROM 702 and / or communication unit 709. When the computer program is loaded into RAM 703 and executed by the computing unit 701, one or more steps of the distributed operating system control method described above can be performed. Alternatively, in other embodiments, the computing unit 701 can be configured to perform distributed operating system control methods by any other suitable means (e.g., by means of firmware).

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

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

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

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

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

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

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

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

Claims

1. A distributed job system control method, the method comprising: For the first container carrying the first process, in response to detecting that the first process is terminated due to a failure of the first container, the current failure type of the first container is determined. If the current fault type is consistent with the target fault type, then the first container is rebuilt, and the first process is restarted based on the rebuilt first container; if the current fault type is inconsistent with the target fault type, then the first container is not rebuilt. The target fault type is a fault type applicable to the reconstruction of each container in the distributed job system to which the first container belongs; Before rebuilding the first container, the method further includes: Obtain container reconstruction information, which is used to indicate the container to be rebuilt when the container fails, and determine that the container to be rebuilt includes the first container based on the container reconstruction information; If it is determined based on the container reconstruction information that the container to be reconstructed includes a second container, then the second container is reconstructed, and the second process carried by the second container is restarted based on the reconstructed second container. The second container is at least one of the following: a container in the replica set to which the first container belongs, a container in a replica set that is associated with the replica set to which the first container belongs, or a container in the job to which the first container belongs. The target fault type is predetermined in the following manner: When different types of failures occur in a container, the corresponding reconstruction results of the container are determined, and based on the reconstruction results, the failure types applicable to the reconstruction of each container in the distributed job system are determined, and the failure types applicable to the reconstruction of each container in the distributed job system are set as the target failure types.

2. The distributed job system control method according to claim 1, wherein, The target fault type is characterized by a first identifier; The current fault type is consistent with the target fault type, and is determined in the following way: Obtain a second identifier that represents the current fault type; The first identifier is determined to match the second identifier.

3. The method according to claim 2, wherein, The first identifier includes the first exit code generated by the first container when the first container experiences a failure of the target failure type; The step of obtaining the second identifier representing the current fault type includes: Obtain the second exit code generated by the first container based on the current fault type; Determining that the first identifier matches the second identifier includes: Determine that the first exit code matches the second exit code.

4. A distributed operating system control device, the device comprising: The detection module is used to detect, for the first container carrying the first process, whether the first process is terminated due to a failure of the first container. The determination module, in response to detecting that the first process is terminated due to a failure of the first container, determines the current failure type of the first container. The processing module is configured to rebuild the first container and restart the first process based on the rebuilt first container if the current fault type is consistent with the target fault type; if the current fault type is inconsistent with the target fault type, the first container is not rebuilt; wherein the target fault type is a fault type applicable to the reconstruction of each container in the distributed job system to which the first container belongs. The determining module is further configured to: Before rebuilding the first container, container rebuilding information is obtained, which is used to indicate the container to be rebuilt when the container fails, and the container to be rebuilt is determined to include the first container based on the container rebuilding information; If it is determined based on the container reconstruction information that the container to be reconstructed includes a second container, then the second container is reconstructed, and the second process carried by the second container is restarted based on the reconstructed second container. The second container is at least one of the following: a container in the replica set to which the first container belongs, a container in a replica set that is associated with the replica set to which the first container belongs, or a container in the job to which the first container belongs. The target fault type is predetermined in the following manner: When different types of failures occur in a container, the corresponding reconstruction results of the container are determined, and based on the reconstruction results, the failure types applicable to the reconstruction of each container in the distributed job system are determined, and the failure types applicable to the reconstruction of each container in the distributed job system are set as the target failure types.

5. The apparatus according to claim 4, wherein, The target fault type is characterized by a first identifier; The determining module determines that the current fault type is consistent with the target fault type using the following method: Obtain a second identifier that represents the current fault type; The first identifier is determined to match the second identifier.

6. The apparatus according to claim 5, wherein, The first identifier includes the first exit code generated by the first container when the first container experiences a failure of the target failure type; The determining module obtains the second identifier representing the current fault type in the following manner: Obtain the second exit code generated by the first container based on the current fault type; The determining module determines whether the first identifier matches the second identifier using the following method: Determine that the first exit code matches the second exit code.

7. An electronic device, comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-3.

8. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-3.

9. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-3.

Images