Resource management method, apparatus, device, medium, product

Abstract

The application is suitable for the computer technology field, and particularly relates to a resource management method, device, equipment, medium and product, the method comprising: acquiring service configuration data and historical resource data of a plurality of tenant objects in a cloud environment, and constructing an object behavior portrait; acquiring resource load data at a first time; based on the object behavior portrait, target resources are respectively scheduled for each tenant object at a second time based on the resource load data, wherein each tenant object corresponds to an independent running environment. The application effectively solves the problems of unbalanced resource allocation and response lag in a multi-tenant environment by combining historical behavior portraits and real-time load data for forward-looking resource scheduling, thereby improving resource utilization and system stability.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and in particular relates to a resource management method, apparatus, equipment, medium, or product. Background Technology

[0002] With the rapid development of cloud computing technology, multi-tenancy has become the standard architecture for cloud platform services, widely used in various scenarios such as internet services, enterprise information systems, and big data analytics. In this model, multiple tenants share the same physical infrastructure, and the cloud platform allocates computing, storage, and network resources to different tenants through virtualization or containerization technologies.

[0003] Existing cloud resource management solutions typically allocate resources based on preset static configurations or simple real-time load thresholds. The system collects current resource usage metrics from tenants, such as CPU utilization and memory usage, and maps available resources to each tenant object according to a pre-defined Service Level Agreement (SLA) or fixed quota policy. When a tenant's resource usage reaches a set limit, the system triggers corresponding alarms or performs basic scaling operations to maintain normal business operations.

[0004] However, in existing technologies, it is often difficult to achieve accurate matching and dynamic optimization of resource allocation when facing complex and ever-changing business loads in a multi-tenant environment. Summary of the Invention

[0005] This application provides a resource management method, apparatus, device, medium, and product, aiming to solve the technical problems of uneven multi-tenant resource allocation and lack of dynamic adjustment mechanism in existing cloud platforms, especially the inability to intelligently respond when facing changing loads.

[0006] In a first aspect, embodiments of this application provide a resource management method applied to a cloud platform, wherein a cloud environment runs on the cloud platform, and the method includes: Obtain service configuration data and historical resource data corresponding to multiple tenant objects in the cloud environment. The service configuration data is used to indicate the configuration requirements of the tenant object when the cloud platform provides business services to the tenant object. The historical resource data is used to indicate the resource usage of the tenant object in a historical period. Based on the service configuration data and the historical resource data, construct an object behavior profile corresponding to the tenant object; Obtain the resource load data corresponding to the multiple tenant objects at the first moment; Based on the object behavior profile, target resources are scheduled for the multiple tenant objects at a second time based on the resource load data. The tenant objects have independent operating environments when performing target services in the cloud environment. The second time is a time after the first time.

[0007] In some embodiments, scheduling target resources for the multiple tenant objects at a second time based on the resource load data, using the object behavior profile as a benchmark, includes: Based on the object behavior profile, the resource scheduling requirements of the multiple tenant objects at the second time point are predicted based on the resource load data. Based on the resource scheduling requirements corresponding to the multiple tenant objects, the target resources are scheduled for each of the multiple tenant objects.

[0008] In some embodiments, scheduling the target resource for each of the multiple tenant objects based on their respective resource scheduling requirements includes: Identify the schedulable resources in the cloud environment; Based on the resource scheduling requirements corresponding to the multiple tenant objects, the resource prediction results corresponding to the multiple tenant objects at the second time point are determined. Based on the resource prediction results and preset scheduling rules, the target resources are dynamically scheduled for the multiple tenant objects from the schedulable resources.

[0009] In some embodiments, the plurality of tenant objects includes a first tenant object, the first tenant object corresponding to a first prediction result, and the first prediction result corresponding to a first resource quantity; The step of dynamically scheduling the target resources for the multiple tenant objects from the schedulable resources based on the resource prediction results and preset scheduling rules includes: If the resource load data of the first tenant object meets the surge condition, a second resource quantity is scheduled to the first tenant based on the first prediction result and the preset scheduling rule, and the second resource quantity is greater than the first resource quantity.

[0010] In some embodiments, the service configuration data includes at least one of the following: the service type, service priority, or service level corresponding to the tenant object.

[0011] In some embodiments, the method further includes: The multiple tenant objects are provided with independent operating environments by means of preset isolation rules, wherein the preset isolation rules include at least one of virtual isolation rules, container isolation rules, or logical differentiation rules.

[0012] Secondly, embodiments of this application provide a resource management device, the device comprising: The acquisition module is used to acquire service configuration data and historical resource data corresponding to multiple tenant objects in the cloud environment. The service configuration data is used to indicate the configuration requirements of the tenant object when the cloud platform provides business services to the tenant object. The historical resource data is used to indicate the resource usage of the tenant object in a historical period. The construction module is used to construct an object behavior profile corresponding to the tenant object based on the service configuration data and the historical resource data; The acquisition module is used to acquire the resource load data corresponding to the multiple tenant objects at a first moment; The scheduling module is used to schedule target resources for the multiple tenant objects respectively based on the object behavior profile and the resource load data at a second time, wherein the tenant objects have an independent running environment when performing target business in the cloud environment, and the second time is a time after the first time.

[0013] Thirdly, embodiments of this application provide a computer device including a memory, one or more processors, and a computer program stored in the memory and executable on the one or more processors, wherein when the one or more processors execute the computer program, the computer device performs the method as described in any embodiment of the first aspect.

[0014] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in any embodiment of the first aspect.

[0015] Fifthly, embodiments of this application provide a computer program product, including a computer program that, when run on an electronic device, causes the electronic device to perform the method described in any of the embodiments of the first aspect.

[0016] It is understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant descriptions in the first aspect above, and will not be repeated here.

[0017] The beneficial effects corresponding to the embodiments of this application are as follows: By acquiring service configuration data and historical resource data from multiple tenant objects in the cloud environment, and constructing object behavior profiles accordingly, and then combining this with resource load data collected in the first moment, target resources are dynamically scheduled in the second moment based on these object behavior profiles. By integrating the business needs indicated by service configuration data with the usage patterns reflected by historical resource data, object behavior profiles that characterize tenant behavior are constructed. This allows resource scheduling to no longer rely solely on instantaneous load but to possess predictive capabilities based on historical trends. Furthermore, the profiles are corrected and supplemented using real-time resource load data from the first moment, thereby accurately scheduling target resources matching the actual needs of each tenant object in the subsequent second moment, ensuring that each tenant executes its business in an independent operating environment. This dual-driven mechanism of historical profiles combined with real-time load enables the system to proactively identify resource demand trends and adjust accordingly, effectively solving the problems of lagging, unbalanced, and unresponsive resource allocation in existing technologies when facing dynamically changing loads. Therefore, it avoids the decline in business performance due to insufficient resource supply or the waste of resources due to over-allocation, improves the resource utilization, system stability and service response consistency of the cloud platform in a multi-tenant environment, realizes the transformation from passive response to proactive prediction and optimization, and ensures the efficient and secure operation of multi-tenant services. Attached Figure Description

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

[0019] Figure 1 This is a flowchart of a resource management method provided in an embodiment of this application; Figure 2 This is a structural block diagram of a resource management device provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0020] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0021] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0022] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0023] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0024] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0025] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0026] In business scenarios, with the rapid development of cloud computing technology, multi-tenancy has become the mainstream architecture for cloud platforms. Existing cloud resource management technologies typically employ fixed quotas or static allocation strategies based on current instantaneous load. However, this traditional approach has significant limitations: firstly, fixed resource allocation cannot detect the cyclical fluctuations and sudden changes in tenant business, leading to significant resource idleness and waste during off-peak periods and insufficient resource supply during peak periods, causing service degradation; secondly, existing scheduling mechanisms often lack in-depth analysis of tenant historical behavior patterns, making it difficult to predict future resource demand trends based on historical data, resulting in lagging resource scheduling and an inability to achieve forward-looking dynamic adjustments. Furthermore, with the surge in the number of tenants and the diversification of business types, existing methods, while ensuring multi-tenant isolation security, struggle to balance the efficiency and fairness of resource allocation, and the system's scalability and intelligence level need improvement.

[0027] To systematically address the above problems, this application provides a resource management method.

[0028] like Figure 1 As shown, the resource management method provided in this application includes the following steps: S101, obtain service configuration data and historical resource data corresponding to multiple tenant objects in the cloud environment.

[0029] Among them, service configuration data is used to indicate the configuration requirements of the tenant object when the cloud platform provides business services to the tenant object, and historical resource data is used to indicate the resource usage of the tenant object in a historical period.

[0030] Service configuration data refers to a set of parameters recorded by the cloud platform during initialization or operation that reflects the tenant's business attributes and service quality requirements. Specifically, service configuration data includes at least one of the following: the business type, business priority, or service level (SLA) corresponding to the tenant object.

[0031] Service type distinguishes the types of applications a tenant runs, such as big data analytics, real-time transaction processing, or video streaming services; service priority identifies the order in which different tenants compete for resources; and service level defines the performance metrics the system promises to tenants, such as response time limits or availability ratios. This data originates from configuration files submitted by tenants during cloud platform registration or from policy information dynamically updated via management interfaces during operation. The service configuration data serves as the fundamental constraint for resource scheduling, ensuring that allocated resources meet the service quality standards agreed upon by the tenants.

[0032] Historical resource data refers to a sequence of records of computing, storage, and network resources actually consumed by a tenant within a specific time period. This data is periodically collected and stored by monitoring probes on the cloud platform, with a time granularity of minutes, hours, or days. Historical resource data includes dimensions such as CPU utilization curves, peak memory usage, disk I / O throughput, and network bandwidth usage. The purpose of this data is to reflect the operational patterns of tenants' businesses, such as identifying a tenant with a fixed computing peak every Friday afternoon, or a type of business exhibiting a significant tidal effect.

[0033] To illustrate, consider a tenant on an e-commerce platform. Its service configuration data shows its business type is online transactions, its service level is Gold, and it requires a response time of less than 50ms. Its historical resource data shows that during the annual Double Eleven shopping festival, this tenant's CPU utilization surges from the usual 20% to 90%, lasting approximately 48 hours. By combining these two types of data, the system can anticipate that this tenant not only has high performance requirements but also exhibits periodic, explosive resource demands.

[0034] This step aims to provide comprehensive and accurate data support for subsequent resource scheduling decisions. By acquiring multi-dimensional service configuration data and long-term historical resource data, the system can overcome the limitations of relying solely on instantaneous load for decision-making, laying the foundation for building accurate tenant behavior models and effectively avoiding resource allocation deviations caused by missing information.

[0035] S102, construct the object behavior profile corresponding to the tenant object based on service configuration data and historical resource data.

[0036] Among them, object behavior profiles can refer to digital models generated through data analysis technology that can characterize tenant object resource usage habits, business fluctuation patterns, and potential demand trends.

[0037] In illustrative terms, object behavior profiling is obtained through feature extraction, pattern recognition, and statistical modeling of the aforementioned service configuration data and historical resource data. Specifically, the system uses machine learning algorithms or statistical analysis methods to extract key indicators such as peak and valley characteristics, growth trends, and periodic fluctuation factors from historical resource data, and combines these with priority weights and service level coefficients from the service configuration data to comprehensively construct the profile. The role of object behavior profiling is to transform discrete historical data into predictable behavioral logic, serving as a benchmark for subsequent resource scheduling.

[0038] The object behavior profile consists of static feature vectors and dynamic prediction functions. Static feature vectors include tenant business type labels and baseline values ​​for general resources; dynamic prediction functions describe the mathematical relationship between resource demand and time changes, such as linear regression models or time series prediction models. When historical resource data is updated, the object behavior profile can trigger a retraining mechanism for iterative updates to adapt to changes in tenant business models.

[0039] As an illustration, the behavioral profile constructed for the aforementioned e-commerce tenant might include a peak sales surge coefficient, calculated based on the ratio of resource increments during historical Double Eleven periods to the usual baseline. The profile also marks the tenant as belonging to a high-priority, highly cyclical category. Based on this profile, the system no longer passively waits for load increases but can predict when the tenant will experience resource shortages at specific time points.

[0040] S103, obtain the resource load data corresponding to multiple tenant objects at the first moment.

[0041] Resource load data can refer to a snapshot of the physical or virtual resources actually occupied by multiple tenant objects at the current point in time (i.e., the first moment). Resource load data is collected through polling or event-driven methods by the cloud platform's real-time monitoring components.

[0042] Unlike historical resource data, resource load data reflects the real-time state of the system, including current instantaneous CPU utilization, remaining memory capacity, network queue length, etc. The purpose of resource load data is to serve as a direct signal to trigger resource scheduling actions, verifying whether the current system state has deviated from its expected trajectory or whether there are sudden abnormal loads.

[0043] The first moment is a dynamic point in time, which can be a preset fixed period (such as every 10 seconds) or a moment triggered by a specific event (such as a tenant's load exceeding a threshold). Methods for obtaining resource load data include, but are not limited to, calling cloud platform API interfaces, reading performance counters in the virtualization layer, or parsing container engine statistical logs.

[0044] To illustrate, at the first moment t1, the monitoring component detected that tenant A's current CPU utilization was 45% and tenant B's memory utilization was 80%. This real-time data reflects the actual load of the system at moment t1 and is a direct basis for determining whether immediate intervention and adjustment are needed.

[0045] This step enables real-time awareness of the cloud environment's operational status. By accurately capturing the instantaneous load of each tenant, the system can promptly identify potential congestion risks or resource idleness, providing accurate input conditions for the next stage of scheduling execution and ensuring the timeliness of resource management.

[0046] S104, based on the object behavior profile, schedules target resources for multiple tenant objects at the second time based on resource load data.

[0047] Among them, when a tenant object executes the target business in the cloud environment, it has an independent running environment, and the second moment is the moment after the first moment.

[0048] The target resource refers to computing, storage, or network resource units dynamically allocated or adjusted to meet the operational needs of tenant objects. The scheduling of the target resource is determined jointly by the predictive benchmark provided by the object behavior profile and the real-time status reflected by resource load data. Specifically, the system compares the resource load data acquired at the first moment with the predicted trend in the object behavior profile. If a deviation is found between the real-time load and the predicted trend, or if a business peak is predicted to arrive soon, a scheduling instruction is generated. The target resource is allocated at the second moment, which is after the first moment. There may be a very short processing delay between the two moments, or it could be a preset future time point (such as reserving resources 5 minutes in advance).

[0049] In this context, an independent runtime environment refers to a logically or physically isolated execution space for each tenant object on the cloud platform, ensuring that the business operations of different tenants do not interfere with each other. An independent runtime environment is achieved through preset isolation rules, including at least one of the following: virtual isolation rules (such as virtual machine hypervisor isolation), container isolation rules (such as Docker / Kubernetes namespace and Cgroups isolation), or logical differentiation rules (such as VLAN network isolation). This isolation mechanism ensures that when scheduling target resources to a tenant, it does not infringe upon the established resource boundaries of other tenants, nor does it cause data leakage.

[0050] To illustrate, if the user behavior profile predicts that tenant A will experience a traffic surge in 10 minutes (the second moment), and the load data from the first moment shows that its current resource reserves are insufficient to support the upcoming growth, the system will immediately initiate a scheduling process. Before or when the second moment arrives, it will automatically allocate additional CPU cores and memory bandwidth from the resource pool to tenant A's independent operating environment. Simultaneously, for tenant C, who is experiencing a low-traffic period, the system may reclaim some of its idle resources to supplement the public resource pool.

[0051] Optionally, based on the object behavior profile, the resource scheduling requirements of multiple tenant objects at the second time point are predicted according to resource load data.

[0052] The object behavior profile refers to a digital model formed by in-depth mining and feature extraction of historical resource data and service configuration data of tenant objects. It includes multi-dimensional information such as the tenant object's business cycle patterns, resource usage peak and valley characteristics, probability of sudden traffic spikes, and business priority weights. Resource scheduling requirements refer to the amount of computing, storage, or network resources urgently needed by the tenant object at a specific future time point (i.e., the second moment) to maintain the normal operation of the target business or achieve preset service quality standards. Specifically, this step uses the real-time resource load data acquired at the first moment as an input variable, substitutes it into the predictive model built based on the object behavior profile, and uses time series analysis or machine learning algorithms to deduce the changing trend of resource load, thereby quantifying and outputting the resource scheduling requirements at the second moment.

[0053] To illustrate, if a tenant's behavior profile shows a consistent business peak between 10:00 AM and 11:00 AM daily, and historical data indicates a typical 40% surge in CPU utilization during this period, the predictive model will combine this real-time situation with historical profile characteristics to calculate the additional 50% CPU computing power required for resource scheduling at a second time (e.g., 10:15 AM). This predictive mechanism, based on the fusion of profile data and real-time data, can proactively identify potential resource bottlenecks, transforming passive response into proactive defense and providing reliable data support for subsequent precise scheduling.

[0054] Optionally, target resources can be scheduled for each tenant object based on the resource scheduling requirements corresponding to each tenant object.

[0055] In this context, "integration" refers to the process by which the cloud platform scheduler, after receiving resource scheduling requests from all tenants, comprehensively plans resource allocation strategies based on the preset global resource pool status and the service level agreements (SLAs) of each tenant. Target resources can refer to specific physical or virtual resource units allocated from the cloud platform's available resource pool to a particular tenant, including virtual machine instances, container groups, bandwidth quotas, or storage space. Specifically, this step first aggregates the resource scheduling requests of multiple tenants to form a global demand view. Then, it checks the total amount of schedulable resources in the cloud environment. If schedulable resources are sufficient, target resources are directly allocated to each tenant according to the predicted demand. If resources are scarce, weighted arbitration is performed based on the business priority in the service configuration data, prioritizing the supply of target resources to high-priority tenants and implementing degraded scheduling or queuing strategies for low-priority tenants.

[0056] To illustrate, when the system predicts that a first tenant requires 10 compute cores due to a sudden surge in business demand, while a second tenant only needs 2 compute cores, but currently only 8 cores are available, if the first tenant's business priority is higher than the second tenant's, the scheduler will prioritize allocating 8 cores to the first tenant or allocate 6 cores based on its SLA guarantee baseline and trigger emergency expansion, while simultaneously suspending the second tenant's non-critical resource requests. This step, based on the accurate prediction results generated in the previous step, achieves refined and differentiated resource allocation, avoiding resource idleness or contention conflicts caused by traditional static allocation. Therefore, the cloud platform can complete resource pre-positioning or dynamic migration before the second moment arrives, ensuring that tenants have a continuous and stable operating environment when executing their target business, significantly improving the overall resource utilization and business response speed of the cloud environment.

[0057] Optionally, determine the schedulable resources in the cloud environment.

[0058] Scheduled resources refer to the set of physical or virtual resources that the cloud platform can allocate to tenant objects at any given moment, including computing resources (such as the number of CPU cores and memory capacity), storage resources (such as disk IOPS and storage space), and network resources (such as bandwidth and number of connections). These scheduleable resources are obtained by scanning the resource pool status in the cloud environment in real time. Specifically, the system will traverse all physical nodes and virtualization layers, count the total amount of unoccupied and healthy remaining resources, and deduct the reserve resources reserved for the system's own operation.

[0059] To illustrate, if a cloud environment has a total of 1000 CPU cores, 600 are currently occupied, and the system reserves 50, then the schedulable resource is 350 CPU cores. By determining the globally schedulable resource, clear boundary constraints can be provided for subsequent resource allocation, avoiding system crashes or service degradation caused by overselling.

[0060] Optionally, the resource prediction results corresponding to the multiple tenant objects at the second time point are determined based on the resource scheduling requirements corresponding to the multiple tenant objects respectively.

[0061] The resource prediction result refers to the estimated amount of resources required by each tenant object at a future second time point. This resource prediction result is calculated by combining the resource scheduling requirements obtained above with historical behavioral characteristics. Specifically, the system inputs the resource scheduling requirements of each tenant into a pre-trained load prediction model, which comprehensively considers the tenant's business cycle, burst traffic characteristics, and current growth trend, and outputs the resource requirements at the second time point.

[0062] To illustrate, for tenant A with periodic peak business, if their resource scheduling demand at the first moment shows a rapidly increasing load, and historical data shows that it typically reaches its peak in 10 minutes, then the model predicts that their resource forecast at the second moment will be 1.5 times the current demand. The resource forecast result, used in conjunction with resource scheduling demand, is used to proactively identify future resource gaps, shifting resource allocation from a reactive response to proactive planning, thereby significantly reducing business latency.

[0063] Optionally, target resources can be dynamically scheduled for multiple tenant objects from the schedulable resources based on resource prediction results and preset scheduling rules.

[0064] The preset scheduling rules refer to the resource allocation strategies pre-defined by the system, including but not limited to priority queuing rules, fair sharing rules, weighted round-robin rules, or guarantee rules based on Service Level Agreements (SLAs). The target resource is the resource instance ultimately allocated to each tenant object. This step is executed as follows: first, the resource prediction results of multiple tenant objects are sorted or weighted according to the preset scheduling rules; then, within the determined schedulable resource range, the needs of high-priority or high-weight tenants are satisfied sequentially, generating specific resource scheduling instructions.

[0065] As an illustration, when schedulable resources are insufficient to meet the forecast results of all tenants, if the preset scheduling rules prioritize premium tenants, the system will prioritize allocating resources to premium tenants until they meet the forecast results, and then allocate the remaining resources to other tenants. Through the coordination of resource forecast results and preset scheduling rules, the system can achieve optimal resource matching in resource-constrained scenarios, ensuring the continuity of critical business operations while maximizing the overall resource utilization efficiency.

[0066] Optionally, if the resource load data of the first tenant object meets the surge condition, a second resource quantity is scheduled to the first tenant based on the first prediction result and the preset scheduling rules, and the second resource quantity is greater than the first resource quantity.

[0067] The surge condition refers to the criteria used to trigger the emergency capacity expansion mechanism. It is obtained by comparing the resource load data of the first tenant object in real-time with a preset dynamic threshold or rate of change. Specifically, the surge condition can include a resource utilization rate increase exceeding a set percentage within a unit of time (e.g., CPU utilization spikes from 40% to 85% within one minute), or an absolute load value instantly exceeding a certain multiple of historical peak values. This condition identifies sudden high-load scenarios, distinguishing them from normal business fluctuations, thereby initiating special resource scheduling strategies. The first prediction result is a general resource demand estimate based on the object's behavioral profile and historical data, corresponding to the first resource quantity, representing the resource baseline required by the tenant under normal business trends. The second resource quantity is the emergency resource supply calculated by the system according to preset scheduling rules after detecting the surge condition. A second resource quantity greater than the first resource quantity means that the system not only meets the originally predicted demand but also provides additional buffer resources to cope with sudden traffic surges.

[0068] As an illustration, when the first tenant is a live video service, and a sudden surge in the number of viewers is detected, causing a surge in bandwidth load, the system no longer limits itself to the 100Mbps bandwidth (first resource) predicted in the first forecast. Instead, it immediately allocates the bandwidth to 150Mbps (second resource) according to preset elastic scaling rules. This over-scaling mechanism ensures that the first tenant's operating environment will not experience service interruptions or delays due to resource bottlenecks during peak business periods.

[0069] This step aims to address the technical challenge of traditional static or conventional scheduling failing to handle sudden surges in load. The execution entity is the resource scheduling module within the cloud platform, which performs this operation in the second moment after the first moment. Specifically, the execution method is as follows: First, continuously monitor the real-time resource load data of the first tenant object. Once the data characteristics match the preset surge conditions, immediately interrupt the conventional scheduling process and invoke emergency expansion logic. Next, read the first predicted result (i.e., the first resource quantity) corresponding to the tenant and, combined with the expansion coefficient or fixed incremental strategy in the preset scheduling rules, calculate a higher second resource quantity. Finally, lock and allocate this second resource quantity from the schedulable resource pool of the cloud environment to the first tenant object. The resulting resource allocation scheme effectively absorbs sudden traffic surges, ensuring the continuity and stability of critical services under extreme loads, and significantly improving the system's fault tolerance and user experience.

[0070] In some embodiments, the service configuration data includes at least one of the following: the service type, service priority, or service level corresponding to the tenant object.

[0071] Service configuration data refers to the set of metadata used by the cloud platform to characterize the specific configuration requirements of a tenant when providing business services. Specifically, business type can refer to the functional classification of the applications run by the tenant, such as online transaction processing, big data analytics, video streaming rendering, or offline batch processing. Different types of businesses have significantly different sensitivities to computing resources, storage I / O, and network bandwidth. Business priority refers to weighted indicators set according to the importance or urgency of the business as agreed in the tenant contract, used to determine the scheduling order in resource contention scenarios. Service level refers to the service quality standards agreed upon in the Service Level Agreement (SLA), including indicators such as availability commitments, response time thresholds, and fault recovery time targets. These dimensional data are obtained through tenant registration interfaces, manual configuration by administrators, or automatic parsing from historical service contracts.

[0072] To illustrate, for a tenant object in a core financial trading system, its service configuration data can be set as follows: business type is real-time high-frequency trading, business priority is marked as the highest level (P0), and service level requirement is 99.99% availability with latency below 10ms. For a tenant object in an internal log archiving system, its service configuration data can be set as follows: business type is offline data storage, business priority is marked as low level (P3), and service level requirement is 99% availability. Through this multi-dimensional collection of configuration information, the system can accurately identify the business attributes and value differences of different tenants.

[0073] This step aims to enrich the data foundation of object behavior profiles, enabling them to reflect not only tenants' historical usage habits but also their current business value and urgency. Based on the aforementioned business type, business priority, or service level, the scheduling module can combine static configuration requirements with dynamic load data when making resource allocation decisions. Specifically, when resource constraints occur in the cloud environment, the processor will prioritize resource supply to high-priority tenants based on business priority, while temporarily restricting resource expansion for low-priority tenants. Simultaneously, considering business type characteristics, CPU resources are allocated to compute-intensive services, and storage bandwidth resources are allocated to I / O-intensive services. This significantly improves the rationality and targeting of resource scheduling, ensures the continuity and service quality of critical businesses, and effectively avoids resource mismatch problems caused by missing configuration information.

[0074] In some embodiments, a preset isolation rule is used to provide an independent operating environment for multiple tenant objects, wherein the preset isolation rule includes at least one of a virtual isolation rule, a container isolation rule, or a logical differentiation rule.

[0075] The preset isolation rules refer to a set of policies enforced by the cloud platform during resource scheduling to ensure the business independence and data security of different tenant objects. These preset isolation rules can originate from global security configurations loaded during cloud platform initialization or from specific instructions dynamically issued based on the tenant object's Service Level Agreement (SLA). Their purpose is to create logically or physically independent execution spaces, preventing abnormal behavior of any tenant object (such as memory leaks, CPU overload, or malicious attacks) from affecting other tenant objects on the same physical node.

[0076] Specifically, the preset isolation rules include at least one of virtual isolation rules, container isolation rules, or logical differentiation rules. Virtual isolation rules are implemented based on hardware virtualization technology, such as allocating an independent virtual machine instance to each tenant object through the Hypervisor layer. Each virtual machine has an independent operating system kernel, virtual CPU, and virtual memory space, thereby achieving strong kernel-level isolation. Container isolation rules are implemented based on operating system-level namespace and cgroup technologies, such as isolating the processes, file systems, and network stacks of different tenants through Docker or Kubernetes engines, sharing the host kernel but limiting resource usage limits, thereby achieving lightweight process-level isolation. Logical differentiation rules are implemented based on software-defined logical boundaries, such as using VLAN segmentation, database schema isolation, or application-layer tenant ID authentication mechanisms to distinguish data ownership through logical identifiers when sharing the same running instance.

[0077] As an illustration, when a cloud environment contains financial tenants with extremely high security requirements, the system can automatically match and apply virtual isolation rules to allocate a dedicated virtual machine environment for that tenant, ensuring its data is completely physically isolated from other internet tenants. For microservice tenants with higher requirements for startup speed and resource density, the system can apply container isolation rules to deploy hundreds of isolated container instances on the same physical server, ensuring process invisibility while maximizing resource utilization. This flexible isolation rule selection mechanism allows for dynamic adjustment of isolation granularity based on the tenant's business characteristics, optimizing resource consumption while ensuring security.

[0078] This step aims to provide a secure execution platform for the target resources of the aforementioned scheduling. Based on the object behavior profile constructed from the aforementioned acquired service configuration data and historical resource data, the system not only determines the quantity requirements of resources but also implicitly includes the security level requirements for the operating environment. By implementing preset isolation rules, multiple tenant objects can each have their own independent operating environment when executing target business in the cloud environment. This effectively avoids resource contention, data leakage, and lateral movement attacks between tenants, significantly improving the overall stability and security of the cloud platform.

[0079] The preset isolation rules include at least one of virtual isolation rules, container isolation rules, or logical differentiation rules.

[0080] The three isolation rules mentioned above are not mutually exclusive, but can be combined and applied according to the actual architecture of the cloud platform and the hybrid deployment requirements of tenant objects. The virtual isolation rule focuses on providing complete system environment isolation and is suitable for scenarios that require custom operating systems or running legacy applications; the container isolation rule focuses on providing efficient resource encapsulation and rapid elastic scaling and is suitable for cloud-native applications and microservice architectures; the logical differentiation rule focuses on providing low-cost data and access control isolation and is suitable for multi-tenant SaaS service models.

[0081] Specifically, when determining which isolation rule to use, the business type or service level in the service configuration data of the tenant object obtained above can be considered. For example, if the service configuration data indicates that a tenant object belongs to the high security level and the business type is core accounting processing, then virtual isolation rules should be preferred; if it indicates bursty traffic and the business type is web page rendering, then container isolation rules should be preferred to support second-level scaling; if it indicates general office work and the business type is document collaboration, then logical differentiation rules can be used to reduce operation and maintenance costs. In addition, these rules can be updated over time. When a change in the security risk level of a tenant object is detected, the preset isolation rules can be dynamically upgraded from logical differentiation rules to container isolation rules or even virtual isolation rules.

[0082] By flexibly configuring and combining virtual isolation rules, container isolation rules, and logical differentiation rules, this application can adapt to multi-tenant cloud environments of different scales and business models. This diverse isolation approach works closely with the aforementioned resource scheduling steps: resource scheduling addresses the question of how much resource to allocate, while isolation rules address how to use resources in a secure environment. Working together, they ensure that while dynamically adjusting resource load, strict tenant boundaries are always maintained, achieving a balance between efficient resource utilization and high-level security.

[0083] The resource management method provided in this application achieves efficient cloud resource management through the synergistic effect of the aforementioned technical features. Specifically, by acquiring service configuration data and historical resource data, the system first establishes a comprehensive tenant awareness foundation; then, based on this data, it constructs object behavior profiles, transforming static configurations and dynamic historical patterns into quantifiable predictive models, thus solving the problem of existing technologies lacking intelligent predictive capabilities. On this basis, combined with real-time resource load data acquired in the first moment, the system can accurately schedule target resources for each tenant in the second moment, while calibrating the real-time state and utilizing the forward-looking guidance of object behavior profiles. This dual-drive mechanism of historical profiles + real-time load makes resource scheduling no longer a passive response but an active planning. Simultaneously, by providing each tenant with an independent operating environment and utilizing isolation rules such as virtualization, containerization, or logical differentiation, data security and business independence are ensured in the context of multi-tenant shared physical resources, preventing resource contention and mutual interference. Ultimately, this entire process forms a closed-loop optimization system from data perception and intelligent analysis to dynamic execution, significantly improving resource utilization, ensuring the service quality of high-priority businesses, and enhancing the system's elastic scalability in large-scale concurrent scenarios.

[0084] Reference Figure 2 The device 200 includes the following: The acquisition module 210 is used to acquire service configuration data and historical resource data corresponding to multiple tenant objects in the cloud environment. The service configuration data is used to indicate the configuration requirements of the tenant object when the cloud platform provides business services to the tenant object. The historical resource data is used to indicate the resource usage of the tenant object in a historical period. Module 220 is used to construct an object behavior profile corresponding to the tenant object based on the service configuration data and the historical resource data; The acquisition module 210 is used to acquire resource load data corresponding to the multiple tenant objects at a first moment; The scheduling module 230 is used to schedule target resources for the multiple tenant objects respectively based on the object behavior profile and the resource load data at a second time, wherein the tenant objects have an independent running environment when performing target business in the cloud environment, and the second time is a time after the first time.

[0085] It should be noted that the information interaction and execution process between the above-mentioned devices / modules are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0086] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0087] To implement the above embodiments, this application also proposes an electronic device. Figure 3 This is a schematic diagram of the structure of an electronic device according to an embodiment of this application.

[0088] like Figure 3 As shown, the above-mentioned electronic device 500 includes: The system includes a memory 510 and at least one processor 520, and a bus 530 connecting the different components (including the memory 510 and the processor 520). The memory 510 stores a computer program, and when the processor 520 executes the program, it implements the method for controlling the robot according to the embodiments of this application.

[0089] Bus 530 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0090] Electronic device 500 typically includes a variety of electronic device readable media. These media can be any available media that can be accessed by electronic device 500, including volatile and non-volatile media, removable and non-removable media.

[0091] Memory 510 may also include computer system readable media in the form of volatile memory, such as random access memory (RAM) 540 and / or cache memory 550. Electronic device 500 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 560 can be used to read and write non-removable, non-volatile magnetic media (… Figure 3 Not shown; usually referred to as a "hard drive"). Although Figure 3 As not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 530 via one or more data media interfaces. Memory 510 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of this application.

[0092] A program / utility 580 having a set (at least one) of program modules 570 may be stored, for example, in memory 510. Such program modules 570 include—but are not limited to—an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 570 typically perform the functions and / or methods described in the embodiments of this application.

[0093] Electronic device 500 can also communicate with one or more external devices 590 (e.g., keyboard, pointing device, display 591, etc.), and with one or more devices that enable a user to interact with electronic device 500, and / or with any device that enables electronic device 500 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed via input / output (I / O) interface 595. Furthermore, electronic device 500 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 593. As shown, network adapter 593 communicates with other modules of electronic device 500 via bus 530. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 500, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0094] The processor 520 performs various functional applications and data processing by running programs stored in the memory 510.

[0095] It should be noted that the implementation process and technical principles of the electronic device in this embodiment are explained in the foregoing description of the resource management method in the embodiments of this application, and will not be repeated here.

[0096] This application also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps described in the various method embodiments above.

[0097] This application provides a computer program product that, when run on an electronic device, enables the electronic device to perform the steps described in the various method embodiments above.

[0098] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. A computer-readable medium can include at least: any entity or device capable of carrying computer program code to a photographic device / electronic device, a recording medium, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some regions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

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

[0100] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0101] In the embodiments provided in this application, it should be understood that the disclosed devices / electronic devices and methods can be implemented in other ways. For example, the device / electronic device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices or units may be electrical, mechanical, or other forms.

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

[0103] In the foregoing, specific details such as particular system architectures and techniques have been set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application can also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted to avoid unnecessary detail from obscuring the description of this application.

[0104] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0105] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0106] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0107] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0108] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0109] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A resource management method, characterized in that, The method is applied to a cloud platform, where a cloud environment runs, and the method includes: Obtain service configuration data and historical resource data corresponding to multiple tenant objects in the cloud environment. The service configuration data is used to indicate the configuration requirements of the tenant object when the cloud platform provides business services to the tenant object. The historical resource data is used to indicate the resource usage of the tenant object in a historical period. Based on the service configuration data and the historical resource data, construct an object behavior profile corresponding to the tenant object; Obtain the resource load data corresponding to the multiple tenant objects at the first moment; Based on the object behavior profile, target resources are scheduled for the multiple tenant objects at a second time based on the resource load data. The tenant objects have independent operating environments when performing target services in the cloud environment. The second time is a time after the first time.

2. The method according to claim 1, characterized in that, The step of scheduling target resources for the multiple tenant objects at a second time based on the object behavior profile and the resource load data includes: Based on the object behavior profile, the resource scheduling requirements of the multiple tenant objects at the second time point are predicted based on the resource load data. Based on the resource scheduling requirements corresponding to the multiple tenant objects, the target resources are scheduled for each of the multiple tenant objects.

3. The method according to claim 2, characterized in that, The step of scheduling the target resources for the multiple tenant objects based on their respective resource scheduling requirements includes: determining the schedulable resources in the cloud environment; Based on the resource scheduling requirements corresponding to the multiple tenant objects, the resource prediction results corresponding to the multiple tenant objects at the second time point are determined. Based on the resource prediction results and preset scheduling rules, the target resources are dynamically scheduled for the multiple tenant objects from the schedulable resources.

4. The method according to claim 3, characterized in that, The plurality of tenant objects includes a first tenant object, which corresponds to a first prediction result and the first prediction result corresponds to a first resource quantity. The step of dynamically scheduling the target resources for the multiple tenant objects from the schedulable resources based on the resource prediction results and preset scheduling rules includes: If the resource load data of the first tenant object meets the surge condition, a second resource quantity is scheduled to the first tenant based on the first prediction result and the preset scheduling rule, and the second resource quantity is greater than the first resource quantity.

5. The method according to any one of claims 1 to 4, characterized in that, The service configuration data includes at least one of the following: the business type, business priority, or service level corresponding to the tenant object.

6. The method according to any one of claims 1 to 4, characterized in that, The method further includes: The multiple tenant objects are provided with independent operating environments by means of preset isolation rules, wherein the preset isolation rules include at least one of virtual isolation rules, container isolation rules, or logical differentiation rules.

7. A resource management device, characterized in that, The device includes: The acquisition module is used to acquire service configuration data and historical resource data corresponding to multiple tenant objects in the cloud environment. The service configuration data is used to indicate the configuration requirements of the tenant object when the cloud platform provides business services to the tenant object. The historical resource data is used to indicate the resource usage of the tenant object in a historical period. The construction module is used to construct an object behavior profile corresponding to the tenant object based on the service configuration data and the historical resource data; The acquisition module is used to acquire the resource load data corresponding to the multiple tenant objects at a first moment; The scheduling module is used to schedule target resources for the multiple tenant objects respectively based on the object behavior profile and the resource load data at a second time, wherein the tenant objects have an independent running environment when performing target business in the cloud environment, and the second time is a time after the first time.

8. A computer device comprising a memory, one or more processors, and a computer program stored in the memory and executable on the one or more processors, characterized in that, When the one or more processors execute the computer program, the computer device causes the computer device to implement the method as described in any one of claims 1 to 6.

9. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 6.

10. A computer program product, characterized in that, Includes a computer program that, when run on an electronic device, causes the electronic device to perform the method as described in any one of claims 1 to 6.

Images