Node calling method, electronic equipment, storage medium and program product

Abstract

The invention discloses a node calling method, electronic equipment, a storage medium and a program product, and the method comprises the steps: obtaining hardware parameters of service hardware corresponding to each node in response to a node calling request, the hardware parameters comprising online time of the service hardware; based on the online time and the node calling request, performing node screening on each node to obtain candidate nodes; determining the priority of each node in the candidate nodes based on the online time; and calling the target node from the candidate nodes on the basis of the priority, and through the method, the stability of service execution can be improved.

Description

Technical Field

[0001] This application relates to the technical field of cloud services, and in particular, to a method for node invocation, an electronic device, a storage medium, and a program product. Background Art

[0002] With the development of cloud service technology, more and more services involve cloud services. During the process of providing cloud services, the longer the service time of the cloud service, the more likely it is to fail. In related technologies, in order to ensure the normal provision of cloud services, the service time of the cloud service is often controlled by setting an expiration time. For example, if the expiration time is 5 years, the cloud service will be taken offline after 5 years of providing services. At the same time, during the process of providing cloud services, failures may also occur. When a cloud service fails, whether or not the expiration time has been reached, the cloud service needs to be taken offline. Through the above method, although the normal operation of the cloud service can be ensured, when the expiration time is reached or a failure occurs midway, the cloud service is directly taken offline, and the hardware corresponding to the cloud service will no longer work after being taken offline, resulting in low utilization efficiency of the hardware corresponding to the cloud service. At the same time, if services with high importance are deployed in cloud services approaching the expiration time, it is very easy to cause irreparable losses and reduce the stability of service execution. Summary of the Invention

[0003] In view of this, embodiments of this application provide a method for node invocation, an electronic device, a storage medium, and a program product.

[0004] The technical solution of the embodiments of this application is implemented as follows:

[0005] Embodiments of this application provide a method for node invocation, the method comprising:

[0006] In response to a node invocation request, obtain the hardware parameters of the service hardware corresponding to each node, where the hardware parameters include the online time of the service hardware;

[0007] Based on the online time and the node invocation request, perform node screening on each of the nodes to obtain candidate nodes;

[0008] Based on the online time, determine the priority of each node in the candidate nodes;

[0009] Based on the priority, invoke a target node from the candidate nodes.

[0010] In the above solution, before responding to the node call request, the method further includes: obtaining the hardware parameters of the service hardware of each node; marking the file data corresponding to each node to obtain target file data with the hardware parameters; the obtaining the hardware parameters of the service hardware corresponding to each node in the candidate nodes includes: parsing the target file data of each node in the candidate nodes to obtain the hardware parameters of the service hardware corresponding to each node in the candidate nodes.

[0011] In the above solution, the screening of each node based on the online time and the node call request to obtain candidate nodes includes: obtaining the scheduling time limit in the node call request; determining the current date by calling the current date function, and based on the current date and the online time of the service hardware of each node, determining the service time of each service hardware; if the service time exceeds the scheduling time limit, determining the service hardware corresponding to the service time as expired hardware, and taking the nodes that do not include the expired hardware as the nodes in the candidate nodes.

[0012] In the above solution, the hardware parameters further include the expected lifespan; the determining the priority of each node in the candidate nodes based on the online time includes: performing the following processing for each node in the candidate nodes: determining the lifecycle of the service hardware corresponding to the node based on the expected lifespan and the online time; determining the newness and oldness of the node based on the lifecycle; determining the priority of the node in the candidate nodes based on the newness and oldness of the node and the hardware parameters.

[0013] In the above solution, the determining the newness and oldness of the node based on the lifecycle includes: obtaining the first failure count of the service hardware corresponding to the node and the second failure count of the node; determining the failure rate of the service hardware based on the first failure count and the second failure count; determining the hardware weight of the service hardware based on the failure rate; performing a weighted sum of the lifecycle of the service hardware corresponding to the node based on the hardware weight to obtain the newness and oldness of the node.

[0014] In the above solution, the hardware parameters include: resource occupancy rate; the determining the priority of the node in the candidate nodes based on the newness and oldness of the node and the hardware parameters includes: determining the maximum value among the newness and oldness of the candidate nodes as the target newness and oldness; performing the following processing for each node in the candidate nodes: calculating the difference between the newness and oldness corresponding to the node and the target newness and oldness to obtain the newness and oldness difference of the node; determining the priority of the node based on the newness and oldness difference and the resource occupancy rate of the service hardware corresponding to the node.

[0015] An embodiment of the present application provides a node call device, and the device includes:

[0016] An acquisition module, configured to acquire hardware parameters of service hardware corresponding to each node in response to a node call request, where the hardware parameters include the online time of the service hardware;

[0017] A screening module, configured to perform node screening on each of the nodes based on the online time and the node call request to obtain candidate nodes;

[0018] A determination module, configured to determine the priority of each node in the candidate nodes based on the online time;

[0019] A call module, configured to call a target node from the candidate nodes based on the priority.

[0020] An embodiment of the present application further provides an electronic device, including: a processor and a memory for storing a computer program that can run on the processor, where the processor is configured to execute the steps in the above node call method when running the computer program.

[0021] An embodiment of the present application further provides a computer storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps in the above node call method are implemented.

[0022] An embodiment of the present application further provides a computer program product, including a computer program, and when the computer program is executed by a processor, the steps in the above node call method are implemented.

[0023] In the embodiment of the present application, in response to a node call request, hardware parameters of service hardware corresponding to each node are acquired, and the hardware parameters include the online time of the service hardware. Based on the online time and the node call request, each node is screened to obtain candidate nodes. The present application screens each node through the online time of each service hardware to obtain candidate nodes that can meet the requirements of the node call request, avoiding subsequent calculation and selection of target nodes from all nodes, saving computing resources. At the same time, it also ensures that the finally selected target node is a node that meets the node call request, ensuring the stability of business execution. Then, based on the online time, the priority of each node in the candidate nodes is determined, and based on the priority, a target node is called from the candidate nodes. By determining the priority of each node in the candidate nodes, the most suitable target node for the node call request is selected, improving the stability of business execution. BRIEF DESCRIPTION OF THE DRAWINGS

[0024] Figure 1A It is a first flowchart of a node call method provided by an embodiment of the present application;

[0025] Figure 1B This is the second process schematic diagram of a node call method provided by an embodiment of the present application;

[0026] Figure 2 This is the flowchart for creating a container passed by an embodiment of the present application;

[0027] Figure 3 This is the operation flowchart of a scheduler provided by an embodiment of the present application;

[0028] Figure 4 This is the schematic diagram of the hardware composition structure of an electronic device provided by an embodiment of the present application. Detailed implementation manners

[0029] The present application will be further described in detail below in conjunction with the accompanying drawings and embodiments.

[0030] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those of ordinary skill in the technical field to which this application belongs. The terms used in the specification of this application are only for the purpose of describing specific embodiments and are not intended to limit this application.

[0031] Before further elaborating on the embodiments of the present application, the nouns and terms involved in the embodiments of the present application are described. The nouns and terms involved in the embodiments of the present application are applicable to the following explanations.

[0032] 1) The open-source container orchestration platform (Kubernetes) is an open-source platform used to manage containerized applications on multiple hosts in a cloud platform. The goal of Kubernetes is to make it simple and efficient to deploy containerized applications. Kubernetes provides a mechanism for application deployment, planning, updating, and maintenance.

[0033] 2) In response to: used to represent the conditions or states on which the executed operations depend. When the dependent conditions or states are met, one or more of the executed operations can be real-time or can have a set delay; without special instructions, there is no restriction on the execution order of the multiple executed operations.

[0034] As the usage time of a cloud server increases, the following performance degradation situations may occur: 1. Performance degradation: Each hardware component of the cloud server (such as the Central Processing Unit (CPU), memory, hard disk, etc.) will experience problems such as aging, wear, and failure over time, resulting in a decrease in the performance of the entire system. For example, the startup time becomes slower and the response time becomes longer; 2. Security degradation: Over time, the software and system versions on the cloud server may become outdated, lacking the latest security updates and fixes, making it vulnerable to security vulnerabilities and leading to security issues such as data leakage and system crashes; 3. Compatibility degradation: Over time, the software and system versions on the cloud server may become incompatible, resulting in problems such as system crashes and programs being unable to start, restricting the use of applications; 4. Difficult maintenance: Over time, problems may occur with both the hardware and software of the cloud server, and the maintenance cost will gradually increase. If maintenance and updates are not carried out in a timely manner, serious consequences such as system crashes or data loss may occur.

[0035] In view of this, the embodiments of the present application provide a method for node invocation. In response to a node invocation request, the hardware parameters of the service hardware corresponding to each node are obtained. The hardware parameters include the online time of the service hardware. Based on the online time and the node invocation request, each node is screened to obtain candidate nodes. The present application screens each node through the online time of each service hardware to obtain candidate nodes that can meet the requirements of the node invocation request, avoiding subsequent calculation and selection of target nodes from all nodes, saving computing resources. At the same time, it also ensures that the finally selected target node is a node that meets the node invocation request, ensuring the stability of business execution. Then, based on the online time, the priority of each node in the candidate nodes is determined, and based on the priority, the target node is invoked from the candidate nodes. By determining the priority of each node in the candidate nodes, the most suitable target node for the node invocation request is selected, improving the stability of business execution. Next, the method for node invocation provided by the embodiments of the present application is described. The electronic device for implementing the data processing method of the embodiments of the present application can be a terminal, a server, or a combination of both. Therefore, the execution subject of each step will not be repeated hereinafter. Figure 1A It is a first flowchart of a method for node invocation provided by an embodiment of the present application, as Figure 1A shown. The method includes:

[0036] Step 101, in response to a node invocation request, obtain the hardware parameters of the service hardware corresponding to each node. The hardware parameters include the online time of the service hardware.

[0037] During the operation of cloud services, first, the nodes of each service register with the service registry, providing their own service information, including service addresses, ports, interfaces, etc.; the client (such as a mobile application, etc.) initiates a node call request to the service registry according to business requirements, and the service registry returns the service node information that meets the conditions according to the request, including the routing address, port, etc. of the node. The client selects a node for call according to the node information returned by the service registry. The client sends the call request to the selected service node through methods such as HTTP requests, remote procedure calls (RPCs), message queues, etc. After receiving the request, the service node executes the corresponding business logic according to the request content. After the service node processes the request, it returns the processing result to the client.

[0038] In actual implementation, the services provided by each node need to be supported by multiple service hardware. The service hardware corresponding to each node can be completely different or partially the same. Among them, the service hardware can include CPUs, memories, storage devices, network devices, power supplies, security devices, optical devices, etc.

[0039] In some embodiments, before executing the response to the node call request in step 101, the following technical solutions can also be executed: obtain the hardware parameters of the service hardware of each node; mark the file data corresponding to each node to obtain the target file data with hardware parameters; parse the target file data of each node in the candidate nodes to obtain the hardware parameters of the service hardware corresponding to each node.

[0040] In actual implementation, the file data corresponding to a node is data describing the information of the node, including the information of the service hardware corresponding to the node. For example, the service hardware corresponding to node A is memory B and storage device C, and the file data of node A can be memory B: resource occupancy rate 70%, storage device C: resource occupancy rate 60%.

[0041] In actual implementation, the process of obtaining the hardware parameters of the service hardware of each node can be to log in to each node and collect the specific production date information of the cloud server and each service hardware corresponding to the node. The service hardware includes: CPUs, memory modules, hard disks, graphics cards, motherboards, power supplies, fans, etc.; according to the information such as the model and serial number of the service hardware, look up the production date. The production dates of some service hardware can be obtained from the components themselves, and some need to consult documents such as purchase orders.

[0042] After that, tags can be added to each node to obtain the target file data with hardware parameters. The specific format can be as follows:

[0043]

[0044] Among them, node-name is the name of the node, and date is the online time. Date can be in the format of AAAABBCC, such as 20200101.

[0045] After obtaining the target file data, the hardware parameters of each node can be parsed according to the positions where the hardware parameters are stored in the target file data. Continuing with the above example, if the format of the target file data is kubectl label nodes <node-name>machine_manufacture_date= <date>, the online time of the server (machine) of the node can be obtained by reading the data at the date.

[0046] Step 102: Based on the online time and the node call request, perform node screening on each node to obtain candidate nodes.

[0047] In some embodiments, the step 102 of performing node screening on each node based on the online time and the node call request to obtain candidate nodes can be implemented by the following technical solution: obtain the scheduling time limit in the node call request; determine the current date by calling the current date function, and based on the current date and the online time of the service hardware of each node, determine the service time of each service hardware; if the service time exceeds the scheduling time limit, determine the service hardware corresponding to the service time as expired hardware, and use the nodes that do not include the expired hardware as the nodes in the candidate nodes.

[0048] In actual implementation, the node call request can carry a scheduling time limit to limit the service time of the scheduled nodes, avoid having nodes with long service times and prone to failures undertake important services, and improve the stability of service provision. If the scheduling time limit is not included in the node call request, the scheduling time limit can be set according to the service importance. For example, if the service importance is high, the scheduling time limit can be set to 5 years; if the service importance is medium, the scheduling time limit can be set to 7 years; if the service importance is low, the scheduling time limit can be set to 10 years.

[0049] In actual implementation, by calling the current date function that obtains the current time, the date of the current cloud service is obtained, and then by subtracting the online time of the service hardware from the current date, the service time of each service hardware is obtained. For example, if the current date is 20240101 and the online time of the service hardware is 20220101, the service time of the service hardware can be obtained as 2 years.

[0050] In actual implementation, if the service time of the service hardware corresponding to a node exceeds the scheduling time limit, determine that the service hardware is expired hardware, and do not use the node as a node in the candidate nodes. For example, the service hardware corresponding to node A includes service hardware A, service hardware B, and service hardware C, the scheduling time limit is 5 years, the service time of service hardware A is 2 years, the service time of service hardware B is 3 years, and the service time of service hardware C is 6 years. Then it can be determined that the service time of service hardware C exceeds the scheduling time limit, so it can be determined that service hardware C is expired hardware, and it can be determined that node A is not a node in the candidate nodes.

[0051] Step 103: Based on the online time, determine the priority of each node in the candidate nodes.

[0052] In some embodiments, the hardware parameters further include the expected lifespan. Determining the priority of each node in the candidate nodes based on the online time in step 103 can be implemented through steps 1031 to 1033 as shown in Figure 1B below:

[0053] Step 1031: For each node in the candidate nodes, perform the following processing: Based on the expected lifespan and the online time, determine the lifecycle of the service hardware corresponding to the node.

[0054] Determining the expected lifespan of the hardware is a comprehensive evaluation process that involves considerations of hardware design, manufacturing, testing, and actual usage conditions. Specifically, the expected lifespan of the service hardware can be determined in the following ways:

[0055] 1. Lifespan testing: By running the hardware device for a long time under standard usage conditions and observing changes in its performance and functions, thereby evaluating its lifespan.

[0056] 2. Accelerated lifespan testing: By testing the hardware under extreme conditions (such as high temperature, low temperature, humidity, etc.), accelerating its aging and failure processes, thereby predicting the expected lifespan under normal conditions.

[0057] 3. Failure mode and effect analysis: Analyze the possible failure modes of the hardware and their impacts on system performance to predict the hardware lifespan.

[0058] 4. Critical component lifespan assessment: Predict the lifespan of critical components (such as batteries, motors, electronic components, etc.) in the hardware to estimate the overall hardware lifespan.

[0059] In actual implementation, the lifecycle of the service hardware can be determined through the following formula (1):

[0060]

[0061] In formula (1), P i is the lifecycle of the service hardware, t is the current date, p t is the online time of the service hardware, and A is the expected lifespan of the service hardware.

[0062] Step 1032: Based on the lifecycle, determine the newness of the node.

[0063] In some embodiments, determining the newness or oldness of a node based on its life cycle in step 1032 can be achieved through the following technical solution: obtaining the first failure count of the service hardware corresponding to the node and the second failure count of the node; determining the failure rate of the service hardware based on the first failure count and the second failure count; determining the hardware weight of the service hardware based on the failure rate; and obtaining the newness or oldness of the node by performing a weighted sum of the life cycles of the service hardware corresponding to the node based on the hardware weight.

[0064] In actual implementation, the first failure count can be the failure count of the service hardware, and the second failure count can be the number of times the node corresponding to the service node fails. For example, node A includes service hardware A and service hardware B. Among them, the failure count of service hardware A is 10 times, and the failure count of service hardware B is 30 times. Then, the first failure count of service hardware A can be 10 times, and the second failure count can be 40 times. At this time, the failure rate of service hardware A can be 25%.

[0065] In actual implementation, since the service hardware with a higher number of failures has a greater probability of failure, in order to ensure the stability of the service, the hardware weight can be positively correlated with the failure rate. Specifically, the value of the hardware weight can be 10 times the failure rate. Continuing with the above example, if the failure rate of service hardware A is 25%, then the weight of service hardware A can be 2.5.

[0066] In actual implementation, after obtaining the hardware weight of each service hardware corresponding to the node, a weighted sum of the life cycles of the service hardware can be performed to obtain the newness or oldness of the node.

[0067] Step 1033: Determine the priority of the node among the candidate nodes based on the newness or oldness of the node and the hardware parameters.

[0068] In some embodiments, determining the priority of the node among the candidate nodes based on the newness or oldness of the node and the hardware parameters in step 1033 can be achieved through the following technical solution: determining the maximum value among the newness or oldness of the candidate nodes as the target newness or oldness; performing the following processing for each node among the candidate nodes: calculating the difference between the newness or oldness of the node and the target newness or oldness to obtain the newness difference of the node; and determining the priority of the node based on the newness difference and the resource occupancy rate of the service hardware corresponding to the node.

[0069] In actual implementation, the candidate nodes include node A, node B, and node C. The newness or oldness of node A is 1, the newness or oldness of node B is 2, and the newness or oldness of node C is 3. Then, the newness or oldness 3 of node C can be used as the target newness or oldness. After that, the newness difference of node A can be -2, and the newness difference of node B can be -1.

[0070] In actual implementation, after obtaining the new-old difference, data such as the new-old difference and the resource occupancy rate of each service hardware can be input into the priority prediction model, and the priority of each node in the candidate nodes is output by the priority prediction model.

[0071] In actual implementation, the process of training the priority prediction model can be to obtain training samples with priority annotations, input the training samples into the priority prediction model to be trained, predict the priority of the training samples by the priority prediction model to be trained to obtain the predicted priority, and construct a loss function based on the predicted priority and the priority annotation to train the priority prediction model.

[0072] Step 104, based on the priority, call the target node from the candidate nodes.

[0073] In actual implementation, the node with the highest priority in the candidate nodes can be used as the target node, or the nodes with the top N priorities in the candidate nodes can be selected. Then, the top N nodes are returned to the calling end of the nodes, and the user determines the target node among them.

[0074] Next, an exemplary application of the embodiments of the present application in an actual application scenario will be described.

[0075] The processing methods for cloud server service time scheduling in the related art are usually as follows:

[0076] 1. A third-party platform maintains the activation time of the cloud server and sets an expiration time, which is usually set to 5 years. After 5 years, the service stops when it expires, and these cloud server nodes are manually taken offline.

[0077] 2. Without considering the cloud server service time, as the service time increases, once a failure occurs, it is manually taken offline.

[0078] 3. Divide the working years of the cloud server. When the cloud server has worked for more than a certain number of years, it is regarded as a machine of inferior quality, and the cloud server is added to a cluster with low service quality requirements such as offline service for secondary utilization.

[0079] The disadvantages of the existing processing solutions for cloud server service time scheduling are as follows:

[0080] 1. Lack of flexibility: These solutions usually adopt fixed thresholds or division methods, such as a fixed expiration time or years division, and cannot be comprehensively adjusted according to the actual usage of the cloud server. For example, for some services that do not require high-quality guarantee, the expiration period can be set longer. Therefore, different expiration periods can be set for services with different guarantee levels.

[0081] 2. Service Quality and Stability: As the service time of the cloud server increases, the probability of risks in the software and hardware of the cloud server will increase, and the probability of performance loss will also increase. Directly scheduling services that require high guarantee to machines approaching the end of the warranty period will lead to certain stability risks.

[0082] 3. Higher Management Costs: These solutions often require manual operations and the introduction of third-party systems, such as cloud server offline processing, node grouping, etc., increasing management costs and the risk of errors.

[0083] 4. Ignoring the Differences in the Degrees of Damage of Different Components: Existing processing solutions mainly focus on the service time of the overall cloud server, without considering the differences in the degrees of damage of different components (such as CPU, memory, network interface cards, etc.). This means that when judging whether a cloud server needs maintenance, downgrading, or replacement, refined adjustments cannot be made according to the actual conditions of specific components. For example, the hard disk of a certain cloud server may have been damaged, but its CPU and memory still have good performance. At this time, simply taking the entire cloud server offline based on the overall service time may cause waste of resources.

[0084] The following combines Figure 2 to illustrate the basic core component operation process of creating a container (pod) in Kubernetes. Figure 2 It is the flowchart of creating a container adopted in the embodiments of this application.

[0085] Step 201, Write a file.

[0086] The user pushes the prepared image to the image repository, and the user writes a data serialization format file (yaml) of the Pod to be created. This request is transmitted to the node server (APIServer) component, which will write the Pod-related information into the database.

[0087] Step 202, The node server sends a request to find the container to the scheduler.

[0088] Step 203, The scheduler selects a suitable target node.

[0089] The scheduler will detect the unscheduled Pods and update the cache and queue in the scheduler. The former is used to maintain the cluster situation from the perspective of the scheduler, and the latter is used to maintain the Pods to be scheduled. After being scheduled by the scheduler, through pre-selection filtering and preference scoring, the former filters out the nodes (Nodes) that do not meet the requirements, such as the service time does not match, and the latter performs preference scoring on the filtered Nodes. For example, the resource usage situation on the Node and the preferences of the Node for the Pod will all be used as the basis for scoring. And this scheduler supports custom extension of the existing scheduling strategies.

[0090] Step 204, retrieve and run the container.

[0091] After the Pod completes scheduling, the corresponding node name will be filled in the node name filling place of the calling node. At this time, the detector will detect the filled node name and start the process of starting the Pod, including pulling the required images for the Pod and establishing the running environment of the Pod.

[0092] The following combines Figure 3 , to illustrate the running process of the scheduler. Figure 3 is the running process flow chart of the scheduler provided by the embodiment of the present application.

[0093] Step 301, configure and start the scheduler.

[0094] (1) Add a configuration section to the scheduler's configuration file to specify the default schedulable date range Ti (i.e., the above-mentioned scheduling time limit) during scheduling. The format is as follows:

[0095]

[0096] Date range value <date>Indicates the maximum allowable service life. For example, 5 means 5 years.

[0097] When the scheduler starts, it reads these configurations and saves them as internal variables. When performing scheduling, if the user does not specify Ti in the node call request, this default configuration is adopted. For the previous operation and maintenance failure rate situation, that is, the higher the failure rate, the greater the weight. Default weights are set for each component (i.e., the above-mentioned service hardware), and custom weight setting is supported. The weight wi (i.e., the above-mentioned hardware weight) can be adjusted according to the actual failure rate. The hardware weight will affect the scoring for optimization during subsequent scheduling. The greater the hardware weight, the greater the impact on the final score. Among them, the hardware weight wi = 10 * fi, where fi is the failure rate of the hardware, and the weight of the cloud server is fixed at 1. For example, the hardware weights of node A can be: cloud server: weight w_mac = 1; central processing unit: weight w_cpu = 1; memory (RAM): weight w_ram = 1.5; hard disk (HDD / SSD): weight w_hdd_ssd = 2.5; graphics card (GPU): weight w_gpu = 1.5; network interface card (NIC): weight w_nic = 1; power supply unit (PSU): weight w_psu = 1.5; motherboard: weight w_motherboard = 1.

[0098] Step 302, the scheduler marks the file data of each node.

[0099] Collect the specific production date information of each main component of the node. The main components include: CPU, memory module, hard disk, graphics card, motherboard, power supply, fan, etc. According to the model number, serial number and other information of the components, find the production date. Some information can be obtained from the component itself, and some need to consult documents such as purchase orders. Add labels to the node and its components on each node in the following format:

[0100]

[0101]

[0102] The date in the label uses the YYYYMMDD format, such as 20200101. The tagging operation needs to be completed for each node and its components in the cluster. After completion, the administrator can view the labels of each node, and these labels will be accessed and used in the subsequent scheduling process.

[0103] Step 303, the client issues a node call request.

[0104] The client can specify the production date requirement of the node (i.e., the above-mentioned scheduling time limit) in the YAML file of the task. For example: manufacture-date: <date>; cpu-manufacture-date: <date>; ram-manufacture-date: <date>, the "date" in the label is represented by numbers. This task supports the use of cloud servers or component services <date>Nodes within [X] years.

[0105] Step 304, the scheduler obtains node information.

[0106] The scheduler first obtains information about all nodes, including the hardware configuration of the nodes, resource usage, and the production dates of the nodes and their respective components, etc. Then it accesses the detailed information of all node objects. The node objects contain resource usage, such as requests and limits for CPU and memory.

[0107] The scheduler can also access the summary interface of each node to obtain hardware configuration information of the node, such as the number of CPU cores, total memory, etc. To obtain the production dates of the nodes and components (i.e., the above-mentioned service hardware), the scheduler extracts the tags of the node objects, such as "cpu_manufacture_date=20200101". The scheduler parses these tags, extracts the production dates, and saves them in the standard date format. If the production dates of some components do not exist, the scheduler will record them for notifying the administrator to supplement. Finally, the scheduler will obtain the complete information of each node, including resource usage, hardware configuration, and the production dates of key components.

[0108] Step 305, the scheduler determines whether the node scheduling request includes a scheduling time limit.

[0109] If the node scheduling request does not include a scheduling time limit, then according to the default configuration set in Step 301, such as: when the importance is Guaranteed: Ti = 5 years; when the importance is Burstable: Ti = 7 years; when the importance is BestEffort: Ti = 10 years.

[0110] In the above way, according to the importance of the Pod, different default values for the upper limit of the server usage years that can be tolerated are set. Provide more stringent server usage year requirements for more important Pods, schedule them to newer servers, and provide higher service quality. For less important Pods, the year requirements can be relaxed, allowing them to be scheduled to servers with longer usage times, reducing costs, and thus also extending the server usage years, so that servers that should have been taken off the shelves after 5 years can continue to provide services to less important Pods, thereby delaying the time of taking off the shelves. By reasonably configuring the default values, users can obtain scheduling quality that meets the importance of the Pod without explicitly configuring the production date requirements.

[0111] Step 306, the scheduler determines the candidate node list.

[0112] Call the current date and time function from the system to obtain the current date string. Then convert the string to the standard date format and store it as the variable Dt. After that, for each node n in the cluster, extract the component production date label, such as "cpu_manufacture_date", from the labels of that node. Convert the label date to the standard date format and store it as the variable Dpi. If a certain component's production date is missing for a certain node, record it as missing in Dpi.

[0113] After that, calculate the service life Ui: for each component i of each node n, calculate the service life (i.e., the above-mentioned service time): Ui = Dt - Dpi. Store the Ui of all components as the service life data of node n. Check whether the service life Ui exceeds Ti. For each component i of each node n, if Ui > Ti, then mark node n as not meeting the conditions. If any component does not meet the conditions, filter out that node n. Store the remaining filtered nodes as the candidate node list.

[0114] If all nodes are filtered, then skip some components of some nodes and re-filter until a non-empty candidate node list is obtained.

[0115] Step 307, the scheduler determines the target node.

[0116] The scheduler executes the preference filter to further screen the schedulable node list. Select the best node according to the resource utilization rate, reliability, cloud server and its component production time and other factors of the node. The newer the comprehensive degree of the cloud server and its components, the higher the comprehensive priority of the node. Specifically, obtain the production date information (i.e., the above-mentioned online time) of all candidate nodes that meet the preselection conditions. For each component i, calculate its life cycle ratio pi = (current date t - component production date pti) / component expected life, where the expected life can be set according to historical data and actual situations. Calculate the new and old degree of the node and its components. Specifically, refer to the following formula (2):

[0117] Dnode = ∑W i *P i (2)

[0118] In formula (2), Dnode is the new and old degree, W i is the hardware weight of service hardware i, P i is the life cycle of service hardware i.

[0119] Find the maximum freshness degree (i.e., the above-mentioned target freshness degree) Dnode_max of the node with the latest freshness degree in the candidate node set, that is, Dnode_max = max(Dnode), where Dnode is the freshness degree value of each node in the candidate node set. For each node, calculate its node priority (i.e., the above-mentioned freshness difference) Pnode = Dnode_max – Dnode.

[0120] For each other scheduling policy such as resource utilization rate, service affinity policy, etc., input the current Pod and the candidate node list, run the scoring algorithm of its policy, output the scores of the candidate nodes, and add the score of the node freshness difference to the total score. Select the node with the highest combined score from the candidate nodes as the preferred result (i.e., the above-mentioned target node).

[0121] After that, the detector prepares the running environment of the Pod until the Pod enters the running state (Running). Thus, due to the scheduling decision of the scheduler, the state of the Pod on the target node has been updated from the waiting state (Pending) to Running. In addition, the scheduler will continuously monitor the running state of each Pod. Once it detects that the Pod is in a non-Running state, it will trigger the intelligent rescheduling of the Pod and automatically reschedule the Pod to a more suitable node. During rescheduling, the scheduler will comprehensively consider the resource usage of each node, the production date information, and the configuration requirements of the Pod, and use an algorithm similar to the initial scheduling to calculate the best scheduling decision for the current cluster environment. Through this intelligent rescheduling mechanism, the scheduling location of the Pod can be optimized in real time, and the reliability of the task can be improved. When the node state changes and the original scheduling decision is no longer optimal, the scheduler can quickly respond and automatically migrate the Pod to a more suitable node to avoid task anomalies or failures.

[0122] The embodiment of the present application also provides a node calling device, which corresponds to the above-mentioned node calling method, and the steps in the above-mentioned node calling method embodiment are also fully applicable to the device embodiment of the present application.

[0123] The device includes:

[0124] An acquisition module, configured to acquire the hardware parameters of the service hardware corresponding to each node in response to a node calling request, where the hardware parameters include the online time of the service hardware;

[0125] A screening module, configured to screen each of the nodes based on the online time and the node calling request to obtain candidate nodes;

[0126] A determination module, configured to determine the priority of each node in the candidate nodes based on the online time;

[0127] A calling module, configured to call a target node from the candidate nodes based on the priority.

[0128] It should be noted that: when the device for node calling provided in the above embodiment performs node calling, only the division of the above program modules is used for illustration. In actual application, the above processing can be allocated to different program modules according to needs, that is, the internal structure of the device is divided into different program modules to complete all or part of the above-described processing. In addition, the device for node calling provided in the above embodiment and the method embodiment for node calling belong to the same concept. For the specific implementation process, please refer to the method embodiment, which will not be elaborated here.

[0129] Based on the hardware implementation of the above program modules, and in order to implement the method of the embodiments of the present application, the embodiments of the present application further provide an electronic device. Figure 4 It is a schematic diagram of the hardware composition structure of an electronic device provided by an embodiment of the present application. As Figure 4 shown, the electronic device includes:

[0130] A communication interface 401, capable of interacting with other devices such as network devices for information.

[0131] A processor 402, connected to the communication interface 401 to implement information interaction with other devices, and when running a computer program, configured to execute the method provided by one or more of the above technical solutions. And the computer program is stored on a memory 403.

[0132] Of course, in actual application, each component in the electronic device is coupled together through a bus system 404. It can be understood that the bus system 404 is used to realize the connection and communication between these components. In addition to the data bus, the bus system also includes a power bus, a control bus, and a status signal bus. However, for the sake of clarity, in Figure 4 all kinds of buses are labeled as the bus system 404.

[0133] The memory 403 in the embodiments of the present application is used to store various types of data to support the operation of the computer device. Examples of these data include: any computer program for operating on the electronic device.

[0134] It can be understood that the memory 403 can be a volatile memory or a non-volatile memory, or can include both volatile and non-volatile memories. Among them, the non-volatile memory can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), a ferromagnetic random access memory (FRAM), a flash memory, a magnetic surface memory, an optical disc, or a compact disc read-only memory (CD-ROM); the magnetic surface memory can be a disk memory or a tape memory. The volatile memory can be a random access memory (RAM), which is used as an external cache. By way of example but not limitation, many forms of RAM are available, such as a static random access memory (SRAM), a synchronous static random access memory (SSRAM), a dynamic random access memory (DRAM), a synchronous dynamic random access memory (SDRAM), a double data rate synchronous dynamic random access memory (DDR SDRAM), an enhanced synchronous dynamic random access memory (ESDRAM), a sync link dynamic random access memory (SLDRAM), a direct rambus random access memory (DRRAM).The memories described in the embodiments of this application are intended to include, but are not limited to, these and any other suitable types of memories.

[0135] The methods disclosed in the embodiments of this application above can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with the ability to process signals. In the implementation process, each step of the above methods can be completed by the integrated logic circuit in the hardware of the processor or by instructions in the form of software. The above-mentioned processor may be a general-purpose processor, a DSP, or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The processor can implement or execute each method, step, and logic block diagram disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor, etc. Combining the steps of the methods disclosed in the embodiments of this application, it can be directly embodied as being executed and completed by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software module may be located in a storage medium, and this storage medium is located in the memory. The processor reads the program in the memory and combines its hardware to complete the steps of the foregoing methods.

[0136] Optionally, when the processor 402 executes the program, it implements the corresponding processes implemented by the electronic device in each method of the embodiments of this application. For the sake of brevity, it will not be elaborated here.

[0137] In an exemplary embodiment, the embodiments of this application also provide a storage medium, namely a computer storage medium, specifically a computer-readable storage medium. For example, it includes a first memory storing a computer program. The above computer program can be executed by the processor of the computer device to complete the steps of the foregoing methods. The computer-readable storage medium may be a FRAM, ROM, PROM, EPROM, EEPROM, Flash Memory, magnetic surface memory, optical disc, or CD-ROM, etc.

[0138] In several embodiments provided in this application, it should be understood that the disclosed devices, computer devices, and methods can be implemented in other ways. The device embodiments described above are only illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined, or can be integrated into another system, or some features can be ignored, or not executed. In addition, the couplings, direct couplings, or communication connections between the various components shown or discussed may be through some interfaces. The indirect couplings or communication connections of the devices or units may be electrical, mechanical, or other forms.

[0139] The units described above as separate components may or may not be physically separated. The components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0140] In addition, in each embodiment of this application, each functional unit may be entirely integrated in a processing unit, or each unit may be separately regarded as a unit, or two or more units may be integrated in one unit. The above-mentioned integrated units may be implemented in the form of hardware, or in the form of a combination of hardware and software functional units.

[0141] Those of ordinary skill in the art can understand that all or part of the steps to implement the above method embodiments can be completed by hardware related to program instructions. The foregoing program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps including the above method embodiments. The foregoing storage medium includes various media that can store program codes, such as removable storage devices, ROM, RAM, magnetic disks, or optical discs.

[0142] Alternatively, if the above-mentioned integrated units of this application are implemented in the form of software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of this application essentially or the part that contributes to the related technology can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The foregoing storage medium includes various media that can store program codes, such as removable storage devices, ROM, RAM, magnetic disks, or optical discs.

[0143] In an exemplary embodiment, the embodiments of this application also provide a computer program product, including a computer program, which can be executed by a processor 402 of an electronic device to complete the steps of the method applied to the remote management end in the embodiments of this application.

[0144] In an exemplary embodiment, the embodiments of this application also provide a computer program product, including a computer program, which can be executed by a processor 402 of an electronic device to complete the steps of the method applied to the terminal in the embodiments of this application.

[0145] It should be noted that "first", "second", etc. are used to distinguish similar objects and do not necessarily need to describe a specific order or sequence.

[0146] In addition, the technical solutions described in the embodiments of the present application can be arbitrarily combined without conflict.

[0147] As mentioned above, the above are only specific embodiments of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art within the technical scope disclosed in the present application can easily think of changes or substitutions, which should all be covered within the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.< / date> < / date> < / date> < / date> < / date> < / date>

Claims

1. A method for node invocation, characterized in that: The method comprises: In response to the node call request, obtaining hardware parameters of the service hardware corresponding to each node, wherein the hardware parameters include the online time of the service hardware; Based on the online time and the node call request, each of the nodes is screened to obtain a candidate node; Determine the priority of each node among the candidate nodes based on the online time; Based on the priority, a target node is called from the candidate nodes.

2. The method according to claim 1, characterized in that Before responding to the node call request, the method further includes: Get the hardware parameters of the service hardware of each node; Marking the file data corresponding to each of the nodes to obtain target file data with the hardware parameters; The obtaining of hardware parameters of the service hardware corresponding to each node includes: The target file data of each of the nodes is parsed to obtain hardware parameters of the service hardware corresponding to each of the nodes.

3. The method according to claim 1, characterized in that The node screening is performed on each of the nodes based on the online time and the node call request to obtain a candidate node, including: Obtaining the scheduling time limit in the node call request; Determine the current date by calling the current date function, and determine the service time of each of the service hardware based on the current date and the online time of the service hardware of each of the nodes; If the service time exceeds the scheduling time limit, it is determined that the service hardware corresponding to the service time is expired hardware, and the node that does not include the expired hardware is used as the candidate node.

4. The method according to claim 1, characterized in that: The hardware parameters also include expected lifespan; The determining the priority of each node in the candidate nodes based on the online time includes: The following processing is performed for each of the candidate nodes: Determine the life cycle of the service hardware corresponding to the node based on the expected life span and the online time; Based on the life cycle, determining the newness of the node; The priority of the node among the candidate nodes is determined based on the newness or oldness of the node and the hardware parameters.

5. The method according to claim 4, characterized in that Determining the newness of the node based on the life cycle includes: Obtain a first failure number of service hardware failures corresponding to the node and a second failure number of failures of the node; Determining a failure rate of the service hardware based on the first failure number and the second failure number; determining a hardware weight of the service hardware based on the failure rate; Based on the hardware weight, a weighted sum is performed on the life cycle of the service hardware corresponding to the node to obtain the newness of the node.

6. The method according to claim 4, characterized in that The hardware parameters also include resource occupancy rate; The determining the priority of the node among the candidate nodes based on the newness or oldness of the node and the hardware parameter includes: Determine the maximum value among the newness and oldness of the candidate nodes as the target newness and oldness; The following processing is performed for each of the candidate nodes: Subtract the newness and oldness corresponding to the node from the target newness and oldness to obtain the newness and oldness difference of the node; The priority of the node is determined based on the new and old differences and the resource occupancy rate of the service hardware corresponding to the node.

7. A node calling device, characterized in that: The device comprises: An acquisition module, configured to acquire hardware parameters of service hardware corresponding to each node in response to a node call request, wherein the hardware parameters include an online time of the service hardware; A screening module, used for screening each node based on the online time and the node call request to obtain a candidate node; A determination module, used to determine the priority of each node among the candidate nodes based on the online time; A calling module is used to call a target node from the candidate nodes based on the priority.

8. An electronic device, characterized in that: include: A processor and a memory for storing a computer program that can be executed on the processor, wherein: The processor is used to execute the steps of the node calling method described in any one of claims 1 to 6 when running a computer program.

9. A computer storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the node calling method described in any one of claims 1 to 6 are implemented.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the computer program implements the steps of the node calling method according to any one of claims 1 to 6.

Images