Method and system for dynamic scheduling of virtual resources in a hybrid cloud environment

Abstract

The application discloses a virtual resource dynamic scheduling method and system in a hybrid cloud environment, and relates to the technical field of resource scheduling. The method captures and analyzes abstract business requirement specifications, translates them into scheduling strategy objects that can be understood and activated by machines. At the same time, the resource state in the underlying hybrid cloud environment, multi-cloud price models, and real-time business KPI flows are multi-dimensionally fused to form a globally unified system state view. Based on this, an adaptive mechanism based on a control loop is introduced, with the activated strategy derived from the intention analysis as the guide, and multi-element optimization indicators as the decision factors that can be dynamically allocated, for continuous weight vector optimization and generation. Finally, the scheduler uses the dynamic weights to intelligently score new task requests and make optimal placement decisions. In this way, an intelligent decision-making closed loop from business intention definition to resource scheduling execution can be achieved, thereby improving the resource allocation efficiency and business agility of the hybrid cloud environment.

Description

Technical Field

[0001] This application relates to the field of resource scheduling technology, and more specifically, to a method and system for dynamic scheduling of virtual resources in a hybrid cloud environment. Background Technology

[0002] With the evolution and popularization of cloud computing technology, hybrid cloud has become the mainstream choice for enterprise IT architecture, integrating the security and controllability of private cloud with the elasticity, scalability, and cost advantages of public cloud. However, this heterogeneous resource environment spanning different infrastructures greatly increases the complexity of virtual resource management. In the context of hybrid cloud, how to efficiently and intelligently schedule virtual resources such as virtual machines and containers to dynamically balance performance, cost, reliability, and other multi-dimensional optimization goals, ensuring that service level agreements (SLAs) for critical businesses are met while maximizing resource utilization, has become a core issue and key challenge for cloud management platforms. Effective resource scheduling is not only the technological cornerstone for maximizing IT operational efficiency but also an important guarantee for supporting enterprise business agility.

[0003] In existing technologies, multiple status indicators of the underlying infrastructure are typically considered comprehensively, such as node CPU and memory load, network bandwidth, storage I / O, and pricing models of different cloud service providers. A scoring mechanism is used to select the optimal deployment location for new business requests. However, existing schedulers mostly rely on a pre-configured, static weighting strategy to aggregate these evaluation indicators, assigning fixed weight values ​​to different optimization objectives such as performance and cost. The fundamental flaw of this approach is that its rigid logic cannot adapt to the dynamic changes in enterprise business objectives. In actual operation, business priorities are not constant: for example, during peak business periods such as earnings season or e-commerce promotions, the importance of system performance and stability far outweighs operating costs; while during regular operation, cost-effectiveness becomes the primary consideration. Traditional static scheduling mechanisms cannot perceive and respond to such semantic changes at the business level, leading to a disconnect between resource scheduling strategies and business objectives. This may ultimately result in insufficient resources affecting business at critical moments, or unnecessary expenses due to resource redundancy during stable business periods.

[0004] Therefore, there is an urgent need for an optimized method and system for dynamic scheduling of virtual resources in a hybrid cloud environment. Summary of the Invention

[0005] This application is made in order to solve the above-mentioned technical problems.

[0006] According to one aspect of this application, a method for dynamic scheduling of virtual resources in a hybrid cloud environment is provided, comprising: acquiring a business intent specification; performing intent parsing and target translation on the business intent specification to obtain an activated policy object; performing multi-dimensional state fusion perception on the acquired resource status data, price data, and business KPI stream to obtain a unified system state; performing dynamic weight adaptation based on control loops on the unified system state and the activated policy object to obtain a dynamic weight vector; acquiring a new task request; and performing weighted scoring and scheduling decision on the new task request based on the dynamic weight vector and the unified system state to obtain a placement decision, wherein the placement decision includes the finally selected target node.

[0007] According to another aspect of this application, a dynamic scheduling system for virtual resources in a hybrid cloud environment is provided, comprising: a business intent specification acquisition module for acquiring business intent specifications; an intent parsing and target translation module for performing intent parsing and target translation on the business intent specifications to obtain activated policy objects; a multi-dimensional state fusion perception module for performing multi-dimensional state fusion perception on the acquired resource state data, price data, and business KPI stream to obtain a unified system state; a dynamic weight adaptation module for performing dynamic weight adaptation based on control loops on the unified system state and activated policy objects to obtain a dynamic weight vector; a new task request acquisition module for acquiring new task requests; and a weighted scoring and scheduling decision module for performing weighted scoring and scheduling decisions on new task requests based on the dynamic weight vector and the unified system state to obtain a placement decision, wherein the placement decision includes the finally selected target node.

[0008] Compared with existing technologies, this application provides a method and system for dynamic scheduling of virtual resources in a hybrid cloud environment. It captures and parses abstract business requirement specifications, translating them into machine-understandable and activatable scheduling policy objects. Simultaneously, it integrates the resource status, multi-cloud pricing model, and real-time business KPI streams in the underlying hybrid cloud environment to form a globally unified system state view. Based on this, an adaptive mechanism based on a control loop is introduced. Guided by the activation policy derived from intent parsing, it uses multiple optimization indicators as dynamically adjustable decision factors for continuous weight vector optimization and generation. Finally, the scheduler uses this set of dynamic weights to intelligently weight and score new task requests, making the optimal placement decision. This achieves an intelligent decision-making closed loop from business intent definition to resource scheduling execution, thereby improving resource allocation efficiency and business agility in the hybrid cloud environment. Attached Figure Description

[0009] The above and other objects, features, and advantages of this application will become more apparent from the more detailed description of the embodiments of this application in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this application and form part of the specification. They are used together with the embodiments of this application to explain this application and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0010] Figure 1 This is a flowchart of a method for dynamic scheduling of virtual resources in a hybrid cloud environment according to an embodiment of this application.

[0011] Figure 2 This is a data flow diagram of a virtual resource dynamic scheduling method in a hybrid cloud environment according to an embodiment of this application.

[0012] Figure 3 This is a flowchart of sub-step S2 of the method for dynamic scheduling of virtual resources in a hybrid cloud environment according to an embodiment of this application.

[0013] Figure 4 This is a flowchart of sub-step S21 of the method for dynamic scheduling of virtual resources in a hybrid cloud environment according to an embodiment of this application.

[0014] Figure 5 This is a flowchart of sub-step S3 of the method for dynamic scheduling of virtual resources in a hybrid cloud environment according to an embodiment of this application.

[0015] Figure 6 This is a flowchart of sub-step S4 of the virtual resource dynamic scheduling method in a hybrid cloud environment according to an embodiment of this application.

[0016] Figure 7 This is a flowchart of sub-step S42 of the method for dynamic scheduling of virtual resources in a hybrid cloud environment according to an embodiment of this application.

[0017] Figure 8 This is a flowchart of sub-step S422 of the method for dynamic scheduling of virtual resources in a hybrid cloud environment according to an embodiment of this application.

[0018] Figure 9 This is a block diagram of a virtual resource dynamic scheduling system in a hybrid cloud environment according to an embodiment of this application. Detailed Implementation

[0019] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0020] To address the problems mentioned above in the background technology, this application proposes a method for dynamic scheduling of virtual resources in a hybrid cloud environment. Figure 1 This is a flowchart of a method for dynamic scheduling of virtual resources in a hybrid cloud environment according to an embodiment of this application. Figure 2 This is a data flow diagram of a virtual resource dynamic scheduling method in a hybrid cloud environment according to an embodiment of this application. For example... Figure 1 and Figure 2 As shown, the virtual resource dynamic scheduling method in a hybrid cloud environment includes the following steps: S1, obtaining a business intent specification; S2, performing intent parsing and target translation on the business intent specification to obtain activated policy objects; S3, performing multi-dimensional state fusion perception on the obtained resource status data, price data, and business KPI stream to obtain a unified system state; S4, performing dynamic weight adaptation based on control loops on the unified system state and activated policy objects to obtain a dynamic weight vector; S5, obtaining a new task request; S6, based on the dynamic weight vector and the unified system state, performing weighted scoring and scheduling decisions on the new task request to obtain a placement decision, wherein the placement decision includes the finally selected target node.

[0021] In the aforementioned method for dynamic scheduling of virtual resources in a hybrid cloud environment, step S1 involves obtaining the business intent specification. It should be understood that traditional hybrid cloud virtual resource scheduling systems rely on static weight configurations, making decisions based solely on fixed technical indicators. They cannot perceive dynamic changes in business objectives, such as prioritizing performance during peak sales periods or cost during normal times. This leads to a disconnect between scheduling strategies and business needs, easily causing resource mismatches or SLA breaches. Therefore, this application establishes a direct link between business objectives and scheduling logic by obtaining the business intent specification defined by business or operations personnel. This provides a precise source of information for subsequently transforming abstract business requirements into machine-executable scheduling rules, ensuring that scheduling decisions always revolve around current business priorities. This avoids insufficient performance of critical business operations or wasted costs on non-critical business operations due to a lack of business orientation, laying a business-driven foundation for the entire dynamic scheduling system.

[0022] Specifically, in one possible embodiment, step S1 is implemented as follows: First, it is clarified that the provider of the specification is the enterprise operations and maintenance team or business leader, and the specification is written in declarative YAML format. In a specific scenario with enterprise cloud disk application as the background, this process can be manifested as follows: the enterprise IT administrator creates a group cloud disk for a specific business department through the cloud disk management and control platform and sets its storage quota limit. This operation defines a resource constraint-type business intent. At the same time, the administrator configures read, write, download and other access permission policies for different members of the group (such as the R&D department and the marketing department). These configurations completed through the graphical interface will be converted into structured specification text in the system backend. Second, the specification content must include the target application group identifier (such as transaction system, data analysis system), effective time range (such as specific date range or permanent effective), core business objectives (such as ultimate performance, cost saving) and initial weight suggestions to ensure that business requirements are fully conveyed. Finally, the system reads the specification through a preset configuration management interface (such as a REST API) or a specified local path. After reading, it immediately performs a key field integrity check. Once it confirms that there are no missing fields, it stores the specification in a dedicated specification storage module, forming a structured initial data asset that provides a stable and reliable data source for subsequent intent parsing steps.

[0023] In the aforementioned method for dynamic scheduling of virtual resources in a hybrid cloud environment, step S2 involves parsing and translating the business intent specification to obtain the activated policy object. It should be understood that since the business intent specification is a human-readable declarative configuration containing abstract business goals, such as performance priority during peak sales periods, it cannot be directly recognized and executed by the scheduling system and needs to be transformed into structured instructions that are understandable to machines. Therefore, this application further parses and translates the specification to transform the abstract business semantics into an executable policy containing specific KPI goals, time ranges, and initial weights. This eliminates the semantic gap between business and technology, ensuring that the scheduling system accurately receives business instructions, providing a clear strategic basis for subsequent dynamic weight adjustments and resource scheduling, avoiding scheduling decision deviations caused by ambiguous instructions, and ensuring a high degree of alignment between scheduling behavior and business goals.

[0024] In particular, in one specific embodiment, Figure 3 This is a flowchart of sub-step S2 of the virtual resource dynamic scheduling method in a hybrid cloud environment according to an embodiment of this application. Figure 3 As shown, step S2 includes: S21, performing structured parsing and verification of the business intent specification to obtain a filtered intent list; S22, based on the intent-to-KPI mapping library, performing intent semantic translation and KPI target visualization on the filtered intent list to obtain a visualized strategy fragment list; S23, based on the default strategy configuration, aggregating activated strategy objects on the visualized strategy fragment list to obtain the activated strategy objects.

[0025] Specifically, step S21 involves structured parsing and verification of the business intent specification to obtain a filtered intent list. It should be understood that direct use of the business intent specification may lead to scheduling system anomalies due to potential formatting errors (such as abnormal YAML indentation), invalid data (such as invalid time formats), or currently ineffective (such as promotional strategies outside of peak promotional periods). Therefore, this application further performs structured parsing and verification of the specification to filter out intent entries that are formatted correctly, have valid data, and are currently in effect. This eliminates invalid or erroneous business instructions from the source, prevents illegal data from interfering with the scheduling logic, ensures that subsequent translation and strategy generation steps are based on reliable input, reduces the system's overhead in processing invalid intents, and improves the stability and efficiency of the overall scheduling process.

[0026] In particular, in one specific embodiment, Figure 4 This is a flowchart of sub-step S21 of the virtual resource dynamic scheduling method in a hybrid cloud environment according to an embodiment of this application. Figure 4 As shown, step S21 includes: S211, performing basic syntax parsing on the business intent specification to obtain an original intent object list; S212, performing intent object pattern verification and data standardization on the original intent object list to obtain a verified intent object list; S213, performing time context filtering on the verified intent object list based on the current system time to obtain a filtered intent list.

[0027] More specifically, step S211 involves performing basic syntax parsing on the business intent specification to obtain a list of original intent objects. It should be understood that since business intent specifications are typically stored in text formats such as YAML, they are unstructured data. Machines cannot directly recognize and extract key information, and the text may contain syntax errors such as indentation mistakes and unclosed fields. Failure to address these issues can lead to interruptions in subsequent data processing. Therefore, this application further performs basic syntax parsing on the specification text to transform the text-formatted specification into machine-recognizable structured objects. This transforms unstructured text into structured data assets, while proactively identifying and preventing grammatically incorrect data from entering subsequent processes. This provides initial, format-compliant structured input for subsequent data validation and semantic translation, ensuring the smoothness of the entire parsing chain.

[0028] Specifically, in one possible embodiment, step S211 is implemented as follows: First, the business intent specification text is loaded through the system-configured file reading interface, and the text content is passed to the standard YAML parser. Second, the parser verifies the text syntax line by line, checking whether the indentation level, field separators, string closures, etc., conform to the YAML specification. If a syntax error is detected, the error location and reason are immediately recorded, and the parsing of the intent is terminated. Finally, the grammatically compliant text content is deserialized and transformed into a structured object containing key information such as application group, effective period, and core objectives. All compliant objects are integrated to form an original intent object list and output.

[0029] More specifically, step S212 involves performing intent object pattern validation and data standardization on the original intent object list to obtain a validated intent object list. It should be understood that, since the original intent object list only ensures format compliance, it may still contain issues such as missing fields (e.g., missing core target fields), incorrect data types (e.g., application group identifiers are single strings instead of lists), and non-compliant values ​​(e.g., the initial weight sum is not 1). These issues can lead to inaccurate subsequent semantic translation. Therefore, this application further performs pattern validation and data standardization on the original intent object list to verify the validity of the data content and unify the data format. This ensures the completeness of fields, the correctness of types, and the compliance of values ​​for each intent object, eliminating inconsistencies at the semantic level of the data, providing high-quality structured data for subsequent time filtering and semantic translation, and avoiding translation deviations or strategy failures caused by data anomalies.

[0030] Specifically, in one possible embodiment, step S212 is implemented as follows: First, a predefined intent object validation rule template is loaded, which specifies the required attributes, data types, and numerical ranges of each field. Second, the original intent object list is traversed, and each object is validated against the template one by one to check for missing required fields, whether the application group is a list of strings, and whether the initial weight sum meets the requirements. Objects that do not meet the rules are marked as invalid, and the reasons are recorded. Finally, the validated objects are subjected to data standardization processing, unifying the field naming format and numerical units, and all compliant objects are integrated to form a validated intent object list.

[0031] More specifically, step S213 involves filtering the list of verified intent objects based on the current system time using time context to obtain a filtered intent list. It should be understood that some intents in the verified intent object list may have specific effective periods, such as strategies that only take effect during peak sales periods. Including them in the scheduling logic during non-effective periods would lead to resource mismatch; for example, enabling peak sales-level resource configurations during regular periods would result in resource waste or cost overruns. Therefore, this application further filters the list of verified intent objects based on the current system time to select executable intents within the current time period. This ensures that all intents ultimately involved in generating the scheduling strategy conform to the current business time context, avoiding interference from invalid intents on scheduling decisions, reducing the system's processing overhead for ineffective intents, and ensuring a high degree of match between the scheduling strategy and current business needs.

[0032] Specifically, in one possible embodiment, step S213 is implemented as follows: First, the current system time is obtained with high precision through the system clock module to ensure that the time accuracy reaches the second level. Second, the list of verified intent objects is traversed, and the validity period information of each object is extracted. If the validity period is marked as permanently effective, the object is directly retained. If a specific start and end time is included, it is determined whether the current system time is within the start and end time interval. Finally, only intent objects that are permanently effective or whose current time is within the validity period are retained. These objects are categorized and integrated according to application groups to form a filtered intent list, ensuring that all intents in the list have the validity of the current execution time.

[0033] Specifically, in step S22, based on the intent-to-KPI mapping library, the filtered intent list is semantically translated and KPI targets are visualized to obtain a visualized list of strategy fragments. It should be understood that since the filtered intent list still contains abstract business objectives such as stability priority, lacking measurable quantitative indicators, the scheduling system cannot determine the specific standards for resource scheduling. Therefore, this application further combines the intent-to-KPI mapping library for semantic translation and KPI visualization to transform abstract objectives into strategy fragments containing specific indicator names, thresholds, and calculation logic. This provides the scheduling system with a quantitative basis that can be directly used for deviation calculation, giving subsequent dynamic weight adjustments a clear reference standard, avoiding subjectivity in scheduling decisions caused by ambiguous objectives, and ensuring that the direction of scheduling optimization in different business scenarios is clear and executable.

[0034] Specifically, in one possible embodiment, step S22 is implemented as follows: First, the filtered intent list is traversed, and for each intent's core objective (such as ultimate performance), the intent-to-KPI mapping library is queried using the objective as the key to obtain the corresponding KPI template. For example, in an enterprise cloud disk scenario, when a business intent to configure high-frequency read / write permissions for a research and development department group is received, this step translates it into a series of concrete KPI objectives, such as the storage volume IOPS (read / write per second) target value for the application group should be no less than 5000, and the P99 percentile of file access latency should be less than 100 milliseconds. Second, the baseline KPI database is called, and historical baseline values ​​are obtained based on the application group in the intent. The specific KPI threshold is calculated using the calculation formula in the template (such as baseline value × 0.5). Finally, the application group, concrete KPI rules (such as P99 latency < 90ms), and initial weights are integrated into a strategy fragment, and all fragments form a concrete strategy fragment list.

[0035] Specifically, in step S23, the activated policy objects are aggregated from the concrete policy fragment list based on the default policy configuration to obtain the activated policy objects. It should be understood that since the concrete policy fragment list only covers application groups with clear business intentions and does not include application groups without specific intentions, and the fragments are scattered, it is not conducive to unified system invocation. Therefore, this application further combines the default policy configuration with the aggregation of activated policy objects to integrate the policies of all application groups and supplement the default rules of application groups not covered. This forms a globally unified policy covering all application groups, ensuring that application groups without specific intentions also have compliant scheduling basis, while transforming scattered fragments into structured callable objects, improving the query and execution efficiency of the scheduling system, and ensuring that all virtual resource scheduling has clear and unified policy guidance.

[0036] Specifically, in one possible embodiment, step S23 is implemented as follows: First, an empty key-value pair set of activation policy objects is initialized, with the application group name as the key. Second, the list of visualized policy fragments is traversed, with the application group corresponding to each fragment as the key, and the KPI rules and initial weights in the fragment as values ​​stored in the key-value pair set. If multiple fragments exist for the same application group, the higher-priority fragment is retained according to a preset priority. Finally, a list of all known application groups in the system is obtained. For application groups that do not appear in the key-value pair set, the preset default policy (such as performance weight 0.5, cost weight 0.5, P99 latency <200ms) is added as a value to the key-value pair set, ultimately forming a complete activation policy object.

[0037] In the aforementioned method for dynamic virtual resource scheduling in a hybrid cloud environment, step S3 involves multi-dimensional state fusion perception of the acquired resource status data, price data, and business KPI streams to obtain a unified system status. It should be understood that since resource status data (e.g., CPU utilization), price data (e.g., public cloud instance unit price), and business KPI streams (e.g., P99 latency) originate from heterogeneous data sources such as private clouds, public clouds, and business monitoring systems, their data formats, semantic standards, and collection times are inconsistent. Therefore, the scheduling system cannot directly make global decisions based on scattered data. Thus, this application further performs multi-dimensional fusion perception on the three types of data to integrate heterogeneous data and form a globally unified system status view. This eliminates data silos, ensuring that resource supply, cost fluctuations, and business health information can be simultaneously obtained during scheduling decisions. This avoids the problem of local optima rather than global optima caused by data fragmentation, improving the comprehensiveness and accuracy of resource scheduling.

[0038] In particular, in one specific embodiment, Figure 5 This is a flowchart of sub-step S3 of the virtual resource dynamic scheduling method in a hybrid cloud environment according to an embodiment of this application. Figure 5 As shown, step S3 includes: S31, performing data cleaning and standardization transformation on resource status data, price data and business KPI stream based on the standard model definition to obtain a standardized data fragment set; S32, performing timestamp alignment and status snapshot aggregation on the standardized data fragment set to obtain a unified system status.

[0039] Specifically, step S31 involves cleaning and standardizing resource status data, price data, and business KPI streams based on a standard model definition to obtain a standardized data fragment set. It should be understood that since resource status data, price data, and business KPI streams come from different systems, they suffer from problems such as inconsistent data formats (e.g., memory units include both GiB and MiB), invalid values ​​(e.g., negative CPU utilization), and semantic ambiguity (e.g., instance performance is not clearly defined). Direct fusion could lead to data conflicts or decision-making biases. Therefore, this application further cleanses and standardizes the three types of data according to a standard model definition to correct data errors and unify data formats and semantics. This ensures the comparability and compatibility of data from different sources, clearing obstacles for subsequent timestamp alignment and state aggregation, while improving data quality, preventing invalid data from interfering with scheduling logic, and ensuring the accuracy of subsequent decisions.

[0040] Specifically, in one possible embodiment, step S31 is implemented as follows: First, a pre-set standard data model is loaded, which specifies the unit (e.g., memory in GiB, price in yuan / hour), data type (e.g., utilization rate as a percentage, instance name as a string), and valid value range (e.g., CPU utilization rate 0-100%) for various types of data. Second, the three types of raw data are traversed, invalid values ​​(e.g., utilization rates exceeding the range) are removed, and format errors are corrected (e.g., converting MiB memory values ​​to GiB). Finally, according to the field definitions of the standard model, the cleaned data is encapsulated into structured fragments, and all fragments are integrated to form a standardized data fragment set, ensuring that the format and semantics of each fragment are completely consistent with the standard model.

[0041] Specifically, step S32 involves aligning the standardized data fragment set with timestamps and aggregating state snapshots to obtain a unified system state. In a specific example of this application, the unified system state includes timestamps, private cloud state, public cloud state, business KPI state, and an active load list. In enterprise cloud disk application scenarios, the business KPI state may specifically include real-time performance indicators such as the average file upload / download rate of each group, the P95 value of user access latency, the synchronization success rate during high-concurrency periods, and the number of active user sessions. It should be understood that because the collection cycles of resource state, price, business KPI, and active load-related fragments in the standardized data fragment set are different (e.g., resource data is collected every 15 seconds, and business KPI is collected every 5 seconds), the timestamps of each fragment are scattered. Direct use would cause distortion in system state judgment, such as using the resource load from 10 seconds ago to match the current business indicator, and the scattered fragments cannot form a global view. Therefore, this application further aligns the standardized data fragments with timestamps and aggregates state snapshots to unify the data time base and integrate it into a global system state that includes modules such as timestamps and private cloud state. This ensures that all data is based on the same point in time, avoiding misjudgments caused by time differences. At the same time, by aggregating data to form a panoramic view of the system, it provides a complete and synchronous data source for subsequent dynamic weight adjustments and scheduling decisions, ensuring the comprehensiveness and accuracy of the decisions.

[0042] Specifically, in one possible embodiment, step S32 is implemented as follows: First, the system presets a snapshot generation cycle, such as once every 5 seconds, and determines the snapshot reference timestamp at the beginning of each cycle. Second, it iterates through the standardized data fragment set, filters out fragments whose timestamps deviate from the reference timestamp within a preset threshold (such as ±2 seconds), and removes expired fragments exceeding the threshold to complete timestamp alignment. Finally, the aligned fragments are aggregated according to a preset structure: the reference timestamp is used as the timestamp field of the unified system state; private cloud host resource (CPU, memory) information is integrated to form the private cloud state; public cloud instance specifications and pricing data are summarized to form the public cloud state; indicators of each application group are collected to form the business KPI state; and current running task information is statistically analyzed to form an active load list, ultimately combining them into a complete unified system state.

[0043] In the aforementioned method for dynamic virtual resource scheduling in a hybrid cloud environment, step S4 involves dynamically adapting the weights of the unified system state and the activated policy objects using a control loop to obtain a dynamic weight vector. It should be understood that traditional scheduling relies on fixed weights, making it impossible to adjust the priority of optimization targets based on changes in business KPIs (such as increased latency during peak sales periods), leading to a disconnect between resource allocation and business needs. Therefore, this application further combines real-time data of the unified system state with the target requirements of the activation strategy, achieving weight adaptation through a control loop to dynamically adjust the weight ratio of optimization targets such as performance and cost. This allows the weights to change in real time with the business state, ensuring that scheduling decisions are always anchored to the current business priority, avoiding resource mismatch caused by static weights, and improving the system's responsiveness to business fluctuations, thus guaranteeing the stable achievement of business SLAs.

[0044] In particular, in one specific embodiment, Figure 6 This is a flowchart of sub-step S4 of the virtual resource dynamic scheduling method in a hybrid cloud environment according to an embodiment of this application. Figure 6 As shown, step S4 includes: S41, calculating KPI deviations under multiple application contexts for the unified system state and the activated policy object to obtain a KPI deviation set; S42, inputting the KPI deviation set into the PID controller to obtain the aggregated weight update vector; S43, based on the activated policy object, reconstructing and normalizing the aggregated weight update vector to obtain a dynamic weight vector.

[0045] Specifically, step S41 involves calculating the KPI deviation for the unified system state and the activated strategy object under multiple application contexts to obtain a KPI deviation set. It should be understood that dynamic weight adaptation requires determining the adjustment direction based on the gap between business indicators and targets. However, the unified system state only provides real-time KPI data, and the activated strategy object only contains KPI targets. The separation of these two factors makes it impossible to directly obtain adjustment basis, easily leading to blind weight adjustments. Therefore, this application further calculates the deviation by associating real-time KPIs with target values ​​under multiple application group contexts, thereby obtaining specific deviation information for each KPI in each application group. This provides accurate deviation data for subsequent PID control, clarifies the direction and degree of adjustment required for each application group, avoids inaccurate weight adjustments due to a lack of deviation basis, and ensures that deviation calculation covers all controlled application groups, achieving a globally unified adjustment benchmark.

[0046] Specifically, in one possible embodiment, step S41 is implemented as follows: First, all application groups in the activated policy object are traversed, and the corresponding real-time business KPI data in the unified system state is matched for each application group. Second, the KPI target of the application group, such as the P99 latency threshold, is extracted from the activated policy, and the real-time KPI value is compared with the target value. A signed deviation is calculated according to the target rules (such as less than or greater than). Finally, all KPI deviations of each application group are organized according to the structure of application group, KPI name, and deviation value. The deviation information of all application groups is integrated to form a KPI deviation set, ensuring that each deviation corresponds to a specific application scenario.

[0047] Specifically, in step S42, the KPI deviation set is input into the PID controller to obtain the aggregated weight update vector. It should be understood that since the KPI deviation set may contain multiple KPI deviations, such as delay and error rate deviations, and directly converting a single deviation into a weight adjustment amount can easily lead to adjustment oscillations or overshoot, making it impossible to stably approach the target. Therefore, this application further inputs the KPI deviation set into the PID controller to fuse multiple KPI deviation signals and generate a smooth and stable weight update amount. In this way, the proportional term responds to the current deviation, the integral term eliminates static errors, and the derivative term suppresses overshoot, ensuring that the weight adjustment both responds promptly to business changes and avoids drastic fluctuations. Simultaneously, fusing multiple KPI deviations ensures that the adjustment prioritizes addressing the most urgent issues, improving the stability and rationality of the weight adjustment.

[0048] In particular, in one specific embodiment, Figure 7 This is a flowchart of sub-step S42 of the virtual resource dynamic scheduling method in a hybrid cloud environment according to an embodiment of this application. Figure 7As shown, step S42 includes: S421, performing PID control quantization on each KPI deviation signal in the KPI deviation set to obtain an independent weight adjustment set; S422, performing multi-adjustment fusion on the independent weight adjustment set to obtain a unified performance weight increment; S423, applying weight increment and boundary constraints to the unified performance weight increment based on the current performance weight and weight boundary configuration in the activated strategy object to obtain the aggregated weight update vector.

[0049] More specifically, step S421 involves quantizing the individual KPI deviation signals using PID control on each KPI deviation in the KPI deviation set to obtain an independent set of weight adjustment amounts. It should be understood that since the nature and degree of influence of deviations of different KPIs (such as P99 delay and transaction success rate) in the KPI deviation set are different, directly calculating the adjustment amount by mixing multiple KPI deviations together would lead to ambiguity in the adjustment direction; for example, it would be impossible to make a decision when delay needs to be increased or success rate needs to be decreased. Therefore, this application further quantifies each KPI deviation separately using PID control to obtain a specific and precise weight adjustment suggestion for each deviation. This provides a clear single-deviation basis for subsequent fusion of multiple adjustment amounts, avoids mutual interference between different KPI deviations, and ensures that the adjustment needs of each deviation are accurately captured, laying the foundation for targeted weight adjustment.

[0050] Specifically, in one possible embodiment, step S421 is implemented as follows: First, the KPI deviation set is traversed, and each application group, KPI name, and deviation value entry is extracted. Second, preset PID controller parameters are matched for the KPI, such as a gain Kp=0.02 for delay deviation and Kp=0.03 for error rate deviation. The historical deviation value of the KPI is obtained from the system's historical state. Next, the proportional term (current deviation × Kp), integral term (cumulative historical deviation × Ki), and derivative term (deviation change rate × Kd) are calculated, and the sum of these three terms yields the single KPI weight adjustment amount. Finally, all single KPI adjustment amounts are organized according to application group, KPI name, and adjustment amount structure to form an independent weight adjustment amount set, ensuring that each adjustment amount corresponds to a specific KPI problem.

[0051] More specifically, step S422 involves fusing multiple adjustment values ​​from the set of independent weight adjustment values ​​to obtain a unified performance weight increment. It should be understood that, since the set of independent weight adjustment values ​​may contain multiple KPI adjustment values ​​for the same application group, such as a latency adjustment of +0.05 or an error rate adjustment of +0.12, failure to fuse these values ​​would result in the system generating multiple adjustment instructions for the same application group, making it impossible to determine the final adjustment direction and potentially causing scheduling chaos. Therefore, this application further fuses multiple adjustment values ​​for the same application group to obtain a single, clear performance weight increment. This allows for prioritizing responses to the most urgent KPI issues through strategies such as taking the maximum positive impact; for example, if the error rate deviation is more severe, its adjustment value is used, avoiding adjustment instruction conflicts. Simultaneously, it ensures that each application group outputs only one unified increment, simplifying the subsequent weight constraint process.

[0052] In particular, in one specific embodiment, Figure 8 This is a flowchart of sub-step S422 of the virtual resource dynamic scheduling method in a hybrid cloud environment according to an embodiment of this application. Figure 8 As shown, step S422 includes: S4221, classifying the set of independent weight adjustment amounts by application group to obtain a candidate adjustment amount list; S4222, inputting the candidate adjustment amount list into the maximum influence priority selector to obtain the fused performance weight increment; S4223, aggregating the fused performance weight increment by application group to obtain a unified performance weight increment.

[0053] In a specific example of this application, step S4221 involves categorizing the set of independent weight adjustment amounts by application group to obtain a candidate adjustment amount list. It should be understood that since the set of independent weight adjustment amounts is stored in a discrete structure of application group, KPI name, and adjustment amount, adjustment amounts from different application groups are mixed together. Direct fusion would lead to interference between adjustment amounts across application groups, such as confusing latency adjustment amounts from application group A with error rate adjustment amounts from application group B, making it impossible to accurately match business scenarios. Therefore, this application further categorizes and organizes the adjustment amount set by application group dimension to separate the adjustment needs of different application groups. This ensures that the adjustment amounts of each application group are processed independently, avoiding cross-scenario interference, making the fusion process more targeted, and improving the matching accuracy between adjustment amounts and business scenarios.

[0054] Specifically, in a possible embodiment, the implementation process of step S4221 is as follows: First, initialize an empty classification container with the application group identifier as the container key and the adjustment amount list of the application group as the value. Second, traverse each entry in the independent weight adjustment amount set, and extract the application group identifier and the adjustment amount value included in the entry. Then, determine whether the application group identifier already exists in the classification container. If it exists, append the adjustment amount value to the corresponding list. If it does not exist, create a new key-value pair (application group identifier - new list) and add the adjustment amount. Finally, after the traversal is completed, perform a duplicate removal process on the adjustment amount list of each application group, that is, exclude the duplicate calculated adjustment amounts, and form a candidate adjustment amount list containing all application groups. Each list only corresponds to the adjustment requirements of a single application group.

[0055] In a specific example of the present application, in S4222, the candidate adjustment amount list is input into the maximum impact priority selector to obtain the fused performance weight increment. It should be understood that in the candidate adjustment amount list, the multiple adjustment amounts of the same application group may be different. For example, some adjustment amounts are small and some are large. If the average value is simply taken or randomly selected, the adjustment requirements for key business issues will be weakened (such as adopting a small adjustment amount when the error rate seriously exceeds the standard), resulting in the weight adjustment not matching the business urgency. Therefore, the present application further inputs the candidate list into the maximum impact priority selector to screen out the adjustment amount that has the most significant impact on the business. In this way, it can be ensured that the weight adjustment responds to the most urgent KPI deviation first. For example, if the adjustment amount corresponding to the error rate deviation is larger, it will be adopted first, avoiding damage to the business SLA due to insufficient adjustment strength. At the same time, through the positive priority logic of the selector (negative adjustment amounts are not adopted), the performance weight is ensured not to decrease, maintaining business stability.

[0056] Specifically, in a possible embodiment, the implementation process of step S4222 is as follows: First, load the core rule of the maximum impact priority selector, that is, screen out the maximum value in the candidate list, and this value is not less than zero. Second, input the candidate adjustment amount list of the current application group into the selector. The selector traverses the values in the list one by one, excludes all negative values, and retains zero and positive values. Then, if the set of retained values is not empty, take the maximum value in it as the fused performance weight increment. If the set is empty (all adjustment amounts are negative), take zero as the increment (to ensure that the performance weight does not decrease). Finally, the selector outputs the fused performance weight increment and attaches the selection basis, such as selecting 0.12 because it is the maximum value in the series list, ensuring that the adjustment process is traceable.

[0057] In a specific example of this application, S4223, the merged performance weight increments are aggregated by application group to obtain a unified performance weight increment. It should be understood that because the merged performance weight increments are stored dispersedly by application group (e.g., increments for application group A are stored in cache A, and increments for application group B are stored in cache B), there is a lack of unified structured organization. Subsequent weight boundary constraints and weight reconstruction steps require calling the increments of each application group individually, which is inefficient and prone to omissions. Therefore, this application further aggregates the merged increments of all application groups to form a globally unified increment set. This integrates the dispersed increments into structured data, facilitating batch calls in subsequent steps, avoiding omissions of application groups, and improving data processing efficiency through a unified format, such as an application group-increment key-value structure. This ensures that dynamic weight adjustments cover all controlled application groups, achieving unified alignment of global business objectives.

[0058] Specifically, in one possible embodiment, step S4223 is implemented as follows: First, a global aggregation container is initialized, using a key-value structure of application group identifier - merged increment. Second, the merged performance weight increments of all application groups are traversed, with the identifier of each application group as the key and the corresponding merged increment as the value, and stored in the aggregation container. Next, an integrity check is performed on the key-value pairs in the aggregation container to confirm that all application groups existing in the activation policy object are included; if any are missing, a default increment, such as zero, is added. Finally, a preliminary range check is performed on the increment values ​​in the aggregation container, such as excluding abnormal increments greater than 0.5. After confirming that there are no errors, the increments are encapsulated into a unified performance weight increment, which serves as input data for subsequent weight boundary constraint steps.

[0059] More specifically, step S423 involves applying weight increments and boundary constraints to the unified performance weight increment based on the current performance weight and weight boundary configuration in the activated policy object to obtain the aggregated weight update vector. It should be understood that directly adding the unified performance weight increment to the current performance weight may result in extreme values ​​exceeding a reasonable scheduling range (e.g., the weight needs to be between 0.1 and 0.99), leading to subsequent normalization failure or extreme scheduling decisions, such as considering only performance and ignoring cost. Therefore, this application further combines the current performance weight and boundary configuration to apply and constrain the unified increment, thereby correcting extreme values ​​and obtaining a compliant weight update amount. This ensures that the performance weight always remains within an effective range, avoiding scheduling deviations caused by weight imbalance, while providing compliant input for subsequent weight normalization, guaranteeing the mathematical validity and business rationality of the dynamic weight vector.

[0060] Specifically, in one possible embodiment, step S423 is implemented as follows: First, the current performance weight of each application group is extracted from the activated policy object, such as a current weight of 0.7 for a certain application group. Second, the current performance weight is added to the corresponding unified performance weight increment to obtain the initial update weight, such as 0.7 + 0.25 = 0.95. Next, the weight boundary configuration is loaded, such as a minimum performance weight of 0.1 and a maximum performance weight of 0.99. If the initial update weight exceeds the boundary, such as 1.02, it is corrected to 0.99, and the boundary value is replaced. Finally, the corrected weight update amounts of all application groups are integrated to form an aggregated weight update vector, ensuring that each update amount meets the constraint requirement of 0.1 ≤ weight ≤ 0.99, which can be directly used for subsequent normalization processing.

[0061] In particular, in another preferred embodiment, step S42 further includes: dynamically adjusting the contribution weights of the integral and derivative terms in the PID controller using an adaptive gain function based on the KPI deviation, wherein the adaptive gain function includes: a first adaptive gain function whose value decreases as the absolute value of the KPI deviation increases, used to suppress the cumulative effect of the integral term when the system deviation is large; and a second adaptive gain function whose value decreases as the absolute value of the KPI deviation decreases, used to suppress the excessive response of the derivative term to noise when the system tends to stabilize.

[0062] In other words, for the output term of the PID controller, namely the proportional term... Integral terms and differential terms The three components are fused according to their data properties and roles in the control cycle to generate independent adjustment quantities. Specifically, the proportional term is instantaneous and dominant, directly reflecting the magnitude of the current deviation and serving as the main driving force for the controller's response. When the system experiences a large, sudden shock (e.g., a flow peak), the proportional term immediately generates a large output, attempting to quickly correct the deviation. The integral term is historical and memory-based, accumulating the sum of all past deviations. Its main function is to eliminate small static errors that still exist after the system reaches stability. Its disadvantages are slow response and the risk of integral saturation. That is, if the system cannot eliminate the deviation for a long time due to some reason (e.g., resources have reached their limit), the integral term will accumulate indefinitely, causing severe overshoot when the system regains control capability. The derivative term is predictive and damping, reflecting the speed (trend) of deviation changes. Its function is to anticipate the future direction of the deviation and apply a counterforce in advance, thereby suppressing system oscillations and overshoot. Its main disadvantage is that it is very sensitive to high-frequency noise in the input signal; even small KPI fluctuations can cause drastic fluctuations in the D-term output, resulting in system instability.

[0063] Therefore, the proportional term varies at different control stages. Integral terms and differential terms The importance and applicability of these three factors differ. In the initial stage of a sharp increase in deviation, it is desirable to use the proportional term. and differential terms Rapid response, and integral terms It's best to avoid participating to prevent accumulating excessive debt (point saturation). During the stable period approaching the target, it's desirable to optimize the point allocation. It functions to eliminate steady-state error, while the proportional term The effect weakens, the differential term Provides necessary damping. During system oscillations, the differential term... It is of the highest importance.

[0064] Therefore, based on the KPI deviation, it is necessary to dynamically adjust the contribution weights of the integral and derivative terms in the PID controller using an adaptive gain function, that is, based on the current system state (i.e., the deviation). (and the characteristics of its rate of change dE / dt), dynamically adjusting the proportional term. Integral terms and differential terms The weights of the three terms in the final output are used to achieve PID weighted fusion of adaptive gain. That is, by introducing two adaptive gain functions that depend on the system state. and This is used to dynamically adjust the contributions of the integral and differential terms, expressed as: ;in, Output as a proportional term. Output the integral term. Output the differential term. For KPI deviation, The first adaptive gain function is... This is the second adaptive gain function. This indicates the amount of weight adjustment for a single KPI.

[0065] Here, to simplify the model and maintain the dominant role of the scaling term as the cornerstone of the response, the gain of the scaling term is set to a constant of 1.

[0066] To suppress integral saturation, the integral term is fully introduced only when the deviation is small and the system tends to stabilize. When the deviation is large, the influence of the integral term is significantly reduced or even completely removed. A first adaptive gain function can be used, whose value decreases as the absolute value of the KPI deviation increases. This function is used to suppress the cumulative effect of the integral term when the system deviation is large. For example, a Gaussian function can be used. ;in, It is an adjustable normal value used to control the rate of decay. When it is 0, =1, integral term When fully introduced, when | When the value increases, the exponent term becomes a large negative number. It quickly approaches 0, effectively shutting down the integral term and thus avoiding the accumulation of invalid integrals during periods of severe system fluctuation.

[0067] Furthermore, it is necessary to balance the damping effect of the derivative term with its noise sensitivity. Specifically, its damping effect should be enhanced when the deviation is large and the system is likely to undergo drastic changes, while its influence should be weakened when the deviation is small, the system is stable, and the deviation change is primarily caused by noise. Therefore, a second adaptive gain function is introduced, whose value decreases as the absolute value of the KPI deviation decreases. This function is used to suppress the excessive response of the derivative term to noise when the system tends to stabilize. In other words, it is desirable for the derivative term to play a role when the deviation is large and there is a risk of overshoot, while its effect should be suppressed in the stable region to prevent noise interference. ;in, It is also an adjustable positive constant; this function is similar to... The opposite behavior: when When it is 0, Setting it to 0 effectively shuts off the differential term, preventing excessive response to noise near the stable point. When | When it gets bigger, It rapidly approaches 1, causing the differential term to... It can fully exert its predictive and damping functions to prevent the system from going out of control or causing serious overshoot.

[0068] Thus, when a hybrid cloud system encounters persistent, non-resolvable performance issues (e.g., a regional public cloud failure preventing scaling), adaptive gain... The integral term will approach 0 due to the continuous large deviation, thus freezing the accumulation of the integral term and effectively preventing integral saturation. Once the fault is recovered, the system will not experience severe weight overshoot due to the huge historical integral term, but will be able to recover to the normal state more smoothly and quickly, with stronger robustness and anti-saturation ability.

[0069] Meanwhile, in the initial stage of system response to a sudden surge in traffic, Very small It is very large at this time. The control action mainly consists of the rapid response of the proportional term and the early suppression of the derivative term. The system can quickly and decisively increase the performance weights and is not prone to overshoot. As the system gradually stabilizes, the deviation... When decreasing, Gradually increase to 1, Gradually decrease to 0, The integral term then intervenes, precisely eliminating residual static errors and ensuring that business KPIs remain accurately stable at the target value. The entire process achieves a smooth transition between different control stages, balancing speed and stability, and exhibiting superior dynamic response characteristics.

[0070] Furthermore, when the system is running stably and the KPIs fluctuate slightly around the target value, these fluctuations often represent measurement noise. Because at this time... It's very small. As the value approaches zero, the output of the differential term is effectively suppressed, avoiding frequent and ineffective fine-tuning of scheduling weights due to irrelevant KPI noise, which greatly enhances the stability of the entire scheduling system.

[0071] Specifically, in step S43, based on the activated policy object, the aggregated weight update vector is reconstructed and normalized to obtain a dynamic weight vector. It should be understood that since the aggregated weight update vector only includes adjustments to the primary optimization objective (e.g., performance) and does not cover other objectives (e.g., cost), and the sum of the adjusted weights may not be 1, it cannot be directly used for scheduling scoring. Therefore, this application further combines the initial weight configuration in the activated policy to reconstruct and normalize the update vector, thereby completing all optimization objective weights and ensuring the sum is 1. This forms a complete and effective weight vector, avoiding scheduling decision errors caused by missing weights or imbalanced sums, while ensuring the weights meet mathematical validity requirements and can be directly input into subsequent weighted scoring stages, improving the efficiency and accuracy of scheduling decisions.

[0072] Specifically, in one possible embodiment, step S43 is implemented as follows: First, extract the initial weights (such as cost weights) of other optimization objectives besides the primary objective from the activated policy object for each application group. Second, integrate the primary objective adjustment amount in the aggregated weight update vector with the initial weights of other objectives to reconstruct a complete weight vector containing all optimization objectives. Next, calculate the sum of the reconstructed weight vectors, and normalize each weight using the sum as the denominator to ensure that the sum of all weights is exactly 1. Finally, organize the normalized weights of each application group according to the optimization objective and weight value structure, and integrate the weight information of all application groups to form a dynamic weight vector, ensuring that it can be directly used for weighted calculation in subsequent scheduling decisions.

[0073] In the aforementioned method for dynamic scheduling of virtual resources in a hybrid cloud environment, step S5 involves obtaining a new task request. It should be understood that since the core of hybrid cloud virtual resource scheduling is allocating suitable nodes for virtual resource tasks (such as virtual machines and containers) to be deployed, the new task request is the sole trigger for the scheduling process. Furthermore, the request contains crucial information such as the task's resource requirements (e.g., CPU and memory specifications) and business affiliation (e.g., the application group to which it belongs). The absence of this information would lead to subsequent scheduling decisions lacking clear targets and basis. Therefore, this application further captures new task requests to be scheduled and parses key attributes to clarify the task's deployment requirements and business association. This provides precise targeting for subsequent weighted scoring and scheduling decisions, ensuring that scheduling behavior revolves around specific tasks, avoiding blind decisions due to missing task information, and by clarifying the application group affiliation, enabling tasks to match corresponding dynamic weights, ensuring that deployment results are aligned with current business priorities.

[0074] Specifically, in one possible embodiment, step S5 is implemented as follows: First, the system continuously listens for new task requests through a preset task access interface (such as the REST API of a hybrid cloud management platform or the Pod request interface of a container scheduling system). When a request message is detected, the processing flow is triggered immediately. Second, the request parsing module is called to extract the core attributes of the task from the message, including the required number of vCPU cores, memory capacity, whether GPU acceleration is required, the application group identifier, and service level requirements (such as core task / non-core task). Next, the extracted attributes are validated to confirm that the resource requirements are within the system's supported range (such as not exceeding the maximum instance specification) and that the application group identifier exists in the known application group list. Finally, the validated task information is encapsulated into a structured new task object and stored in the task scheduling queue, providing complete and compliant input data for the subsequent weighted scoring steps.

[0075] In the aforementioned method for dynamic virtual resource scheduling in a hybrid cloud environment, step S6 involves weighted scoring and scheduling decisions for new task requests based on dynamic weight vectors and unified system status to obtain placement decisions. These placement decisions include the final selected target node. It should be understood that since new task requests only specify deployment requirements, dynamic weight vectors only reflect current business priorities (e.g., performance weights, cost weights), and unified system status only presents resource and cost status, these three factors exist independently and cannot directly determine the task deployment node. This can easily lead to node selection deviating from business objectives (e.g., deploying core tasks to low-performance nodes) or actual resource conditions (e.g., selecting a fully loaded private cloud host). Therefore, this application further combines these three factors for weighted scoring and quantitative decision-making to select target nodes from candidate nodes that simultaneously meet task requirements, business priorities, and resource status. This ensures that node selection considers multiple dimensions, avoids resource mismatch or cost waste, and achieves objective decision-making through weighted scoring, improving scheduling accuracy and ensuring that task deployment meets both Service Level Agreements (SLAs) and current business optimization goals.

[0076] Specifically, in one possible embodiment, step S6 is implemented as follows: The system first listens for a new task request, which is a specific user uploading a 10GB video file to a video editing collaboration group. The system parses the resource requirements of the task for high storage IO and network throughput and determines its application group. Next, the scheduler performs a weighted scoring on candidate nodes (such as high-performance SSD nodes in a private cloud and standard object storage nodes in a public cloud) selected from the unified system state, based on the dynamic weight vector corresponding to the application group (e.g., adjusting the performance weight to 0.8 and the cost weight to 0.2 during peak business periods). Private cloud SSD nodes receive extremely high performance scores due to their low latency and high IOPS, while public cloud nodes have higher cost scores but lower performance scores. After the scheduler calculates the total score according to the formula "Total Score = Performance Score × Performance Weight + Cost Score × Cost Weight", the private cloud SSD node receives the highest total score. Finally, the system selects the node with the highest total score as the target node, generates a placement decision containing the node's unique identifier and deployment parameters, and schedules the backend storage resources of the upload task to the private cloud SSD node to ensure a smooth experience for large file uploads and meet business intent. At the same time, the decision-making process is recorded in the audit log.

[0077] In summary, the method for dynamic scheduling of virtual resources in a hybrid cloud environment based on the embodiments of this application is explained. It captures and parses abstract business requirement specifications, translating them into machine-understandable and activatable scheduling policy objects. Simultaneously, it integrates the resource status, multi-cloud pricing model, and real-time business KPI stream in the underlying hybrid cloud environment to form a globally unified system state view. Based on this, an adaptive mechanism based on a control loop is introduced. Guided by the activation policy derived from intent parsing, it uses multiple optimization indicators as dynamically adjustable decision factors for continuous weight vector optimization and generation. Finally, the scheduler uses this set of dynamic weights to intelligently weight and score new task requests and make the optimal placement decision. This enables an intelligent decision-making closed loop from business intent definition to resource scheduling execution, thereby improving resource allocation efficiency and business agility in the hybrid cloud environment.

[0078] Figure 9 This is a block diagram of a virtual resource dynamic scheduling system in a hybrid cloud environment according to an embodiment of this application. Figure 9 As shown, a virtual resource dynamic scheduling system 100 in a hybrid cloud environment according to an embodiment of this application includes: a business intent specification acquisition module 110, used to acquire business intent specifications; an intent parsing and target translation module 120, used to perform intent parsing and target translation on the business intent specifications to obtain activated policy objects; a multi-dimensional state fusion perception module 130, used to perform multi-dimensional state fusion perception on the acquired resource state data, price data, and business KPI stream to obtain a unified system state; a dynamic weight adaptation module 140, used to perform dynamic weight adaptation based on control loops on the unified system state and activated policy objects to obtain a dynamic weight vector; a new task request acquisition module 150, used to acquire new task requests; and a weighted scoring and scheduling decision module 160, used to perform weighted scoring and scheduling decisions on new task requests based on the dynamic weight vector and the unified system state to obtain a placement decision, wherein the placement decision includes the finally selected target node.

[0079] As described above, the virtual resource dynamic scheduling system 100 in a hybrid cloud environment according to the embodiments of this application can be implemented in various wireless terminals, such as servers with a virtual resource dynamic scheduling algorithm in a hybrid cloud environment. In one possible implementation, the virtual resource dynamic scheduling system 100 in a hybrid cloud environment according to the embodiments of this application can be integrated into the wireless terminal as a software module and / or a hardware module. For example, the virtual resource dynamic scheduling system 100 in a hybrid cloud environment can be a software module in the operating system of the wireless terminal, or it can be an application developed for the wireless terminal; of course, the virtual resource dynamic scheduling system 100 in a hybrid cloud environment can also be one of many hardware modules of the wireless terminal.

[0080] Alternatively, in another example, the virtual resource dynamic scheduling system 100 and the wireless terminal in the hybrid cloud environment can also be separate devices, and the virtual resource dynamic scheduling system 100 in the hybrid cloud environment can be connected to the wireless terminal via wired and / or wireless networks, and transmit interactive information in accordance with the agreed data format.

[0081] Those skilled in the art will understand that the specific operations of each step in the above-described virtual resource dynamic scheduling system in a hybrid cloud environment have been referenced above. Figures 1 to 8 The description of the dynamic scheduling method for virtual resources in a hybrid cloud environment has been detailed, and therefore, its repeated description will be omitted.

Claims

1. A method for dynamically scheduling virtual resources in a hybrid cloud environment, the method comprising: The method comprises the following steps: acquiring a business intention specification; performing intention analysis and target translation on the business intention specification to obtain an activated strategy object; performing multi-dimensional state fusion sensing on the acquired resource state data, price data and business KPI stream to obtain a unified system state, the unified system state comprising a timestamp, a private cloud state, a public cloud state, a business KPI state and an active load list; performing dynamic weight adaptation based on a control loop on the unified system state and the activated strategy object to obtain a dynamic weight vector; acquiring a new task request; performing weighted scoring and scheduling decision on the new task request based on the dynamic weight vector and the unified system state to obtain a placement decision, the placement decision comprising a finally selected target node; wherein the dynamic weight adaptation based on the control loop on the unified system state and the activated strategy object to obtain the dynamic weight vector comprises: performing KPI deviation calculation in a multi-application context on the unified system state and the activated strategy object to obtain a KPI deviation set; inputting the KPI deviation set into a PID controller to obtain an aggregated weight update vector; performing weight vector reconstruction and normalization on the aggregated weight update vector based on the activated strategy object to obtain the dynamic weight vector.

2. The method of claim 1, wherein, The intention analysis and target translation on the business intention specification to obtain the activated strategy object comprises: performing structured analysis and verification on the business intention specification to obtain a filtered intention list; performing intention semantic translation and KPI target concretization on the filtered intention list based on an intention-to-KPI mapping library to obtain a concretized strategy segment list; performing activated strategy object aggregation on the concretized strategy segment list based on a default strategy configuration to obtain the activated strategy object.

3. The method of claim 2, wherein, The structured analysis and verification on the business intention specification to obtain the filtered intention list comprises: performing basic syntax analysis on the business intention specification to obtain an original intention object list; performing intention object mode checking and data standardization on the original intention object list to obtain a checked intention object list; performing time context filtering on the checked intention object list based on a current system time to obtain the filtered intention list.

4. The method of claim 1, wherein, The multi-dimensional state fusion sensing on the acquired resource state data, price data and business KPI stream to obtain the unified system state comprises: performing data cleaning and standardization conversion on the resource state data, price data and business KPI stream based on a standard model definition to obtain a standardized data segment set; performing timestamp alignment and state snapshot aggregation on the standardized data segment set to obtain the unified system state.

5. The method of claim 1, wherein, The inputting of the KPI deviation set into the PID controller to obtain the aggregated weight update vector comprises: performing PID control quantization of a single KPI deviation signal on each KPI deviation in the KPI deviation set to obtain an independent weight adjustment amount set; performing multi-adjustment amount fusion on the independent weight adjustment amount set to obtain a unified performance weight increment; performing weight increment application and boundary constraint on the unified performance weight increment based on a current performance weight in the activated strategy object and a weight boundary configuration to obtain the aggregated weight update vector.

6. The method of claim 5, wherein, The independent weight adjustment amount set is fused to obtain a unified performance weight increment, including: classifying the independent weight adjustment amount set by application group to obtain a candidate adjustment amount list; inputting the candidate adjustment amount list into a maximum influence priority selector to obtain a fused performance weight increment; and performing application group aggregation on the fused performance weight increment to obtain a unified performance weight increment.

7. The method of claim 5, wherein, The KPI deviation set is input into a PID controller to obtain an aggregated weight update vector, further including: dynamically adjusting the contribution weights of the integral term and the differential term in the PID controller according to the KPI deviation, using an adaptive gain function, wherein the adaptive gain function includes: a first adaptive gain function whose value decreases with the increase of the absolute value of the KPI deviation, used to suppress the cumulative effect of the integral term when the system deviation is large; and a second adaptive gain function whose value decreases with the decrease of the absolute value of the KPI deviation, used to suppress the excessive response of the differential term to noise when the system tends to be stable.

8. A virtual resource dynamic scheduling system in a hybrid cloud environment, characterized in that, The method comprises: a business intent specification obtaining module configured to obtain a business intent specification; an intent analysis and target translation module configured to perform intent analysis and target translation on the business intent specification to obtain an activated policy object; a multi-dimensional state fusion perception module configured to perform multi-dimensional state fusion perception on the obtained resource state data, price data and business KPI flow to obtain a unified system state, the unified system state including a timestamp, a private cloud state, a public cloud state, a business KPI state and an active load list; a dynamic weight adaptation module configured to perform dynamic weight adaptation based on a control loop on the unified system state and the activated policy object to obtain a dynamic weight vector; a weighted scoring and scheduling decision module configured to perform weighted scoring and scheduling decision on the new task request based on the dynamic weight vector and the unified system state to obtain a placement decision, the placement decision including a finally selected target node. The method further comprises: performing KPI deviation calculation on the unified system state and the activated policy object under a multi-application context to obtain a KPI deviation set; and inputting the KPI deviation set into a PID controller to obtain an aggregated weight update vector; and performing weight vector reconstruction and normalization on the aggregated weight update vector based on the activated policy object to obtain the dynamic weight vector.

Images