Cloud instance management method based on cloud management platform and cloud management platform

Abstract

The invention discloses a cloud instance management method based on a cloud management platform and the cloud management platform, which can avoid the hot spot problem of a physical server to a certain extent. The method comprises the steps that a cloud management platform receives a token setting request from a user through a setting interface, the token setting request is used for indicating various tokens set by the user for a plurality of physical servers, and the various tokens are used for indicating a plurality of sub available resources of different specifications obtained by dividing available resources of the physical servers; the cloud management platform allocates at least one token in a plurality of tokens to the plurality of physical servers based on the token setting request and current available resources of the plurality of physical servers; the cloud management platform determines a target physical server from the multiple physical servers and creates a cloud instance of the user in the target physical server, and at least one token of the target physical server comprises a token matched with the load when the cloud instance runs.

Description

[0001] This application claims the priority of a Chinese patent application with the application number 202311544855.6 and the invention title "A Cloud Instance Management Method and a Cloud Management Platform Based on a Cloud Management Platform" submitted to the National Intellectual Property Administration on November 17, 2023, the entire content of which is incorporated herein by reference. Technical Field

[0002] Embodiments of this application relate to the field of cloud technologies, and in particular, to a cloud instance management method and a cloud management platform based on a cloud management platform. Background Art

[0003] With the rapid development of cloud technologies, more and more users choose to use cloud service systems to provide cloud services to meet their own business needs. For example, users can use various services such as cloud computing and cloud storage provided by cloud service systems to complete data processing with the help of the cloud, so as to meet their own data processing needs.

[0004] In a cloud service system in related technologies, a physical server can create virtual machines on itself to provide cloud services for users through the virtual machines. Since at least one virtual machine can be deployed on the physical server, and these virtual machines on the physical server will occupy the resources of the physical server when running, when the amount of resources used by these virtual machines exceeds a certain threshold, a hotspot problem will occur on the physical server. To solve the hotspot problem, usually, the virtual machines on the physical server can be migrated to another physical server, and this problem can be solved.

[0005] In the above process, although the hotspot problem of the physical server can be solved by migrating virtual machines, this method is often post - processing, that is, when migrating virtual machines, the hotspot problem has already occurred. Therefore, how to prevent the occurrence of the hotspot problem has become an urgent problem to be solved. Summary of the Invention

[0006] Embodiments of this application provide a cloud instance management method and a cloud management platform based on a cloud management platform, which can actively manage the resources available for deploying cloud instances in a physical server by means of tokens, and can avoid the occurrence of hotspot problems on the physical server to a certain extent.

[0007] In a first aspect of embodiments of this application, a cloud instance management method based on a cloud management platform is provided, where the cloud management platform is used to manage the infrastructure for providing cloud services, and the infrastructure includes multiple physical servers. The method includes:

[0008] When a user needs to set tokens for multiple physical servers, the cloud management platform can provide a setting interface to the user. Therefore, the user can send a token setting request of the user to the setting interface, so that the cloud management platform receives the token setting request through the setting interface. Among them, the token setting request is used to indicate multiple tokens set by the user for multiple physical servers, and these multiple tokens are used to indicate multiple sub-available resources of different specifications obtained by dividing the available resources of the physical servers.

[0009] After receiving the token setting request, the cloud management platform can determine based on the token setting request that the user needs to allocate multiple tokens selected by the user to multiple physical servers. Then, the cloud management platform can obtain the current available resources of the multiple physical servers, and based on the current available resources of the multiple physical servers, allocate at least one of the multiple tokens selected by the user to the multiple physical servers.

[0010] After the cloud management platform completes the token allocation for multiple physical servers, when the user needs to create a cloud instance, the cloud management platform can provide a creation interface to the user. Therefore, the user can send a cloud instance creation request of the user to the creation interface, so that the cloud management platform receives the cloud instance creation request through the creation interface. Among them, the cloud instance creation request is used to indicate the cloud instance that the user needs to create.

[0011] After receiving the cloud instance creation request, the cloud management platform can determine the load at runtime of the cloud instance that the user needs to create based on the cloud instance creation request, and determine the token that matches the load. Then, the cloud management platform can select, from multiple physical servers, the physical server with the token as the target physical server, and create the user's cloud instance on the target physical server. In this way, the cloud instance created by the cloud management platform on the target physical server can provide cloud services to the user, thereby meeting the user's business needs.

[0012] As can be seen from the above method: when a user needs to set tokens for multiple physical servers, the user can send a token setting request to the cloud management platform through the setting interface provided by the cloud management platform. The token setting request is used to indicate multiple types of tokens set by the user for multiple physical servers. These multiple types of tokens are used to indicate multiple sub-available resources of different specifications obtained by partitioning the available resources of the physical servers. Then, based on the token setting request, the cloud management platform can determine that token setting needs to be performed for multiple physical servers. Therefore, the cloud management platform can use the current available resources of the multiple physical servers as a reference benchmark and allocate at least one of these multiple types of tokens to the multiple physical servers. Then, when the user needs to create a cloud instance, the cloud management platform can traverse the multiple physical servers. If a certain physical server has a token that matches the load during the operation of the user's cloud instance, the cloud management platform can determine that physical server as the target physical server and create the user's cloud instance in the target physical server so that these cloud instances can provide cloud services for the user. In the foregoing process, for any one of the multiple physical servers, the cloud management platform can allocate at least one type of token to this physical server under the instruction of the user. These tokens represent how many resources in the current available resources of this physical server can be used to create cloud instances (related to the total number of these tokens), and these tokens represent how many types of cloud instances the resources of this physical server available for creating cloud instances can specifically support (related to the types of these tokens) and how many cloud instances of each type there are (related to the quantity of each type of token). Then, when the user needs to create a cloud instance, if there is a token on this physical server that matches the load during the operation of the user's cloud instance, it means that the resources of this physical server are sufficient, and the cloud management platform will create the user's cloud instance on this physical server. If not, it means that the resources of this physical server are insufficient, and the cloud management platform can create the user's cloud instance on the remaining physical servers. Thus, it can be seen that by way of token allocation to plan in advance the resources in the physical server available for deploying cloud instances and by way of token application and consumption to actively manage the resources in the physical server available for deploying cloud instances, it is possible to avoid the hot spot problem of physical servers to a certain extent.

[0013] In a possible implementation, the token setting request includes at least one of the following: description information of multiple physical servers, description information of multiple types of tokens, description information of multiple sub-available resources, constraints that multiple types of tokens need to satisfy, and optimization objectives for multiple physical servers affected by multiple types of tokens. In the foregoing implementation, the token setting request may include description information of multiple physical servers, description information of multiple types of tokens selected by the user, description information of multiple sub-available resources indicated by the multiple types of tokens, constraints that the multiple types of tokens need to satisfy, and optimization objectives for multiple physical servers affected by the multiple types of tokens. Thus, it can be seen that the token setting request includes various information related to multiple types of tokens selected by the user for multiple physical servers. Therefore, the token setting request can be used to indicate the multiple types of tokens.

[0014] In a possible implementation, the cloud management platform allocates at least one of multiple tokens to multiple physical servers based on a token setting request and the current available resources of the multiple physical servers, including: the cloud management platform obtains the current load of the multiple physical servers based on the token setting request, and determines the current available resources of the multiple physical servers based on the current load; the cloud management platform performs a simulation allocation based on multiple tokens for the multiple physical servers based on the current available resources, constraints, and optimization goals, to obtain multiple token allocation policies; the cloud management platform obtains the predicted load of the multiple physical servers based on the current load, and determines a target token allocation policy from the multiple token allocation policies based on the predicted load; the cloud management platform performs an actual allocation based on multiple tokens for the multiple physical servers according to the target token allocation policy, so that the multiple physical servers have at least one of the multiple tokens. In the foregoing implementation, after receiving the token setting request, the cloud management platform can first collect the current load of the multiple physical servers in real time and calculate the current load of the multiple physical servers, so as to obtain the current available resources of the multiple physical servers. Then, based on the current available resources of the multiple physical servers, the constraints that the multiple tokens selected by the user need to meet, and the optimization goals for the multiple physical servers affected by these multiple tokens, the cloud management platform performs a simulation allocation based on these multiple tokens for the multiple physical servers, so as to obtain multiple token allocation policies. Next, the cloud management platform can obtain a prediction based on the current load of the multiple physical servers, so as to obtain the predicted load of the multiple physical servers. Subsequently, the cloud management platform can find the optimal token allocation policy from the multiple token allocation policies based on the predicted load of the multiple physical servers and determine it as the target token allocation policy. Finally, the cloud management platform can perform an actual allocation based on these multiple tokens for the multiple physical servers according to the indication of the target token allocation policy, so that the multiple physical servers have at least one of the multiple tokens selected by the user. Thus, when allocating tokens to physical servers, the cloud management platform can comprehensively consider the impact of the current load of the physical servers and the future load of the physical servers, take into account the long-term load balancing of the physical servers, correctly allocate tokens to the physical servers, and ensure the effective utilization of the resources of the physical servers.

[0015] In a possible implementation, the token and the load satisfy any of the following: the specification of the sub-available resource indicated by the token is greater than or equal to the specification of the load; the specification of the sub-available resource indicated by the token is greater than or equal to the specification of the load, and the difference between the specification of the sub-available resource indicated by the token and the specification of the load is within a preset range. In the foregoing implementation, after determining the load at the time of running the cloud instance that the user needs to create, the cloud management platform can traverse multiple physical servers based on the indication of the loose token filtering policy. If it is found that a certain physical server has a certain token and the specification of the sub-available resource indicated by the token is greater than or equal to the specification of the load at the time of running the cloud instance, the cloud management platform directly determines the physical server as the target physical server. Of course, the cloud management platform can also traverse multiple physical servers according to the indication of the strict token filtering policy. If it is found that a certain physical server has a certain token, the specification of the sub-available resource indicated by the token is greater than or equal to the specification of the load at the time of running the cloud instance, and the difference between the specification of the sub-available resource indicated by the token and the specification of the load at the time of running the cloud instance is within a preset range, the cloud management platform directly determines the physical server as the target physical server. Thus, it can be seen that the cloud management platform can accurately select the target physical server from multiple physical servers according to the loose token filtering policy and the strict token filtering policy, and create the user's cloud instance on the target physical server. It can be seen that these policies can ensure that when the resources of the physical server are sufficient, the cloud management platform can successfully respond to the user's cloud instance creation requirement in the way of token application and token consumption.

[0016] In a possible implementation, the method further includes: the cloud management platform displays the following at least one item to the user through a display interface: the tokens remaining on multiple physical servers, the token combinations included in the remaining tokens and the number of combinations, the process of change of the optimization target for multiple physical servers over time, the process of determining tokens from the target physical server, and the process of removing tokens. In the foregoing implementation, the cloud management platform displays one or more of the following contents to the user through the display interface: the tokens remaining on multiple physical servers, the multiple token combinations included in these remaining tokens and the number of each token combination, the process of change of the optimization target for multiple physical servers over time, the process of determining tokens from the target physical server, the process of removing tokens, and so on. Thus, it can be seen that the cloud management platform can also display the available resource situation and the remaining token situation of multiple physical servers to the user in real time, avoid black box management, and help the user fine-tune the available resources of multiple physical servers in real time.

[0017] In a possible implementation, the method further includes: the cloud management platform removes tokens from the target physical server.

[0018] In a possible implementation manner, the cloud instance includes at least one of the following: physical server, virtual machine, container, micro virtual machine, and bare metal server.

[0019] A second aspect of the embodiments of the present application provides a cloud management platform. The cloud management platform is used to manage the infrastructure that provides cloud services. The infrastructure includes multiple physical servers. The cloud management platform includes: a receiving module, configured to receive a token setting request from a user through a setting interface. The token setting request is used to indicate multiple tokens set by the user for the multiple physical servers. The multiple tokens are used to indicate multiple sub-available resources of different specifications obtained by partitioning the available resources of the physical servers; an allocation module, configured to allocate at least one of the multiple tokens to the multiple physical servers based on the token setting request and the current available resources of the multiple physical servers; a creation module, configured to determine a target physical server from the multiple physical servers and create a cloud instance of the user in the target physical server. At least one token possessed by the target physical server includes a token that matches the load during the operation of the cloud instance.

[0020] In a possible implementation manner, the token setting request includes at least one of the following: description information of the multiple physical servers, description information of the multiple tokens, description information of the multiple sub-available resources, constraints that the multiple tokens need to satisfy, and optimization objectives for the multiple physical servers affected by the multiple tokens.

[0021] In a possible implementation manner, the allocation module is configured to: obtain the current load of the multiple physical servers based on the token setting request, and determine the current available resources of the multiple physical servers based on the current load; perform a simulated allocation based on the multiple tokens on the multiple physical servers based on the current available resources, constraints, and optimization objectives to obtain multiple token allocation policies; obtain the predicted load of the multiple physical servers based on the current load, and determine a target token allocation policy from the multiple token allocation policies based on the predicted load; perform an actual allocation based on the multiple tokens on the multiple physical servers according to the target token allocation policy, so that the multiple physical servers have at least one of the multiple tokens.

[0022] In a possible implementation manner, the cloud management platform further includes: a removal module, configured to remove tokens from the target physical server.

[0023] In a possible implementation manner, the token and the load satisfy any one of the following: the specification of the sub-available resource indicated by the token is greater than or equal to the specification of the load; the specification of the sub-available resource indicated by the token is greater than or equal to the specification of the load, and the difference between the specification of the sub-available resource indicated by the token and the specification of the load is within a preset range.

[0024] In a possible implementation manner, the cloud management platform further includes: a display module, configured to display to a user through a display interface at least one of the following: tokens remaining in multiple physical servers, token combinations included in the remaining tokens and the number of combinations, the process of change over time of optimization objectives for multiple physical servers, the process of determining tokens from a target physical server, and the process of removing tokens.

[0025] In a possible implementation manner, the cloud instance includes at least one of the following: a physical server, a virtual machine, a container, a micro virtual machine, and a bare metal server.

[0026] A third aspect of the embodiments of the present application provides a computing device cluster, which includes at least one computing device, and each computing device includes a processor and a memory: the memory is used to store instructions; the processor is configured to execute, according to the instructions, to cause the computing device cluster to execute the method described in the first aspect or any possible implementation manner in the first aspect.

[0027] A fourth aspect of the embodiments of the present application provides a computer storage medium, which stores one or more instructions, and when the instructions are executed by one or more computers, the one or more computers are caused to implement the method described in the first aspect or any possible implementation manner in the first aspect.

[0028] A fifth aspect of the embodiments of the present application provides a computer program product, characterized in that the computer program product stores instructions, and when the instructions are executed by a computer, the computer is caused to implement the method described in the first aspect or any possible implementation manner in the first aspect.

[0029] In the embodiments of the present application, when a user needs to set tokens for multiple physical servers, the user can send a token setting request to the cloud management platform through the setting interface provided by the cloud management platform. The token setting request is used to indicate multiple types of tokens set by the user for the multiple physical servers. These multiple types of tokens are used to indicate multiple sub-available resources of different specifications obtained by partitioning the available resources of the physical servers. Then, based on the token setting request, the cloud management platform can determine that token settings need to be performed for the multiple physical servers. Therefore, the cloud management platform can use the current available resources of the multiple physical servers as a reference benchmark and allocate at least one of these multiple types of tokens to the multiple physical servers. Then, when the user needs to create a cloud instance, the cloud management platform can traverse the multiple physical servers. If a certain physical server has a token that matches the load during the operation of the user's cloud instance, the cloud management platform can determine that physical server as the target physical server and create the user's cloud instance in the target physical server, so that these cloud instances can provide cloud services for the user. In the foregoing process, for any one of the multiple physical servers, the cloud management platform can allocate at least one token to the physical server under the user's instruction. These tokens represent how many resources in the current available resources of the physical server can be used to create cloud instances (related to the total number of these tokens), and these tokens represent how many types of cloud instances the resources of this physical server available for creating cloud instances can specifically support (related to the types of these tokens) and how many cloud instances of each type there are (related to the number of each type of token). Then, when the user needs to create a cloud instance, if there is a token on the physical server that matches the load during the operation of the user's cloud instance, it means that the resources of the physical server are sufficient, and the cloud management platform will create the user's cloud instance on this physical server. If not, it means that the resources of the physical server are insufficient, and the cloud management platform can create the user's cloud instance on the remaining physical servers. It can be seen that by allocating tokens to plan in advance the resources in the physical server that can be used to deploy cloud instances and actively manage the resources in the physical server that can be used to deploy cloud instances through token application and consumption, the hot spot problem of the physical server can be avoided to a certain extent. BRIEF DESCRIPTION OF THE DRAWINGS

[0030] Figure 1 FIG. is a schematic structural diagram of a cloud service system provided by an embodiment of the present application;

[0031] Figure 2 FIG. is a schematic diagram of a cloud instance management method based on a cloud management platform provided by an embodiment of the present application;

[0032] Figure 3 FIG. is a schematic diagram of a user interface provided by an embodiment of the present application;

[0033] Figure 4Another schematic diagram of the user interface provided by the embodiments of the present application;

[0034] Figure 5 A schematic structural diagram of the cloud management platform provided by the embodiments of the present application;

[0035] Figure 6 Another schematic diagram of the user interface provided by the embodiments of the present application;

[0036] Figure 7 A schematic structural diagram of the cloud management platform provided by the embodiments of the present application;

[0037] Figure 8 A schematic structural diagram of the computing device provided by the embodiments of the present application;

[0038] Figure 9 A schematic structural diagram of the computing device cluster provided by the embodiments of the present application;

[0039] Figure 10 A schematic diagram of the computer devices in the computer cluster provided by the embodiments of the present application being connected through a network. Detailed implementation manners

[0040] The embodiments of the present application provide a cloud instance management method and a cloud management platform based on a cloud management platform, which actively manage the resources available for deploying cloud instances in physical servers by means of tokens, and can avoid the hot spot problem of physical servers to a certain extent.

[0041] The terms "first", "second", etc. in the specification, claims and above-mentioned drawings of the present application are used to distinguish similar objects, and do not have to be used to describe a specific order or sequence. It should be understood that such terms can be interchanged under appropriate circumstances, which is only a way of distinguishing when describing objects with the same attributes in the embodiments of the present application. In addition, the terms "include" and "have" and any variations thereof are intended to cover non-exclusive inclusion, so that a process, method, system, product or device including a series of units does not have to be limited to those units, but may include other units not clearly listed or inherent to these processes, methods, products or devices.

[0042] With the rapid development of cloud technology, more and more users choose to use cloud service systems to provide cloud services to meet their own business needs. For example, users can use various services such as cloud computing and cloud storage provided by cloud service systems to complete data processing with the help of the cloud, so as to meet their own data processing needs.

[0043] In a cloud service system of related technologies, physical servers can create virtual machines on themselves. These virtual machines usually run users' applications or microservices to provide services to users remotely. Since one or more virtual machines can be deployed on a physical server, and these virtual machines running on the physical server will occupy various resources of the physical server (such as computing resources, storage resources, and communication resources, etc.), when the quantity of various resources used by these virtual machines exceeds the corresponding preset threshold, it will cause a hot spot problem on the physical server, and the operation and maintenance pressure will also increase accordingly. To solve the hot spot problem, usually, the virtual machines on the physical server can be migrated to another physical server, and then this problem can be solved.

[0044] In the above process, although the hot spot problem of the physical server can be solved by migrating virtual machines, this method is often post - placed, that is, when migrating virtual machines, the hot spot problem has already occurred. Therefore, how to prevent the occurrence of hot spot problems has become an urgent problem to be solved.

[0045] Furthermore, during the process of migrating virtual machines, there are often certain risks and costs, which need to bear additional expenses, and even more severe problems such as virtual machine migration failure and virtual machine anomalies during migration exist.

[0046] To solve the above problems, the embodiments of the present application provide a cloud instance management method based on a cloud management platform. This method can be implemented through a cloud service system. Figure 1 The following is a schematic structural diagram of the cloud service system provided by the embodiments of the present application. As Figure 1 shown, the cloud service system includes an infrastructure that can provide cloud services and a cloud management platform that manages these infrastructures. The cloud management platform and the infrastructure will be introduced separately below:

[0047] A cloud management platform can comprehensively manage the infrastructure in the entire cloud service system (for example, among multiple physical servers included in the infrastructure, select a specific physical server for a user and create a user-exclusive cloud instance on the specific physical server so that the cloud instance provides cloud services for the user, etc.), and can also be open to users outside the cloud service system and respond to their requests. For example, the cloud management platform can provide various interfaces such as a login interface, a setting interface, a creation interface, and a display interface for the client of the user (such as the terminal device used by the user or the browser on the terminal device, etc.) to access. Among them, the cloud management platform can authenticate the client of the user through the login interface, and after successful authentication, allow the client of the user to log in to the cloud management platform. For another example, the cloud management platform can also, through the setting interface, allow the client of the user to send a user's token setting request to the cloud management platform, and this token setting request can be used to indicate multiple tokens set by the user for the physical server, and these multiple tokens can be used to indicate multiple sub-available resources of different specifications obtained by dividing the available resources of the physical server. Then, the cloud management platform can allocate at least one of these multiple tokens to each physical server among the multiple physical servers included in the infrastructure based on the token setting request. For another example, the cloud management platform can also, through the creation interface, allow the client of the user to send a user's cloud instance creation request to the cloud management platform, and this request is used to indicate the cloud instance that the user needs to create. Then, the cloud management platform can screen out a certain physical server among the multiple physical servers based on the cloud instance creation request, and this physical server contains tokens that match the load of the cloud instance that the user needs to create. Then, the cloud management platform can create the user's cloud instance on this physical server. For another example, the cloud management platform can also, through the display interface, display to the user a series of contents such as the remaining tokens of multiple physical servers, the combinations formed by these tokens, etc. for the user to use and adjust later.

[0048] The infrastructure includes multiple physical servers, which can be understood as a cluster that can be managed by a cloud management platform. After the cloud management platform selects a physical server from this cluster, it can create cloud instances that provide services for users on this physical server. It should be noted that for a user's cloud instance, the cloud instance can be presented in multiple ways. For example, the cloud instance can be the physical server selected by the cloud management platform. Another example is that the cloud instance can also be a virtual machine (VM) created by the cloud management platform on the physical server through virtualization technology. Another example is that the cloud instance can also be a container (docker) created by the cloud management platform on the physical server through virtualization technology. Another example is that the cloud instance can also be a micro virtual machine (microVM) created by the cloud management platform on the physical server through virtualization technology. Another example is that the cloud instance can also be a container (docker) created by the cloud management platform on the physical server through virtualization technology. Another example is that the cloud instance can also be a bare metal server selected by the cloud management platform, and so on.

[0049] Furthermore, these multiple physical servers can be set in one or more sites, and the sites can be presented in multiple forms. For example, one or more sites can be multiple regions in the infrastructure. Another example is that one or more sites can be multiple availability zones in the infrastructure. Another example is that one or more sites can be at least one edge site and at least one central cloud site in the infrastructure, and so on.

[0050] Based on the above cloud service system, it can be known that at the user's instruction, the cloud management platform can obtain multiple tokens set by the user and allocate at least one token to multiple physical servers according to the current available resources of the multiple physical servers. It should be noted that for any one of the multiple physical servers, the number of tokens allocated by the cloud management platform to this physical server correspondingly indicates the number of specifications of sub-available resources of this physical server. When the cloud management platform allocates a certain number of a certain token to this physical server, it correspondingly indicates that this physical server has a certain number of a certain specification of sub-available resources. Then, when the cloud management platform needs to create a cloud instance for the user, the cloud management platform can first determine the load when the cloud instance runs and determine the token (that is, a certain specification of sub-available resources) that can match this load. Therefore, the cloud management platform can select the physical server with this token from multiple physical servers and create the user's cloud instance on this physical server to meet the user's needs. To further understand this process, the following will be combined with Figure 2 to further introduce this process. Figure 2 This is a schematic diagram of the cloud instance management method based on the cloud management platform provided by the embodiment of this application. As Figure 2As shown, the method can be implemented through a cloud service system such as Figure 1 shown. The cloud management platform includes a cloud management platform and the infrastructure for providing cloud services. The infrastructure includes multiple physical servers. The method includes:

[0051] 201. The cloud management platform receives a token setting request from a user through a setting interface. The token setting request is used to indicate multiple tokens set by the user for multiple physical servers. The multiple tokens are used to indicate multiple sub-available resources of different specifications obtained by dividing the available resources of the physical servers.

[0052] In this embodiment, when the user needs to set tokens for multiple physical servers, the cloud management platform can provide a setting interface (such as a token setting column in the user interface, etc.) to the client used by the user. Therefore, the user can send a user's token setting request to the setting interface through the client, so that the cloud management platform receives the token setting request through the setting interface. It should be noted that the cloud management platform can create a token pool in advance, and based on the available resources of the physical servers (such as available computing resources, available storage resources, available communication resources, etc.), divide the available resources of the physical servers into multiple sub-available resources of different specifications (such as available sub-computing resources, available sub-storage resources, available sub-communication resources, etc.), generate multiple candidate tokens, and then fill the multiple candidate tokens into the token pool. Then, the cloud management platform can provide the token pool to the user through the setting interface for the user to view and select. Then, the user can select multiple tokens for multiple physical servers from the token pool (the number of types of candidate tokens in the token pool is greater than or equal to the number of types of tokens selected by the user). Subsequently, the user can generate a token setting request for indicating these multiple tokens at the setting interface and send it to the cloud management platform through the setting interface. Thus, for the multiple tokens selected by the user indicated by the token setting request, these multiple tokens are used to indicate multiple sub-available resources of different specifications obtained by dividing the available resources of the physical servers.

[0053] For example, assume that the total amount (total specification) of the available central processing unit (CPU) in a physical server is 100%. Based on this, the cloud management platform can set four specifications of available sub-CPUs for the CPU of the physical server. The amount of the sub-CPU of the first specification is 12%, the amount of the sub-CPU of the second specification is 10%, the amount of the sub-CPU of the third specification is 8%, and the amount of the sub-CPU of the fourth specification is 5%. Accordingly, four tokens are generated, namely, A-level token, B-level token, C-level token, and D-level token. Among them, the A-level token is used to indicate 12% of the sub-CPU, the B-level token is used to indicate 10% of the sub-CPU, the C-level token is used to indicate 8% of the sub-CPU, and the D-level token is used to indicate 5% of the sub-CPU. After the cloud management platform provides these four tokens to the user as a token pool, the user can select the A-level token, B-level token, and C-level token from the token pool and generate a token setting request to send to the cloud management platform.

[0054] Specifically, the token setting request can be presented in the following manner:

[0055] The token setting request may include the description information of multiple physical servers (such as the models of multiple physical servers, etc.), the description information of multiple tokens selected by the user (such as the identifiers used to represent these multiple tokens, etc.), the description information of multiple sub-available resources indicated by these multiple tokens (such as the categories to which these multiple sub-available resources belong, etc.), the constraints that these multiple tokens need to satisfy, and the optimization objectives for multiple physical servers affected by these multiple tokens.

[0056] Still as the above example, as Figure 3 shown ( Figure 3 which is a schematic diagram of the user interface provided by the embodiment of the present application), when the user needs to perform token setting for multiple physical servers based on the available resources of multiple physical servers, the cloud management platform can provide a user interface to the user. The user interface includes multiple token setting columns such as a token resource selection column, a token identifier selection column, a host model selection column, a token constraint selection column, and an optimization objective selection column.

[0057] Among them, the token resource selection bar can provide multiple categories of sub-available resources indicated by the token, such as CPU, memory, network bandwidth, etc., for the user to select the category of sub-available resources indicated by the required token. The token identification selection bar can provide multiple identifications of the token, such as circular identification, square identification, etc., for the user to select the identification representing the required token. The host model selection bar can provide multiple models of physical servers for the user to select the model representing the physical server targeted by them. The token constraint selection bar can provide each constraint that the token needs to meet, such as configuring level-X tokens (i.e., the aforementioned token pool, including level-A tokens, level-B tokens, etc.), and the number of level-X tokens on a single physical server not exceeding Y, etc., for the user to select the constraints that the required token needs to meet. The optimization objective selection bar can provide the optimization objectives of the physical servers affected by the token, such as CPU load balance (i.e., the balance degree of CPU usage rates of multiple physical servers), memory load balance (i.e., the balance degree of memory usage rates of multiple physical servers), etc., for the user to select the objectives to be optimized for multiple physical servers.

[0058] Based on this, after the user browses the options provided in each column of the user interface, the user can select various constraints such as "configuring level-A tokens, level-B tokens, and level-C tokens" in the token constraint selection bar, select "CPU" in the token resource selection bar to indicate that level-A tokens, level-B tokens, and level-C tokens indicate different sizes of sub-CPUs, select "circular identification", "square identification", and "triangle identification" in the token identification selection bar to represent level-A tokens, level-B tokens, and level-C tokens respectively, select the model of multiple physical servers targeted by the user in the host model selection bar, and select various optimization objectives for multiple physical servers such as "CPU load balance" in the optimization objective selection bar. In this way, each column of the user interface can, based on these selections of the user, gather and generate a token setting request (this request contains these selections of the user) and send it to the cloud management platform.

[0059] It should be understood that in this embodiment, Figure 3 the example shown only gives a schematic introduction with the user interface including the token constraint selection bar. In practical applications, as Figure 4 shown ( Figure 4 is another schematic diagram of the user interface provided by the embodiment of the present application), the user interface may include a token description bar. The token description bar does not provide the constraints that the token needs to meet, but the user can input a description of the constraints that the selected token needs to meet in the token description bar. These descriptions are usually natural languages. Then, the generated token setting request can include these natural languages. After receiving the token setting request, the cloud management platform can process these natural languages through a large language model to parse out the constraints that the selected token needs to meet.

[0060] 202. The cloud management platform allocates at least one of multiple tokens to multiple physical servers based on the token setting request and the current available resources of the multiple physical servers.

[0061] After receiving the token setting request, the cloud management platform can parse the token setting request to determine that the user needs to allocate multiple tokens selected by the user to multiple physical servers. Then, the cloud management platform can obtain the current available resources of the multiple physical servers (for example, the currently available computing resources, the currently available storage resources, and the currently available communication resources, etc.), and based on the current available resources of the multiple physical servers, allocate at least one of the multiple tokens selected by the user to the multiple physical servers.

[0062] It should be noted that for any one of the multiple physical servers, the cloud management platform allocates at least one of the multiple tokens selected by the user to this physical server. Since the current available resources of this physical server are limited, the quantity of each token among the at least one token allocated to this physical server is also limited. That is to say, the total amount of sub-available resources indicated by all the tokens allocated to this physical server is less than or equal to the total amount of the current available resources of this physical server.

[0063] Still as in the above example, after receiving the token setting request from the user, the cloud management platform can determine that it is necessary to allocate at least one of the A-level tokens, B-level tokens, and C-level tokens to the multiple physical servers. Then, the cloud management platform can determine the currently available CPUs of the multiple physical servers. Suppose the currently available CPU of physical server 1 among the multiple physical servers is 85%. Therefore, the cloud management platform can allocate 5 A-level tokens and 2 B-level tokens to physical server 1, and the sum of the available sub-CPUs indicated by these 7 tokens is 80%.

[0064] Specifically, the cloud management platform can allocate at least one of the multiple tokens selected by the user to the multiple physical servers in the following manner:

[0065] (1) After receiving the token setting request, the cloud management platform can first collect the current loads of the multiple physical servers in real time (which can also be referred to as the current used resources, for example, the currently used computing resources, the currently used storage resources, and the currently used communication resources, etc.), and calculate the current loads of the multiple physical servers to obtain the current available resources of the multiple physical servers.

[0066] Still as in the above example, as Figure 5 shown ( Figure 5It is a schematic structural diagram of the cloud management platform provided by the embodiment of the present application. The cloud management platform may include an interface (such as the various selection bars mentioned above, etc.), a scheduler, a reservator, and a generator. After the interface of the cloud management platform receives a token setting request from a user, the interface may send the token setting request to the generator, so that the generator generates a token allocation policy for multiple physical servers. For the sake of illustration, hereinafter, physical server 1 among multiple physical servers is introduced schematically. For physical server 1, the generator can obtain that the currently used CPU of physical server 1 is 15% from the load dataset. Therefore, the generator can determine that the currently available CPU of physical server 1 is 85% based on the currently used CPU of physical server 1.

[0067] Then, for the remaining physical servers among the multiple physical servers other than physical server 1, the generator can also perform similar operations. Therefore, the generator can finally obtain the currently available CPUs of multiple physical servers.

[0068] (2) Based on the currently available resources of multiple physical servers, the constraints that multiple tokens selected by the user need to satisfy, and the optimization goals for multiple physical servers affected by these multiple tokens, the cloud management platform performs a simulation allocation of multiple physical servers based on these multiple tokens, so as to obtain multiple token allocation policies.

[0069] Still as the above example, after obtaining the currently available CPUs of multiple physical servers, the generator can combine the currently available CPUs of multiple physical servers, the constraints selected by the user extracted from the token configuration request (such as the sum of the sub-CPUs indicated by A-level tokens, B-level tokens, and C-level tokens does not exceed 90% of the CPU upper limit of the physical server, etc.) and the optimization goals (such as when allocating A-level tokens, B-level tokens, and C-level tokens, giving priority to the balance of CPU usage rates among multiple physical servers, etc.), and perform multiple simulation allocations of multiple physical servers based on A-level tokens, B-level tokens, and C-level tokens, so as to obtain multiple token allocation schemes.

[0070] (3) After obtaining multiple token allocation policies, the cloud management platform can obtain the historical load curves of multiple physical servers, and combine the historical load curves of multiple physical servers and the current load of multiple physical servers for prediction, so as to obtain the predicted (future) loads of multiple physical servers. Then, the cloud management platform can find the optimal token allocation policy from multiple token allocation policies based on the predicted loads of multiple physical servers and determine it as the target token allocation policy.

[0071] Still as in the above example, after obtaining multiple token allocation schemes, the generator can send the obtained token allocation schemes to the reservator. The reservator can predict the CPUs that multiple physical servers will use in the future by combining the currently used CPUs of multiple physical servers and the historical CPU usage curves of multiple physical servers. Then, the reservator can use the CPUs that multiple physical servers will use in the future as a reference benchmark to select the optimal token allocation scheme from multiple token allocation schemes. The token allocation scheme includes: allocating 5 A-level tokens and 2 B-level tokens to physical service 1, allocating 3 A-level tokens, 3 B-level tokens and 2 C-level tokens to physical server 2, allocating 7 B-level tokens and 3 C-level tokens to physical server 2, and so on.

[0072] (4) After obtaining the target token allocation policy, the cloud management platform can, according to the instructions of the target token allocation policy, perform actual allocation of multiple tokens to multiple physical servers, so that multiple physical servers have at least one of the multiple tokens selected by the user.

[0073] Still as in the above example, after obtaining the optimal token allocation scheme, the reservator can, according to the optimal token allocation scheme, allocate 5 A-level tokens and 2 B-level tokens to physical service 1, allocate 3 A-level tokens, 3 B-level tokens and 2 C-level tokens to physical server 2, allocate 7 B-level tokens and 3 C-level tokens to physical server 2, and so on. In this way, the reservator successfully completes the actual allocation of tokens to multiple physical servers.

[0074] It should be understood that in this embodiment, the cloud management platform can periodically execute step 202 to continuously update the tokens possessed by multiple physical servers, so as to prepare for subsequent users to create cloud instances on multiple physical servers.

[0075] 203. The cloud management platform determines a target physical server from multiple physical servers and creates a cloud instance of a user in the target physical server. At least one token possessed by the target physical server includes a token that matches the load during the operation of the cloud instance.

[0076] After the cloud management platform completes token allocation for multiple physical servers, when a user needs to create a cloud instance, the cloud management platform can provide a creation interface (such as the cloud instance configuration bar in the user interface, etc.) to the client used by the user. Therefore, the user can send a cloud instance creation request of the user to the creation interface through the client, so that the cloud management platform receives the cloud instance creation request through the creation interface, where the cloud instance creation request is used to indicate the cloud instance that the user needs to create. Then, the cloud management platform can determine the load of the cloud instance that the user needs to create during operation (that is, the resources required by the cloud instance during operation) based on the cloud instance creation request, and determine the token that matches the load. Then, the cloud management platform can select the physical server with the token from multiple physical servers as the target physical server, create the user's cloud instance on the target physical server, and remove the token from the target physical server (equivalent to consuming the token). In this way, the cloud instance created by the cloud management platform on the target physical server can provide cloud services to the user, thus meeting the user's business needs.

[0077] Specifically, the cloud management platform can determine the target physical server in the following way:

[0078] (1) After determining the load of the cloud instance that the user needs to create during operation, the cloud management platform can screen out the target physical server from multiple physical servers according to the loose token filtering policy. That is to say, the cloud management platform can traverse multiple physical servers. If it is found that a certain physical server has a certain token (of course, it can also be several tokens), and the specification (quantity) of the sub-available resources indicated by the token is greater than or equal to the specification of the load of the cloud instance during operation, the cloud management platform directly determines this physical server as the target physical server.

[0079] Still as in the above example, after the interface of the cloud management platform receives the virtual machine creation request sent by the user, it can send the virtual machine creation request to the scheduler. The scheduler can determine that the CPU required for the virtual machine that the user needs to create during operation is 9%. Since the loose token filtering policy is set in the scheduler, the scheduler can determine that the tokens that match the load of the virtual machine during operation are the A-level token and the B-level token. Assuming that only physical server 5 and physical server 6 among multiple physical servers still have the A-level token and the B-level token, the scheduler can randomly determine a physical server from these 2 physical servers, such as physical server 5, create the user's virtual machine on physical server 5, and remove an A-level token or a B-level token from physical server 5.

[0080] (2) After determining the load during the operation of the cloud instance to be created by the user, the cloud management platform can screen out the target physical server from multiple physical servers according to the strict token filtering policy. That is to say, the cloud management platform can traverse multiple physical servers. If it is found that a certain physical server has a certain token, the specification (quantity) of the sub-available resources indicated by the token is greater than or equal to the specification of the load during the operation of the cloud instance, and the difference between the specification of the sub-available resources indicated by the token and the specification of the load during the operation of the cloud instance is within a preset range (the size of this range can be set according to actual needs and is not limited here), the cloud management platform directly determines this physical server as the target physical server.

[0081] Still as in the above example, after the interface of the cloud management platform receives the virtual machine creation request sent by the user, it can send the virtual machine creation request to the scheduler. The scheduler can determine that the CPU required during the operation of the virtual machine to be created by the user is 9%. Since a strict token filtering policy is set in the scheduler, the scheduler can determine that the token matching the operation of the virtual machine is a Class B token. Assume that only physical server 7 among multiple physical servers still has a Class B token. The scheduler can create the user's virtual machine on physical server 7 and remove a Class B token from physical server 7.

[0082] More specifically, the cloud management platform can also show the content related to multiple physical servers to the user in the following ways:

[0083] The cloud management platform sends one or more of the following content to the user's client through the display interface (for example, the operation and maintenance display window of the user interface): the remaining tokens of multiple physical servers, various token combinations included in these remaining tokens and the quantity of each token combination (it can also be understood that it can also be various cloud instance combinations that can still be created on these multiple physical servers (a cloud instance combination usually includes at least two cloud instances, and the loads during the operation of at least two cloud instances are different) and the quantity of each cloud instance combination), the process of the optimization target for multiple physical servers changing over time, the process of determining tokens from the target physical server, the process of removing tokens, etc. Then, the user's client can present this content to the user for viewing and use.

[0084] It should be noted that this content can be presented to the user in different forms. For example, the remaining tokens of multiple physical servers can be presented to the user in the form of a chart, various token combinations included in these remaining tokens and the quantity of each token combination can also be presented to the user in the form of a chart, the process of the optimization target for multiple physical servers changing over time can also be presented to the user in the form of a chart, and the process of determining tokens from the target physical server and the process of removing tokens can be presented to the user in the form of a video.

[0085] For example, as Figure 6 shown ( Figure 6 which is another schematic diagram of the user interface provided by the embodiments of the present application), the cloud management platform can display the remaining tokens of the resource pool (multiple physical servers), the combined distribution of tokens (virtual machines) supported by the resource pool, the change curve of the optimization target over time, and the playback video of the token consumption in the resource pool, etc. on the operation and maintenance display window of the user interface. After the user browses these contents on the operation and maintenance display window, the user can readjust and manage the resource pool and the tokens in the resource pool.

[0086] It should be understood that in this embodiment, when the cloud management platform selects the target physical server, it can either use only the loose token filtering policy or the strict token filtering policy alone, or use the loose token filtering policy and the strict token filtering policy comprehensively. For example, the cloud management platform first selects the target physical server based on the strict token filtering policy. If no target physical server is selected, it then selects the target physical server based on the loose token filtering policy.

[0087] In the embodiments of the present application, when a user needs to set tokens for multiple physical servers, the user can send a token setting request to the cloud management platform through the setting interface provided by the cloud management platform. The token setting request is used to indicate multiple types of tokens set by the user for the multiple physical servers, and these multiple types of tokens are used to indicate multiple sub-available resources of different specifications obtained by partitioning the available resources of the physical servers. Then, based on the token setting request, the cloud management platform can determine that token settings need to be performed for the multiple physical servers. Therefore, the cloud management platform can use the current available resources of the multiple physical servers as a reference benchmark and allocate at least one of these multiple types of tokens to the multiple physical servers. Then, when the user needs to create a cloud instance, the cloud management platform can traverse the multiple physical servers. If a certain physical server has a token that matches the load during the operation of the user's cloud instance, the cloud management platform can determine the physical server as the target physical server and create the user's cloud instance in the target physical server so that these cloud instances can provide cloud services for the user. In the foregoing process, for any one of the multiple physical servers, the cloud management platform can, under the instruction of the user, allocate at least one token to the physical server. These tokens represent how much total resources in the current available resources of the physical server can be used to create cloud instances (related to the total number of these tokens), and these tokens represent how many types of cloud instances the part of the resources of the physical server that can be used to create cloud instances can specifically support (related to the types of these tokens) and how many of each type of cloud instance there are (related to the number of each type of token). Then, when the user needs to create a cloud instance, if there is a token on the physical server that matches the load during the operation of the user's cloud instance, it means that the resources of the physical server are sufficient, and the cloud management platform will create the user's cloud instance on the physical server. If not, it means that the resources of the physical server are insufficient, and the cloud management platform can create the user's cloud instance on the remaining physical servers. Thus, it can be seen that by means of token allocation, the resources in the physical server that can be used to deploy cloud instances are planned in advance, and by means of token application and consumption, the resources in the physical server that can be used to deploy cloud instances are actively managed, which can, to a certain extent, avoid the hotspot problem of the physical server.

[0088] Furthermore, in the embodiments of the present application, by managing the available resources of the physical server based on tokens, there is no need to perform migration of cloud instances, which can avoid the risks and costs existing in the migration process and is beneficial to improving the stability and service quality of the entire cloud service system.

[0089] Even further, in the embodiments of the present application, when the cloud management platform allocates tokens to the physical server, it can comprehensively consider the current load of the physical server and the impact generated by the future load of the physical server, taking into account the long-term load balancing of the physical server, so as to correctly allocate tokens to the physical server and ensure the effective utilization of the resources of the physical server.

[0090] Furthermore, in the embodiments of the present application, the cloud management platform can accurately select a target physical server from multiple physical servers according to the loose token filtering policy and the strict token filtering policy, and create a cloud instance of the user on the target physical server. It can be seen that these policies can ensure that when the resources of the physical server are sufficient, the cloud management platform can successfully respond to the user's cloud instance creation requirement in the way of token application and token consumption.

[0091] Furthermore, in the embodiments of the present application, the cloud management platform can also display the available resource status and the remaining token status of multiple physical servers to the user in real time, avoiding black-box management and helping the user to fine-tune the available resources of multiple physical servers in real time.

[0092] The above is a detailed description of the cloud instance management method based on the cloud management platform provided by the embodiments of the present application. Next, the cloud management platform provided by the embodiments of the present application will be introduced. Figure 7 It is a schematic structural diagram of the cloud management platform provided by the embodiments of the present application, as Figure 7 shown. The cloud management platform is used to manage the infrastructure that provides cloud services. The infrastructure includes multiple physical servers. The cloud management platform includes:

[0093] A receiving module 701, configured to receive a token setting request from a user through a setting interface. The token setting request is used to indicate multiple tokens set by the user for multiple physical servers. The multiple tokens are used to indicate different specifications of multiple sub-available resources obtained by dividing the available resources of the physical server. For example, the receiving module 701 can be used to implement Figure 2 the step 201 in the embodiment shown.

[0094] An allocation module 702, configured to allocate at least one of the multiple tokens to multiple physical servers based on the token setting request and the current available resources of the multiple physical servers. For example, the allocation module 702 can be used to implement Figure 2 the step 202 in the embodiment shown.

[0095] A creation module 703, configured to determine a target physical server from multiple physical servers and create a cloud instance of the user on the target physical server. At least one token of the target physical server includes a token that matches the load during the operation of the cloud instance. For example, the creation module 703 can be used to implement Figure 2 the step 203 in the embodiment shown.

[0096] In a possible implementation manner, the token setting request includes at least one of the following: description information of multiple physical servers, description information of multiple types of tokens, description information of multiple sub-available resources, constraints that multiple types of tokens need to satisfy, and optimization objectives for multiple physical servers affected by multiple types of tokens.

[0097] In a possible implementation manner, the allocation module 702 is configured to: obtain the current loads of multiple physical servers based on the token setting request, and determine the current available resources of the multiple physical servers based on the current loads; perform simulated allocation of multiple physical servers based on multiple types of tokens based on the current available resources, constraints, and optimization objectives to obtain multiple token allocation policies; obtain the predicted loads of the multiple physical servers based on the current loads, and determine a target token allocation policy from the multiple token allocation policies based on the predicted loads; perform actual allocation of multiple physical servers based on multiple types of tokens according to the target token allocation policy, so that at least one of the multiple types of tokens is available on the multiple physical servers.

[0098] In a possible implementation manner, the cloud management platform further includes: a removal module, configured to remove tokens from the target physical servers.

[0099] In a possible implementation manner, the token and the load satisfy any one of the following: the specification of the sub-available resource indicated by the token is greater than or equal to the specification of the load; the specification of the sub-available resource indicated by the token is greater than or equal to the specification of the load, and the difference between the specification of the sub-available resource indicated by the token and the specification of the load is within a preset range.

[0100] In a possible implementation manner, the cloud management platform further includes: a display module, configured to display at least one of the following to the user through a display interface: the remaining tokens on multiple physical servers, the token combinations included in the remaining tokens and the quantity of the combinations, the process of change of the optimization objectives for multiple physical servers over time, the process of determining tokens from the target physical servers, and the process of removing tokens.

[0101] In a possible implementation manner, the cloud instance includes at least one of the following: a physical server, a virtual machine, a container, a micro virtual machine, and a bare metal server.

[0102] It should be noted that for the information interaction, implementation process, etc. among the above-mentioned device modules / units, since they are based on the same concept as the method embodiment of the present application, the technical effects brought by them are the same as those of the method embodiment of the present application. For specific content, reference can be made to the description in the method embodiment shown in the foregoing of the embodiments of the present application, and details are not described herein again.

[0103] Please refer to Figure 8 , Figure 8A schematic structural diagram of a computing device provided by an embodiment of the present application. As Figure 8 shown, the computing device 800 (which can be used to present the aforementioned cloud management platform) includes: a processor 801, a memory 802, a communication interface 803, and a bus 804. The processor 801, the memory 802, and the communication interface 803 are coupled through a bus (not labeled in the figure). The memory 802 stores instructions. When the execution instructions in the memory 802 are executed, the computing device 800 executes the method executed by the cloud management platform in the above method embodiment.

[0104] The computing device 800 can be one or more integrated circuits configured to implement the above method. For example: one or more application specific integrated circuits (ASICs), or one or more digital signal processors (DSPs), or one or more field programmable gate arrays (FPGAs), or a combination of at least two of these integrated circuit forms. Again, when the units in the device can be implemented in the form of a processing element scheduler, the processing element can be a general-purpose processor, such as a central processing unit (CPU) or other processors that can call programs. Again, these units can be integrated together to be implemented in the form of a system-on-a-chip (SOC).

[0105] The processor 801 can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. The general-purpose processor can be a microprocessor or any conventional processor.

[0106] The memory 802 can be a volatile memory, a non-volatile memory, or can include both volatile and non-volatile memories. Among them, the non-volatile memory can be a read-only memory (ROM), a programmable ROM (PROM), an erasable PROM (EPROM), an electrically erasable PROM (EEPROM), or a flash memory. The volatile memory can be a random access memory (RAM), which is used as an external cache. By way of example but not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchlink DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0107] The executable program code is stored in the memory 802, and the processor 801 executes the executable program code to respectively implement the functions of the foregoing receiving module, allocating module, creating module and other modules, so as to implement the cloud instance management method based on the cloud management platform. That is to say, the memory 802 stores instructions for executing the cloud instance management method based on the cloud management platform described above.

[0108] The communication interface 803 uses a transceiver module such as, but not limited to, a network interface card, a transceiver, to implement the communication between the computing device 800 and other devices or communication networks.

[0109] In addition to including a data bus, the bus 804 may further include a power bus, a control bus, a status signal bus, etc. The bus may be a peripheral component interconnect express (PCIe) bus, or an extended industry standard architecture (EISA) bus, a unified bus (Ubus or UB), a compute express link (CXL), a cache coherent interconnect for accelerators (CCIX), etc. The bus may be divided into an address bus, a data bus, a control bus, etc.

[0110] Please refer to Figure 9 , Figure 9 which is a schematic structural diagram of a computing device cluster provided by an embodiment of the present application. As Figure 9 shown, the computing device cluster 900 includes at least one computing device 800.

[0111] As Figure 9 shown, the computing device cluster 900 includes at least one computing device 800. Instructions for executing the above-mentioned cloud instance management method based on a cloud management platform may be stored in the memories 802 of one or more of the computing devices 800 in the computing device cluster 900.

[0112] In some possible implementation manners, partial instructions for executing the above-mentioned cloud instance management method based on a cloud management platform may also be stored separately in the memories 802 of one or more of the computing devices 800 in the computing device cluster 900. In other words, a combination of one or more computing devices 800 may jointly execute the instructions for executing the above-mentioned cloud instance management method based on a cloud management platform.

[0113] It should be noted that the memories 802 in different computing devices 800 in the computing device cluster 900 may store different instructions, which are respectively used to execute partial functions of the above-mentioned cloud management platform. That is, the instructions stored in the memories 802 of different computing devices 800 may implement the functions of one or more of the receiving module, the allocation module, and the creation module.

[0114] In some possible implementation manners, one or more of the computing devices 800 in the computing device cluster 900 may be connected through a network. Among them, the network may be a wide area network or a local area network, etc.

[0115] Please refer to Figure 10 ,Figure 10 This is a schematic diagram showing the network connection of computer devices in a computer cluster provided by an embodiment of the present application. As Figure 10 shown, two computing devices 800A and 800B are connected through a network. Specifically, they are connected to the network through the communication interfaces in each computing device.

[0116] In a possible implementation, the memory in computing device 800A stores instructions for executing functions of modules such as the receiving module, etc. At the same time, the memory in computing device 800B stores instructions for executing functions of modules such as the allocation module and the creation module, etc.

[0117] It should be understood that Figure 10 the functions of computing device 800A shown in

[0118] can also be completed by multiple computing devices. Similarly, the functions of computing device 800B can also be completed by multiple computing devices. Figure 2 An embodiment of the present application also relates to a computer storage medium. The computer-readable storage medium stores a program for signal processing. When it runs on a computer, it causes the computer to execute the steps performed by the cloud management platform in the

[0119] embodiment shown. Figure 2 An embodiment of the present application also relates to a computer program product. The computer program product stores instructions. When the instructions are executed by a computer, it causes the computer to execute the steps performed by the cloud management platform in the

[0120] Those skilled in the art can clearly understand that for the convenience and brevity of description, the specific working processes of the above-described systems, devices, and units can refer to the corresponding processes in the foregoing method embodiments and will not be elaborated herein.

[0121] In several embodiments provided by the present application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point, the displayed or discussed couplings or direct couplings or communication connections to each other can be through some interfaces, and the indirect couplings or communication connections of devices or units can be in electrical, mechanical, or other forms.

[0122] The unit described as a separation component may or may not be physically separated. The component shown as a unit may or may not be a physical unit, that is, it may be located in one place or distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0123] In addition, each functional unit in various embodiments of the present application may be integrated in a processing unit, may exist separately as individual physical units, or two or more units may be integrated in one unit. The above-mentioned integrated units can be implemented in the form of hardware or in the form of software functional units.

[0124] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on such an understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in various embodiments of the present application. The foregoing storage medium includes: various media such as USB flash drives, mobile hard disks, read-only memories (ROM, read-only memory), random access memories (RAM, random access memory), magnetic disks, or optical discs that can store program codes.

Claims

1. A cloud instance management method based on a cloud management platform, characterized in that: The cloud management platform is used to manage an infrastructure for providing cloud services, wherein the infrastructure includes a plurality of physical servers, and the method includes: The cloud management platform receives a token setting request from a user through a setting interface, wherein the token setting request is used to indicate a plurality of tokens set by the user for the plurality of physical servers, and the plurality of tokens are used to indicate a plurality of sub-available resources of different specifications obtained by dividing the available resources of the physical servers; The cloud management platform allocates at least one of the plurality of tokens to the plurality of physical servers based on the token setting request and currently available resources of the plurality of physical servers; The cloud management platform determines a target physical server from the multiple physical servers, and creates a cloud instance of the user in the target physical server, wherein at least one token of the target physical server includes a token that matches the load of the cloud instance during runtime.

2. The method according to claim 1, characterized in that The token setting request includes at least one of the following: description information of the multiple physical servers, description information of the multiple tokens, description information of the multiple sub-available resources, constraints that the multiple tokens need to satisfy, and optimization goals for the multiple physical servers affected by the multiple tokens.

3. The method according to claim 2, characterized in that The cloud management platform allocating at least one of the multiple tokens to the multiple physical servers based on the token setting request and currently available resources of the multiple physical servers includes: The cloud management platform obtains the current loads of the multiple physical servers based on the token setting request, and determines the current available resources of the multiple physical servers based on the current loads; The cloud management platform performs simulated allocation based on the multiple tokens on the multiple physical servers based on the currently available resources, the constraints and the optimization goals to obtain multiple token allocation strategies; The cloud management platform obtains predicted loads of the multiple physical servers based on the current loads, and determines a target token allocation strategy from the multiple token allocation strategies based on the predicted loads; The cloud management platform performs actual allocation of the multiple tokens to the multiple physical servers according to the target token allocation strategy, so that the multiple physical servers have at least one token among the multiple tokens.

4. The method according to any one of claims 1 to 3, characterized in that: The method further comprises: The cloud management platform removes the token from the target physical server.

5. The method according to claim 4, characterized in that The token and the payload satisfy any of the following conditions: The specification of the sub-available resource indicated by the token is greater than or equal to the specification of the load; The specification of the sub-available resource indicated by the token is greater than or equal to the specification of the load, and the difference between the specification of the sub-available resource indicated by the token and the specification of the load is within a preset range.

6. The method according to claim 4 or 5, characterized in that: The method further comprises: The cloud management platform displays at least one of the following to the user through a display interface: the remaining tokens of the multiple physical servers, the token combinations contained in the remaining tokens and the number of the combinations, the process of how the optimization targets for the multiple physical servers change over time, the process of determining the tokens from the target physical servers, and the process of removing the tokens.

7. The method according to any one of claims 1 to 6, characterized in that: The cloud instance includes at least one of the following: a physical server, a virtual machine, a container, a micro virtual machine, and a bare metal server.

8. A cloud management platform, characterized in that: The cloud management platform is used to manage the infrastructure for providing cloud services, the infrastructure includes multiple physical servers, and the cloud management platform includes: A receiving module, configured to receive a token setting request from a user through a setting interface, wherein the token setting request is used to indicate a plurality of tokens set by the user for the plurality of physical servers, wherein the plurality of tokens are used to indicate a plurality of sub-available resources of different specifications obtained by dividing the available resources of the physical servers; an allocation module, configured to allocate at least one of the plurality of tokens to the plurality of physical servers based on the token setting request and currently available resources of the plurality of physical servers; A creation module is used to determine a target physical server from the multiple physical servers and create a cloud instance of the user in the target physical server, wherein at least one token of the target physical server includes a token that matches the load of the cloud instance when it is running.

9. The cloud management platform according to claim 8, characterized in that: The token setting request includes at least one of the following: description information of the multiple physical servers, description information of the multiple tokens, description information of the multiple sub-available resources, constraints that the multiple tokens need to satisfy, and optimization goals for the multiple physical servers affected by the multiple tokens.

10. The cloud management platform according to claim 9, characterized in that: The allocation module is used to: obtaining current loads of the plurality of physical servers based on the token setting request, and determining currently available resources of the plurality of physical servers based on the current loads; Based on the currently available resources, the constraints and the optimization goal, simulate allocation based on the multiple tokens to the multiple physical servers to obtain multiple token allocation strategies; Acquire predicted loads of the plurality of physical servers based on the current loads, and determine a target token allocation strategy from the plurality of token allocation strategies based on the predicted loads; According to the target token allocation strategy, actual allocation based on the multiple tokens is performed on the multiple physical servers so that the multiple physical servers have at least one token among the multiple tokens.

11. The cloud management platform according to any one of claims 8 to 10, characterized in that: The cloud management platform also includes: The removal module is used to remove the token from the target physical server.

12. The cloud management platform according to claim 11, characterized in that: The token and the payload satisfy any of the following conditions: The specification of the sub-available resource indicated by the token is greater than or equal to the specification of the load; The specification of the sub-available resource indicated by the token is greater than or equal to the specification of the load, and the difference between the specification of the sub-available resource indicated by the token and the specification of the load is within a preset range.

13. The cloud management platform according to claim 11 or 12, characterized in that: The cloud management platform also includes: A display module is used to display at least one of the following items to the user through a display interface: the remaining tokens of the multiple physical servers, the token combinations contained in the remaining tokens and the number of the combinations, the process of the optimization goals for the multiple physical servers changing over time, the process of determining the tokens from the target physical servers, and the process of removing the tokens.

14. The cloud management platform according to any one of claims 8 to 13, characterized in that: The cloud instance includes at least one of the following: a physical server, a virtual machine, a container, a micro virtual machine, and a bare metal server.

15. A computing device cluster, characterized in that: The computing device cluster includes at least one computing device, each computing device including a processor and a memory: The memory is used to store instructions; The processor is configured to cause the computing device cluster to execute the method according to any one of claims 1 to 7 according to the instructions.

16. A computer storage medium, characterized in that: The computer storage medium stores one or more instructions, which, when executed by one or more computers, enable the one or more computers to implement the method of any one of claims 1 to 7.

17. A computer program product, characterized in that The computer program product stores instructions, and when the instructions are executed by a computer, the computer implements the method according to any one of claims 1 to 7.

Images