Resource scheduling method for desktop cloud environment and related equipment

Abstract

The invention discloses a resource scheduling method for a desktop cloud environment and related equipment, and aims to solve the problem that links such as real-time resource state perception, virtual desktop priority differentiation, system load scene adaptation and data migration cost consideration are difficult to collaboratively optimize due to insufficient comprehensive adaptability of resource scheduling in an existing desktop cloud environment. Therefore, the technical problems of mismatching between resource allocation and actual demands, low resource utilization rate, poor system stability and poor user experience are solved.

Description

Technical Field

[0001] This application relates to the field of data processing, and in particular to a resource scheduling method and related equipment for a desktop cloud environment. Background Technology

[0002] In desktop cloud environments, with the increasing number of virtual desktops and the growing diversity of user needs, the rationality and efficiency of resource scheduling become particularly important. This is because the quality of resource scheduling directly determines the overall performance of the system and the user experience. Inappropriate resource scheduling may result in some virtual desktops not receiving sufficient resources, thus affecting their operating speed and stability.

[0003] Therefore, the design and optimization of resource scheduling mechanisms are particularly important in desktop cloud environments. This requires comprehensive consideration of multiple factors, such as the number of virtual desktops, the diversity of user needs, and the availability of system resources.

[0004] In view of the above, this application is hereby submitted. Summary of the Invention

[0005] The purpose of this application is to propose a resource scheduling method and related equipment for a desktop cloud environment, in order to solve the technical problems of insufficient comprehensive adaptability of resource scheduling in the existing desktop cloud environment, difficulty in coordinating and optimizing real-time resource status perception, virtual desktop priority differentiation, system load scenario adaptation and data migration cost consideration, resulting in mismatch between resource allocation and actual needs, low resource utilization, poor system stability and user experience.

[0006] To address the aforementioned technical problems, this application provides a resource scheduling method for a desktop cloud environment, employing the following technical solution: A resource scheduling method for a desktop cloud environment includes the following steps: Real-time acquisition of basic resource data and virtual desktop feature data; generation of server resource status data and virtual desktop status data. Based on the virtual desktop status data, the priority of each virtual desktop is determined, and a priority sorting table is generated; Based on the server resource status data and the priority sorting table, a preliminary resource allocation plan is generated, and a feasible resource allocation plan is obtained by filtering the preliminary resource allocation plan. Based on the server resource status data, the system load scenario is determined, and based on the load scenario and the feasible resource allocation scheme, a scheduling scheme is generated. Based on the scheduling scheme, the data migration cost is determined, and a migration decision is generated based on the data migration cost. Based on the migration decision, the server resource status data, and the virtual desktop status data, the matching degree between the virtual desktop and the server is determined. Based on the matching degree, the server allocated to each virtual desktop is determined, and the hardware resources of the corresponding server are allocated to each virtual desktop.

[0007] Furthermore, the step of determining the priority of each virtual desktop based on the virtual desktop status data and generating a priority ranking table includes: Extract the user level and business urgency of each virtual desktop from the server resource status data and virtual desktop status data; The user level and the business urgency are quantified and assigned values ​​to obtain the quantified values ​​of the user level and the business urgency. The priority of each virtual desktop is determined based on the user level quantification value and the business urgency quantification value. All virtual desktops are sorted in descending order of priority to generate the priority sorting table.

[0008] Furthermore, the step of screening the preliminary resource allocation scheme to obtain a feasible resource allocation scheme includes: Based on the server resource status data, the preliminary resource allocation schemes that have reached the preset utilization threshold of the target server resources or that do not match the requirements of the server hardware and the virtual desktop are screened out and eliminated. The preliminary resource allocation schemes after screening and elimination are taken as the feasible resource allocation schemes.

[0009] Furthermore, the server resource status data includes server resource utilization metrics and the number of virtual desktop connections; The step of determining the system load scenario based on the server resource status data, and generating a scheduling scheme based on the load scenario and the feasible resource allocation scheme, includes: The system load scenario is determined based on the resource utilization rate index and the number of connections, wherein the system load scenario includes a high load scenario and a stable load scenario. The feasible resource allocation scheme is adjusted according to the system load scenario to generate the scheduling scheme.

[0010] Furthermore, determining the data migration cost based on the scheduling scheme and generating a migration decision based on the data migration cost includes: Extract the data migration parameters from the scheduling scheme; The data migration cost is determined based on the aforementioned data migration parameters; A migration decision is generated based on the comparison between the data migration cost and the preset cost threshold.

[0011] Furthermore, the step of determining the matching degree between virtual desktops and servers based on the migration decision, the server resource status data, and the virtual desktop status data, determining the server allocated to each virtual desktop based on the matching degree, and allocating corresponding server hardware resources to each virtual desktop includes: Based on the virtual desktop status data and the server resource status data, the matching degree between the virtual desktop and the server is determined; Based on the migration decision, candidate servers are selected from multiple servers; Based on the matching degree, the allocation association between each virtual desktop and the candidate server is determined; Based on the allocation association, the server assigned to each virtual desktop is determined, and the hardware resources of the corresponding server are allocated to each virtual desktop.

[0012] Furthermore, the step of selecting candidate servers from the servers based on the migration decision includes: If the migration decision is to perform a migration, then the target server specified in the scheduling scheme is selected as the candidate server; If the migration decision is to reject the migration, then the server where each virtual desktop is currently located is selected as the candidate server.

[0013] A resource scheduling system for a desktop cloud environment, used to execute the resource scheduling method for the desktop cloud environment, comprising: The data acquisition module is used to acquire basic resource data and virtual desktop status data in real time, and generate server resource status data and virtual desktop status data. The priority determination module is used to determine the priority of each virtual desktop based on the virtual desktop status data and generate a priority sorting table. The feasible solution generation module is used to generate a preliminary resource allocation plan based on the server resource status data and the priority sorting table, and to filter the preliminary resource allocation plan to obtain a feasible resource allocation plan. The scheduling scheme generation module is used to determine the system load scenario based on the server resource status data, and generate a scheduling scheme based on the load scenario and the feasible resource allocation scheme. A migration decision generation module is used to determine the data migration cost based on the scheduling scheme, and generate a migration decision based on the data migration cost; The final solution generation module is used to determine the matching degree between the virtual desktop and the server based on the migration decision, the server resource status data, and the virtual desktop status data. Based on the matching degree, a server is assigned to each virtual desktop, and hardware resources of the corresponding server are allocated to each virtual desktop.

[0014] A computer device includes a memory and a processor, the memory storing computer-readable instructions, wherein the processor, when executing the computer-readable instructions, implements the steps of the resource scheduling method for a desktop cloud environment as described above.

[0015] A computer-readable storage medium storing computer-readable instructions, which, when executed by a processor, implement the steps of the resource scheduling method for a desktop cloud environment as described above.

[0016] Compared with the prior art, the embodiments of this application have the following main advantages: The resource scheduling method and related equipment for a desktop cloud environment disclosed in this application generate corresponding status data by acquiring basic resource data and virtual desktop status data in real time, providing accurate real-time basis for resource scheduling; determine priorities based on virtual desktop status data and generate a sorting table to ensure that resource allocation is tilted towards high-priority needs; generate preliminary plans by combining server resource status and priority sorting, and screen out feasible plans, eliminating unreasonable allocations to ensure basic adaptability; determine system load scenarios based on server resource status and adjust feasible plans accordingly to generate a scheduling plan, making the scheduling strategy adaptable to load changes; determine data migration costs based on the scheduling plan and generate migration decisions to avoid resource waste caused by ineffective migrations; finally, combine migration decisions, resource status, and feature data to determine the matching degree between virtual desktops and servers and generate a final allocation plan to achieve accurate resource matching. The above steps work together to effectively improve the rationality and efficiency of resource scheduling in the desktop cloud environment, making resource allocation more in line with actual needs, improving resource utilization, enhancing system stability, and improving user experience. Attached Figure Description

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

[0018] Figure 1 This is an exemplary system architecture diagram to which this application can be applied; Figure 2 This is a flowchart of an embodiment of the resource scheduling method for a desktop cloud environment according to this application; Figure 3This is a schematic diagram of the structure of an embodiment of the resource scheduling system for a desktop cloud environment according to this application; Figure 4 This is a schematic diagram of the structure of one embodiment of the computer device according to this application. Detailed Implementation

[0019] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein in the specification of the application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application; the terms "comprising" and "having," and any variations thereof, in the specification, claims, and foregoing drawings of this application, are intended to cover non-exclusive inclusion. The terms "first," "second," etc., in the specification, claims, or foregoing drawings of this application are used to distinguish different objects, not to describe a particular order.

[0020] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0021] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.

[0022] like Figure 1 As shown, system architecture 100 may include terminal devices 101, 102, and 103, a network 104, and a server 105. Network 104 serves as the medium for providing communication links between terminal devices 101, 102, and 103 and server 105. Network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0023] Users can use terminal devices 101, 102, and 103 to interact with server 105 via network 104 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 101, 102, and 103, such as web browser applications, shopping applications, search applications, instant messaging tools, email clients, social media platform software, etc.

[0024] Terminal devices 101, 102, and 103 can be various electronic devices with displays and support web browsing, including but not limited to smartphones, tablets, e-book readers, MP3 (Moving Picture Experts Group Audio Layer III) players, MP4 (Moving Picture Experts Group Audio Layer IV) players, laptops, and desktop computers, etc.

[0025] Server 105 can be a server that provides various services, such as a backend server that supports the pages displayed on terminal devices 101, 102, and 103.

[0026] It should be noted that the resource scheduling method for the desktop cloud environment provided in this application embodiment is generally executed by the server, and correspondingly, the resource scheduling system for the desktop cloud environment is generally set up in the server.

[0027] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0028] Continue to refer to Figure 2 The diagram illustrates a flowchart of an embodiment of a resource scheduling method for a desktop cloud environment according to this application. The resource scheduling method for the desktop cloud environment includes the following steps: Step S1: Acquire basic resource data and virtual desktop status data in real time, and generate server resource status data and virtual desktop status data.

[0029] In this embodiment, the resource scheduling method of the desktop cloud environment runs on the electronic devices (e.g., Figure 1 The server shown can send or receive data via wired or wireless connections. It should be noted that the aforementioned wireless connection methods may include, but are not limited to, 3G / 4G / 5G connections, WiFi connections, Bluetooth connections, WiMAX connections, Zigbee connections, UWB (ultra wideband) connections, and other currently known or future known wireless connection methods.

[0030] In this embodiment, basic resource data refers to real-time metrics of server hardware operation, including but not limited to: CPU utilization (sampling granularity of 1 second), memory usage, GPU load (including video memory usage), network send / receive rate (unit: Gbps), storage IOPS and latency (unit: ms). Virtual desktop feature data refers to the attribute information of virtual desktops, including: desktop ID, business type (such as "design", "office", "video"), user level (such as "VIP", "normal", "temporary"), business urgency (such as "urgent", "normal", "low"), and resource requirement baseline (such as design desktops require ≥8GB of GPU memory). Server resource status data is the result of organizing basic resource data, and its format is [server IP, timestamp, CPU utilization, memory usage, GPU load, network speed, storage IOPS, storage latency]. For example: "Server_01,2025-08-0909:00:00,75%,60%,30%,2Gbps,10000,10ms"; Virtual desktop status data is a structured record of virtual desktop characteristics, in the format of [Desktop ID, Business Type, User Level, Business Urgency, CPU Requirement Baseline, GPU Requirement Baseline], for example "Desktop_001, Design, VIP, Urgent, 4 Cores, 12GB".

[0031] In summary, the specific example of this step is as follows: by deploying a monitoring agent program on the server cluster and embedding a data collection plugin in the virtual desktop, data is collected in real time with a sampling granularity of 1 second: The monitoring agent collects hardware metrics such as CPU utilization and memory usage of the server, and after cleaning (removing outliers), it summarizes them in the format of "server IP + timestamp + metric value". The data acquisition plugin records the business type, user level, and other characteristics of the virtual desktop, and combines them with the preset resource requirement baseline (such as the GPU requirement of the design desktop) to organize them into structured data; Ultimately, two types of standardized datasets are generated: server resource status data (reflecting real-time hardware load) and virtual desktop status data (reflecting desktop attributes and requirements).

[0032] Step S2: Based on the virtual desktop status data, determine the priority of each virtual desktop and generate a priority sorting table.

[0033] In this embodiment, priority refers to the degree of priority of virtual desktops in resource allocation, which is determined comprehensively based on key indicators in virtual desktop status data (such as user level, business urgency, etc.). For example, design-oriented desktops require GPU resources and are used when business is urgent, so they have a higher priority than regular office desktops; VIP users' desktops have a higher priority than those of temporary users. The priority sorting table is a list of virtual desktops arranged from highest to lowest priority, in the format of [Desktop ID, priority score], for example, "Desktop_001 (90 points) → Desktop_002 (85 points) → ... → Desktop_500 (30 points)".

[0034] Specifically, the following is an example of generating a priority ranking table: the scheduling system extracts the "user level" and "business urgency" fields from the virtual desktop status data and calculates the priority using a quantification model: Assign values ​​of 3 / 2 / 1 to user levels (VIP / Normal / Temporary) and 3 / 2 / 1 to business urgency levels (Urgent / Regular / Low) respectively; The overall score is calculated using the formula: "Priority = User Level × 0.6 + Business Urgency × 0.4". Sort all virtual desktops from highest to lowest priority score to generate a priority sorting table.

[0035] Step S3: Based on the server resource status data and the priority sorting table, generate a preliminary resource allocation scheme, and filter the preliminary resource allocation scheme to obtain a feasible resource allocation scheme.

[0036] In this embodiment, the preliminary resource allocation scheme refers to the scheme of initially allocating a server to each virtual desktop based on the current resource status of the server (such as a server with low load) and the priority sorting table, for example, "Desktop_001 is allocated to Server_05 (GPU server, current load 60%)". The filtering rules are based on server resource status data, such as: eliminating unreasonable solutions such as "target server CPU utilization ≥ 85%" and "GPU server allocated to office desktops without GPU requirements"; Feasible resource allocation schemes are a set of valid schemes after screening, such as retaining schemes that meet resource constraints and hardware matching requirements, such as "Desktop_001 is allocated to Server_05" and "Desktop_002 is allocated to Server_08".

[0037] Specifically, this step first uses a greedy algorithm to traverse the virtual desktops from high to low priority in the priority sorting table, and assigns each desktop to the server with the lowest current load (load = (CPU utilization + memory usage) / 2). After allocation, the server load data is updated in real time. Then, based on the server resource status data, two types of schemes are eliminated: the utilization rate of a certain type of resource on the target server is greater than or equal to the threshold (CPU ≥ 85%, GPU ≥ 90%), or the server hardware does not match the desktop requirements (e.g., design-oriented desktops are assigned to servers without GPUs). The remaining schemes are the feasible resource allocation schemes. The above thresholds can be adjusted according to the actual situation.

[0038] Step S4: Determine the system load scenario based on the server resource status data; generate a scheduling scheme based on the load scenario and the feasible resource allocation scheme. In this embodiment, the system load scenarios include high load scenarios and stable load scenarios, as detailed below: High-load scenarios: Server resource utilization increases from 60% to 90% within 5 seconds (such as during the morning peak from 9:00 to 10:00), or ≥50 new virtual desktop connections are added within 1 minute; Stable load scenario: Server resource utilization is stable at 40%-60% (such as lunch break 12:30-13:30), and the number of virtual desktop connections does not fluctuate significantly.

[0039] The scheduling scheme is the result of adjusting feasible resource allocation schemes based on the load scenario, as detailed below: In high-load scenarios, generate fast-response scheduling solutions, such as "prioritize migrating low-priority office desktops to servers with a load of <70% (such as Server_10)"; In scenarios with stable load, generate optimized scheduling schemes, such as "merging migration tasks on the same target server and sorting the migration order by virtual desktop image size".

[0040] Specifically, this step first monitors the CPU utilization and virtual desktop connection count in the server resource status data in real time. If the CPU utilization increases from 60% to 90% within 5 seconds or ≥50 new connections are added within 1 minute, it is determined to be a high-load scenario. If the resource utilization is stable between 40% and 60% and the number of connections fluctuates little, it is determined to be a stable-load scenario. Then, for the high-load scenario, servers with a load <70% are selected from the feasible solutions as targets, and low-priority desktops are migrated first to generate a fast response solution. For the stable-load scenario, the feasible solutions are optimized to obtain an optimized scheduling solution by merging migration tasks of the same target server and sorting the migration order by image size.

[0041] Step S5: Based on the scheduling scheme, determine the data migration cost, and generate a migration decision based on the data migration cost; In this embodiment, data migration cost refers to the overhead of performing migration operations in the scheduling scheme, including network transmission cost (e.g., migrating a 50GB image occupies 25% of bandwidth and takes 8 seconds), storage cost (e.g., generating a snapshot on an SSD server takes 50ms), and user-perceived cost (e.g., a 24% probability of lag during migration). Migration decisions are based on a cost-benefit analysis: if the benefits of reduced server load after migration (such as resource utilization optimization saving 150 yuan / hour) outweigh the migration costs (such as the conversion value corresponding to 350ms), then a "execute migration" decision is generated; otherwise, a "reject migration" decision is generated.

[0042] Specifically, the following example can be used to calculate migration costs and generate migration decisions: Extract parameters such as the amount of migration data and the storage type of the target server from the scheduling scheme, and calculate the three-dimensional costs respectively: network cost (migration data volume × bandwidth utilization / available bandwidth), storage cost (snapshot generation time × number of concurrent migrations), and perceived cost (probability of lag × migration duration × user priority weight). The sum is the total cost. Calculate the migration benefit (load difference before and after migration × server resource value). If the benefit is greater than the cost conversion value (e.g., 1ms = 0.001 yuan), then generate an "execute migration" decision; otherwise, generate a "reject migration" decision.

[0043] Step S6. Based on the migration decision, the server resource status data, and the virtual desktop status data, determine the matching degree between the virtual desktop and the server, determine the server allocated to each virtual desktop based on the matching degree, and allocate the corresponding server hardware resources to each virtual desktop. In this embodiment, the matching degree refers to the degree of compatibility between the virtual desktop requirements and the server hardware capabilities. It is calculated by comparing the virtual desktop status data (e.g., a design desktop requires ≥12GB of GPU memory) with the server resource status data (e.g., Server_05 has 16GB of GPU memory) (e.g., a matching degree of 0.85). Based on the matching degree, a server is assigned to each virtual desktop, and corresponding server hardware resources are allocated to each virtual desktop. The above process of determining the server assigned to each virtual desktop and allocating corresponding server hardware resources to each virtual desktop is the generated final allocation scheme. The final allocation scheme combines the migration decision and the matching degree: if the migration decision is "execute migration", then servers with a matching degree ≥ 0.8 (such as Server_05) are selected from the target servers specified in the scheduling scheme and allocated to the design desktop; if the migration decision is "reject migration", then the virtual desktop is retained on the current server (such as the office desktop continuing to use Server_20), ensuring resource adaptation and controllable migration costs.

[0044] Specifically, virtual desktop status data is converted into demand vectors (such as CPU demand and GPU demand), and server resource status data is converted into capability vectors (such as CPU computing power and GPU video memory). The matching degree between the two is calculated using the cosine similarity formula (range 0-1). Candidate servers are selected based on migration decisions (if migration is executed, the target server in the scheduling plan is selected; if migration is rejected, the current server is selected). Servers are allocated from high to low matching degree. If there is competition, priority is combined to form the final allocation plan.

[0045] This application generates corresponding status data by acquiring basic resource data and virtual desktop status data in real time, providing accurate real-time basis for resource scheduling; it determines priorities and generates a sorting table based on virtual desktop status data, ensuring resource allocation is tilted towards high-priority needs; it generates preliminary plans by combining server resource status and priority sorting, and filters out feasible plans, eliminating unreasonable allocations to ensure basic adaptability; it determines system load scenarios based on server resource status and adjusts feasible plans accordingly to generate a scheduling plan, making the scheduling strategy adaptable to load changes; it determines data migration costs based on the scheduling plan and generates migration decisions to avoid resource waste caused by ineffective migrations; finally, it combines migration decisions, resource status, and characteristic data to determine the matching degree between virtual desktops and servers and generates a final allocation plan, achieving precise resource matching. The above steps work together to effectively improve the rationality and efficiency of resource scheduling in the desktop cloud environment, making resource allocation more aligned with actual needs, improving resource utilization, enhancing system stability, and improving user experience.

[0046] In some optional implementations of this embodiment, the step of determining the priority of each virtual desktop and generating a priority sorting table based on virtual desktop state data specifically includes: S21. Extract the user level and business urgency of each virtual desktop from the server resource status data and virtual desktop status data; In this embodiment, user level refers to the identity level of the virtual desktop user, which is used to distinguish the priority of resource allocation, such as: core users (such as enterprise R&D personnel), ordinary users (such as administrative personnel), and temporary users (such as visitors). Business urgency refers to the urgency of the currently running task on the virtual desktop, based on the task's time constraints and importance. Examples include: real-time business processing (such as online transactions), routine business operations (such as document editing), and non-urgent tasks (such as data archiving). Examples of extracted results: "Desktop_A, User Level = Core User, Business Urgency = Real-time Business Processing" and "Desktop_B, User Level = Ordinary User, Business Urgency = Routine Business Operation".

[0047] Specifically, in this embodiment, the user level (such as a preset user identity identifier) ​​is extracted from the "user attribute" field of the virtual desktop status data; the business urgency (such as the timeliness identifier of the task) is extracted from the "task tag" field of the virtual desktop status data; and the extraction results are verified by combining the "process resource consumption threshold" in the server resource status data (such as the preset resource consumption threshold being higher for high-urgency tasks).

[0048] S22. Quantify and assign values ​​to the user level and the business urgency respectively to obtain the quantified value of the user level and the quantified value of the business urgency. In this embodiment, the rules for assigning user level quantification values ​​are as follows: core users can be assigned higher scores (e.g., 3 points), ordinary users can be assigned medium scores (e.g., 2 points), and temporary users can be assigned lower scores (e.g., 1 point) (the specific scores can be set according to the actual scenario). The rules for assigning quantifiable values ​​for business urgency are as follows: real-time business processing can be assigned a higher score (e.g., 3 points), routine business operations can be assigned a medium score (e.g., 2 points), and non-urgent tasks can be assigned a lower score (e.g., 1 point) (the specific score can be adjusted according to the importance of the task). Examples of quantification results: "Desktop_A: User level quantification value = 3, Business urgency quantification value = 3" "Desktop_B: User level quantification value = 2, Business urgency quantification value = 2".

[0049] Specifically, in this embodiment, based on preset quantification rules, user levels are assigned corresponding scores (the higher the score, the higher the priority), and the rules can be adjusted according to business scenarios; Similarly, a quantitative score is assigned to the urgency of a task, taking into account the potential impact of task delays; the quantitative results are stored in a structured format and linked to the corresponding virtual desktop ID.

[0050] S23. Determine the priority of each virtual desktop based on the user level quantification value and the business urgency quantification value; In this embodiment, the priority is a quantitative result that combines user level and business urgency, used to determine the order of resource allocation; Calculation example: If the weights are all 0.5, the priority of Desktop_A = 3 × 0.5 + 3 × 0.5 = 3; the priority of Desktop_B = 2 × 0.5 + 2 × 0.5 = 2 (the specific weights and results are just examples and can be adjusted flexibly).

[0051] Specifically, in this embodiment, a weighted summation formula is used to calculate the priority. The weights can be set according to the business's emphasis on user identity and task urgency. If the calculation results are the same, priority can be given to sorting by user level quantification value to ensure the task priority of core users.

[0052] S24. Sort all virtual desktops in descending order of priority to generate the priority sorting table.

[0053] In this embodiment, the priority sorting table is the core reference for resource scheduling, ensuring that high-priority virtual desktops receive sufficient resources first. Sorting example (exemplary content): Desktop_A (priority 3, core user, real-time business processing); Desktop_C (priority 2.5, core user, routine business operations); Desktop_B (priority 2, ordinary user, routine business operations).

[0054] Specifically, in this embodiment, all virtual desktops are sorted in descending order based primarily on priority scores; a sorting table containing virtual desktop ID, priority, user level, and business urgency is generated as the basis for subsequent resource allocation.

[0055] This application achieves dynamic prioritization of virtual desktops through the above steps, ensuring that the resource needs of core businesses and important users are prioritized, improving the rationality of resource allocation, and enhancing the response efficiency of high-priority tasks.

[0056] In some optional implementations of this embodiment, the above-described process of filtering the preliminary resource allocation scheme to obtain a feasible resource allocation scheme includes: Based on the server resource status data, the preliminary resource allocation schemes that have reached the preset utilization threshold of the target server resources or that do not match the requirements of the server hardware and the virtual desktop are screened out and eliminated. The preliminary resource allocation schemes after screening and elimination are taken as the feasible resource allocation schemes.

[0057] In this embodiment, the preliminary resource allocation scheme refers to the initial allocation result without hardware adaptation and load threshold verification, which is only roughly matched based on priority and the currently available resources of the server. Example: "Desktop_001 (high priority) is initially assigned to Server_01 and Server_03; Desktop_002 (medium priority) is initially assigned to Server_02."

[0058] Furthermore, firstly, based on a priority sorting table, server resources are allocated sequentially from high to low priority for virtual desktops; secondly, referring to server resource status data (such as current load and hardware configuration), one or more candidate servers are initially matched for each virtual desktop; then, the allocation results are recorded to form a preliminary scheme set containing "virtual desktop ID - server ID - resource allocation details".

[0059] In this embodiment, the screening and elimination of schemes in this step mainly involves two schemes: one is to eliminate schemes whose target server resource utilization reaches a preset utilization threshold, and the other is to eliminate schemes whose server hardware and virtual desktop requirements do not match.

[0060] Specifically, in the scheme that excludes servers whose resource utilization reaches the preset utilization threshold, server resource status data refers to a dataset reflecting the real-time operating status of the server, including indicators such as CPU utilization, memory usage, GPU load, and network bandwidth utilization (e.g., "Server_01, CPU utilization 85%, memory usage 70%"). The preset utilization threshold refers to the upper limit of resource usage set based on server hardware performance and business needs (e.g., the CPU utilization threshold can be set to 80%-90%, and the memory usage threshold can be set to 75%-85%, with specific values ​​adjusted according to the server model and business scenario). The filtering logic for eliminating schemes whose target server resource utilization reaches the preset utilization threshold is as follows: if the utilization rate of any resource such as CPU, memory, or GPU of the target server allocated to a virtual desktop in the preliminary scheme reaches or exceeds the corresponding preset threshold, then the scheme is eliminated.

[0061] For example: In the initial plan, "Desktop_001 is assigned to Server_01", but the CPU utilization of Server_01 has reached 88% (the preset threshold is 85%), so the plan is removed.

[0062] Furthermore, in solutions that eliminate mismatches between server hardware and virtual desktop requirements, server hardware refers to the physical configuration of the server, including processor type (e.g., whether it includes a GPU), memory capacity, storage type (e.g., SSD / HDD), network interface speed, etc.; virtual desktop requirements refer to the hardware support needed for the virtual desktop to run, determined based on virtual desktop status data (e.g., design desktops require GPU support, video processing desktops require high-speed network interfaces). Mismatch scenarios include, but are not limited to: assigning GPU-accelerated virtual desktops to servers without GPUs, assigning high-IOPS storage virtual desktops to HDD servers (instead of SSD servers), and assigning high-bandwidth virtual desktops to servers with network interfaces below 1Gbps.

[0063] For example: In the initial plan, "the design-type virtual desktop Desktop_003 was assigned to Server_05, which has no GPU". However, this plan was removed because the hardware of Server_05 could not meet the GPU requirements of Desktop_003.

[0064] After filtering by the above two rules, all preliminary schemes that were not eliminated are retained; If the same virtual desktop corresponds to multiple feasible solutions, all valid options are temporarily saved for further optimization in subsequent steps.

[0065] The solutions that were not eliminated are feasible resource allocation solutions, that is, effective allocation solutions that meet server resource load constraints and hardware adaptation requirements, and can be directly used as the basis for subsequent scheduling. Example: After screening, the following solutions are retained: "Desktop_001 is assigned to Server_03 (CPU utilization 70%, including GPU)" and "Desktop_002 is assigned to Server_02 (memory utilization 65%, network interface 10Gbps)" to form a set of feasible solutions.

[0066] This application, through the aforementioned screening steps, ensures that the resource allocation scheme complies with the server hardware capabilities and load limitations, avoiding scheduling failures caused by resource overload or hardware incompatibility, and providing a reliable foundation for subsequent load scenario adaptation and scheduling scheme generation.

[0067] In some optional implementations of this embodiment, the server resource status data mentioned above includes server resource utilization indicators and the number of virtual desktop connections; The step of determining the system load scenario based on the server resource status data, and generating a scheduling scheme based on the load scenario and the feasible resource allocation scheme, includes: S41. Determine the system load scenario based on the resource utilization rate index and the number of connections, wherein the system load scenario includes a high load scenario and a stable load scenario; In this embodiment, the server resource status data is a real-time dataset reflecting the server's operating status. The core indicators related to the load scenario include resource utilization and virtual desktop connections. The resource utilization indicators can be CPU utilization, memory usage, GPU load, network bandwidth utilization, etc. (reflecting the busyness of server hardware resources). The number of virtual desktop connections is the number of virtual desktops currently connected to the server (reflecting user access pressure).

[0068] Specifically, core monitoring metrics are extracted from server resource status data, including resource utilization and virtual desktop connection count; scenario judgment rules are set, and the current load scenario of the system is determined by monitoring the changing trends and numerical ranges of the metrics in real time.

[0069] System load scenarios are operational state types categorized based on server resource usage and user access pressure, primarily including high-load scenarios and stable-load scenarios, among which: High-load scenario: This refers to a state where server resources are strained or user access pressure increases sharply. The criteria for judgment include, but are not limited to: resource utilization metrics rapidly rising from the normal range to a preset high-load threshold within a preset time (e.g., CPU utilization rising from 60% to over 85% within 5 minutes), or a significant increase in the number of virtual desktop connections in a short period (e.g., new connections accounting for more than 30% of the current total connections within 10 minutes). For example, during the weekday morning peak hours of 9:00-10:00, a large number of users logging into virtual desktops simultaneously causes the server CPU utilization to rapidly rise to 90%, which is judged as a high-load scenario.

[0070] Stable load scenario: This refers to a state where server resources are evenly distributed and user access pressure is stable. The criteria for judgment include: resource utilization indicators consistently remaining within a preset normal range (e.g., CPU utilization 40%-70%), and minimal fluctuations in virtual desktop connections (e.g., connection change rate less than 5% within 1 hour). For example, during the lunch break from 12:30 to 13:30, user activity decreases, and server resource utilization remains stable at around 50%, which is considered a stable load scenario.

[0071] S42. Adjust the feasible resource allocation scheme according to the system load scenario to generate the scheduling scheme.

[0072] In this embodiment, the scheduling scheme is the final execution scheme after adjusting the feasible resource allocation scheme based on the load scenario. The specific generation logic is as follows: In high-load scenarios: The scheduling objective is to quickly alleviate server pressure and ensure that core business operations are not affected. Based on feasible resource allocation schemes, servers with resource utilization below a preset safety threshold (e.g., CPU utilization < 70%) are prioritized as target servers, and low-priority virtual desktops (refer to the priority sorting table in step S2) are migrated first to reduce the impact on high-priority business operations. For example: Select Server_08 (CPU utilization 65%) as the target from feasible schemes, and prioritize migrating low-priority office virtual desktops to this server to form a fast-response scheduling scheme.

[0073] For stable load scenarios: the scheduling goal is to optimize resource allocation efficiency and reduce overall operating costs. Based on feasible resource allocation schemes, adjustments are made by merging migration tasks on the same target server (reducing redundant operations) and sorting the migration order by task complexity or data volume (improving execution efficiency). For example, the two migration tasks "Desktop_002 assigned to Server_05" and "Desktop_003 assigned to Server_05" are merged and executed in ascending order of data volume, forming an optimized scheduling scheme.

[0074] In this embodiment, based on a feasible resource allocation scheme, the scheme is adjusted in a targeted manner according to the scheduling objectives of different load scenarios (such as prioritizing response speed in high load scenarios and prioritizing resource efficiency in stable load scenarios). The adjustments include, but are not limited to, screening target servers, determining migration priorities, and optimizing task execution order, ultimately forming a scheduling scheme that can be directly executed.

[0075] This application dynamically adjusts resource scheduling strategies based on real-time load scenarios, enabling the scheduling scheme to respond quickly and ensure system stability under high loads, while optimizing resource utilization efficiency under stable loads, effectively improving the dynamic adaptability of the desktop cloud environment.

[0076] In some optional implementations of this embodiment, the above-described determination of data migration cost based on the scheduling scheme and generation of migration decision based on the data migration cost includes: S51. Extract the data migration parameters from the scheduling scheme; In this embodiment, data migration parameters refer to key information that affects the cost of the migration process, including but not limited to: The amount of data in the virtual desktops to be migrated (such as the size of the virtual desktop image and the amount of user data). The storage type of the target server (such as SSD or HDD, which affects data write speed). Priority of virtual desktop users involved in the migration (refer to the priority sorting table in step S2). The network environment (such as bandwidth and latency) between the source server and the target server.

[0077] Example: Extract "Desktop_001, data size 50GB, target server storage type is SSD, user priority is high, network bandwidth is 10Gbps" from the scheduling scheme.

[0078] In this embodiment, the migration-related content in the scheduling scheme is analyzed, and the core parameters affecting migration costs are extracted. After the parameters are extracted, they are organized according to the structure of "virtual desktop ID-parameter category-parameter value" to form a parameter table.

[0079] S52. Determine the data migration cost based on the data migration parameters; In this embodiment, data migration cost refers to the total overhead incurred in performing the migration operation, including but not limited to: Network transmission cost: The overhead incurred due to network bandwidth usage for data transmission (such as the time and bandwidth utilization for transmitting 50GB of data at 10Gbps bandwidth). Storage operation cost: the overhead of generating virtual desktop snapshots and writing data on the target server (e.g., the snapshot generation time for SSD storage is shorter than that for HDD). User experience impact cost: The migration process may cause user operation lag, delay and other impacts (e.g., the perceived cost of lag for high-priority users is higher than that for low-priority users).

[0080] The calculation method involves converting the costs of each dimension into comparable values ​​(such as uniformly converting them to time or resource consumption) using a pre-defined quantification model, and then summing them to obtain the total cost. Example: For a migration task, the network transmission cost is 200ms, the storage operation cost is 50ms, the user experience impact cost is 100ms, and the total cost is 350ms.

[0081] This step combines data migration parameters to calculate the resource consumption and potential impact during the migration process from multiple dimensions; and summarizes the costs of each dimension to obtain the total cost of data migration.

[0082] S53. Based on the comparison between the data migration cost and the preset cost threshold, a migration decision is generated.

[0083] In this embodiment, the preset cost threshold refers to the upper limit of cost set in advance to ensure the necessity and rationality of migration (e.g., it can be set to 500ms, and the specific value can be adjusted according to server performance and user needs). Migration decisions refer to the final action instructions determined based on cost comparison results, including two outcomes: If the total migration cost is less than or equal to the preset cost threshold, a "execute migration" decision is generated, indicating that the benefits of migration (such as server load balancing and improved resource utilization) outweigh the costs; If the total migration cost is greater than the preset cost threshold, a "reject migration" decision is generated, indicating that the migration overhead is too high and will not be executed for the time being.

[0084] Example: If the total cost of a migration task is 350ms (≤ preset threshold 500ms), a "execute migration" decision is generated; if the total cost of another task is 600ms (>500ms), a "reject migration" decision is generated.

[0085] This step retrieves a preset cost threshold (which is set based on the business's tolerance for migration costs); compares the calculated total migration cost with the preset threshold, and generates a decision based on the comparison results.

[0086] This application ensures the rationality of migration operations by quantifying migration costs and comparing them with thresholds, avoiding resource waste or user experience degradation caused by blind migration, and making resource scheduling in desktop cloud environments more economical and targeted.

[0087] In some optional implementations of this embodiment, the virtual desktop status data mentioned above includes the resource requirement parameters of the virtual desktop, and the server resource status data includes the hardware performance parameters of the server. In this embodiment, resource requirement parameters refer to the hardware support indicators required for the virtual desktop to run, which are determined based on virtual desktop status data, including but not limited to: CPU core count requirements, memory capacity requirements, GPU memory requirements (e.g., design desktops require ≥8GB), network bandwidth requirements (e.g., video desktops require ≥1Gbps), storage IOPS requirements, etc.; hardware performance parameters refer to the actual hardware capabilities of the server, which are determined based on server resource status data, including but not limited to: CPU computing power, total memory capacity and available amount, GPU memory capacity and load, network throughput, storage IOPS and type (SSD / HDD), etc. The process of determining the matching degree between virtual desktops and servers based on the migration decision, the server resource status data, and the virtual desktop status data, determining the server allocated to each virtual desktop based on the matching degree, and allocating corresponding server hardware resources to each virtual desktop includes: S61. Based on the compatibility between the resource requirement parameters of the virtual desktop status data and the hardware performance parameters of the server resource status data, determine the matching degree between the virtual desktop and the server; Compatibility refers to the degree to which the server's hardware performance parameters meet the resource requirements of the virtual desktop. For example, a server with 16GB of GPU memory can meet the 8GB requirement of a virtual desktop, which is highly compatible; if the server does not have a GPU but the virtual desktop requires GPU support, the compatibility is 0. Match score is a quantitative result of adaptability (usually a value between 0 and 1, where 1 represents a perfect match). It can be calculated based on the number of matching parameters or their weighting (e.g., core parameters have higher weighting). Example: A design-oriented virtual desktop requires a GPU ≥ 8GB and a CPU ≥ 4 cores. One server has a GPU = 12GB (matched) and a CPU = 6 cores (matched), resulting in a match score of 0.9; another server has no GPU (not matched), resulting in a match score of 0.3.

[0088] S62. Based on the migration decision, candidate servers are selected from multiple servers; In this embodiment, the migration decision is the output of step S5 (execute migration or reject migration), which determines whether the virtual desktop needs to change its current server; Candidate servers refer to the set of servers that meet the migration decision requirements and can be used as virtual desktop allocation targets, wherein: If the migration decision is "execute migration": the candidate server is the target server specified in the scheduling plan (it must meet the basic resource availability conditions, such as the load not reaching the threshold). If the migration decision is "deny migration": the candidate server is the server where the virtual desktop is currently located (i.e., maintain the status quo and do not change the server).

[0089] Example: When the migration decision is "Execute migration", servers with a load of <70% are selected from Server_05 and Server_08 specified in the scheduling plan as candidates; when the decision is "Reject migration", Server_02, where the virtual desktop is currently located, is directly selected as a candidate.

[0090] S63. Based on the matching degree, determine the allocation association between each virtual desktop and the candidate server; In this embodiment, the allocation association refers to the correspondence between virtual desktops and candidate servers, specifying "which virtual desktop is assigned to which candidate server"; For example: the association between virtual desktop Desktop_001 (design type) and candidate servers Server_05 (match degree 0.9) and Server_08 (match degree 0.7) is "Desktop_001→Server_05"; the association between virtual desktop Desktop_002 (office type) and candidate server Server_02 (match degree 0.8) is "Desktop_002→Server_02".

[0091] Specifically, for each virtual desktop, its matching degree with all candidate servers is calculated; virtual desktops are sorted from high to low according to matching degree, and are preferentially assigned to the candidate server with the highest matching degree; if multiple virtual desktops compete for the same server, the virtual desktop priority can be combined to assist in the decision.

[0092] S64. Based on the allocation association, determine the server assigned to each virtual desktop, and allocate hardware resources of the corresponding server to each virtual desktop.

[0093] In this embodiment, the allocation relationships between all virtual desktops and candidate servers are summarized and organized into a structured scheme, including information such as virtual desktop ID, target server ID, and resource allocation details (such as the specific allocation amount of CPU and memory). The scheme must meet the requirements of no conflict (the total resource allocation of the same server does not exceed its hardware capacity) and can be directly used to perform resource scheduling.

[0094] Specifically, the final allocation plan is the basis for resource scheduling and must be clear, feasible, and reflect the correspondence between "virtual desktop - server - resource quantity". The following is an example of a solution snippet: Desktop_001 (Design) → Server_05, allocated 8GB GPU memory, 4 CPU cores, and 16GB RAM; Desktop_002 (Office Type) → Server_02, allocated 2 CPU cores and 8GB of memory; (All allocations meet the hardware performance limits of Server_05 and Server_02).

[0095] In some optional implementations of this embodiment, the above-described method of selecting candidate servers from the servers based on the migration decision includes: If the migration decision is to perform a migration, then the target server specified in the scheduling scheme is selected as the candidate server; In this embodiment, "execute migration" refers to the result of the migration decision being "execute," indicating that after assessing the data migration cost, it is determined that the benefits of the migration operation outweigh the costs, and the virtual desktop needs to be migrated from its current server to another server. The target server specified in the scheduling scheme refers to the server that is explicitly recorded in the scheduling scheme generated in step S4 and is planned to receive the migrated virtual desktop, such as Server_05 and Server_08 in "migrate Desktop_001 to Server_05 and Desktop_002 to Server_08." The basic resource availability conditions refer to the minimum operating requirements that the target server must meet (determined based on server resource status data), including but not limited to: CPU utilization < 80%, memory usage < 75%, network bandwidth availability > 30%, etc. (specific thresholds can be adjusted according to hardware performance). Example: The scheduling plan specifies Server_05, Server_06, and Server_08 as target servers. After verification, Server_05 (CPU utilization 65%) and Server_08 (memory utilization 60%) meet the resource availability conditions, while Server_06 (CPU utilization 90%) does not. Finally, Server_05 and Server_08 are selected as candidate servers.

[0096] In this embodiment, the scheduling scheme generated in step S4 is parsed, and the list of target servers explicitly specified therein for receiving the migrated virtual desktops is extracted; combined with the server resource status data, it is verified whether the target servers meet the basic resource availability conditions (such as the load not exceeding the preset threshold and the hardware function being normal); all target servers that meet the conditions are retained as candidate servers when performing the migration.

[0097] If the migration decision is to reject the migration, then the server where each virtual desktop is currently located is selected as the candidate server.

[0098] In this embodiment, "reject migration" means that the migration decision is "rejected", indicating that the migration cost is too high or the benefits are insufficient, and there is no need to migrate the virtual desktop, so its current deployment status is maintained. The server where the virtual desktop is currently located refers to the server (source server) where the virtual desktop is running. For example, if Desktop_003 is currently running on Server_02, then Server_02 is its current server. Example: If the migration decision is "deny migration", and Desktop_003 is currently located on Server_02 and Desktop_004 is currently located on Server_03, then Server_02 and Server_03 will be directly selected as candidate servers for both.

[0099] Specifically, in this embodiment, the server information (i.e., the source server) where each virtual desktop is currently located is extracted from the virtual desktop status data or system logs; without the need to filter other servers, the current server is directly used as the candidate server to ensure that the virtual desktop maintains its existing deployment status.

[0100] This application selects candidate servers based on different migration decision results to ensure that the candidate range is consistent with the decision logic: when performing a migration, it focuses on the target server specified by the scheduling plan (to ensure the migration is implemented), and when rejecting a migration, it locks the current server (to avoid invalid changes). This provides an accurate and compliant server range for subsequent allocation based on matching degree, and improves the stability and rationality of resource scheduling.

[0101] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by instructing related hardware through computer-readable instructions. These computer-readable instructions can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above methods. The aforementioned storage medium can be a non-volatile storage medium such as a magnetic disk, optical disk, or read-only memory (ROM), or random access memory (RAM).

[0102] It should be understood that although the steps in the flowcharts of the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0103] Further reference Figure 3 As a response to the above Figure 2 To implement the method shown, this application provides an embodiment of a device, which is similar to... Figure 2 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0104] like Figure 3 As shown, the resource scheduling system 300 for the desktop cloud environment described in this embodiment includes: a data acquisition module 301, a priority determination module 302, a feasible solution generation module 303, a scheduling solution generation module 304, a migration decision generation module 305, and a final solution generation module 306. Wherein: Data acquisition module 301 is used to acquire basic resource data and virtual desktop status data in real time, and generate server resource status data and virtual desktop status data. The priority determination module 302 is used to determine the priority of each virtual desktop based on the virtual desktop status data and generate a priority sorting table. The feasible solution generation module 303 is used to generate a preliminary resource allocation scheme based on the server resource status data and the priority sorting table, and to filter the preliminary resource allocation scheme to obtain a feasible resource allocation scheme. The scheduling scheme generation module 304 is used to determine the system load scenario based on the server resource status data, and generate a scheduling scheme based on the load scenario and the feasible resource allocation scheme. The migration decision generation module 305 is used to determine the data migration cost based on the scheduling scheme, and generate a migration decision based on the data migration cost. The final scheme generation module 306 is used to determine the matching degree between the virtual desktop and the server based on the migration decision, the server resource status data and the virtual desktop status data, and generate a final allocation scheme based on the matching degree.

[0105] To address the aforementioned technical problems, embodiments of this application also provide a computer device. Please refer to [link / reference needed]. Figure 4 , Figure 4 This is a basic structural block diagram of the computer device in this embodiment.

[0106] The computer device 4 includes a memory 41, a processor 42, and a network interface 43 that are interconnected via a system bus. It should be noted that only the computer device 4 with components 41-43 is shown in the figure; however, it should be understood that it is not required to implement all the shown components, and more or fewer components can be implemented alternatively. Those skilled in the art will understand that the computer device described here is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.

[0107] The computer device can be a desktop computer, laptop, handheld computer, or cloud server, etc. The computer device can interact with the user via a keyboard, mouse, remote control, touchpad, or voice control.

[0108] The memory 41 includes at least one type of readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, disk, optical disk, etc. In some embodiments, the memory 41 may be an internal storage unit of the computer device 4, such as the hard disk or memory of the computer device 4. In other embodiments, the memory 41 may also be an external storage device of the computer device 4, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 4. Of course, the memory 41 may also include both the internal storage unit and its external storage device of the computer device 4. In this embodiment, the memory 41 is typically used to store the operating system and various application software installed on the computer device 4, such as computer-readable instructions of the # method, etc. In addition, the memory 41 can also be used to temporarily store various types of data that have been output or will be output.

[0109] In some embodiments, the processor 42 may be a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chip. The processor 42 is typically used to control the overall operation of the computer device 4. In this embodiment, the processor 42 is used to execute computer-readable instructions stored in the memory 41 or to process data, for example, to execute computer-readable instructions of the # method.

[0110] The network interface 43 may include a wireless network interface or a wired network interface, which is typically used to establish communication connections between the computer device 4 and other electronic devices.

[0111] This application also provides another embodiment, namely, providing a computer-readable storage medium storing computer-readable instructions that can be executed by at least one processor to cause the at least one processor to perform the steps of the resource scheduling method for the desktop cloud environment as described above.

[0112] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0113] Obviously, the embodiments described above are only some embodiments of this application, not all embodiments. The accompanying drawings show preferred embodiments of this application, but do not limit the patent scope of this application. This application can be implemented in many different forms; rather, the purpose of providing these embodiments is to provide a more thorough and comprehensive understanding of the disclosure of this application. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing specific embodiments, or make equivalent substitutions for some of the technical features. Any equivalent structures made using the content of this application's specification and drawings, directly or indirectly applied to other related technical fields, are similarly within the scope of patent protection of this application.

Claims

1. A resource scheduling method for a desktop cloud environment, characterized in that, Includes the following steps: Real-time acquisition of basic resource data and virtual desktop feature data; generation of server resource status data and virtual desktop status data. Based on the virtual desktop status data, the priority of each virtual desktop is determined, and a priority sorting table is generated; Based on the server resource status data and the priority sorting table, a preliminary resource allocation plan is generated, and a feasible resource allocation plan is obtained by filtering the preliminary resource allocation plan. Based on the server resource status data, the system load scenario is determined, and based on the load scenario and the feasible resource allocation scheme, a scheduling scheme is generated. Based on the scheduling scheme, the data migration cost is determined, and a migration decision is generated based on the data migration cost. Based on the migration decision, the server resource status data, and the virtual desktop status data, the matching degree between the virtual desktop and the server is determined. Based on the matching degree, the server allocated to each virtual desktop is determined, and the hardware resources of the corresponding server are allocated to each virtual desktop.

2. The resource scheduling method for a desktop cloud environment according to claim 1, characterized in that, The step of determining the priority of each virtual desktop based on the virtual desktop status data and generating a priority sorting table includes: Extract the user level and business urgency of each virtual desktop from the server resource status data and virtual desktop status data; The user level and the business urgency are quantified and assigned values ​​to obtain the quantified values ​​of the user level and the business urgency. The priority of each virtual desktop is determined based on the user level quantification value and the business urgency quantification value. All virtual desktops are sorted in descending order of priority to generate the priority sorting table.

3. The resource scheduling method for a desktop cloud environment according to claim 1, characterized in that, The process of filtering the preliminary resource allocation scheme to obtain a feasible resource allocation scheme includes: Based on the server resource status data, the preliminary resource allocation schemes that have reached the preset utilization threshold of the target server resources or that do not match the requirements of the server hardware and the virtual desktop are screened out and eliminated. The preliminary resource allocation schemes after screening and elimination are taken as the feasible resource allocation schemes.

4. The resource scheduling method for a desktop cloud environment according to claim 1, characterized in that, The server resource status data includes server resource utilization metrics and the number of virtual desktop connections. The step of determining the system load scenario based on the server resource status data, and generating a scheduling scheme based on the load scenario and the feasible resource allocation scheme, includes: The system load scenario is determined based on the resource utilization rate index and the number of connections, wherein the system load scenario includes a high load scenario and a stable load scenario. The feasible resource allocation scheme is adjusted according to the system load scenario to generate the scheduling scheme.

5. The resource scheduling method for a desktop cloud environment according to claim 1, characterized in that, The process of determining the data migration cost based on the scheduling scheme and generating a migration decision based on the data migration cost includes: Extract the data migration parameters from the scheduling scheme; The data migration cost is determined based on the aforementioned data migration parameters; A migration decision is generated based on the comparison between the data migration cost and the preset cost threshold.

6. The resource scheduling method for a desktop cloud environment according to claim 1, characterized in that, The process of determining the matching degree between virtual desktops and servers based on the migration decision, the server resource status data, and the virtual desktop status data, determining the server allocated to each virtual desktop based on the matching degree, and allocating corresponding server hardware resources to each virtual desktop includes: Based on the virtual desktop status data and the server resource status data, the matching degree between the virtual desktop and the server is determined; Based on the migration decision, candidate servers are selected from multiple servers; Based on the matching degree, the allocation association between each virtual desktop and the candidate server is determined; Based on the allocation association, the server assigned to each virtual desktop is determined, and the hardware resources of the corresponding server are allocated to each virtual desktop.

7. The resource scheduling method for a desktop cloud environment according to claim 6, characterized in that, The process of selecting candidate servers from the servers based on the migration decision includes: If the migration decision is to perform a migration, then the target server specified in the scheduling scheme is selected as the candidate server; If the migration decision is to reject the migration, then the server where each virtual desktop is currently located is selected as the candidate server.

8. A resource scheduling system for a desktop cloud environment, used to execute the resource scheduling method for a desktop cloud environment as described in claims 1 to 7, characterized in that, include: The data acquisition module is used to acquire basic resource data and virtual desktop status data in real time, and generate server resource status data and virtual desktop status data. The priority determination module is used to determine the priority of each virtual desktop based on the virtual desktop status data and generate a priority sorting table. The feasible solution generation module is used to generate a preliminary resource allocation plan based on the server resource status data and the priority sorting table, and to filter the preliminary resource allocation plan to obtain a feasible resource allocation plan. The scheduling scheme generation module is used to determine the system load scenario based on the server resource status data, and generate a scheduling scheme based on the load scenario and the feasible resource allocation scheme. A migration decision generation module is used to determine the data migration cost based on the scheduling scheme, and generate a migration decision based on the data migration cost; The final solution generation module is used to determine the matching degree between the virtual desktop and the server based on the migration decision, the server resource status data, and the virtual desktop status data. Based on the matching degree, a server is assigned to each virtual desktop, and hardware resources of the corresponding server are allocated to each virtual desktop.

9. A computer device, characterized in that, The system includes a memory and a processor, wherein the memory stores computer-readable instructions, and the processor executes the computer-readable instructions to implement the steps of the resource scheduling method for a desktop cloud environment as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-readable instructions, which, when executed by a processor, implement the steps of the resource scheduling method for a desktop cloud environment as described in any one of claims 1 to 7.

Images