A hybrid scheduling system of a KVM virtualization-based FaaS platform

Abstract

The application discloses a hybrid scheduling system of a FaaS platform based on KVM virtualization, which is based on a lightweight user mode scheduling mechanism, and realizes task scheduling and dynamic load balancing through the cooperative work of four core modules, i.e., a pre-execution processor, a task detector, a task distributor and a load balancer. The pre-execution processor analyzes the hybrid execution time of different task types under different scheduling methods, and provides data support for scheduling decisions; the task detector monitors the submitted tasks in the system in real time and judges the task types; the task distributor makes a distribution decision in combination with pre-processing information, task characteristics and real-time load proportion; and the load balancer ensures the load balancing between scheduling sets through real-time load monitoring, and avoids the overload of single-core sets. The application can reduce the average execution time of tasks of the FaaS platform in a high-concurrency scenario, improve the resource utilization rate and task execution efficiency, and provides an efficient and reliable solution for serverless computing task scheduling.

Description

Technical Field

[0001] The present invention belongs to the technical field of software development, and in particular relates to a hybrid scheduling system for a FaaS platform based on KVM virtualization. Background Art

[0002] Serverless computing has garnered widespread attention and adoption, particularly in the fields of distributed computing and cloud services, due to its highly simplified resource management and powerful computing capabilities. Function as a Service, a key model in serverless computing, allows developers to deploy single-function applications in a fully decoupled environment without having to worry about managing and maintaining the underlying servers. The serverless computing model significantly simplifies the complexity of application deployment and management, allowing developers to focus on implementing business logic, thereby improving overall development efficiency. However, with the widespread use of FaaS platforms such as AWS Lambda, Google Cloud Functions, and Microsoft Azure Functions, these platforms often struggle to maintain optimal execution efficiency when executing highly concurrent function instances. This results in decreased application performance, increased tail latency, and longer execution times, directly increasing user service costs.

[0003] Taking Firecracker, a commonly used FaaS computing platform, as an example, Firecracker allows thousands of short-lived function instances to execute simultaneously on a bare metal server with just 96 CPU cores, meaning a single physical core can manage hundreds of concurrent tasks. FaaS functions typically execute in milliseconds to seconds, with approximately half taking around one second. It uses kernel-based virtual machines (KVMs) to provide virtual CPUs to isolated user environments for task execution. Firecracker uses the default Linux Completely Fair Scheduler (CFS) algorithm. However, short tasks predominate in FaaS computing, and CFS is not optimized for FaaS computing, which inflates the overall average execution time of tasks on the platform. Furthermore, the Linux CFS scheduler, being insensitive to workloads, frequently performs context switches, resulting in excessive wait times for short functions. This, in turn, causes turnaround times far exceeding actual service times, leading to excessive charges for users by the cloud. Therefore, there is an urgent need for a more flexible and customizable scheduling strategy to improve FaaS computing performance.

[0004] Compared to Linux kernel scheduling, user-space scheduling overcomes the inherent flaws of kernel-space scheduling by granting scheduling authority directly to user space. Compared to kernel-space scheduling, user-space schedulers are typically implemented by applications or thread libraries. Context switching typically only requires saving and restoring user-space context (such as register state) and does not involve kernel-level information such as CPU state and memory management. User-space scheduling is performed in user-level space, eliminating the need to switch to kernel mode every time. This avoids mode switching and the overhead of numerous system calls, thereby reducing switching overhead. User-space scheduling offers significant breakthroughs in adaptability and performance, helping to improve the efficiency of advanced applications such as FaaS computing. FaaS platforms that utilize lightweight virtualization technologies such as Firecracker can achieve high concurrency on a single node.

[0005] In summary, the completely fair scheduling provided by the Linux kernel is not suitable for high-concurrency scenarios with multiple short tasks, limiting the overall task execution efficiency of the FaaS platform. Therefore, a user-mode scheduler is needed to improve resource utilization and task execution efficiency by adapting to changing task characteristics, thereby meeting the performance requirements of the FaaS platform in high-concurrency environments. Summary of the Invention

[0006] The purpose of this invention is to provide a hybrid scheduling system for the FaaS platform based on KVM virtualization, aiming to improve the resource utilization and task execution efficiency of the FaaS platform in a high-concurrency environment and meet the real-time changing task feature requirements.

[0007] The specific technical solution for achieving the purpose of the present invention is:

[0008] A hybrid scheduling system for a FaaS platform based on KVM virtualization, the system comprising: a pre-execution processor, a task detector, a task dispatcher, and a load balancer;

[0009] The pre-processing executor applies different user-state scheduling algorithms on a single physical machine based on the existing user-state scheduling system, collects execution time information of each task under each user-state scheduling algorithm, divides task types according to the resource intensity of the tasks and sets different proportional skews for the number of each task in the pre-processing stage, executes the divided multiple tasks under different user-state scheduling algorithms, and collects execution time result information of each task under different proportional skews of different user-state schedulers, thereby providing execution time data for subsequent real-time task scheduling of the task dispatcher;

[0010] The task detector is configured for monitoring a newly submitted task request in the system in real time, judging resource intensity of a current task, and determining whether the current task has been executed in the platform. If the current task has been executed in the FaaS platform, the resource intensity of the current task is obtained according to recorded information in the preprocessing executor, and the current task is subsequently distributed to a corresponding optimal user mode scheduling set. If the current task has not been executed in the FaaS platform, the task is directly distributed to a Linux default CFS scheduling set. The task detector reads IO information, Mem information and CPU information of the current task by combining a metrics.fifo pipeline in Firecracker, classifies the current task according to a task type classification in the preprocessing executor, and records a specific classification category, thereby providing classification support for task distribution of a subsequent task distributor. Meanwhile, a globally unique task ID and a submission timestamp are assigned.

[0011] The preprocessing executor and the task detector implement task submission.

[0012] The task distributor implements real-time task distribution. According to the current task type recorded in the task detector and real-time task information of each set recorded in a real-time task proportion monitoring module in each set, the current task is added to a corresponding core in sequence, and an optimal value is obtained by referring to execution time results under different task proportions recorded in the preprocessing executor, thereby performing actual task allocation. Once the task is allocated to a specified scheduling set, execution time information, an allocated process identifier and scheduling set information in a structure are updated.

[0013] The load balancer is responsible for recording end times of each executed task distributed by the task distributor, calculating execution time of each task by calculating a difference between the end time and a start time of the task, calculating average execution time of each scheduling set in a current time window by counting all execution times in the current time window of each scheduling set, and providing data support for dynamic adjustment of the scheduling set. The average execution time of all sets is calculated, the size of a set exceeding the average execution time is increased, and the size of a set with a small average execution time is reduced, thereby realizing dynamic scaling of the set and preventing overload of a single set.

[0014] Further, the existing user mode scheduling system applies different user mode scheduling algorithms to a single physical machine. Specifically, the existing user mode scheduling system has the ability to divide processor cores in intervals on a single physical machine through centralized scheduling, and can apply different user mode scheduling algorithms to each core set, that is, multiple user mode scheduling algorithms coexist globally. Different user mode scheduling algorithms are executed in different sets by dividing multiple sets.

[0015] Furthermore, the data structure of the current task includes: a globally unique task identifier for uniquely identifying each task; a submission timestamp for recording the time of task submission; an execution time and an end time for tracking the execution cycle of the task; a process identifier for identifying the specific process of task execution; a predefined task type identification for classification according to task type; a scheduling set identifier for indicating the core set to which the current task belongs; when the task detector detects the currently submitted task, it assigns a task identifier to the current task and records the task timestamp and task type.

[0016] Furthermore, the real-time task ratio monitoring module in each set records the number of tasks being executed in each core set in the corresponding time window, monitors the number ratio of tasks of different task types, and is used to calculate the execution time result after adding the current task to be assigned to each core, providing real-time scheduling data support for task dispatcher scheduling.

[0017] The hybrid scheduling system proposed in this paper can flexibly adjust resource allocation and scheduling strategies in a high-concurrency environment based on the dynamic changes in task characteristics. The pre-execution processor collects historical task execution data and uses the cosine similarity algorithm to match the optimal scheduling strategy, improving task execution efficiency. The task detector identifies the resource requirements of new tasks in real time, and the task dispatcher combines real-time load information to achieve dynamic and balanced task allocation. The load balancer supports the system's dynamic scalability by monitoring and adjusting the load of core clusters, preventing overload of a single cluster and ensuring overall system stability.

[0018] The present invention reduces the average execution time of tasks on existing FaaS platforms in high-concurrency, multi-tasking environments and alleviates the problem of excessive user charges on the platform. It provides a flexible and efficient adaptive scheduling solution with good practical value and application prospects. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 This is a diagram of the overall architecture of hybrid scheduling according to an embodiment of the present invention;

[0020] Figure 2 This is a distribution diagram of a user-mode scheduling processor core set according to an embodiment of the present invention;

[0021] Figure 3 is a classification diagram of pre-execution tasks according to an embodiment of the present invention;

[0022] Figure 4 This is a real-time task classification detection diagram according to an embodiment of the present invention;

[0023] Figure 5 is a real-time task request queue scheduling diagram according to an embodiment of the present invention;

[0024] Figure 6 is a real-time task set interval dynamic adjustment diagram of an embodiment of the present application. DETAILED DESCRIPTION

[0025] The specific implementation of a KVM virtualization-based FaaS platform hybrid scheduling system will be described in detail below. This implementation aims to demonstrate how the system modules work together to achieve efficient task scheduling and set adjustment through a specific execution process.

[0026] The system of the present application works as follows, the process of which includes the following steps:

[0027] Task submission: In the task submission phase, the system sets up a pre-execution processor and a task detector. The pre-execution processor S101: is used to collect the execution results of multiple task types under different user-mode scheduling algorithms before task execution. By analyzing the execution performance of different tasks under different proportional skew, the optimal scheduling strategy is formed to provide data support for subsequent scheduling decisions.

[0028] Task detector: responsible for real-time monitoring of newly submitted task requests, identifying task types, and assigning each task a globally unique task ID and submission timestamp. For tasks that have been executed on the platform, directly obtain their resource-intensive properties according to the information recorded in the pre-execution processor, and assign them to the corresponding optimal user-mode scheduling set. If the task is submitted for the first time, it is initially assigned to the Linux default CFS scheduling set; by combining the metrics.fifo pipe of Firecracker, read the CPU, memory, I / O and other resource usage information of the task, and combine the task type classification basis in the pre-execution processor to classify and record the task.

[0029] Task execution: In the task execution phase, the system contains a task distributor. Task distributor: according to the optimal scheduling strategy provided by the pre-execution processor, the task type identified by the task detector, and the real-time load of each core set, make real-time task distribution decisions. Through dynamic allocation of tasks, balanced allocation of tasks is achieved, improving resource utilization and task execution efficiency. Once the task is assigned to the designated scheduling set, the task distributor will update the execution time, process identifier and scheduling set in the task structure, ensuring the accuracy of task scheduling.

[0030] Collection Adjustment: During the collection adjustment phase, the system includes a load balancer. The load balancer continuously monitors the load of each core collection and records the execution time of each task. By calculating the execution time of tasks and counting the average execution time of each scheduling collection within the current time window, it provides data support for the dynamic adjustment of scheduling collections. Based on the average execution time of different collections, the collection size is dynamically adjusted, increasing resources for collections with long average execution times and reducing resources for collections with short average execution times, thus achieving elastic resource scaling. By balancing the load between scheduling collections, overload of individual collections is prevented, ensuring system stability and reliability.

[0031] Example

[0032] This embodiment is a hybrid scheduling system based on the KVM virtualized FaaS platform. The system block diagram is shown in Figure 1 In the figure, M is the real-time task ratio monitoring module. The system is based on a lightweight user-mode scheduling mechanism. Figure 2 This mechanism allows core intervals to be divided into multiple sets, with each set exclusively utilizing a user-mode scheduling method. This supports the use of different scheduling algorithms on different physical cores, meaning that multiple global user-mode scheduling algorithms can coexist. By dividing the system into multiple sets, different user-mode scheduling algorithms can be executed in different sets. The system primarily comprises four core components: a pre-execution processor, a task detector, a task dispatcher, and a load balancer. The pre-execution processor pre-executes multiple task types before real-time tasks are executed, analyzing the execution results of each task under different scheduling methods. The collected information matches the optimal scheduling strategy, providing data support for subsequent scheduling decisions. The task detector monitors newly submitted task requests in real time, identifies task types, and assigns globally unique task IDs and submission timestamps to support subsequent task dispatch. The task dispatcher makes real-time task dispatch decisions based on pre-processing information, task characteristics, and the real-time task load ratio, enabling dynamic task allocation. The load balancer continuously monitors the load of each core set to ensure load balancing across scheduling sets, supporting dynamic resource scaling, preventing overload on a single set, and ensuring overall stability and reliability.

[0033] The pre-processing executor sets multiple task types at different skew ratios before the real-time task is executed, and collects the execution time results of each task under multiple user-mode scheduling algorithms. Figure 3In the task pre-execution phase, specific tasks are divided into the service-free platform, and the resource usage information and execution time results of the executed tasks are recorded in metrics.fifo. The specific task division in this phase includes division of known task types, division of multiple tasks with different proportional skew at the same concurrency, and execution of different combinations under different user state schedulers, and the actual execution time of each task is recorded. The resource usage information during the execution of known type tasks is recorded through metrics.fifo, which provides data support for the division of subsequent real-time tasks. The statistical time results and task type division information are all statistical in the pre-execution data.

[0034] The task detector is configured to determine the resource intensity of the real-time task, see Figure 4 By using the characteristics of the service-free platform, the executed tasks are recorded by the platform, and by checking whether the current submitted task has been executed in the platform, the real-time task can be quickly classified according to the pre-execution data. If the current task has been executed in the FaaS platform, the resource intensity of the current task is directly obtained according to the recorded information in the preprocessor; if the current task has not been executed in the FaaS platform, the task is directly distributed to the CFS scheduling set of the Linux default, and the task detector reads the IO information, Mem information and CPU information of the current task by combining the metrics.fifo pipeline in Firecracker, and classifies the current task according to the task type classification basis in the preprocessor to obtain the classification result of the current task. This process involves data structure updating. The data structure includes: a globally unique task identifier for uniquely identifying each task; a submission timestamp for recording the time of task submission; an execution time and an end time for tracking the execution period of the task; a process identifier for identifying the specific process of task execution; a predefined task type identification for classification according to the task type; and a scheduling set identifier for indicating the core set to which the current task belongs. When the task detector detects the current submitted task, the task identifier is assigned to the current task, and the task timestamp and task type are recorded.

[0035] The task distributor, see Figure 5 The task distributor determines the current task type recorded in the task detector, and monitors the real-time task proportion module M (see Figure 1The system monitors the number of real-time tasks in each core set within the time window and aggregates them to derive the ratio of tasks to all queues. It then calculates the ratio of tasks in each set after adding the current task to the corresponding core interval. Using cosine similarity, it matches the optimal execution times for various task ratios recorded in the preprocessor to quickly obtain the optimal execution time for the current task in each set. It then finds the minimum of the optimal times obtained in each set and assigns it to the execution interval queue, where it awaits scheduling by the user-mode scheduling algorithm within that set. Once a task is assigned to a specified scheduling set, the execution time information, assigned process identifier, and scheduling set information in the structure are updated.

[0036] The load balancer, see Figure 6 The load balancer records the end time of each completed task, and calculates the specific execution time of each task in the platform by calculating the difference between the task end time and the task start time. By counting the total execution time of the current time window of each scheduling set, the average execution time of each scheduling set in the current time window is calculated. The load balancer compares the maximum difference in the set average time with the set interval adjustment threshold. If the maximum difference exceeds the adjustment threshold, it means that the cost of the adjustment interval can be compensated after adjusting the set interval, and the overall set interval is redistributed according to the proportion of the average execution time of each set. If it does not exceed, the original interval allocation is used for execution. By unifying the average execution time of tasks in all sets, increasing the number of cores of sets with long average execution time, and reducing the size of sets with small average execution time, dynamic scaling of sets can be achieved.

Claims

1. A hybrid scheduling system for a FaaS platform based on KVM virtualization, characterized in that: The system includes: a pre-execution processor, a task detector, a task distributor, and a load balancer; The pre-execution processor applies different user-state scheduling algorithms on a single physical machine based on the existing user-state scheduling system, collects execution time information of each task under each user-state scheduling algorithm, divides task types according to the resource intensity of the tasks and sets different proportional skews for the number of each task in the pre-processing stage, executes the divided multiple tasks under different user-state scheduling algorithms, and calculates the execution time result information of each task under different proportional skews of different user-state schedulers, thereby providing execution time data for subsequent real-time task scheduling of the task dispatcher; The task detector is used to monitor newly submitted task requests in the system in real time and determine the resource intensity of the current task. It checks whether the currently submitted task has been executed on the platform. If the current task has been executed on the FaaS platform, it directly obtains the resource intensity of the current task based on the information recorded in the pre-processing executor and subsequently distributes it to the corresponding optimal user-mode scheduling set. If the current task has not been executed on the FaaS platform, it directly distributes the task to the Linux default CFS scheduling set. The task detector reads the IO information, Mem information, and CPU information of the current task by combining the metrics.fifo pipeline in Firecracker, and classifies the current task based on the task type classification basis in the pre-processing executor. It also records its specific classification category to provide classification support for subsequent task distribution by the task distributor; at the same time, it assigns a globally unique task ID and submission timestamp, where: The pre-execution processor and task detector implement task submission; The task dispatcher implements real-time task dispatching. Based on the current task type recorded in the task detector and the real-time task information in each set recorded in the real-time task ratio monitoring module in each set, the task dispatcher calculates the optimal value after adding the current task to the corresponding core in sequence, and then performs actual task dispatching according to the execution time results under different task ratios recorded in the pre-processing executor. Once the task is assigned to the specified scheduling set, the execution time information, the assigned process identifier, and the scheduling set information in the structure are updated. The load balancer is responsible for recording the end time of each completed task distributed by the task distributor, and calculating the specific execution time of each task by calculating the difference between the task end time and the task start time; by counting the total execution time of the current time window of each scheduling set, calculating the average execution time of each scheduling set in the current time window, providing data support for the dynamic adjustment of the scheduling set; averaging the execution time of tasks in all sets, increasing the size of sets that exceed the average execution time, and reducing the size of sets with a small average execution time, thereby realizing dynamic scaling of sets and preventing overload of single sets.

2. The hybrid scheduling system of the FaaS platform based on KVM virtualization according to claim 1 is characterized in that: The existing user-state scheduling system applies different user-state scheduling algorithms on a single physical machine. Specifically, the existing user-state scheduling system has the ability to partition processor cores on a single physical machine through centralized scheduling, and can apply different user-state scheduling algorithms to each core set, that is, to achieve global coexistence of multiple user-state scheduling algorithms; by dividing into multiple sets, different user-state scheduling algorithms are executed in different sets.

3. The hybrid scheduling system of the FaaS platform based on KVM virtualization according to claim 1 is characterized in that: The data structure of the current task includes: a globally unique task identifier for uniquely identifying each task; a submission timestamp for recording the time of task submission; an execution time and an end time for tracking the execution cycle of the task; a process identifier for identifying the specific process of task execution; a predefined task type identification for classifying according to task type; a scheduling set identifier for indicating the core set to which the current task belongs; when the task detector detects the currently submitted task, it assigns a task identifier to the current task and records the task timestamp and task type.

4. The hybrid scheduling system of the FaaS platform based on KVM virtualization according to claim 1, characterized in that: The real-time task ratio monitoring module in each set records the number of tasks being executed in each core set in the corresponding time window, monitors the ratio of the number of tasks of different task types, and is used to calculate the execution time result after the current task to be assigned is added to each core, providing real-time scheduling data support for task dispatcher scheduling.

Images