Method and apparatus for scheduling application workloads

Abstract

This specification provides an application workload scheduling method and apparatus. The application workload scheduling method includes: acquiring observability data of a target application workload in an initial node; determining, based on the observability data, related application workloads that the target application workload depends on from all nodes; generating scheduling configuration data based on the dependency relationship between the target application workload and the related application workloads; and scheduling the target application workload and the related application workloads to corresponding target nodes based on the scheduling configuration data. By determining the related application workloads that the target application workload depends on from all nodes and generating scheduling configuration data based on the dependency relationship between application workloads to schedule the application workloads to the corresponding nodes, the communication latency between dependent application workloads is reduced because the dependency relationship between application workloads is taken into account during scheduling.

Description

Technical Field

[0001] The embodiments in this specification relate to the field of computer technology, and in particular to an application workload scheduling method. Background Technology

[0002] Existing platforms only report low-level resource utilization information, such as CPU, memory, and network usage, which is not application-specific. Cluster managers (such as Kubernetes) typically view workload deployment as an allocation problem of using available resources in the cluster to meet the resource needs of applications, and use heuristics to generate best-effort solutions. This results in significant communication latency between nodes hosting some application workloads, necessitating a solution to address this issue. Summary of the Invention

[0003] In view of this, embodiments of this specification provide an application workload scheduling method. One or more embodiments of this specification also relate to an application workload scheduling apparatus, a computing device, a computer-readable storage medium, and a computer program, to address the technical deficiencies existing in the prior art.

[0004] According to a first aspect of the embodiments of this specification, an application workload scheduling method is provided, comprising:

[0005] Obtain observability data for the target application workload in the initial node;

[0006] Based on the observability data, determine the associated application workloads that the target application workload depends on from all nodes;

[0007] Based on the dependency relationship between the target application workload and the associated application workload, schedule configuration data is generated;

[0008] Based on the scheduling configuration data, the target application workload and the associated application workload are scheduled to the corresponding target node.

[0009] According to a second aspect of the embodiments of this specification, an application workload scheduling apparatus is provided, comprising:

[0010] The data acquisition module is configured to acquire observable data of the target application workload in the initial node;

[0011] The relationship determination module is configured to determine, based on the observability data, the associated application workloads that the target application workload depends on from all nodes;

[0012] The configuration generation module is configured to generate scheduling configuration data based on the dependency relationship between the target application workload and the associated application workload.

[0013] The scheduling module is configured to schedule the target application workload and the associated application workload to the corresponding target node according to the scheduling configuration data.

[0014] According to a third aspect of the embodiments of this specification, a computing device is provided, comprising:

[0015] Memory and processor;

[0016] The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions, which, when executed by the processor, implement the steps of the above-described application workload scheduling method.

[0017] According to a fourth aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores computer-executable instructions that, when executed by a processor, implement the steps of the application workload scheduling method described above.

[0018] According to a fifth aspect of the embodiments of this specification, a computer program is provided, wherein when the computer program is executed in a computer, it causes the computer to perform the steps of the application workload scheduling method described above.

[0019] This specification provides an application workload scheduling method and apparatus. The application workload scheduling method includes: acquiring observability data of a target application workload in an initial node; determining, based on the observability data, related application workloads that the target application workload depends on from all nodes; generating scheduling configuration data based on the dependency relationship between the target application workload and the related application workloads; and scheduling the target application workload and the related application workloads to corresponding target nodes based on the scheduling configuration data. By determining the related application workloads that the target application workload depends on from all nodes and generating scheduling configuration data based on the dependency relationship between application workloads to schedule the application workloads to the corresponding nodes, the communication latency between dependent application workloads is reduced because the dependency relationship between application workloads is taken into account during scheduling. Attached Figure Description

[0020] Figure 1 This is a flowchart illustrating an application workload scheduling method provided in one embodiment of this specification;

[0021] Figure 2This is a schematic diagram of a proxy mesh that applies a workload scheduling method according to one embodiment of this specification;

[0022] Figure 3 This is a schematic diagram of an application workload scheduling method provided in one embodiment of this specification;

[0023] Figure 4 This is a schematic diagram illustrating a service dependency of an application workload scheduling method provided in one embodiment of this specification;

[0024] Figure 5 This is a flowchart illustrating the processing procedure of an application workload scheduling method provided in one embodiment of this specification.

[0025] Figure 6 This is a schematic diagram of the structure of an application workload scheduling device provided in one embodiment of this specification;

[0026] Figure 7 This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0027] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0028] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “described,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0029] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

[0030] First, the terms and concepts used in one or more embodiments of this specification will be explained.

[0031] Service Mesh: A service mesh is a configurable infrastructure layer used for managing microservice applications. It is commonly used to describe the services that make up an application (such as microservices) and the interactions between these services. A service mesh typically consists of a control plane and a data plane. The control plane is a set of services running in a dedicated namespace. These services perform control and management functions, such as aggregating telemetry data, providing user-facing application programming interfaces (APIs), and providing control data to the data plane. The data plane consists of a series of transparent proxies running alongside each service instance.

[0032] Service mesh proxy: Used to forward requests to be sent to the service mesh or issued by the service mesh. Requests corresponding to each microservice in the service mesh will pass through the service mesh proxy.

[0033] Service Mesh Proxy Configuration: Service mesh proxy configuration refers to the configuration data issued by the control plane to each service mesh proxy in order to enable the service mesh to correctly proxy service traffic, achieve service interoperability and service governance.

[0034] Cluster: A collection of computer resources that operate as a unit of logical grouping. It may be a single physical cluster or a logical group of clusters that contains multiple physical clusters.

[0035] Multi-cluster: A combination of clusters consisting of more than one cluster.

[0036] Service dependency: In a distributed software system, the services provided by the system are based on the combination and collaboration of different sub-services. Service dependency is often used to describe the calling relationships between other services in order for one service to fulfill a request for that service.

[0037] Application load balancing: refers to the process of scheduling and distributing application workloads across the cluster.

[0038] Kubernetes is an open-source application used to manage containerized applications across multiple hosts in a cloud platform.

[0039] The Deployment object is used to deploy applications. It is one of the most frequently used objects in Kubernetes.

[0040] YAML is a highly readable format used to express data serialization.

[0041] Observability: This usually refers to the ability to measure the current state of a system based on the data generated by the system. It generally includes three dimensions: logs, metrics, and tracking.

[0042] This specification provides an application workload scheduling method, and also relates to an application workload scheduling device, a computing device, and a computer-readable storage medium, which will be described in detail in the following embodiments.

[0043] See Figure 1 , Figure 1 A flowchart of an application workload scheduling method according to an embodiment of this specification is shown, which specifically includes the following steps.

[0044] Step 102: Obtain observability data for the target application workload in the initial node.

[0045] The initial node can be understood as a node in the cluster. For example, if a cluster includes node A and node B, the initial node is node A. The target application workload can be the application workload to be scheduled, such as an email service. Observable data can be the data from when the application workload calls other application workloads. For example, if the email service calls the synchronization service, observable data will be generated.

[0046] In practical applications, when providing users with the required functionalities through the collaboration of multiple services within a service mesh, all requests originally sent directly to services within the service mesh are intercepted by the service mesh proxy. The service mesh proxy then forwards these requests to the services within the service mesh for processing. Similarly, requests sent by individual services within the service mesh are first forwarded to the service mesh proxy, which then forwards them to the corresponding services. Therefore, the service mesh proxy can obtain the runtime status data of each service within the service mesh. Furthermore, the managed control plane component can obtain the runtime status data of the target application workload or issue configuration information for scheduling from the mesh proxy.

[0047] See Figure 2 , Figure 2 This is a schematic diagram of a proxy mesh that applies a workload scheduling method according to one embodiment of this specification. Figure 2 This is a schematic diagram of a service mesh according to an embodiment of the present disclosure. The service mesh is mainly used to facilitate secure and reliable communication between multiple microservices. Microservices refer to decomposing an application into multiple smaller services or instances and distributing them across different clusters / machines.

[0048] As shown in the figure, the microservice includes application service instance A and application service instance B, which together form the functional application layer of the service mesh. In one implementation, application service instances A and B run as containers / processes in machine / workload container group 214 (POD).

[0049] In one implementation, application service instance A can be a product query service, and application service instance B can be a product order placement service.

[0050] like Figure 2 As shown, application service instance A and grid agent (sidecar) 206 coexist in machine workload container group 218, and application service instance B and grid agent 210 coexist in machine workload container 218. Grid agents 206 and 210 form the data plane layer of the service mesh. Grid agents 206 and 210 run as containers / processes 208 and 212, respectively, and grid agent 206 and application service instance A can communicate bidirectionally, as can grid agent 210 and application service instance B. Furthermore, grid agents 206 and 210 can also communicate bidirectionally.

[0051] In one implementation, all traffic from application service instance A is routed to the appropriate destination via mesh proxy 206, and all network traffic from application service instance B is routed to the appropriate destination via mesh proxy 210. It should be noted that the network traffic mentioned herein includes, but is not limited to, HTTP, REST, gRPC, Redis, and other similar formats.

[0052] In one implementation, the functionality of the extended data plane layer can be achieved by writing custom filters for the service mesh's envoy. The service mesh envoy configuration can enable the service mesh to correctly proxy service traffic, achieving service interoperability and service governance. Mesh envoys 206 and 210 can be configured to perform at least one of the following functions: service discovery, health checking, routing, load balancing, authentication and authorization, and observability.

[0053] like Figure 2 As shown, the service mesh also includes a control plane layer. This control plane layer can consist of a set of services running in a dedicated namespace, hosted by a managed control plane component 202 on machine / workload container groups (machine / Pod) 204. For example... Figure 2As shown, the managed control plane component 202 communicates bidirectionally with grid agents 206 and 210. The managed control plane component 202 is configured to perform various control and management functions. For example, it receives telemetry data transmitted from grid agents 206 and 210 and can further aggregate this telemetry data. In addition to these services, the managed control plane component 202 can also provide a user-facing application programming interface (API) to facilitate manipulation of network behavior and the provision of configuration data to grid agents 206 and 210.

[0054] Specifically, obtaining observability data of the target application workload in the initial node includes:

[0055] Obtain status data for at least one dimension of the target application workload in the initial node;

[0056] Analyzing the state data of at least one dimension yields observable data.

[0057] In practical applications, data obtained from a single dimension may be incomplete, thus missing some application workloads. Therefore, obtaining observable data of the target application workload from multiple dimensions can reduce the probability of application omissions.

[0058] For example, obtain log information from the email service and analyze the log information to obtain observable data of the email service.

[0059] Furthermore, obtaining state data for at least one dimension of the target application workload in the initial node includes:

[0060] Retrieve log dimension data of the target application workload from the log storage;

[0061] Obtain the monitoring dimension data of the target application workload from the monitoring dimension data storage;

[0062] Retrieve the tracking dimension data of the target application workload from the tracking dimension data store.

[0063] The log dimension data may include the service name and service namespace. Optionally, it may also include other types of information, such as the transmission port and transmission protocol. The monitoring dimension data may include the request time, the size of the response data corresponding to the request, and the data status of the response data (taking the data status involved in the payment function as an example, the data status involved in the payment function may include unpaid, successful payment, and failed payment status). Optionally, the monitoring dimension data may also include other types of metrics. This application does not limit the specific type of monitoring dimension data. The tracking dimension data can be understood as data generated based on the transmission path of the obtained request in the service mesh corresponding to the service mesh proxy.

[0064] In practical applications, see Figure 3 , Figure 3 This is a schematic diagram of an application workload scheduling method provided in one embodiment of this specification. Since the traffic of application workload 302 in each data plane is intercepted by the service mesh proxy 304, the service mesh proxy 304 can generate service access logs for each intercepted traffic. These logs are automatically collected into a log dimension data store by a log collection system. Because the traffic of application workload 302 is intercepted by the service mesh proxy 304, the service mesh proxy 304 can generate multiple monitoring metrics for service access, which are collected into a monitoring dimension data store by the monitoring system. By extracting tracing information (such as request IDs) from the access messages between services, request path tracing dimension data in the mesh can be generated for each service request, and this data can be automatically collected into the tracing dimension data store. Therefore, the corresponding data can be directly obtained from the corresponding storage; this data can be called observability data and can be collected by the observability data collector 306.

[0065] After obtaining the status data, observable data can be generated based on it. Since the status data can include at least one of log dimension data, monitoring dimension data, and tracing dimension data, determining the call relationships between services in the service mesh based on status data corresponding to at least one dimension can include at least one of the following implementation methods:

[0066] The process of analyzing the state data of at least one dimension to obtain observable data includes:

[0067] Dependency log information is obtained by analyzing the log dimension data according to preset rules;

[0068] Based on the identifier of the target application workload, the observability data is obtained by extracting the dependency log information.

[0069] In practical applications, see Figure 3 Log data analyzer 314 can use rules to find special logs (logs with information such as the requested service name, port, and protocol) generated by service mesh agent 304 that relate to accessing dependent services, and extract and generate observability data for each service from the special logs.

[0070] For example, based on the preset keywords "service" and "port number", search for dependency log information about all services in the logs, and then search for observability data of the email service from the dependency log information based on the keyword "email service".

[0071] Optionally, other types of information in the log dimension data can also be combined to determine the call relationships between services. Taking the log dimension data, which also includes transport ports and transport protocols, as an example, when determining the call relationships between various services in the service mesh based on the log dimension data as state data, at least one of the following implementation methods can also be used:

[0072] Based on log dimension data, services with the same service name, service namespace, and transmission port in the log dimension data are identified as services with a calling relationship.

[0073] Based on log dimension data, services with the same service name, service namespace, and transport protocol in the log dimension data are identified as services with a calling relationship.

[0074] It should be noted that the two methods mentioned above can also be used in combination. That is, in more possible implementations, services with the same service name, service namespace, transmission port and transmission protocol in the log dimension data can be identified as services with a calling relationship.

[0075] The embodiments in this specification determine the calling relationship by combining information such as the transmission port and transmission protocol. This allows for the integration of information from more perspectives to determine the calling relationship, thereby improving the accuracy of the determined calling relationship.

[0076] Furthermore, based on the monitoring dimension data, the similarity of the monitoring dimension data between any two services is determined, and services whose similarity meets the set conditions are identified as services with a calling relationship. The specific implementation method is as follows.

[0077] The process of analyzing the state data of at least one dimension to obtain observable data includes:

[0078] Determine the similarity between the preset monitoring metrics of the target application workload and the preset monitoring metrics of other application workloads;

[0079] The observability data is obtained based on a preset similarity threshold and the similarity.

[0080] The monitoring indicators may include the request time, the size of the response data corresponding to the request, and the data status of the response data (taking the data status involved in the payment function as an example, the data status involved in the payment function may include statuses such as unpaid, successful payment, and failed payment). Optionally, the monitoring indicators may also include other types of indicators, and this application does not limit the specific type of monitoring indicators. The similarity threshold can be any value, and this application does not limit the specific value of the similarity threshold.

[0081] In practical applications, see Figure 3 The monitoring data analyzer 316 can use one or more monitoring metrics for each service stored in the monitoring dimension data 310, calculate the similarity of the various monitoring metrics between services in the time series, and use the similarity to assess the likelihood of a dependency relationship between services.

[0082] Taking monitoring metrics including request time, the size of the response data corresponding to the request, and the status of the response data as an example, for any two services, the similarity of the monitoring data corresponding to any monitoring metric can be determined. Thus, if the determined similarity meets the target conditions, it can be determined that there is a calling relationship between the two services.

[0083] Furthermore, for any two services, the similarity of monitoring data corresponding to multiple monitoring indicators can be determined to obtain multiple similarities. Based on these multiple similarities, the similarity between the two services can be determined. If the determined similarity meets the target condition, a calling relationship between the two services can be determined. Optionally, when determining the similarity between two services based on multiple similarities, the average of these multiple similarities can be calculated, and the calculated average can be used as the similarity between the two services. Alternatively, other methods can be used to determine the similarity between two services based on multiple similarities; this application does not limit this approach.

[0084] Alternatively, tracing dimension data can be generated based on requests obtained from the service mesh proxy. For example, tracing information can be extracted from the obtained requests, and the transmission path of the obtained requests in the service mesh can be determined based on the extracted tracing information, and the determined transmission path can be used as tracing dimension data.

[0085] The process of analyzing the state data of at least one dimension to obtain observable data includes:

[0086] The tracking path is obtained by analyzing the tracking dimension data;

[0087] The observability data is obtained based on the tracing path.

[0088] In practical applications, see Figure 3 The tracking data analyzer 318, based on the tracking dimension data 312, identifies any two adjacent services in the transmission path indicated by the tracking dimension data 312 as services with a calling relationship.

[0089] For example, a request identifier (Identity Document, ID) can be used as tracking information. In addition, other types of data can also be used as tracking information. This application does not limit the specific type of tracking information.

[0090] It should be noted that the call relationship between various services in the service mesh can be determined based on the transmission path of a single request. Although the call relationship determined based on a single request is accurate, it may not be comprehensive. Therefore, the transmission paths of multiple requests in the service mesh can be collected to obtain a more comprehensive call relationship.

[0091] Through the above process, the call relationships of various services in the service mesh can be determined from three different dimensions. The above three methods can be used individually or based on any one of the above methods to determine the call relationships. In more possible implementations, the above three methods can also be used in combination, that is, any two or three of them can be used to determine the call relationships.

[0092] In some embodiments, when the runtime state data used to determine the call relationship corresponds to at least two dimensions, the determined call relationship is weighted and calculated to obtain the call relationship between the various services corresponding to the service mesh proxy.

[0093] In the weighted calculation of the determined call relationships, the weights of the call relationships determined based on different types of running status data can be determined based on the sampling rate and sampling time of different types of running status data. Optionally, other information can also be combined to determine the weights.

[0094] Taking the determination of the weight of the call relationship based on the sampling rate and sampling time of different types of running status data as an example, the product of the sampling rate and sampling time can be calculated, and the calculated product can be proportionally taken to determine the weight.

[0095] For example, if two types of runtime status data are used, and the product of the sampling rate and sampling time corresponding to these two types of runtime status data is 9 and 7 respectively, then these two values ​​can be proportionally calculated, and the sum of the proportions can be guaranteed to be 1. Thus, the weights of the call relationship determined based on these two types of runtime status data can be obtained as 0.5625 and 0.4375 respectively.

[0096] By combining the sampling rate and sampling time, the weights of the call relationships determined based on different dimensions of runtime status data can be realized. This ensures that the longer the sampling time and the higher the sampling rate, the greater the weight of the call relationship determined by the data. Furthermore, the longer the sampling time and the higher the sampling rate, the higher the accuracy of the data. As a result, the credibility of the call relationship obtained by weighted calculation is higher.

[0097] Step 104: Based on the observability data, determine the associated application workloads that the target application workload depends on from all nodes.

[0098] The related application workloads that the target application workload depends on can be understood as having a calling relationship between the target application workload and the related application workloads. For example, if service A calls service B, it can be said that service A depends on service B.

[0099] In practical applications, if service A is to be scheduled, it is necessary to determine not only the services that the target application workload A directly depends on, but also the services that the target application workload A indirectly depends on.

[0100] Specifically, determining the associated application workloads that the target application workload depends on from all nodes based on the observability data includes:

[0101] Based on the observability data, determine the directly related application workloads that the target application workload depends on from all nodes;

[0102] Based on the directly associated application workloads, at least one level of indirectly associated application workloads is determined.

[0103] In this context, directly related application workloads can be understood as services that the target application workload directly depends on, while indirectly related application workloads can be understood as services that the target application workload indirectly depends on. For example, if service A depends on service B, and service B depends on service C, then service B is called a directly related application workload, and service C is called an indirectly related application workload.

[0104] For example, see Figure 4 , Figure 4This is a schematic diagram of service dependencies of an application workload scheduling method provided in one embodiment of this specification. There are application workloads A, B, C, D, E, F, G, H, and I. The target application workload is A. Then the directly associated application workloads include D and C. D depends on F and G. Then the first-level indirectly associated application workloads are F and G. Correspondingly, G depends on I. Then the second-level indirectly associated application workload is I.

[0105] This specification describes an example of determining multi-level associated application workloads through the target application workload. Application workloads can be scheduled according to the hierarchical relationship to determine the scheduling relationship between all services in a link.

[0106] Step 106: Generate scheduling configuration data based on the dependency relationship between the target application workload and the associated application workload.

[0107] In this context, dependency can be understood as a calling relationship. For example, if service A calls service B, it can be said that service A depends on service B, and thus there is a dependency relationship between service A and service B.

[0108] In practical applications, determining the nodes to which the target application workload and related application workloads should be allocated based on the dependencies between them can minimize inter-server communication.

[0109] Specifically, generating scheduling configuration data based on the dependency relationship between the target application workload and the associated application workload includes:

[0110] Generate a dependency directed graph based on the dependency relationship between the target application workload and the associated application workload;

[0111] The dependent directed graph is segmented to obtain a dependent subgraph;

[0112] The scheduling configuration data is generated based on the dependency subgraph.

[0113] Among them, the dependent directed graph can be an acyclic directed graph, that is, an acyclic directed graph built according to the dependency relationships between application workloads.

[0114] In practical applications, see Figure 3The problem can be modeled as a graph partitioning and mapping problem using a graph partitioning engine 322. This problem generates a set of subgraphs 324 from an undirected graph 320 and maps each subgraph 324 to a cluster node. The resource requirements indicated by the vertex weights in the subgraphs 324 are satisfied, and the communication cost between different cluster nodes, represented by edge weights, is minimized. The generated subgraphs 324 are converted into executable application configuration data 328 (e.g., configuration scripts or templates) and enforced by the container platform orchestrator. Depending on the container platform, different methods can be used to implement this component; this specification does not limit the specific implementation.

[0115] For example, in Kubernetes, this component can be integrated with the control plane by modifying or replacing the default Kube Scheduler. Alternatively, this component can be kept independent and used to modify deployment manifest files with node (pod) affinity and anti-affinity rules, such as Deployment deployment YAML files.

[0116] Further, generating the scheduling configuration data based on the dependency subgraph includes:

[0117] The resource requirements of the target application workload and each associated application workload are determined based on the dependency subgraph.

[0118] Based on the resource requirements, determine the target node corresponding to the target application workload, and the target node corresponding to each associated application workload;

[0119] The scheduling configuration data is generated based on the target node corresponding to the target application workload and the target node corresponding to each associated application workload.

[0120] Resource requirements can refer to the hardware resource requirements, such as CPU utilization and memory utilization.

[0121] In practical applications, see Figure 3 The scheduling configuration updater 326 can consider the target application workload and the hardware resources required by each associated application workload to determine whether to allocate the same node or different nodes. For example, if service A depends on service B, and if the hardware resources of node P1 can run service A and service B, then scheduling configuration data 328 is generated to configure service A and service B on node P1.

[0122] Further, generating the scheduling configuration data based on the dependency subgraph includes:

[0123] The communication latency between the target application workload and the initial node corresponding to each associated application workload is determined based on the dependency subgraph.

[0124] The target node corresponding to the target application workload and the target node corresponding to each associated application workload are determined based on the communication latency.

[0125] The scheduling configuration data is generated based on the target node corresponding to the target application workload and the target node corresponding to each associated application workload.

[0126] In practical applications, the scheduling configuration updater 326 can also take into account the communication latency between nodes in order to allocate application workloads to the corresponding nodes. For example, if service A depends on service B and service A is on node P1, if the communication latency between node P1 and node P2 is minimal, then scheduling configuration data 328 is generated to configure service B on node P2.

[0127] The embodiments in this specification generate scheduling data based on the dependencies between application workloads and taking into account the communication latency between application workloads, thereby reducing the communication latency between application workloads with dependencies.

[0128] Step 108: Based on the scheduling configuration data, schedule the target application workload and the associated application workload to the corresponding target node.

[0129] In practical applications, see Figure 3 After the scheduler 330 obtains the scheduling configuration data 328, it can schedule the application workload according to the scheduling configuration data 328. When the scheduling configuration data 328 is the node affinity rule, the application workload needs to be scheduled according to affinity. The specific implementation method is as follows.

[0130] Specifically, scheduling the target application workload and the associated application workload to the corresponding target node according to the scheduling configuration data includes:

[0131] The target application workload and the associated application workload are determined based on the scheduling configuration data, along with their affinity with multiple nodes;

[0132] Based on the affinity, the target application workload and the associated application workload are scheduled to the corresponding target node.

[0133] For example, if service A depends on service B, and service A is on node P1, then relative to nodes P2 and P3, if node P1 has a high affinity with node P2 and a low affinity with node P3, then service B will be configured on node P2.

[0134] This specification provides an application workload scheduling method, which includes: acquiring observability data of a target application workload in an initial node; determining, based on the observability data, related application workloads that the target application workload depends on from all nodes; generating scheduling configuration data based on the dependency relationship between the target application workload and the related application workloads; and scheduling the target application workload and the related application workloads to corresponding target nodes based on the scheduling configuration data. By determining the related application workloads that the target application workload depends on from all nodes and generating scheduling configuration data based on the dependency relationship between application workloads to schedule the application workloads to the corresponding nodes, the communication latency between dependent application workloads is reduced because the dependency relationship between application workloads is taken into account during scheduling.

[0135] The following is in conjunction with the appendix Figure 5 Taking the application workload scheduling method provided in this specification as an example of its application on a server, the method will be further explained. Figure 5 The present specification illustrates a flowchart of an application workload scheduling method according to an embodiment, which includes the following steps.

[0136] Step 502: Retrieve log dimension data of the target application workload from the log store.

[0137] Step 504: Analyze the log dimension data according to preset rules to obtain dependency log information.

[0138] Step 506: Extract observability data from dependency log information based on the identifier of the target application workload.

[0139] Step 508: Based on the observability data, identify the associated application workloads that the target application workload depends on from all nodes.

[0140] Step 510: Generate a directed dependency graph based on the dependency relationship between the target application workload and related application workloads.

[0141] Step 512: Segment the dependent directed graph to obtain dependent subgraphs.

[0142] Step 514: Generate scheduling configuration data based on the dependency subgraph.

[0143] Step 516: Based on the scheduling configuration data, schedule the target application workload and associated application workload to the corresponding target node.

[0144] By identifying the associated application workloads that the target application workload depends on from all nodes, and generating scheduling configuration data based on the dependencies between application workloads to schedule the application workloads to the corresponding nodes, the communication latency between application workloads with dependencies is reduced because the dependencies between application workloads are taken into account during scheduling.

[0145] Corresponding to the above method embodiments, this specification also provides embodiments of application workload scheduling devices. Figure 6 A schematic diagram of an application workload scheduling device according to one embodiment of this specification is shown. Figure 6 As shown, the device includes:

[0146] The data acquisition module 602 is configured to acquire observability data of the target application workload in the initial node;

[0147] The relationship determination module 604 is configured to determine the associated application workloads that the target application workload depends on from all nodes based on the observability data.

[0148] The configuration generation module 606 is configured to generate scheduling configuration data based on the dependency relationship between the target application workload and the associated application workload.

[0149] The scheduling module 608 is configured to schedule the target application workload and the associated application workload to the corresponding target node according to the scheduling configuration data.

[0150] Furthermore, the data acquisition module 602 is also configured to:

[0151] Obtain status data for at least one dimension of the target application workload in the initial node;

[0152] Analyzing the state data of at least one dimension yields observable data.

[0153] Furthermore, the data acquisition module 602 is also configured to:

[0154] Retrieve log dimension data of the target application workload from the log storage;

[0155] Obtain the monitoring dimension data of the target application workload from the monitoring dimension data storage;

[0156] Retrieve the tracking dimension data of the target application workload from the tracking dimension data store.

[0157] Furthermore, the data acquisition module 602 is also configured to:

[0158] Dependency log information is obtained by analyzing the log dimension data according to preset rules;

[0159] Based on the identifier of the target application workload, the observability data is obtained by extracting the dependency log information.

[0160] Furthermore, the data acquisition module 602 is also configured to:

[0161] Determine the similarity between the preset monitoring metrics of the target application workload and the preset monitoring metrics of other application workloads;

[0162] The observability data is obtained based on a preset similarity threshold and the similarity.

[0163] Furthermore, the data acquisition module 602 is also configured to:

[0164] The tracking path is obtained by analyzing the tracking dimension data;

[0165] The observability data is obtained based on the tracing path.

[0166] Furthermore, the relationship determination module 602 is also configured to:

[0167] Based on the observability data, determine the directly related application workloads that the target application workload depends on from all nodes;

[0168] Based on the directly associated application workloads, at least one level of indirectly associated application workloads is determined.

[0169] Furthermore, the configuration generation module 606 is also configured to:

[0170] Generate a dependency directed graph based on the dependency relationship between the target application workload and the associated application workload;

[0171] The dependent directed graph is segmented to obtain a dependent subgraph;

[0172] The scheduling configuration data is generated based on the dependency subgraph.

[0173] Furthermore, the configuration generation module 606 is also configured to:

[0174] The resource requirements of the target application workload and each associated application workload are determined based on the dependency subgraph.

[0175] Based on the resource requirements, determine the target node corresponding to the target application workload, and the target node corresponding to each associated application workload;

[0176] The scheduling configuration data is generated based on the target node corresponding to the target application workload and the target node corresponding to each associated application workload.

[0177] Furthermore, the configuration generation module 606 is also configured to:

[0178] The communication latency between the target application workload and the initial node corresponding to each associated application workload is determined based on the dependency subgraph.

[0179] The target node corresponding to the target application workload and the target node corresponding to each associated application workload are determined based on the communication latency.

[0180] The scheduling configuration data is generated based on the target node corresponding to the target application workload and the target node corresponding to each associated application workload.

[0181] Furthermore, the scheduling module 608 is also configured to:

[0182] The target application workload and the associated application workload are determined based on the scheduling configuration data, along with their affinity with multiple nodes;

[0183] Based on the affinity, the target application workload and the associated application workload are scheduled to the corresponding target node.

[0184] This specification provides an application workload scheduling device. The device acquires observability data of a target application workload in an initial node. Based on the observability data, it determines the associated application workloads that the target application workload depends on from all nodes. Based on the dependency relationship between the target application workload and the associated application workloads, it generates scheduling configuration data. Based on the scheduling configuration data, it schedules the target application workload and the associated application workloads to their corresponding target nodes. By determining the associated application workloads that the target application workload depends on from all nodes and generating scheduling configuration data based on the dependency relationship between application workloads to schedule the application workloads to the appropriate nodes, the communication latency between dependent application workloads is reduced because the scheduling takes into account the dependency relationship between application workloads.

[0185] The above is an illustrative scheme of an application workload scheduling device according to this embodiment. It should be noted that the technical solution of this application workload scheduling device and the technical solution of the application workload scheduling method described above belong to the same concept. For details not described in detail in the technical solution of the application workload scheduling device, please refer to the description of the technical solution of the application workload scheduling method described above.

[0186] Figure 7 A structural block diagram of a computing device 700 according to one embodiment of this specification is shown. The components of the computing device 700 include, but are not limited to, a memory 710 and a processor 720. The processor 720 is connected to the memory 710 via a bus 730, and a database 750 is used to store data.

[0187] The computing device 700 also includes an access device 740, which enables the computing device 700 to communicate via one or more networks 760. Examples of these networks include a Public Switched Telephone Network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or a combination of communication networks such as the Internet. The access device 740 may include one or more of any type of wired or wireless network interface (e.g., a Network Interface Card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) interface, a Wi-MAX interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, a Near Field Communication (NFC) interface, and so on.

[0188] In one embodiment of this specification, the above-described components of the computing device 700 and Figure 7 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 7 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0189] The computing device 700 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or PCs. The computing device 700 can also be a mobile or stationary server.

[0190] The processor 720 is configured to execute the following computer-executable instructions, which, when executed by the processor, implement the steps of the above-described application workload scheduling method.

[0191] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the application workload scheduling method described above belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the application workload scheduling method described above.

[0192] An embodiment of this specification also provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the application workload scheduling method described above.

[0193] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium and the technical solution of the application workload scheduling method described above belong to the same concept. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the application workload scheduling method described above.

[0194] An embodiment of this specification also provides a computer program, wherein when the computer program is executed in a computer, it causes the computer to perform the steps of the application workload scheduling method described above.

[0195] The above is an illustrative example of a computer program according to this embodiment. It should be noted that the technical solution of this computer program and the technical solution of the application workload scheduling method described above belong to the same concept. Details not described in detail in the computer program's technical solution can be found in the description of the application workload scheduling method described above.

[0196] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0197] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or some intermediate form. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording media, USB flash drive, portable hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added to or subtracted according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

[0198] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments in this specification are not limited to the described order of actions, because according to the embodiments in this specification, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments in this specification.

[0199] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0200] The preferred embodiments disclosed above are merely illustrative of this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments described herein. These embodiments are selected and specifically described in this specification to better explain the principles and practical applications of the embodiments, thereby enabling those skilled in the art to better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. An application workload scheduling method applied to a service mesh, the service mesh including a mesh proxy and a managed control plane component, the mesh proxy corresponding to and coexisting with an application workload in a machine workload container, the mesh proxy communicating bidirectionally with the managed control plane component; the method comprising: The grid proxy intercepts traffic from target application workloads within the initial node of the same machine's workload container. It generates at least one dimension of state data for each intercepted traffic, analyzes this state data to obtain observability data, and transmits the observability data to the managed control plane component. Specifically, requests initiated to the target application workload are intercepted by the grid proxy and forwarded to the target application workload for processing. Requests between application workloads are first forwarded to the grid proxy, which then forwards them to the corresponding application workload. The managed control plane component determines the associated application workloads that the target application workload depends on from all nodes based on the observability data; generates scheduling configuration data based on the dependency relationship between the target application workload and the associated application workloads; and schedules the target application workload and the associated application workloads to the corresponding target nodes based on the scheduling configuration data.

2. The method according to claim 1, wherein analyzing the state data of the at least one dimension to obtain observable data includes: Obtain status data for at least one dimension of the target application workload in the initial node; Analyzing the state data of at least one dimension yields observable data.

3. The method according to claim 2, wherein obtaining state data of at least one dimension of the target application workload in the initial node includes: Retrieve log dimension data of the target application workload from the log storage; Obtain the monitoring dimension data of the target application workload from the monitoring dimension data storage; Retrieve the tracking dimension data of the target application workload from the tracking dimension data store.

4. The method according to claim 3, wherein analyzing the state data of the at least one dimension to obtain observable data includes: Dependency log information is obtained by analyzing the log dimension data according to preset rules; Based on the identifier of the target application workload, the observability data is obtained by extracting the dependency log information.

5. The method according to claim 3, wherein analyzing the state data of the at least one dimension to obtain observable data includes: Determine the similarity between the preset monitoring metrics of the target application workload and the preset monitoring metrics of other application workloads; The observability data is obtained based on a preset similarity threshold and the similarity.

6. The method according to claim 3, wherein analyzing the state data of the at least one dimension to obtain observable data includes: The tracking path is obtained by analyzing the tracking dimension data; The observability data is obtained based on the tracing path.

7. The method according to claim 1, wherein determining the associated application workloads to which the target application workload depends from all nodes based on the observability data comprises: Based on the observability data, determine the directly related application workloads that the target application workload depends on from all nodes; Based on the directly associated application workloads, at least one level of indirectly associated application workloads is determined.

8. The method according to claim 1, wherein generating scheduling configuration data based on the dependency relationship between the target application workload and the associated application workload includes: Generate a dependency directed graph based on the dependency relationship between the target application workload and the associated application workload; The dependent directed graph is segmented to obtain a dependent subgraph; The scheduling configuration data is generated based on the dependency subgraph.

9. The method according to claim 8, wherein generating the scheduling configuration data based on the dependency subgraph comprises: The resource requirements of the target application workload and each associated application workload are determined based on the dependency subgraph. Based on the resource requirements, determine the target node corresponding to the target application workload, and the target node corresponding to each associated application workload; The scheduling configuration data is generated based on the target node corresponding to the target application workload and the target node corresponding to each associated application workload.

10. The method according to claim 9, wherein generating the scheduling configuration data based on the dependency subgraph comprises: The communication latency between the target application workload and the initial node corresponding to each associated application workload is determined based on the dependency subgraph. The target node corresponding to the target application workload and the target node corresponding to each associated application workload are determined based on the communication latency. The scheduling configuration data is generated based on the target node corresponding to the target application workload and the target node corresponding to each associated application workload.

11. The method according to claim 1, wherein scheduling the target application workload and the associated application workload to the corresponding target node according to the scheduling configuration data comprises: The target application workload and the associated application workload are determined based on the scheduling configuration data, along with their affinity with multiple nodes; Based on the affinity, the target application workload and the associated application workload are scheduled to the corresponding target node.

12. An application workload scheduling apparatus applied to a service mesh, the service mesh including a mesh proxy and a managed control plane component, the mesh proxy corresponding to and coexisting with an application workload in a machine workload container, the mesh proxy communicating bidirectionally with the managed control plane component; the apparatus comprising: The grid proxy intercepts traffic from target application workloads within the initial node of the same machine's workload container. It generates at least one dimension of state data for each intercepted traffic, analyzes this state data to obtain observability data, and transmits the observability data to the managed control plane component. Specifically, requests initiated to the target application workload are intercepted by the grid proxy and forwarded to the target application workload for processing. Requests between application workloads are first forwarded to the grid proxy, which then forwards them to the corresponding application workload. The managed control plane component determines the associated application workloads that the target application workload depends on from all nodes based on the observability data. The configuration generation module is configured to generate scheduling configuration data based on the dependency relationship between the target application workload and the associated application workload. The scheduling module is configured to schedule the target application workload and the associated application workload to the corresponding target node according to the scheduling configuration data.

13. A computing device, comprising: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions, which, when executed by the processor, implement the steps of the application workload scheduling method according to any one of claims 1 to 11.

14. A computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the application workload scheduling method according to any one of claims 1 to 11.

Images