Resource allocation method, apparatus, cluster, and program product
Patent Information
- Application Number
- CN202411551459.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2024-10-31
- Publication Date
- 2026-08-18
- Estimated Expiration
- 2044-10-31
AI Technical Summary
[0004]本申请提供一种资源分配方法、装置、集群以及程序产品,以解决网关高可用性的问题
[0060]关于第二方面至第五方面中任一种实现方式所带来的技术效果可参见第一方面或第一方面中任一种可选的实现方式所带来的技术效果。此处不再赘述。本申请在上述各方面提供的实现方式的基础上,还可以进一步组合以提供更多实现方式。
Smart Images

Figure CN119629074B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of cloud computing technology, and in particular to a resource allocation method, apparatus, cluster, and program product. Background Technology
[0002] Cloud computing services manage and schedule a large number of computing resources in a unified manner, forming a resource pool and providing services to users on demand through the network. In cloud computing service scenarios, to ensure the reliability of Service Level Agreements (SLAs), multiple gateway instances are typically deployed in the cloud platform for the same service, and these multiple gateway instances are used to forward data streams.
[0003] However, since multiple gateway instances may be located in the same rack, the same data center, or the same physical device, there is a lack of anti-affinity between multiple gateway instances that process the same service, resulting in low reliability of the gateway instances. Summary of the Invention
[0004] This application provides a resource allocation method, apparatus, cluster, and program product to solve the problem of gateway high availability.
[0005] Firstly, this application provides a resource allocation method. During the resource allocation process, a cloud management platform receives a first request and creates an anti-affinity group comprising multiple fault domains within the cloud management platform. The cloud management platform obtains multiple instance creation requests within the anti-affinity group, creates multiple gateway instances within the anti-affinity group according to these requests, and schedules the first gateway instance among the multiple gateway instances to a first cluster of the infrastructure, ensuring that the fault domain of the first cluster is different from the fault domains of other clusters with scheduled gateway instances.
[0006] Based on the first aspect, it ensures anti-affinity among gateway instances deployed in different fault domains, resulting in different blast radii for different gateway instances. Even if one gateway instance fails, the remaining gateway instances can continue to operate normally, thereby improving overall reliability. Furthermore, using anti-affinity groups to guarantee anti-affinity among multiple gateway instances eliminates the need for users to manually configure anti-affinity among multiple gateway instances, greatly simplifying the deployment of multiple gateway instances.
[0007] In one alternative implementation, in response to the first request, an anti-affinity group is created in the cloud management platform, specifically as follows:
[0008] In response to the first request, the cloud management platform provides a first interface, which includes an anti-affinity group identifier input box. In response to the first operation on the first interface, the cloud management platform provides a second interface. In the second interface, the anti-affinity group identifier input box includes an anti-affinity group identifier. In response to the second operation on the second interface, the cloud management platform creates an anti-affinity group.
[0009] In this way, the creation process of anti-affinity gateway instances is simplified and the difficulty of creating anti-affinity gateway instances is reduced by creating anti-affinity groups through interface interaction.
[0010] In one optional implementation, the second interface further includes an anti-affinity group query box. During the process of obtaining multiple instance creation requests, the cloud management platform responds to a third operation on the second interface and provides a third interface; in the third interface, the anti-affinity group query box includes an anti-affinity group identifier. The cloud management platform responds to a fourth operation on the third interface and provides a fourth interface. The fourth interface includes: the anti-affinity group identifier, the number of instances in the anti-affinity group corresponding to that identifier, and instance operation function controls. Furthermore, the cloud management platform responds to a fifth operation on the fourth interface by obtaining instance creation requests.
[0011] For example, the number of instances includes the number of gateway instances associated with the anti-affinity group and the total number of gateway instances that the anti-affinity group supports associating with; the instance operation function control is used to create instances within the anti-affinity group.
[0012] In this way, the cloud management platform interacts with users through a user interface. Users can set up gateway instances through the interface, which simplifies the implementation difficulty of deploying multiple gateway instances and helps improve the reliability of gateway instances deployed in the cloud management platform.
[0013] In one optional implementation, obtaining multiple instance creation requests specifically involves: the cloud management platform obtaining a second request; this second request carries an anti-affinity group identifier. Furthermore, in response to the second request, the cloud management platform provides a fifth interface. This fifth interface includes an anti-affinity group input box and an instance input box; the anti-affinity group input box includes an anti-affinity group identifier. Finally, in response to a sixth operation on the fifth interface, the cloud management platform obtains an instance creation request; this instance creation request carries an anti-affinity group identifier.
[0014] In the first aspect of this application, the cloud management platform provides users with an anti-affinity group model, which eliminates the need for users to manually configure anti-affinity between multiple gateway instances, thereby greatly simplifying the difficulty of deploying multiple gateway instances.
[0015] In one optional implementation, each instance creation request carries an anti-affinity group identifier. In the implementation where the cloud management platform creates multiple gateway instances in the anti-affinity group based on multiple instance creation requests, for the first instance creation request among the multiple instance creation requests, the cloud management platform provides a sixth interface in response to the first instance creation request. This sixth interface includes the anti-affinity group identifier carried by the first instance creation request and the first instance identifier. In response to a seventh operation on the sixth interface, the cloud management platform creates the first gateway instance and associates the first gateway instance with the anti-affinity group identifier.
[0016] In this way, the cloud management platform provides users with an anti-affinity group model through a user interface, so that users do not need to configure anti-affinity between multiple gateway instances themselves, which greatly simplifies the difficulty of deploying multiple gateway instances.
[0017] In one optional implementation, the fault domains included in the anti-affinity group are related to the instance types within the anti-affinity group; the instance types include: cross-availability zone instances and non-cross-availability zone instances.
[0018] Cross-Availability Zone instances indicate that multiple nodes in the first cluster are located in at least two availability zones. Non-cross-Availability Zone instances indicate that all nodes in the first cluster are located in the same availability zone.
[0019] Optionally, when the instance type is a cross-availability zone instance, the fault domain included in the anti-affinity group is the host group.
[0020] Optionally, when the instance type is an instance that does not span availability zones, the fault domains included in the anti-affinity group are availability zones or host groups.
[0021] In this way, the cloud management platform can provide multiple ways to set up fault domains and set up corresponding fault domains based on the instance type of the gateway instance, thereby improving the flexibility of fault domain settings.
[0022] In one alternative implementation, multiple gateway instances of the anti-affinity group operate in a master-master mode. Multiple data streams are processed by the multiple gateway instances of the anti-affinity group; different gateway instances process different data streams.
[0023] In this way, multiple gateway instances belonging to the same anti-affinity group can run in master-master mode, forwarding data streams in parallel, which can improve data stream forwarding efficiency. Furthermore, if one gateway instance fails, it can automatically switch to another healthy gateway instance, thus ensuring high availability of the gateway.
[0024] In one optional implementation, the multiple gateway instances of the anti-affinity group operate in a primary / standby mode. Data flow is processed by the first gateway instance. If the first gateway instance fails, the data flow transmission node switches to the second gateway instance among the multiple gateway instances. The second gateway instance can be any one of the multiple gateway instances other than the first gateway instance.
[0025] In this way, when multiple gateway instances within the same anti-affinity group operate in primary / standby mode, redundant gateway instances are provided, thereby improving gateway reliability. Furthermore, in the event of a failure of the primary gateway instance, automatic switchover to the standby gateway instance is possible, ensuring high availability of the gateway.
[0026] In one optional implementation, the specific implementation is as follows: the first gateway instance is a cross-availability zone instance, and the second gateway instance is a cross-availability zone instance; the second gateway instance is any one of the multiple gateway instances except for the first gateway instance.
[0027] A first gateway instance includes multiple first gateway entities; different first gateway entities correspond to different availability zones;
[0028] The second gateway instance comprises multiple second gateway entities; different second gateway entities correspond to different availability zones. In the event of a failure of the first gateway instance, the cloud management platform will switch the data flow transmission node of the first gateway entity within the first availability zone to the second gateway entity located within the first availability zone.
[0029] Thus, during the switching of data flow transmission nodes across availability zones, data flows within the same availability zone are forwarded by the second gateway entity within that availability zone, without needing to bypass the availability zone, thereby shortening the data flow transmission time and reducing transmission latency.
[0030] In one alternative implementation, scheduling the first gateway instance to the first cluster of the infrastructure is specifically implemented as follows: the cloud management platform initializes multiple clusters in the infrastructure; the number of clusters is the same as the number of fault domains included in the anti-affinity group. The cloud management platform selects the first cluster from multiple candidate clusters based on the resource specifications of the first gateway instance; and schedules the first gateway instance to the first cluster.
[0031] Optionally, the specifications of the first cluster match the resource specifications of the first gateway instance; the candidate clusters include clusters among multiple clusters that have not scheduled gateway instances.
[0032] Based on this optional implementation, the cluster of gateway instances is determined according to resource specifications, ensuring the compatibility between the cluster and the gateway instances and improving the reliability of the gateway instances. Furthermore, the cloud management platform handles the scheduling of gateway instances automatically, eliminating the need for users to concern themselves with the complex underlying scheduling mechanisms, thus greatly simplifying the deployment of multiple gateway instances.
[0033] Secondly, this application provides a resource allocation device. The device is deployed on a cloud management platform; the cloud management platform is used to manage infrastructure, which includes multiple hosts; the device includes a communication module, a processing module, and a storage module.
[0034] The communication module is used to respond to the first request and to obtain multiple instance creation requests.
[0035] The processing module is used to create an anti-affinity group corresponding to the first request, create requests based on multiple instances, create multiple gateway instances in the anti-affinity group, and schedule the first gateway instance among the multiple gateway instances to the first cluster of the infrastructure.
[0036] The storage module is used to store executable program code, as well as data from the resource allocation device during the resource allocation process, etc.
[0037] One gateway instance corresponds to one instance creation request; the anti-affinity group includes multiple fault domains, and gateway instances deployed in different fault domains have anti-affinity. The fault domain is an availability zone, host group, or host; the first cluster includes M hosts from multiple hosts, and the fault domain of the first cluster is different from the fault domain of other clusters with scheduled gateway instances.
[0038] In one alternative implementation, the processing module is configured to: provide a first interface in response to a first request, the first interface including an anti-affinity group identifier input box; provide a second interface in response to a first operation on the first interface; in the second interface, the anti-affinity group identifier input box includes an anti-affinity group identifier; and create an anti-affinity group in response to a second operation on the second interface.
[0039] In one optional implementation, the second interface further includes an anti-affinity group query box. The aforementioned processing module is configured to: respond to a third operation on the second interface and provide a third interface, in which the anti-affinity group query box includes an anti-affinity group identifier; and respond to a fourth operation on the third interface and provide a fourth interface, wherein the fourth interface includes: an anti-affinity group identifier, the number of instances of the anti-affinity group corresponding to the anti-affinity group identifier, and instance operation function controls. For example, the number of instances includes the number of gateway instances associated with the anti-affinity group and the total number of gateway instances that the anti-affinity group supports associating with; the instance operation function controls are used to create instances within the anti-affinity group. The aforementioned processing module is also configured to: respond to a fifth operation on the fourth interface and obtain an instance creation request.
[0040] In one alternative implementation, the processing module is used for:
[0041] Obtain a second request; this second request carries an anti-affinity group identifier;
[0042] In response to the second request, a fifth interface is provided; wherein the fifth interface includes an anti-affinity group input box and an instance input box; the anti-affinity group input box includes an anti-affinity group identifier;
[0043] The aforementioned processing module is also used to: in response to the sixth operation on the fifth interface, obtain an instance creation request; the instance creation request carries an anti-affinity group identifier.
[0044] In one optional implementation, each instance creation request carries an anti-affinity group identifier. The aforementioned processing module is used to: for the first instance creation request among multiple instance creation requests, provide a sixth interface in response to the first instance creation request; and, in response to a seventh operation on the sixth interface, create a first gateway instance and associate the first gateway instance with the anti-affinity group identifier. The sixth interface includes the anti-affinity group identifier carried by the first instance creation request and the first instance identifier.
[0045] In one optional implementation, the fault domains included in the anti-affinity group are related to the instance types within the anti-affinity group; the instance types include: cross-availability zone instances and non-cross-availability zone instances.
[0046] Cross-Availability Zone instances indicate that multiple nodes in the first cluster are located in at least two availability zones. Non-cross-Availability Zone instances indicate that all nodes in the first cluster are located in the same availability zone.
[0047] Optionally, when the instance type is a cross-availability zone instance, the fault domain included in the anti-affinity group is the host group.
[0048] Optionally, when the instance type is an instance that does not span availability zones, the fault domains included in the anti-affinity group are availability zones or host groups.
[0049] In one alternative implementation, multiple gateway instances of the anti-affinity group operate in a master-master mode. Multiple data streams are processed by the multiple gateway instances of the anti-affinity group; different gateway instances process different data streams.
[0050] In one optional implementation, the multiple gateway instances of the anti-affinity group operate in a primary / standby mode. Data flow is processed by the first gateway instance. In the event of a failure of the first gateway instance, the data flow transmission node switches to the second gateway instance among the multiple gateway instances. The second gateway instance can be any one of the multiple gateway instances other than the first gateway instance.
[0051] In one optional implementation, the specific implementation is as follows: the first gateway instance is a cross-availability zone instance, and the second gateway instance is a cross-availability zone instance; the second gateway instance is any one of the multiple gateway instances except for the first gateway instance.
[0052] A first gateway instance includes multiple first gateway entities; different first gateway entities correspond to different availability zones.
[0053] A second gateway instance includes multiple second gateway entities; different second gateway entities correspond to different availability zones.
[0054] The processing module is also configured to: in the event of a failure of the first gateway instance, switch the transmission node of the data flow of the first gateway entity in the first availability zone to the second gateway entity located in the first availability zone.
[0055] In one alternative implementation, the specific implementation includes: a processing module further configured to initialize multiple clusters in the infrastructure; the number of clusters being the same as the number of fault domains included in the anti-affinity group; and selecting a first cluster from multiple candidate clusters based on the resource specifications of the first gateway instance; and scheduling the first gateway instance to the first cluster.
[0056] Optionally, the specifications of the first cluster match the resource specifications of the first gateway instance; the candidate clusters include clusters among multiple clusters that have not scheduled gateway instances.
[0057] Thirdly, this application provides a computing device cluster. The computing device cluster includes at least one computing device. Each computing device includes a processor and a memory; the processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the computing device cluster to perform the method as described in the first aspect or any optional implementation thereof.
[0058] Fourthly, embodiments of this application provide a computer program product containing instructions that, when executed by a computing device cluster, cause the computing device cluster to perform the method described in the first aspect or any optional implementation thereof.
[0059] Fifthly, embodiments of this application provide a computer-readable storage medium including computer program instructions. When the computer program instructions are executed by a computing device cluster, the computing device cluster executes the instructions in the computing program stored in the computer-readable storage medium to perform the method in the first aspect or any optional implementation of the first aspect.
[0060] The technical effects of any of the implementations in aspects two through five can be found in the first aspect or any optional implementation of the first aspect. Further details are omitted here. Based on the implementations provided in the above aspects, this application can be further combined to provide more implementations. Attached Figure Description
[0061] Figure 1 A diagram illustrating the forwarding of data streams for multiple gateway instances;
[0062] Figure 2 A schematic diagram of the computer system provided in this application;
[0063] Figure 3 A flowchart illustrating the resource allocation method provided in this application;
[0064] Figure 4 This application provides schematic diagrams of gateway instances of different instance types.
[0065] Figure 5 A flowchart illustrating the scheduling gateway instance provided in this application;
[0066] Figure 6 A schematic diagram illustrating gateway instance scheduling in the master-master mode provided in this application;
[0067] Figure 7 A schematic diagram illustrating gateway instance scheduling in the primary / standby mode provided in this application;
[0068] Figure 8 This application provides a schematic diagram of gateway instance scheduling across availability zones.
[0069] Figure 9 A schematic diagram of the interactive interface for creating anti-affinity groups provided in this application. Figure 1 ;
[0070] Figure 10 A schematic diagram of the interactive interface for creating anti-affinity groups provided in this application. Figure 2 ;
[0071] Figure 11A A schematic diagram of the interactive interface for creating an instance as provided in this application. Figure 1 ;
[0072] Figure 11B A schematic diagram of the interactive interface for creating an instance as provided in this application. Figure 2 ;
[0073] Figure 11C A schematic diagram of the interactive interface for creating an instance as provided in this application. Figure 3 ;
[0074] Figure 12 A schematic diagram of the interactive interface for creating a gateway instance provided in this application;
[0075] Figure 13 A schematic diagram of the resource allocation device provided in this application;
[0076] Figure 14 A schematic diagram of the computing device provided in this application;
[0077] Figure 15 This application provides a schematic diagram of the structure of a computing device cluster.
[0078] Figure 16 This is a schematic diagram of the network connection between computing devices in the computing device cluster provided in this application. Detailed Implementation
[0079] For the same business logic, multiple gateway instances are typically deployed in the cloud platform to forward data streams. For example... Figure 1 As shown in (a) in the figure, Figure 1 Figure (a) illustrates the forwarding of data streams by multiple gateway instances. Virtual machine 1 processes service 1. During the processing of service 1, the data stream of service 1 is distributed to gateway instance 1 and gateway instance 2 through load balancing. Gateway instance 1 and gateway instance 2 then forward their respective received data streams to virtual machine 1.
[0080] Currently, when deploying gateway instances, multiple gateway instances may be located in the same rack, the same data center, or the same physical device, resulting in anti-affinity between multiple gateway instances belonging to the same task.
[0081] like Figure 1 As shown in Figure (b), gateway instance 1 and gateway instance 2 are created in the cloud platform. Gateway instance 1 includes gateway entity 1 and referral entity 1, and gateway entity 2 includes referral entity 2. Figure 2As shown, Gateway Entity 1 and Gateway Entity 2 are located in the gateway node cluster of the cloud platform. Traffic Referral Entity 1 and Traffic Referral Entity 2 are located in the traffic referral cluster of the cloud platform. Therefore, Gateway Entity 1 (or Traffic Referral Entity 1) and Gateway Entity 2 (or Traffic Referral Entity 2) may be located in the same rack, the same data center, or under the same physical device.
[0082] like Figure 1 As shown in Figure (c), relative to Figure 1 Figure (b) in Figure 1 In diagram (c), gateway instance 1 is located in availability zone 1, gateway instance 2 is located in availability zone 2, and referral entity 1 and referral entity 2 are located in the referral cluster of the cloud platform. Therefore, it can be seen that... Figure 1 The deployment illustration provided in Figure (c) still suffers from a lack of affinity between gateway instances. Furthermore, when gateway instance 1 in Availability Zone 1 fails, the data flow forwarded by gateway instance 1 will be forwarded by gateway instance 2. Since gateway instance 1 and gateway instance 2 are located in different Availability Zones, the data flow needs to detour across Availability Zones, resulting in high latency.
[0083] Based on this, this application provides a resource allocation method to address the high availability issue of gateways. This method ensures anti-affinity among gateway instances deployed in different fault domains, resulting in different blast radii for different gateway instances. This ensures that a failure in one gateway instance will not affect other gateway instances, thus improving overall reliability. Furthermore, by utilizing anti-affinity groups to guarantee anti-affinity among multiple gateway instances, users do not need to manually configure anti-affinity among multiple gateway instances, greatly simplifying the deployment of multiple gateway instances.
[0084] Specifically, during the resource allocation process, an anti-affinity group comprising multiple fault domains is created in the cloud management platform. Multiple gateway instances are created within the anti-affinity group, and the first gateway instance among the multiple gateway instances is scheduled to the first cluster of the infrastructure. It is ensured that the fault domain of the first cluster is different from the fault domain of other clusters that have scheduled gateway instances.
[0085] It should be noted that the resource allocation method provided in this application embodiment can be used not only for the deployment of multiple gateway instances, but also for the deployment of multiple containers and virtual machines. This application embodiment does not limit this application. It is understood that when the resource allocation method is used for the deployment of multiple containers and virtual machines, the anti-affinity group includes multiple instances or containers, and the instances or containers within the anti-affinity group have anti-affinity properties.
[0086] The terminology used in the implementation section of this application is only for explaining specific embodiments of this application and is not intended to limit this application. A brief introduction to some concepts that may be involved in this application is given below.
[0087] Resources refer to virtual computing resources in cloud services, such as threads, processes, or data streams, or hardware resources, such as processors, network connections, or expansion cards.
[0088] A resource pool refers to the collection of various hardware and software involved in a cloud computing data center, which can be divided into computing resources, storage resources, and network resources according to their type.
[0089] Scheduling refers to the process of allocating resources to a number of instances in a cloud service.
[0090] Cloud computing environment: An entity that provides cloud services to users using basic resources under the cloud computing model. The cloud environment includes cloud data centers and cloud service platforms.
[0091] Cloud data centers encompass a vast amount of basic resources (including computing clusters, storage resources, and network resources) owned by cloud service providers. In this article, cloud data centers may also be referred to as cloud management platforms, cloud computing platforms, etc.
[0092] Host: A physical server deployed in a cloud management platform. The physical resources of a host include the physical central processing unit (CPU) and memory devices. Each host runs virtualization software, which virtualizes some physical resources into virtual resources for use by instances. For example, the virtualization software virtualizes the CPU into a virtual CPU (vCPU). The host also has resources such as memory channels, cache channels, caches, network input / output (I / O) bandwidth, and storage I / O bandwidth, which are shared by the instances running on the host.
[0093] Instance: A compute node running on a host machine. Common instances include virtual machines (VMs) or containers. Each instance consumes some or all of the host machine's virtual resources. Typically, instances deployed on compute nodes can be used for data transfer, data computation, etc. In this article, instances used for data transfer are referred to as gateway instances. In some other implementations, instances used for data transfer may also be called gateways.
[0094] A gateway instance, a data flow forwarding gateway, is typically a virtual gateway. Its main functions include route matching and forwarding, and Network Address Translation (NAT). A gateway instance generally consists of a traffic-leading entity and a gateway entity.
[0095] The referrer entity refers to the front-end access layer of the gateway instance. The referrer entity is used to direct traffic to multiple gateway entity nodes.
[0096] A gateway entity, composed of multiple gateway nodes, is responsible for processing data flows, such as NAT translation or route forwarding.
[0097] An anti-affinity group refers to a collection of gateway instances. Different gateway instances belonging to the same anti-affinity group reside in different fault domains. Instances located in different fault domains do not affect each other. In the following text, an anti-affinity group includes multiple gateway instances.
[0098] A fault domain refers to an area or part of a computer system that may experience a fault. Depending on the fault domain level, fault domains can typically include: zones, availability zones, host groups, and hosts.
[0099] The following provides illustrative examples of regions, availability zones, host groups, and hosts.
[0100] A region refers to a collection of data centers belonging to a cloud service provider across a geographical area. It typically comprises multiple physically adjacent locations. Generally, a region can span one or more geographical locations. Different regions are highly networked, yet physically isolated from each other. A region usually contains one or more availability zones.
[0101] An Availability Zone (AZ) refers to a collection of one or more physical data centers. Network connectivity and power supply are isolated between different Availability Zones. Typically, an Availability Zone contains one or more server units.
[0102] A server group (also known as a host group or rack) refers to a collection of computing resources that are logically or physically located within an availability zone. In this article, a server group contains one or more hosts.
[0103] The following uses different levels of fault domains as examples to illustrate how different gateway instances in the anti-affinity group are located in different fault zones.
[0104] In the first example, the fault domain is a region. Different gateway instances within an anti-affinity group are located in different regions.
[0105] In the second example, the fault domain is an availability zone. Different gateway instances within an anti-affinity group reside in different availability zones. Multiple availability zones can be located within the same region, or at least two of the multiple availability zones can be located in different regions.
[0106] In the third example, the fault domain is the server group. Different gateway instances within an anti-affinity group reside on different server groups. Multiple server groups can reside in the same availability zone, or at least two of the multiple server groups can reside in different availability zones.
[0107] In the fourth example, the fault domain is the host. Different gateway instances within an anti-affinity group reside on different hosts. Multiple hosts can reside on the same group. Alternatively, different hosts can reside on different groups.
[0108] The four examples above are merely illustrative examples illustrating that different gateway instances within an anti-affinity group are located in different fault zones at different fault domain levels. They should not be construed as limiting the resource allocation method provided in the embodiments of this application.
[0109] The blast radius, also known as the gateway instance's blast radius, indicates the area affected by a gateway instance failure. Understandably, given that different gateway instances have different blast radii, if one gateway instance fails, the remaining gateway instances can continue to operate normally.
[0110] The instance specifications, also known as instance size or resource specifications, indicate the amount of resources an instance uses.
[0111] Specifications include: number of vCPUs and memory size (in gigabytes, GB).
[0112] Alternatively, specifications may include: the number of vCPUs, memory size, memory bandwidth, network bandwidth, number of graphics processing units (GPUs), and the size of non-volatile storage devices (typically high-speed storage media such as solid-state drives (SSDs) or NVMe SSDs). In this article, the resource specifications of gateway instances mainly include memory size, memory bandwidth, and network bandwidth. The specifications of a cluster deploying gateway instances mainly include memory size, memory bandwidth, and network bandwidth.
[0113] A service level agreement (SLA) is an agreement between a service provider and a user, or between service providers themselves, to ensure the performance and reliability of a service.
[0114] Virtual Private Cloud (VPC) provides a secure and isolated network environment by using logical network isolation.
[0115] In a virtual private cloud (VPN) scenario, multiple gateway instances can typically be created to handle the data flow of a single service, thereby ensuring the network security of the VPN. This data flow can also be referred to as a service flow or service traffic.
[0116] Load balancing (LB) is a network technology that distributes traffic across multiple gateway instances and has the ability to detect gateway instance failover.
[0117] The resource allocation method provided in this application is described below with reference to the accompanying drawings.
[0118] First see Figure 2 , Figure 2 A schematic diagram of the structure of a computer system provided for this application. For example... Figure 2 As shown, the computer system includes a client 20, a cloud service platform 30, and a cloud management platform 10.
[0119] In a first optional implementation, the client 20 can be a computer running an application. This computer can be a physical machine or a virtual machine. For example, if the computer running the application is a physical computing device, it can be a host or a terminal. A terminal can also be called a terminal device, user equipment (UE), mobile station (MS), mobile terminal (MT), etc. Terminals can be mobile phones, tablets, laptops, desktop computers, virtual reality (VR) terminal devices, augmented reality (AR) terminal devices, wireless terminals in industrial control, wireless terminals in autonomous driving, wireless terminals in remote medical surgery, wireless terminals in smart grids, wireless terminals in transportation safety, wireless terminals in smart cities, wireless terminals in smart homes, and so on. The embodiments of this application do not limit the specific technology or device form used by the client 20.
[0120] In the second alternative implementation, client 20 can be an application, such as a cloud computing application. Alternatively, client 20 can be a web client. Client 20 runs on a terminal device. The terminal device includes, but is not limited to, mobile terminals, tablets, personal computers, or laptops.
[0121] It should be noted that the above two implementation methods are merely different implementations of the client 20. In practical applications, the client 20 can also have other implementation methods. For example, the client 20 can be a software module running on any one or more hosts in the computing cluster 110. This application does not limit this.
[0122] In one alternative implementation, a resource management system 120 is deployed in the cloud management platform 10.
[0123] In some implementations, the resource management system 120 can be deployed independently on an instance of the cloud management platform 10. Alternatively, the resource management system 120 can be deployed in a distributed manner across multiple instances of the cloud management platform 10.
[0124] like Figure 2 As shown, the resource management system 120 is abstracted into a cloud service by the cloud service provider on the cloud service platform 30 and provided to users. After a user purchases the cloud service through the client 20 on the cloud service platform 30 (pre-payment is possible, with settlement based on the final resource usage), the cloud environment utilizes the resource management system 120 deployed on the cloud management platform 10 to provide the cloud service to the user. When using the cloud service, the user can determine the tasks to be executed and upload data to the cloud environment through the application programming interface (API) or graphical user interface (GUI) in the client 20. The resource management system 120 in the cloud environment receives the user's task information and data, performs data processing and executes the corresponding tasks, and obtains the processing results. The resource management system 120 returns the processing results of the tasks or the status information during the execution process to the user through the API or GUI. Among these tasks, there are including but not limited to AI model training tasks, AI recognition tasks, content generation tasks, instance scheduling, data analysis business, etc. This application does not limit these tasks.
[0125] In addition, in some other embodiments, the functions of the resource management system 120 may be performed by the cloud management platform 10 or other components of the cloud management platform 10, and this application does not limit the implementation method.
[0126] In one alternative implementation, such as Figure 2 As shown, the cloud management platform 10 also includes a computing cluster 110.
[0127] Here, computing cluster 110 refers to a collection of computers connected via a local area network or the Internet, which includes multiple hosts. For example... Figure 2 As shown, computing cluster 110 includes host 111 and host 112. Host 111 and host 112 belong to different fault domains.
[0128] The resource management system 120 establishes a communication connection with each host, scheduling different gateway instances within the same anti-affinity group to hosts in different fault domains. It should be noted that... Figure 2The illustrated computer system architecture is merely an example; the types and number of devices within the system can be configured according to actual needs, and this application embodiment does not limit this. For example, the computer system may also include more computing clusters 110, or the computer system may also include a resource pool providing computing resources. Figure 2 (Not shown in the image).
[0129] The following is combined Figure 2 The structure of each module in the resource management system 120 is introduced.
[0130] like Figure 2 As shown, the resource management system 120 includes a load balancer 121, a resource management module 122, an anti-affinity group creation module 123, and an instance creation module 124.
[0131] It is worth noting that the functions implemented by the load balancer 121, resource management module 122, anti-affinity group creation module 123, and instance creation module 124 can be completed by the cloud management platform 10 or other components of the cloud management platform 10, and this application does not limit their implementation methods.
[0132] The following provides an exemplary description of the connection relationships between the load balancer 121, the resource management module 122, the anti-affinity group creation module 123, and the instance creation module 124, as well as the functions implemented by each module.
[0133] The load balancer 121 establishes a communication connection with each host in the computing cluster 110. The resource management module 122 establishes communication connections with the load balancer 121, the instance creation module 124, the anti-affinity creation module, and each host in the computing cluster 110.
[0134] The following provides examples illustrating the deployment methods of load balancer 121, resource management module 122, anti-affinity group creation module 123, and instance creation module 124.
[0135] In the first optional deployment method, the load balancer 121, resource management module 122, anti-affinity group creation module 123, and instance creation module 124 can be deployed on the same device.
[0136] In the second optional deployment method, the load balancer 121, resource management module 122, anti-affinity group creation module 123, and instance creation module 124 can be deployed on different devices respectively.
[0137] For example, the load balancer 121, resource management module 122, anti-affinity group creation module 123, and instance creation module 124 can be deployed in different computing devices.
[0138] For example, the load balancer 121, resource management module 122, anti-affinity group creation module 123, and instance creation module 124 can be deployed in different virtual machines on the same computing device.
[0139] It should be noted that the two optional implementation methods mentioned above are merely different ways to deploy the load balancer 121, resource management module 122, anti-affinity group creation module 123, and instance creation module 124. In practical applications, the load balancer 121, resource management module 122, anti-affinity group creation module 123, and instance creation module 124 can also have other deployment methods. For example, the resource management module 122, anti-affinity group creation module 123, and instance creation module 124 can be deployed on device 1, while the load balancer 121 can be deployed on device 2, where device 1 and device 2 are different devices. This application does not impose any limitations on this.
[0140] The following describes the functions of each module in the resource management system 120.
[0141] Among them, the anti-affinity group creation module 123 is used to create anti-affinity groups in the cloud management platform.
[0142] Instance creation module 124 is used to create multiple gateway instances within an anti-affinity group.
[0143] Resource management module 122 is used to schedule different gateway instances within the anti-affinity group to hosts in different fault domains of computing cluster 110.
[0144] Load balancer 121 is used to distribute data streams to different gateway instances in a load-balanced manner.
[0145] It should be noted that, Figure 2 The accompanying drawings are merely illustrative and do not constitute a limitation on the instance scheduling method provided in the embodiments of this application. Figure 2 The naming and division of modules in the resource management system 120 shown are illustrative. In practical applications, the resource management system 120 may have other grouping methods, which are not limited in this application. Furthermore, the resource management system 120 may also be named a resource allocation device. This resource allocation device may include different... Figure 2 The module shown below, this resource allocation device can be used as a reference. Figure 13 The provided embodiments are not described in detail herein.
[0146] Next, combined Figures 3 to 8 This application describes the implementation of the resource allocation method provided.
[0147] Please see Figure 3 , Figure 3 Flowchart of the resource allocation method provided in the embodiments of this application Figure 1 The resource allocation method shown can be applied to... Figure 2 In the cloud management platform 10 shown, the resource allocation method is executed by the cloud management platform 10. This cloud management platform can be referred to as a cloud computing platform, management node, cloud platform side, etc. Alternatively, this resource allocation method can also be executed by the resource management system 120 in the cloud management platform 10.
[0148] Taking the resource allocation method provided in this application embodiment as an example, which is executed by the cloud management platform 10, such as... Figure 3 As shown, the resource allocation method includes steps S310 to S340.
[0149] S310, in response to the first request, cloud management platform 10 creates an anti-affinity group in cloud management platform 10.
[0150] Anti-affinity groups consist of multiple fault domains, and gateway instances deployed in different fault domains exhibit anti-affinity.
[0151] In the process corresponding to S310, client 20 sends a first request to cloud management platform 10. Cloud management platform 10 receives the first request sent by client 20.
[0152] In some feasible scenarios, the first request may also be sent to the cloud management platform 10 by another device. This other device may refer to a client, terminal, user equipment, server, or other types of devices.
[0153] In other feasible scenarios, the first request may also be sent to the cloud management platform 10 by an application deployed on one or more devices that are communicatively connected to the cloud platform. This application may include, but is not limited to, distributed training applications, cloud computing applications, video playback applications, live streaming applications, and game applications.
[0154] In other feasible scenarios, the first request may also be automatically generated by the cloud management platform 10. For example, the cloud management platform 10 may automatically trigger the generation of the first request when providing business services to the client 10. These business services include, but are not limited to, content generation services, cloud computing services, data computing services, and model training services.
[0155] The above three scenarios are merely alternative methods for different requests and should not be construed as limitations on the resource allocation method provided in this application.
[0156] The following provides an illustrative description of the contents included in the first request.
[0157] In one alternative implementation, the first request is used to provide the cloud management platform 10 with the requirement information to create an anti-affinity group.
[0158] For example, a user inputs the requirement information for creating an anti-affinity group through the display interface provided by the cloud management platform 10, generating a first request. The cloud management platform 10 receives the first request through this display interface. Specifically, the implementation method of the cloud management platform 10 receiving the first request based on the display interface can be referred to as follows. Figures 9 to 10 The embodiments provided are not described in detail here.
[0159] The following three specific examples illustrate the requirements for creating anti-affinity groups.
[0160] In the first optional instance, the first request includes: the target application type and the target Service Level Agreement (SLA), such as a remote dictionary server (Redis) and a load balancing service (Nginx). That is, the requirement information for creating the anti-affinity group includes the target application type and the target SLA.
[0161] Among them, the target application type is used to determine the maximum resource specification of the gateway instance in the anti-affinity group. For example, the cloud management platform 10 determines the resource specification of the gateway instance in the anti-affinity group based on the correspondence between the application type and the resource specification.
[0162] The target SLA is used to indicate the reliability of the anti-affinity in-group gateway instance. Understandably, the larger the target SLA, the higher the reliability of the corresponding anti-affinity in-group gateway instance.
[0163] In the second alternative example, the first request also includes: an anti-affinity group identifier and the fault domain level of the anti-affinity group. Accordingly, the requirement information for creating the anti-affinity group includes: the target application type, the target SLA, the anti-affinity group identifier, and the fault domain level of the anti-affinity group.
[0164] The anti-affinity group identifier is unique and is used to distinguish the unique and definite anti-affinity group in the cloud management platform 10. The specific form of the anti-affinity group identifier is not limited in this embodiment.
[0165] The fault domain level is used to indicate the level to which the fault domain of the anti-affinity group belongs. For example, the fault domain level can be the area level, availability zone level, unit level, or host level.
[0166] In the third optional instance, the first request also includes: the anti-affinity group identifier, the fault domain level of the anti-affinity group, and the required number of instances. Accordingly, the requirement information for creating the anti-affinity group includes: the target application type, the target SLA, the anti-affinity group identifier, the fault domain level of the anti-affinity group, the gateway instance specification, and the required number of instances.
[0167] The instance requirement refers to the total number of gateway instances that support association within the anti-affinity group.
[0168] The three optional implementation methods described above are merely alternative forms of the requirement information for creating an anti-affinity group when the first request includes different information. In practical applications, the requirement information for creating an anti-affinity group can take other forms, which are not limited in this embodiment.
[0169] In addition to the first request being used to provide demand information, in another optional implementation, the first request can also be used to request the creation of an anti-affinity group from the cloud management platform 10. For example, a user sends a first request to the cloud management platform 10 through client 20, and the cloud management platform 10 responds to the first request by providing an interface to client 20. The user inputs the demand information for the anti-affinity group based on the interface. The cloud management platform 10 creates the anti-affinity group based on the demand information input through the interface. Specifically, the cloud management platform 10 can refer to the following... Figure 9 The provided embodiments create anti-affinity groups. The embodiments described in this application will not be elaborated upon here.
[0170] S320, Cloud Management Platform 10 receives multiple instance creation requests.
[0171] Corresponding to the S320 process, client 20 sends multiple instance creation requests to cloud management platform 10. For example... Figure 3 As shown, the cloud management platform 10 obtains N instance creation requests: instance creation request 1, instance creation request 2, ..., instance creation request N, where N is an integer greater than 2.
[0172] In one optional implementation, the multiple instance creation requests can be any number of instance creation requests within an instance creation data stream. The instance creation data stream, also referred to as a data stream, includes multiple instance creation requests. Each instance creation request requests the cloud management platform 10 to create a gateway instance, and each instance creation request carries the number of gateway instances to be created. Different instance creation requests carry the number of gateway instances to be created.
[0173] In this application, the number of gateway instances specified in the creation request is not specifically limited. For example, if the instance creation request includes a request to create one gateway instance, then one instance creation request is used to create one gateway instance within the anti-affinity group. As another example, if the instance creation request includes a request to create at least two gateway instances, then one instance creation request is used to create at least two gateway instances within the anti-affinity group.
[0174] The following three specific examples illustrate instance creation requests.
[0175] In the first optional example, multiple instance creation requests originate from an instance creation data stream sent by the same device. This setting can refer to a terminal, user device, server, or other type of device.
[0176] In the second alternative example, multiple instance creation requests originate from the same instance creation data stream sent by the same application.
[0177] For example, the application can be deployed on one or more devices that communicate with the cloud platform. This application can include, but is not limited to, cloud computing applications, artificial intelligence (AI) training applications, and data analysis applications.
[0178] In a third optional example, multiple instance creation requests originate from the instance creation data stream of the same task. This task could be a disaster recovery deployment task, a distributed storage task, a distributed AI training task, a gateway deployment task, etc. In this embodiment, the specific form of this task is not limited.
[0179] The three possible examples above are merely optional methods for multiple instance creation requests provided in the embodiments of this application, and should not be construed as limiting the resource allocation method provided in the embodiments of this application. Furthermore, in other situations, the instance creation data stream may also be referred to as a request sequence, data request stream, or other names, etc., and this is not limited in the embodiments of this application.
[0180] In another optional implementation, each instance creation request may also carry a group identifier and an instance identifier. The group identifier indicates the anti-affinity group to which the gateway instance is created. The instance identifier, similar to the anti-affinity group identifier, is unique and used to identify a unique gateway instance within the cloud platform.
[0181] In some optional examples, different instance creation requests carry the same group identifier, and different instance creation requests carry different instance identifiers. Alternatively, in other optional examples, at least two of the multiple instance creation requests carry different group identifiers, and different instance creation requests carry different instance identifiers.
[0182] In some alternative implementations, the instance creation request may also carry instance type information. This instance type information indicates the instance type of the gateway instance to be created.
[0183] In one alternative implementation, the gateway instance can be of the following types: cross-availability zone instance and non-cross-availability zone instance.
[0184] The following combination Figure 4Figures (a) and (b) in the text provide examples of cross-availability zone instances and non-cross-availability zone instances, respectively.
[0185] A cross-availability zone instance refers to a gateway instance whose multiple referral entities are located in multiple availability zones, and multiple gateway entities located in multiple availability zones.
[0186] For example, taking a gateway instance that includes two referral entities and two gateway entities as an example, such as... Figure 4 As shown in Figure (a), Gateway Instance 1 includes Gateway Entity 1-1, Gateway Entity 1-2, Referral Entity 1-1, and Referral Entity 1-2.
[0187] like Figure 4 As shown in Figure (a), gateway entity 1-1 and traffic referral entity 1-1 are located in availability zone 1, while gateway entity 1-2 and traffic referral entity 1-2 are located in availability zone 2.
[0188] A non-cross-availability zone instance refers to a gateway instance whose multiple referral entities are located in the same availability zone, and whose multiple gateway entities are located in the same availability zone. Furthermore, both the multiple referral entities and the multiple gateway entities reside within the same availability zone.
[0189] like Figure 4 As shown in Figure (b), with Figure 4 Compared to the deployment shown in Figure (a) in [the text], in [the text] Figure 4 In Figure (b), gateway entity 1-1 and referral entity 1-1 are located in availability zone 1, and referral entity 1-1 and referral entity 1-2 are also located in availability zone 1.
[0190] The above mainly uses the example of gateway instance types including cross-availability zone instances and non-cross-availability zone instances to illustrate the instance types of gateway instances. In other embodiments, the instance types may also include other forms. In this application embodiment, the specific form of the instance type of gateway instance is not limited.
[0191] S330, Cloud Management Platform 10 creates multiple gateway instances in the anti-affinity group based on multiple instance creation requests.
[0192] like Figure 3 As shown, the cloud management platform 10 creates S gateway instances in the anti-affinity group based on multiple instance creation requests: gateway instance 1, gateway instance 2, and gateway instance S. Here, S is greater than or equal to N, meaning the number of gateway instances created is greater than or equal to the number of instance creation requests received.
[0193] In one alternative implementation, an instance creation request can be used to create one or more gateway instances.
[0194] In the first example, the instance creation request includes a request to create one gateway instance. One instance creation request is used to create one gateway instance within the anti-affinity group; that is, one gateway instance corresponds to one instance creation request. Therefore, the number of gateway instances created is equal to the number of instance creation requests obtained. For example... Figure 3 As shown, gateway instance 1 corresponds to instance creation request 1, gateway instance 2 corresponds to instance creation request 2, and gateway instance S corresponds to instance creation request N.
[0195] In the second example, if the instance creation request includes multiple requests to create gateway instances, then one instance creation request is used to create multiple gateway instances within the anti-affinity group; that is, at least two gateway instances correspond to the same instance creation request. In this example, the number of gateway instances created is greater than the number of instance creation requests obtained.
[0196] The following example, using an instance creation request, illustrates how to create a gateway instance in an anti-affinity group.
[0197] In the first optional implementation, the instance creation request includes the number of gateway instances to be created. The cloud server side determines the number of gateway instances to be created based on the instance creation request and creates gateway instances that meet the required number in the anti-affinity group. Instance identifiers are assigned to the one or more created gateway instances, and these instance identifiers are associated with the anti-affinity group identifiers of the anti-affinity group. In this embodiment, the method of assigning instance identifiers to gateway instances is not limited; for example, instance identifiers can be randomly assigned. Alternatively, instance identifiers can be generated based on the time encoding of the created gateway instances.
[0198] In the second optional implementation, the instance creation request includes the number of instances to be created, a group identifier, and an instance identifier. The cloud management platform 10 determines, based on the instance creation request, the number of gateway instances to be created, the anti-affinity group indicated by the group identifier, and the instance identifiers of the one or more gateway instances to be created. The cloud management platform 10 creates gateway instances that meet the required number of instances and associates the instance identifier of each gateway instance with the group identifier.
[0199] In the third optional implementation, the instance creation request includes the number of gateway instances to be created, group identifier, instance identifier, and instance type information. Compared to the second optional implementation, in the third optional implementation, the cloud management platform 10 further marks the instance type of the created gateway instances based on the instance type information. Alternatively, the cloud management platform 10 further marks the instance type of the anti-affinity group based on the instance type information.
[0200] It is worth noting that in some cases, gateway instances belonging to the same anti-affinity group have the same instance type. Alternatively, in other cases, gateway instances belonging to the same anti-affinity group have different instance types.
[0201] The three optional implementation methods described above are merely different ways for the cloud management platform 10 to create multiple gateway instances in the anti-affinity group based on the instance creation request. In other embodiments, the cloud management platform 10 may also use other implementation methods to create gateway instances. This application does not limit this. For example, the cloud server generates instance creation guidance information based on the instance creation request. The instance creation guidance information includes the instance status of each fault domain in the anti-affinity group and the estimated instance creation result. After the client 20 confirms the instance creation request according to the instance creation guidance information, the cloud management platform 10 creates instances in the anti-affinity group based on the instance creation guidance information.
[0202] The instance status for each fault domain includes: the fault domain is associated with a gateway instance or the fault domain is not associated with a gateway instance. The estimated instance creation result includes: gateway instance creation successful or gateway instance creation failed.
[0203] S340, for the first gateway instance among multiple gateway instances, the cloud management platform 10 schedules the first gateway instance to the first cluster of the infrastructure.
[0204] The first gateway instance is any one of multiple gateway instances that needs to be scheduled. For example... Figure 3 As shown, the first gateway instance is gateway instance i, where i is a positive integer less than or equal to S.
[0205] The first cluster comprises M hosts from a set of multiple hosts, and the fault domain of the first cluster differs from the fault domains of other clusters with scheduled gateway instances. Here, M is an integer greater than or equal to 1, and M is less than the number of hosts in cluster 110. For example... Figure 3 As shown, the first cluster includes host 111 and host 112.
[0206] In one alternative implementation, the cloud management platform 10 initializes multiple clusters in the infrastructure. In another implementation that schedules the first gateway instance, the cloud management platform 10 identifies multiple candidate clusters from among the multiple clusters that do not yet have a gateway instance scheduled. The cloud management platform 10 selects a first cluster from the multiple candidate clusters. The cloud management platform 10 then schedules the first gateway instance into that first cluster.
[0207] In one optional implementation, as described above regarding the gateway instance, the gateway instance includes a referral entity and a gateway entity, and a corresponding cluster includes a gateway sub-cluster and a referral sub-cluster. The gateway sub-cluster provides the gateway entity for the gateway instance. The referral sub-cluster provides the referral entity for the gateway instance. In some optional implementations, the gateway sub-cluster may also be referred to as a gateway node cluster or a gateway cluster, and the referral sub-cluster may also be referred to as a referral cluster; this is not limited in the embodiments of this application.
[0208] Similarly, the first cluster includes a first gateway sub-cluster and a first referral sub-cluster. In the implementation of scheduling the first gateway instance to the first cluster, the cloud management platform 10 uses the first gateway sub-cluster in the first cluster as the first gateway entity in the first gateway instance, and uses the first referral sub-cluster in the first cluster as the first referral entity of the first gateway instance.
[0209] In one alternative implementation, "multiple candidate clusters without scheduled gateway instances" can refer to a cluster without scheduled gateway instances belonging to the same anti-affinity group as the first gateway instance. That is, the candidate cluster may have gateway instances belonging to other anti-affinity groups scheduled. Alternatively, "multiple candidate clusters without scheduled gateway instances" can also refer to a cluster without scheduled any gateway instances.
[0210] The above S340 describes the gateway instance scheduling process of the cloud management platform 10 using the first gateway instance as an example. In some optional schemes, the cloud management platform 10 can also schedule the second gateway instance to the second cluster of the infrastructure. The second gateway instance is one of the other gateway instances among multiple gateway instances besides the first gateway instance, and the second cluster is the cluster in the infrastructure of the cloud management platform 10 that matches the second gateway instance. The implementation method of the cloud management platform 10 scheduling the second gateway instance to the second cluster can refer to the scheduling process of the first gateway instance.
[0211] The following explains how the cloud management platform 10 initializes multiple clusters.
[0212] In one alternative implementation, the cloud management platform 10 can initialize multiple clusters in the infrastructure based on the fault domain level of the anti-affinity group. The number of clusters is the same as the number of fault domains included in the anti-affinity group.
[0213] For example, the fault domain level of the anti-affinity group is the availability zone level. The cloud management platform 10 groups hosts within the same availability zone in the infrastructure as a cluster, based on the availability zone to which the host belongs. Alternatively, the cloud management platform 10 deploys virtual machines on hosts within the same availability zone in the infrastructure, based on the availability zone to which the host belongs, thus forming a cluster of virtual machines deployed on hosts within the same availability zone.
[0214] For example, the fault level of the anti-affinity group is at the group level. The cloud management platform 10 groups hosts belonging to the same group in the infrastructure as a cluster based on the group to which the host belongs. Alternatively, the cloud management platform 10 deploys virtual machines on hosts belonging to the same group in the infrastructure based on the group to which the host belongs, thus forming a cluster of virtual machines deployed on hosts within the same group.
[0215] For example, the failure level of the anti-affinity group is at the host level. Cloud management platform 10 treats a host in the infrastructure as a cluster. Alternatively, cloud management platform 10 deploys one or more virtual machines on each host. One or more virtual machines deployed on a single host are treated as a cluster.
[0216] The above are merely different implementations of initializing the cluster based on the fault level of the anti-affinity group. In other embodiments, cluster initialization can also be implemented in other ways; for example, the cluster can be initialized based on the number of gateway instances and the fault level of the anti-affinity group. For another example, the cloud management platform 10 can also initialize the cluster based on the instance type of the anti-affinity group. This application does not limit the scope of these implementations.
[0217] The following describes how to initialize the cluster based on the number of gateway instances and the fault level of the anti-affinity group.
[0218] In one alternative implementation, the cloud management platform 10 initializes a cluster in the infrastructure that meets the number of gateway instances based on the fault domain level of the anti-affinity group.
[0219] For example, the fault domain level of the anti-affinity group is the availability zone level. The cloud management platform 10 selects candidate availability zones based on multiple availability zones in the infrastructure, ensuring a sufficient number of gateway instances. The cloud management platform 10 treats a candidate availability zone as a cluster. Alternatively, the cloud management platform 10 deploys virtual machines on hosts within a candidate availability zone, treating the virtual machines deployed on hosts within a candidate availability zone as a cluster.
[0220] For example, the fault level of the anti-affinity group is at the unit level. The cloud management platform 10 selects candidate units that meet the required number of gateway instances based on multiple units in the infrastructure. The cloud management platform 10 treats a candidate unit as a cluster. Alternatively, the cloud management platform 10 deploys virtual machines on the hosts of each candidate unit, treating all virtual machines deployed on all hosts in a candidate unit as a cluster.
[0221] For example, the failure level of the anti-affinity group is at the host level. The cloud management platform 10 selects candidate hosts based on multiple hosts in the infrastructure, ensuring a sufficient number of gateway instances are reached. The cloud management platform 10 treats a candidate host as a cluster. Alternatively, the cloud management platform 10 deploys one or more virtual machines on a candidate host, treating the one or more virtual machines deployed on a candidate host as a cluster.
[0222] The following provides an exemplary description of how to initialize a cluster based on an instance type of gateway instance.
[0223] In one optional implementation, the instance type of the anti-affinity group is cross-availability zone. The cloud management platform 10 initializes multiple clusters based on multiple units within the infrastructure.
[0224] For example, the cloud management platform 10 initializes multiple clusters based on multiple units in the infrastructure, referring to the above-described implementation method based on the fault domain level of anti-affinity groups. The embodiments in this application will not be elaborated upon here.
[0225] For example, the cloud management platform 10 can initialize multiple clusters based on multiple units in the infrastructure, referring to the above-described implementation method of initializing clusters based on the number of gateway instances and the fault level of anti-affinity groups. Further details of the embodiments in this application will not be elaborated upon here.
[0226] Additionally, in some optional scenarios, the instance type of the anti-affinity group can also be non-cross-availability zone. When the instance type of the anti-affinity group is non-cross-availability zone, the cloud management platform 10 can initialize the availability zone based on the fault level of the anti-affinity group.
[0227] For example, cloud management platform 10 initializes multiple clusters based on multiple units in the infrastructure. As another example, cloud management platform 10 initializes multiple clusters based on multiple availability zones in the infrastructure.
[0228] The above mainly describes the implementation method of initializing the cluster. The following describes the implementation method of selecting the first cluster.
[0229] In the first alternative implementation, the cloud management platform 10 can select any candidate cluster from the candidate clusters as the first cluster.
[0230] In the second alternative implementation, the cloud management platform 10 can select the first cluster from multiple candidate clusters based on the resource specifications of the first gateway instance.
[0231] The first cluster is a candidate cluster whose specifications meet the resource specifications of the first gateway instance. For example, the candidate clusters whose specifications are greater than or equal to the resource specifications of the first gateway instance are selected as the first cluster.
[0232] The gateway instance specifications can be set by the user. Alternatively, the gateway instance specifications can be configured by the cloud management platform 10 itself; however, this embodiment does not impose any limitations on this.
[0233] It should be noted that the two optional implementation methods mentioned above are only different ways to select the first cluster. In practical applications, other implementation methods can also be used. For example, if there is no candidate cluster among multiple candidate clusters that meets the resource specifications of the first gateway instance, the cloud management platform 10 can initialize a first cluster that meets the resource specifications of the first gateway instance from the cloud platform's resource pool. This is not limited in this embodiment.
[0234] In one alternative implementation, after scheduling the first gateway instance to the first cluster, the next first gateway instance is selected, and the above-mentioned S340 is executed to schedule the next gateway instance until all the gateway instances in the anti-affinity group are scheduled to the corresponding clusters.
[0235] It is worth noting that the execution order of S330 and S340 is not limited in this embodiment. For example, in some optional implementations, after the cloud management platform 10 creates multiple gateway instances within the anti-affinity group, it schedules these multiple gateway instances, i.e., executing them in the order of S330→S340. As another example, in some optional implementations, the cloud management platform 10 initializes multiple clusters based on the fault domain level of the anti-affinity group. In the implementation of creating gateway instances based on instance creation requests, the cloud management platform 10 schedules the gateway instance created based on one instance creation request to the cluster, and then creates a gateway instance based on the next instance creation request. That is, executing them in the order of S330→S340→S330.
[0236] The following uses the fault domain as an example to illustrate the concept of a generator set. Figure 5 The implementation method of the scheduling gateway instance is explained.
[0237] like Figure 5 As shown, Figure 5 This is a flowchart illustrating a scheduling gateway instance provided in an embodiment of this application. The process of this scheduling gateway instance includes stages ① to ③.
[0238] In phase ①, the cloud management platform 10 initializes cluster 1 in cluster 1 of the infrastructure and initializes cluster 2 in cluster 2. Cluster 1 is in fault domain 1, and cluster 2 is in fault domain 2.
[0239] Cluster 1 includes gateway sub-cluster 1 and traffic referral sub-cluster 1. Cluster 2 includes gateway sub-cluster 2 and traffic referral sub-cluster 2.
[0240] Phase 2: Cloud management platform 10 creates gateway instance 1 within the anti-affinity group. Gateway entity 1 of gateway instance 1 is located in gateway sub-cluster 1, and referral entity 1 of gateway instance 1 is located in referral sub-cluster 1.
[0241] Phase 3: Cloud management platform 10 creates gateway instance 2 within the anti-affinity group. Gateway entity 2 of gateway instance 2 is located in gateway sub-cluster 2, and referral entity 2 of gateway instance 2 is located in referral sub-cluster 2.
[0242] In phase ③, since gateway instance 1 has already been created in cluster 1 in phase ②, the cloud management platform 10 creates gateway instance 2 in cluster 2, which has not yet scheduled a gateway instance.
[0243] It is worth noting that, in Figure 5 In the provided embodiment, gateway instance 1 is scheduled to cluster 1. In other cases, cloud management platform 10 may also schedule gateway instance 1 to cluster 2. Accordingly, if gateway instance 1 is scheduled to cluster 2, cloud management platform 10 will schedule gateway instance 2 to cluster 1.
[0244] In addition, the above Figure 5 This example illustrates the concept using an anti-affinity group containing two gateway instances. In practical applications, the anti-affinity group can include more gateway instances, allowing the cloud management platform 10 to initialize more clusters. This is not a limitation in this embodiment.
[0245] based on Figure 3 The provided embodiment creates multiple gateway instances within an anti-affinity group and schedules the first gateway instance among these instances to a first cluster of the infrastructure, ensuring that the fault domain of the first cluster is different from the fault domains of other clusters with scheduled gateway instances. This ensures anti-affinity among gateway instances deployed in different fault domains, resulting in different blast radii for different gateway instances. Even if one gateway instance fails, the remaining gateway instances can continue to operate normally, thereby improving overall reliability. Furthermore, using an anti-affinity group to guarantee anti-affinity among multiple gateway instances eliminates the need for users to manually configure anti-affinity among multiple gateway instances, greatly simplifying the deployment of multiple gateway instances.
[0246] The following is an exemplary description of how the cloud management platform 10 responds to the first request and creates an anti-affinity group.
[0247] In one alternative implementation, to ensure high availability of the gateway, in step S310 above, the cloud management platform 10 can respond to the first request and obtain the requirement information for creating an anti-affinity group. Based on the requirement information, the cloud management platform 10 determines the creation guidance information for the anti-affinity group and creates the anti-affinity group accordingly. This ensures the reliability of the gateway instances within the anti-affinity group.
[0248] The creation guidance information includes the fault domain level of the anti-affinity group, the required number of instances, and the maximum resource specifications of the gateway instances. The maximum resource specifications of the gateway instances can be determined by the cloud management platform 10 based on the target application type. Alternatively, the maximum resource specifications of the gateway instances can be set by the user. This embodiment does not impose any limitations on this.
[0249] In one optional implementation, the requirement information includes the target application type and the target SLA. The cloud management platform 10 generates multiple candidate creation guidance messages based on the target application type. The cloud management platform 10 simulates candidate anti-affinity groups under different candidate creation guidance messages and obtains the SLA metrics for different candidate anti-affinity groups. Anti-affinity groups are created based on the candidate creation guidance messages corresponding to the candidate anti-affinity groups that meet the target SLA.
[0250] Among them, different candidate creation guidance information has different fault domain levels, and different candidate creation guidance information has different instance requirements.
[0251] Among them, a candidate anti-affinity group that meets the target SLA can be a candidate anti-affinity group whose SLA index is greater than or equal to the target SLA.
[0252] The following explains how to obtain SLA metrics.
[0253] The cloud management platform calculates SLA metrics for the fault domain level, instance requirement, and failure rate of the 10 candidate anti-affinity groups. The failure rate includes the failure rate of each fault domain within the candidate anti-affinity group.
[0254] Taking the creation guidance information of the candidate anti-affinity group as an example: the fault domain level is the unit level and the required number of instances is S. Therefore, the candidate anti-affinity group includes S fault domains, that is, S gateway instances are distributed in the S units corresponding to the anti-affinity group. If the fault rate of the fault domain is p, the SLA index of the candidate anti-affinity group can be calculated by the following formula (1).
[0255]
[0256] Where i is a positive integer greater than 1 and less than S.
[0257] For example, when the instance requirement S is 2 and the failure rate p is 99.9%, the SLA index of the candidate anti-affinity group can be obtained as 99.9999% by formula (1).
[0258] Additionally, in some optional scenarios, the required information includes: target application type, target SLA, anti-affinity group identifier, and fault domain level of the anti-affinity group. When the required information also includes the anti-affinity group identifier and the fault domain level of the anti-affinity group, the cloud management platform 10 can create the anti-affinity group using other implementation methods.
[0259] For example, in one alternative implementation, the cloud management platform 10 can obtain SLA metrics for different candidate instance requirement numbers based on the fault domain level of the anti-affinity group. It then selects the target candidate instance requirement number from multiple candidate instance requirement numbers to meet the target SLA. The cloud management platform 10 determines the maximum resource specification of the gateway instance based on the target application type. Based on the target candidate instance requirement number, the maximum resource specification, and the fault domain level of the anti-affinity group, the cloud management platform 10 generates creation guidance information. Based on the creation guidance information, the cloud management platform 10 creates an anti-affinity group and associates the anti-affinity group identifier with the created anti-affinity group.
[0260] The cloud management platform 10 can refer to the above formula (1) to obtain the SLA index under different candidate instance requirements, which will not be repeated here in this embodiment.
[0261] The following two specific examples illustrate the required number of target candidate instances.
[0262] In the first optional example, among the multiple candidate instance requirements, there exists a candidate instance requirement whose SLA metric satisfies the target SLA. The cloud management platform 10 uses this candidate instance requirement whose SLA metric satisfies the target SLA as the target candidate instance requirement.
[0263] In the second alternative example, among the multiple candidate instance requirements, there are multiple candidate instance requirements that meet the target SLA. The cloud management platform 10 uses the maximum value among the multiple candidate instance requirements that meet the target SLA as the target candidate instance requirement, thus utilizing a larger number of gateway instances to improve gateway reliability.
[0264] In the third alternative example, there are multiple candidate instance requirements that satisfy the target SLA. The cloud management platform 10 uses the minimum of these multiple candidate instance requirements as the target candidate instance requirement, thus ensuring gateway reliability using a smaller number of gateway instances.
[0265] The above three examples are merely optional methods for different target candidate instance requirements. In practical applications, there may be other methods, which are not limited in this application embodiment.
[0266] In addition, in some optional scenarios, the requirement information includes: target application type, target SLA, anti-affinity group identifier, fault domain level of the anti-affinity group, gateway instance specifications, and the required number of instances. When the requirement information also includes the required number of instances and gateway instance specifications, the cloud management platform 10 can obtain creation guidance information based on the fault domain level of the anti-affinity group, gateway instance specifications, and the required number of instances in the requirement information. The cloud management platform 10 creates the anti-affinity group based on the creation guidance information and associates the anti-affinity group identifier with the created anti-affinity group.
[0267] The above mainly describes different implementation methods of the cloud management platform 10 creating anti-affinity groups based on demand information. In other embodiments, the cloud management platform 10 may also create anti-affinity groups in other ways. This application does not limit these methods.
[0268] For example, cloud management platform 10 generates anti-affinity group calculation results based on the demand information provided in the first request. Cloud management platform 10 provides the anti-affinity group calculation results to client 20. The anti-affinity group calculation results include: SLA indicators.
[0269] After client 20 obtains the anti-affinity group calculation results, the user can modify the first request based on the calculation results. For example, the user can modify one or more of the fault domain level, gateway instance specifications, and instance requirement quantity in the first request. Cloud management platform 10 then recreates the anti-affinity group based on the requirement information indicated by the modified first request.
[0270] Alternatively, after client 20 obtains the anti-affinity group calculation result, the user enters a confirmation operation for the anti-affinity group calculation result. Cloud management platform 10 receives the confirmation operation for the anti-affinity group calculation result and creates an anti-affinity group according to the requirement information indicated in the first request.
[0271] In one alternative implementation, to ensure high availability of the gateway, after scheduling multiple gateway instances within the anti-affinity group to clusters in different fault domains, the multiple gateway instances belonging to the same anti-affinity group can operate in master-master mode or master-standby mode.
[0272] In the master-master mode, multiple data flows between client 20 and the cloud platform are handled by multiple gateway instances in the anti-affinity group. Furthermore, different gateway instances handle different data flows.
[0273] The primary / standby mode refers to the cloud management platform 10 dividing multiple gateway instances in the anti-affinity group into a primary gateway instance and a standby gateway instance. The primary gateway instance handles multiple data streams between the client 20 and the cloud platform. In the event of a failure of the primary gateway instance, the cloud management platform 10 switches the data stream transmission node from the primary gateway instance to the standby gateway instance.
[0274] The following combination Figures 6 to 7 The master-master mode and the master-standby mode are illustrated by examples respectively.
[0275] First, let's explain the master-master mode.
[0276] Please see Figure 6 , Figure 6 This is a schematic diagram of the master-master mode provided in an embodiment of this application. Anti-affinity group 1 includes gateway instance 1 and gateway instance 2. Gateway instance 1 is communicatively connected to load balancer 121 and virtual machine 1 in the VPC, respectively. Gateway instance 2 is also communicatively connected to load balancer 121 and virtual machine 1 in the VPC, respectively. Virtual machine 1 is used to process service 1. In some optional embodiments, gateway instance 1 may also be referred to as the first gateway instance, and gateway instance 2 may be referred to as the second gateway instance.
[0277] When the cloud management platform 10 receives multiple data streams from service 1, the cloud management platform 10 controls the load balancer 121 to schedule the multiple data streams to gateway instance 1 and gateway instance 2. Gateway instance 1 and gateway instance 2 then forward their respective received data streams to virtual machine 1. In this way, by using multiple gateway instances to forward data streams in parallel, the data stream forwarding efficiency can be improved.
[0278] like Figure 6 As shown in Figure (a), the data streams received by the cloud management platform 10 for service 1 include: data stream 1, data stream 2, data stream 3, and data stream 4. The load balancer 121 schedules data streams 1 and 2 to gateway instance 1, and schedules data streams 3 and 4 to gateway instance 2.
[0279] In one alternative implementation, load balancer 121 can obtain the hash value of each data stream according to a hash rule, and determine the gateway instance to forward the data stream based on the hash value. For example, load balancer 121 takes the remainder of the hash value of the data stream modulo 2. If the remainder is 0, gateway instance 1 is selected as the gateway instance to forward the data stream. If the remainder is 1, gateway instance 2 is selected as the gateway instance to forward the data stream.
[0280] In one optional implementation, load balancer 121 obtains the instance status of gateway instance 1 and gateway instance 2. The instance status includes normal or faulty. If load balancer 121 determines that the instance status of gateway instance 1 (or gateway instance 2) is faulty, load balancer 121 switches the gateway instance forwarding the data flow from gateway instance 1 and gateway instance 2 to gateway instance 2 (or gateway instance 1). In this way, by utilizing multiple gateway instances, when one gateway instance fails, it can automatically switch to another normal gateway instance, thereby ensuring high availability of the gateway.
[0281] It should be noted that, in this embodiment of the application, the load balancer 121 does not limit the acquisition of the instance status of gateway instance 1 and gateway instance 2. For example, the load balancer 121 may acquire the instance status of gateway instance 1 and gateway instance 2 in any of the following ways: heartbeat detection, active probing, passive probing, and port checking.
[0282] like Figure 6 As shown in Figure (b), the instance status of gateway instance 1 is faulty. The load balancer 121 switches the transmission node of data flow 1 and data flow 2 from gateway instance 1 to gateway instance 2. At this time, gateway instance 2 forwards data flow 1, data flow 2, data flow 3 and data flow 4.
[0283] In some alternative scenarios, if a failed gateway instance recovers, the load balancer 121 directs the data flow received according to the hash rule to the recovered gateway instance.
[0284] like Figure 6 As shown in Figure (c), when the instance status of gateway instance 1 is normal, load balancer 121 directs the received data streams 5 and 6 to gateway instance 1. At this time, gateway instance 2 forwards data streams 1, 2, 3, and 4, while gateway instance 1 forwards data streams 5 and 6.
[0285] In addition, in some alternative scenarios, if both gateway instance 1 and gateway instance 2 are in a faulty state, the cloud management platform 10 creates gateway instance 3 within anti-affinity group 1 based on the instance specifications of gateway instance 1 or gateway instance 2. Gateway instance 3 is then used as the transmission node for forwarding the data flow of service 1.
[0286] like Figure 6 As shown in Figure (d), the instance status of Gateway Instance 1 and Gateway Instance 2 is faulty. A new Gateway Instance 3 is added to Anti-Affinity Group 1. Load Balancer 121 switches the transmission node of Data Flow 1 and Data Flow 2 from Gateway Instance 1 to Gateway Instance 3. Load Balancer 121 switches the transmission node of Data Flow 3 and Data Flow 4 from Gateway Instance 2 to Gateway Instance 3.
[0287] based on Figure 6 The provided embodiments demonstrate that multiple gateway instances belonging to the same anti-affinity group operate in master-master mode, forwarding data streams in parallel, which improves data stream forwarding efficiency. Furthermore, when one gateway instance fails, it can automatically switch to another healthy gateway instance, thus ensuring high availability of the gateway.
[0288] Secondly, the primary / standby mode will be explained.
[0289] Please see Figure 7 , Figure 7 This is a schematic diagram illustrating the primary / standby mode provided in an embodiment of this application. Relative to... Figure 6 As shown in Figure (a) in the master-master mode, in the master-standby mode, when the cloud management platform 10 receives multiple data streams from service 1, the cloud management platform 10 controls the load balancer 121 to schedule the multiple data streams to the master gateway instance. The master gateway instance then transmits the data streams to virtual machine 1. In this way, redundant gateway instances are provided, improving the reliability of the gateway.
[0290] like Figure 7 As shown in Figure (a), gateway instance 1 is designated as the primary gateway instance, and gateway instance 2 as the backup gateway instance. The data streams received by the cloud management platform 10 for service 1 include: data stream 1, data stream 2, data stream 3, and data stream 4. The load balancer 121 schedules data streams 1, 2, 3, and 4 to gateway instance 1. In some alternative configurations, gateway instance 1 may also be referred to as the first gateway instance, and gateway instance 2 may be referred to as the second gateway instance.
[0291] In one optional implementation, load balancer 121 obtains the instance status of gateway instance 1 and gateway instance 2. If load balancer 121 determines that the instance status of gateway instance 1 is faulty, load balancer 121 switches the gateway instance forwarding the data flow from gateway instance 1 to gateway instance 2. Thus, by utilizing primary and backup gateway instances, automatic switchover to the backup gateway instance is possible when the primary gateway instance fails, thereby ensuring high availability of the gateway.
[0292] like Figure 7 As shown in Figure (b), gateway instance 1 is in a fault state, and the primary gateway instance is changed from gateway instance 1 to gateway instance 2, with gateway instance 1 serving as the backup gateway instance. Load balancer 121 switches the transmission nodes of data stream 1, data stream 3, and data stream 4 from gateway instance 1 to gateway instance 2.
[0293] based on Figure 7The provided embodiments demonstrate that when multiple gateway instances belonging to the same anti-affinity group operate in primary / standby mode, redundant gateway instances are provided to improve gateway reliability. In the event of a failure of the primary gateway instance, automatic switchover to the standby gateway instance is possible, thereby ensuring high availability of the gateway.
[0294] The above Figure 6 and Figure 7 This document primarily describes the switching methods for data flow transmission nodes in the master-master and master-standby modes of gateway instances within an anti-affinity group. In other embodiments, when the gateway instance type within the anti-affinity group is cross-availability zone, the first gateway instance and the second gateway instance within the anti-affinity group are both cross-availability zone instances. When the cloud management platform 10 switches the data flow transmission node from the first gateway instance to the second gateway instance, the switching is implemented according to the availability zone where the gateway entity and the referral entity in the first gateway instance are located.
[0295] The following provides an example of how to switch transmission nodes for data streams across availability zones.
[0296] In one alternative implementation, the first gateway instance includes multiple first gateway entities; different first gateway entities correspond to different availability zones. The second gateway instance includes multiple second gateway entities; different second gateway entities correspond to different availability zones.
[0297] Taking the first gateway instance as gateway instance 1 and the second gateway instance as gateway instance 2 as an example, as follows: Figure 8 As shown, Figure 8 This diagram illustrates the switching of transmission nodes for data streams across availability zones.
[0298] like Figure 8 As shown in Figure (a), fault domain 1 includes gateway sub-cluster 1 and referral sub-cluster 1. Fault domain 2 includes gateway sub-cluster 2 and referral sub-cluster 2. Gateway instance 1 includes gateway entity 1-1, gateway entity 1-2, referral entity 1-1, and referral entity 1-2. Gateway instance 2 includes gateway entity 2-1, gateway entity 2-2, referral entity 2-1, and referral entity 2-2.
[0299] Gateway entity 1-1, referral entity 1-1, gateway entity 2-1, and referral entity 2-1 are located in availability zone 1. Gateway entity 1-2, referral entity 1-2, gateway entity 2-2, and referral entity 2-2 are located in availability zone 2.
[0300] like Figure 8As shown in Figure (a), gateway instance 1 forwards data flow 1 and data flow 2 in service 1. Data flow 1 is forwarded by gateway entity 1-1 and referral entity 1-1 within availability zone 1. Data flow 2 is forwarded by gateway entity 1-2 and referral entity 1-2 within availability zone 2.
[0301] In one alternative implementation, if the first gateway instance fails, the cloud management platform 10 switches the data flow transmission node of the first gateway entity in the first availability zone to the second gateway entity in the first availability zone.
[0302] The first availability zone can be any availability zone where any first gateway entity in the first gateway instance is located.
[0303] like Figure 8 As shown in Figure (b), the instance status of gateway instance 1 is faulty. The cloud management platform 10 switches the transmission node of data flow 1 and data flow 2 from gateway instance 1 to gateway instance 2. Furthermore, data flow 1 is forwarded by gateway entity 2-1 and referral entity 2-1 within availability zone 1. Data flow 2 is forwarded by gateway entity 2-2 and referral entity 2-2 within availability zone 2.
[0304] based on Figure 8 In the provided embodiments, during the switching of transmission nodes for data flows across availability zones, data flows within the same availability zone are forwarded by the second gateway entity within that availability zone, without needing to circumvent availability zones. This shortens the transmission time of the data flow and reduces transmission latency.
[0305] The above Figures 3 to 8 This application's technical solution will be explained primarily from the perspective of the interaction between the cloud management platform 10 and the client 20. The following section will combine... Figures 9 to 12 An example of the interaction interface between the cloud management platform 10 and the client 20 is provided.
[0306] First, an example of the interactive interface for creating anti-affinity groups is provided.
[0307] In one alternative implementation, the cloud management platform 10 provides an anti-affinity group creation interface to the client 20. For example... Figure 9 As shown in Figure (a), the anti-affinity group creation interface displays an "Anti-affinity group creation" control. When the user clicks the "Anti-affinity group creation" control in the anti-affinity group creation interface, the client 20 sends a first request to the cloud management platform 10.
[0308] The cloud management platform responds to the first request and provides services such as... Figure 9 The first interface is shown in Figure (b). This first interface displays an anti-affinity group input box. Client 20 displays as shown... Figure 9As shown in Figure (b), the user inputs a first operation based on the anti-affinity group input box in the first interface. The cloud management platform 10 responds to the first operation by providing, for example... Figure 9 The second interface is shown in Figure (c). In this second interface, the anti-affinity group input box includes the anti-affinity group identifier: Group 1.
[0309] The user clicks the "Confirm Creation" control on the second interface to input a second operation. The cloud management platform 10 responds to this second operation by creating an anti-affinity group. If the cloud management platform 10 receives the user's input for the "Cancel Control" on the second interface, the cloud management platform 10 provides the following... Figure 9 The first interface is shown in Figure (b). Alternatively, the cloud management platform 10 provides, for example... Figure 9 The anti-affinity group creation interface is shown in Figure (a).
[0310] Taking the first operation as an example, the implementation of the first operation will be explained. Similarly, the implementation of the second operation can refer to the implementation of the first operation.
[0311] The first operation can be a contact-based operation, such as tapping, long-pressing, swiping, double-tapping, or clicking on controls in the interface. Alternatively, the first operation can be a contactless operation, such as gesture input, physical buttons, or voice input. Alternatively, the first operation can also be a typing operation, such as typing with a mouse or keyboard.
[0312] In another scenario, the anti-affinity group creation interface provided by the cloud management platform 10 may also include a requirement information input box, through which the user inputs the requirement information for creating the anti-affinity group. The client 20 then sends a first request to the cloud management platform 10 based on the user's input requirement information for creating the anti-affinity group.
[0313] Taking demand information as an anti-affinity group identifier as an example, this is different from the above. Figure 9 The provided anti-affinity group creation interface is in Figure 10 The anti-affinity group creation interface shown in Figure (a) also includes a requirements information input box. This requirements information input box includes the anti-affinity group identifier, which the user needs to input.
[0314] The user clicks the requirement information input box in the anti-affinity group creation interface and enters the requirement information, such as... Figure 10 As shown in Figure (b), the requirement information input box in the anti-affinity group creation interface includes the following: Anti-affinity group identifier: Group 1.
[0315] User click Figure 10In Figure (b), the "Anti-Affinity Group Creation" control in the anti-affinity group creation interface allows client 20 to send a first request to cloud management platform 10. Cloud management platform 10 then creates the anti-affinity group based on the requirement information carried in the first request.
[0316] Secondly, an example of the interactive interface for obtaining an instance creation request is provided.
[0317] In one alternative implementation, the second interface provides an anti-affinity group query box and query controls. (As described above...) Figure 9 Taking the second interface provided in Figure (c) as an example, as Figure 11A As shown in Figure (a), the second interface provides an anti-affinity group query box and query controls. The user inputs a third operation based on the anti-affinity group query box in the second interface.
[0318] In response to the third operation, the cloud management platform 10 fills the content entered in the third operation into the anti-affinity group query box, providing, for example... Figure 11A The third interface is shown in Figure (b). The anti-affinity group query box in the third interface includes group 1.
[0319] User click Figure 11A The fourth operation is input through the query control in the third interface shown in Figure (b). The cloud management platform 10 provides the number of instances in the anti-affinity group corresponding to the anti-affinity group identifier and the instance creation control. The user clicks the instance creation control to send an instance creation request to the cloud management platform 10.
[0320] The number of instances in an anti-affinity group includes the number of gateway instances associated with the anti-affinity group and the total number of gateway instances that the anti-affinity group supports associating with. The total number of gateway instances that an anti-affinity group supports associating with can also be referred to as the instance requirement.
[0321] For example, in response to the fourth operation, the cloud management platform 10 provides the query results page for group 1 on the third interface. Figure 11A As shown in Figure (c), the first row of the query results page for Group 1 displays "Name", "Number of Instances", and "Operation". The second row displays "Group 1", "1 / 2", "Add Instance" control, and "Delete" control. "1 / 2" indicates that the total number of gateway instances that can be associated within the anti-affinity group named Group 1 is 2, and the number of gateway instances associated with this anti-affinity group is 1. When the user clicks the "Add Instance" control, a request to create an instance is sent to the cloud management platform 10.
[0322] For example, cloud management platform 10 responds to the fourth operation, providing, for example... Figure 11AThe fourth interface is shown in Figure (d). This fourth interface includes: anti-affinity group identifier: group 1, instance quantity: 1 / 2, "Add Instance" control, and "Delete" control. When the user clicks the "Add Instance" control in the fourth interface to enter the fifth operation, the cloud management platform 10 responds to the fifth operation and obtains the instance creation request.
[0323] In an optional scenario, the cloud management platform 10 responds to the fifth operation by providing an instance creation interface, such as... Figure 11B As shown in Figure (a), the instance creation interface displays an "Instance Creation" control and an anti-affinity group identifier: Group 1. When the user clicks the "Instance Creation" control, client 20 sends a second request to cloud management platform 10.
[0324] In response to the second request, cloud management platform 10 provides, for example... Figure 11B The fifth interface is shown in Figure (b). This fifth interface includes: an anti-affinity group input box, an instance input box, a "Cancel" control, and an "OK" control. The anti-affinity group input box includes: Group 1.
[0325] The user inputs the sixth operation based on the fifth interface, and the cloud management platform 10 responds to the sixth operation by obtaining the instance creation request.
[0326] In another alternative scenario, the instance creation interface displays an anti-affinity group input box and an "Instance Creation" control. For example... Figure 11C As shown in Figure (a).
[0327] When a user clicks the anti-affinity group input box in the instance creation interface and enters an identifier, the cloud management platform 10 responds to this identifier input by providing, for example... Figure 11C The instance creation interface is shown in Figure (b). Figure 11C In the instance creation interface shown in Figure (b), the anti-affinity group input box includes: Group 1. The user clicks... Figure 11C In Figure (b), the "OK" control inputs the second sub-operation. Client 20 sends a second request to cloud management platform 10 based on the data content in the instance input box. Cloud management platform 10 responds to the second request by providing, for example... Figure 11B The fifth interface is shown in Figure (b).
[0328] The identification input operation can be data input or selection operation, and this application embodiment does not limit it.
[0329] Finally, the interactive interface for creating a gateway instance is described.
[0330] In one alternative implementation, the cloud management platform 10 responds to the first instance creation request among multiple instance creation requests, providing, for example... Figure 12The sixth interface shown. This sixth interface includes: creating an XX1 gateway instance, anti-affinity group identifier: group 1, instance identifier: XX1, and a "confirm" control.
[0331] When the user clicks the "Confirm" button to enter the seventh operation, the cloud management platform 10 responds by creating a first gateway instance XX1 within the anti-affinity group corresponding to group 1, and then associating the first gateway instance XX1 with group 1.
[0332] The above description primarily focuses on the interaction between the cloud management platform 10 and the client 20 to introduce the technical solutions provided in the embodiments of this application. It is understood that the cloud management platform 10 includes the corresponding hardware structures and / or software modules for executing various functions. Those skilled in the art will readily recognize that, based on the algorithm steps of the examples described in conjunction with the embodiments disclosed in this application, this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0333] This application embodiment can group the cloud management platform 10 into functional modules according to the above method example. For example, each functional group can correspond to a functional module, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the naming and grouping of modules in this application embodiment are illustrative and only represent one logical functional grouping. In actual implementation, there may be other grouping methods.
[0334] For example, the resource management system deployed in the cloud management platform 10 can also be named the resource allocation device. Figure 13 As shown, Figure 13 This is a schematic diagram of the structure of a resource allocation device provided in an embodiment of this application. The resource allocation device shown includes: a communication module 131, a processing module 132, and a storage module 133.
[0335] The communication module 131 is used to respond to the first request and to obtain multiple instance creation requests. For example, the communication module 131 performs the above... Figure 3 S310 and S320 in the example.
[0336] Processing module 132 is used to create an anti-affinity group corresponding to the first request, and to create multiple gateway instances in the anti-affinity group based on multiple instance creation requests; and to schedule the first gateway instance among the multiple gateway instances to the first cluster of the infrastructure. For example, processing module 132 performs the above... Figure 3 Steps S330 and S340 in the process.
[0337] Storage module 133 is used to store executable program code, as well as data from the resource allocation device during the resource allocation process, etc.
[0338] One gateway instance corresponds to one instance creation request; the anti-affinity group includes multiple fault domains, and gateway instances deployed in different fault domains have anti-affinity. The fault domain is an availability zone, host group, or host; the first cluster includes M hosts from multiple hosts, and the fault domain of the first cluster is different from the fault domain of other clusters with scheduled gateway instances.
[0339] The communication module 131, processing module 132, and storage module 133 can be implemented in software or in hardware. For example, the implementation of processing module 132 will be described below. Similarly, the implementation of communication module 131 and storage module 133 can refer to the implementation of processing module 132.
[0340] As an example of a software functional unit, processing module 132 may include code running on a computing instance. The computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Further, the aforementioned computing instance may be one or more. For example, processing module 132 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code may be distributed in the same region or in different regions. Further, the multiple hosts / virtual machines / containers used to run the code may be distributed in the same availability zone (AZ) or in different AZs, each AZ including one or more geographically proximate data centers. Typically, a region may include multiple AZs.
[0341] Similarly, multiple hosts / virtual machines / containers used to run this code can be distributed within the same Virtual Private Cloud (VPC) or across multiple VPCs. Typically, a VPC is set up within a region. Communication between two VPCs within the same region, as well as between VPCs in different regions, requires a communication gateway to be set up within each VPC to enable interconnection between VPCs.
[0342] As an example of a hardware functional unit, the processing module 132 may include at least one computing device, such as a server. Alternatively, the processing module 132 may also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be implemented using a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), generic array logic (GAL), or any combination thereof.
[0343] The processing module 132 includes multiple computing devices that can be distributed within the same region or in different regions. Similarly, the communication module 131 includes multiple computing devices that can be distributed within the same Availability Zone (AZ) or in different AZs. Likewise, the processing module 132 includes multiple computing devices that can be distributed within the same Virtual Private Cloud (VPC) or in multiple VPCs. These multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.
[0344] It should be noted that, in other embodiments, the processing module 132 can be used to execute any step in the resource allocation method. The communication module 131 can be used to execute any step in the resource allocation method. The storage module 133 can be used to execute any step in the resource allocation method. The communication module 131, processing module 132, and storage module 133 can all execute any step in the resource allocation method. The steps implemented by the communication module 131, processing module 132, and storage module 133 can be specified as needed. By implementing different steps in the resource allocation method through the communication module 131, processing module 132, and storage module 133, all functions of the resource allocation device 13 are realized.
[0345] This application also provides a computing device for performing the above-described resource allocation method.
[0346] In one example, the computing device may include, for example: Figure 13 The resource allocation device 13 shown includes a communication module 131, a processing module 132, and a storage module 133.
[0347] In another example, such as Figure 14 As shown, the computing device 14 includes a bus 142, a processor 144, a memory 146, and a communication interface 148. The processor 144, the memory 146, and the communication interface 148 communicate with each other via the bus 142. The computing device 14 can be a server or a terminal device. It should be understood that this application does not limit the number of processors 144 and memory 146 in the computing device 14.
[0348] Bus 142 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, Figure 14 The bus 142 may be represented by a single line, but this does not mean that there is only one bus or one type of bus. The bus 142 may include a path for transmitting information between various components of the computing device 14 (e.g., memory 146, processor 144, communication interface 148).
[0349] Processor 144 may include any one or more processors such as a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).
[0350] In this application, processor 144 can perform the above-described... Figure 3 The provided resource allocation method. For example, in response to a first request, an anti-affinity group comprising multiple fault domains is created in the cloud management platform. Multiple instance creation requests are obtained, and multiple gateway instances are created within the anti-affinity group based on these requests. The first gateway instance among the multiple gateway instances is scheduled to the first cluster of the infrastructure, ensuring that the fault domain of the first cluster is different from the fault domains of other clusters with scheduled gateway instances.
[0351] Memory 146 may include volatile memory, such as random access memory (RAM). Processor 144 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).
[0352] The memory 146 stores executable program code, and the processor 144 executes the executable program code to implement the functions of the aforementioned communication module 131, processing module 132, and storage module 133, thereby implementing the resource allocation method. That is, the memory 146 stores instructions for executing the resource allocation method.
[0353] The communication interface 148 uses transceiver modules such as, but not limited to, network interface cards and transceivers to enable communication between the computing device 14 and other devices or communication networks.
[0354] The resource allocation method disclosed in the above embodiments can be applied to or implemented by the processor 144. The processor 144 can be an integrated circuit chip with signal processing capabilities.
[0355] In implementation, each step of the above method can be completed by the integrated logic circuits in the hardware of the processor 144 or by instructions in software form. The processor 144 can be a general-purpose processor, including a CPU, a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete vacuum tubes or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this application can be directly embodied in the execution of the hardware decoding processor, or can be executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 146, and the processor 144 reads the information in memory 146 and completes the steps of the above method in combination with its hardware.
[0356] In one possible implementation, the processor 144 can also be used to execute a resource allocation method. For specific implementation, please refer to the embodiments provided by the above-described resource allocation method. The embodiments of this application will not be repeated here.
[0357] In this embodiment of the application, the chip system may be composed of chips or may include chips and other discrete devices.
[0358] This application also provides a computing device cluster 15 for performing the above-described resource allocation method.
[0359] In one example, the computing device cluster 15 may include, for example: Figure 13 The resource allocation device 13 shown includes a communication module 131, a processing module 132, and a storage module 133.
[0360] In another instance, such as Figure 15 As shown, the computing device cluster 15 includes at least one such Figure 14 The computing device 14 shown includes a bus 142, a processor 144, a memory 146, and a communication interface 148. The processor 144, the memory 146, and the communication interface 148 communicate with each other via the bus 142. The computing device 14 can be a server or a terminal device.
[0361] In one possible implementation, one or more computing devices in the computing device cluster 15 can be connected via a network. This network can be a wide area network (WAN), a local area network (LAN), or similar. Figure 16 One possible implementation is shown. For example... Figure 16 As shown, the two computing devices 14A and 14B are connected via a network. Specifically, they are connected to the network through communication interfaces in each computing device. In this type of possible implementation, the memory 146 in computing device 14A stores instructions for executing the functions of communication module 131. Meanwhile, the memory 146 in computing device 14B stores instructions for executing the functions of processing module 132 and storage module 133.
[0362] Figure 16 The connection method between the computing device clusters shown can take into account the resource allocation method provided in this application. During the resource allocation process, the creation of anti-affinity groups and the scheduling of gateway instances are involved, which requires processing a large amount of data. Therefore, it is considered that the functions implemented by the processing module 132 and the storage module 133 are executed by the computing device 14B, and the functions implemented by the communication module 131 are executed by the computing device 14A.
[0363] It should be understood that Figure 16The functions of the computing device 14A shown can also be performed by multiple computing devices 14. Similarly, the functions of the computing device 14B can also be performed by multiple computing devices 14.
[0364] This application also provides a computer program product containing instructions. The computer program product may be a software or program product containing instructions, capable of running on a computing device or stored on any usable medium. When the computer program product runs on at least one computing device, it causes the at least one computing device to perform the resource allocation method described above.
[0365] For example, when a computer program product is run on at least one computing device, it causes the at least one computing device to perform... Figure 3 The resource allocation method shown.
[0366] This application also provides a computer-readable storage medium. All or part of the processes in the above method embodiments can be implemented by a computer program instructing related hardware. This program can be stored in the computer-readable storage medium, and when executed, it can include the processes of the above method embodiments. The computer-readable storage medium can be a terminal of any of the foregoing embodiments, such as an internal storage unit including a data transmission end and / or a data receiving end, like a hard disk or memory of the terminal. The computer-readable storage medium can also be an external storage device of the terminal, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the terminal. Further, the computer-readable storage medium can include both the internal storage unit and the external storage device of the terminal. The computer-readable storage medium is used to store the computer program and other programs and data required by the terminal. The computer-readable storage medium can also be used to temporarily store data that has been output or will be output.
[0367] It should be noted that the terms "first" and "second," etc., in the specification, claims, and drawings of this application are used to distinguish different objects, not to describe a specific order. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or apparatuses.
[0368] It should be understood that in this application, "at least one (item)" means one or more, "more than one" means two or more, "at least two (items)" means two or three or more, and "and / or" is used to describe the relationship between related objects, indicating that there can be three relationships. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the related objects before and after are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.
[0369] It should be understood that in the embodiments of this application, "B corresponding to A" means that B is associated with A. For example, B can be determined based on A. It should also be understood that determining B based on A does not mean that B is determined solely based on A; B can also be determined based on A and / or other information. Furthermore, the term "connection" in the embodiments of this application refers to various connection methods, such as direct connection or indirect connection, to achieve communication between devices, and the embodiments of this application do not impose any limitations on this.
[0370] Unless otherwise specified, the term "transmission" in the embodiments of this application refers to bidirectional transmission, encompassing the actions of sending and / or receiving. Specifically, "transmission" in the embodiments of this application includes sending data, receiving data, or both sending and receiving data. In other words, data transmission here includes uplink and / or downlink data transmission. Data may include channels and / or signals; uplink data transmission refers to uplink channel and / or uplink signal transmission, and downlink data transmission refers to downlink channel and / or downlink signal transmission.
[0371] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.
Claims
1. A resource allocation method, characterized by, The method is applied to a cloud management platform, which manages infrastructure, including multiple hosts; the method includes: In response to the first request, an anti-affinity group is created in the cloud management platform; the anti-affinity group includes multiple fault domains, and gateway instances deployed in different fault domains have anti-affinity. The fault domains included in the anti-affinity group are related to the instance types within the anti-affinity group; the instance types include: cross-availability zone instances and non-cross-availability zone instances; The cross-availability zone instance is used to indicate that multiple nodes in the first cluster are in at least two availability zones; The instance that does not cross availability zones is used to indicate that all nodes in the first cluster are in the same availability zone; In the case where the instance type is a cross-availability zone instance, the fault domain included in the anti-affinity group is the host group; When the instance type is a non-availability zone instance, the fault domain included in the anti-affinity group is an availability zone or a host group; Get multiple instance creation requests; Based on the multiple instance creation requests, multiple gateway instances are created in the anti-affinity group; wherein, one gateway instance corresponds to one instance creation request; For the first gateway instance among the plurality of gateway instances, the first gateway instance is scheduled to the first cluster of the infrastructure; the first cluster includes M hosts among a plurality of hosts, and the fault domain of the first cluster is different from the fault domain of other clusters with scheduled gateway instances.
2. The method of claim 1, wherein, The step of creating an anti-affinity group in the cloud management platform in response to the first request includes: In response to the first request, a first interface is provided, the first interface including: an anti-affinity group identifier input box; In response to a first operation on the first interface, a second interface is provided; in the second interface, the anti-affinity group identifier input box includes an anti-affinity group identifier; In response to a second operation on the second interface, the anti-affinity group is created.
3. The method of claim 2, wherein, The second interface also includes: an anti-affinity group query box; The process of obtaining multiple instance creation requests includes: In response to a third operation on the second interface, a third interface is provided; in the third interface, the anti-affinity group query box includes the anti-affinity group identifier; In response to a fourth operation on the third interface, a fourth interface is provided; the fourth interface includes: the anti-affinity group identifier, the number of instances of the anti-affinity group corresponding to the anti-affinity group identifier, and instance operation function controls; the number of instances includes the number of gateway instances associated with the anti-affinity group and the total number of gateway instances that the anti-affinity group supports associating with; the instance operation function controls are used to create instances within the anti-affinity group; In response to the fifth operation on the fourth interface, an instance creation request is obtained.
4. The method according to any one of claims 1 to 3, characterized in that, The process of obtaining multiple instance creation requests includes: Obtain a second request; the second request carries an anti-affinity group identifier; In response to the second request, a fifth interface is provided; the fifth interface includes an anti-affinity group input box and an instance input box; the anti-affinity group input box includes the anti-affinity group identifier; In response to the sixth operation on the fifth interface, an instance creation request is obtained; the instance creation request carries the anti-affinity group identifier.
5. The method according to any one of claims 1 to 3, characterized in that, Each instance creation request carries the anti-affinity group identifier of the aforementioned anti-affinity group; The step of creating multiple gateway instances in the anti-affinity group based on the multiple instance creation requests includes: For the first instance creation request among the plurality of instance creation requests, in response to the first instance creation request, a sixth interface is provided, the sixth interface including the anti-affinity group identifier and the first instance identifier carried by the first instance creation request; In response to the seventh operation on the sixth interface, a first gateway instance is created and associated with the anti-affinity group identifier.
6. The method according to any one of claims 1 to 3, characterized in that, The multiple gateway instances of the anti-affinity group operate in either master-master mode or master-standby mode. In the master-master mode, multiple data streams are processed by multiple gateway instances of the anti-affinity group; Different gateway instances handle different data streams; In the primary / backup mode, the data flow is processed by the first gateway instance. If the first gateway instance fails, the transmission node of the data flow is switched to the second gateway instance among the plurality of gateway instances. The second gateway instance is any one of the plurality of gateway instances other than the first gateway instance.
7. The method according to any one of claims 1 to 3, characterized in that, The first gateway instance is a cross-availability zone instance, and the second gateway instance is a cross-availability zone instance; the second gateway instance is any one of the plurality of gateway instances other than the first gateway instance; The first gateway instance includes multiple first gateway entities; different first gateway entities correspond to different availability zones; The second gateway instance includes multiple second gateway entities; different second gateway entities correspond to different availability zones; After scheduling the first gateway instance to the first cluster of the infrastructure, the method further includes: In the event of a failure of the first gateway instance, the data flow transmission node of the first gateway entity in the first availability zone will be switched to the second gateway entity located in the first availability zone.
8. The method according to any one of claims 1 to 3, characterized in that, The step of scheduling the first gateway instance to the first cluster of the infrastructure includes: Multiple clusters are initialized in the infrastructure; the number of clusters is the same as the number of fault domains included in the anti-affinity group. A first cluster is selected from multiple candidate clusters based on the resource specifications of the first gateway instance; the specifications of the first cluster match the resource specifications of the first gateway instance; the candidate clusters include clusters among the multiple clusters that have not scheduled gateway instances. Schedule the first gateway instance to the first cluster.
9. A resource allocation apparatus characterized by comprising: The device is deployed on a cloud management platform; The cloud management platform is used to manage infrastructure, which includes multiple hosts; the device includes: The communication module is used to respond to the first request and to obtain multiple instance creation requests; The processing module is configured to create an anti-affinity group corresponding to the first request, create a request based on the multiple instances, create multiple gateway instances in the anti-affinity group, and schedule the first gateway instance among the multiple gateway instances to the first cluster of the infrastructure. One gateway instance corresponds to one instance creation request; the anti-affinity group includes multiple fault domains, and gateway instances deployed in different fault domains have anti-affinity; the first cluster includes M hosts out of multiple hosts, and the fault domain where the first cluster is located is different from the fault domain where other clusters with scheduled gateway instances are located. The fault domains included in the anti-affinity group are related to the instance types within the anti-affinity group; the instance types include: cross-availability zone instances and non-cross-availability zone instances; The cross-availability zone instance is used to indicate that multiple nodes in the first cluster are in at least two availability zones; The instance that does not cross availability zones is used to indicate that all nodes in the first cluster are in the same availability zone; In the case where the instance type is a cross-availability zone instance, the fault domain included in the anti-affinity group is the host group; When the instance type is a non-availability zone instance, the fault domains included in the anti-affinity group are availability zones or host groups.
10. A cluster of computing devices, characterized in that, It includes at least one computing device, each computing device including a processor and memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the cluster of computing devices to perform the method as described in any one of claims 1 to 8.
11. A computer program product comprising instructions, characterized in that, When the instruction is executed by the computing device cluster, the computing device cluster performs the method as described in any one of claims 1 to 8.
Citation Information
Patent Citations
Anti-affinity scheduling method and device for creating cloud host and medium
CN115061823A