Instance allocation methods, apparatus, terminal devices, and computer-readable storage media

Abstract

This application discloses an instance allocation method, apparatus, terminal device, and computer-readable storage medium. The method includes: acquiring reserved instance data and instance usage data of multiple accounts; determining a first account and a second account among the multiple accounts based on the reserved instance data and instance usage data, wherein the first account is an account with insufficient reserved instances, and the second account is an account with overflowing reserved instances; and generating an instance allocation scheme based on the instance usage data to allocate the overflowing reserved instances of the second account to the first account. Using the method of this application, the reasonable allocation of reserved instances among multiple accounts can be achieved, reducing idle reserved instances and on-demand instance usage, which is beneficial to improving the utilization efficiency of cloud resources and improving the resource allocation effect among multiple accounts.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, specifically to an instance allocation method, apparatus, terminal device, and computer-readable storage medium. Background Technology

[0002] With the development of cloud computing technology, enterprises typically deploy and manage cloud resources through multiple cloud accounts to meet the needs of different business departments, projects, or cost accounting. In cloud resource billing systems, Reserved Instances (RI), as a billing method that offers discounted rates by pre-committing to resource usage for a specified period, are widely used to reduce cloud resource usage costs. In practice, different accounts within the same enterprise often independently purchase and use their respective reserved instances. Due to changes in business load, uneven resource planning, and other reasons, some accounts may have higher instance usage than their reserved instance count, while other accounts' reserved instances may not be fully utilized, resulting in reserved instance overflow. This leads to low reserved instance utilization and an overall need to improve cloud resource efficiency. Summary of the Invention

[0003] This application provides an instance allocation method, apparatus, terminal device, and computer-readable storage medium, which can achieve reasonable allocation of reserved instances among multiple accounts, reduce the idle status of reserved instances and the use of on-demand instances, and help improve the utilization efficiency of cloud resources and improve the resource allocation effect among multiple accounts.

[0004] The technical solution adopted by this invention to solve the problem is as follows: Obtain reserved instance data and instance usage data for multiple accounts; Based on the reserved instance data and instance usage data, the first account and the second account are determined among multiple accounts. The first account is the account with insufficient reserved instances, and the second account is the account with overflowing reserved instances. Based on instance usage data, generate an instance allocation scheme that allocates the reserved instances overflowing from the second account to the first account.

[0005] In some implementation schemes of this application, a first account and a second account are determined from multiple accounts based on reserved instance data and instance usage data, including: Analyze the reserved instance data to determine the utilization rate and coverage of reserved instances for multiple accounts. The coverage rate is the percentage of reserved instances among all instances of the corresponding account. Accounts with a usage rate higher than or equal to the first threshold and a coverage rate lower than the second threshold are identified as the first account; Accounts with usage rates below the third threshold are identified as second accounts.

[0006] In some implementation schemes of this application, an instance allocation scheme is generated based on instance usage data to allocate reserved instances overflowing from the second account to the first account, including: Match the reserved instance of the first account that overflowed with the non-reserved instance of the second account; When there are matching target overflow reserved instances and target non-reserved instances, the target overflow reserved instance is assigned to the first account corresponding to the target non-reserved instance based on the instance usage data, thus obtaining the instance allocation scheme.

[0007] In some implementations of this application, the reserved instance of the first account overflowing and the non-reserved instance of the second account are matched, including: Determine the configuration information of the overflowing reserved instances and the configuration information of the non-reserved instances, wherein the configuration information includes at least one of the following: instance specifications and region; Match the configuration information of the overflowing reserved instances with the configuration information of the non-reserved instances; If matching configuration information exists, determine whether there are matching target overflow reserved instances and target non-reserved instances.

[0008] In some implementation schemes of this application, there are multiple first accounts corresponding to the target non-reserved instances. Based on instance usage data, the target overflow reserved instances are allocated to the first accounts corresponding to the target non-reserved instances to obtain an instance allocation scheme, including: Obtain the business priority of multiple primary accounts corresponding to the target non-reserved instance; Based on instance usage data, determine the instance usage trends of multiple primary accounts corresponding to the target non-reserved instance; Based on business priorities and instance usage trends, select the target primary account from among the multiple primary accounts corresponding to the target non-reserved instance; The target overflow reserved instance is allocated to the target first account to obtain the instance allocation scheme.

[0009] In some implementation schemes of this application, a target primary account is selected from multiple primary accounts corresponding to the target non-reserved instance, based on business priority and instance usage trends, including: Among the multiple first accounts corresponding to the target non-reserved instance, the accounts whose instance usage trend fluctuation value is less than a predetermined threshold are identified as candidate accounts. Among the candidate accounts, the account with the highest business priority is identified as the target primary account.

[0010] In some embodiments of this application, the method further includes: Real-time monitoring of configuration information for multiple account instances; When the configuration information of instances for multiple accounts changes, the steps to obtain reserved instance data and instance usage data for multiple accounts are executed.

[0011] Secondly, embodiments of the present invention also provide an instance allocation device, comprising: The acquisition module is used to acquire reserved instance data and instance usage data for multiple accounts; The determination module is used to determine the first account and the second account among multiple accounts based on the reserved instance data and instance usage data. The first account is the account with insufficient reserved instances, and the second account is the account with overflowing reserved instances. The generation module is used to generate an instance allocation scheme based on instance usage data, which allocates the reserved instances overflowing from the second account to the first account.

[0012] Thirdly, this application also provides a terminal device, which includes: One or more processors; Memory; and One or more applications, wherein the applications are stored in memory and configured to be executed by a processor to implement the instance allocation method of any of the first aspects.

[0013] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, the computer program being loaded by a processor to perform the steps in the instance allocation method of any of the first aspects.

[0014] The beneficial effects of this invention are as follows: By acquiring reserved instance data and instance usage data of multiple accounts, and on this basis, identifying the first account with insufficient reserved instances and the second account with overflowing reserved instances, a comprehensive analysis of the cloud resource usage of multiple accounts is conducted. Based on the instance usage data, an instance allocation scheme is generated to allocate the overflowing reserved instances in the second account to the first account. This allows the originally underutilized reserved instances to be used to cover the instance usage needs of accounts with insufficient reserved instances, thereby improving the overall utilization efficiency of reserved instances and improving the resource allocation effect among multiple accounts. Attached Figure Description

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

[0016] Figure 1 This is a schematic diagram of a scenario for the instance allocation system provided in an embodiment of the present invention; Figure 2 This is a flowchart illustrating one embodiment of the instance allocation method provided in this invention. Figure 3 This is a flowchart illustrating a specific embodiment of managing instances under an account, as provided in this invention. Figure 4 This is a schematic block diagram of the instance allocation device provided in the embodiments of the present invention; Figure 5 This is a schematic diagram of an embodiment of the terminal device provided in this invention. Detailed Implementation

[0017] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0018] In the description of this application, the terms "first," "second," "third," etc., are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined with "first," "second," "third," etc., may explicitly or implicitly include one or more of the stated features.

[0019] In this application, the term "exemplary" is used to mean "used as an example, illustration, or description." Any embodiment described as "exemplary" in this application is not necessarily to be construed as being more preferred or advantageous than other embodiments. The following description is provided to enable any person skilled in the art to make and use this application. Details are set forth in the following description for purposes of explanation. It should be understood that those skilled in the art will recognize that this application can be made without using these specific details. In other instances, well-known structures and processes are not described in detail to avoid obscuring the description of this application with unnecessary detail. Therefore, this application is not intended to be limited to the embodiments shown, but is consistent with the broadest scope of the principles and features disclosed in this application.

[0020] It should be noted that since the method in this application embodiment is executed in a terminal device, the processing objects of each terminal device exist in the form of data or information, such as time, which is essentially time information. It can be understood that if size, quantity, position, etc. are mentioned in subsequent embodiments, they are all corresponding data that exist so that the terminal device can process them. Specific details will not be elaborated here.

[0021] This application provides an instance allocation method, apparatus, terminal device, and computer-readable storage medium, which will be described in detail below.

[0022] Please see Figure 1 , Figure 1 This is a schematic diagram of a scenario for an instance allocation system provided in an embodiment of this application. The instance allocation system may include a terminal device 100, which integrates an instance allocation device, such as... Figure 1 Terminal devices in the process.

[0023] In this embodiment, the terminal device 100 is mainly used to obtain reserved instance data and instance usage data of multiple accounts; based on the reserved instance data and instance usage data, a first account and a second account are determined among the multiple accounts, wherein the first account is the account with insufficient reserved instances, and the second account is the account with overflowing reserved instances; based on the instance usage data, an instance allocation scheme is generated to allocate the overflowing reserved instances of the second account to the first account, which can achieve reasonable allocation of reserved instances among multiple accounts, reduce the situation of idle reserved instances and on-demand instance usage, which is conducive to improving the utilization efficiency of cloud resources and improving the resource allocation effect among multiple accounts.

[0024] In this embodiment, the terminal device 100 can be an independent server, a server network, or a server cluster. For example, the terminal device 100 described in this embodiment includes, but is not limited to, a computer, a network host, a single network server, a set of multiple network servers, or a cloud server composed of multiple servers. The cloud server is composed of a large number of computers or network servers based on cloud computing.

[0025] It is understood that the terminal device 100 used in the embodiments of this application can be a device that includes both receiving and transmitting hardware, that is, a device having receiving and transmitting hardware capable of performing bidirectional communication on a bidirectional communication link. Such a device may include: cellular or other communication devices having a single-line display, a multi-line display, or a cellular or other communication device without a multi-line display. Specifically, the terminal device 100 may be a desktop terminal or a mobile terminal, and the terminal device 100 may also be one of a mobile phone, tablet computer, laptop computer, etc.

[0026] Those skilled in the art will understand that Figure 1 The application environment shown is merely one application scenario of the solution in this application and does not constitute a limitation on the application scenario of the solution in this application. Other application environments may include those that are more specific to this application. Figure 1 The number of more or fewer terminal devices shown, for example Figure 1Only one terminal device is shown in the example. It is understood that the instance allocation system may also include one or more other services, which are not specified here.

[0027] In addition, such as Figure 1 As shown, the instance allocation system may also include a memory 200 for storing data, such as reserved instance data, instance usage data, instance allocation schemes, etc.

[0028] It should be noted that, Figure 1 The schematic diagram of the instance allocation system shown is merely an example. The instance allocation system and scenarios described in this application are intended to more clearly illustrate the technical solutions of this application and do not constitute a limitation on the technical solutions provided in this application. As those skilled in the art will know, with the evolution of instance allocation systems and the emergence of new business scenarios, the technical solutions provided in this application are also applicable to similar technical problems.

[0029] First, this application provides an instance allocation method. The execution subject of the instance allocation method is an instance allocation device, which is applied to a terminal device. The instance allocation method includes: obtaining reserved instance data and instance usage data of multiple accounts; determining a first account and a second account among the multiple accounts based on the reserved instance data and instance usage data, wherein the first account is an account with insufficient reserved instances, and the second account is an account with overflowing reserved instances; and generating an instance allocation scheme based on the instance usage data to allocate the overflowing reserved instances of the second account to the first account.

[0030] like Figure 2 The diagram shown is a flowchart of an embodiment of the instance allocation method in this application. The instance allocation method may include the following steps S201 to S203, as detailed below: Step S201: Obtain the reserved instance data and instance usage data for multiple accounts.

[0031] In this embodiment, multiple accounts are multiple cloud accounts belonging to the same enterprise. Reserved instance data is used to characterize the reserved instance resources already held in each account, and instance usage data is used to characterize the actual usage of cloud instances running in each account.

[0032] This embodiment obtains the reserved instance data and instance usage data of multiple accounts, which can reveal the status of reserved instance resource configuration and actual cloud resource consumption of different accounts, providing a data foundation for subsequent unified analysis across multiple accounts.

[0033] Step S202: Based on the reserved instance data and instance usage data, determine the first account and the second account among multiple accounts. The first account is the account with insufficient reserved instances, and the second account is the account with overflowing reserved instances.

[0034] In this embodiment, insufficient reserved instances refer to an account's reserved instance resources being insufficient to cover its current instance usage needs, while reserved instance overflow refers to an account's reserved instances not being fully utilized and having idle resources. By comparing and analyzing the reserved instance data and instance usage data of multiple accounts, the differences in the supply and demand relationship of reserved instances among different accounts can be identified. This allows for the differentiation between reserved instance demanders and reserved instance suppliers among multiple accounts, clarifying the scope of cross-account resource allocation and providing a basis for generating a reasonable instance allocation scheme in the future.

[0035] Step S203: Based on the instance usage data, generate an instance allocation scheme to allocate the reserved instances overflowing from the second account to the first account.

[0036] In this embodiment, the instance allocation scheme refers to a specific plan for reallocating underutilized reserved instances in the second account to cover the instance usage needs of the first account. By generating an instance allocation scheme based on instance usage data, resources in accounts with overflowing reserved instances can be effectively utilized and used to supplement the resource needs of accounts with insufficient reserved instances. This achieves a reasonable allocation of reserved instances among multiple accounts, improves the overall utilization rate of reserved instances, and enhances the efficiency of cloud resource usage across multiple accounts.

[0037] In one specific implementation, based on reserved instance data and instance usage data, a first account and a second account are determined among multiple accounts. This includes: analyzing the reserved instance data to determine the usage rate and coverage rate of reserved instances for multiple accounts, where the coverage rate is the proportion of reserved instances in all instances of the corresponding account; determining the account with a usage rate higher than or equal to a first threshold and a coverage rate lower than a second threshold as the first account; and determining the account with a usage rate lower than a third threshold as the second account.

[0038] In this embodiment, the reserved instance data is first analyzed to determine the reserved instance utilization rate and coverage rate for each of the multiple accounts. The reserved instance utilization rate refers to the proportion of reserved instances in an account that have been actually used and consumed by actual instances out of the total reserved instances in that account, reflecting whether the reserved instances are being fully utilized; the coverage rate refers to the proportion of reserved instances in all instances of the corresponding account, reflecting the degree to which the instance usage needs of that account are covered by reserved instances.

[0039] After obtaining the reserved instance utilization and coverage for each account, accounts with a utilization rate higher than or equal to the first threshold and a coverage rate lower than the second threshold are identified as the first type of account. This means that while the reserved instances for these accounts are fully utilized, their proportion within the overall instance pool is low, failing to effectively cover their actual instance usage needs, reflecting insufficient reserved instance resources. Simultaneously, accounts with a utilization rate lower than the third threshold are identified as the second type of account. The reserved instances for these accounts are not fully utilized, exhibiting idle or overflowing reserved instance resources. By assessing the reserved instance utilization rate, accounts with underutilized reserved instance resources can be identified, thus identifying them as potential reserved instance suppliers. The first and third thresholds can be 100%, the second threshold can be 50%, or other values ​​set according to actual needs.

[0040] By using the above method, the first and second accounts are determined among multiple accounts based on the reserved instance utilization and coverage, enabling the system to accurately distinguish between the demanders and suppliers of reserved instance resources, and providing a logical basis for subsequent reallocation of reserved instances among accounts.

[0041] In one specific implementation, an instance allocation scheme is generated based on instance usage data to allocate the reserved instance overflowing from the second account to the first account. This includes: matching the reserved instance overflowing from the first account with the non-reserved instance of the second account; and when there are matching target overflow reserved instances and target non-reserved instances, allocating the target overflow reserved instance to the first account corresponding to the target non-reserved instance based on instance usage data to obtain the instance allocation scheme.

[0042] In this embodiment, the overflowing reserved instances of the first account and the non-reserved instances of the second account are first matched. Overflowing reserved instances refer to reserved instance resources that have been purchased but not yet consumed by instances and are in an allocable state; non-reserved instances refer to instances that are not covered by reserved instances and are running using other billing methods. Matching refers to determining the correspondence between reserved instances and non-reserved instances based on instance usage data to determine whether they meet the basic conditions for allocability. After matching is completed, when a target overflowing reserved instance and a target non-reserved instance exist, the target overflowing reserved instance is allocated to the first account corresponding to the target non-reserved instance according to the instance usage data, thus obtaining the instance allocation scheme.

[0043] In one specific implementation, the process of matching the overflowing reserved instance of the first account with the non-reserved instance of the second account includes: determining the configuration information of the overflowing reserved instance and the configuration information of the non-reserved instance, wherein the configuration information includes at least one of the following: instance specifications and the region in which it is located; matching the configuration information of the overflowing reserved instance and the configuration information of the non-reserved instance; and when matching configuration information exists, determining that there are matching target overflowing reserved instance and target non-reserved instance.

[0044] In this embodiment, the overflow of reserved instances from the first account and the non-reserved instances from the second account are matched. To determine whether the overflowing reserved instances can cover the usage requirements of the non-reserved instances, the configuration conditions of the two need to be compared. Therefore, the configuration information of the overflowing reserved instances and the configuration information of the non-reserved instances are first determined. The configuration information describes the resource attributes of the instance in the cloud platform, including at least one of the instance specifications and the region it is located in. The instance specifications characterize the type of computing resources corresponding to the instance, and the region characterizes the geographical or logical location of the instance deployment.

[0045] After obtaining the configuration information of the overflowing reserved and non-reserved instances, their configuration information is matched to determine whether the overflowing reserved instances meet the configuration requirements of the non-reserved instances. Target overflow reserved instances and target non-reserved instances refer to instance resources whose configuration information is mutually compatible and have the basis for allocation. When matching configuration information exists, it is determined that there are matching target overflow reserved instances and target non-reserved instances. By matching the configuration information, instance resources that are mutually compatible in configuration conditions can be filtered out, thereby avoiding the allocation of unsuitable reserved instances to non-reserved instances and ensuring the feasibility of subsequent allocation.

[0046] In one specific implementation, there are multiple first accounts corresponding to the target non-reserved instances. Based on instance usage data, the target overflow reserved instances are allocated to the first accounts corresponding to the target non-reserved instances to obtain an instance allocation scheme. This includes: obtaining the business priorities of the multiple first accounts corresponding to the target non-reserved instances; determining the instance usage trends of the multiple first accounts corresponding to the target non-reserved instances based on the instance usage data; selecting a target first account from the multiple first accounts corresponding to the target non-reserved instances based on the business priorities and instance usage trends; and allocating the target overflow reserved instances to the target first accounts to obtain the instance allocation scheme.

[0047] In this embodiment, there are multiple first accounts corresponding to the target non-reserved instance. This means that there are multiple accounts with insufficient reserved instances, and these accounts all have non-reserved instances that match the target overflow reserved instance. Therefore, it is necessary to further determine the account that will ultimately receive the reserved instance from among the multiple first accounts. In this case, the business priority of the multiple first accounts corresponding to the target non-reserved instance can be obtained. The business priority is used to characterize the importance of the business carried by different accounts or the resource guarantee level. As a reference factor for resource allocation decisions, it helps to distinguish different accounts when resources are limited. By introducing business priority, indiscriminate allocation among multiple candidate accounts can be avoided, thus making instance allocation more in line with actual business needs.

[0048] Furthermore, based on instance usage data, the instance usage trends of multiple primary accounts corresponding to the target non-reserved instance can be determined. Instance usage trends characterize how instance usage in an account changes over time, reflecting the stability or variability of instance usage. By analyzing instance usage trends, the continued demand for instance resources from different accounts over a future period can be determined, thus providing a dynamic basis for allocation decisions.

[0049] After obtaining business priorities and instance usage trends, a target primary account is selected from multiple primary accounts corresponding to the target non-reserved instance, based on these priorities and trends. Finally, the target overflow reserved instances are allocated to the selected target primary account, resulting in an instance allocation scheme. Through these steps, the recipients of reserved instances can be reasonably determined among multiple accounts with insufficient reserved instances, ensuring effective utilization of overflowing reserved instance resources while considering business needs and instance usage characteristics, thereby improving the rationality of reserved instance reallocation and overall cloud resource utilization efficiency.

[0050] In one specific implementation, based on business priority and instance usage trends, a target first account is selected from multiple first accounts corresponding to the target non-reserved instance. This includes: among the multiple first accounts corresponding to the target non-reserved instance, determining the account whose instance usage trend fluctuation value is less than a predetermined threshold as a candidate account; and among the candidate accounts, determining the account with the highest business priority as the target first account.

[0051] In this embodiment, the instance usage trend refers to the characteristics of instance usage in the first account over time, reflecting the stability of instance usage; the fluctuation value is an indicator used to quantify the magnitude of changes in the instance usage trend, and its value reflects the drasticness of the changes in instance usage; the predetermined threshold is a reference standard for judging whether the instance usage trend is stable. By analyzing the instance usage trend and its fluctuation value, accounts with relatively stable instance usage can be identified among multiple first accounts.

[0052] Specifically, among the multiple primary accounts corresponding to the target non-reserved instance, accounts whose instance usage fluctuation value is less than a predetermined threshold are first identified as candidate accounts. By analyzing the instance usage data, the instance usage changes of different accounts are compared and filtered to exclude accounts with large instance usage changes. This ensures that the reserved instances allocated subsequently can be assigned to accounts with relatively stable instance usage, reducing the possibility of decreased resource utilization efficiency due to instance usage changes after the reserved instances are allocated.

[0053] After obtaining candidate accounts, the account with the highest business priority is further identified as the target primary account. Business priority is used to characterize the importance of the business carried by different accounts. By introducing business priority into the filtering of accounts with stable instance usage, the stability of resource usage can be ensured while prioritizing the allocation of reserved instances to accounts with higher business importance.

[0054] By following the steps above, we can determine the primary account to receive the overflow of reserved instances from multiple accounts with insufficient reserved instances, taking into account both instance usage stability and business importance. This improves the rationality and reliability of reserved instance reallocation decisions and promotes the efficient utilization of cloud resources.

[0055] In one specific implementation, the method further includes: real-time detection of the configuration information of multiple account instances; and when the configuration information of multiple account instances changes, performing the steps of obtaining the reserved instance data and instance usage data of multiple accounts.

[0056] In this embodiment, the configuration information of instances across multiple accounts can also be monitored in real time. This configuration information refers to data characterizing instance resource attributes and reflecting the current resource configuration status of the instance. By monitoring the instance configuration information across multiple accounts in real time, changes in instance configurations can be detected promptly, thereby allowing for an understanding of the dynamic status of cloud resources during actual operation.

[0057] When changes are detected in the configuration information of instances for multiple accounts, the procedure for retrieving reserved instance data and instance usage data for these accounts is executed. Changes in instance configuration information refer to adjustments to the instance's resource attributes relative to its original state, which may affect the applicability of reserved instances and instance usage. By retrieving reserved instance data and instance usage data for multiple accounts when configuration information changes, it ensures that the data used for subsequent analysis remains consistent with the current instance operating status.

[0058] Through the above steps, when the instance configurations of multiple accounts change, the system can promptly trigger the data acquisition process, avoiding analysis and allocation decisions based on expired data. This improves the real-time performance and accuracy of the reserved instance reallocation process, making the generated instance allocation scheme more in line with the actual usage of current cloud resources.

[0059] In one specific implementation, the method further includes: reading the instance's tags to determine the instance's attributes. These attributes distinguish whether the instance is an on-demand instance (i.e., an instance purchased based on recent usage needs) or a reserved instance. An on-demand instance can be understood as the non-reserved instance mentioned earlier. Tags can be added to all instances to indicate their attributes. If an instance has no tag, it is determined to be a newly created instance. If the tag is RI-Buy, it is determined to be a reserved instance. The tag can also specify the RI order associated with the instance, supporting multiple order concatenation. If the tag is SP, it is determined to be an instance purchased with SP. If the tag is OnDemand, it is determined to be an on-demand instance. If the tag is RI-Inherit, it is determined to be a reserved instance inherited or transferred.

[0060] In one specific implementation, before reading the instance's tags, the method further includes: obtaining order information, establishing a relationship between instances and orders based on the order information, determining the instance's attributes, and adding corresponding tags to the instance. Specifically, firstly, the order information of all current instances is exported; then, instances are matched according to the account, region, and specifications of the RI order; the existing RI usage and coverage baseline is obtained, and overflow detection analysis is performed to identify whether the RI can be reallocated; historical monitoring data is analyzed using AI to identify the actual usage pattern of instances, and based on this, the optimal order-instance matching strategy is intelligently recommended; tags are applied starting from the earliest purchased machine according to the purchase date, and orders and instances that match perfectly are directly tagged accordingly; for orders and instances that do not match perfectly, the instance specifications are recalculated, and instances with smaller specifications are merged and tagged with the larger order's tag; AI identifies tag allocation anomalies and provides intelligent repair suggestions; finally, an AI analysis and tagging report with anomaly handling suggestions is generated.

[0061] In one specific implementation, the method further includes: collecting all instance information and filtering out new instances without tags; using AI to analyze historical usage data, combined with RI usage and coverage data, to identify resource usage patterns and detect RI overflow; based on usage patterns, cost data, and business context, intelligently recommending the optimal instance specifications and generating a new RI purchase confirmation list that includes specification optimization solutions and overflow analysis results; and automatically tagging instances after RI purchase to establish association relationships.

[0062] Specifically, the process begins by comprehensively collecting information on all compute instances, including instance type, configuration specifications, runtime, and resource consumption. A tag filtering mechanism then precisely identifies new, untagged instances not associated with any RI (Integrated Resource Provider) orders. Historical usage data is then input into an AI analysis model. This model mines the resource consumption patterns of instances, identifying, for example, instances exhibiting periodic peaks or prolonged periods of low load. It also combines this with current RI usage and coverage data to cross-validate the rationality of resource allocation, detecting RI overflow (where some RIs cannot effectively utilize remaining resources due to specification mismatch) or coverage gaps (where high-frequency usage instances are not covered by RIs). Based on these analysis results, the most economical instance specifications are matched according to the actual usage patterns of the instances (such as CPU / memory fluctuations), for example, downgrading long-term low-load instances to more cost-effective ones. The system recommends elastic scaling solutions for instances with periodic peak demand, while integrating cost data (such as the price difference between on-demand instances and RIs, and the procurement cost of RIs of different specifications) and business context (such as the business department to which the instance belongs and service level agreement requirements). Through a multi-objective optimization algorithm, it generates the optimal specification combination and finally outputs a new RI purchase confirmation list containing two core contents: first, the specification optimization plan, which clarifies which instances need to have their specifications adjusted and the specific configuration after the adjustment; second, the overflow analysis results, which mark the redundant RI resources that can be released and the coverage gaps that can be reallocated. When users complete the RI purchase according to the list, the system automatically performs a tag binding operation to establish a relationship between the newly purchased RI and the corresponding instance, ensuring the traceability and compliance of resource allocation. This avoids the efficiency bottleneck and subjective bias of manual analysis and achieves continuous improvement in resource utilization and cost control through a dynamic optimization mechanism.

[0063] In one specific implementation, the method further includes: identifying RI orders nearing their expiration date and analyzing the current specifications and usage status of their associated instances; using AI to perform in-depth analysis of monitoring data over a period of time (e.g., 30-90 days) to assess the fluctuation trend of actual resource utilization and obtain historical usage and coverage change patterns; detecting existing RI resource redundancy through overflow analysis and intelligently recommending renewal plans based on usage pattern predictions and cost data; providing differentiated renewal optimization suggestions for instances with different tag types (e.g., on-demand to reserved, inherited orders, etc.) and fully considering instance configuration history and overflow redistribution possibilities; and finally generating a renewal confirmation list that includes AI analysis conclusions, cost data, and overflow assessment.

[0064] Specifically, firstly, RI order information nearing expiration (e.g., within 30 days) is extracted, and the current specifications (e.g., CPU core count, memory capacity) and running status (e.g., active / idle) of their associated instances are simultaneously obtained to provide basic data support for subsequent analysis. Then, monitoring data from the past 30-90 days (including key indicators such as CPU utilization, memory usage, and network traffic) is retrieved. An AI-driven time-series analysis model is used to uncover dynamic patterns in resource consumption, such as identifying periodic peaks (e.g., high load at specific times of the day) or long-term low-load (e.g., idle at night) usage patterns, while also considering historical usage and coverage trends. After completing the usage model... After the formal analysis, the system enters the overflow detection phase. By comparing the current RI specifications with the actual needs of the instances, it identifies RI overflow or time overflow (i.e., the time period covered by the RI does not match the active time of the instances (e.g., all-day RI is reserved but the instances only run during the day)). Simultaneously, it combines cost data (e.g., the unit time price difference between on-demand instances and RI, and the procurement cost differences of different RI specifications) to assess the economic impact of redundant resources. Based on the above analysis results, the AI ​​model predicts future resource needs based on the historical usage patterns of instances (e.g., considering business growth or seasonal fluctuations), and combines current RI market price fluctuations (e.g., supplier promotional activities) and instance configuration history (e.g., past...). The system analyzes whether the specifications are frequently adjusted and generates multiple renewal combination plans. For example, it recommends splitting some large RIs into multiple smaller RIs to cover scattered small instances, or suggests shortening the RI renewal duration for low-load instances to reduce long-term lock-in costs. For instances with different tag types, the system provides differentiated optimization strategies: for instances that are "converted from on-demand to reserved" (i.e., switching from an on-demand payment model to an RI reservation model), the system focuses on evaluating the cost-saving potential and resource adaptability after the conversion; for instances with "inherited orders" (such as inheriting RIs from other teams due to business adjustments), the system analyzes their matching degree with the original order and the possibility of reallocation, for example, suggesting transferring redundant RIs to other teams or adjusting... The system comprehensively covers all aspects of resource utilization. Ultimately, it integrates AI analysis conclusions (such as resource utilization trend predictions and overflow risk levels), cost data (such as a comparison of the total cost of renewing different specifications / durations), and overflow assessment results (such as the amount of redundant resources that can be released) to generate a structured renewal confirmation list. The list not only includes the recommended renewal specifications, duration, and price for each RI, but also indicates the basis for renewal (such as "Because the average CPU utilization of instance A in the past 90 days is only 30%, it is recommended to renew the lower-spec specification to save 40% of the cost") and risk warnings (such as "There may be a 15% specification overflow after renewal, it is recommended to monitor instance configuration change requirements simultaneously"). This provides decision-makers with transparent and traceable intelligent support.

[0065] In one specific implementation, the method further includes: capturing instance configuration change events in real time, using AI to compare monitoring data before and after the configuration change, and evaluating the rationality of the specification adjustment; simultaneously analyzing the changing trends of utilization and coverage, and identifying RI resource redundancy or insufficiency in combination with overflow detection; predicting resource requirements after configuration change based on historical usage patterns and cost data, and automatically adjusting tags and coverage relationships for different configuration change types (upgrading or downgrading within the same family, or changing across families): upgrading within the same family triggers a supplementary RI purchase suggestion, downgrading within the same family generates a redistribution plan (i.e., the instance allocation plan mentioned above), and changing across families initiates a replanning process; AI comprehensively considers cost and resource utilization, intelligently recommends the optimal processing strategy and triggers an alarm mechanism, and finally updates coverage and utilization metrics to form a closed-loop optimization.

[0066] Specifically, the system can capture instance specification change events (such as increases in CPU core count, adjustments to memory capacity, etc.) in real time and simultaneously acquire key monitoring data before and after the configuration change (including CPU utilization, memory usage, network traffic, etc.). AI algorithms are used to compare and analyze the two sets of data to assess the rationality of the configuration adjustment—for example, if the CPU utilization of an instance remains below 30% after an upgrade, it is considered over-configured; if the memory usage frequently reaches the 95% threshold after a downgrade, it indicates a risk of insufficient configuration. Simultaneously, the system analyzes the impact of the configuration change on overall resource utilization, calculating the trend of RI utilization and coverage changes after the configuration change, and using overflow detection algorithms to identify resource redundancy and resource gaps. Based on the above analysis results, combined with the instance's historical usage patterns and cost data, the system predicts the evolution trend of resource demand after the configuration change—for example, if an instance is frequently upgraded due to business growth, it is predicted that it may need further expansion in the next 3 months. For different configuration change types, the system adopts differentiated processing strategies: for upgrades within the same family, if the remaining amount of the original RI specification is detected to exceed the safety threshold, a suggestion to purchase additional RI is triggered to avoid resource waste; for downgrades within the same family, if the new specification can still cover other unused RIs, a different strategy is adopted. For instances requiring reserved space, a redistribution plan is generated to transfer redundant RIs to high-priority instances. For cross-family changes, a replanning process is initiated to reassess the resource pool's specification distribution and coverage. In the strategy recommendation phase, the AI ​​model considers cost-saving potential, resource utilization improvement space, and business impact factors to generate the optimal processing strategy. For example, it might recommend splitting some redundant RIs into smaller specifications to cover more low-load instances, or suggest replacing high-cost RIs with newer, more cost-effective specifications. Simultaneously, the system triggers a tiered alert mechanism based on risk level—for instances that may cause business interruptions... For severe underconfiguration (e.g., memory overflow risk exceeding 80%), an emergency alert is immediately pushed out and a rollback and reconfiguration recommendation is made; for mild resource redundancy (e.g., remaining resources below 10%), an optimization prompt is sent and pending tasks are recorded; finally, the decision results are automatically executed, updating the tag association between instances and RIs (e.g., migrating the reassigned RI tags from the original instance to the new instance), refreshing the coverage and utilization metrics of the resource pool (e.g., including the repurchased RIs in the allocated resource statistics), and recording the optimization effect of this reconfiguration (e.g., cost savings, utilization improvement percentage points), and optimizing the resource allocation strategy.

[0067] In one specific implementation, the method further includes: identifying EKS nodes (Elastic Kubernetes Service) and marking them as Savings Plan (SP) types; using AI to analyze the cluster's scaling up / down patterns and resource usage trends, and simultaneously obtaining SP utilization and coverage baselines; analyzing SP utilization efficiency through overflow detection combined with cost data, and predicting future SP demand based on Kubernetes workload characteristics to dynamically calculate coverage gaps; monitoring coverage change trends in real time, and using AI to intelligently recommend SP replenishment timing and quantity based on business periodic characteristics and cost data; and supporting overflow resource reallocation strategies for hybrid RI / SP environments to ensure a dynamic balance between reserved resources and on-demand resources, ultimately forming a closed-loop management of coverage prediction, replenishment recommendations, and resource scheduling.

[0068] Specifically, firstly, all EKS nodes are accurately identified from the cloud resource monitoring platform, and then marked as SP types based on the node's configured tags or resource attributes (such as instance type, region, availability zone). Simultaneously, the cluster's scaling history (such as the time and scale of automatic scaling via HPA, and changes in the number of manually adjusted nodes) and resource usage trend data (including real-time CPU / memory utilization, network traffic, and the deviation between Pod resource requests and actual consumption) are collected. This data is then combined with the current SP utilization rate (the ratio of allocated SP resources to total committed SP resources) and coverage rate (the percentage of EKS nodes covered by SPs out of the total number of nodes). A baseline model is constructed using a ratio to provide a quantitative reference for subsequent analysis. Then, the system proceeds to the overflow detection and cost analysis phase. By comparing the SP's committed resources with the actual needs of the EKS cluster, the system identifies two types of resource mismatch scenarios: first, resource overflow (the SP's committed resources significantly exceed the cluster's average demand, for example, the SP covers idle nodes during low-load periods at night); second, coverage gaps (the SP does not cover expansion nodes during peak business periods, resulting in some nodes being billed on demand). Simultaneously, combined with cost data (such as the hourly committed cost of the SP and the unit time price difference of on-demand instances, and the procurement cost differences of different SP specifications), the system calculates the wasted amount of overflow resources and the cost gaps. The additional costs caused by the above analysis results; based on the above analysis results, the system uses an AI model to predict future SP demand. Its core logic is to integrate the periodic characteristics of Kubernetes workloads (such as the daily order peak of e-commerce business from 10-12 o'clock, and the nighttime batch processing of AI training tasks) with resource consumption patterns (such as the fixed ratio of resource requests of certain Pods), and generate a cluster size prediction curve for the next 24-72 hours through a time-series prediction algorithm, and dynamically calculate the coverage gap; in the decision recommendation stage, the system combines the periodic characteristics of business (such as the decrease in load on weekends and the load fluctuation on the end-of-month settlement day) with cost data (such as SP) The system provides intelligent recommendations on the timing and quantity of SP replenishment for bulk purchases. For hybrid RI / SP environments, the system supports an overflow resource reallocation strategy. When it detects that SP for a certain type of resource (such as GPU nodes) is overflowing while RI coverage is insufficient, the system automatically adjusts the resource allocation relationship through tag matching and resource affinity analysis (such as prioritizing the allocation of idle GPU nodes covered by SP to Pods that need GPUs but are not covered by RI). This ensures a dynamic balance between reserved resources (RI+SP) and on-demand resources. For example, idle CPU nodes covered by SP can be temporarily allocated to short-term computing tasks not covered by RI, and the resources can be automatically released after the task is completed.Ultimately, the system forms a complete closed loop of coverage prediction, replenishment recommendations, and resource scheduling: on the one hand, it pushes the AI-generated replenishment list (including recommended SP specifications, quantities, durations, and expected cost savings) to the approval process; on the other hand, it automatically executes resource reallocation strategies (such as updating resource tags via Kubernetes Descriptor or adjusting resource labels via cloud service provider APIs), and updates coverage and utilization metrics after the operation is completed (such as including newly replenished SPs in the allocated resource statistics and removing reallocated nodes from the original SP coverage list). Simultaneously, it records the effectiveness data of this optimization, providing feedback for subsequent iterations and continuously optimizing resource allocation strategies.

[0069] In one specific implementation, the method further includes: calculating the utilization and coverage of RI; then obtaining official utilization and coverage statistics from the cloud computing platform as a benchmark for comparison, performing overflow detection analysis, and identifying RI overflow situations and reallocation opportunities; further utilizing AI to analyze instance usage data, identifying anomalies and trend changes in resource usage, and providing forward-looking optimization suggestions based on usage pattern predictions and instance usage data; in addition, AI intelligently assesses alarm priorities, reduces interference from invalid alarms, and automatically triggers alarms for coverage, utilization, and missing tags (an alarm is triggered when the utilization is below 100%); and continuously monitors and updates data to ensure the real-time nature and accuracy of monitoring.

[0070] As a specific implementation method, such as Figure 3 As shown, this embodiment proposes a Reserved Instance (RI) management system, which can realize the reallocation of Reserved Instances (RI) among multiple accounts belonging to the same enterprise, as well as the purchase of new RIs, renewal of RIs, purchase of Savings Plans (SPs), and adjustment of instance configurations.

[0071] After the management system starts, it first enters the data collection phase. The system collects various types of data from multiple cloud service instances of the enterprise, including RI / SP order data and multi-service instance data, providing basic information for subsequent processes. Then, the collected data undergoes multi-dimensional analysis: the number of RI orders is counted to calculate RI utilization and coverage. If conditions are set, such as utilization falling below 100% or coverage falling below 80%, corresponding alarm mechanisms are triggered. It can also analyze Prometheus monitoring data using AI to identify resource usage anomalies and trends, and perform AI predictive analysis, providing optimization suggestions based on monitoring data, and finally generating intelligent alarm notifications. After the inspection results are recorded, they are used to update dashboard data, generate a new RI purchase confirmation list and RI overflow analysis results, awaiting the next inspection.

[0072] The RI (Instant Provider) new purchase process is initiated based on inspection results or other triggering conditions. The system generates RI new purchase suggestions based on AI-recommended optimal instance specifications, combined with monitoring data and business context. After cost-benefit analysis, a purchase confirmation list is output. The RI purchase operation is executed after administrator confirmation or modification. Upon completion of the purchase, a new RI order ID is obtained, tags are automatically associated and updated for the instance, and the initial RI planning is completed after verifying tag integrity.

[0073] The RI renewal process is triggered by a scheduled inspection task. The system scans for RIs that are about to expire, filters orders expiring within 30 days, and finds associated instances based on the order ID. The system obtains the historical usage coverage of the RI, and AI analyzes monitoring data to assess the actual resource utilization. It performs overflow analysis to detect whether there is overflow in the current RI, recommends renewal specifications through AI, conducts cost-benefit comparison analysis, generates a renewal confirmation list, and executes the RI renewal after administrator confirmation. Historical matching relationships are recorded in the database, and tags are updated to complete the renewal.

[0074] The SP (Service Provider) purchase process includes obtaining SP usage coverage, AI analysis of EKS cluster scaling patterns to predict SP demand, SP overflow detection and data analysis of SP usage efficiency, calculation of SP demand according to specifications, acquisition of the current SP purchase amount for the account, and calculation of SP coverage and SP usage. Through coverage checks, if the coverage is below a threshold, it is recorded as insufficient coverage. Based on the judgment of N consecutive days below the threshold, AI intelligently recommends SP replenishment. After considering data overflow analysis and cost-benefit analysis, a replenishment suggestion list is output. After administrator processing, an SP management report is generated, which is triggered periodically under cluster scaling events or awaits the next check.

[0075] The instance reconfiguration process is initiated when the system detects a specification change. It integrates Cost Explorer data to obtain utilization and coverage rates before and after the reconfiguration. AI analyzes monitoring data before and after the reconfiguration to evaluate the rationality of the reconfiguration, performs overflow detection and analysis to determine RI overflow, obtains the specifications before and after the reconfiguration, and determines the reconfiguration type. For same-family upgrades, it sends coverage drop alarms and searches for suitable instances. If found, it transfers the original RI label to the suitable instance and purchases a new RI according to the upgrade specifications. For same-family downgrades, it checks for RI overflow; if overflow is found, it sends utilization alarms, and AI recommends overflow RI reallocation schemes. For cross-family reconfigurations, it checks for original RI overflow; if no overflow record is found, it matches historical relationships in the database, transfers the original RI label to an instance of the same specification, and purchases a new RI according to the new specifications. Finally, it updates coverage and utilization metrics and records the reconfiguration processing results.

[0076] The reallocation process, a crucial part of the overall solution, involves the system collecting cross-account data in a multi-account environment. This includes RI (Individual Provider) orders and instance data for each account, grouped by Payer account, region, and specification. It obtains the usage coverage for each account, uses AI to analyze usage patterns, identifies optimal RI sharing strategies, and performs cross-account overflow detection to identify sharing opportunities. The system calculates RI usage for each account, identifies accounts with overflowing and insufficient RI, matches instances based on instance specifications and regions, and uses AI to intelligently match overflowing RIs. Based on the matching results, different reallocation schemes are generated: a complete match generates a cross-account allocation scheme, a partial match generates a partial allocation and repurchase scheme, and no match generates a new RI purchase scheme. After calculating the cost optimization effect, a reallocation suggestion list is generated. After administrator confirmation, tag-based reallocation is executed, updating source and target account instance tags. After verifying the tag updates, coverage is recalculated, cross-account usage statistics are updated, and cross-account optimization is completed. Furthermore, the reallocation step can be executed periodically or automatically when instance specifications change.

[0077] This systematic solution achieves comprehensive management and optimization of enterprise cloud resources through the organic integration and intelligent collaboration of various processes. From daily inspection and monitoring of resources to resource procurement, renewal, reconfiguration, and redistribution among accounts, it forms a closed-loop management system, effectively improving resource utilization efficiency and reducing enterprise costs.

[0078] To better implement the instance allocation method in the embodiments of this application, based on the instance allocation method, the embodiments of this application also provide an instance allocation device, such as... Figure 4 As shown, the instance allocation device 400 includes: Module 410 is used to obtain reserved instance data and instance usage data for multiple accounts; The determination module 420 is used to determine the first account and the second account among multiple accounts based on the reserved instance data and instance usage data. The first account is the account with insufficient reserved instances, and the second account is the account with overflowing reserved instances. The generation module 430 is used to generate an instance allocation scheme based on instance usage data, which allocates the reserved instances overflowing from the second account to the first account.

[0079] In this embodiment, by obtaining reserved instance data and instance usage data of multiple accounts, and on this basis, determining the first account with insufficient reserved instances and the second account with overflowing reserved instances, a comprehensive analysis of the cloud resource usage of multiple accounts is conducted. Based on the instance usage data, an instance allocation scheme is generated to allocate the overflowing reserved instances in the second account to the first account, so that the originally underutilized reserved instances can be used to cover the instance usage needs of the account with insufficient reserved instances, thereby improving the overall utilization efficiency of reserved instances.

[0080] In some embodiments of this application, the determining module 420 determines a first account and a second account from multiple accounts based on reserved instance data and instance usage data, including: Analyze the reserved instance data to determine the utilization rate and coverage of reserved instances for multiple accounts. The coverage rate is the percentage of reserved instances among all instances of the corresponding account. Accounts with a usage rate higher than or equal to the first threshold and a coverage rate lower than the second threshold are identified as the first account; Accounts with usage rates below the third threshold are identified as second accounts.

[0081] In some embodiments of this application, the generation module 430 generates an instance allocation scheme based on instance usage data, which allocates the reserved instances overflowing from the second account to the first account, including: Match the reserved instance of the first account that overflowed with the non-reserved instance of the second account; When there are matching target overflow reserved instances and target non-reserved instances, the target overflow reserved instance is assigned to the first account corresponding to the target non-reserved instance based on the instance usage data, thus obtaining the instance allocation scheme.

[0082] In some embodiments of this application, the generation module 430 matches the reserved instance of the first account overflow with the non-reserved instance of the second account, including: Determine the configuration information of the overflowing reserved instances and the configuration information of the non-reserved instances, wherein the configuration information includes at least one of the following: instance specifications and region; Match the configuration information of the overflowing reserved instances with the configuration information of the non-reserved instances; If matching configuration information exists, determine whether there are matching target overflow reserved instances and target non-reserved instances.

[0083] In some embodiments of this application, the generation module 430 generates multiple first accounts corresponding to the target non-reserved instances. Based on instance usage data, it allocates the target overflow reserved instances to the first accounts corresponding to the target non-reserved instances to obtain an instance allocation scheme, including: Obtain the business priority of multiple primary accounts corresponding to the target non-reserved instance; Based on instance usage data, determine the instance usage trends of multiple primary accounts corresponding to the target non-reserved instance; Based on business priorities and instance usage trends, select the target primary account from among the multiple primary accounts corresponding to the target non-reserved instance; The target overflow reserved instance is allocated to the target first account to obtain the instance allocation scheme.

[0084] In some embodiments of this application, the generation module 430 selects a target first account from multiple first accounts corresponding to the target non-reserved instance based on business priority and instance usage trends, including: Among the multiple first accounts corresponding to the target non-reserved instance, the accounts whose instance usage trend fluctuation value is less than a predetermined threshold are identified as candidate accounts. Among the candidate accounts, the account with the highest business priority is identified as the target primary account.

[0085] In some embodiments of this application, the instance allocation device 400 is further configured to: Real-time monitoring of configuration information for multiple account instances; When the configuration information of instances for multiple accounts changes, the steps to obtain reserved instance data and instance usage data for multiple accounts are executed.

[0086] This application embodiment also provides a terminal device that integrates any of the instance allocation devices provided in this application embodiment. The terminal device includes: One or more processors; Memory; and One or more applications, wherein the applications are stored in memory and configured to be executed by a processor in the steps of the instance allocation method in any of the embodiments described above.

[0087] This application also provides a terminal device that integrates any of the instance allocation devices provided in this application. For example... Figure 5 As shown, it illustrates a structural schematic diagram of the terminal device involved in the embodiments of this application. Specifically: The terminal device may include components such as a processor 501 with one or more processing cores, a memory 502 with one or more computer-readable storage media, a power supply 503, and an input unit 504. Those skilled in the art will understand that... Figure 5 The terminal device structure shown does not constitute a limitation on the terminal device and may include more or fewer components than shown, or combine certain components, or have different component arrangements. Wherein: The processor 501 is the control center of the terminal device. It connects various parts of the terminal device via various interfaces and lines, and performs various functions and processes data by running or executing software programs and / or modules stored in the memory 502, and by calling data stored in the memory 502, thereby providing overall monitoring of the terminal device. Optionally, the processor 501 may include one or more processing cores; preferably, the processor 501 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, user interface, and applications, and the modem processor mainly handles wireless communication. It is understood that the modem processor may not be integrated into the processor 501.

[0088] The memory 502 can be used to store software programs and modules. The processor 501 executes various functional applications and data processing by running the software programs and modules stored in the memory 502. The memory 502 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the terminal device, etc. In addition, the memory 502 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory 502 may also include a memory controller to provide the processor 501 with access to the memory 502.

[0089] The terminal device also includes a power supply 503 that supplies power to the various components. Preferably, the power supply 503 can be logically connected to the processor 501 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply 503 may also include one or more DC or AC power supplies, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and other arbitrary components.

[0090] The terminal device may also include an input unit 504, which can be used to receive input digital or character information, and generate keyboard, mouse, joystick, optical or trackball signal inputs related to user settings and function control.

[0091] Although not shown, the terminal device may also include a display unit, etc., which will not be described in detail here. Specifically, in this embodiment, the processor 501 in the terminal device loads the executable files corresponding to the processes of one or more applications into the memory 502 according to the following instructions, and the processor 501 runs the applications stored in the memory 502 to realize various functions, as follows: Obtain reserved instance data and instance usage data for multiple accounts; Based on the reserved instance data and instance usage data, the first account and the second account are determined among multiple accounts. The first account is the account with insufficient reserved instances, and the second account is the account with overflowing reserved instances. Based on instance usage data, generate an instance allocation scheme that allocates the reserved instances overflowing from the second account to the first account.

[0092] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be performed by instructions, or by instructions controlling related hardware. These instructions can be stored in a computer-readable storage medium and loaded and executed by a processor.

[0093] Therefore, embodiments of this application provide a computer-readable storage medium, which may include: read-only memory (ROM), random access memory (RAM), a magnetic disk, or an optical disk, etc. A computer program is stored thereon, and the computer program is loaded by a processor to execute the steps in any of the instance allocation methods provided in embodiments of this application. For example, the computer program loaded by the processor can execute the following steps: Obtain reserved instance data and instance usage data for multiple accounts; Based on the reserved instance data and instance usage data, the first account and the second account are determined among multiple accounts. The first account is the account with insufficient reserved instances, and the second account is the account with overflowing reserved instances. Based on instance usage data, generate an instance allocation scheme that allocates the reserved instances overflowing from the second account to the first account.

[0094] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the detailed descriptions of other embodiments above, which will not be repeated here.

[0095] In practice, each of the above units or structures can be implemented as an independent entity or can be arbitrarily combined to be implemented as the same or several entities. For the specific implementation of each of the above units or structures, please refer to the previous method embodiments, which will not be repeated here.

[0096] For details on the implementation of each of the above operations, please refer to the previous examples, which will not be repeated here.

[0097] The above provides a detailed description of an instance allocation method, apparatus, terminal device, and computer-readable storage medium provided in the embodiments of this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. An instance allocation method, characterized in that, include: Obtain reserved instance data and instance usage data for multiple accounts; Based on the reserved instance data and the instance usage data, a first account and a second account are determined from the plurality of accounts, wherein the first account is an account with insufficient reserved instances, and the second account is an account with overflowing reserved instances. Based on the instance usage data, an instance allocation scheme is generated to allocate the reserved instances overflowing from the second account to the first account.

2. The instance allocation method according to claim 1, characterized in that, The step of determining the first account and the second account from the plurality of accounts based on the reserved instance data and the instance usage data includes: The reserved instance data is analyzed to determine the utilization rate and coverage rate of the reserved instances for the multiple accounts, wherein the coverage rate is the proportion of the reserved instances among all instances of the corresponding account; Accounts with a usage rate higher than or equal to the first threshold and a coverage rate lower than the second threshold are identified as the first account; Accounts with usage rates below the third threshold are identified as the second type of account.

3. The instance allocation method according to claim 1, characterized in that, The step of generating an instance allocation scheme based on the instance usage data, which allocates the reserved instances overflowing from the second account to the first account, includes: Match the reserved instances of the first account that overflowed with the non-reserved instances of the second account; When there are matching target overflow reserved instances and target non-reserved instances, the target overflow reserved instance is allocated to the first account corresponding to the target non-reserved instance based on the instance usage data, thus obtaining the instance allocation scheme.

4. The instance allocation method according to claim 3, characterized in that, The step of matching the reserved instance of the first account overflow with the non-reserved instance of the second account includes: Determine the configuration information of the overflowing reserved instance and the configuration information of the non-reserved instance, wherein the configuration information includes at least one of the following: instance specifications and region; The configuration information of the overflowing reserved instance is matched with the configuration information of the non-reserved instance; If matching configuration information exists, determine whether there are matching target overflow reserved instances and target non-reserved instances.

5. The instance allocation method according to claim 3, characterized in that, The target non-reserved instance corresponds to multiple first accounts. The step of allocating the target overflow reserved instance to the first account corresponding to the target non-reserved instance based on the instance usage data, to obtain the instance allocation scheme, includes: Obtain the business priorities of multiple first accounts corresponding to the target non-reserved instance; Based on the instance usage data, determine the instance usage trends of multiple first accounts corresponding to the target non-reserved instance; Based on the business priority and the instance usage trend, select the target first account from the multiple first accounts corresponding to the target non-reserved instance; The target overflow reserved instance is allocated to the target first account to obtain the instance allocation scheme.

6. The instance allocation method according to claim 5, characterized in that, The step of selecting the target first account from among the multiple first accounts corresponding to the target non-reserved instance based on the business priority and the instance usage trend includes: Among the multiple first accounts corresponding to the target non-reserved instance, the accounts whose instance usage trend fluctuation value is less than a predetermined threshold are identified as candidate accounts; Among the candidate accounts, the account with the highest business priority is determined as the target first account.

7. The instance allocation method according to claim 1, characterized in that, Also includes: Real-time monitoring of the configuration information of the instances of the multiple accounts; When the configuration information of the instances of the multiple accounts changes, the steps of obtaining the reserved instance data and instance usage data of the multiple accounts are executed.

8. An instance allocation device, characterized in that, include: The acquisition module is used to acquire reserved instance data and instance usage data for multiple accounts; The determining module is used to determine a first account and a second account from the plurality of accounts based on the reserved instance data and the instance usage data, wherein the first account is an account with insufficient reserved instances and the second account is an account with overflowing reserved instances; The generation module is used to generate an instance allocation scheme based on the instance usage data, which allocates the reserved instances overflowing from the second account to the first account.

9. A terminal device, characterized in that, The terminal device includes: one or more processors, a memory, and one or more applications, wherein the one or more applications are stored in the memory and configured to be executed by the processor to implement the instance allocation method of any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, It stores a computer program, which is loaded by a processor to perform the steps of the instance allocation method according to any one of claims 1 to 7.

Images