Cloud resource management method, device and system

Abstract

The invention relates to the technical field of cloud computing, and provides a cloud resource management method, device and system, and the method comprises the steps: carrying out the first management operation of a first resource in cloud resources according to the operation cycle of a target application, and enabling the first management operation to indicate the switching of the state of the first resource, the state of the first resource comprises allowing the first resource to run the target application or allowing the first resource to run the target application and the non-target application. The target application comprises the application running according to the running cycle in the multiple applications, and the non-target application comprises the applications except the target application in the multiple applications. The resource scheduling of the management cloud resources is realized to meet the resource requirements of the operation of various applications, the utilization rate of the cloud resources is improved, and the resource waste is reduced.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, specifically to cloud resource management methods, apparatus, and systems. Background Technology

[0002] Tenants can use cloud computing systems to run applications. Different types of applications have different resource requirements. For example, some applications need to run quickly to process their tasks, so sufficient resources need to be allocated to run them in a timely manner, while some applications need to run for a long time to process their tasks, and it is acceptable to wait for a period of time before allocating resources to run them.

[0003] For some cloud computing systems, such as private clouds, resource scheduling of cloud resources can be managed to run various applications of a tenant. For example, a bank may be a tenant of a private cloud, where cloud resources are exclusively available for the bank's use. The bank can manage the resource scheduling of these cloud resources to run various applications, such as transaction applications and auditing applications. When a tenant has multiple applications using cloud resources simultaneously, determining the resource requirements of each application and managing the resource scheduling of cloud resources to better meet these requirements are pressing technical problems that need to be solved. Summary of the Invention

[0004] This application provides a cloud resource management method, apparatus, and system that can manage cloud resource scheduling, thereby better meeting the resource requirements of various applications and improving the utilization rate of cloud resources.

[0005] A first aspect provides a cloud resource management method, wherein cloud resources are used to run multiple applications of a tenant. The method includes determining a target application from the multiple applications, wherein the target application includes applications that run on a scheduled cycle among the multiple applications. It also includes obtaining the state of a first resource in the cloud resources, the state of the first resource including allowing the first resource to be used to run the target application, or allowing the first resource to be used to run both the target application and non-target applications, wherein non-target applications include applications other than the target application among the multiple applications. Finally, it includes performing a first management operation on the first resource according to the scheduled cycle of the target application, the first management operation indicating a switch in the state of the first resource.

[0006] In the cloud resource management method provided in this application embodiment, a distinction is made between target applications running according to their runtime cycles and other non-target applications among multiple applications. The runtime cycle of the target application indicates its runtime segment. The method automatically switches the state of a first resource (such as a portion of the cloud resources) based on the target application's runtime cycle. This ensures that during the target application's runtime segment, the first resource is dedicated to running the target application, meeting its resource requirements. Furthermore, outside the target application's runtime segment, the first resource can be used to run both the target application and non-target applications, maintaining high utilization even when the first resource is not heavily used for running the target application, thus reducing resource waste.

[0007] In some possible implementations, performing a first management operation on the first resource based on the target application's runtime cycle includes: during the target application's peak runtime period, switching the state of the first resource to allow the first resource to be used to run the target application; and during the target application's off-peak runtime period, switching the state of the first resource to allow the first resource to be used to run both the target application and non-target applications.

[0008] By analyzing the peak operating hours of the target application, we can accurately determine the periods when the primary resource needs to be used more extensively to run the target application, and by analyzing the off-peak operating hours of the target application, we can accurately determine the periods when the primary resource is not used more extensively to run the target application. In this way, the above method allows for more accurate switching of the primary resource's state, enabling more efficient use of the primary resource and better reducing resource waste.

[0009] In other possible implementations, the method also includes: determining the target application and its runtime based on historical runtime data from multiple applications.

[0010] Historical application data can accurately reflect the application's operational characteristics. Based on this, the cloud resource management method provided in this application embodiment automatically determines the application's category (including target applications, non-target applications, etc.) and the target application's operational cycle based on the application's historical operational data. This results in high efficiency and accuracy in application classification.

[0011] In some other possible implementations, the non-target application includes multiple applications other than the target application among multiple applications, and the method further includes: performing a second management operation on cloud resources, the second management operation instructing the scheduling of a second resource in the cloud resources to use the second resource to run at least one application among the non-target applications, wherein the scheduling method of the second resource is related to at least one of the application categories and priorities of the multiple applications included in the non-target application.

[0012] The second resource allows multiple applications (e.g., multiple applications other than the target application) to share it. Applications of different categories and priorities have different resource requirements. This application's embodiments differentiate between application categories and priorities, and schedule the second resource to run multiple applications based on these categories and priorities. This approach can effectively meet the resource needs of multiple applications while ensuring high utilization of the second resource.

[0013] In some other possible implementations, the non-target applications include a first application and a second application, where the first application has a higher priority than the second application. The second management operation on the cloud resources includes: if a task from the first application is received and the resource occupancy rate of the second resource is higher than a threshold, using the resources on the second resource that are used to run the second application to run the first application; or if no second application is running on the second resource, adding the task of the first application to a waiting queue.

[0014] Based on this, when a task from the first application is received and there are few or no idle resources in the second resource, the system can preempt resources used by the second application, which has a lower priority than the first application, to run the first application, thus effectively guaranteeing the resource needs of higher-priority applications. Furthermore, when the second application, which has a lower priority than the first application, is running in the second resource, the task from the first application can be added to a waiting queue, ensuring that the task from the first application can continue to be executed when idle resources become available.

[0015] In some other possible implementations, the method also includes removing tasks from the waiting queue that have been waiting for longer than a time threshold.

[0016] The waiting queue has a limited capacity for tasks. Tasks with long waiting times can be abandoned. Therefore, removing long-waiting tasks from the waiting queue ensures that new tasks can be added to the waiting queue in a timely manner to await execution.

[0017] In some other possible implementations, the non-target application includes a third application, which satisfies at least one of the following: the application category is the target category or the priority is lower than the target priority. The second management operation on cloud resources includes: upon receiving a task from a third application, if the amount of idle resources in the second resource meets the target requirements, allowing the idle resources in the second resource to be used to run the third application; otherwise, disallowing the idle resources in the second resource to be used to run the third application.

[0018] Based on this, it is possible to control the resource allocation of certain categories and / or lower-priority applications more flexibly and precisely according to demand (that is, the idle resources in the second resource can only be used to run the third application when the amount of idle resources in the second resource meets the target requirements, and the target requirements may include, for example, a large amount of idle resources, or the proportion of idle resources in the second resource being greater than the target proportion, etc.), ensuring that the second resource is used first to run other categories and / or applications with higher resource requirements.

[0019] In some other possible implementations, the method also includes: determining the application category or priority of the multiple applications included in the non-target application based on the historical running data of the multiple applications included in the non-target application.

[0020] Historical operational data of an application can accurately reflect its operational characteristics. Based on this, the cloud resource management method provided in this application embodiment automatically determines the categories and priorities of multiple applications included in a non-target application based on the application's historical operational data, resulting in high efficiency and accuracy in application classification and grading.

[0021] In some other possible implementations, historical runtime data includes at least one of the following: the application's historical runtime, the amount of resources consumed during the application's historical runtime, the application's historical runtime latency, the number of requests processed during the application's historical runtime, and the application's historical task processing time.

[0022] The application's historical runtime, resource consumption, and request volume all reflect its historical runtime periods, including peak and off-peak times. Historical runtime latency and task processing time reflect historical resource usage requirements. Therefore, this historical runtime data accurately and comprehensively reflects the application's operational characteristics, helping to accurately determine its category, runtime cycle, and priority.

[0023] Secondly, a cloud resource management device is provided, wherein cloud resources are used to run multiple applications of a tenant, and the device includes a first management module. The first management module is configured to determine a target application from the multiple applications, wherein the target application includes applications that run on a scheduled basis. Furthermore, it acquires the status of a first resource in the cloud resources, the status of the first resource including allowing the first resource to be used to run the target application, or allowing the first resource to be used to run both the target application and non-target applications, wherein non-target applications include applications other than the target application from the multiple applications. Finally, it performs a first management operation on the first resource according to the scheduled basis of the target application, the first management operation indicating a switch in the status of the first resource.

[0024] In some possible implementations, the first management module is also used to: switch the state of the first resource to allow the first resource to be used to run the target application during the peak running period of the target application; and switch the state of the first resource to allow the first resource to be used to run both the target application and non-target applications during the off-peak running period of the target application.

[0025] In some other possible implementations, the first management module is also used to: determine the target application and the running cycle of the target application among the multiple applications based on the historical running data of the multiple applications.

[0026] In other possible implementations, the non-target application includes multiple applications other than the target application. The apparatus also includes a second management module. The second management module performs a second management operation on cloud resources, instructing the scheduling of a second resource within the cloud resources to run at least one application among the non-target applications, wherein the scheduling method of the second resource is related to at least one of the application categories and priorities of the multiple applications included in the non-target application.

[0027] In some other possible implementations, the non-target applications include a first application and a second application, wherein the first application has a higher priority than the second application. The second management module is also used to: when receiving a task from the first application and the resource occupancy rate of the second resource is higher than the occupancy threshold, use the resources in the second resource that are used to run the second application to run the first application; or if there is no second application running in the second resource, add the task of the first application to the waiting queue.

[0028] In some other possible implementations, the second management module is also used to remove tasks from the waiting queue that have been waiting for longer than a time threshold.

[0029] In some other possible implementations, the non-target application includes a third application, which satisfies at least one of the following: the application category is the target category or the priority is lower than the target priority. The second management module is further configured to: upon receiving a task from a third application, if the amount of idle resources in the second resource meets the target requirements, allow the idle resources in the second resource to be used to run the third application; otherwise, disallow the idle resources in the second resource to be used to run the third application.

[0030] In some other possible implementations, the second management module is also used to: determine the application category or priority of the multiple applications included in the non-target application based on the historical running data of the multiple applications included in the non-target application.

[0031] In some other possible implementations, historical runtime data includes at least one of the following: the application's historical runtime, the amount of resources consumed during the application's historical runtime, the application's historical runtime latency, the number of requests processed during the application's historical runtime, and the application's historical task processing time.

[0032] Thirdly, a cloud resource management system is provided, the system including at least one device for performing the cloud resource management method as described in the first aspect.

[0033] Fourthly, a computing device cluster is provided, comprising at least one computing device, wherein each computing device includes a processor and a memory; and the processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the computing device cluster to perform the cloud resource management method as described in the first aspect.

[0034] Fifthly, a computer program product containing instructions is provided, which, when executed by at least one computing device, causes the at least one computing device to perform the cloud resource management method as described in the first aspect.

[0035] In a sixth aspect, a computer-readable storage medium is provided, including computer program instructions that, when executed by at least one computing device, enable the at least one computing device to perform the cloud resource management method as described in the first aspect.

[0036] Based on the implementation methods provided in the above aspects, this application can be further combined to provide more implementation methods.

[0037] The following description includes more specific details about the implementation methods provided for the above aspects. Attached Figure Description

[0038] Figure 1 A schematic diagram of the architecture of the cloud resource management system provided in the embodiments of this application;

[0039] Figure 2 A flowchart illustrating the cloud resource management method provided in the embodiments of this application. Figure 1 ;

[0040] Figure 3 A flowchart illustrating the cloud resource management method provided in the embodiments of this application. Figure 2 ;

[0041] Figure 4 A schematic diagram of the software architecture of the cloud resource management system provided in the embodiments of this application;

[0042] Figure 5 This is a schematic diagram of the structure of the cloud resource management device provided in the embodiments of this application;

[0043] Figure 6 This is a schematic diagram of the structure of a computing device provided in an embodiment of this application;

[0044] Figure 7 A schematic diagram of the computing device cluster provided in the embodiments of this application. Figure 1 ;

[0045] Figure 8 A schematic diagram of the computing device cluster provided in the embodiments of this application. Figure 2 . Detailed Implementation

[0046] Cloud computing is an on-demand information technology (IT) service that can be conveniently accessed and used via the internet and other means. Cloud resources can refer to a shared pool of cloud computing resources, or they can be understood as the resources provided by cloud computing.

[0047] These resources include, but are not limited to, computing resources (such as servers), storage resources (such as storage devices), network resources (such as network lines), databases, software, and other information technology-related resources. Cloud resources can be large in scale, including, for example, tens of thousands of servers, thus providing tenants with strong computing power.

[0048] Cloud computing is provided to users by cloud service providers, and cloud computing users are called tenants. For example, tenants can obtain and use cloud resources on demand to run their applications to handle application tasks and realize their business. An application is a type of software, a program written for a specific user application purpose, such as a text processor, spreadsheet, accounting application, browser, media player, flight simulator, command-line game, image editor, etc.

[0049] Cloud computing systems (or cloud computing platforms) can include various types depending on their deployment methods, such as public cloud, private cloud, and hybrid cloud.

[0050] In public clouds, cloud resources are open to the public, accessible and usable by all tenants, and can be deployed by cloud service providers in various feasible locations. Thus, tenants can use IT services without having to deploy their own IT infrastructure.

[0051] Private cloud resources are not publicly available and are exclusively for the use of a specific tenant. They can be deployed locally in the tenant's data center or other suitable locations. For tenants, private clouds offer data localization and enhanced security compared to public clouds. Some tenants, such as government departments and enterprises with high information security requirements, can use private clouds to ensure the information security of their business operations.

[0052] Hybrid cloud is a cloud computing system that combines two or more types of cloud computing.

[0053] Cloud resources in a cloud computing system can be provided to tenants through virtualization. Virtualization can involve transforming physical resources into logically manageable resources. For example, cloud resources such as servers, storage devices, and networks are virtualized into resource pools for flexible allocation. As an example, servers in cloud resources can be virtualized into virtual machines. For instance, if a cloud resource includes multiple physical servers, one physical server can be virtualized into one or more virtual machines. Tenants can use these virtual machines to perform business operations (e.g., run applications). In this embodiment, a virtual machine can be referred to as a node.

[0054] In some embodiments, resources can be dynamically added to or removed from cloud resources, such as creating new virtual machines or removing some existing virtual machines.

[0055] Tenants can use cloud computing systems to run multiple applications. Each application will use at least a portion of the cloud resources during runtime, and the more tasks an application has, the more resources it will use during runtime.

[0056] Different types of applications may have different resource requirements when running. For example, some applications need to run quickly to process their tasks, so sufficient resources need to be allocated to run them in a timely manner, while some applications need to run for a long time to process their tasks, so it is acceptable to wait for a period of time before allocating resources to run them.

[0057] For some cloud computing systems, such as private clouds, the resource scheduling of cloud resources can be managed to run various applications of the tenant. For example, if a bank is a tenant of a private cloud, the cloud resources of the private cloud can be exclusively provided to the bank, and the bank can manage the resource scheduling of the cloud resources to run various applications such as the bank's transaction applications and auditing applications.

[0058] When a tenant has multiple applications using cloud resources simultaneously, resource usage conflicts can easily arise between the applications.

[0059] For example, if a cloud computing system first receives data processing tasks from a bank's auditing and user profiling applications, it will allocate cloud resources to run these applications to process their tasks. Later, if the cloud computing system receives a data processing task from a transaction application, there will be no available cloud resources to run the transaction application, making it unable to process its tasks.

[0060] However, the tasks in the auditing and user profiling applications have relatively long execution times and lower real-time requirements, meaning a waiting period before processing is acceptable. The transaction applications, on the other hand, have higher real-time requirements, needing to process tasks promptly and provide results back to bank users. The consuming of cloud resources by applications with lower real-time requirements prevents the transaction applications from running, impacting banking operations.

[0061] Therefore, how to determine the resource requirements of various applications and how to manage the resource scheduling of cloud resources to meet the resource requirements of various applications are technical problems that urgently need to be solved.

[0062] In some implementations, multiple applications can be manually categorized, and each type of application can be allocated a separate resource pool within the cloud resources. Each resource pool contains compute, storage, and network resources isolated from other resource pools, used to run the corresponding type of application. In this way, the resources used by various applications can be isolated from each other, reducing resource usage conflicts.

[0063] However, since the resource pools are pre-defined, each pool contains a fixed amount of resources. This can lead to situations where some application types have smaller workloads and only utilize a portion of the resources in the pool, while others have larger workloads and insufficient resources. This can result in some idle resources in certain pools not being fully utilized, leading to resource waste, and some pools not being able to support the timely processing of tasks from applications with high real-time requirements. Furthermore, when there are many application types, relying on manual experience to accurately categorize various applications is difficult, and manual categorization is inefficient.

[0064] In some implementations, the amount of cloud resources allocated to different applications can be dynamically adjusted based on user resource adjustment requests. This can improve cloud resource utilization and reduce resource waste to some extent. However, this method relies on user requests and user experience, making it difficult to adjust resource allocation in a timely manner and to guarantee that the adjusted resource allocation will effectively improve cloud resource utilization.

[0065] In some implementations, after manually categorizing multiple applications, tasks from different application types can be placed into different task queues. The cloud computing system then selects tasks from certain task queues for processing. In this way, the cloud computing system prioritizes using idle cloud resources to run certain types of applications (i.e., the applications to which the prioritized tasks belong). This method can reduce resource usage conflicts between different applications to some extent. However, when there are many types of applications, relying on human experience makes it difficult to accurately categorize multiple applications, making it difficult to accurately meet the resource needs of various applications, and manual categorization is inefficient.

[0066] To better manage cloud resource scheduling to meet the resource requirements of various applications, this application provides a cloud resource management method. The method includes performing a first management operation on cloud resources according to the runtime cycle of a target application. The first management operation instructs switching the state of a first resource in the cloud resources. The state of the first resource includes allowing the first resource to be used to run the target application, allowing the first resource to be used to run the target application, and allowing non-target applications. Target applications include applications running on a runtime cycle from among multiple applications, and non-target applications include applications other than the target application from among multiple applications.

[0067] In the cloud resource management method provided in this application embodiment, a distinction is made between target applications running according to their runtime cycles and other non-target applications among multiple applications. The runtime cycle of the target application indicates its runtime segment. The method automatically switches the state of a first resource (such as a portion of the cloud resources) based on the target application's runtime cycle. This ensures that during the target application's runtime segment, the first resource is dedicated to running the target application, meeting its resource requirements. Furthermore, outside the target application's runtime segment, the first resource can be used to run both the target application and non-target applications, maintaining high utilization even when the first resource is not heavily used for running the target application, thus reducing resource waste.

[0068] The cloud resource management method provided in this application can be applied to various types of cloud computing systems that require cloud resource management, such as private clouds, to manage the scheduling of cloud resources so that cloud resources can be used to run multiple applications of a tenant.

[0069] The system architecture provided in the embodiments of this application is described below.

[0070] Figure 1 This is a schematic diagram of the architecture of a cloud resource management system provided in an embodiment of this application. The cloud resource management system 100 can be used to implement the cloud resource management method proposed in this embodiment. Figure 1 As shown, the cloud resource management system 100 includes cloud resources 110, user terminals 120, and management devices 130.

[0071] Cloud resource 110 can be any resource included in various types of cloud computing systems. Cloud resource 110 can include, but is not limited to, various resources involved in information technology such as computing resources (e.g., servers), storage resources (e.g., storage devices), and network resources (e.g., network lines). Cloud resource 110 can be provided to tenants for use, for example, to run tenant applications to process application tasks and realize tenant business.

[0072] User terminal 120 can be a device involved in the implementation of tenant services, which can generate or receive application tasks.

[0073] For example, a tenant provides services to users, and the user terminal 120 can be the terminal used by the tenant's users. When users use the user terminal 120 to perform services, application tasks are generated. Alternatively, the user terminal 120 can be a device used by the tenant, where the user terminal sends the application tasks generated during service performance to the user terminal 120, or the tenant directly uses the user terminal 120 to perform services, and the user terminal 120 generates application tasks.

[0074] Tasks generated during business implementation can be processed by running corresponding applications; these tasks are called application tasks. For example, a tenant provides various services such as auditing, transaction processing, profiling, and AI training. Tasks generated during auditing are processed by running an auditing application (these tasks are called auditing application tasks), tasks generated during profiling are processed by running a profiling application (these tasks are called profiling application tasks), and tasks generated during AI training are processed by running an AI training application (these tasks are called AI training application tasks), and so on.

[0075] Tasks generated or received by the user client (120) can be processed by the cloud computing system. Tenants may have various applications; for each application's task, the cloud computing system can run the corresponding application to handle that task.

[0076] The management device 130 can be any feasible device such as a server or terminal (e.g., mobile terminal, laptop, AR / VR, etc.). The management device 130 is used to manage the scheduling of cloud resources 110 so that cloud resources 110 can be used to run tenant applications. For example, cloud resources 110 can be used to run multiple applications of tenant, such as application 1, application 2, and application 3.

[0077] For example, client 120 can send application tasks to management device 130, which can manage the scheduling of cloud resources 110 to run tenant applications and process received application tasks. Furthermore, management device 130 can also feed back the task processing results obtained by cloud resources 110 in processing application tasks to client 120.

[0078] In some embodiments, the management device 130 may be a device in a cloud computing system or a device outside of a cloud computing system.

[0079] The management device 130 can be used to execute the steps of the cloud resource management method provided in the embodiments of this application to manage the scheduling of cloud resources 110 to run various applications of the tenant. For more details regarding the management device 130 executing the cloud resource management method, please refer to... Figures 2-3 And its related descriptions.

[0080] It is worth noting that, Figure 1 This is merely a schematic diagram of the architecture of a cloud resource management system provided in this application embodiment. The positional relationships between the devices, components, modules, etc. shown in the figure do not constitute any limitation.

[0081] For example, Figure 1 The management device 130 is a device other than the cloud resource 110. In other cases, the management device 130 can also be a device within the cloud resource 110.

[0082] The cloud resource management method provided in the embodiments of this application is described in detail below. The cloud resource management method provided in the embodiments of this application can... Figure 1 The cloud resource management system shown is implemented on 100.

[0083] Figure 2 A flowchart illustrating the cloud resource management method provided in the embodiments of this application. Figure 1 . Figure 2 The cloud resource management method shown can be executed by a computing device. For example, it can be executed by the management device 130 in the cloud resource management system 100.

[0084] like Figure 2 As shown, the method includes the following steps.

[0085] Step 210: Determine the runtime of the target application.

[0086] As previously mentioned, cloud resources can be used to run multiple applications of a tenant. In this embodiment, an application that runs on a specific schedule among the multiple applications can be identified; this type of application can be referred to as the target application. In this embodiment, the target application can also be referred to as a real-time fixed application.

[0087] Applications other than the target application among multiple applications can be referred to as non-target applications. Thus, non-target applications can include applications that are not running according to the scheduled runtime cycle.

[0088] Applications running according to a cycle refers to applications operating periodically. For example, a cycle is defined as a period of time (e.g., a day, a week, or a month). The application runs during certain periods within each or more cycles, meaning it runs regularly within each or more cycles. For instance, the application experiences peak operating periods (or peak periods) during certain periods within each or more cycles, meaning peak operating periods occur regularly within each or more cycles.

[0089] The defined time period can be the application's runtime cycle, which may include the application's runtime segments, such as peak runtime periods. Additionally, the time periods within a runtime cycle other than peak runtime periods can be referred to as off-peak periods (or low-peak periods). The application's peak runtime periods can be set according to requirements.

[0090] For example, if the number of requests an application runs and processes exceeds a certain threshold during a specific period, then that period is considered the application's peak running time. The requests processed by the application during runtime are equivalent to the application's tasks, and the number of requests represents the number of tasks. The threshold can be determined based on requirements, such as 1, 10, or 100. Conversely, during off-peak running times, the application may not run or may process fewer requests, for example, less than the threshold.

[0091] For example, if an application runs during a certain period and consumes more resources than a resource consumption threshold, that period is considered the application's peak operating period. The consumed resources can include computing resources (e.g., CPU usage) and storage resources (e.g., storage space usage). The resource consumption threshold can be determined based on demand; for example, it could be 20 CPUs or 50% of the total cloud resources. Conversely, during off-peak operating periods, the application may not run or may consume fewer resources, such as less than the resource consumption threshold.

[0092] exist Figure 2 Section 230 also shows a schematic diagram of the target application's runtime cycle. For example... Figure 2 As shown in Figure 230, multiple operating cycles are illustrated, including the first operating cycle and the second operating cycle. Taking the first operating cycle as an example, the first operating cycle includes the peak and off-peak operating periods of the target application.

[0093] In the embodiments of this application, the target application and non-target application among the tenant's multiple applications can be determined in various ways.

[0094] In some implementations, target and non-target applications among a tenant's multiple applications can be identified through manual classification. Furthermore, the runtime of target applications can be set based on experience.

[0095] For example, users typically conduct transactions during the bank's business hours from 9:00 to 18:00. Based on experience, the bank's transaction application can be identified as the target application, and the operation cycle of the bank's transaction application can be set to one day, with the peak operation period of the transaction application being from 10:00 to 16:00.

[0096] In other implementations, historical runtime data from multiple applications of a tenant can be obtained, and the target and non-target applications can be automatically identified based on this data. This improves the accuracy and efficiency of application classification.

[0097] Over a historical period, the cloud computing system may have run multiple applications belonging to a tenant; that is, the cloud resources of the cloud computing system have been used to run multiple applications belonging to a tenant. The historical runtime data for each application may include runtime data of that application running on the cloud computing system over a historical period. Furthermore, computing devices, such as management device 130, can obtain the historical runtime data of multiple applications from the cloud computing system.

[0098] Historical runtime data for each application may include one or more of the following: historical runtime of the application, amount of resources consumed during the application's historical runtime, historical runtime latency of the application, number of requests processed during the application's historical runtime, and historical task processing time of the application.

[0099] The application's historical runtime can include the application's runtime within each historical period. For example, it can include the application's runtime for each day in the historical time period.

[0100] Historical runtime data can reflect or determine the application's historical runtime periods. For example, based on the daily runtime of a trading application, it can be determined that the trading application's runtime period regularly occurs between 9:00 AM and 6:00 PM each day. Conversely, based on the daily runtime of a profiling application, it can be determined that the profiling application's runtime occurs irregularly each day, such as at 8:00 AM one day and at 5:00 PM the next.

[0101] The amount of resources consumed during the application's historical execution can include the amount of resources consumed per unit of time during the application's runtime. The unit of time can be set according to requirements, such as 1 minute.

[0102] The historical runtime latency of an application can refer to the time taken from receiving the application's task (i.e., request) to completing the application's task in a historical period. In the embodiments of this application, the application's runtime latency can be the average latency of multiple tasks processed by the application during runtime.

[0103] The number of requests processed during the application's historical operation can refer to the number of requests processed per unit time during the application's runtime (i.e., the number of tasks processed). In this embodiment, the number of requests processed during application runtime can be the average number of requests processed per unit time during application runtime.

[0104] The historical task processing time of an application can refer to the time spent processing a task of the application during its runtime in the past. In the embodiments of this application, the historical task processing time of an application can be the average processing time of multiple tasks processed by the application during runtime.

[0105] In some embodiments, an application can be determined as a target application through various methods based on its historical runtime data. Some of these methods are described below.

[0106] As an example, an application can be identified as a target application based on its historical runtime and the number of requests it processed during its historical runtime.

[0107] For example, based on the historical runtime of application A and the number of requests processed during its historical runtime, it can be determined that application A runs and processes more requests than a certain threshold during certain periods in each or multiple historical cycles. In this way, it can be determined that application A regularly experiences peak runtime periods in each or multiple historical cycles, and application A is the target application.

[0108] Another example is that an application can be determined as a target application based on its historical runtime and the amount of resources it consumed during its historical runtime.

[0109] For example, based on the historical running times and resource consumption of application A during its historical operation, it can be determined that application A runs and consumes more resources than a resource consumption threshold during certain periods in each or multiple historical cycles. In this way, it can be determined that application A regularly experiences peak operating periods during certain periods in each or multiple historical cycles, and application A is identified as the target application.

[0110] In some embodiments, in addition to running according to a runtime cycle, the target application may also satisfy the requirement that the application's runtime latency is lower than a latency threshold. The latency threshold can be set according to requirements, for example, 10 minutes.

[0111] Thus, another example is that an application can be determined as a target application based on its runtime, the number of requests processed during its historical runtime, and / or the amount of resources consumed during its historical runtime, as well as its historical runtime latency.

[0112] For example, based on the running time of application A, the number of requests processed during the application's historical operation, and / or the amount of resources consumed during the application's historical operation, if it is determined that application A regularly experiences peak operating periods in certain periods of each or multiple historical cycles, and the historical runtime latency of application A is less than the latency threshold, then application A is the target application.

[0113] In some embodiments, in addition to running on a cycle, the target application may also meet service quality requirements higher than a service quality requirement threshold.

[0114] The Quality of Service (QoS) requirement of an application refers to the service quality required by the user for the application, which can be measured by the runtime latency required by the user for the application. The lower the runtime latency required by the application, the lower the QoS requirement of the application.

[0115] The service quality requirements of an application can be determined manually. For example, an application tag can be manually set for each application, and the application tag indicates the service quality requirements of the application.

[0116] The service quality requirement threshold can be determined based on demand; for example, the service quality requirement threshold could be a runtime latency of 10 minutes. Furthermore, if the runtime latency required by a certain application's service quality requirements is less than 10 minutes, then the application's service quality requirement is higher than the service quality requirement threshold.

[0117] Thus, another example is that an application can be determined as a target application based on its runtime, the number of requests processed during its historical runtime and / or the amount of resources consumed during its historical runtime, as well as its quality of service requirements.

[0118] In some embodiments, when a target application is determined among multiple applications according to the aforementioned method, the operating cycle of the target application can also be determined based on the historical operating data of the target application.

[0119] For example, based on the historical operation data of the target application, it is determined that the application A regularly experiences a peak operation period from 11:00 to 16:00 in each historical cycle (such as a day). Then the operation cycle of application A is 1 day, and the peak operation period in the operation cycle is from 11:00 to 16:00.

[0120] To facilitate understanding, taking a bank as an example of a cloud resource tenant, the following are examples of various applications used by the bank.

[0121] The bank's various applications include transaction applications, auditing applications, profiling applications, artificial intelligence training applications, and coupon distribution applications.

[0122] The historical operating data of multiple bank applications can be obtained using the aforementioned method. Based on the historical operating data of these multiple applications, if it is determined that the transaction application operates according to the operating cycle, the runtime latency of the transaction application is lower than the latency threshold, and the service quality requirements of the transaction application are higher than the service quality requirement threshold, then the transaction application is identified as the target application.

[0123] Furthermore, based on the historical operating data of these multiple applications, it was determined that the audit application, profiling application, artificial intelligence training application, and coupon distribution application did not run according to the operating cycle. Therefore, it was determined that the audit application, profiling application, artificial intelligence training application, and coupon distribution application were not target applications and were non-target applications.

[0124] Step 220: Perform the first management operation on cloud resources according to the target application's operating cycle.

[0125] The first management operation performed on cloud resources can indicate a switch in the status of the first resource in the cloud.

[0126] The first resource may include at least a portion of the cloud resources, and the amount of the first resource can be determined based on demand.

[0127] For example, the maximum resource consumption of the target application can be estimated based on experience or the resource consumption of the target application during its historical operation. Furthermore, the amount of the first resource can be determined based on the estimated maximum resource consumption of the target application. This ensures that the first resource can meet the resource requirements of the target application.

[0128] As an example, cloud resources include 100 virtual machines, and the first resource for the target application may include 30 virtual machines.

[0129] The status of the first resource includes allowing the first resource to be used to run the target application and allowing the first resource to be used to run both the target application and non-target applications.

[0130] Specifically, when the state of the first resource is "allowed to be used to run the target application," it can mean that the first resource is dedicated to running the target application, i.e., the first resource does not support running non-target applications. When the state of the first resource is "allowed to be used to run both the target application and non-target applications," it can mean that the first resource can be used by both the target application and non-target applications.

[0131] As mentioned earlier, the target application's runtime cycle reflects its peak runtime periods, such as peak hours. Switching the state of the primary cloud resource based on the target application's runtime cycle ensures that: during periods when the primary resource needs to be used extensively for running the target application, it is dedicated solely to running the target application, meeting its resource requirements. During periods when the primary resource is not extensively used for running the target application, it is no longer dedicated solely to it (thus leaving significant idle resources unused for the target application), but can be used for both the target and non-target applications, thus improving resource utilization and reducing waste.

[0132] In some embodiments, the first management operation may specifically include: during the peak operating period of the target application, switching the state of the first resource to allow the first resource to be used to run the target application; during the off-peak operating period of the target application, switching the state of the first resource to allow the first resource to be used to run both the target application and non-target applications.

[0133] By analyzing the peak operating hours of the target application, we can accurately determine the periods when the primary resource needs to be used more extensively to run the target application, and by analyzing the off-peak operating hours of the target application, we can accurately determine the periods when the primary resource is not used more extensively to run the target application. In this way, the above method enables more accurate switching of the primary resource's state, allowing for more efficient use of the primary resource and better reduction of resource waste.

[0134] As an example, taking a first resource that includes multiple virtual machines as an example, the first management operation may specifically include:

[0135] When the target application is currently in its peak operating period, check whether the status of the multiple virtual machines contained in the first resource is set to allow only the target application to run. If other applications (referring to applications other than the current target application, such as non-target applications) are running and occupying virtual machines in the first resource, then evict the other applications occupying the first resource, so that the status of all virtual machines in the first resource is switched to allow only the target application to run.

[0136] When the target application is not in its peak operating period, check if the status of the multiple virtual machines contained in the first resource is set to allow only the target application to run. If so, switch the status of the first resource to allow both the target and non-target applications to run. For example, add all virtual machines contained in the first resource to the list of schedulable resources so that non-target applications can use them when running.

[0137] In this application embodiment, the target application may include multiple applications. For any one target application, a first resource can be allocated in the cloud resources. That is, for multiple target applications, multiple first resources can be allocated in the cloud resources. Furthermore, each first resource can be accessed through... Figure 2 The method shown is used for management.

[0138] Figure 3 A flowchart illustrating the cloud resource management method provided in the embodiments of this application. Figure 2 . Figure 3 The cloud resource management method shown can be executed by a processing device. For example, it can be executed by the management device 130 in the cloud resource management system 100.

[0139] Figure 3 The method can be used to manage a second resource within cloud resources to run a non-target application. The second resource may include at least a portion of the cloud resources that are permitted to be used to run a non-target application.

[0140] For example, Figure 2 In the method shown, a portion of the cloud resources is designated as the first resource. When the first resource is in a state where it is allowed to be used to run the target application, the remaining portion of the cloud resources, excluding the first resource, is allowed to be used to run non-target applications. The remaining portion of the cloud resources is then designated as the second resource.

[0141] For example, Figure 2 In the method shown, a portion of the cloud resources is designated as the first resource. When the state of the first resource is such that it is allowed to be used to run both the target application and non-target applications, both the first resource and the remaining cloud resources (excluding the first resource) can be used to run non-target applications and thus can be designated as the second resource.

[0142] like Figure 3 As shown, the method includes the following steps.

[0143] Step 310: Determine at least one of the application categories and priorities of the multiple applications contained in the non-target application.

[0144] like Figure 2 As described above, non-target applications may include multiple applications, which may belong to multiple application categories.

[0145] In step 310, the application category of each of the multiple applications included in the non-target application can be determined, and the second resource in the cloud resources can be managed according to the application categories of these multiple applications.

[0146] Application categories can be set according to requirements. For example, non-target applications can include application categories such as real-time bursty and non-real-time.

[0147] In the embodiments of this application, the application category of each application among the multiple applications included in the non-target application can be determined by various methods.

[0148] In some implementations, the application category of each tenant's application can be determined through manual classification.

[0149] In other implementations, historical runtime data from multiple applications of a tenant can be obtained, and the application category of each application can be automatically determined based on this data. This improves the accuracy and efficiency of application classification.

[0150] The historical runtime data for each application may include one or more of the following: the application's historical runtime, the amount of resources consumed during the application's historical runtime, the application's historical runtime latency, the number of requests processed during the application's historical runtime, and the application's historical task processing time. For more information on application historical runtime data, please refer to [link to relevant documentation]. Figure 2 And its related descriptions.

[0151] In some embodiments, the application category of each application included in a non-target application can be determined in various ways based on the application's historical runtime data. Some of these methods are described below.

[0152] As an example, as mentioned earlier, non-target applications do not run according to the runtime cycle. Based on this, the application category of the application can also be determined according to the application's historical runtime latency.

[0153] For example, if the historical runtime latency of application B included in the non-target application is less than the latency threshold, and the application category of application B is real-time bursty.

[0154] For example, if the historical runtime latency of application B contained in a non-target application is greater than the latency threshold, then application B is classified as a non-real-time application.

[0155] Another example is that, in addition to determining the application category based on the application's historical runtime latency, the application category can also be determined based on the application's quality of service requirements.

[0156] For example, if the historical runtime latency of application B included in the non-target application is less than the latency threshold, and the service quality requirements of application B are higher than the service quality requirement threshold, then the application category of application B is real-time bursty.

[0157] For example, if the historical runtime latency of application B contained in a non-target application is greater than the latency threshold, and the service quality requirements of application B are lower than the service quality requirement threshold, then the application category of application B is non-real-time.

[0158] In step 310, the priority of each application among the multiple applications included in the non-target application can also be determined, and the second resource in the cloud resources can be managed according to the priority of these multiple applications.

[0159] The priority type can be set according to requirements. As an example, non-target applications can include priorities such as high priority, medium priority, and low priority.

[0160] In the embodiments of this application, the priority of each application among the multiple applications included in a non-target application can be determined by various methods.

[0161] In some implementations, the priority of each application for a tenant can be determined through manual classification.

[0162] In other implementations, historical runtime data from multiple applications of a tenant can be obtained, and the priority of each application can be automatically determined based on this data. This can improve the accuracy and efficiency of application tiering.

[0163] In some embodiments, the priority of each application included in a non-target application can be determined in various ways based on the application's historical runtime data. Some of these methods are described below.

[0164] As an example, an application's priority can be determined based on its historical task processing time. For instance, if application B's historical task processing time is less than a task processing time threshold, application B has high priority. If application B's historical task processing time is greater than the task processing time threshold, application B has medium or low priority. The task processing time threshold can be set according to requirements, such as 40 seconds.

[0165] Another example is that application priority can be determined based on the amount of resources consumed during its historical operation. For instance, if application B's resource consumption during its historical operation is less than the resource consumption threshold, application B is considered high priority. If application B's resource consumption during its historical operation is greater than the resource consumption threshold, application B is considered medium or low priority. The task processing time threshold can be set according to requirements.

[0166] Another example is that application priority can be determined based on the application's quality of service (QoS) requirements. For instance, if application B's QoS requirements are higher than the QoS requirement threshold, application B is considered high-priority or medium-priority. If application B's QoS requirements are lower than the QoS requirement threshold or there are no QoS requirements, application B is considered low-priority.

[0167] In some embodiments, the application priority can be determined by combining the application's historical task processing time, the amount of resources consumed during the application's historical operation, and the application's service quality requirements.

[0168] For example, if the historical task processing time of application B is less than the task processing time threshold, the amount of resources consumed during the historical operation of application B is less than the resource consumption threshold, and the service quality requirements of application B are higher than the service quality requirement threshold, then application B is of high priority.

[0169] For example, if the historical task processing time of application B exceeds the task processing time threshold, the amount of resources consumed during the historical operation of application B exceeds the resource consumption threshold, and the service quality requirements of application B exceed the service quality requirement threshold, then application B is of medium priority.

[0170] Step 320: Perform a second management operation on the cloud resources. The second management operation instructs the scheduling of a second resource in the cloud resources so that the second resource is used to run at least one application among the non-target applications.

[0171] In step 320, the scheduling method of the second resource is related to at least one of the application categories and priorities of the multiple applications included in the non-target application. Different second resource scheduling methods can be applied to applications of different application categories. Furthermore, different second resource scheduling methods can also be applied to applications of different priorities.

[0172] In the embodiments of this application, in order to facilitate the description and differentiation of various applications in non-target applications, the various applications in non-target applications can be represented by first application, second application, third application, etc.

[0173] In the first implementation, the second management operation on the cloud resources includes: when receiving a task from the first application and the resource occupancy rate of the second resource is lower than a first occupancy threshold (the first occupancy threshold can be set according to requirements, such as 100%, 95%, etc. As an example, the first occupancy threshold can be 100%, that is, there are idle resources in the second resource), using the idle resources to run the first application.

[0174] In the second implementation, the second management operation on the cloud resources includes: when a task from the first application is received and the resource occupancy rate of the second resource is higher than a second occupancy threshold (the first occupancy threshold can be set according to requirements, such as 95%, 99%, etc. As an example, the first occupancy threshold can be a value close to 100%, at which point it can be considered that there are no idle resources in the second resource), if a second application is running in the second resource, and the priority of the second application is lower than that of the first application, the resources used by the second application in the second resource are used to run the first application.

[0175] Based on this, when a task is received from the first application and there are few or no idle resources in the second resource pool, the system can preempt resources used by the second application, which has a lower priority than the first application, to run the first application. This effectively guarantees the resource needs of higher-priority applications.

[0176] In the third implementation, the second management operation on the cloud resources includes: when receiving a task from the first application and the resource occupancy rate of the second resource is higher than the second occupancy threshold (e.g., when there are no idle resources in the second resource), if there is no second application running in the second resource, the priority of the second application is lower than that of the first application, and the task running the first application is added to the waiting queue.

[0177] Based on this, when a task from the first application is received and a second application with a lower priority than the first application is running in the second resource, the task from the first application can be added to the waiting queue, ensuring that the task from the first application can continue to be executed when there are idle resources.

[0178] In the fourth implementation, the second management operation on the cloud resources includes: for certain applications of a specified category and / or priority, which may be referred to as third applications in this embodiment, when receiving a task from a third application, if the amount of idle resources in the second resources meets the target requirements, the idle resources in the second resources are allowed to be used to run the third application; otherwise, the idle resources in the second resources are not allowed to be used to run the third application.

[0179] The third application can meet at least one of the following conditions: the application category is the target category (the target category can be set according to requirements, such as non-real-time), and the priority is lower than the target priority (the target priority can be set according to requirements, such as medium priority or low priority).

[0180] The target requirements for the amount of idle resources can be set according to needs, such as the target requirements including the amount of idle resources being greater than a target threshold.

[0181] In some embodiments, the target requirement for the amount of idle resources is related to the priority of the third application. For example, when the third application is of medium priority, the target requirement for the amount of idle resources includes an idle resource quantity greater than zero. When the third application is of low priority, the target requirement for the amount of idle resources includes an idle resource quantity as a percentage of the second resource quantity greater than a target percentage (the target percentage can be set according to requirements, such as 30%).

[0182] In some embodiments, in the fourth implementation, the second management operation described above can be achieved by performing traffic control on the third application.

[0183] For example, if the third application is a target category such as non-real-time and the third application is of high priority, then when the task of the third application is received, the task of the third application is allowed to be released, and the second resource is allowed to be used to run the third application to process the task of the third application.

[0184] For example, if the third application is of a target category such as non-real-time and has a medium or low priority, then when receiving a task from the third application, if the amount of idle resources in the second resource meets the target requirements (e.g., the amount of idle resources is greater than zero, or the proportion of idle resources in the second resource is greater than the target proportion), then the task of the third application is allowed, and the second resource is permitted to be used to run the third application to process its task. Otherwise, the task of the third application is not allowed, making it impossible to schedule the task of the third application; that is, the idle resources in the second resource are not allowed to be used to run the third application.

[0185] According to the fourth implementation method, resource allocation for certain categories and / or lower-priority applications can be controlled more flexibly and precisely as needed (i.e., the idle resources in the second resource can only be used to run the third application if the amount of idle resources in the second resource meets the target requirements), ensuring that the second resource is used first to run other categories and / or applications with higher resource requirements.

[0186] In some embodiments, the first, second, and third implementations are applicable to the application category of the first application being real-time bursty.

[0187] In some embodiments, the first, second, third, and fourth implementation methods can be used in combination.

[0188] For example, if the third application is a non-real-time type and has a high priority, then when a task for the third application is received, the task for the third application is allowed. Also, if there are idle resources in the second resource, those idle resources are used to run the third application. If there are no idle resources in the second resource, and if there is an application with a lower priority than the third application running in the second resource (in this case, the third application can be considered the first application, and the application with a lower priority than the third application is the second application), the resources used by the application with a lower priority in the second resource are used to run the third application. Alternatively, if there are no idle resources in the second resource, and if there is an application with a lower priority than the third application running in the second resource, the task to run the third application is added to the waiting queue.

[0189] In some embodiments, the waiting queue can hold a limited number of tasks. When the number of tasks in the waiting queue has reached the maximum capacity, tasks waiting to be added to the waiting queue can be abandoned, i.e., task scheduling fails.

[0190] In some embodiments, the method further includes: checking whether a task in the waiting queue has timed out; if a task has timed out, the task can be removed from the waiting queue. A task removed from the waiting queue can be abandoned, i.e., task scheduling fails. If a task has not timed out, the aforementioned method can still be used to manage secondary resources to run the application and process the tasks in the waiting queue. Here, task timeout may refer to a task waiting in the waiting queue for a time exceeding a time threshold, which can be set according to requirements, such as 1 minute.

[0191] In this embodiment, a list of schedulable resources can be created for the second resource in the cloud resources, and the second resource can be scheduled by viewing and changing the status of resources in the list. The status of a resource may include whether the resource is idle, whether the resource is occupied by a certain application, etc.

[0192] In the cloud resource management method provided in the embodiments of this application, for example Figure 2 , Figure 3 The provided cloud resource management method allows for the deployment of a specific application to run on designated cloud resources once the resources allocated to it are identified. Furthermore, it enables the collection of runtime data during application operation, which can be used to analyze cloud resource management results and optimize the management method.

[0193] Figure 4 This is a schematic diagram of the software architecture of the cloud resource management system provided in the embodiments of this application. Figure 4 The software architecture in [the document] can be used to implement Figure 2 and Figure 3 The cloud resource management methods provided.

[0194] like Figure 4 As shown, the cloud resource management system may include an application profiling system 410, an application orchestration system 420, an application scheduling system 430, and an application execution system 440.

[0195] Application profiling system 410 can be used to acquire operational data of applications in a cloud computing system, and can also be used to analyze application operational data to create application profiles, obtaining application profile data (such as profile data like the target application's runtime cycle). Application profiling system 140 can be used to implement... Figure 2 The steps in step 210 include, for example, the application profiling system 410 is used to determine the operating cycle of the target application based on the historical operating data of multiple applications of the tenant.

[0196] Application orchestration system 420 can be used to determine the application category and priority of an application. In some embodiments, application coding system 420 can be used to acquire application profile data from application profiling system 410, and determine the application category and priority of an application based on the application profile data from application profiling system 410.

[0197] In some embodiments, the application orchestration system 420 can be used to implement Figure 3 The steps in step 310, for example, include the application coding system 420 being used to determine the application category and priority of each application among the tenant's multiple applications.

[0198] In some embodiments, the application profiling system 410 can also be used to determine the application category and priority of an application, and to feed back the application category and priority of an application to the application coding system 420 to assist the application coding system 420 in determining the application category and priority of an application more accurately.

[0199] In some embodiments, the application profiling system 410 can collect application runtime data from the cloud computing system multiple times to update the application profile data. Thus, as the application continues to run, the application profile data becomes increasingly accurate, as do the application categories and priorities.

[0200] The application scheduling system 430 can be used to manage cloud resources based on the application profile data (e.g., the runtime of the target application) of the application profile system 410, the application category and / or application priority determined by the application orchestration system 420, so as to schedule cloud resources for running tenant applications.

[0201] In some embodiments, the application scheduling system 430 can be used to implement Figure 2 The steps in step 220 include, for example, the application scheduling system 430 being used to perform the first management operation on cloud resources. Furthermore, the application scheduling system 430 can also be used to implement... Figure 3 The steps in step 320, for example, the application scheduling system 430 can be used to perform a second management operation on cloud resources.

[0202] The application execution system 440 can be used to manage the running of applications on cloud resources based on the cloud resource scheduling results of the application scheduling system 430, such as deploying tenant applications to run on corresponding resources.

[0203] The application execution system 440 can also be used to manage the task processing results obtained from application execution. For example, the application execution system 440 can obtain the task processing results obtained from running applications on cloud resources, and can also be used to feed back the task processing results to the user terminal.

[0204] The application execution system 440 can also acquire the running data of applications in the cloud computing system, and the running data of the applications can be provided to the application profiling system 410 for analysis.

[0205] It is worth noting that, Figure 4The software architecture shown is merely an example and does not limit the implementation of the cloud resource management method provided in the embodiments of this application.

[0206] The above text combines Figures 2 to 4 This document describes in detail the cloud resource management method provided according to embodiments of this application. The following will combine... Figure 5 This application describes the apparatus provided according to the present application. These apparatuses can be used to implement the functions of the processor in the above method embodiments, and thus can also achieve the beneficial effects of the above method embodiments.

[0207] Figure 5 This is a schematic diagram of the structure of a cloud resource management device provided in an embodiment of this application. Figure 5 As shown, the cloud resource management device 500 includes a first management module 510 and a second management module 520.

[0208] The first management module 510 is used to determine a target application from multiple applications, wherein the target application includes applications that run according to a runtime cycle among the multiple applications. It also acquires the status of a first resource in cloud resources, the status of the first resource including allowing the first resource to be used to run the target application, allowing the first resource to be used to run the target application, and allowing non-target applications, wherein non-target applications include applications other than the target application among the multiple applications. Furthermore, it performs a first management operation on the first resource according to the runtime cycle of the target application, the first management operation indicating a switch in the status of the first resource.

[0209] In some implementations, the first management module 510 is also used to: switch the state of the first resource to allow the first resource to be used to run the target application during the peak running period of the target application; and switch the state of the first resource to allow the first resource to be used to run both the target application and non-target applications during the off-peak running period of the target application.

[0210] In some implementations, the first management module 510 is also used to: determine the target application and the running cycle of the target application among the multiple applications based on the historical running data of multiple applications.

[0211] The second management module 520 is used to perform a second management operation on cloud resources. The second management operation instructs the scheduling of a second resource in the cloud resources so that the second resource is used to run at least one application in the non-target application. The scheduling method of the second resource is related to at least one of the application categories and priorities of the multiple applications contained in the non-target application.

[0212] In some implementations, the non-target applications include a first application and a second application, where the first application has a higher priority than the second application. The second management module 520 is also used to: when receiving a task from the first application and the resource occupancy rate of the second resource is higher than the occupancy threshold, use the resources in the second resource that are used to run the second application to run the first application; or if there is no second application running in the second resource, add the task of the first application to the waiting queue.

[0213] In some implementations, the second management module 520 is also used to remove tasks from the waiting queue whose waiting time exceeds a time threshold.

[0214] In some implementations, the non-target application includes a third application, which satisfies at least one of the following: the application category is the target category or the priority is lower than the target priority. The second management module 520 is further configured to: upon receiving a task from a third application, if the amount of idle resources in the second resource meets the target requirements, allow the idle resources in the second resource to be used to run the third application; otherwise, disallow the idle resources in the second resource to be used to run the third application.

[0215] In some implementations, the second management module 520 is also used to: determine the application category or priority of the multiple applications included in the non-target application based on the historical running data of the multiple applications included in the non-target application.

[0216] In some implementations, historical runtime data includes at least one of the following: the application's historical runtime, the amount of resources consumed during the application's historical runtime, the application's historical runtime latency, the number of requests processed during the application's historical runtime, and the application's historical task processing time.

[0217] For a more detailed description of the functions of the first management module 510 and the second management module 520, please refer to the embodiments of this application. Figures 2-3 The relevant descriptions in the cloud resource management methods proposed in the paper.

[0218] Optionally, the first management module 510 and the second management module 520 may each include multiple sub-modules, and the multiple sub-modules may be deployed separately to implement part of the functions of the corresponding module, such as implementing the aforementioned Figures 2-3 One or more steps of the cloud resource management method provided in [the document / platform].

[0219] Both the first management module 510 and the second management module 520 can be implemented in software or in hardware. For example, the implementation of the first management module 510 will be described below. Similarly, the implementation of the second management module 520 can refer to the implementation of the first management module 510.

[0220] As an example of a software functional unit, the first management module 510 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Further, the aforementioned computing instance may be one or more. For example, the first management module 510 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed in the same region or in different regions. Further, the multiple hosts / virtual machines / containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including one or more geographically proximate data centers. Typically, a region may include multiple AZs.

[0221] Similarly, multiple hosts / virtual machines / containers used to run this code can be distributed within the same Virtual Private Cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Communication between two VPCs within the same region, as well as between VPCs in different regions, requires a communication gateway to be set up within each VPC to enable interconnection between VPCs.

[0222] As an example of a hardware functional unit, the first management module 510 may include at least one computing device, such as a server. Alternatively, the first management module 510 may also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be implemented using a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), or any combination thereof.

[0223] The multiple computing devices included in the first management module 510 can be distributed in the same region or in different regions. Similarly, the multiple computing devices included in the first management module 510 can be distributed in the same Availability Zone (AZ) or in different AZs. Likewise, the multiple computing devices included in the first management module 510 can be distributed in the same Virtual Private Cloud (VPC) or in multiple VPCs. These multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0224] It should be noted that, in other embodiments, the first management module 510 can be used to execute... Figures 2-3 The second management module 520 can be used to execute any step in the cloud resource management method provided in the documentation. Figures 2-3 Any step in the cloud resource management method provided herein, the steps implemented by the first management module 510 and the second management module 520 can be specified as needed, and implemented by the first management module 510 and the second management module 520 respectively. Figures 2-3 The cloud resource management method provided in the article uses different steps to realize all the functions of the cloud resource management device 500.

[0225] This application also provides a computing device 600. For example... Figure 6 As shown, the computing device 600 includes: a bus 602, a processor 604, a memory 606, and a communication interface 608. The processor 604, memory 606, and communication interface 608 communicate with each other via the bus 602. The computing device 600 can be a server or a terminal device. It should be understood that this application does not limit the number of processors and memories in the computing device 600. Optionally, the processor 604 of the computing device 600 can be connected to a display or input device via the communication interface 608. Figure 6 (Not shown in the image).

[0226] Bus 602 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be divided into address buses, data buses, control buses, etc. For ease of representation, Figure 6 The bus 602 may be represented by a single line, but this does not mean that there is only one bus or one type of bus. The bus 602 may include a path for transmitting information between various components of the computing device 600 (e.g., memory 606, processor 604, communication interface 608).

[0227] Processor 604 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP). In this embodiment, processor 604 is used to perform the steps or operations described in this embodiment.

[0228] Memory 606 may include volatile memory, such as random access memory (RAM). Processor 604 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0229] The memory 606 stores executable program code, and the processor 604 executes the executable program code to implement the functions of the aforementioned first management module 510 and second management module 520, thereby realizing the embodiments of this application. Figures 2-3 The cloud resource management method provided in this application. That is, the memory 606 stores the data for executing the embodiments of this application. Figures 2-3 The instructions provided in the cloud resource management method.

[0230] The communication interface 608 uses transceiver modules, such as, but not limited to, network interface cards and transceivers, to enable communication between the computing device 600 and other devices or communication networks.

[0231] The display may include various display devices capable of display functions, such as plasma displays and liquid crystal displays. The computing device 600 can implement the embodiments of this application through the display. Figures 2-3 The cloud resource management methods provided in the document involve display functions.

[0232] Input devices can include various input devices that enable information / signal input, such as keyboards, mice, and touch screens.

[0233] This application also provides a computing device cluster 700. For example... Figure 7 As shown, the computing device cluster includes at least one computing device 600. The memory 606 of one or more computing devices 600 in the computing device cluster may store the same memory for executing the embodiments of this application. Figures 2-3The instructions provided in the cloud resource management method.

[0234] In some possible implementations, the memory 606 of one or more computing devices 600 in the computing device cluster may also store memory for executing the embodiments of this application. Figures 2-3 The instructions provided in the cloud resource management method are partially specified. In other words, a combination of one or more computing devices 600 can jointly execute instructions for performing the embodiments of this application. Figures 2-3 The instructions provided in the cloud resource management method.

[0235] It should be noted that the memory 606 in different computing devices 600 within the computing device cluster can store different instructions, which are used to implement some functions of the cloud resource management device 500. That is, the instructions stored in the memory 606 of different computing devices 600 can implement the functions of one or more modules in the aforementioned first management module 510 and second management module 520.

[0236] In some possible implementations, one or more computing devices in a computing device cluster can be connected via a network. This network can be a wide area network (WAN) or a local area network (LAN), etc.

[0237] Figure 8 One possible implementation is shown. For example... Figure 8 As shown, the two computing devices 600A and 600B are connected via a network. Specifically, they are connected to the network through communication interfaces in each computing device. In this possible implementation, the memory 606 in computing device 600A stores instructions for executing the functions of the first management module 510. Simultaneously, the memory 606 in computing device 600B stores instructions for executing the functions of the second management module 520.

[0238] Figure 8 The connection method between the computing device clusters shown can be that, considering the cloud resource management method provided in this application needs to manage the data of the waiting queue, the function implemented by the second management module 520 is handed over to the computing device 600B for execution.

[0239] It should be understood that Figure 8 The functions of computing device 600A shown can also be performed by multiple computing devices 600. Similarly, the functions of computing device 600B can also be performed by multiple computing devices 600.

[0240] This application also provides another computing device cluster. The connection relationships between the computing devices in this computing device cluster can be similarly referred to... Figure 7 and Figure 8The connection method of the computing device cluster is different. One or more computing devices 600 in this computing device cluster may store the same memory 606 for executing the embodiments of this application. Figures 2-3 The instructions provided in the cloud resource management method.

[0241] In some possible implementations, the memory 606 of one or more computing devices 600 in the computing device cluster may also store memory for executing the embodiments of this application. Figures 2-3 The instructions provided in the cloud resource management method are partially specified. In other words, a combination of one or more computing devices 600 can jointly execute instructions for performing the embodiments of this application. Figures 2-3 The instructions provided in the cloud resource management method.

[0242] This application also provides a computer program product containing instructions. The computer program product may be a software or program product containing instructions, capable of running on a computing device or stored on any usable medium. The instructions contained in the computer program product may include instructions for performing the embodiments described in this application. Figures 2-3 The instructions for the cloud resource management method provided herein. When the computer program product is run on at least one computing device, the at least one computing device executes the instructions in the embodiments of this application. Figures 2-3 The steps or operations of the cloud resource management methods provided in the document.

[0243] This application also provides a computer-readable storage medium. The computer-readable storage medium can be any available medium that a computing device can store, or a data storage device such as a data center containing one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium (e.g., solid-state drive). The computer-readable storage medium includes instructions that instruct the computing device to execute the embodiments described in this application. Figures 2-3 The steps or operations of the cloud resource management methods provided in the document.

[0244] Finally, it should be noted that 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 protection scope of the technical solutions of the embodiments of this application.

[0245] The terms “first,” “second,” “third,” and “fourth,” etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish different objects, not to define a specific order.

[0246] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

Claims

1. A cloud resource management method, characterized in that, The cloud resources are used to run multiple applications for a tenant, and the method includes: A target application is determined from the plurality of applications, the target application including applications that run according to a runtime cycle among the plurality of applications; Obtain the status of a first resource in the cloud resources. The status of the first resource includes allowing the first resource to be used to run the target application or allowing the first resource to be used to run the target application and non-target applications. The non-target applications include applications other than the target application among the plurality of applications. A first management operation is performed on the first resource according to the operating cycle of the target application, and the first management operation indicates a switch in the state of the first resource.

2. The method according to claim 1, characterized in that, The first management operation on the first resource according to the runtime cycle of the target application includes: During the peak operating period of the target application, the state of the first resource is switched to allow the first resource to be used to run the target application; During off-peak hours of the target application, the state of the first resource is switched to allow the first resource to be used to run both the target application and the non-target application.

3. The method according to claim 1 or 2, characterized in that, The method further includes: Based on the historical operating data of the multiple applications, the target application and its operating cycle are determined among the multiple applications.

4. The method according to any one of claims 1-3, characterized in that, The non-target applications include multiple applications other than the target application among the multiple applications, and the method further includes: A second management operation is performed on the cloud resources, the second management operation instructing the scheduling of a second resource in the cloud resources so that the second resource is used to run at least one application in the non-target application, wherein the scheduling method of the second resource is related to at least one of the application categories and priorities of the multiple applications included in the non-target application.

5. The method according to claim 4, characterized in that, The non-target applications include a first application and a second application, wherein the first application has a higher priority than the second application, and the second management operation on the cloud resources includes: When the task from the first application is received and the resource utilization rate of the second resource is higher than the utilization threshold: The first application is run by using the resources allocated to the second application within the second resource; or... If the second application is not running in the second resource, add the task of the first application to the waiting queue.

6. The method according to claim 4 or 5, characterized in that, The non-target application includes a third application, which satisfies at least one of the following: the application category is the target category or the priority is lower than the target priority. The second management operation on the cloud resource includes: When receiving a task from the third application, if the amount of idle resources in the second resource meets the target requirements, the idle resources in the second resource are allowed to be used to run the third application; otherwise, the idle resources in the second resource are not allowed to be used to run the third application.

7. The method according to any one of claims 4-6, characterized in that, The method further includes: Based on the historical running data of the multiple applications included in the non-target application, the application category or priority of the multiple applications included in the non-target application is determined.

8. The method according to claim 3 or 7, characterized in that, The historical operational data includes at least one of the following: The application's historical runtime, the amount of resources consumed during the application's historical runtime, the application's historical runtime latency, the number of requests processed during the application's historical runtime, and the application's historical task processing time.

9. A cloud resource management device, characterized in that, The cloud resources are used to run multiple applications for a tenant. The device includes a first management module, which is used to: A target application is determined from the plurality of applications, the target application including applications that run according to a runtime cycle among the plurality of applications; Obtain the status of a first resource in the cloud resources. The status of the first resource includes allowing the first resource to be used to run the target application or allowing the first resource to be used to run the target application and non-target applications. The non-target applications include applications other than the target application among the plurality of applications. A first management operation is performed on the first resource according to the operating cycle of the target application, and the first management operation indicates a switch in the state of the first resource.

10. The apparatus according to claim 9, characterized in that, The non-target applications include multiple applications other than the target application among the multiple applications. The device further includes a second management module, which is used to: A second management operation is performed on the cloud resources, the second management operation instructing the scheduling of a second resource in the cloud resources so that the second resource is used to run at least one application in the non-target application, wherein the scheduling method of the second resource is related to at least one of the application categories and priorities of the multiple applications included in the non-target application.

11. A computing device cluster, characterized in that, The computing device cluster includes at least one computing device, and each computing device includes a processor and memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the cluster of computing devices to perform the method as described in any one of claims 1-8.

12. A computer program product containing instructions, characterized in that, When the instruction is executed by at least one computing device, the at least one computing device performs the method as described in any one of claims 1-8.

13. A computer-readable storage medium, characterized in that, Includes computer program instructions, which, when executed by a cluster of computing devices, perform the method as described in any one of claims 1-8.

Images