Processing method and device of terminal equipment, storage medium and electronic equipment

Abstract

The invention discloses a processing method and device of terminal equipment, a storage medium and electronic equipment, and relates to the technical field of computers, and the processing method comprises the steps that the running time of a processor of the terminal equipment is acquired from a resource pool of a server side; determining the processor with the running duration exceeding the duration threshold as a risk processor with a fault risk; in response to the fact that the number of the risk processors in the resource pool exceeds a number threshold value, determining a target restart condition for restarting the terminal equipment where the risk processors in the resource pool are located; and restarting the terminal device where the risk processor in the resource pool is located according to the target restarting condition. Compared with the prior art, the method has the advantages that by acquiring the running time of the processors, identifying the risk processors and automatically restarting when the number of the risk processors reaches the standard, faults caused by long-term running of the processors can be avoided in advance, the operation and maintenance efficiency of the terminal equipment is improved, and meanwhile it is guaranteed that the terminal equipment achieves deep energy saving in the deep sleep mode.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a processing method, apparatus, storage medium and electronic device for a terminal device. Background Technology

[0002] C-States (CPU power states) refers to the technology by which the CPU reduces energy consumption by entering different sleep states when idle. When the CPU core is in C0, it executes instructions normally, consuming the most power. When the CPU core is idle, it can enter a series of deeper sleep states from C1 to Cn. The deeper the sleep state, the lower the energy consumption. This is a core technology for energy saving in data center servers in cloud computing and edge computing scenarios.

[0003] Currently, servers need to enable deep hibernation mode to meet energy-saving requirements. However, if the server remains in deep hibernation mode for an extended period, it may cause server crashes and make it impossible to maintain the servers after a large number of crashes. Disabling deep hibernation mode will prevent the server from meeting its deep energy-saving requirements. Summary of the Invention

[0004] In view of this, this application provides a processing method, apparatus, storage medium and electronic device for terminal devices. The main purpose is to solve the technical problem that in the prior art, servers need to enable deep hibernation mode to achieve energy saving requirements. In this case, if the server is in deep hibernation mode for a long time, it will cause the server to crash. Moreover, after a large number of servers crash, it is impossible to maintain the server. Disabling deep hibernation mode will lead to the inability to meet the deep energy saving requirements of the server.

[0005] In a first aspect, this application provides a processing method for a terminal device, including: Obtain the processor runtime of the terminal device from the resource pool on the server side; Processors whose runtime exceeds the duration threshold are identified as risky processors with a risk of failure. In response to the number of risk processors in the resource pool exceeding a number threshold, a target restart condition is determined for restarting the terminal device where the risk processor in the resource pool is located. The terminal device containing the risk processor in the resource pool is restarted according to the target restart conditions.

[0006] Optionally, in response to the number of risk processors in the resource pool exceeding a threshold, a target restart condition is determined for restarting the terminal device where the risk processors in the resource pool reside, including: In response to the number of risk processors in the resource pool exceeding a number threshold, a target time window and / or a target number of processors are determined for restarting the terminal devices where the risk processors in the resource pool are located. The step of restarting the terminal device containing the risk processor in the resource pool according to the target restart conditions includes: According to the target time window and / or the target number of processors, the terminal devices where the risk processors in the resource pool are located are restarted.

[0007] Optionally, according to the target time window and / or the target number of processors, a restart operation is performed on the terminal device where the risk processor in the resource pool is located, including: In response to the current time being within the first time window of the target time window, the target number of processors are determined from the risk processors in the resource pool as the first processors to be restarted; Within the first time window, perform a restart operation on the terminal device where the first processor to be restarted is located.

[0008] Optionally, determining the target number of processors from the risk processors in the resource pool as the first processors to be restarted includes: Determine a first number of risk processors that do not require virtual machine migration; If the first number is greater than the target number of processors, the processors of the target number of processors are determined from the first risk processors as the first processors to be restarted; If the first number is less than or equal to the target number of processors, the first risk processor and the second number of second risk processors that need to be migrated for virtual machines are used as the first processors to be restarted, where the second number is the difference between the target number of processors and the first number.

[0009] Optionally, after performing a reboot operation on the terminal device where the first processor to be rebooted resides within the first time window, the method further includes: In response to the second time window where the current time is within the target time window, the processors in the resource pool other than the first processor to be restarted are designated as the second processor to be restarted. Within the second time window, perform a restart operation on the terminal device where the second processor to be restarted is located.

[0010] Optionally, before performing a restart operation on the terminal device where the risk processor in the resource pool resides according to the target time window and / or the target number of processors, the method further includes: Alarms are masked on the terminal devices where the first risk processor, which does not require virtual machine migration, is located. Perform virtual machine migration and alarm masking on the terminal device where the second risk processor that requires virtual machine migration is located.

[0011] Secondly, this application provides a processing apparatus for a terminal device, comprising: The acquisition module is configured to obtain the processor runtime of the terminal device from the resource pool on the server. The determination module is configured to identify processors whose runtime exceeds a duration threshold as risky processors with a risk of failure. The determination module is also configured to determine a target restart condition for restarting the terminal device where the risk processor in the resource pool is located in response to the number of risk processors in the resource pool exceeding a number threshold. The restart module is configured to perform a restart operation on the terminal device where the risk processor in the resource pool is located, according to the target restart conditions.

[0012] Thirdly, this application provides a computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the processing method of the terminal device described in the first aspect.

[0013] Fourthly, this application provides an electronic device, including a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, wherein the processor executes the computer program to implement the processing method of the terminal device described in the first aspect.

[0014] By employing the above technical solution, this application provides a processing method, apparatus, storage medium, and electronic device for a terminal device. The method obtains the runtime of the terminal device's processor from a resource pool on the server side; identifies processors whose runtime exceeds a certain threshold as risky processors; determines target restart conditions for restarting the terminal device containing the risky processors in the resource pool when the number of risky processors in the resource pool exceeds a certain threshold; and performs a restart operation on the terminal device containing the risky processors in the resource pool according to the target restart conditions. Compared with existing technologies, this application, by obtaining the processor runtime and identifying risky processors, automatically executes a restart operation when the number of risky processors reaches a certain threshold. This can proactively avoid failures caused by long-term processor operation, ensure the stable operation of the terminal device and the resource pool, thereby improving the operational efficiency of the terminal device, reducing operational risks, and simultaneously ensuring deep energy saving in deep sleep mode. Attached Figure Description

[0015] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0016] 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, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A flowchart illustrating a processing method for a terminal device according to an embodiment of this application is shown; Figure 2 A flowchart illustrating a processing method for a terminal device according to an embodiment of this application is shown; Figure 3 A schematic diagram illustrating an example provided in an embodiment of this application is shown; Figure 4 A schematic diagram illustrating an example provided in an embodiment of this application is shown; Figure 5 This paper shows a schematic diagram of the structure of a processing device for a terminal device according to an embodiment of this application; Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0018] The embodiments of this application will now be described in more detail with reference to the accompanying drawings. It should be noted that, unless otherwise specified, the embodiments and features described herein can be combined with each other.

[0019] To address the current technical problem that servers need to enable deep hibernation mode to achieve energy savings, which can lead to server downtime and make maintenance impossible after a large number of server failures, this embodiment provides a processing method for a terminal device, such as... Figure 1 As shown, the method includes: Step 101: Obtain the runtime of the terminal device's processor from the server's resource pool.

[0020] In this embodiment, the server can be a device or system with resource management capabilities. The server can be used to collect, store, and process the operating data of the terminal device, thereby enabling remote control of the terminal device. For example, the server in this embodiment can specifically be a cloud management system, which can establish a communication connection with the terminal device and receive the operating data reported by the terminal device in real time.

[0021] In this embodiment, the resource pool can be a pool composed of processors from multiple terminal devices, and these processors can belong to the same data center, the same business cluster, or the same management domain. For example, the resource pool in this embodiment can specifically be a collection of CPU resources corresponding to a domestically produced x86 architecture server cluster.

[0022] In the embodiments of this application, the terminal device can be a hardware device with computing capabilities, such as a server or workstation, and the processor of the terminal device can be a core computing component such as a central processing unit (CPU). For example, the terminal device in the embodiments of this application can specifically be a server equipped with a domestically produced x86 architecture CPU.

[0023] In this embodiment of the application, runtime can be the cumulative time the processor has been running continuously since its last startup or restart. For example, the runtime in this embodiment can be obtained through a counter function module in the newly added deep hibernation energy-saving security management module. This counter function module can interact with the server to synchronize the processor's clock counter value and convert it into time units such as days or hours. When the processor starts, the initial runtime value can be 0. For every 24 hours of continuous operation, the runtime can increase by 1 day. If the terminal device restarts due to fault maintenance, active restart, or other reasons, the runtime can be reset to 0 and the accumulation can begin again.

[0024] It should be noted that the runtime can be obtained in real time through communication protocols such as SNMP and HTTP, or by the terminal device reporting to the server at a preset period (such as every hour). The server then verifies and organizes the reported data to obtain the target runtime.

[0025] Step 102: Identify processors whose runtime exceeds the duration threshold as risky processors with potential for failure.

[0026] In this embodiment of the application, the duration threshold can be a pre-set runtime threshold used to determine whether the processor faces a risk of failure. The duration threshold can be pre-configured in combination with the processor's hardware design characteristics, fault triggering rules and operation and maintenance security requirements, or it can be dynamically adjusted according to the processor model, application scenario, business importance and other factors.

[0027] For example, the duration threshold in this application embodiment can be specifically set for the characteristics of a CPU with deep hibernation power saving function. The clock counter inside the CPU counts from the time of power-on. When the count exceeds the preset value, it will overflow, which is equivalent to a continuous running time of about 1044 days. If the CPU is in a deep hibernation state (such as C6 or an equivalent deep hibernation state) after overflow, it will cause a crash. Therefore, in order to reserve sufficient safety redundancy, the duration threshold can be set to 1000 days. That is, when the CPU's running time exceeds 1000 days and it is in a deep hibernation state, it can be determined to be a risky processor.

[0028] In this embodiment, a risk processor can be a processor whose runtime exceeds a time threshold, posing a potential hardware failure or functional malfunction due to prolonged operation. For example, after obtaining the runtime of each processor, the runtime of each processor can be compared with the time threshold. If the runtime of a processor exceeds the time threshold, then the processor can be identified as a risk processor with a failure risk.

[0029] Step 103: In response to the number of risk processors in the resource pool exceeding the number threshold, determine the target restart conditions for restarting the terminal device where the risk processors in the resource pool are located.

[0030] In this embodiment of the application, the quantity threshold can be a pre-set critical value for the number of risk processors used to determine whether a batch restart operation needs to be initiated. The quantity threshold can be set in combination with the size of the resource pool, the operation and maintenance capacity, and the scope of business impact.

[0031] For example, the method for setting the quantity threshold in the embodiments of this application may include, but is not limited to, configuring it according to a fixed number, or configuring it according to the proportion of the total number of processors in the resource pool, or dynamically adjusting it according to factors such as the manpower reserves of the operation and maintenance team and the duration of business off-peak periods. For example, if the resource pool contains 1,000 terminal devices, the quantity threshold can be set to 700 (i.e., the risk processor accounts for 70%). When the number of risk processors in the resource pool exceeds 700, the restart condition determination process is triggered.

[0032] In this embodiment, the target restart condition can be a constraint set to ensure the safe and orderly execution of the restart operation. For example, the target restart condition in this embodiment may specifically include restart time requirements, limits on the number of processors for batch execution, etc. For instance, the execution time of the restart operation and the number of processors for a single restart can be determined by combining factors such as idle business hours and the remaining capacity of the resource pool.

[0033] Step 104: Reboot the terminal device containing the risk processor in the resource pool according to the target reboot conditions.

[0034] In this embodiment, a restart operation can refer to the operation of shutting down and then turning on the terminal device. The restart operation can be used to reset the processor's operating state and eliminate potential faults accumulated over long-term operation. For example, in this embodiment, the restart operation can be specifically initiated by a server (such as a cloud management system) issuing a restart command based on target restart conditions. The terminal device receives the command and automatically executes the restart process without manual intervention.

[0035] For example, if the target restart conditions include a rule that is executed between 0:00 and 4:00 at night and restarts 20 devices at a time, the server will send restart instructions to the terminal devices where the risk processor is located in batches of 20 devices during the period between 0:00 and 4:00 at night, and the terminal devices will execute the restart operation in sequence.

[0036] Compared with the prior art, the embodiments of this application obtain the processor runtime and identify risky processors. When the number of risky processors reaches the standard, an automatic restart operation is performed. This can avoid failures caused by long-term processor operation in advance, ensure the stable operation of terminal devices and resource pools, thereby improving the operation and maintenance efficiency of terminal devices, reducing operation and maintenance risks, and ensuring that terminal devices achieve deep energy saving in deep sleep mode.

[0037] As an optional approach, when executing the "responding to the number of risk processors in the resource pool exceeding a threshold, determine the target restart condition for restarting the terminal device where the risk processors in the resource pool reside," the following methods can be used, but are not limited to them, such as... Figure 2 As shown, it includes: Step 201: In response to the number of risk processors in the resource pool exceeding the number threshold, determine the target time window and / or the target number of processors for restarting the terminal devices where the risk processors in the resource pool are located.

[0038] In this embodiment of the application, the target time window can be a pre-planned time period suitable for performing the restart operation. The target time window can be used to avoid peak business periods to reduce the impact on business. For example, in this embodiment of the application, the target time window can be specifically set to 0-4 am (240 minutes in total) at night, excluding the beginning and end of the month and holidays. During this period, the business load is low, and the restart operation has the least impact on business.

[0039] In this embodiment of the application, the target number of processors can be the maximum number of processors allowed to be restarted in a single cycle or period, based on the remaining capacity of the resource pool. The target number of processors can be calculated using Formula 1, where the preset upper limit can be 20, 30, etc., and the remaining capacity of the resource pool can be determined by data such as CPU and memory usage monitored in real time by the server.

[0040] Target number of processors = min(preset upper limit, remaining capacity of resource pool) (Formula 1) Step 202: Reboot the terminal devices containing the risk processors in the resource pool according to the target time window and / or the target number of processors.

[0041] In this embodiment, if a target time window and a target number of processors are set, the terminal devices of the target number of processors can be restarted within the target time window. For example, if the target time window is from 0:00 to 4:00 at night and the target number of processors is 20, the server will start the restart process precisely at 0:00, selecting 20 terminal devices containing risk processors to perform restarts each time. After the restarts are completed, the next batch will be started, until the preset number of restart operations are completed within the time window.

[0042] In this embodiment of the application, if only a target time window is set, the risk processor can be restarted continuously within the target time window until all risk processors have completed restarting or the time window ends; if only the target number of processors is set, they can be restarted in batches according to the target number of processors, and the batch interval can be set according to the business recovery requirements (such as one batch per hour).

[0043] It should be noted that during the restart operation, the server can monitor the restart progress and resource pool status in real time. If resource overload or business anomalies occur, the restart operation can be paused and the target parameters adjusted.

[0044] As an optional approach, when performing the action of "rebooting the terminal device where the risk processor in the resource pool is located according to the target time window and / or the target number of processors", the following method may be used, but is not limited thereto: the method includes: in response to the current time being in the first time window of the target time window, determining the number of processors of the target number of processors from the risk processors in the resource pool as the first processor to be rebooted; and performing a reboot operation on the terminal device where the first processor to be rebooted is located within the first time window.

[0045] In this embodiment, the first time window can be the first execution period divided within the target time window. The division of the first time window can include, but is not limited to, splitting by day or by hour. For example, in this embodiment, the target time window can specifically be 0:00-4:00 AM for two consecutive days, with the first day's 0:00-4:00 AM being the first time window, and the target number of processors being 20. When the current time is within the first day's 0:00-4:00 AM, 20 processors are selected from the risk processors in the resource pool as the first processors to be restarted, prioritizing processors with no business load to reduce impact.

[0046] In this embodiment, the first processor to be restarted may be a processor selected from the risk processors and given priority for restarting. The selection method for the first processor to be restarted may include, but is not limited to, sorting based on factors such as the processor's service carrying status, resource utilization, and fault risk level, prioritizing the processor with the least impact.

[0047] Optionally, when executing "determining the target number of processors from the risk processors in the resource pool as the first processors to be restarted", the following method may be used, but is not limited thereto: the method includes: determining a first number of first risk processors that do not need to be migrated from the risk processors; if the first number is greater than the target number of processors, determining the target number of processors from the first risk processors as the first processors to be restarted; if the first number is less than or equal to the target number of processors, taking the first risk processor and a second number of second risk processors that need to be migrated as the first processors to be restarted, where the second number is the difference between the target number of processors and the first number.

[0048] In this embodiment, the first risk processor may be a risk processor that does not host any virtual machines on the terminal device and does not require virtual machine migration upon restart. The first risk processor can be determined by querying the virtual machine running status of the terminal device through the server.

[0049] In the embodiments of this application, the second risk processor may be a risk processor that hosts a virtual machine on the terminal device and needs to migrate the virtual machine to another device before restarting. The selection of the second risk processor can be determined by combining factors such as the difficulty of virtual machine migration and the carrying capacity of the target device.

[0050] In the embodiments of this application, the first quantity may be the total number of first risk processors.

[0051] In this embodiment of the application, the second quantity may be the number of additional risk processors that need to be added from the second risk processor in order to meet the target number of processors.

[0052] For example, the virtual machine in this application embodiment can be a virtual computing environment simulated on a physical terminal device through virtualization technology. The virtual machine can independently run an operating system and business applications. The first risk processor is the risk processor on the terminal device that does not run any virtual machines, and the second risk processor is the risk processor on the terminal device that runs virtual machines. If the target number of processors is 20, the first number of first risk processors is determined to be 15. Since 15 is less than 20, the second number is 20-15=5. That is, the first processors to be restarted include 15 first risk processors and 5 second risk processors. If the first number is 25, which is greater than the target number of processors of 20, then 20 are randomly selected from the 25 first risk processors or sorted by resource utilization as the first processors to be restarted.

[0053] Optionally, after executing "perform a restart operation on the terminal device where the first processor to be restarted is located within the first time window", the following method can be used, but is not limited to: in response to the second time window where the current time is within the target time window, the processors in the resource pool other than the first processor to be restarted are designated as the second processor to be restarted; and a restart operation is performed on the terminal device where the second processor to be restarted is located within the second time window.

[0054] In this embodiment, the second time window can be the next execution period after the first time window within the target time window. The second time window can be continuous with the first time window or spaced apart by a preset time. The setting of the second time window can be determined based on the total number of risk processors, the restart time of a single batch, etc.

[0055] It should be noted that if there are a large number of risk processors, a third time window and a fourth time window can be created until all risk processors have completed the restart. During the restart process, if the preset restart task is not completed within a certain time window, the remaining task can be carried over to the next time window.

[0056] In this embodiment, the second processor to be restarted may be a remaining risk processor in the resource pool that has not completed restarting in the first time window.

[0057] For example, if the target time window in this application embodiment is 0-4 AM for two consecutive nights, then 0-4 AM on the first day is the first time window, and 0-4 AM on the second day is the second time window; if the first number of processors to be restarted is 20, and there are a total of 100 risk processors in the resource pool, then the second number of processors to be restarted is 80; when the current time is 0-4 AM on the second day (second time window), the server starts the restart operation for the 80 second processors to be restarted, and the restart process is the same as that of the first time window, and is executed in batches according to the number of target processors.

[0058] Optionally, before executing "rebooting the terminal devices where the risk processors in the resource pool reside according to the target time window and / or the target number of processors", the following methods may be used, but not limited to these: alarm masking for the terminal devices where the first risk processor does not require virtual machine migration; virtual machine migration and alarm masking for the terminal devices where the second risk processor requires virtual machine migration.

[0059] In this embodiment, alarm blocking can temporarily disable the fault alarm function of the terminal device during the restart process to avoid triggering false alarms due to normal restart operations, which would interfere with operation and maintenance monitoring. For example, the alarm blocking in this embodiment can be implemented by the server issuing an alarm blocking command to the terminal device. The blocking scope can include CPU offline alarms, device disconnection alarms, etc., during the restart process, and the alarm function is automatically restored after the restart is completed.

[0060] In the embodiments of this application, virtual machine migration can be carried out by synchronizing the memory data and running status of the virtual machine running on the terminal device where the second risk processor is located to other normally running terminal devices through hot migration technology without stopping the machine. Virtual machine migration can preferentially select to migrate to terminal devices that have been restarted.

[0061] For example, the virtual machine migration method in this application embodiment may include, but is not limited to, migration based on shared storage or migration based on the network. During the migration process, the migration progress and business status are monitored in real time. If the migration fails, it can be automatically retried or switched to other terminal devices.

[0062] As an alternative, to avoid server crashes that occur after prolonged use in deep hibernation mode (C6 mode) following power-on, requiring manual restart, one approach is to disable the C6 mode on the server device containing the CPU. Disabling C6 mode prevents deeper C-mode energy saving, increasing energy consumption over the server's lifespan. Another approach is to manually estimate the potential server failure time and restart the server extensively in advance; however, this method is inefficient, risky, and practically unmanageable. Therefore, this application also provides an example, such as... Figure 3 As shown, the C6 energy-saving and safety management module mainly includes three functional modules: a counter function module, a detection function module, and an automated restart strategy function module. The C6 energy-saving and safety management module interacts with the cloud management system (i.e., the server in this embodiment) to exchange information and issue policies to control and enable the C6 energy-saving server to safely and automatically restart to solve the problem of downtime failure. The C6 energy-saving and safety management module can be set up together with the cloud management system or as an independent cloud operation and maintenance tool.

[0063] Optionally, the counter function module synchronizes the server's clock counter value (i.e., the running time in this embodiment) through the cloud management system and converts it to days. The initial value TIME=0 when the server is powered on; TIME increases by 1 for each day (24 hours) of operation; if the server is restarted due to fault maintenance or other reasons, TIME is reset to 0.

[0064] Optionally, the detection module detects all servers whose counter N (e.g., 730) is less than TIME and whose counter M (e.g., 1000) is less than the TIME value, and calculates the percentage of such servers in the entire resource pool. It interacts with the cloud management system to record the server's identifier in the cloud resource pool, the name of the resource pool, AZ / HA information, whether there is a business virtual machine, and the computing resource utilization rate of the resource pool. The server is categorized by the entire resource pool. When the percentage of such servers in the entire pool reaches a threshold (e.g., 70%), an alert or alarm is issued, and the automated restart strategy is notified to be executed.

[0065] Optionally, the automated restart strategy module, designed for Hygon servers with CC6 energy saving enabled, involves three main steps to formulate an automated restart strategy, taking into account constraints to determine the optimal strategy. Initially, a manual confirmation step is added when the strategy is issued to the cloud management system for execution, ensuring perceptibility and maintainability, with the ultimate goal of achieving automation.

[0066] Optionally, the automated restart strategy steps may include: Step 1: For servers without virtual machines, disable alarms for this batch of servers in the system, and then perform a batch restart.

[0067] Step 2: For the remaining virtual machine servers, enable virtual machine hot migration. You can prioritize migrating to servers that have been restarted after the migration is completed. The number of servers to be migrated at one time depends on the remaining computing resources of the target server that can be migrated. Then, proceed with Step 1.

[0068] Step 3: Repeat step 2 until all servers have been restarted.

[0069] It should be noted that the following three restrictive conditions must be met before implementing the resource pool server restart policy: Limitation 1: When the cloud management system implements the above resource pool server restart strategy, it is recommended to avoid the beginning and end of the month and holidays, and to perform the operation during the off-peak business hours from 0:00 to 4:00 at night (a total of 240 minutes) (that is, the target time window of this application embodiment).

[0070] Restriction 2: To ensure business security approaching 1044 days, considering various unforeseen circumstances and security redundancy time, it is recommended to start phased implementation when TIME=1000 days have passed, with one resource pool operated in a 2-day window, and only one resource pool operated within one window period.

[0071] Limitation 3: By implementing the above strategy, the number of servers to be batch-executed at one time (i.e., the first number in the embodiments of this application) can be limited to reduce the scope of impact of a single execution. Based on the time required for a single restart, which is 5 minutes per server (the restart time of high-performance servers is usually between 10 seconds and 5 minutes, depending on the hardware configuration, system complexity and application load), for example, if 1000 servers need to be restarted, and 20 servers are restarted each time, it will take 1000 / 20×5=250 minutes, which can be completed within no more than 2 night operation windows.

[0072] As an optional approach, this application also provides an example, such as... Figure 4 As shown, this example fully implements the restart strategy and constraints required by the user. Through clear logical judgment and process control, it ensures that the server restart operation is completed with minimal business operations within the safe time window (i.e., the target time window in this embodiment), while guaranteeing the operability and maintainability of the system. This example may include the following steps: Step 1: Time Condition Check. First, determine if it is not the beginning or end of the month, not a holiday, and within the 0-4 AM off-peak business period to ensure the restart is performed during the optimal time period; check the current resource pool according to the time window, including the server's continuous running time TIME=1000 days, and whether other resource pools have been operated on that day; if the conditions are not met, enter a waiting state to avoid affecting peak business periods, until the time requirements are met for subsequent processing.

[0073] If step 3 is completed and the process returns to step 1, it is necessary to determine whether the current time exceeds the processing window of a single resource pool. If it exceeds the window, the virtual machine migration will be rolled back, and the processing flow of that resource pool will end.

[0074] Step 2: Processing servers without virtual machines. Filter out servers without virtual machines and first disable their alarms; perform batch restarts to reduce manual intervention costs; after restarting servers without virtual machines, check if all servers in the resource pool detection list have restarted. If so, skip Step 3 and return to Step 1 to check if there is another resource pool to be processed; if not, proceed to Step 3 to process servers with virtual machines.

[0075] Step 3: Processing servers with virtual machines. Select servers with virtual machines and perform virtual machine hot migration first; prioritize migrating to servers that have already been restarted to make full use of resources; after migration is complete, execute the restart process in Step 2 to form a loop; otherwise, retry the migration or adjust the target.

[0076] As an optional approach, this example also includes a restrictive condition implementation mechanism, which may specifically include: Time window control ensures compliant operation time through three judgment nodes (not at the beginning or end of the month, not on holidays, and 0-4 o'clock); the waiting node design ensures that the process is blocked until the time conditions are met, avoiding accidental operation.

[0077] The batch quantity limit (i.e., the target number of processors in this embodiment) is dynamically calculated according to the following formulas 2, 3, and 4 when determining the number of restarts: Number of restarts per cycle = min(20, remaining capacity of the target resource pool) (Formula 2) Total time = (Total number of servers / Number of restarts per session) × 5 minutes (Formula 3) Ensure the total operation time does not exceed two night operation windows (2 × 240 minutes = 480 minutes) (Formula 4) A safe time window control is implemented, triggering a restart process when TIME=1000 days, reserving 44 days of safety redundancy; each resource pool is allocated a 2-day operation window, and only 1 resource pool is processed per day; through resource pool status check nodes, it is ensured that only 1 resource pool is operated at the same time.

[0078] Optionally, this example can dynamically adjust the number of restarts per cycle based on the remaining capacity of the resource pool; avoid resource pool overload due to excessive concurrency; process resources in batches, with each resource pool having an independent window; operate only one resource pool per day to control the scope of risk impact; include a built-in time window calculator to automatically plan restart batches and times; and support importing business calendars to automatically avoid important business dates.

[0079] Compared with existing technologies, the embodiments of this application, by specifying the restart conditions of the target time window and / or the target number of processors, can ensure business security while allowing processors to continuously and stably run in deep hibernation power-saving mode, avoiding energy loss caused by power-saving functions being disabled due to fault risks; by prioritizing the processing of some processors to be restarted in the first time window, the restart task can be promoted in an orderly manner in time periods, reducing the load pressure on the resource pool for a single restart; by prioritizing processors that do not require virtual machine migration as the first processors to be restarted, the impact of restart on business can be minimized, and the restart execution efficiency can be improved; by processing the remaining processors to be restarted in the second time window, batch restart of all risky processors can be achieved, ensuring that all processors can safely enable deep hibernation power saving, and maximizing the overall energy saving effect; by performing alarm masking and virtual machine migration processing in advance, false alarm interference caused by restart can be avoided, while ensuring business continuity and further improving the reliability of restart operations.

[0080] Furthermore, as Figure 1 and Figure 2 The specific implementation of the method shown in this embodiment provides a processing device for a terminal device, such as... Figure 5 As shown, the device includes: an acquisition module 31, a determination module 32, and a restart module 33.

[0081] The acquisition module 31 is configured to obtain the runtime of the terminal device's processor from the resource pool on the server. The determination module 32 is configured to identify processors whose runtime exceeds a duration threshold as risky processors with a risk of failure. The determination module 32 is also configured to determine the target restart condition for restarting the terminal device where the risk processor in the resource pool is located in response to the number of risk processors in the resource pool exceeding the number threshold. Restart module 33 is configured to restart the terminal device where the risk processor in the resource pool is located according to the target restart conditions.

[0082] In some examples of this embodiment, the determining module 32 is specifically configured to, in response to the number of risk processors in the resource pool exceeding a number threshold, determine a target time window and / or a target number of terminal devices where the risk processors in the resource pool are located; and perform a restart operation on the terminal devices where the risk processors in the resource pool are located according to the target restart conditions, including: performing a restart operation on the terminal devices where the risk processors in the resource pool are located according to the target time window and / or the target number of terminal devices.

[0083] In some examples of this embodiment, the restart module 33 is further configured to, in response to a first time window in which the current time is within the target time window, determine a target number of processors from the risk processors in the resource pool as the first processors to be restarted; and perform a restart operation on the terminal device where the first processor to be restarted is located within the first time window.

[0084] In some examples of this embodiment, the determining module 32 is further configured to: determine a first number of first risk processors that do not require virtual machine migration from the risk processors; if the first number is greater than the target number of processors, determine the processors of the target number from the first risk processors as the first processors to be restarted; if the first number is less than or equal to the target number of processors, determine the first risk processors and the second number of second risk processors that require virtual machine migration as the first processors to be restarted, wherein the second number is the difference between the target number of processors and the first number.

[0085] In some examples of this embodiment, the restart module 32 is further configured to, in response to a second time window in which the current time is within the target time window, designate the processors in the resource pool other than the first processor to be restarted as the second processor to be restarted; and perform a restart operation on the terminal device where the second processor to be restarted is located within the second time window.

[0086] In some examples of this embodiment, the determining module 32 is further configured to perform alarm masking processing on the terminal device where the first risk processor that does not require virtual machine migration is located; and to perform virtual machine migration and alarm masking processing on the terminal device where the second risk processor that requires virtual machine migration is located.

[0087] It should be noted that other corresponding descriptions of the functional units involved in the processing apparatus of the terminal device provided in this embodiment can be found by referring to... Figure 1 and Figure 2 The corresponding description in [the document] will not be repeated here.

[0088] Based on the above, Figure 1 and Figure 2 Accordingly, this embodiment also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the above-described method. Figure 1 and Figure 2 The method shown.

[0089] Based on this understanding, the technical solution of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as CD-ROM, USB flash drive, mobile hard drive, etc.) and includes several instructions to cause a computer device (such as personal computer, server, or network device, etc.) to execute the methods of various implementation scenarios of this application.

[0090] like Figure 6 The diagram shown is a hardware structure schematic of an electronic device according to the present invention, comprising: At least one processor 401; and, A memory 402 connected to the processing of at least one processor 401 terminal device; wherein, The memory 402 stores instructions that can be executed by at least one processor, which enables the at least one processor to perform the processing method of the terminal device as described above.

[0091] Figure 6 Take a processor 401 as an example.

[0092] The electronic device may also include an input device 403 and an output device 404.

[0093] The processor 401, memory 402, input device 403, and output device 404 can be connected via a bus or other means. Figure 6 Taking the example of a connection between China and Israel via a bus.

[0094] Memory 402, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions / modules corresponding to the processing method of the terminal device in the embodiments of this application, for example, Figure 1 and Figure 2 The method flow is shown. The processor 401 executes various functional applications and terminal device processing by running non-volatile software programs, instructions, and modules stored in the memory 402, that is, it implements the terminal device processing method in the above embodiments.

[0095] The memory 402 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created according to the use of the processing method of the terminal device. Furthermore, the memory 402 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 402 may optionally include memory remotely located relative to the processor 401, and these remote memories can be connected via a network to means of executing the processing method of the terminal device. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, processing networks of mobile terminal devices, and combinations thereof.

[0096] Input device 403 can receive user clicks and generate signal inputs related to user settings and function control of the terminal device's processing method. Output device 404 may include display devices such as a display screen.

[0097] One or more modules are stored in memory 402, and when run by one or more processors 401, they execute the processing method of the terminal device in any of the above method embodiments.

[0098] Optionally, the aforementioned physical devices may also include a user interface, a network interface, a camera, radio frequency (RF) circuitry, sensors, audio circuitry, a Wi-Fi module, etc. The user interface may include a display screen, input units such as a keyboard, etc., and optional user interfaces may also include USB interfaces, card reader interfaces, etc. The network interface may optionally include standard wired interfaces, wireless interfaces (such as Wi-Fi interfaces), etc.

[0099] Those skilled in the art will understand that the physical device structure provided in this embodiment does not constitute a limitation on the physical device, and may include more or fewer components, or combine certain components, or have different component arrangements.

[0100] The storage medium may also include an operating system and a processing module for network terminal devices. The operating system is a program that manages the hardware and software resources of the aforementioned physical devices, supporting the operation of information processing programs and other software and / or programs. The processing module for network terminal devices is used to enable terminal device processing between the various components within the storage medium, as well as terminal device processing with other hardware and software within the information processing physical device.

[0101] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms, or it can be implemented by hardware. By applying the solution of this embodiment, compared with the existing technology, this application embodiment obtains the processor runtime and identifies risky processors, and automatically performs a restart operation when the number of risky processors reaches the target. This can avoid failures caused by long-term processor operation in advance, ensure the stable operation of terminal devices and resource pools, thereby improving the operation and maintenance efficiency of terminal devices, reducing operation and maintenance risks, and ensuring that terminal devices achieve deep energy saving in deep sleep mode. By specifying the restart conditions of the target time window and / or the target number of processors, the processor can be kept running stably in deep sleep energy-saving mode while ensuring business security, avoiding energy loss caused by power-saving functions being turned off due to failure risks. By prioritizing the processing of processors awaiting restart within the first time window, restart tasks can be carried out in an orderly manner across different time periods, reducing the load pressure on the resource pool from a single restart. By prioritizing processors that do not require virtual machine migration as the first processors to be restarted, the impact of restarts on business operations can be minimized, and restart execution efficiency can be improved. By processing the remaining processors awaiting restart through the second time window, batch restarts of all risky processors can be achieved, ensuring that all processors can safely enable deep hibernation for energy saving and maximizing overall energy-saving effects. By performing alarm masking and virtual machine migration processing in advance, false alarms caused by restarts can be avoided, while ensuring business continuity and further improving the reliability of restart operations.

[0102] It should be noted that, in this document, relational terms such as "first" and "second" are used merely 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. Unless otherwise specified, 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 the element.

[0103] The above are merely specific embodiments of this application, enabling those skilled in the art to understand or implement 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 these embodiments, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A processing method for a terminal device, characterized in that, include: Obtain the processor runtime of the terminal device from the resource pool on the server side; Processors whose runtime exceeds the duration threshold are identified as risky processors with a risk of failure. In response to the number of risk processors in the resource pool exceeding a number threshold, a target restart condition is determined for restarting the terminal device where the risk processor in the resource pool is located. The terminal device containing the risk processor in the resource pool is restarted according to the target restart conditions.

2. The method according to claim 1, characterized in that, The response that the number of risk processors in the resource pool exceeds a certain threshold determines the target restart conditions for restarting the terminal devices where the risk processors in the resource pool reside, including: In response to the number of risk processors in the resource pool exceeding a number threshold, a target time window and / or a target number of processors are determined for restarting the terminal devices where the risk processors in the resource pool are located. The step of restarting the terminal device containing the risk processor in the resource pool according to the target restart conditions includes: According to the target time window and / or the target number of processors, the terminal devices where the risk processors in the resource pool are located are restarted.

3. The method according to claim 2, characterized in that, The step of restarting the terminal device containing the risk processor in the resource pool according to the target time window and / or the target number of processors includes: In response to the current time being within the first time window of the target time window, the target number of processors are determined from the risk processors in the resource pool as the first processors to be restarted; Within the first time window, perform a restart operation on the terminal device where the first processor to be restarted is located.

4. The method according to claim 3, characterized in that, The step of determining the target number of processors from the risk processors in the resource pool as the first processors to be restarted includes: Determine a first number of risk processors that do not require virtual machine migration; If the first number is greater than the target number of processors, the processors of the target number of processors are determined from the first risk processors as the first processors to be restarted; If the first number is less than or equal to the target number of processors, the first risk processor and the second number of second risk processors that need to be migrated for virtual machines are used as the first processors to be restarted, where the second number is the difference between the target number of processors and the first number.

5. The method according to claim 4, characterized in that, After performing a reboot operation on the terminal device where the first processor to be rebooted is located within the first time window, the method further includes: In response to the second time window where the current time is within the target time window, the processors in the resource pool other than the first processor to be restarted are designated as the second processor to be restarted. Within the second time window, perform a restart operation on the terminal device where the second processor to be restarted is located.

6. The method according to claim 5, characterized in that, Before performing a restart operation on the terminal device where the risk processor in the resource pool is located according to the target time window and / or the target number of processors, the method further includes: Alarms are masked on the terminal devices where the first risk processor, which does not require virtual machine migration, is located. Perform virtual machine migration and alarm masking on the terminal device where the second risk processor that requires virtual machine migration is located.

7. A processing apparatus for a terminal device, characterized in that, include: The acquisition module is configured to obtain the processor runtime of the terminal device from the resource pool on the server. The determination module is configured to identify processors whose runtime exceeds a duration threshold as risky processors with a risk of failure. The determination module is also configured to determine a target restart condition for restarting the terminal device where the risk processor in the resource pool is located in response to the number of risk processors in the resource pool exceeding a number threshold. The restart module is configured to perform a restart operation on the terminal device where the risk processor in the resource pool is located, according to the target restart conditions.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1 to 6.

9. An electronic device, comprising a storage medium, a processor, and a computer program stored on the storage medium and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 6.

10. A computer program product, the computer program product comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 6.

Images