Fault analysis method, device, equipment and storage medium

Abstract

The present application is about a fault analysis method, device, equipment and storage medium, which relates to the field of computer technology and can realize efficient fault analysis of bare metal management process. The fault analysis method includes: obtaining the status information of the bare metal server during the execution of the target task; determining the target fault type of the bare metal server according to the status information; determining at least one analysis result corresponding to at least one enabling information according to at least one enabling information corresponding to the target fault type; summarizing at least one analysis result and generating a problem detail report.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a fault analysis method, device, equipment and storage medium. Background Art

[0002] With the continuous evolution of cloud computing technology, bare metal, with its exclusive resources, low loss, secure and controllable resource supply characteristics, can effectively make up for the shortcomings of virtualization technology at the virtual (hypervisor) layer, and has gradually become the choice of most users.

[0003] The bare metal management process involves bare metal node registration, driver information and certificate verification, more detailed attribute information, temporary file system loading, and instance incubation. Each step is divided into multiple subtasks for asynchronous execution, with complex business logic, involving a wide range of technology stacks, and difficult fault demarcation. When management fails, operation and maintenance personnel need to investigate the specific causes for many inspection items, which increases the technical difficulty and requires a lot of time and manpower costs. Therefore, how to achieve efficient fault analysis in the bare metal management process is a technical problem that needs to be solved urgently. Summary of the invention

[0004] The present application provides a fault analysis method, apparatus, device and storage medium for realizing efficient fault analysis of a bare metal pipe-integration process.

[0005] The technical solution of the embodiment of the present application is as follows:

[0006] According to a first aspect of an embodiment of the present application, a fault analysis method is provided, including: obtaining status information of a bare metal server during the execution of a target task; determining a target fault type of the bare metal server based on the status information; determining at least one analysis result corresponding to the at least one enabling information based on at least one enabling information corresponding to the target fault type; and summarizing the at least one analysis result to generate a problem details report.

[0007] Optionally, the target task includes: multiple subtasks corresponding to a preset execution order; a method for determining a target fault type of a bare metal server based on status information, comprising: determining an execution result of a first subtask based on the status information; the first subtask is any one of the multiple subtasks; when the execution result of the first subtask indicates an execution failure, determining the target fault type to be a fault corresponding to the first subtask; when the execution result of the first subtask indicates a successful execution, determining the execution result of the second subtask based on the status information, until the execution result of the second subtask indicates an execution failure, determining the target fault type to be a fault corresponding to the second subtask; the second subtask is the next subtask after the first subtask in the preset execution order among the multiple subtasks.

[0008] Optionally, the target task is a management task, and the first subtask is instance scheduling; the method for determining the execution result of the first subtask according to the status information includes: based on the identifier of the bare metal server, querying at least one resource component corresponding to the bare metal server, and obtaining at least one scheduling result corresponding one-to-one to the at least one resource component; determining the execution result of the instance scheduling based on the at least one scheduling result; the execution result of the instance scheduling is scheduling success or scheduling failure.

[0009] Optionally, when the scheduling is successful, the target fault type is a non-scheduling fault, and at least one enabling information includes: log information generated by the bare metal server executing the management task; a method for determining at least one analysis result corresponding one-to-one to at least one enabling information based on at least one enabling information corresponding to the target fault type includes: determining the analysis result corresponding to the log information based on the log information.

[0010] Optionally, the log information includes: instance operation log, bare metal node operation status, image uniform resource locator log, interface request log, pre-start execution environment node log and behavior control log; according to the log information, a method for determining the analysis result corresponding to the log information includes: querying the instance operation log to determine whether there is an error status code in the instance operation log; querying the target bare metal node matching the bare metal server to determine whether the operation status of the target bare metal node is in use; querying the image uniform resource locator log to determine whether the record status code of the image uniform resource locator log indicates a normal state; querying the interface request log to determine whether the record status code of the interface request log indicates a normal state; querying the pre-execution environment node log to determine whether there is a request record; querying the behavior control log to determine whether the server status code of the bare metal server starting in the pre-execution environment indicates a normal state.

[0011] Optionally, when the scheduling is successful, the target fault type is a non-scheduling fault, and at least one enabling information includes: configuration information of the bare metal server; a method for determining at least one analysis result corresponding one-to-one to at least one enabling information based on at least one enabling information corresponding to the target fault type includes: determining the analysis result corresponding to the configuration information based on the configuration information.

[0012] Optionally, the configuration information includes: a managed configuration management database, link layer discovery protocol information, node driver information, intelligent platform management interface information, and disk array information; a method for determining an analysis result corresponding to the configuration information based on the configuration information includes: comparing the managed configuration management database with the link layer discovery protocol information to determine whether there is mismatching information; querying the node driver information to determine whether there is missing information; comparing the managed configuration management database with the intelligent platform management interface information to determine whether there is mismatching information; querying the disk array information to determine whether there are keywords corresponding to the disk array template.

[0013] Optionally, when the scheduling is successful, the target fault type is a non-scheduling fault, and at least one enabling information includes: operating information of the bare metal server; a method for determining at least one analysis result corresponding one-to-one to at least one enabling information based on at least one enabling information corresponding to the target fault type includes: determining the analysis result corresponding to the operating information based on the operating information.

[0014] Optionally, after the bare metal server is deployed, the operation information includes: the management network and storage network of the bare metal server, the proxy port, user data, and hardware configuration information; based on the operation information, a method for determining an analysis result corresponding to the operation information includes: based on the connectivity of the management network and the storage network, confirming whether the network card configuration of the bare metal server is in a normal state; based on the proxy port, confirming whether the proxy service is running normally; based on the user data, checking whether the hardware configuration corresponding to the user data is in a normal state.

[0015] Optionally, during the bare metal server deployment process, the operation information includes: the operation status of the bare metal server; and a method for determining an analysis result corresponding to the operation information based on the operation information, including: calling an out-of-band management tool to check whether the operation status is in a normal state.

[0016] Optionally, when scheduling fails, the target fault type is a scheduling fault, and at least one enabling information includes: scheduling information of schedulable resources; a method for determining at least one analysis result corresponding one-to-one to at least one enabling information based on at least one enabling information corresponding to the target fault type includes: determining the analysis result corresponding to the instance scheduling based on the scheduling information and the resource requirement information of the target task.

[0017] Optionally, the scheduling information includes: the number of schedulable resources, the number of available task nodes, the number of successfully issued instances, and the scheduling status of schedulable resources or available task nodes; a method for determining an analysis result corresponding to instance scheduling based on the scheduling information and the resource requirement information of the target task includes: comparing the resource requirement quantity of the target task in the resource requirement information to see whether it is greater than the number of schedulable resources; comparing the task node requirement quantity of the target task in the resource requirement information to see whether it is greater than the number of available task nodes; comparing the instance requirement quantity of the target task in the resource requirement information to see whether it is greater than the number of successfully issued instances; and determining whether the scheduling status is in an inoperable state.

[0018] Optionally, the status information includes: a keyword corresponding to the fault event when a scheduling failure occurs; the keyword is any one of no available host, request execution timeout, request network failure, and request interface failure; a method for obtaining status information of a bare metal server during the execution of a target task, comprising: based on the error instance name generated by the fault event, querying the identifier of the target instance corresponding to the fault event; based on the identifier of the target instance, querying the instance component corresponding to the target instance to obtain the keyword.

[0019] According to a second aspect of an embodiment of the present application, a fault analysis device is provided, including: an acquisition unit, a status analysis unit and a generation unit; the acquisition unit is used to acquire status information of a bare metal server during the execution of a target task; the status analysis unit is used to determine a target fault type of the bare metal server based on the status information; the status analysis unit is also used to determine at least one analysis result corresponding to at least one enabling information based on at least one enabling information corresponding to the target fault type; the generation unit is used to summarize at least one analysis result and generate a problem details report.

[0020] Optionally, the target task includes: multiple subtasks corresponding to a preset execution order; a state analysis unit, specifically used to: determine the execution result of the first subtask according to the state information; the first subtask is any one of the multiple subtasks; when the execution result of the first subtask indicates an execution failure, determine the target fault type as the fault corresponding to the first subtask; when the execution result of the first subtask indicates a successful execution, determine the execution result of the second subtask according to the state information, until the execution result of the second subtask indicates an execution failure, determine the target fault type as the fault corresponding to the second subtask; the second subtask is the next subtask after the first subtask in the preset execution order among the multiple subtasks.

[0021] Optionally, the target task is a management task, and the first subtask is instance scheduling; the status analysis unit is specifically used to: based on the identifier of the bare metal server, query at least one resource component corresponding to the bare metal server, and obtain at least one scheduling result corresponding to the at least one resource component; determine the execution result of the instance scheduling based on the at least one scheduling result; the execution result of the instance scheduling is scheduling success or scheduling failure.

[0022] Optionally, when the scheduling is successful, the target fault type is a non-scheduling fault, and at least one enabling information includes: log information generated by the bare metal server executing the management task; a status analysis unit, specifically including: a log analysis unit; a log analysis unit, used to determine the analysis result corresponding to the log information based on the log information.

[0023] Optionally, the log information includes: instance operation log, bare metal node operation status, image uniform resource locator log, interface request log, pre-start execution environment node log and behavior control log; the log analysis unit is specifically used to: query the instance operation log to determine whether there is an error status code in the instance operation log; query the target bare metal node matching the bare metal server to determine whether the operation status of the target bare metal node is in use; query the image uniform resource locator log to determine whether the record status code of the image uniform resource locator log indicates a normal state; query the interface request log to determine whether the record status code of the interface request log indicates a normal state; query the pre-execution environment node log to determine whether there is a request record; query the behavior control log to determine whether the bare metal server starts the server status code in the pre-execution environment and indicates a normal state.

[0024] Optionally, when the scheduling is successful, the target fault type is a non-scheduling fault, and at least one enabling information includes: configuration information of the bare metal server; a status analysis unit, specifically including: a configuration analysis unit; a configuration analysis unit, used to determine an analysis result corresponding to the configuration information based on the configuration information.

[0025] Optionally, the configuration information includes: a managed configuration management database, link layer discovery protocol information, node driver information, intelligent platform management interface information, and disk array information; a configuration analysis unit is specifically used to: compare the managed configuration management database with the link layer discovery protocol information to determine whether there is any mismatching information; query the node driver information to determine whether there is any missing information; compare the managed configuration management database with the intelligent platform management interface information to determine whether there is any mismatching information; query the disk array information to determine whether there are keywords corresponding to the disk array template.

[0026] Optionally, when the scheduling is successful, the target fault type is a non-scheduling fault, and at least one enabling information includes: the operation information of the bare metal server; a status analysis unit, specifically including: an operation analysis unit; an operation analysis unit, used to determine the analysis result corresponding to the operation information based on the operation information.

[0027] Optionally, after the bare metal server is deployed, the operation information includes: the management network and storage network of the bare metal server, the proxy port, user data, and hardware configuration information; the operation analysis unit is specifically used to: based on the connectivity of the management network and the storage network, confirm whether the network card configuration of the bare metal server is in a normal state; based on the proxy port, confirm whether the proxy service is running normally; based on the user data, check whether the hardware configuration corresponding to the user data is in a normal state.

[0028] Optionally, during the bare metal server deployment process, the operation information includes: the operation status of the bare metal server; and an operation analysis unit, which is specifically used to: call an out-of-band management tool to check whether the operation status is normal.

[0029] Optionally, when scheduling fails, the target fault type is a scheduling fault, and at least one enabling information includes: scheduling information of schedulable resources; a state analysis unit, specifically including: a scheduling analysis unit; a scheduling analysis unit, used to determine the analysis result corresponding to the instance scheduling based on the scheduling information and the resource requirement information of the target task.

[0030] Optionally, the scheduling information includes: the number of schedulable resources, the number of available task nodes, the number of successfully issued instances, and the scheduling status of schedulable resources or available task nodes; the scheduling analysis unit is specifically used to: compare the resource requirement information to see whether the resource requirement quantity of the target task is greater than the number of schedulable resources; compare the resource requirement information to see whether the task node requirement quantity of the target task is greater than the number of available task nodes; compare the resource requirement information to see whether the instance requirement quantity of the target task is greater than the number of successfully issued instances; and determine whether the scheduling status is an inoperable state.

[0031] Optionally, the status information includes: a keyword corresponding to the fault event when a scheduling failure occurs; the keyword is any one of no available host, request execution timeout, request network failure, and request interface failure; an acquisition unit, specifically used to query the identifier of the target instance corresponding to the fault event based on the error instance name generated by the fault event; based on the identifier of the target instance, query the instance component corresponding to the target instance to obtain the keyword.

[0032] According to a third aspect of an embodiment of the present application, a fault analysis device is provided, which may include: a processor and a memory for storing processor executable instructions; wherein the processor is configured to execute instructions to implement any optional fault analysis method in the above-mentioned first aspect.

[0033] According to a fourth aspect of an embodiment of the present application, a computer-readable storage medium is provided, on which instructions are stored. When the instructions in the computer-readable storage medium are executed by a processor of a fault analysis device, the fault analysis device is enabled to perform any one of the optional fault analysis methods in the above-mentioned first aspect.

[0034] The technical solution provided by this application brings at least the following beneficial effects:

[0035] Based on any of the above aspects, the fault analysis method in the present application can classify the target fault types, decompose the business logic implemented by bare metal management, and configure the corresponding analysis path for each fault type to achieve accurate analysis of the specific fault causes, effectively solving the problem of difficulty in fault analysis caused by processing logic, system configuration, and human operation problems in the cloud environment. BRIEF DESCRIPTION OF THE DRAWINGS

[0036] The drawings herein are incorporated into the specification and constitute a part of the specification, illustrate embodiments consistent with the present application, and together with the specification are used to explain the principles of the present application, and do not constitute an improper limitation on the present application.

[0037] Figure 1 A schematic diagram of a fault analysis system provided in an embodiment of the present application;

[0038] Figure 2 A schematic diagram of a fault analysis method provided in an embodiment of the present application is shown. Figure 1 ;

[0039] Figure 3 A schematic diagram of a fault analysis method provided in an embodiment of the present application is shown. Figure 2 ;

[0040] Figure 4 The structure of a fault analysis device provided in an embodiment of the present application is shown in FIG. Figure 1 ;

[0041] Figure 5 The structure of a fault analysis device provided in an embodiment of the present application is shown in FIG. Figure 2 . DETAILED DESCRIPTION

[0042] In order to enable ordinary persons in the art to better understand the technical solution of the present application, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the accompanying drawings.

[0043] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. On the contrary, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the attached claims.

[0044] It should also be understood that the term “comprising” indicates the presence of described features, integers, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements and / or components.

[0045] In order to facilitate the understanding of the present application, the relevant elements involved in the present application are now described.

[0046] Openstack: An open source cloud computing management platform project, which is a combination of a series of software open source projects, providing scalable and elastic cloud computing services for private and public clouds.

[0047] Ironic: A project within the OpenStack architecture that focuses on bare metal management and system push. It is an infrastructure as a service (IaaS) cloud service based on bare metal services.

[0048] Nova-compute: The entry point for managing and configuring virtual machines in the Openstack architecture, responsible for the lifecycle management of virtual machine instances.

[0049] Link layer discovery protocol (LLDP): defines a standard method for Ethernet network devices, such as switches, routers, and wireless LAN access points, to announce their presence to other nodes in the network and save discovery information about neighboring devices.

[0050] Ironic-conductor: Receives bare metal instance management requests and performs operations such as creation, update, and deletion.

[0051] Glance: Provides services for discovering, registering, and retrieving virtual machine images within the Openstack architecture, and provides a RESTful application programming interface (API) for querying virtual machine (VM) image metadata.

[0052] Neutron-server: Responsible for accepting external requests within the Openstack architecture, including command-line interface (CLI) API, representational state transfer (REST) ​​API, etc., and scheduling the corresponding backend plug-ins for processing.

[0053] Preboot execution environment (PXE): Based on the server-client (Client / Server) network model, it supports remote hosts to download images from remote servers through the network, boot and install various operating systems such as Windows and Linux.

[0054] As described in the background technology, among the open source technologies related to the cloud platform, the more mature solution for the full life cycle management of bare metal instances is the Ironic service of the Openstack project, which involves bare metal node registration, verification of driver information and certificates, more detailed attribute information, temporary file system loading, and instance incubation. Each step is divided into multiple subtasks for asynchronous execution, the business logic is complex, involving a variety of technology stacks, and fault demarcation is difficult. In the troubleshooting process, due to the characteristics of the bare metal server itself, the problem reproduction requires the use of an out-of-band system for targeted analysis, and the restart and reconstruction process takes longer than a virtual machine. The management process has specific requirements for the initial configuration of the server at the start, such as disk array (redundant arrays of independent disks, RAID) configuration, network card order, etc. In the early stage of engineering implementation, human connection errors and system configuration errors that may occur in the bare metal shelf integration may also cause instance management failure.

[0055] When management fails, the operation and maintenance personnel need to investigate the specific reasons for many inspection items, which increases the technical difficulty and consumes a lot of time and manpower. Therefore, how to achieve efficient fault analysis in the bare metal management process is a technical problem that needs to be solved urgently.

[0056] Based on this, the fault analysis method in this application can classify the target fault types, decompose the business logic implemented by bare metal management, and configure the corresponding analysis path for each fault type to achieve accurate analysis of the specific fault causes, effectively solving the problem of difficulty in fault analysis caused by processing logic, system configuration, and human operation problems in the cloud environment.

[0057] The following is an exemplary description of the fault analysis method provided in the embodiment of the present application in conjunction with the accompanying drawings:

[0058] Figure 1 A schematic diagram of a fault analysis system provided in an embodiment of the present application is shown in FIG. Figure 1 As shown, the fault analysis system may include: a fault analysis device 101, multiple task nodes 102, and a bare metal server 103.

[0059] In some embodiments, the fault analysis device 101 may include a front-end device and a back-end device. The front-end device may include physical devices such as smart phones, desktop computers, tablet computers, laptops, digital assistants, smart wearable devices, etc., and may also include software running in the physical device, such as application programs (APPs), web pages, applets, etc. Specifically, the front-end device may send an execution request for the fault analysis task of the bare metal server 103 to the back-end device.

[0060] The backend device may include an independently operated server, a distributed server, or a server cluster consisting of multiple servers. The backend device may include a network communication unit, a processor, a memory, etc. Specifically, the backend device may respond to the execution request for the fault analysis task of the bare metal server 103 sent by the frontend device, and perform fault analysis on the bare metal server 103 to execute the target task.

[0061] In some embodiments, multiple task nodes 102 may provide multiple application components that provide service support for the bare metal server 103. Specifically, multiple task nodes 102 may execute the above target tasks, and each may generate log information during the execution of the above target tasks.

[0062] In some embodiments, the bare metal server 103 may include an independently operated server, a distributed server, or a server cluster consisting of multiple servers. The bare metal server 103 may include a network communication unit, a processor, a memory, etc. Specifically, the bare metal server 103 may receive a control instruction corresponding to a target task and execute the control instruction.

[0063] It should be noted that the above-mentioned fault analysis device 101, multiple task nodes 102, and bare metal server 103 can all be called electronic devices.

[0064] The fault analysis method provided in the embodiment of the present application can be applied to the aforementioned Figure 1 The fault analysis device 101 in the application scenario shown. Figure 2 As shown, the fault analysis method may include:

[0065] S201. A fault analysis device obtains status information of a bare metal server during execution of a target task.

[0066] Optionally, the target task can be a bare metal server management task, which is all the states that the bare metal server instance goes through from being purchased by the tenant to being returned by the tenant, including but not limited to the request, scheduling, task generation, network creation, PXE preparation, instance incubation, etc. during the instance creation process.

[0067] Optionally, the target task may include multiple subtasks corresponding to a preset execution order. For example, when the target task is a management task, the subtask may be instance scheduling.

[0068] In one practicable manner, each subtask may be assigned a respective process identifier, which is used as identification information to distinguish different subtasks during the execution of the target task.

[0069] Optionally, the status information may include: the execution result of the target task, and a keyword corresponding to a fault event when a scheduling failure occurs. The keyword is any one of no available host, request execution timeout, request network failure, and request interface failure.

[0070] In one achievable manner, the method for a fault analysis device to obtain a keyword may include: the fault analysis device first queries the identifier of a target instance corresponding to the fault event based on the name of an error instance generated by the fault event, and then queries the instance component corresponding to the target instance based on the identifier of the target instance to obtain the keyword.

[0071] Specifically, the management task fails to execute the deployment request of the physical server by calling the Openstack nova interface. The instance enters the inactive state. At this time, the fault analysis device can query the universally unique identifier (uuid) of the corresponding instance component in the Openstack architecture through the name of the error instance. Then, the fault analysis device can obtain the fault event keyword of the management failure from the nova database based on the uuid.

[0072] S202: The fault analysis device determines a target fault type of the bare metal server according to the status information.

[0073] Optionally, the target failure type can correspond to any subtask, indicating that the bare metal server fails during the execution of the above subtask.

[0074] In one practicable manner, the fault analysis device can determine whether a fault occurs during the execution of each subtask in sequence according to a preset execution order. When a subtask in the front of the preset execution order is found to have a fault, the fault analysis of other subsequent subtasks is stopped to reduce the scope of fault investigation and improve the efficiency of fault analysis. The specific method includes: S11-S13.

[0075] S11. The fault analysis device determines the execution result of the first subtask according to the status information.

[0076] The first subtask is any subtask among the multiple subtasks.

[0077] S12: When the execution result of the first subtask indicates execution failure, the fault analysis device determines that the target fault type is a fault corresponding to the first subtask.

[0078] S13. When the execution result of the first subtask indicates successful execution, the fault analysis device determines the execution result of the second subtask according to the status information, until the execution result of the second subtask indicates failure, and determines the target fault type as the fault corresponding to the second subtask.

[0079] The second subtask is the next subtask after the first subtask in the preset execution order among the multiple subtasks.

[0080] Specifically, when the target fault type is a scheduling fault or a non-scheduling fault, the fault analysis device needs to determine the execution result of the instance scheduling. Unlike other components, Nova can implement the addition, deletion, modification and query operations on virtual machines, and can also implement bare metal incubation, power on and off, and deletion operations through the Ironic interface. The nova database only records the bare metal state transfer keywords, and the specific execution process error details cannot be fully reflected. Further confirmation of the execution result of the instance scheduling is required.

[0081] In one practicable manner, the method for the fault analysis device to determine the execution result of the instance scheduling may include: S21 - S22.

[0082] S21. The fault analysis device queries at least one resource component corresponding to the bare metal server based on the identifier of the bare metal server, and obtains at least one scheduling result corresponding to the at least one resource component.

[0083] First, in the Openstack architecture, after receiving the instance management request initiated by the user, Openstack will add a request-id to the response information to track the service request, scheduling, and response details in the relevant component logs. The fault analysis device can query the request identifier (request-id) corresponding to the creation action through the nova instance action list based on the bare metal server uuid.

[0084] Then, the fault analysis device may search for the first scheduling result through the log information of the scheduler (nova-scheduler) according to the request-id.

[0085] In one achievable manner, when nova-scheduler is deployed in a multi-active deployment scheme, the fault analysis device needs to traverse the scheduling logs of all task nodes.

[0086] In another possible implementation, when nova-scheduler is deployed in a master-slave mode, the fault analysis device only needs to query the master node scheduling log.

[0087] Specifically, when the query result of the log information is that 0 data (hosts) is returned after the filter (filters), it means that there are no available host resources. Otherwise, it means that there are available resources and the uuid of the target node that is successfully scheduled can be queried.

[0088] In Openstack, a method for determining a task node corresponding to a target task may include: defining multiple types of filters to achieve instance scheduling results that meet multiple conditions, performing weight calculations on task nodes that pass through the filters, and finally selecting a task node with the largest weight value to deploy the instance.

[0089] The fault analysis device can also query the nova database instance information table according to the bare metal server uuid to obtain the second scheduling result.

[0090] Specifically, if the corresponding hypersivisor information is not empty, it means that the scheduling is successful, and the corresponding value is the uuid of the target node.

[0091] The fault analysis device can also query the Ironic database node table according to the UUID of the bare metal node to obtain the third scheduling result.

[0092] Specifically, the Ironic database node table uses a state machine to represent the states of each task node used to distinguish different executable operations, and is divided into two stages: inspection (Inspect) and application (Provision) according to the management sequence. The inspection stage includes states such as bare metal registration, information verified, manageable, and automatic entry of hardware information. The provision stage includes states such as available, deploying, waiting for callback, and running. If the node status of the task node is in any state after the available state in the provision stage, it means that the task node has been successfully scheduled.

[0093] S22. The fault analysis device determines an execution result of the instance scheduling according to at least one scheduling result.

[0094] In combination with the description in S21, the fault analysis device may determine the fault analysis device based on the first scheduling result, the second scheduling result and the third scheduling result. The execution result of the instance scheduling is scheduling success or scheduling failure.

[0095] Specifically, when the first scheduling result is the same as the second scheduling result, that is, the uuid of the target node is consistent, and the third scheduling result indicates that the node state of the target node is any state after the available state in the Provision stage, it indicates that the scheduling is successful. When the scheduling is successful, it indicates that the target fault type is a non-scheduling fault. On the contrary, when the scheduling fails, it indicates that the target fault type is a scheduling fault.

[0096] S203: The fault analysis device determines, according to the at least one enabling information corresponding to the target fault type, at least one analysis result corresponding to the at least one enabling information.

[0097] Specifically, when the fault type is different, the corresponding enabling information is different. In order to improve the efficiency and accuracy of fault analysis, the fault analysis device can directly search for at least one enabling information corresponding to the target fault type to achieve accurate analysis of the fault. For example, when the target fault type is a scheduling fault, the fault analysis device can perform fault analysis on the enabling information involved in the scheduling stage.

[0098] Optionally, when scheduling is successful, the target fault type is a non-scheduling fault, and the at least one enabling information includes: log information generated by the bare metal server when executing the management task, configuration information of the bare metal server, scheduling information of schedulable resources, etc. When scheduling fails, the target fault type is a scheduling fault, and the at least one enabling information includes scheduling information of a schedulable instance.

[0099] S204: The fault analysis device summarizes at least one analysis result and generates a problem detail report.

[0100] Among them, the problem report details can provide a basis for the subsequent repair work of the operation and maintenance personnel.

[0101] The technical solution provided by the above embodiments brings at least the following beneficial effects: It can be seen from S201-S204 that the present application can classify the target fault types, decompose the business logic implemented by bare metal management, and configure the corresponding analysis path for each fault type to achieve accurate analysis of the specific fault cause, thereby effectively solving the problem of difficulty in fault analysis caused by processing logic, system configuration and human operation problems in a cloud environment.

[0102] In an optional embodiment, Figure 2 Based on the method embodiment shown, when scheduling fails, combining Figure 2 ,like Figure 3 As shown, in S203, the method in which the fault analysis device determines at least one analysis result corresponding to at least one enabling information according to at least one enabling information corresponding to the target fault type includes:

[0103] S301. The fault analysis device determines an analysis result corresponding to the instance scheduling according to the scheduling information of the schedulable resources and the resource requirement information of the target task.

[0104] Optionally, the scheduling information of the schedulable resources may include: the number of schedulable resources such as processors (central processing units, CPU), memory, etc., and also include the number of available task nodes, the number of successfully issued instances, and the scheduling status of the schedulable resources or available task nodes. The scheduling status includes: schedulable, scheduled, and inoperable.

[0105] In the first case, if the resource requirement information required by the target task exceeds the available physical machine configuration, the scheduling fails. Therefore, the fault analysis device can query the flavor table of the nova database to compare the resource requirement information and whether the resource requirement quantity of the target task is greater than the schedulable resource quantity.

[0106] In the second case, since the task nodes registered in Ironic correspond to the actual servers in a one-to-one relationship, if there are N physical machines in the environment and N bare metal instances are issued, the N+1th creation request corresponding to the target task will inevitably fail. Therefore, the fault analysis device can query the number of available task nodes in the Ironic database and compare the number of task nodes required for the target task in the resource requirement information to see if it is greater than the number of available task nodes.

[0107] In the third case, since Nova's resource statistics do not care about the instance status of the issued physical machines, even physical machines in the error (ERROR) state occupy the number of available servers. For example, the resource pool contains N physical machines, and N bare metal instances are issued, one of which fails and N-1 succeeds. When the N+1th instance is issued, the scheduling task must fail. Therefore, the fault analysis device can query the number of successfully issued instances in the Ironic database, and compare the instance requirement number of the target task in the resource requirement information to see if it is greater than the number of successfully issued instances.

[0108] In the fourth case, the available task node cannot be successfully scheduled because it is in a special inoperable state, such as maintenance mode, or is in the inspect phase and has not successfully registered into the resource pool. Therefore, the fault analysis device can query the Ironic database to determine whether the scheduling state of the schedulable resources or available task nodes is in an inoperable state.

[0109] The technical solution provided by the above embodiment brings at least the following beneficial effects: As can be seen from S301, when the target fault type is a scheduling fault, the fault analysis device can determine the analysis result corresponding to the instance scheduling based on the scheduling information corresponding to the instance scheduling and the resource requirement information of the target task. Compared with troubleshooting all information, the present application can more specifically analyze the fault cause corresponding to the target fault type, which can effectively improve the accuracy and efficiency of fault analysis.

[0110] In an optional embodiment, Figure 3 Based on the method embodiment shown, when the scheduling is successful, as Figure 3 As shown, in S203, the method in which the fault analysis device determines at least one analysis result corresponding to at least one enabling information according to at least one enabling information corresponding to the target fault type includes:

[0111] S302. The fault analysis device determines an analysis result corresponding to the log information based on the log information generated by the bare metal server when executing the management task.

[0112] Specifically, when the instance is successfully scheduled to the target bare metal server, the management task still fails. The fault analysis device can search for log information in sequence according to the Ironic management processing logic. Since Openstack uses the RESTful API method to implement interface calls between components, it is possible to determine whether the call chain process is normal based on the standard status code fed back, including: S31-S36.

[0113] S31. The fault analysis device queries the instance operation log to determine whether there is an error status code in the instance operation log.

[0114] The fault analysis device can query the running log of the instance to which the bare metal server belongs based on its UUID, that is, all the information of the incubated instance in the nova-compute log, including image and network information, to determine whether there is an error status code.

[0115] S32. The fault analysis device queries the target bare metal node that matches the bare metal server to determine whether the operating status of the target bare metal node is in use.

[0116] Since Ironic uses hashing to implement the association between conductors and bare metal nodes, the matching target bare metal nodes need to be set to the use state. The fault analysis device can query the inventory record to determine whether the matching target bare metal nodes are set to the use state to determine the analysis results.

[0117] S33: The fault analysis device queries the mirror uniform resource locator log to determine whether the record status code of the mirror uniform resource locator log indicates a normal state.

[0118] The fault analysis device can query the corresponding ironic-conductor request image (glance) uniform resource locator (URL) log record status code according to the bare metal server uuid to see whether it is normal.

[0119] S34. The fault analysis device queries the interface request log to determine whether the record status code of the interface request log indicates a normal state.

[0120] The fault analysis device can query the neutron-server node network interface request log record status code based on the bare metal server uuid to see whether it is normal.

[0121] S35. The fault analysis device queries the pre-execution environment node log to determine whether there is a request record.

[0122] The fault analysis device can query the ironic-pre-execution environment (pxe) node log to see if there is a trivial file transfer protocol (TFTP) bootloader request record with a matching time.

[0123] S36. The fault analysis device queries the behavior control log to determine whether the server status code of the bare metal server indicates a normal state.

[0124] The fault analysis device can query the behavior control log, that is, the ironic-conductor log, based on the bare metal server uuid to determine whether the server startup status code is normal during the process of the pxe process starting the memory file system remote copy image and writing to the bare metal server hard disk.

[0125] The technical solution provided by the above embodiment brings at least the following beneficial effects: As can be seen from S302, when scheduling fails, the fault analysis device can determine the analysis result corresponding to the log information based on the log information generated by the bare metal server when executing the management task. Compared with troubleshooting all information, this application can more specifically analyze the fault cause corresponding to the target fault type, which can effectively improve the accuracy and efficiency of fault analysis.

[0126] In an optional embodiment, Figure 3 Based on the method embodiment shown, when the scheduling is successful, as Figure 3 As shown, in S203, the method in which the fault analysis device determines at least one analysis result corresponding to at least one enabling information according to at least one enabling information corresponding to the target fault type includes:

[0127] S303. The fault analysis device determines an analysis result corresponding to the configuration information according to the configuration information of the bare metal server.

[0128] Specifically, before the bare metal instance is available, its configuration data needs to be entered into the database in order to complete subsequent operations. Therefore, the fault analysis device can query the bare metal configuration information according to the bare metal server uuid. The specific query operation may include: S41-S44.

[0129] S41. The fault analysis device compares the managed configuration management database with the local link connection information to determine whether there is any mismatching information.

[0130] First, the fault analysis device can load the bare metal management configuration management database (CMDB).

[0131] CMDB is the information generated by the implementation personnel during the stage of putting the integrated server on the shelf, including the motherboard (chassis) where the bare metal server is located, node name, intelligent platform management interface (IPMI) address, IPMI user, IPMI password, management and business network card addresses, gateway, network card route, network card binding member order and media access control (MAC) address, network card binding mode, available domain, and server status information.

[0132] Then, the fault analysis device can query the local link connection table information of the Ironic database according to the bare metal server uuid, compare the network port information entered into the CMDB side and the database, check whether there is any missing network card binding member information, inconsistent interface names of the upstream switch, and whether the upstream switch ports are cross-connected incorrectly.

[0133] The local link connection table information is the link layer discovery protocol (LLDP) information. The bare metal management process deploys the LLDP service, requests the basic information of the bare metal network port from the switch through the link layer discovery protocol, and reports it to the Ironic entry database.

[0134] S42. The fault analysis device queries the node drive information to determine whether there is any missing information.

[0135] The fault analysis device can query the Ironic database node table based on the bare metal server uuid to obtain node driver information and determine whether it is missing.

[0136] Node driver information is not the server hardware running interface program, but the kernel, root file system, and disk image that the bare metal management process relies on. Node driver information is automatically entered during the inspect phase. If it is missing, the management fails.

[0137] S43. The fault analysis device compares the managed configuration management database with the intelligent platform management interface information to determine whether there is any mismatching information.

[0138] The fault analysis device can query the IPMI information of the Ironic database node table according to the bare metal server uuid, and compare it with the user information recorded on the CMDB side to check whether the information is consistent.

[0139] S44: The fault analysis device queries the disk array information to determine whether there is a keyword corresponding to the disk array template.

[0140] The fault analysis device can query the Ironic database node table RAID information based on the bare metal server uuid to see whether the RAID keyword exists.

[0141] During the bare metal deployment phase, you need to complete RAID configuration for the system disk and specify a RAID configuration keyword when creating a bare metal instance. This keyword corresponds to a bare metal RAID template. If the keyword is not configured, no valid template will match the bare metal creation.

[0142] The technical solution provided by the above embodiment brings at least the following beneficial effects: As can be seen from S303, when the scheduling is successful, the fault analysis device can determine the analysis result corresponding to the configuration information based on the configuration information of the bare metal server. Compared with troubleshooting all information, this application can more specifically analyze the fault cause corresponding to the target fault type, which can effectively improve the accuracy and efficiency of fault analysis.

[0143] In an optional embodiment, Figure 3 Based on the method embodiment shown, when the scheduling is successful, as Figure 3 As shown, in S203, the method in which the fault analysis device determines at least one analysis result corresponding to at least one enabling information according to at least one enabling information corresponding to the target fault type includes:

[0144] S304. The fault analysis device determines an analysis result corresponding to the operation information according to the operation information of the bare metal server.

[0145] Specifically, bare metal server incubation helps users quickly deploy and manage bare metal servers by providing users with services such as physical equipment, network connection, hardware maintenance, and technical support. Fault analysis equipment can obtain bare metal server operation information based on bare metal server uuid, and locate server installation failures through operation information, mainly including two situations:

[0146] The first is that after the bare metal server incubation is completed, that is, after the bare metal server deployment is completed, the fault analysis device can confirm whether the bare metal server's network card configuration is in a normal state based on the connectivity of the management network and the storage network. The fault analysis device can confirm whether the agent service is running normally through the agent port. Optionally, the agent service can include a storage agent service. The fault analysis device can also log in to the system through the user data (user-data) configuration of the initial user name and password, and check whether the hardware configuration corresponding to the user data, such as the network card binding configuration, RAID configuration, etc., is normal and in a normal state.

[0147] The second is that the bare metal server incubation is not completed, that is, during the bare metal server deployment process, Ironic automatically performs a task rollback, and the bare metal server is cleaned and shut down. The fault analysis device can call the out-of-band management tool to pass in the IPMI user information to check whether the running status of the started bare metal server, such as power status, temperature, fan speed, etc., is in normal state.

[0148] The technical solution provided by the above embodiment brings at least the following beneficial effects: As can be seen from S304, when the scheduling is successful, the fault analysis device can determine the analysis result corresponding to the operation information based on the operation information of the bare metal server. Compared with troubleshooting all information, this application can more specifically analyze the fault cause corresponding to the target fault type, which can effectively improve the accuracy and efficiency of fault analysis.

[0149] It is understandable that, in actual implementation, the fault analysis device of the embodiment of the present application may include one or more hardware structures and / or software modules for implementing the aforementioned corresponding fault analysis method, and these execution hardware structures and / or software modules may constitute an electronic device. It should be easily appreciated by those skilled in the art that, in combination with the algorithm steps of each example described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present application.

[0150] Based on this understanding, an embodiment of the present application also provides a fault analysis device. Figure 4 The structure of the fault analysis device provided in the embodiment of the present application is shown in FIG. Figure 1 .like Figure 4 As shown, the fault analysis device includes: an acquisition unit 01, a state analysis unit 02 and a generation unit 03.

[0151] The acquisition unit 01 is used to acquire the status information of the bare metal server during the execution of the target task.

[0152] The state analysis unit 02 is used to determine the target fault type of the bare metal server according to the state information.

[0153] The state analysis unit 02 is further configured to determine, according to the at least one enabling information corresponding to the target fault type, at least one analysis result corresponding one-to-one to the at least one enabling information.

[0154] The generating unit 03 is used to summarize at least one analysis result and generate a problem detail report.

[0155] Optionally, the target task includes: multiple subtasks corresponding to a preset execution order; a state analysis unit 02, specifically used to: determine the execution result of the first subtask according to the state information; the first subtask is any one of the multiple subtasks; when the execution result of the first subtask indicates an execution failure, determine the target fault type as the fault corresponding to the first subtask; when the execution result of the first subtask indicates a successful execution, determine the execution result of the second subtask according to the state information, until the execution result of the second subtask indicates an execution failure, determine the target fault type as the fault corresponding to the second subtask; the second subtask is the next subtask after the first subtask in the preset execution order among the multiple subtasks.

[0156] Optionally, the target task is a management task, and the first subtask is instance scheduling; the status analysis unit 02 is specifically used to: based on the identifier of the bare metal server, query at least one resource component corresponding to the bare metal server, and obtain at least one scheduling result corresponding to the at least one resource component; determine the execution result of the instance scheduling based on the at least one scheduling result; the execution result of the instance scheduling is scheduling success or scheduling failure.

[0157] Optionally, when the scheduling is successful, the target fault type is a non-scheduling fault, and at least one enabling information includes: log information generated by the bare metal server executing the management task; the status analysis unit 02, specifically including: a log analysis unit 021.

[0158] The log analysis unit 021 is used to determine the analysis result corresponding to the log information according to the log information.

[0159] Optionally, the log information includes: instance operation log, bare metal node operation status, image uniform resource locator log, interface request log, pre-start execution environment node log and behavior control log; the log analysis unit 021 is specifically used to: query the instance operation log to determine whether there is an error status code in the instance operation log; query the target bare metal node matching the bare metal server to determine whether the operation status of the target bare metal node is in use; query the image uniform resource locator log to determine whether the record status code of the image uniform resource locator log indicates a normal state; query the interface request log to determine whether the record status code of the interface request log indicates a normal state; query the pre-execution environment node log to determine whether there is a request record; query the behavior control log to determine whether the bare metal server starts the server status code in the pre-execution environment to indicate a normal state.

[0160] Optionally, when scheduling is successful, the target fault type is a non-scheduling fault, and at least one enabling information includes: configuration information of the bare metal server; the status analysis unit 02, specifically including: a configuration analysis unit 022.

[0161] The configuration analysis unit 022 is used to determine the analysis result corresponding to the configuration information according to the configuration information.

[0162] Optionally, the configuration information includes: a managed configuration management database, link layer discovery protocol information, node driver information, intelligent platform management interface information, and disk array information; the configuration analysis unit 022 is specifically used to: compare the managed configuration management database with the link layer discovery protocol information to determine whether there is any mismatching information; query the node driver information to determine whether there is any missing information; compare the managed configuration management database with the intelligent platform management interface information to determine whether there is any mismatching information; query the disk array information to determine whether there is a keyword corresponding to the disk array template.

[0163] Optionally, when scheduling is successful, the target fault type is a non-scheduling fault, and at least one enabling information includes: operation information of the bare metal server; status analysis unit 02, specifically including: operation analysis unit 023.

[0164] The operation analysis unit 023 is used to determine the analysis result corresponding to the operation information according to the operation information.

[0165] Optionally, after the bare metal server is deployed, the operation information includes: the management network and storage network of the bare metal server, the proxy port, user data, and hardware configuration information; the operation analysis unit 023 is specifically used to: based on the connectivity of the management network and the storage network, confirm whether the network card configuration of the bare metal server is in a normal state; based on the proxy port, confirm whether the proxy service is running normally; based on the user data, check whether the hardware configuration corresponding to the user data is in a normal state.

[0166] Optionally, during the bare metal server deployment process, the operation information includes: the operation status of the bare metal server; the operation analysis unit 023 is specifically used to: call the out-of-band management tool to check whether the operation status is normal.

[0167] Optionally, when scheduling fails, the target fault type is a scheduling fault, and at least one enabling information includes: scheduling information of schedulable resources; the state analysis unit 02 specifically includes: a scheduling analysis unit 024.

[0168] The scheduling analysis unit 024 is used to determine the analysis result corresponding to the instance scheduling according to the scheduling information and the resource requirement information of the target task.

[0169] Optionally, the scheduling information includes: the number of schedulable resources, the number of available task nodes, the number of successfully issued instances, and the scheduling status of schedulable resources or available task nodes; the scheduling analysis unit 024 is specifically used to: compare the resource requirement information to see whether the resource requirement number of the target task is greater than the number of schedulable resources; compare the resource requirement information to see whether the task node requirement number of the target task is greater than the number of available task nodes; compare the resource requirement information to see whether the instance requirement number of the target task is greater than the number of successfully issued instances; and determine whether the scheduling status is an inoperable state.

[0170] Optionally, the status information includes: a keyword corresponding to the fault event when a scheduling failure occurs; the keyword is any one of no available host, request execution timeout, request network failure, and request interface failure; an acquisition unit 01, which is specifically used to query the identifier of the target instance corresponding to the fault event based on the error instance name generated by the fault event; based on the identifier of the target instance, query the instance component corresponding to the target instance to obtain the keyword.

[0171] As described above, the embodiment of the present application can divide the functional modules of the first terminal according to the above method example. Among them, the above integrated modules can be implemented in the form of hardware or in the form of software functional modules. In addition, it should be noted that the division of modules in the embodiment of the present application is schematic, which is only a logical function division, and there may be other division methods in actual implementation. For example, each functional module can be divided according to each function, or two or more functions can be integrated in one processing module.

[0172] Regarding the fault analysis device in the above embodiment, the specific manner in which each module performs operations and the beneficial effects possessed have been described in detail in the above method embodiment and will not be repeated here.

[0173] The embodiment of the present application also provides a fault analysis device. Figure 5 The structure of the fault analysis device provided in the embodiment of the present application is shown in FIG. Figure 2 The fault analysis device may include at least one processor 501 , a communication bus 502 , a memory 503 and at least one communication interface 504 .

[0174] The processor 501 may be a central processing unit (CPU), a microprocessing unit, an ASIC, or one or more integrated circuits for controlling the execution of the program of the present application.

[0175] Communication bus 502 may include a pathway for transmitting information between the above-mentioned components.

[0176] The communication interface 504 uses any transceiver-like device for communicating with other devices or communication networks, such as electronic devices, Ethernet, radio access networks (RAN), wireless local area networks (WLAN), etc.

[0177] The memory 503 may be a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, a random access memory (RAM) or other types of dynamic storage devices that can store information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical disc, laser disc, optical disc, digital versatile disc, Blu-ray disc, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to carry or store the desired program code in the form of an instruction or data structure and can be accessed by a computer, but is not limited thereto. The memory may be independent and connected to the processing unit via a bus. The memory may also be integrated with the processing unit.

[0178] The memory 503 is used to store the application code for executing the solution of the present application, and the execution is controlled by the processor 501. The processor 501 is used to execute the application code stored in the memory 503, so as to realize the functions in the method of the present application.

[0179] In a specific implementation, as an embodiment, the processor 501 may include one or more CPUs, such as Figure 5 Processor 0 and processor 1 in.

[0180] In a specific implementation, as an embodiment, the fault analysis device may include multiple processors, such as Figure 5 501 and processor 505 in the embodiment of the present invention. Each of these processors may be a single-CPU processor or a multi-CPU processor. The processor herein may refer to one or more devices, circuits, and / or processing cores for processing data (e.g., computer program instructions).

[0181] In a specific implementation, as an embodiment, the fault analysis device may further include an input device 506 and an output device 507. The input device 506 communicates with the output device 507 and may receive user input in a variety of ways. For example, the input device 506 may be a mouse, a keyboard, a touch screen device, or a sensor device. The output device 507 communicates with the processor 501 and may display information in a variety of ways. For example, the output device 507 may be a liquid crystal display (LCD), a light emitting diode (LED) display device, etc.

[0182] Those skilled in the art will understand that Figure 5 The structure shown in the figure does not constitute a limitation on the fault analysis device, and may include more or less components than those shown in the figure, or combine certain components, or adopt a different component arrangement.

[0183] The present application also provides a computer-readable storage medium including instructions, wherein the computer-readable storage medium stores instructions, and when the instructions in the computer-readable storage medium are executed by the processor of the fault analysis device, the fault analysis device can perform the fault analysis method provided in the above-mentioned embodiment. For example, the computer-readable storage medium may be a memory 503 including instructions, and the above instructions may be executed by the processor 501 of the fault analysis device to complete the above method.

[0184] Optionally, the computer-readable storage medium may be a non-transitory computer-readable storage medium, for example, the non-transitory computer-readable storage medium may be a ROM, RAM, CD-ROM, magnetic tape, floppy disk, optical data storage device, etc.

[0185] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the invention disclosed herein. The present application is intended to cover any modification, use or adaptation of the present application, which follows the general principles of the present application and includes common knowledge or customary techniques in the art that are not disclosed in the present application. The specification and examples are intended to be exemplary only, and the true scope and spirit of the present application are indicated by the following claims.

[0186] It should be understood that the present application is not limited to the precise structures that have been described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof. The scope of the present application is limited only by the appended claims.

Claims

1. A fault analysis method, characterized in that: include: Obtain the status information of the bare metal server during the execution of the target task; The target task includes: a plurality of subtasks corresponding to a preset execution order; Determine, according to the state information, an execution result of a first subtask; the first subtask is any one of the multiple subtasks; When the execution result of the first subtask indicates execution failure, determining the target fault type to be a fault corresponding to the first subtask; When the execution result of the first subtask indicates successful execution, determining the execution result of the second subtask according to the state information, until the execution result of the second subtask indicates failure, determining the target fault type to be a fault corresponding to the second subtask; the second subtask is the next subtask after the first subtask in the plurality of subtasks according to the preset execution order; Determining, according to at least one enabling information corresponding to the target fault type, at least one analysis result corresponding one-to-one to the at least one enabling information; Summarizing the at least one analysis result to generate a problem details report; The target task is a management task, and the first subtask is instance scheduling; and determining the execution result of the first subtask according to the state information includes: Based on the identifier of the bare metal server, query at least one resource component corresponding to the bare metal server to obtain at least one scheduling result corresponding to the at least one resource component; Determine, according to the at least one scheduling result, an execution result of the instance scheduling; the execution result of the instance scheduling is scheduling success or scheduling failure; When scheduling is successful, the target fault type is a non-scheduling fault, and the at least one enabling information includes: log information generated by the bare metal server executing the management task; and determining, according to the at least one enabling information corresponding to the target fault type, at least one analysis result corresponding to the at least one enabling information includes: Determine, according to the log information, an analysis result corresponding to the log information; When scheduling is successful, the target fault type is a non-scheduling fault, and the at least one enabling information includes: configuration information of the bare metal server; The determining, according to the at least one enabling information corresponding to the target fault type, at least one analysis result corresponding to the at least one enabling information comprises: According to the configuration information, an analysis result corresponding to the configuration information is determined.

2. The method according to claim 1, characterized in that: The log information includes: instance operation log, bare metal node operation status, image uniform resource locator log, interface request log, pre-start execution environment node log and behavior control log; the analysis result corresponding to the log information is determined according to the log information, including: Query the instance operation log to determine whether there is an error status code in the instance operation log; Querying a target bare metal node that matches the bare metal server, and determining whether the running status of the target bare metal node is in use; querying the mirror uniform resource locator log to determine whether a record status code of the mirror uniform resource locator log indicates a normal state; Query the interface request log to determine whether the record status code of the interface request log indicates a normal state; Query the pre-startup execution environment node log to determine whether there is a request record; The behavior control log is queried to determine whether a server status code when the bare metal server is started in the pre-execution environment indicates a normal state.

3. The method according to claim 2, characterized in that The configuration information includes: a management configuration management database, link layer discovery protocol information, node driver information, intelligent platform management interface information, and disk array information; and determining, based on the configuration information, an analysis result corresponding to the configuration information, includes: Comparing the management configuration management database with the link layer discovery protocol information to determine whether there is mismatching information; Query the node driver information to determine whether any information is missing; Compare the management configuration management database with the intelligent platform management interface information to determine whether there is any mismatching information; The disk array information is queried to determine whether there is a keyword corresponding to the disk array template.

4. The method according to claim 1, characterized in that: When scheduling is successful, the target fault type is a non-scheduling fault, and the at least one enabling information includes: operation information of the bare metal server; and determining, according to the at least one enabling information corresponding to the target fault type, at least one analysis result corresponding to the at least one enabling information includes: According to the operation information, an analysis result corresponding to the operation information is determined.

5. The method according to claim 4, characterized in that After the bare metal server is deployed, the operation information includes: a management network and a storage network, a proxy port, user data, and hardware configuration information of the bare metal server; and determining, based on the operation information, an analysis result corresponding to the operation information, includes: Based on the connectivity of the management network and the storage network, confirm whether the network card configuration of the bare metal server is in a normal state; Based on the proxy port, confirm whether the proxy service is running normally; Based on the user data, it is checked whether the hardware configuration corresponding to the user data is in a normal state.

6. The method according to claim 4, characterized in that In the bare metal server deployment process, the operation information includes: the operation status of the bare metal server; and determining, according to the operation information, an analysis result corresponding to the operation information includes: Call an out-of-band management tool to check whether the running status is normal.

7. The method according to claim 1, characterized in that When scheduling fails, the target fault type is a scheduling fault, and the at least one enabling information includes: scheduling information of schedulable resources; and determining, according to the at least one enabling information corresponding to the target fault type, at least one analysis result corresponding to the at least one enabling information includes: An analysis result corresponding to the instance scheduling is determined according to the scheduling information and the resource requirement information of the target task.

8. The method according to claim 7, characterized in that The scheduling information includes: the number of schedulable resources, the number of available task nodes, the number of successfully issued instances, and the scheduling status of schedulable resources or available task nodes; the determining, based on the scheduling information and the resource requirement information of the target task, an analysis result corresponding to the instance scheduling includes: Comparing the resource requirement information, whether the resource requirement quantity of the target task is greater than the schedulable resource quantity; Comparing the resource requirement information, whether the required number of task nodes of the target task is greater than the number of available task nodes; Comparing the resource requirement information, whether the required number of instances of the target task is greater than the number of instances that have been successfully issued; Determine whether the scheduling state is an inoperable state.

9. The method according to claim 1, characterized in that: The state information includes: a keyword corresponding to a fault event when a scheduling failure occurs; the keyword is any one of no available host, request execution timeout, request network failure, and request interface failure; The obtaining of status information of the bare metal server during the execution of the target task includes: Based on the error instance name generated by the fault event, query the identifier of the target instance corresponding to the fault event; Based on the identifier of the target instance, the instance component corresponding to the target instance is queried to obtain the keyword.

10. A fault analysis device, characterized in that: include: an acquisition unit, a state analysis unit, and a generation unit; The acquisition unit is used to acquire the status information of the bare metal server during the execution of the target task; The target task includes: a plurality of subtasks corresponding to a preset execution order; The state analysis unit is specifically used for: Determine, according to the state information, an execution result of a first subtask; the first subtask is any one of the multiple subtasks; When the execution result of the first subtask indicates execution failure, determining the target fault type to be a fault corresponding to the first subtask; When the execution result of the first subtask indicates successful execution, determining the execution result of the second subtask according to the state information, until the execution result of the second subtask indicates failure, determining the target fault type to be a fault corresponding to the second subtask; the second subtask is the next subtask after the first subtask in the plurality of subtasks according to the preset execution order; The state analysis unit is further configured to determine, according to at least one enabling information corresponding to the target fault type, at least one analysis result corresponding to the at least one enabling information; The generating unit is used to summarize the at least one analysis result and generate a problem detail report; The target task is a management task, and the first subtask is instance scheduling; The state analysis unit is further specifically configured to: based on the identifier of the bare metal server, query at least one resource component corresponding to the bare metal server, and obtain at least one scheduling result corresponding to the at least one resource component in a one-to-one manner; Determine, according to the at least one scheduling result, an execution result of the instance scheduling; the execution result of the instance scheduling is scheduling success or scheduling failure; When scheduling is successful, the target fault type is a non-scheduling fault, and the at least one enabling information includes: log information generated by the bare metal server executing the management task; determining an analysis result corresponding to the log information according to the log information; When scheduling is successful, the target fault type is a non-scheduling fault, and the at least one enabling information includes: configuration information of the bare metal server; and determining an analysis result corresponding to the configuration information according to the configuration information.

11. An electronic device, characterized in that: The electronic device comprises: processor; a memory for storing instructions executable by the processor; The processor is configured to execute the instructions to implement the fault analysis method according to any one of claims 1 to 9.

12. A computer-readable storage medium having instructions stored thereon, characterized in that: When the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to execute the fault analysis method according to any one of claims 1 to 9.

Images