A computing power resource startup failure confirmation method, system, device and medium

Abstract

The application discloses a computing resource startup failure confirmation method and system, equipment and medium, relates to the technical field of computing resource exception processing, obtains the power-on review result of the computing resource, and the power-on review result is used to indicate whether the computing resource has completed power-on; first state information, second state information and third state information associated with the scheduling task of the computing resource are obtained; according to the power-on review result, the first state information, the second state information and the third state information, whether the scheduling task meets the preset startup failure condition is judged; in response to the scheduling task meeting the preset startup failure condition, a computing resource startup failure confirmation result corresponding to the scheduling task is generated; wherein the first state information is used to represent the state of the computing resource at the client host running level, the second state information is used to represent the state of the computing resource at the starting process stage, and the third state information is used to represent the event state of the computing resource at the hardware management level. High accuracy.

Description

Technical Field

[0001] This application relates to the field of computing resource status confirmation and anomaly handling technology, and more specifically, to a method, system, device and medium for confirming computing resource startup failure. Background Technology

[0002] In computing resource scheduling scenarios such as cloud computing and bare metal environments, the scheduling platform starts the physical host by issuing a power-on command to the host of the computing resource. It then waits for the host to complete the complete boot process, including BIOS self-test, hardware initialization, preboot execution environment (PXE) boot, operating system loading, and monitoring agent reconnection. However, for the scheduling platform, whether a power-on command has been executed does not equate to the computing resource being truly powered on and available.

[0003] This is because there is uncertainty between the execution result of the power-on command and the actual power-on status of the computing resources. For example, power controller failure or management network jitter may cause the command to not actually take effect. Moreover, after the scheduling process is completed, it relies heavily on manual inspection of multiple system logs. All these factors can lead to the inability to correctly identify whether the computing resources have failed to power on.

[0004] In conclusion, accurately identifying the failure of computing resources to boot up is a problem that urgently needs to be solved by those skilled in the art. Summary of the Invention

[0005] The purpose of this application is to provide a method for confirming computing resource startup failures, which can, to some extent, solve the technical problem of how to accurately identify computing resource startup failures. This application also provides a computing resource startup failure confirmation system, an electronic device, and a computer-readable storage medium.

[0006] To achieve the above objectives, this application provides the following technical solution: A method for confirming computing resource startup failure includes: Obtain the power-on verification result of the computing resources, wherein the power-on verification result is used to indicate whether the computing resources have been powered on; Obtain the first, second, and third state information associated with the scheduling task of computing resources; Based on the power-on verification result, the first status information, the second status information, and the third status information, determine whether the scheduled task meets the preset power-on failure conditions; In response to the scheduling task meeting the preset startup failure condition, a startup failure confirmation result for the computing power resource corresponding to the scheduling task is generated; The first state information is used to characterize the state of computing resources at the client host runtime level, the second state information is used to characterize the state of computing resources during the startup process, and the third state information is used to characterize the event state of computing resources at the hardware management level.

[0007] Preferably, determining whether the scheduled task meets the preset power-on failure conditions based on the power-on verification result, the first status information, the second status information, and the third status information includes: If the third state information contains a repeat power-on anomaly event identifier, then the scheduled task is determined to meet the preset power-on failure condition. And / or, in response to the power-on verification result indicating successful power-on, and the first status information lacks evidence of host operation, and the second status information lacks evidence of startup completion, the scheduled task is determined to meet the preset power-on failure condition.

[0008] Preferably, in response to the power-on verification result indicating successful power-on, and the first status information lacking evidence of host operation, and the second status information lacking evidence of startup completion, the scheduled task is determined to meet the preset power-on failure conditions, including: If the power-on verification result indicates that the power-on was successful, and the host power-on time information and the most recent running report time information in the first status information are both empty, and the diskless boot success time information in the second status information is empty, then it is determined that the scheduling task meets the preset power-on failure condition.

[0009] Preferably, before obtaining the first state information, second state information, and third state information associated with the scheduling task of computing resources, the method further includes: The duration of the scheduled task from its creation time to its end time is recorded. In response to the completion of the scheduling task and the duration not being less than a preset duration threshold, the steps of obtaining the first state information, second state information and third state information associated with the scheduling task of acquiring computing resources are executed.

[0010] Preferably, the power-on verification results of the computing resources are obtained, including: When the scheduling task enters the execution phase, the power-on verification task is registered. Based on the power-on verification task, the current power status of computing resources is queried according to a preset period. In response to the current power state being found to be in a power-on state within a preset number of times threshold, a power-on success event is generated, and the power-on success event is used as the power-on verification result; If the number of consecutive queries reaches the preset threshold and the power-on status is not found, a power-on failure event is generated, and the power-on failure event is used as the power-on verification result.

[0011] Preferred options also include: Each time the power-on verification task is executed, the current lifecycle state of the scheduled task is verified; If the current lifecycle state of the scheduled task is no longer running, then the power-on verification task is cancelled.

[0012] Preferably, after generating the computing resource startup failure confirmation result corresponding to the scheduling task, the method further includes: Based on the confirmation result of the computing power resource startup failure, a startup failure exception event is constructed; The boot failure exception event is sent to the upstream event receiver.

[0013] A system for confirming computing resource startup failure includes: The verification result acquisition module is used to acquire the power-on verification result of the computing resources, and the power-on verification result is used to indicate whether the computing resources have been powered on. The information acquisition module is used to acquire the first state information, second state information and third state information associated with the scheduling task of computing resources; The judgment module is used to determine whether the scheduled task meets the preset power-on failure conditions based on the power-on verification result, the first status information, the second status information and the third status information. The result generation module is used to generate a computing resource startup failure confirmation result corresponding to the scheduling task if the scheduling task meets the preset startup failure condition. The first state information is used to characterize the state of computing resources at the client host runtime level, the second state information is used to characterize the state of computing resources during the startup process, and the third state information is used to characterize the event state of computing resources at the hardware management level.

[0014] An electronic device, comprising: Memory, used to store computer programs; A processor, used to implement the steps of the computing resource startup failure confirmation method as described above when executing the computer program.

[0015] A computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of any of the above-described computing resource startup failure confirmation methods.

[0016] This application provides a method for confirming the power-on failure of computing resources. The method involves obtaining the power-on verification result of the computing resources, which indicates whether the computing resources have been powered on; obtaining first, second, and third state information associated with the scheduling task of the computing resources; determining whether the scheduling task meets preset power-on failure conditions based on the power-on verification result, the first state information, the second state information, and the third state information; and generating a power-on failure confirmation result for the computing resources corresponding to the scheduling task if the scheduling task meets the preset power-on failure conditions. The first state information characterizes the state of the computing resources at the client host runtime level, the second state information characterizes the state of the computing resources during the startup process, and the third state information characterizes the event state of the computing resources at the hardware management level. In this application, the first state information comes from the in-band data plane, the second state information comes from the startup phase data plane, and the third state information comes from the out-of-band management data plane. This is equivalent to obtaining different dimensions of evidence for successful boot from the in-band data plane, the startup phase data plane, and the out-of-band management data plane, respectively. The failure modes of these three sources are independent of each other. By fusing these three heterogeneous data sources for cross-validation, the shortcomings of incomplete judgments due to the lack of a single data source are overcome, thus improving the accuracy and reliability of confirming boot failures of computing resources. The computing resource boot failure confirmation system, electronic device, and computer-readable storage medium provided in this application also solve the corresponding technical problems. Attached Figure Description

[0017] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of this application. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0018] Figure 1 A flowchart illustrating a method for confirming computing resource startup failure provided in this application embodiment; Figure 2 A schematic diagram of a computing resource startup failure confirmation system provided in this application embodiment; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application; Figure 4 This is another structural schematic diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0019] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0020] Please see Figure 1 , Figure 1 This is a flowchart illustrating a method for confirming computing resource startup failure, provided in an embodiment of this application.

[0021] This application provides a method for confirming the failure to power on computing resources, which can be applied to devices such as computing resource scheduling platforms, and includes the following steps: Step S101: Obtain the power-on verification result of the computing resources. The power-on verification result is used to indicate whether the computing resources have been powered on.

[0022] In practical applications, after issuing a power-on command to a target computing resource, the computing resource scheduling platform needs to confirm whether the computing resource has actually completed physical power-on. Since there may be discrepancies between the return result of the power-on command and the actual power-on status, this application obtains a more reliable power status indication by acquiring power-on verification results. These verification results are obtained by periodically querying the power status of the computing resource and include at least two possible results: successful power-on and failed power-on, for use in subsequent judgment steps. Here, computing resources refer to physical or virtual resources that provide computing power, including but not limited to bare-metal servers, physical machines, and virtual machine instances. This application will subsequently use computing resources in the client as an example to illustrate the solution.

[0023] In an exemplary embodiment, during the process of obtaining the power-on verification result of computing resources in the client, a power-on verification task can be registered when the scheduling task enters the running phase. A scheduling task refers to a complete operation process of resource allocation, power-on startup, system deployment, and state recovery for computing resources. Each scheduling task has a globally unique task identifier and includes lifecycle attributes such as creation time, running status, and end time, used to uniquely identify a complete scheduling operation. Power-on verification refers to the process of periodically checking the power status after the power-on command is executed to repeatedly confirm whether the computing resources have truly completed the power-on operation. The purpose is to avoid directly equating the result returned by a single command with the actual power-on result. For example, in a computing resource scheduling platform, when a user initiates a computing resource scheduling request, the platform first creates a corresponding scheduling task. This scheduling task may include the device identifier of the target computing resource, the task creation time, the expected operation type, and the task's lifecycle status. After the scheduling task enters the running state, a power-on verification task is registered around the identifier of this scheduling task. This power-on verification task uses the scheduling task identifier as a unique index and is stored in the task mapping structure. During registration... The current review count is recorded as zero, and the next execution time is set. Based on the power-on review task, the current power status of the computing resources is queried according to a preset period. That is, the power-on review task is executed according to a preset period, which is a configurable parameter, such as 10 seconds, 15 seconds, or 30 seconds. Each time the power-on review task is executed, the current lifecycle status of the target scheduled task is read first to confirm whether the scheduled task is still running. If it is still running, the current power status of the target computing resources is queried through the out-of-band management interface, etc. In response to the current power status being queried within the preset number of times threshold, the system will proceed accordingly. If the power-on state is active, a power-on success event is generated. This event includes at least the power-on success event type, target computing resource identifier, scheduling task identifier, detection timestamp, and the original return value of the power status query. This power-on success event is used as the power-on verification result. If the number of consecutive queries reaches a preset threshold and no power-on state is found, a power-on failure event is generated. This event includes at least the power-on failure event type, target computing resource identifier, scheduling task identifier, last detection timestamp, and the number of consecutive failures. This failure event is also used as the power-on verification result. In this way, the initial state of "power-on command executed" can be further refined into two reusable structured results: "power-on confirmed successful" or "power-on not yet activated after consecutive verifications." These results are then solidified in the form of power-on success and power-on failure events, respectively, for use in subsequent failure confirmation processes.

[0024] During computing resource scheduling, the lifecycle of a scheduled task may end prematurely for various reasons, such as user-initiated cancellation of the scheduling request, scheduling timeout, or failure of prerequisite dependencies. If the power-on verification task continues to run after the scheduled task has ended, it will not only waste computing and network resources but may also incorrectly generate power-on success or power-on failure events after the scheduled task has ended, interfering with subsequent processes. To address this issue, this application establishes a binding relationship between the lifecycles of the power-on verification task and the scheduled task. Specifically, firstly, the registration timing of the power-on review task is strictly synchronized with the scheduling task entering the running state. The review task is only registered after the scheduling task successfully enters the running state. If the scheduling task fails to enter the running state for any reason, the review task is not registered. Secondly, each time a power-on review task is executed, the current lifecycle state of the scheduling task is first checked. The lifecycle state of the scheduling task can include creation, running, end, cancellation, failure, etc. If it is detected that the scheduling task does not exist in the system, or its state is no longer running, it means that the scheduling process has ended or there is no need to continue the review. At this time, the power-on review task is automatically cancelled, for example, by deleting the task entry from the task mapping structure and releasing the related resources. Thirdly, when the task state is changed to a non-running state, the review task associated with the task is actively cancelled. This proactive notification mechanism has lower latency than passive verification and can release resources more promptly. Through this mechanism, the lifecycle of the power-on review task is strictly limited to the time period during which the scheduling task is running, and it will not continue to run beyond the lifecycle of the scheduling task, thereby ensuring the consistency between the review behavior and the status of the scheduling task.

[0025] Step S102: Obtain the first state information, second state information and third state information associated with the scheduling task of computing resources.

[0026] In practical applications, scheduling tasks are associated with multiple dimensions of state information, such as first state information, second state information, and third state information. The order in which these three types of state information are acquired can be flexibly adjusted; they can be acquired in parallel to shorten the overall time consumption, or they can be acquired sequentially according to a preset priority. In an exemplary embodiment, the first state information is used to characterize the state of computing resources at the client host operating level. Specifically, it refers to host operation evidence related to successful boot collected by the operating system's internal monitoring agent, such as host boot time information and recent operation reporting time information. This information originates from the operating system operation records of computing resources collected by the host monitoring system. The second state information is used to characterize the state of computing resources during the startup process phase. Specifically, it refers to evidence related to startup completion collected by the diskless boot management system, such as diskless boot success time information. This information can originate from the pre-boot execution environment boot phase log records of computing resources collected by the diskless boot management system. The third state information is used to characterize the event state of computing resources at the hardware management level. Specifically, it refers to the hardware management event logs recorded by the baseboard management controller, including power state change events, hardware fault alarms, and repeated power-on error events. These three types of status information sources are independent of each other in terms of data link, data source, and reporting mechanism. Obtaining these three types of status information is equivalent to obtaining multi-source data, which can improve the reliability of boot failure confirmation through subsequent cross-validation.

[0027] In specific application scenarios, the first state information originates from the host monitoring system and is used to characterize the status of computing resources at the client host's runtime level. For example, within the operating system of the computing resource, a monitoring agent runs. This agent runs automatically after the operating system starts and periodically reports heartbeat data to the host monitoring system. The heartbeat data includes at least the host identifier, reporting timestamp, CPU utilization, memory utilization, and other runtime status information. When the operating system successfully starts for the first time, the monitoring agent reports a record containing the host's boot time. The host monitoring system persistently stores these reported records in the monitoring database, and each record is associated with the device identifier of the target computing resource. During the acquisition of the first information, the device identifier of the target computing resource can be used as a query condition to retrieve host monitoring records related to the time window of the scheduled task from the host monitoring system. The retrieval results need to extract at least two key fields: host boot time and the most recent running reporting time, to determine the first state information.

[0028] The second status information comes from the diskless boot management system and is used to characterize the status of computing resources during the boot process. It can be obtained from a series of staged status logs generated by the computing resources during diskless boot. These logs record the network card identifier and device identifier associated with the target computing resources. In the process of obtaining the second information, the device identifier or network card identifier of the target computing resources can be used as a query condition to retrieve the diskless boot monitoring records corresponding to the scheduling task from the diskless boot management system.

[0029] The third state information originates from the Baseboard Management Controller (BMC) and is used to characterize the event status of computing resources at the hardware management level. As an independent management subsystem on the server motherboard, the BMC continuously records various events generated at the hardware level. These events are stored in the BMC's system event log, and event types include, but are not limited to: power state change events, hardware fault alarms, and repeated power-on error events. A repeated power-on error event refers to an abnormal event that occurs when the BMC detects that the host is already powered on, but the system executes the power-on command again. Therefore, during the acquisition of this third information, the BMC's system event log can be read through the out-of-band management interface, or the BMC events associated with the target computing resource can be retrieved from the BMC event records synchronized to the platform database.

[0030] In the exemplary embodiment, before obtaining the first, second, and third state information associated with the scheduling task of the computing resources, the duration of the scheduling task from its creation time to its end time can also be calculated. For example, continuously listening to the update event of the scheduling task, which is published when the task state changes, when it is detected that the target scheduling task has been written with an end time and its state is marked as ended, subsequent information is not immediately obtained. Instead, the following judgment logic is executed first: read the creation time and end time of the scheduling task. The creation time is the UTC timestamp of the scheduling task being created in the database, and the end time is the UTC timestamp of the scheduling task changing its state to end. Calculate the duration of the scheduling task, which is the difference between the end time and the creation time. This duration reflects the total time from the creation of the scheduling task to its end, including the issuance of the power-on command, waiting for power-on completion, operating system startup, monitoring reconnection, etc. In all stages, in response to the completion of the scheduling task and its duration not being less than a preset duration threshold, the steps of obtaining the first, second, and third status information associated with the scheduling task of the computing resource are executed. The preset duration threshold is a configurable parameter, and its value should be greater than the shortest time required for the computing resource to complete the monitoring back connection from power-on. It can be a fixed value or dynamically calculated based on the historical average startup time of this type of computing resource plus a redundant time window. Correspondingly, if the duration is not less than the preset duration threshold, it means that the scheduling task has run for a sufficient amount of time and has provided sufficient startup opportunities. At this time, it is reasonable to execute the steps of obtaining the first, second, and third status information. If the duration is less than the preset duration threshold, it means that the scheduling process may still be in an unstable convergence stage or belong to a short-term abnormal process that does not need to be included in the power-on failure confirmation. At this time, the current process is terminated, and no further information acquisition or failure judgment is performed. In this way, by introducing this time threshold, the two conditions of the task completion and the start process having enough time to complete are combined, which effectively avoids false alarms caused by premature judgment and improves the accuracy of failure confirmation results.

[0031] Step S103: Based on the power-on verification result, the first status information, the second status information, and the third status information, determine whether the scheduled task meets the preset power-on failure conditions.

[0032] Step S104: In response to the scheduling task meeting the preset startup failure conditions, a startup failure confirmation result for the computing resources corresponding to the scheduling task is generated.

[0033] In practical applications, after acquiring the above four types of information, a comprehensive judgment is made according to a preset judgment logic. This organically integrates the originally isolated power-on verification results, host monitoring records, diskless boot monitoring records, and hardware event records, achieving accurate confirmation of computing resource boot failure through multi-source cross-verification. The preset boot failure conditions include two categories: the first is a repeated power-on anomaly path, where the boot failure condition is directly determined to be met when the third status information contains a repeated power-on anomaly event identifier; the second is a power-on success path without evidence of successful boot, where the boot failure condition is met when the power-on verification result indicates successful power-on, the first status information lacks evidence of host operation, and the second status information lacks evidence of boot completion. The two failure conditions are ORed, meaning that meeting either condition results in a boot failure. Based on this, once the scheduled task is confirmed to meet the preset boot failure conditions, a structured boot failure confirmation result can be generated. This result includes at least the scheduled task identifier, computing resource device identifier, failure type, and judgment timestamp, for subsequent automatic diagnosis, compensation, and auditing processing.

[0034] It should be noted that the principle behind the repeated power-on anomaly event is as follows: During the normal operation of computing resources, the BMC maintains the current power state of the host, which is stored in the BMC's power management status register. When the scheduling platform sends a power-on command to the BMC, the BMC first checks the current power state. If the current state is already powered on, the BMC cannot perform the power-on operation again and will return an error response, recording a repeated power-on error event in the system event log. The occurrence of this event means that there is a discrepancy between the platform's perception of the host's power state and the actual power state perceived by the BMC. This discrepancy itself is strong evidence of power-on failure. Therefore, if there is a repeated power-on anomaly event identifier in the BMC event log, it is directly determined that the current scheduling task meets the preset power-on failure conditions. This is a special failure path, where the target host has not formed a normal power-on delivery result, but has already exposed the repeated power-on anomaly in the event chain. Thus, it is not necessary to wait for other single evidence sources to complete the confirmation before triggering failure confirmation, thereby achieving rapid identification of this type of failure scenario. Furthermore, if no repeated power-on anomaly is detected, after a sufficiently long startup time, a computing resource that has successfully completed the startup must have generated corresponding success records in the host monitoring system and the diskless boot management system. If these records are missing, it means that the startup process failed at some stage. Therefore, when the power-on verification result indicates that the power-on was successful, the first status information lacks evidence of host operation, and the second status information lacks evidence of startup completion, the startup failure condition is determined to be met.

[0035] In an exemplary embodiment, during the process of determining that the scheduling task meets the preset boot failure condition in response to the power-on verification result indicating successful power-on, and the first status information lacks evidence of host operation, and the second status information lacks evidence of startup completion, the scheduling task meets the preset boot failure condition if the power-on verification result indicates successful power-on, and the host boot time information and the most recent running report time information in the first status information are both empty, and the diskless boot success time information in the second status information is empty. Specifically, the host boot time field and the most recent running report time field are extracted from the first status information. If both fields are empty in the monitoring database, that is, there is no boot record and heartbeat record of the computing resource within the scheduling task time window in the monitoring database, then it is determined that the first status information lacks evidence of host operation; at the same time, the diskless boot success time field is extracted from the second status information. If this field is empty in the diskless boot management system, that is, there is no successful boot record of the computing resource within the scheduling task time window in the diskless boot management system, then it is determined that the second status information lacks evidence of startup completion. This judgment method uses clearly defined data fields for evaluation, making it highly operable and accurate.

[0036] In an exemplary embodiment, after generating a startup failure confirmation result for the computing resource corresponding to the scheduling task, a startup failure exception event can be constructed based on the startup failure confirmation result. This involves extracting key attributes from multiple data sources to construct the exception event. The extracted attributes include at least: the device identifier of the target computing resource, used to uniquely identify the physical server where the startup failure occurred; the network interface card (NIC) identifier of the target computing resource, used to identify the server's management NIC or service NIC; the region identifier of the target computing resource, used to identify the data center or availability zone where the server is located; and the identifier of the scheduling task, used to associate the specific scheduling operation corresponding to this failure confirmation. The startup failure exception event is then sent to an upstream event receiver, for example, through a standardized interface such as a message queue, HTTP RESTful API, or gRPC interface. The upstream event receiver can be a data center management system, an automated operation and maintenance platform, a monitoring and alarm system, or a scheduling retry engine. In this way, multi-source evidence that originally required manual analysis can be transformed into a structured failure result that the platform can automatically confirm and directly report, allowing the failure confirmation result to directly enter the upstream processing chain.

[0037] It should be noted that boot failure exceptions can be constructed according to a predefined event model. This event model may include the following fields: a globally unique event identifier, the boot failure event type, the target computing resource device identifier, the network interface card identifier, the scheduling platform region identifier, the scheduling task identifier, the task creation time, the task end time, detailed evidence for the judgment, and the event occurrence time. The failure reason code can be power-on timeout, power-on without evidence, or repeated power-on, etc.

[0038] Building upon this foundation, a unified confirmation result chain can be further established around the same computing resource, encompassing power-on command triggering, power-on verification result solidification, scheduling end triggering, minimum duration threshold filtering, multi-source status cross-verification, and startup failure anomaly reporting. This unified confirmation result enables subsequent processing such as: querying whether a particular computing resource scheduling process constitutes a genuine startup failure; distinguishing between different failure paths, including failure to actually power on, power-on but unsuccessful startup, and repeated power-on anomalies; triggering automatic diagnosis, retry scheduling, or compensation processes for startup failures; and providing structured input for data center-side anomaly auditing and post-event tracking. Through this mechanism, this application transforms startup failures from merely post-event manual analysis conclusions into standardized anomaly results that can be automatically identified, solidified, and reported by the platform.

[0039] This application provides a method for confirming the power-on failure of computing resources. The method involves obtaining the power-on verification result of the computing resources, which indicates whether the computing resources have been powered on; obtaining first, second, and third state information associated with the scheduling task of the computing resources; determining whether the scheduling task meets preset power-on failure conditions based on the power-on verification result, the first state information, the second state information, and the third state information; and generating a power-on failure confirmation result for the computing resources corresponding to the scheduling task if the scheduling task meets the preset power-on failure conditions. The first state information characterizes the state of the computing resources at the client host runtime level, the second state information characterizes the state of the computing resources during the startup process, and the third state information characterizes the event state of the computing resources at the hardware management level. In this application, the first state information comes from the in-band data plane, the second state information comes from the startup phase data plane, and the third state information comes from the out-of-band management data plane. This is equivalent to obtaining different dimensions of evidence of successful startup from the in-band data plane, the startup phase data plane, and the out-of-band management data plane, respectively. The failure modes of the three are independent of each other. By integrating the three types of heterogeneous data sources for cross-validation, the defects of partial judgment caused by the lack of a single data source are overcome, which can improve the accuracy and reliability of the confirmation of startup failure of computing resources.

[0040] Please see Figure 2 , Figure 2 This is a schematic diagram of a computing resource startup failure confirmation system provided in an embodiment of this application.

[0041] This application provides a computing resource startup failure confirmation system, which may include: The verification result acquisition module 101 is used to acquire the power-on verification result of the computing resources. The power-on verification result is used to indicate whether the computing resources have been powered on. The information acquisition module 102 is used to acquire the first state information, the second state information and the third state information associated with the scheduling task of computing resources; The judgment module 103 is used to determine whether the scheduled task meets the preset power-on failure conditions based on the power-on verification result, the first status information, the second status information and the third status information. The result generation module 104 is used to generate a startup failure confirmation result for the computing resources corresponding to the scheduling task in response to the scheduling task meeting the preset startup failure conditions. The first state information is used to characterize the state of computing resources at the client host runtime level, the second state information is used to characterize the state of computing resources during the startup process, and the third state information is used to characterize the event state of computing resources at the hardware management level.

[0042] This application provides a computing resource startup failure confirmation system. The judgment module is specifically used to: determine that the scheduling task meets the preset startup failure conditions if the third status information contains a repeated power-on abnormal event identifier; and / or, determine that the scheduling task meets the preset startup failure conditions if the power-on verification result indicates successful power-on, and the first status information lacks evidence of host operation, and the second status information lacks evidence of startup completion.

[0043] This application provides a computing resource startup failure confirmation system. The judgment module is specifically used to: respond to the power-on verification result indicating successful power-on, and the host startup time information and the most recently reported running time information in the first status information are both empty, and the diskless startup success time information in the second status information is empty, then determine that the scheduling task meets the preset startup failure conditions.

[0044] The computing resource startup failure confirmation system provided in this application embodiment may further include: The triggering module is used to calculate the duration of the scheduling task from its creation time to its end time before acquiring the first, second, and third state information associated with the scheduling task of computing resources; in response to the end of the scheduling task and the duration not being less than a preset duration threshold, the step of acquiring the first, second, and third state information associated with the scheduling task of computing resources is executed.

[0045] This application provides a computing resource power-on failure confirmation system. The verification result acquisition module is specifically used for: registering a power-on verification task when the scheduling task enters the running phase; querying the current power status of the computing resource according to a preset period based on the power-on verification task; generating a power-on success event if the current power status is found to be in a power-on state within a preset number of queries, and using the power-on success event as the power-on verification result; and generating a power-on failure event if the number of consecutive queries reaches a preset number of queries and no power-on state is found, and using the power-on failure event as the power-on verification result.

[0046] The computing resource startup failure confirmation system provided in this application embodiment may further include: The task management module is used to verify the current lifecycle status of the scheduled task each time a power-on review task is executed; if the current lifecycle status of the scheduled task is no longer running, the power-on review task is canceled.

[0047] The computing resource startup failure confirmation system provided in this application embodiment may further include: The exception reporting module is used to generate a confirmation result of the computing resource startup failure corresponding to the scheduling task, construct a startup failure exception event based on the confirmation result, and send the startup failure exception event to the upstream event receiving end.

[0048] This application also provides an electronic device and a computer-readable storage medium, both of which have the corresponding effects of the computing resource startup failure confirmation method provided in the embodiments of this application. Please refer to... Figure 3 , Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0049] An electronic device provided in this application includes a memory 201 and a processor 202. The memory 201 stores a computer program, and when the processor 202 executes the computer program, it implements the steps of the computing resource startup failure confirmation method described in any of the above embodiments.

[0050] Please see Figure 4Another electronic device provided in this application embodiment may further include: an input port 203 connected to the processor 202 for transmitting commands input from the outside to the processor 202; a display unit 204 connected to the processor 202 for displaying the processing results of the processor 202 to the outside; and a communication module 205 connected to the processor 202 for enabling communication between the electronic device and the outside. The display unit 204 may be a display panel, a laser scanning display, etc.; the communication method adopted by the communication module 205 includes, but is not limited to, Mobile High-Definition Link (MHL), Universal Serial Bus (USB), High-Definition Multimedia Interface (HDMI), wireless connection: Wireless Fidelity (WiFi), Bluetooth communication technology, Bluetooth Low Energy communication technology, and communication technology based on IEEE 802.11s.

[0051] This application provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the steps of the computing resource startup failure confirmation method described in any of the above embodiments.

[0052] The computer-readable storage media involved in this application include random access memory (RAM), memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disks, removable disks, CD-ROMs (compact disc read-only memory), or any other form of storage media known in the art.

[0053] This application provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the steps of the computing resource startup failure confirmation method described in any of the above embodiments.

[0054] For descriptions of relevant parts of the computing resource startup failure confirmation system, electronic device, and computer-readable storage medium provided in this application's embodiments, please refer to the detailed descriptions of the corresponding parts in the computing resource startup failure confirmation method provided in this application's embodiments; they will not be repeated here. Furthermore, parts of the technical solutions provided in this application that are consistent with the implementation principles of corresponding technical solutions in the prior art have not been described in detail to avoid excessive elaboration.

[0055] It should also be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0056] The above description of the disclosed embodiments enables those skilled in the art to make or use this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for confirming computing resource startup failure, characterized in that, include: Obtain the power-on verification result of the computing resources, wherein the power-on verification result is used to indicate whether the computing resources have been powered on; Obtain the first, second, and third state information associated with the scheduling task of computing resources; Based on the power-on verification result, the first status information, the second status information, and the third status information, determine whether the scheduled task meets the preset power-on failure conditions; In response to the scheduling task meeting the preset startup failure condition, a startup failure confirmation result for the computing power resource corresponding to the scheduling task is generated; The first state information is used to characterize the state of computing resources at the client host runtime level, the second state information is used to characterize the state of computing resources during the startup process, and the third state information is used to characterize the event state of computing resources at the hardware management level.

2. The method according to claim 1, characterized in that, Based on the power-on verification result, the first status information, the second status information, and the third status information, determine whether the scheduled task meets the preset power-on failure conditions, including: If the third state information contains a repeat power-on anomaly event identifier, then the scheduled task is determined to meet the preset power-on failure condition. And / or, in response to the power-on verification result indicating successful power-on, and the first status information lacks evidence of host operation, and the second status information lacks evidence of startup completion, the scheduled task is determined to meet the preset power-on failure condition.

3. The method according to claim 2, characterized in that, In response to the power-on verification result indicating successful power-on, and the first status information lacks evidence of host operation, and the second status information lacks evidence of startup completion, the scheduled task is determined to meet the preset power-on failure conditions, including: If the power-on verification result indicates that the power-on was successful, and the host power-on time information and the most recent running report time information in the first status information are both empty, and the diskless boot success time information in the second status information is empty, then it is determined that the scheduling task meets the preset power-on failure condition.

4. The method according to claim 1, characterized in that, Before obtaining the first, second, and third state information associated with the scheduling task of computing resources, the process also includes: The duration of the scheduled task from its creation time to its end time is recorded. In response to the completion of the scheduling task and the duration not being less than a preset duration threshold, the steps of obtaining the first state information, second state information and third state information associated with the scheduling task of acquiring computing resources are executed.

5. The method according to claim 1, characterized in that, Obtain the power-on verification results of computing resources, including: When the scheduling task enters the execution phase, the power-on verification task is registered. Based on the power-on verification task, the current power status of computing resources is queried according to a preset period. In response to the current power state being found to be in a power-on state within a preset number of times threshold, a power-on success event is generated, and the power-on success event is used as the power-on verification result; If the number of consecutive queries reaches the preset threshold and the power-on status is not found, a power-on failure event is generated, and the power-on failure event is used as the power-on verification result.

6. The method according to claim 5, characterized in that, Also includes: Each time the power-on verification task is executed, the current lifecycle state of the scheduled task is verified; If the current lifecycle state of the scheduled task is no longer running, then the power-on verification task is cancelled.

7. The method according to claim 1, characterized in that, After generating the confirmation result of the computing resource startup failure corresponding to the scheduled task, the process also includes: Based on the confirmation result of the computing power resource startup failure, a startup failure exception event is constructed; The boot failure exception event is sent to the upstream event receiver.

8. A system for confirming computing resource startup failure, characterized in that, include: The verification result acquisition module is used to acquire the power-on verification result of the computing resources, and the power-on verification result is used to indicate whether the computing resources have been powered on. The information acquisition module is used to acquire the first state information, second state information and third state information associated with the scheduling task of computing resources; The judgment module is used to determine whether the scheduled task meets the preset power-on failure conditions based on the power-on verification result, the first status information, the second status information and the third status information. The result generation module is used to generate a computing resource startup failure confirmation result corresponding to the scheduling task if the scheduling task meets the preset startup failure condition. The first state information is used to characterize the state of computing resources at the client host runtime level, the second state information is used to characterize the state of computing resources during the startup process, and the third state information is used to characterize the event state of computing resources at the hardware management level.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the computing resource startup failure confirmation method as described in any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of the computing resource startup failure confirmation method as described in any one of claims 1 to 7.

Images