A method for communication between VPCs based on public cloud and related products
By creating a global VPC on the cloud management platform and assigning different network prefixes, the problem of communication between different VPCs is solved, enabling resource migration and bandwidth management, and improving communication quality and business deployment flexibility.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- HUAWEI CLOUD COMPUTING TECHNOLOGIES CO LTD
- Filing Date
- 2022-05-30
- Publication Date
- 2026-05-12
AI Technical Summary
The inability to communicate between different VPCs due to overlapping private addresses means that existing methods require tenants to manage private addresses and cannot achieve resource migration and bandwidth guarantee.
Create a global VPC through the cloud management platform, assign different network prefixes to each regional VPC, establish network connections and manage routes to achieve cross-regional communication, and perform resource migration and bandwidth management through the global VPC.
It enables communication between different VPCs, supports resource migration and unified network address management, reduces manual workload, and ensures communication bandwidth and security.
Smart Images

Figure CN117201574B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of cloud computing technology, and in particular to a communication method and related products between virtual private clouds (VPCs) based on public clouds. Background Technology
[0002] A Virtual Private Cloud (VPC) is a virtual network environment created by tenants. It supports tenant self-configuration and management and has many advantages such as security and reliability, thus gaining widespread use. In practical applications, there is a need for communication between different VPCs. However, due to reasons such as private address planning, there may be overlap in private addresses between VPCs that need to communicate, which can prevent these VPCs from communicating with each other.
[0003] Currently, the following two methods are mainly used to achieve communication between VPCs with the same private address: ① Creating VPC peering connections between the VPCs. ② Using a transit gateway to connect the different VPCs. Both methods require tenants to manage the private addresses of the VPCs, and resources within the VPCs cannot be migrated between them, nor is there a guarantee of bandwidth for communication between VPCs.
[0004] Therefore, how to achieve communication between VPCs remains an urgent problem to be solved in the current cloud computing technology field. Summary of the Invention
[0005] This application provides a communication method and related products between VPCs based on public cloud, which can realize communication between different VPCs. On this basis, it can also guarantee the bandwidth when different VPCs communicate, and the resources in different VPCs can be migrated to each other as needed. In addition, it can realize the unified management of VPC network addresses and routes, reducing the workload of manual work.
[0006] Firstly, embodiments of this application provide a communication method between VPCs based on a public cloud. This method includes the following steps: a cloud management platform determines first configuration information input or selected by a tenant, and creates a global VPC based on the first configuration information; the cloud management platform determines second configuration information input or selected by the tenant, and assigns a first network prefix to a first VPC located in a first region based on the second configuration information through the global VPC, and assigns a second network prefix to a second VPC located in a second region through the global VPC. The global VPC is used to achieve cross-regional communication between the first VPC and the second VPC based on the first and second network prefixes. It can be seen that by implementing the above method, the first VPC and the second VPC have different network prefixes, thereby enabling communication between the first VPC and the second VPC.
[0007] In one possible implementation of the first aspect, the region identifier in the first network prefix is different from the region identifier in the second network prefix. The region identifier in the first network prefix identifies the first VPC, and the region identifier in the second network prefix identifies the second VPC. This difference in the first and second network prefixes enables communication between the first and second VPCs.
[0008] In one possible implementation of the first aspect, the method further includes: the cloud management platform assigning a network prefix to the global VPC, wherein the first network prefix and the second network prefix also include the network prefix of the global VPC.
[0009] In one possible implementation of the first aspect, the method further includes: the cloud management platform establishing a network connection between the first VPC and the global VPC, and a network connection between the second VPC and the global VPC. It should be understood that establishing a network connection between the first VPC and the global VPC enables communication between them; similarly, establishing a network connection between the second network prefix and the global VPC enables communication between them. Thus, the first VPC and the second VPC can communicate through the global VPC.
[0010] In one possible implementation of the first aspect, the global VPC stores a first network prefix, a second network prefix, and the routing relationship between the first and second network prefixes. Thus, the global VPC can be used to automatically manage the network addresses of the first and second VPCs, as well as the routing between them.
[0011] In one possible implementation of the first aspect, the first VPC does not support communication with the third VPC. This ensures that the first and third VPCs are isolated from each other, improving the security of services deployed in both the first and third VPCs.
[0012] In one possible implementation of the first aspect, the method further includes: the cloud management platform setting an access control list (ACL) for the first VPC, wherein the ACL includes entries for blocking communication between the first VPC and the third VPC. In this way, the first VPC cannot receive data streams from the third VPC, nor can it send data streams to the third VPC, thereby achieving isolation between the first VPC and the third VPC.
[0013] In one possible implementation of the first aspect, the first VPC includes a first subnet, and the method further includes: the cloud management platform assigns a network prefix to the first subnet through the global VPC, wherein the network prefix of the first subnet includes a first network prefix and a subnet identifier. In this way, the network addresses of the subnets in the first VPC can be managed by the global VPC.
[0014] In one possible implementation of the first aspect, the first subnet includes virtual machines (VMs), and the method further includes: a cloud management platform assigning a network prefix to the VM through a global VPC or a first VPC, wherein the region identifier in the VM's network prefix is used to indicate that the VM supports migration to a VPC under the jurisdiction of the global VPC that can communicate with the first VPC. A VPC under the jurisdiction of the global VPC that can communicate with the first VPC refers to a VPC whose network prefix is assigned by the global VPC and which can communicate with the first VPC through the global VPC.
[0015] In one possible implementation of the first aspect, the region identifier in the network prefix of the aforementioned VM is different from the region identifier in the network prefix of any VPC under the jurisdiction of the global VPC.
[0016] In one possible implementation of the first aspect, the VPC under the jurisdiction of the global VPC that can communicate with the first VPC includes the second VPC. The method further includes: the cloud management platform migrates the VM from the first VPC to the second VPC, wherein the migrated VM is located in the second subnet of the second VPC, and the subnet identifier in the network prefix of the second subnet is the same as the subnet identifier in the network prefix of the first subnet.
[0017] In one possible implementation of the first aspect, the network prefix of the migrated VM is the same as the network prefix of the VM before migration.
[0018] Through the above implementation method, VMs in the first VPC can be migrated to other VPCs across regions, improving the flexibility of business deployment.
[0019] In one possible implementation of the first aspect, the method further includes: the cloud management platform allocating bandwidth to the global VPC, wherein the data flow passing through the global VPC meets the bandwidth requirements.
[0020] In one possible implementation of the first aspect, the method further includes: the cloud management platform assigns a corresponding flow label to the data flow passing through the global VPC based on the identifier of the global VPC, then obtains the bandwidth requirement based on the flow label, and then instructs the forwarding of the data flow based on the bandwidth requirement.
[0021] It should be understood that communication between the first VPC and the second VPC needs to go through the global VPC. Therefore, when the data flow through the global VPC can meet the above bandwidth requirements, the communication between the first VPC and the second VPC can also meet the above bandwidth requirements, thereby improving the quality of communication between the first VPC and the second VPC.
[0022] In one possible implementation of the first aspect, the network prefix of the global VPC is either an IPv6 prefix obtained by the cloud management platform, an IPv6 prefix generated by the cloud management platform, or an IPv6 prefix obtained by the tenant.
[0023] Secondly, embodiments of this application provide a cloud management platform, which includes a determination module and a control module. The determination module is used to determine first configuration information and second configuration information input or selected by a tenant; the control module is used to create a global VPC based on the first configuration information, and to assign a first network prefix to a first VPC located in a first region and a second network prefix to a second VPC located in a second region based on the second configuration information via the global VPC. The global VPC is used to enable cross-regional communication between the first VPC and the second VPC based on the first and second network prefixes.
[0024] In one possible implementation of the second aspect, the region identifier in the first network prefix is different from the region identifier in the second network prefix. Specifically, the region identifier in the first network prefix identifies the first VPC, and the region identifier in the second network prefix identifies the second VPC.
[0025] In one possible implementation of the second aspect, the control module is further configured to assign a network prefix to the global VPC, wherein the first network prefix and the second network prefix also include the network prefix of the global VPC.
[0026] In one possible implementation of the second aspect, the above-mentioned apparatus further includes a network configuration module for establishing network connections between the first VPC and the global VPC, and between the second VPC and the global VPC.
[0027] In one possible implementation of the second aspect, the aforementioned global VPC stores a first network prefix, a second network prefix, and the routing relationship between the first network prefix and the second network prefix.
[0028] In one possible implementation of the second aspect, the first VPC does not support communication with the third VPC.
[0029] In one possible implementation of the second aspect, the network configuration module is further configured to set the ACL of the first VPC, wherein the ACL includes entries for blocking communication between the first VPC and the third VPC.
[0030] In one possible implementation of the second aspect, the first VPC includes a first subnet, and the aforementioned control module is further configured to assign a network prefix to the first subnet through the global VPC, wherein the network prefix of the first subnet includes a first network prefix and a subnet identifier.
[0031] In one possible implementation of the second aspect, the first subnet includes VMs, and the control module is further configured to assign a network prefix to the VMs via a global VPC or a first VPC, wherein the region identifier in the network prefix of the VMs is used to indicate that the VMs support migration to a VPC under the jurisdiction of the global VPC that can communicate with the first VPC. A VPC under the jurisdiction of the global VPC that can communicate with the first VPC refers to a VPC whose network prefix is assigned by the global VPC and which can communicate with the first VPC through the global VPC.
[0032] In one possible implementation of the second aspect, the region identifier in the network prefix of the aforementioned VM is different from the region identifier in the network prefix of any VPC under the global VPC.
[0033] In one possible implementation of the second aspect, the VPC under the jurisdiction of the global VPC that can communicate with the first VPC includes the second VPC. The control module is further configured to migrate the VM from the first VPC to the second VPC, wherein the migrated VM is located in the second subnet of the second VPC, and the subnet identifier in the network prefix of the second subnet is the same as the subnet identifier in the network prefix of the first subnet.
[0034] In one possible implementation of the second aspect, the network prefix of the migrated VM is the same as the network prefix of the VM before migration.
[0035] In one possible implementation of the second aspect, the control module is further configured to allocate bandwidth to the global VPC, wherein the data flow passing through the global VPC meets the bandwidth requirements.
[0036] In one possible implementation of the second aspect, the control module is further configured to attach a corresponding flow label to the data flow passing through the global VPC based on the identifier of the global VPC, obtain the bandwidth requirement based on the flow label, and instruct the forwarding of the data flow based on the bandwidth requirement.
[0037] In one possible implementation of the second aspect, the network prefix of the global VPC is either an IPv6 prefix obtained by the cloud management platform, an IPv6 prefix generated by the cloud management platform, or an IPv6 prefix obtained by the tenant.
[0038] Thirdly, embodiments of this application provide a communication system, which includes the cloud management platform described in the first aspect and any implementation thereof, and further includes a global VPC, a first VPC located in a first region, and a second VPC located in a second region.
[0039] Fourthly, embodiments of this application provide a computing device including a processor and a memory, wherein the processor executes computer program code in the memory to implement some or all of the methods described in the first aspect and any implementation thereof.
[0040] Fifthly, embodiments of this application provide a computer-readable storage medium storing computer program code, which, when executed by a computing device, performs some or all of the methods described in the first aspect and any implementation thereof. Attached Figure Description
[0041] Figure 1 This is a schematic diagram of the structure of a communication system provided in an embodiment of this application;
[0042] Figure 2 This is a schematic diagram illustrating a deployment method of a cloud management platform provided in an embodiment of this application;
[0043] Figure 3 This is a schematic diagram illustrating an application scenario of a cloud management platform provided in an embodiment of this application;
[0044] Figure 4 This is a schematic diagram illustrating another application scenario of the cloud management platform provided in the embodiments of this application;
[0045] Figure 5 This is a schematic diagram illustrating a deployment method for a client capable of communicating with a cloud management platform, provided in an embodiment of this application.
[0046] Figure 6 This is a flowchart illustrating a communication method between VPCs based on a public cloud, provided in an embodiment of this application.
[0047] Figure 7 This is a schematic diagram of a global VPC creation interface provided in an embodiment of this application;
[0048] Figure 8 This is a schematic diagram of another global VPC creation interface provided in an embodiment of this application;
[0049] Figure 9 This is a schematic diagram of a first VPC creation interface provided in an embodiment of this application;
[0050] Figure 10 This is a schematic diagram of a resource creation interface provided in an embodiment of this application;
[0051] Figure 11 This is a schematic diagram illustrating the format of a network prefix for a resource provided in an embodiment of this application;
[0052] Figure 12 This is a schematic diagram illustrating the format of a network prefix for another resource provided in an embodiment of this application;
[0053] Figure 13 This is a flowchart illustrating a VM migration method provided in an embodiment of this application;
[0054] Figure 14 This is a schematic diagram of the structure of a cloud management platform provided in an embodiment of this application;
[0055] Figure 15 This is a schematic diagram of the structure of a computing device provided in an embodiment of this application;
[0056] Figure 16 This is a schematic diagram of a computing device system provided in an embodiment of this application. Detailed Implementation
[0057] To make the solutions provided in the embodiments of this application clearer, before specifically describing the solutions provided in the embodiments of this application, the relevant terms involved in the embodiments of this application will be introduced first.
[0058] A Virtual Private Cloud (VPC) is a private, isolated virtual network environment created by tenants in a public cloud. This means that different VPCs are logically isolated from each other. VPCs support tenant self-configuration and management. For example, tenants can create multiple subnets within a VPC. A subnet is a block of IP addresses within a VPC, dividing the network segment into several blocks. Subnetting helps tenants rationally plan IP address resources. Tenants can also deploy resources within subnets, including VMs, containers, and sandboxes, to provide cloud services. Furthermore, tenants can configure security groups and network ACLs within the VPC. Security groups provide access policies for cloud servers, cloud containers, cloud databases, and other instances within the VPC that have the same security protection requirements and trust each other. Network ACLs control the data flow into and out of subnets through multiple outbound and inbound rules associated with each subnet. Finally, tenants can customize routing tables to provide a basis for forwarding data flows within the VPC. In addition, VPC supports resource migration. Taking VM migration as an example, VM migration refers to moving a VM from one host machine to another, but it is required that the service cannot be interrupted during the migration process. To achieve this, it should be ensured that parameters such as the VM's Internet Protocol (IP) address and Media Access Control (MAC) address remain unchanged before and after the VM migration.
[0059] Because of the aforementioned features of VPCs, an increasing number of tenants are choosing to deploy the resources required for their business (including computing, storage, and network resources) on VPCs. Furthermore, to improve business security and timeliness, tenants can also choose to distribute the resources required for their business across multiple VPCs.
[0060] In practical applications, tenants may need to communicate with each other across multiple VPCs. For example, multinational corporations often have branches and operations distributed across multiple regions, so they typically deploy VPCs in multiple regions and want these VPCs to be able to communicate with each other. Another example is a company whose target audience is located in Region A. The company would deploy a corresponding VPC in Region A to provide cloud services to this audience. When this audience migrates from Region A to Region B, to save costs, the company would like to be able to directly migrate resources from the VPCs deployed in Region A to the VPCs deployed in Region B.
[0061] To address the aforementioned issues, this application provides a communication system. Figure 1 An exemplary schematic diagram of the above-mentioned communication system is shown, such as... Figure 1As shown, the communication system 100 includes a cloud management platform 110, a global VPC 120, multiple region VPCs 130, and multiple access points 140. The following is a brief description of each part of the communication system 100.
[0062] The cloud management platform 110 is used to confirm the configuration information entered or selected by the tenant, and also to create a global VPC 120 and multiple regional VPCs 130 based on the above configuration information. It should be noted that although both the global VPC 120 and the regional VPCs 130 are VPCs, their functions are not the same. The global VPC 120 is used to assign network prefixes to the regional VPCs 130 and their subnets. Different regional VPCs 130 can communicate with each other through the global VPC 120. The global VPC 120 also has network address management capabilities, capable of storing and managing the network prefixes of multiple regional VPCs 130, as well as the network prefixes of the subnets within each regional VPC 130. A Region VPC 130 is a VPC created by a tenant in a designated region based on business needs. Here, "region" refers to a collection of basic resources (including computing resources, storage resources, and network resources), such as a data center built by a cloud service provider. Therefore, tenants can deploy their businesses in Region VPC 130 and use the basic resources in Region VPC 130 to perform their businesses.
[0063] The cloud management platform 110 is also used to assign network prefixes to the global VPC 120, and to assign different network prefixes to multiple regional VPCs 130 through the global VPC 120. Each regional VPC 130's network prefix includes the global VPC 120's network prefix and the regional VPC 130's identifier (hereinafter referred to as the regional identifier). The regional identifier is different in the network prefixes of different regional VPCs 130. This ensures that the network prefixes of different regional VPCs 130 are different, facilitating communication between different regional VPCs 130.
[0064] Optionally, the cloud management platform 110 is also used to create multiple access points 140. These access points 140 may specifically include gateways (such as routers, switches, etc.) and gateway services (such as virtual machines or servers with gateway functionality). The multiple access points 140 are used to establish communication connections between the global VPC 120 and the multiple regional VPCs 130 through the network prefixes of the global VPC 120 and the network prefixes of the multiple regional VPCs 130, thereby enabling communication between the multiple regional VPCs 130.
[0065] Optionally, the cloud management platform 110 is also used to configure ACLs on the access point 140 for security protection of the regional VPC 130 connected to the access point 140. In some embodiments, the ACL includes at least one entry, and the access point 140 controls the data flow into and out of the regional VPC 130 through the at least one entry. For example, multiple regional VPCs 130 include a first VPC, a second VPC, and a third VPC, and multiple access points 140 include a first access point, a second access point, and a third access point. The first VPC is connected to the global VPC 120 through the first access point, the second VPC is connected to the global VPC 120 through the second access point, and the third VPC is connected to the global VPC 120 through the third access point. In this case, the first VPC, the second VPC, and the third VPC can communicate through the global VPC 120. In practical applications, tenants may want the first and second VPCs to communicate, while the first and third VPCs are isolated from each other. In this case, the cloud management platform 110 can configure an ACL on the first access point, which includes entries to block communication between the first and third VPCs. Thus, when the first access point receives a data stream from or sends a data stream to the third VPC, it can discard the data stream according to its local ACL, thereby blocking communication between the first and third VPCs. Similarly, the cloud management platform 110 can also configure an ACL on the third access point, which includes entries to block communication between the first and third VPCs. When the third access point receives a data stream from or sends a data stream to the first VPC, it can discard the data stream according to its local ACL, also blocking communication between the first and third VPCs.
[0066] Optionally, the cloud management platform 110 is also used to instruct the global VPC 120 to assign different network prefixes to subnets in multiple region VPCs 130. The network prefix of a subnet includes the network prefix of its region VPC 130 and a subnet identifier. The subnet identifier is used to identify the subnet; that is, different subnets within the same region VPC 130 have different subnet identifiers in their network prefixes.
[0067] Optionally, the cloud management platform 110 is also used to deploy resources (including VMs, containers, sandboxes, etc.) in subnets of multiple region VPCs 130, and to assign network prefixes to resources. The network prefix of a resource includes a region identifier, which indicates whether the resource supports migration from its own region VPC to other region VPCs. Thus, the cloud management platform 110 can determine whether a resource can be migrated from its own region VPC to other region VPCs based on its network prefix.
[0068] Optionally, the cloud management platform 110 is also used to allocate bandwidth to the global VPC 120, ensuring that data flows through the global VPC 120 are within the allocated bandwidth range. This guarantees bandwidth for communication between regional VPCs 130.
[0069] It is precisely because of the above-mentioned functions of the cloud management platform 110 that communication between different VPCs in multiple regional VPCs 130 is realized. Moreover, the device can also realize the automatic management of network addresses of multiple regional VPCs 130, and enable resources in different VPCs to migrate to each other according to actual business needs. In addition, it can also guarantee bandwidth during inter-VPC communication to provide tenants with higher quality cloud services.
[0070] In this embodiment of the application, the functions of the cloud management platform 110 can be implemented by software devices, hardware devices, or a combination of software devices and hardware devices.
[0071] The cloud management platform 110 is flexible in deployment, as it can be deployed in a cloud environment. A cloud environment is an entity that provides cloud services to tenants using basic resources under a cloud computing model. A cloud environment includes a cloud data center, which comprises a large amount of basic resources (including computing, storage, and network resources) owned by the cloud service provider. The computing resources in a cloud data center can include a large number of computing devices (such as servers). Therefore, the cloud management platform 110 can be one or more servers in a cloud data center, or it can be a software device deployed on servers or virtual machines in a cloud data center. This software device can be deployed distributedly on multiple servers, multiple VMs, or both servers and VMs.
[0072] like Figure 2As shown, the cloud management platform 110 is deployed by the cloud service provider in the cloud data center. The cloud service provider provides the functions provided by the cloud management platform 110 as cloud services to tenants. When using cloud services, tenants can register an account on the cloud management platform 110. After logging into the cloud management platform 110 with their account, they can send relevant configuration information to the cloud management platform 110. Then, the cloud management platform 110 will provide the corresponding cloud services to the tenants through cloud service provision points (including multiple basic resources in the cloud data center).
[0073] For example, such as Figure 3 As shown, after logging into the cloud management platform 110, the tenant sends configuration information to the cloud management platform 110. This configuration information includes relevant information (such as deployment regions) for deploying the global VPC 120 and regional VPCs 130 (including regional VPCs 1 to 6). Therefore, the cloud management platform 110 creates the global VPC 120 in region 0, regional VPC 1 in region 1, regional VPC 2 in region 2, regional VPC 3 in region 3, regional VPC 4 in region 4, regional VPC 5 in region 5, and regional VPC 6 in region 6. Regions 1, 2, and 3 are edge regions; regions 4 and 5 are central regions; and region 6 is a resource region. Edge regions are areas close to user terminals with fewer basic resources (including computing, storage, and network resources); central regions are areas close to areas with concentrated user terminals (such as Beijing, Shanghai, and Guangzhou) with abundant basic resources; and resource regions are areas with abundant basic resources (such as those with large data centers). The cloud management platform 110 also assigns a network prefix to the global VPC 120, and assigns different network prefixes to regional VPCs 1 through 6 through the global VPC 120. The configuration information also includes provisions for preventing communication between regional VPC 1 and other regional VPCs. Therefore, the cloud management platform 110 configures an ACL on the access point connected to regional VPC 1 to block communication between regional VPC 1 and other regional VPCs. Regional VPCs 2 through 6, however, can communicate with each other through the global VPC 120.
[0074] Furthermore, the aforementioned configuration information also includes deploying subnets and VMs within subnets in VPCs 1 through 6. Therefore, the cloud management platform 110 also deploys subnets and VMs within subnets in VPCs 1 through 6 and assigns network prefixes to the subnets and VMs within them. Since VPCs 2 through 6 can communicate across regions, VMs in VPCs 2 through 6 can migrate between them according to business needs. For example, VMs in VPC 2 can migrate to VPC 6 or VPC 3; VMs in VPC 4 can migrate to VPC 3 or VPC 5; and VMs in VPC 5 can migrate to VPC 6. In other words, tenant services can migrate between edge regions, central regions, and resource regions, or between edge regions, central regions, or resource regions. This not only improves the flexibility of business deployment but also addresses tenants' needs for performance, cost, and capacity. For example, when a VPC in a certain region is overloaded or lacks sufficient capacity, the cloud management platform 110 can migrate some of the services running on that VPC to other VPCs. Similarly, when a tenant's business needs change, such as wanting to create a new VPC (Region VPC 7) and run the services from Region VPC 2 on Region VPC 7, ... Figure 4 As shown, after the cloud management platform 110 creates region VPC 7, it can directly migrate services running on region VPC 2 to region VPC 7.
[0075] In addition, the cloud management platform 110 can allocate bandwidth to the global VPC 120 to ensure that the data flow passing through the global VPC 120 is always within an appropriate bandwidth range. It should be understood that since communication between region VPC 2 and region VPC 6 all requires passing through the global VPC 120, ensuring the bandwidth of the data flow passing through the global VPC 120 guarantees the bandwidth for communication between region VPCs, thereby reducing the difficulty of communication between region VPCs (including resource migration).
[0076] In a specific implementation, as one example, the cloud services provided by the cloud management platform 110 to tenants can be divided into two parts: VPC services and cross-region VPC communication services. VPC services refer to the services that tenants can deploy in the cloud within a region VPC 130 (such as the aforementioned region VPC 1 to region VPC 6), which can be provided to tenants free of charge. Cross-region VPC communication services refer to the communication services between region VPCs 130 located in different regions. This service can be provided to tenants free of charge, or it can be purchased by tenants (either on an annual or monthly subscription basis, or prepaid and settled based on the final resource usage) before being provided to them.
[0077] like Figure 5 As shown, when the cloud management platform 110 is set up in a cloud environment, clients that can communicate with the cloud management platform 110 can be deployed in an edge environment, such as applications provided by a cloud service provider that can communicate with the cloud management platform 110; they can also be deployed on terminal computing devices, such as browsers, to receive configuration information input by tenants; or they can be deployed partly in the edge environment and partly on terminal computing devices. The edge environment is an environment that includes a collection of edge computing devices located close to the terminal computing devices. Edge computing devices include edge servers, edge stations with computing power, etc., while terminal computing devices include terminal servers, smartphones, laptops, tablets, personal desktop computers, smart cameras, etc.
[0078] The following is combined Figure 6 The described inter-VPC communication method further illustrates how the aforementioned cloud management platform 110 enables communication between VPCs 130 in different regions. It should be noted that, for simplicity, this description will focus on the communication between the first and second VPCs among multiple regional VPCs 130.
[0079] S101: The cloud management platform 110 determines the configuration information A entered or selected by the tenant, and creates a global VPC 120 based on the configuration information A.
[0080] Specifically, the cloud management platform 110 provides a user interface (UI) or an application programming interface (API). Tenants send configuration information A to the cloud management platform 110 by operating on the UI or API (including inputting or selecting). After determining the configuration information A, the cloud management platform 110 creates a global VPC 120 based on the configuration information A.
[0081] Optionally, configuration information A includes bandwidth information for global VPC 120, specifically including at least one of maximum and minimum bandwidth, to ensure that data flows passing through global VPC 120 meet at least one of the following conditions: less than or equal to the maximum bandwidth, and greater than or equal to the minimum bandwidth. In addition, configuration information A may also include information such as the location and name of global VPC 120.
[0082] For example, Figure 7 This demonstrates a UI for creating a global VPC 120, such as... Figure 7 As shown, the interface includes multiple options such as "Name," "Region," and "Bandwidth." Following the on-screen prompts, the tenant enters the name of the global VPC 120 in the "Name" option, selects the geographical location for deploying the global VPC 120 in the "Region" option, and selects the minimum and maximum bandwidth in the "Bandwidth" option. Afterwards, if the tenant clicks the "Confirm" option, the cloud management platform 110 will receive configuration information A and create the global VPC 120 based on it; if the tenant clicks the "Cancel" option, the cloud management platform 110 will not receive configuration information A and will not create the global VPC 120.
[0083] S102: Cloud management platform 110 assigns a network prefix to global VPC 120.
[0084] The network prefix for global VPC 120 can be either an IPv4 or IPv6 network prefix. The following description of S102 will assume that the network prefix for global VPC 120 is an IPv6 network prefix. Specifically, cloud management platform 110 can assign a network prefix to global VPC 120 using any of the following methods:
[0085] Method 1: Configuration information A can also include the network prefix of the global VPC 120. Therefore, the network prefix of the global VPC 120 can also be specified by the tenant, for example, a global routing prefix applied for by the tenant from an IPv6 address management authority. In specific implementation, after receiving configuration information A, the cloud management platform 110 obtains the network prefix specified by the tenant for the global VPC 120 based on configuration information A, and uses the network prefix specified by the tenant as the network prefix of the global VPC 120.
[0086] Method 2: The cloud management platform 110 applies for a global routing prefix from the IPv6 address management authority, and then uses the obtained global routing prefix as the network prefix of the global VPC 120.
[0087] It should be noted that, generally, a global routing prefix applied for by a tenant from an IPv6 address management authority can only be used by that tenant. However, a global routing prefix applied for by a cloud management platform 110 (i.e., a cloud service provider) from an IPv6 address management authority can be provided to only one tenant, or, to save address resources, can be provided to multiple tenants. When a global routing prefix applied for by a cloud management platform 110 from an IPv6 address management authority needs to be provided to multiple tenants, in order to distinguish between different tenants, the cloud management platform 110 can add a tenant identifier to the network prefix of the global VPC 120. Specifically, the cloud management platform 110 can allocate a network prefix to the global VPC 120 through method 3.
[0088] Method 3: The cloud management platform 110 applies for a global routing prefix from the IPv6 address management authority, and then generates the global VPC 120 network prefix based on the obtained global routing prefix and tenant identifier. Optionally, the global VPC 120 network prefix includes the global routing prefix and tenant identifier.
[0089] The tenant identifier can be the tenant's ID or a number assigned to the tenant by the cloud management platform 110, or other information that can identify the tenant. This application embodiment does not limit the specific information.
[0090] Method 4: The cloud management platform 110 randomly generates a network prefix and uses the randomly generated network prefix as the global network prefix of VPC 120.
[0091] It should be noted that the global routing prefix obtained by the cloud management platform 110 or the tenant from the IPv6 address management authority can generally be directly routed on the Internet, while the network prefix randomly generated by the cloud management platform 110 generally cannot be directly routed on the Internet. In other words, compared to methods 1 to 3, if the cloud management platform 110 uses method 4 to assign a network prefix to the global VPC 120, then when the global VPC 120 or a certain regional VPC 130 needs to access the Internet, an additional network address translation (NAT) gateway needs to be deployed. Therefore, in practical applications, the cloud management platform 110 can choose an appropriate method to allocate a network prefix to the global VPC 120 according to the tenant's business needs. For example, when the global VPC 120 or a certain regional VPC 130 has a need to access the Internet, the cloud management platform 110 can use any of the methods 1 to 3 to allocate a network prefix to the global VPC 120. Conversely, when neither the global VPC 120 nor multiple regional VPCs 130 have a need to access the Internet, the cloud management platform 110 can use method 4 to allocate a network prefix to the global VPC 120.
[0092] In one possible implementation, the UI or API provided by the cloud management platform 110 for creating the global VPC 120 includes configuration information for the network prefix of the global VPC 120. This configuration information instructs the cloud management platform 110 to assign a network prefix to the global VPC 120 in an appropriate manner. For example, Figure 8 This demonstrates another UI for creating a global VPC, compared to... Figure 7 The interface shown Figure 8 The interface now includes a new "Network Prefix" option, which offers three configuration options: "Auto Configuration - Routable on the Internet," "Auto Configuration - Not Routable on the Internet," and "Manual Configuration." When a tenant selects the "Auto Configuration - Routable on the Internet" option, the cloud management platform 110 will assign a network prefix to the global VPC 120 using either method 2 or method 4. When a tenant selects the "Auto Configuration - Not Routable on the Internet" option, the cloud management platform 110 will assign a network prefix to the global VPC 120 using method 4. When a tenant selects the "Manual Configuration" option, the tenant must also enter the network prefix in the box following this option, allowing the cloud management platform 110 to assign a network prefix to the global VPC 120 using method 1.
[0093] It should be understood that when the network prefix of the global VPC 120 is the network prefix in the IPv4 address, the way the cloud management platform 110 assigns the network prefix to the global VPC 120 is similar to the methods 1 to 4 mentioned above. For the sake of simplicity, it will not be described in detail here.
[0094] S103: The cloud management platform 110 determines the configuration information B entered or selected by the tenant and creates the first VPC based on the configuration information B.
[0095] Specifically, the tenant sends configuration information B to the cloud management platform 110 by operating (including inputting or selecting) on the UI or API provided by the cloud management platform 110. After the cloud management platform 110 confirms the configuration information B, it creates the first VPC based on the configuration information B.
[0096] Optionally, configuration information B includes information such as the location and name of the first VPC. For example, Figure 9 This demonstrates a UI for creating a region VPC 130, such as... Figure 9As shown, the interface includes multiple options such as "Name" and "Region". Following the on-screen prompts, the tenant enters the name of the first VPC in the "Name" option and selects the geographical location for deploying the first VPC in the "Region" option. It should be understood that in practical applications, tenants can choose a suitable region to deploy the first VPC based on their business needs, which can reduce network latency, improve access speed, and thus improve cloud service quality. Afterwards, if the tenant clicks the "Confirm" option, the cloud management platform 110 will receive configuration information B and create the first VPC based on configuration information B; if the tenant clicks the "Cancel" option, the cloud management platform 110 can return to the previous menu (e.g., ...). Figure 7 or Figure 8 The UI shown is used to create a global VPC 120, so that the cloud management platform 110 will not receive configuration information B and will not create the first VPC.
[0097] S104: Cloud management platform 110 assigns a network prefix to the first VPC through global VPC 120.
[0098] The network prefix of the first VPC includes the network prefix of the global VPC 120 and the identifier of the first VPC (hereinafter referred to as the first area identifier). The first area identifier may be the number of the first VPC in multiple area VPCs 130, or the ID of the first VPC, or the identifier of the geographical location of the first VPC, etc., which can identify the first VPC. This application embodiment does not limit the information.
[0099] Specifically, after creating the first VPC, the cloud management platform 110 generates a first region identifier. Then, the cloud management platform 110 sends a first configuration command to the global VPC 120, whereby the first configuration command includes the first region identifier. Upon receiving the first configuration command, the global VPC 120 obtains the first region identifier based on the command, and then generates a network prefix for the first VPC based on the first region identifier and the network prefix of the global VPC 120. Finally, the cloud management platform 110 retrieves the network prefix of the first VPC from the global VPC 120 and assigns the retrieved network prefix to the first VPC.
[0100] Optionally, the network prefix of the first VPC may also include the tenant identifier mentioned above, and the first configuration command may also include the tenant identifier mentioned above.
[0101] Optionally, after generating the network prefix of the first VPC in global VPC 120, the network prefix of the first VPC is stored.
[0102] S105: The cloud management platform 110 establishes a network connection between the global VPC 120 and the first VPC based on the network prefix of the global VPC 120 and the network prefix of the first VPC.
[0103] Specifically, the cloud management platform 110 creates a first access point, which can be a gateway (such as a router or switch) or a gateway service (such as a virtual machine or server with gateway functionality). Then, the cloud management platform 110 configures the routing relationship between the network prefix of the global VPC 120 and the network prefix of the first VPC on the first access point. In this way, the global VPC 120 and the first VPC can establish a network connection based on the first access point.
[0104] In practical applications, to protect the security of service data on the first VPC, services deployed on the first VPC need to be isolated from services on the third VPC, or services deployed on the first VPC may not support access by one or more services deployed in the third VPC. Therefore, optionally, the cloud management platform 110 may also perform the following steps: Configure an ACL on the first access point, wherein the ACL includes at least one of the following entries: deny data flows from one or more services in the third VPC, and deny access to data flows sent to one or more services in the third VPC. The "deny data flows from one or more services in the third VPC" entry instructs the first access point to discard data flows received from one or more services in the third VPC, thus preventing access to services deployed on the first VPC from one or more services in the third VPC; the "deny access to data flows sent to one or more services in the third VPC" entry instructs the first access point to discard data flows received from the first VPC to one or more services in the third VPC, thus preventing access to one or more services in the third VPC by services in the first VPC.
[0105] It should be understood that when the ACL on the first access point includes rejecting data flows from all services in the third VPC and rejecting data flows sent to all services in the third VPC, the first VPC and the third VPC are isolated from each other, that is, they cannot communicate with each other.
[0106] S106: The cloud management platform 110 assigns network prefixes to subnets in the first VPC through the global VPC 120.
[0107] The first VPC includes at least one subnet. The number of subnets in the first VPC can be preset by the tenant; for example, configuration information B includes the number of subnets to be deployed in the first VPC. The number of subnets in the first VPC can also be dynamically adjusted by the cloud management platform 110 according to actual conditions. The number of subnets in the first VPC can also be preset by the cloud service provider (e.g., 256), which is not limited in this embodiment. The network prefix of each subnet includes the network prefix of the first VPC and the subnet identifier. The subnet identifier can be a number set by the cloud management platform 110 or the tenant for the subnet, or information that can identify the subnet, such as a subnet ID. Optionally, the network prefix of each subnet can also include the tenant identifier mentioned above.
[0108] In some embodiments, taking a subnet within a first VPC (the first subnet) as an example, the cloud management platform 110 assigns a network prefix to the subnet within the first VPC through the global VPC 120. This includes: the cloud management platform 110 sending a second configuration command to the global VPC 120, wherein the second configuration command includes the identifier of the first subnet (hereinafter referred to as the first subnet identifier). After receiving the second configuration command, the global VPC 120 obtains the first subnet identifier according to the second configuration command, and then generates a network prefix for the first subnet based on the first subnet identifier and the network prefix of the first VPC stored locally. Finally, the cloud management platform 110 obtains the network prefix of the first subnet from the global VPC 120 and assigns the obtained network prefix to the first subnet.
[0109] Optionally, after generating the network prefix of the subnet in the first VPC, the global VPC 120 stores the network prefix of the subnet in the first VPC.
[0110] S107: The cloud management platform 110 determines the configuration information C entered or selected by the tenant, creates resources in the first VPC according to the configuration information C, and assigns a network prefix to the resources.
[0111] The resources created by the cloud management platform 110 within the first VPC can include various types such as VMs, containers, and sandboxes. Configuration information C includes the resource deployment location, specifying which subnet within the first VPC the resource is deployed in. Further, the deployment location can be specified down to which host machine within that subnet. Configuration information C also includes resource migration attribute information, indicating whether the resource supports migration from the first VPC to a VPC under the jurisdiction of global VPC 120 that can communicate with the first VPC. A VPC under the jurisdiction of global VPC 120 refers to a VPC whose network prefix is allocated by global VPC 120, including the aforementioned multiple regional VPCs 130. A VPC under the jurisdiction of global VPC 120 that can communicate with the first VPC refers to a VPC whose network prefix is allocated by global VPC 120 and can communicate with the first VPC through global VPC 120, such as a second VPC. In addition, configuration information C may also include the resource type (e.g., VM, container, sandbox), resource memory size, and resource operating system.
[0112] The network prefix of a resource includes the network prefix of the global VPC 120, a region identifier, and a subnet identifier. Optionally, the network prefix of a resource may also include the tenant identifier described above. The region identifier in the resource's network prefix serves a different purpose than the region identifier in the network prefix of the first VPC described in S104 and the region identifier in the network prefix of the subnet within the first VPC described in S106. The region identifier in the resource's network prefix indicates whether the resource supports migration from the first VPC to a VPC under the jurisdiction of the global VPC 120 that can communicate with the first VPC. The subnet identifier in the resource's network prefix identifies the subnet where the resource is deployed; that is, the subnet identifier in the resource's network prefix is the same as the subnet identifier in the network prefix of the subnet where the resource is deployed.
[0113] Optionally, the representation information of resource migration attributes includes the region identifier in the resource's network prefix. Specifically, when a resource supports migration from a first VPC to a VPC under the jurisdiction of global VPC 120 that can communicate with the first VPC, the region identifier in the resource's network prefix is different from the region identifier in the network prefix of any VPC under the jurisdiction of global VPC 120. For example, assuming that the region identifiers in the network prefixes of multiple region VPCs 130 are 1 to N (N is a positive integer greater than 0), then the region identifier in the resource's network prefix can be any number different from 1 to N (such as 0). When a resource does not support migration from the first VPC to a VPC under the jurisdiction of global VPC 120 that can communicate with the first VPC, the region identifier in the resource's network prefix can be the first region identifier. It should be understood that, in addition to the region identifier, the representation information of resource migration attributes may also include other types of information, such as... Figure 8 The options shown are "Migrate across VPC" and "Migrate without crossing VPC".
[0114] In some embodiments, tenants can send configuration information C to the cloud management platform 110 by operating (including inputting or selecting) on the UI or API provided by the cloud management platform 110. Figure 10 An example UI for creating resources is shown, such as Figure 10 As shown, the interface includes several options such as "Name" and "Network Prefix". Tenants can enter the resource name in the input box after the "Name" option. The "Network Prefix" option has two configuration methods: "Manual Configuration" and "Automatic Configuration". When the tenant selects "Manual Configuration", they can enter the region identifier and subnet identifier in the corresponding address fields. The tenant can choose an appropriate region identifier based on business needs. For example, if the VM needs to be migrated from the first VPC to another VPC, the tenant can select region identifier 0; if the VM only needs to be migrated within the first VPC, the tenant can select the first region identifier. Tenants can also select an appropriate subnet identifier based on business needs, i.e., the identifier of the subnet where the VM will be deployed. When the tenant selects "Automatic Configuration", they need to select the identifier of the subnet where the VM will be deployed in the selection box after the "Deployment Location" option. Additionally, if the VM needs to be migrated from the first VPC to another VPC, the tenant can check the "Cross-VPC Migration" option; if the VM does not need to be migrated from the first VPC to another VPC, the tenant can check the "No Cross-VPC Migration" option. Afterwards, if the tenant clicks the "Confirm" option, the cloud management platform 110 will receive the configuration information C; if the tenant clicks the "Cancel" option, the cloud management platform 110 can return to the previous menu (e.g., ...). Figure 9 The UI shown is used to create the first VPC, so that the cloud management platform 110 will not receive configuration information C.
[0115] In some embodiments, the cloud management platform 110 allocates a network prefix to the created resource, including: the cloud management platform 110 obtains the deployment location of the resource and the representation information of the resource migration attributes based on the configuration information C input by the tenant. When the representation information of the resource migration attributes indicates that the resource supports migration from the first VPC to a VPC under the jurisdiction of the global VPC 120 that can communicate with the first VPC, the cloud management platform 110 allocates a network prefix to the resource through the global VPC 120; when the representation information of the resource migration attributes indicates that the resource does not support migration from the first VPC to a VPC under the jurisdiction of the global VPC 120 that can communicate with the first VPC, the cloud management platform 110 allocates a network prefix to the resource through the first VPC.
[0116] Furthermore, the cloud management platform 110 allocates network prefixes to resources through the global VPC 120. Specifically, the cloud management platform 110 sends a third configuration command to the global VPC 120, where the third configuration command includes the deployment location of the aforementioned resources. Upon receiving the third configuration command, the global VPC 120 determines the subnet identifier in the resource's network prefix based on the third configuration command, and generates a region identifier in the network prefix that differs from any other VPC under the jurisdiction of the global VPC 120. This region identifier is then combined with the network prefix of the globally VPC stored locally to generate the resource's network prefix. Finally, the cloud management platform 110 retrieves the resource's network prefix from the global VPC 120 and allocates the retrieved network prefix to the aforementioned resources.
[0117] The cloud management platform 110 assigns network prefixes to resources through the first VPC. Specifically, the cloud management platform 110 sends a third configuration command to the first VPC, which includes the deployment location of the aforementioned resources. Upon receiving the third configuration command, the first VPC determines the subnet identifier in the resource's network prefix based on the command, and then generates the resource's network prefix by combining it with the network prefix of the first VPC stored locally. Finally, the cloud management platform 110 retrieves the resource's network prefix from the first VPC and assigns the retrieved network prefix to the aforementioned resources.
[0118] In other embodiments, the cloud management platform 110 allocates network prefixes to the created resources, including: the cloud management platform 110 allocates network prefixes to the resources through the global VPC 120. Specifically, based on the configuration information C input by the tenant, the cloud management platform 110 obtains the deployment location and resource migration attribute representation information of the resources, and then sends a third configuration command to the global VPC 120, wherein the third configuration command includes the deployment location and resource migration attribute representation information of the resources. After receiving the third configuration command, Global VPC 120 determines the subnet identifier in the resource's network prefix based on the resource's deployment location. Based on the resource migration attribute representation information, it determines whether the resource supports migration from the first VPC to a VPC under Global VPC 120 that can communicate with the first VPC. When the resource migration attribute representation information indicates that the resource supports migration from the first VPC to a VPC under Global VPC 120 that can communicate with the first VPC, Global VPC 120 generates a region identifier in the network prefix that is different from any VPC under Global VPC 120. When the resource migration attribute representation information indicates that the resource does not support migration from the first VPC to a VPC under Global VPC 120 that can communicate with the first VPC, Global VPC 120 determines a first region identifier. Then, Global VPC 120 generates the resource's network prefix based on the locally stored global VPC network prefix and the determined subnet identifier and region identifier. Finally, the cloud management platform 110 obtains the network prefix of the resources from the global VPC 120 and assigns the obtained network prefix to the aforementioned resources.
[0119] S108: The cloud management platform 110 sends the network prefix of the resource to the host machine where the resource is deployed.
[0120] S109: After receiving the network prefix of the resource, the host machine generates the IP address of the resource based on the network prefix.
[0121] The IP address of the resource can be either an IPv4 address or an IPv6 address. The following description, assuming the resource's IP address is an IPv6 address, illustrates the process by which the host machine generates the resource's IP address based on the resource's network prefix:
[0122] First, it's important to note that an IPv6 address is 128 bits long and consists of two parts: a network prefix and an interface ID, each 64 bits long. Therefore, when a resource's IP address is an IPv6 address, it comprises a 64-bit network prefix and a 64-bit interface ID. The network prefix includes the network prefix assigned to the resource by the cloud management platform 110, and the interface ID includes the MAC address of the host machine's interface. It's crucial to understand that different resources deployed on the host machine correspond to different interfaces on the host machine; in other words, different resources deployed on the same host machine will have different interface IDs in their IPv6 addresses. Therefore, the process of the host machine generating the resource's IP address based on the resource's network prefix involves: generating an interface ID based on the MAC address of the interface corresponding to the resource, and then generating the resource's IP address (i.e., the IPv6 address) based on the resource's network prefix and the interface ID.
[0123] In some embodiments, the network prefix assigned to resources by the cloud management platform 110 (i.e., the network prefix of the resource) is 64 bits. As mentioned above, the network prefix of a resource may include the network prefix of the global VPC 120, the region identifier, the subnet identifier, and may also include the tenant identifier. Therefore, the network prefix of a resource can have multiple formats. Figures 11-12 The network prefixes for resources in different formats are shown respectively.
[0124] like Figure 11 As shown, the network prefix of a resource includes the global VPC 120 network prefix, the area identifier, and the subnet identifier. The global VPC 120 network prefix is 48 bits, the area identifier is 8 bits, and the subnet identifier is 8 bits.
[0125] like Figure 12 As shown, the network prefix of a resource includes the global VPC 120 network prefix, area identifier, tenant identifier, and subnet identifier. The global VPC 120 network prefix is 32 bits, the area identifier is 8 bits, the tenant identifier is 16 bits, and the subnet identifier is 8 bits.
[0126] It should be noted that, generally, tenants request a 48-bit global routing prefix from the IPv6 address management authority. However, when the cloud management platform 110 requests a global routing prefix from the IPv6 address management authority, it can negotiate with the authority to obtain global routing prefixes of different lengths (such as 20 bits, 32 bits, and 48 bits). Therefore, Figure 11The 48-bit global VPC 120 network prefix shown can be obtained by the tenant from the IPv6 address management authority, or by the cloud management platform 110 from the IPv6 address management authority, or include the global routing prefix and tenant identifier obtained by the cloud management platform 110 from the IPv6 address management authority, or be randomly generated by the cloud management platform 110. Figure 12 The 32-bit global VPC 120 network prefix shown can be obtained by the cloud management platform 110 from the IPv6 address management authority.
[0127] It should also be noted that the length of each part of the network prefix of the resource (including the network prefix of the global VPC 120, the area identifier, the subnet identifier, and the tenant identifier) can be flexibly set, and the position of each part can also be flexibly adjusted. For example, the tenant identifier can be placed before the distinguishing identifier, which is not limited in this embodiment. In practical applications, the cloud management platform 110 can allocate a suitable network prefix to the resource according to the configuration information input by the tenant (including configuration information A, configuration information B, and configuration information C).
[0128] It should be understood that when the IP address of a resource is an IPv4 address, its generation process is similar to that of the IPv6 address of the resource described above. Moreover, the IPv4 address of a resource also has multiple formats, which can be obtained by analogy with the IPv6 address of the resource. Therefore, for the sake of simplicity, the embodiments of this application will not be described in detail.
[0129] The creation of the first VPC and its resources can be achieved through the above steps S101-S109. Similarly, the cloud management platform 110 can also create the second VPC and its resources. The specific process can be found in S101-S109, and will not be described in detail here for the sake of simplicity.
[0130] S110: Global VPC 120 enables cross-region communication between the first VPC and the second VPC based on the first network prefix and the second network prefix.
[0131] It should be understood that since the first VPC and the global VPC have a network connection established through the first access point (S105 above), and the second VPC and the global VPC have a network connection established through the second access point, and the network prefixes of the first VPC and the second VPC are different, the first VPC and the second VPC can communicate through the global VPC 120.
[0132] In some embodiments, the global VPC 120 stores the routing relationship between the network prefixes of the first VPC and the network prefixes of the second VPC. For example, the global VPC 120 stores at least one of a first routing table entry and a second routing table entry, wherein the source address in the first routing table entry is the network prefix of the first VPC and the destination address is the network prefix of the second VPC; the source address in the second routing table entry is the network prefix of the second VPC and the destination address is the network prefix of the first VPC. Taking the sending of a data stream (e.g., data stream A) from the first VPC to the second VPC as an example, the global VPC 120 implements cross-regional communication between the first VPC and the second VPC based on the first and second network prefixes. This includes: the global VPC 120 receiving data stream A sent by the first VPC through a first access point, and then sending data stream A to the second VPC through a second access point according to the first routing table entry. That is, the forwarding path of data stream A is first VPC → first access point → global VPC 120 → second access point → second VPC.
[0133] To improve the communication quality between the first VPC and the second VPC, the cloud management platform 110 may optionally perform the following steps: allocate bandwidth to the global VPC 120 so that the data flow passing through the global VPC 120 meets the aforementioned bandwidth requirements. This bandwidth can be preset by the tenant; for example, if configuration information A includes bandwidth information, then the cloud management platform 110 can allocate bandwidth to the global VPC 120 according to configuration information A. Alternatively, the cloud management platform 110 can dynamically adjust the bandwidth based on actual conditions; for example, the cloud management platform 110 can adjust the bandwidth based on the load of the global VPC 120 and the current network status.
[0134] Furthermore, the cloud management platform 110 can ensure that the data flow passing through the global VPC 120 meets the aforementioned bandwidth requirements in the following way: The cloud management platform 110 maintains a mapping table, which includes at least one VPC identifier, at least one flow label, and the correspondence between at least one VPC identifier and at least one flow label. The at least one VPC identifier includes the identifier of the global VPC 120, and the at least one flow label includes the flow label corresponding to the identifier of the global VPC 120 (hereinafter referred to as the target flow label). In addition, since the cloud management platform 110 can create multiple global VPCs according to the tenant's needs, the at least one VPC identifier can also include the identifiers of other global VPCs. Correspondingly, the at least one flow label also includes the flow labels corresponding to the identifiers of other global VPCs. The identifier for a global VPC 120 can be preset by the tenant or set by the cloud management platform 110. When a tenant creates only one global VPC 120, the identifier can be the tenant identifier. When a tenant creates multiple global VPC 120s, the identifier can be the global VPC 120 ID, the global VPC 120 number, or other information that identifies the global VPC 120. The target flow label is used to identify data flows passing through the global VPC 120. In practice, the cloud management platform 110 assigns an identifier to the global VPC 120, then assigns the corresponding flow label to the data flows passing through the global VPC 120 based on the global VPC 120 identifier, obtains the bandwidth requirements based on the flow labels, and finally instructs the forwarding of the data flows based on the bandwidth requirements.
[0135] For example, suppose the first VPC sends data flow A to the second VPC through global VPC 120. When global VPC 120 receives data flow A, the cloud management platform 110 determines the target flow label according to the aforementioned mapping table, and then encapsulates data flow A using the target flow label (for example, by adding the target flow label to the flow label field in the IPv6 header of data flow A, or by adding the target flow label to a custom field in the IPv4 header of data flow A). Afterward, it instructs global VPC 120 to send the encapsulated data flow A to the second VPC. Through this operation, the underlying network can obtain the target flow label when forwarding data flow A, thereby determining the bandwidth allocated by the cloud management platform 110 to global VPC 120. Then, based on the bandwidth requirements, it configures the Quality of Service (QoS) queue for forwarding data flow A, thus completing the forwarding of data flow A. In this way, the bandwidth of data flow A can be guaranteed, thereby ensuring the quality of communication between the first and second VPCs.
[0136] Based on the method provided in the embodiments of this application, in addition to enabling communication between the first VPC and the second VPC, it also enables on-demand migration of resources between the first VPC and the second VPC. The following example illustrates the migration of VMs from the first VPC to the second VPC. Figure 13 The migration process described above is described.
[0137] S201: The VMs in the first VPC send a migration request to the cloud management platform 110.
[0138] The current VM is located on the first host machine, which is located on the first subnet of the first VPC. The migration request includes the VM's IP address, the VM's MAC address, and the IP address of the first host machine.
[0139] S202: The cloud management platform 110 determines whether the VM supports migration from the first VPC to the second VPC based on the above migration request. If the VM supports migration from the first VPC to the second VPC, then S203-S205 are executed. If the VM does not support migration from the first VPC to the second VPC, then the cloud management platform 110 does not execute the relevant operations to migrate the VM from the first VPC to the second VPC.
[0140] Specifically, the cloud management platform 110 obtains the region identifier in the VM's IP address based on the migration request, and then determines whether the VM supports migration from the first VPC to the second VPC based on the region identifier in the VM's IP address. If the region identifier in the VM's IP address is different from the region identifier in the network prefix of any region VPC 130, the cloud management platform 110 determines that the VM supports migration from the first VPC to the second VPC; if the region identifier in the VM's IP address is the same as the first region identifier, the cloud management platform 110 determines that the VM does not support migration from the first VPC to the second VPC.
[0141] S203: The cloud management platform 110 determines the second host machine based on the above migration request.
[0142] Specifically, the cloud management platform 110 obtains the subnet identifier from the VM's IP address based on the migration request, and then determines the second subnet based on the subnet identifier in the VM's IP address, thereby determining the second host. The second host is located on the second subnet, which is a network segment within the second VPC. The subnet identifier in the network prefix of the second subnet is the same as the subnet identifier in the network prefix of the first subnet.
[0143] S204: Cloud management platform 110 establishes a network connection between the first host machine and the second host machine.
[0144] Specifically, the cloud management platform 110 obtains the IP address of the first host machine based on the migration request, and then establishes a network connection between the first host machine and the second host machine based on the IP address of the first host machine and the IP address of the second host machine.
[0145] S205: Cloud management platform 110 migrates VMs from the first host to the second host.
[0146] Specifically, after the network connection between the first and second host machines is established, the cloud management platform 110 sends a migration command to the first host machine. Upon receiving the migration command, the first host machine first sends the VM's configuration (such as the operating system) and device information (such as memory size) to the second host machine, and then synchronizes the VM's memory (such as the VM's initial memory and memory sharding changes) to the second host machine. Next, the VM is paused on the first host machine, and the final memory sharding changes are then transmitted to the second host machine. Finally, the VM is stopped on the first host machine and resumed on the second host machine, thus completing the VM migration.
[0147] It is worth noting that during the VM migration process, other VMs (such as VMs deployed on the first VPC or other VPCs) may access the VM. In this case, the cloud management platform 110 needs to send the data stream from the other VMs to the first host. After the VM migration is completed, if other VMs access the VM, the cloud management platform 110 needs to send the data stream from the other VMs to the second host.
[0148] The preceding text combined Figures 6-13 The described method details the functions of the cloud management platform 110. The following section will combine... Figures 14-16 The cloud management platform 110 is described in more detail from the perspective of its structure.
[0149] Figure 14 An exemplary structural diagram of the cloud management platform 110 is shown. For example... Figure 14As shown, the cloud management platform 110 includes a determination module 111, a control module 112, and a network configuration module 113. The determination module 111, control module 112, and network configuration module 113 work together to implement the steps performed by the cloud management platform 110 in the above method embodiments. Specifically, the determination module 111 is used to perform the steps in S101 (determining the tenant's input or selected configuration information A), S103 (determining the tenant's input or selected configuration information B), and S107 (determining the tenant's input or selected configuration information C). The determination module 111 is also used to send the configuration information A, configuration information B, and configuration information C to the control module 112. Control module 112 is used to execute the steps in S101 above, namely, creating a global VPC 120 based on configuration information A; the steps in S103 above, namely, creating a first VPC based on configuration information B; and the steps in S107 above, namely, creating resources within the first VPC based on configuration information C and assigning network prefixes to the resources. Control module 112 is also used to execute S102-S104, S106, S108, and S110 above. Network configuration module 113 is used to execute S105 above.
[0150] Optionally, the determining module 111 is further configured to receive a migration request sent by the VM and send the migration request to the control module 112; the control module 112 is further configured to execute the above S202-S205.
[0151] Optionally, the control module 112 is also used to perform steps related to ensuring bandwidth when the first VPC and the second VPC communicate, such as allocating bandwidth to the global VPC 120 and labeling the amount of data passing through the global VPC 120 with flow tags.
[0152] It should be understood that Figure 14 The structural diagram shown is merely an exemplary structural division of the cloud management platform 110 based on function. This application does not limit the specific structural division of the cloud management platform 110. Those skilled in the art can reasonably divide the internal functions of the cloud management platform 110 according to the scheme described in the method embodiments of this application, thereby enabling the internal functional modules of the cloud management platform 110 to implement the various steps of the cloud management platform 110 as the execution subject in the method embodiments. It should also be understood that the various modules within the cloud management platform 110 can be software modules, hardware modules, or a combination of both.
[0153] Figure 15This illustration shows a structural diagram of a computing device provided in an embodiment of this application. The aforementioned cloud management platform 110 can be deployed on this computing device. This computing device can be a computing device in a cloud environment (e.g., a server), a computing device in an edge environment, or a terminal computing device. Figure 15 As shown, the computing device 200 includes a memory 210, a processor 220, a communication interface 230, and a bus 240, wherein the memory 210, the processor 220, and the communication interface 230 are connected to each other via the bus 240.
[0154] The memory 210 may include read-only memory (ROM), static storage, dynamic storage, random access memory (RAM), hard disk, etc. The memory 210 can store programs, such as the programs in the determination module 111, the control module 112, and the network configuration module 113. When the program code stored in the memory 210 is executed by the processor 220, the processor 220 and the communication interface 230 are used to execute the methods executed by the cloud management platform 110 (including the methods described in S101-S110 and S201-S205 above, and related steps to ensure bandwidth during communication between the first VPC and the second VPC). The memory 210 can also store data, such as intermediate or result data generated by the processor 220 during execution, such as the network prefix and ACL of the global VPC 120.
[0155] The processor 220 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), a graphics processing unit (GPU), or one or more integrated circuits.
[0156] Processor 220 can also be an integrated circuit chip with signal processing capabilities. In implementation, some functions of the cloud management platform 110 can be completed through integrated logic circuits in the hardware of processor 220 or instructions in software form. Processor 220 can also be a general-purpose processor, a digital signal processor (DSP), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components, capable of implementing or executing 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, etc. The methods disclosed in the embodiments of this application can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. Software modules can reside 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. This storage medium is located in memory 210. Processor 220 reads information from memory 210 and, in conjunction with its hardware, completes some or all of the functions of the cloud management platform 110.
[0157] Communication interface 230 uses transceiver modules, such as, but not limited to, transceivers, to enable communication between computing device 200 and other devices or communication networks. For example, communication interface 230 receives configuration information (including configuration information A, configuration information B, and configuration information C) sent by a tenant.
[0158] Bus 240 may include a pathway for transmitting information between various components in computing device 200 (e.g., memory 210, processor 220, and communication interface 230).
[0159] Figure 16 This diagram illustrates the structure of a computing device system according to an embodiment of this application. The computing device system includes multiple computing devices, and the aforementioned cloud management platform 110 can be distributed and deployed across these multiple computing devices. Figure 16 As shown, the computing device system 300 includes multiple computing devices 400. Each computing device 400 includes a memory 410, a processor 420, a communication interface 430, and a bus 440. The memory 410, the processor 420, and the communication interface 430 are connected to each other via the bus 440.
[0160] The memory 410 may include ROM, RAM, static storage devices, dynamic storage devices, hard disks (e.g., SSDs, HDDs), etc. The memory 410 may store program code, such as a portion of the program in the determination module 111, a portion of the program in the control module 112, and a portion of the program in the network configuration module 113. When the program code stored in the memory 410 is executed by the processor 420, the processor 420 and the communication interface 430 are used to execute some of the methods executed by the cloud management platform 110 (including some of the methods described in S101-S110 and S201-S205 above, and steps related to ensuring bandwidth during communication between the first VPC and the second VPC). The memory 410 may also store data, such as intermediate or result data generated by the processor 420 during execution, such as the network prefix and ACL of the global VPC 120.
[0161] Processor 420 can be a CPU, GPU, ASIC, or one or more integrated circuits. Processor 420 can also be an integrated circuit chip with signal processing capabilities. In implementation, some functions of the cloud management platform 110 can be completed through integrated logic circuits in the hardware of processor 420 or through software instructions. Processor 420 can also be a DSP, FPGA, general-purpose processor, other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components, capable of implementing or executing some of 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, etc. The steps of the methods disclosed in the embodiments of this application can be directly manifested as execution by a hardware decoding processor, or execution 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. This storage medium is located in memory 410. Processor 420 reads information from memory 410 and, in conjunction with its hardware, completes some functions of the cloud management platform 110.
[0162] The communication interface 430 uses a transceiver module, such as, but not limited to, a transceiver, to enable communication between the computing device 400 and other computing devices or communication networks. For example, the communication interface 430 receives configuration information (including configuration information A, configuration information B, and configuration information C) sent by a tenant.
[0163] Bus 440 may include a pathway for transmitting information between various components in computing device 400 (e.g., memory 410, processor 420, and communication interface 430).
[0164] The aforementioned multiple computing devices 400 establish communication channels through a communication network to realize the functions of the cloud management platform 110. Any computing device can be a computing device in a cloud environment (e.g., a server), a computing device in an edge environment, or a terminal computing device.
[0165] The descriptions of the processes corresponding to the above-mentioned figures each have their own emphasis. For parts of a process that are not described in detail, please refer to the relevant descriptions of other processes.
[0166] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, or a combination thereof. When implemented using software, it can be implemented, in whole or in part, as a computer program product. This computer program product may include one or more computing instructions executed by the cloud management platform 110, which, when loaded and executed on a computer, generate, in whole or in part, the processes or functions described in the embodiments of this application.
[0167] The aforementioned computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The aforementioned computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the aforementioned computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic cable, twisted pair, or wireless (e.g., infrared, wireless, microwave)) means. The aforementioned computer-readable storage medium stores computer program instructions that are executed by the cloud management platform 110. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more media. The aforementioned available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., optical disc), or a semiconductor medium (e.g., solid-state disk (SSD)).
Claims
1. A communication method between Virtual Private Clouds (VPCs) based on public cloud, characterized in that, include: The cloud management platform determines the first configuration information entered or selected by the tenant and creates a global VPC based on the first configuration information. The cloud management platform determines the second configuration information input or selected by the tenant, creates a first VPC in the first region, and creates a second VPC in the second region based on the second configuration information. The cloud management platform utilizes the global VPC to assign a first network prefix to the first VPC based on the identifier of the first VPC and the network prefix of the global VPC, and assigns a second network prefix to the second VPC based on the identifier of the second VPC and the network prefix of the global VPC. The first network prefix is different from the second network prefix. The global VPC is used to realize cross-regional communication between the first VPC and the second VPC based on the first network prefix and the second network prefix.
2. The method according to claim 1, characterized in that, The region identifier in the first network prefix is different from the region identifier in the second network prefix.
3. The method according to claim 2, characterized in that, Also includes: The cloud management platform assigns a network prefix to the global VPC, wherein the first network prefix and the second network prefix also include the network prefix of the global VPC.
4. The method according to claim 3, characterized in that, Also includes: The cloud management platform establishes a network connection between the first VPC and the global VPC, as well as a network connection between the second VPC and the global VPC.
5. The method according to claim 4, characterized in that, The global VPC stores the first network prefix, the second network prefix, and the routing relationship between the first network prefix and the second network prefix.
6. The method according to claim 5, characterized in that, The first VPC does not support communication with the third VPC.
7. The method according to claim 6, characterized in that, Also includes: The cloud management platform sets an Access Control List (ACL) for the first VPC, wherein the ACL includes entries for blocking communication between the first VPC and the third VPC.
8. The method according to any one of claims 1-7, characterized in that, The first VPC includes a first subnet, and the method further includes: The cloud management platform assigns a network prefix to the first subnet through the global VPC, wherein the network prefix of the first subnet includes the first network prefix and the subnet identifier.
9. The method according to claim 8, characterized in that, The first subnet includes virtual machines (VMs), and the method further includes: The cloud management platform assigns a network prefix to the VM through the global VPC or the first VPC, wherein the region identifier in the network prefix of the VM is used to indicate that the VM supports migration to a VPC under the jurisdiction of the global VPC that can communicate with the first VPC.
10. The method according to claim 9, characterized in that, The region identifier in the network prefix of the VM is different from the region identifier in the network prefix of any VPC under the jurisdiction of the global VPC.
11. The method according to claim 10, characterized in that, The VPC under the jurisdiction of the global VPC that can communicate with the first VPC includes the second VPC, and the method further includes: The cloud management platform migrates the VM from the first VPC to the second VPC, wherein the migrated VM is located in the second subnet of the second VPC, and the subnet identifier in the network prefix of the second subnet is the same as the subnet identifier in the network prefix of the first subnet.
12. The method according to claim 11, characterized in that, The network prefix of the migrated VM is the same as the network prefix of the VM before migration.
13. The method according to claim 12, characterized in that, Also includes: The cloud management platform allocates bandwidth to the global VPC, and the data flow passing through the global VPC meets the bandwidth requirements.
14. The method according to claim 13, characterized in that, Also includes: The cloud management platform assigns corresponding flow tags to the data streams passing through the global VPC based on the identifier of the global VPC; The cloud management platform obtains the bandwidth requirement based on the flow tag and instructs the forwarding of the data flow based on the bandwidth requirement.
15. The method according to claim 14, characterized in that, The network prefix of the global VPC is the Internet Protocol version 6 (IPv6) prefix obtained by the cloud management platform.
16. The method according to claim 14, characterized in that, The network prefix of the global VPC is the IPv6 prefix generated by the cloud management platform.
17. The method according to claim 14, characterized in that, The network prefix of the global VPC is the IPv6 prefix requested by the tenant.
18. A cloud management platform, characterized in that, include: The determination module is used to determine the first and second configuration information input or selected by the tenant. The control module is configured to create a global Virtual Private Cloud (VPC) based on the first configuration information; create a first VPC in a first region and a second VPC in a second region based on the second configuration information; and, using the global VPC, assign a first network prefix to the first VPC based on the identifier of the first VPC and the network prefix of the global VPC, and assign a second network prefix to the second VPC based on the identifier of the second VPC and the network prefix of the global VPC, wherein the first network prefix and the second network prefix are different, and the global VPC is used to enable cross-regional communication between the first VPC and the second VPC based on the first network prefix and the second network prefix.
19. The cloud management platform according to claim 18, characterized in that, The region identifier in the first network prefix is different from the region identifier in the second network prefix.
20. The cloud management platform according to claim 19, characterized in that, The control module is further configured to assign a network prefix to the global VPC, wherein the first network prefix and the second network prefix also include the network prefix of the global VPC.
21. The cloud management platform according to claim 20, characterized in that, Also includes: The network configuration module is used to establish network connections between the first VPC and the global VPC, as well as network connections between the second VPC and the global VPC.
22. The cloud management platform according to claim 21, characterized in that, The global VPC stores the first network prefix, the second network prefix, and the routing relationship between the first network prefix and the second network prefix.
23. The cloud management platform according to claim 22, characterized in that, The first VPC does not support communication with the third VPC.
24. The cloud management platform according to claim 23, characterized in that, The network configuration module is further configured to set the access control list (ACL) of the first VPC, wherein the ACL includes entries for blocking communication between the first VPC and the third VPC.
25. The cloud management platform according to any one of claims 18-24, characterized in that, The first VPC includes a first subnet. The control module is further configured to allocate a network prefix to the first subnet through the global VPC, wherein the network prefix of the first subnet includes the first network prefix and the subnet identifier.
26. The cloud management platform according to claim 25, characterized in that, The first subnet includes virtual machines (VMs). The control module is further configured to assign a network prefix to the VM through the global VPC or the first VPC, wherein the region identifier in the network prefix of the VM is used to indicate that the VM supports migration to a VPC under the jurisdiction of the global VPC that can communicate with the first VPC.
27. The cloud management platform according to claim 26, characterized in that, The region identifier in the network prefix of the VM is different from the region identifier in the network prefix of any VPC under the jurisdiction of the global VPC.
28. The cloud management platform according to claim 27, characterized in that, The VPC under the global VPC that can communicate with the first VPC includes the second VPC. The control module is further configured to migrate the VM from the first VPC to the second VPC, wherein the migrated VM is located in the second subnet of the second VPC, and the subnet identifier in the network prefix of the second subnet is the same as the subnet identifier in the network prefix of the first subnet.
29. The cloud management platform according to claim 28, characterized in that, The network prefix of the migrated VM is the same as the network prefix of the VM before migration.
30. The cloud management platform according to claim 29, characterized in that, The control module is also used to allocate bandwidth to the global VPC, wherein the data flow passing through the global VPC meets the bandwidth requirements.
31. The cloud management platform according to claim 30, characterized in that, The control module is further configured to assign a corresponding flow label to the data flow passing through the global VPC based on the identifier of the global VPC, obtain the bandwidth requirement based on the flow label, and instruct the forwarding of the data flow based on the bandwidth requirement.
32. The cloud management platform according to claim 31, characterized in that, The network prefix of the global VPC is the Internet Protocol version 6 (IPv6) prefix obtained by the cloud management platform.
33. The cloud management platform according to claim 31, characterized in that, The network prefix of the global VPC is the IPv6 prefix generated by the cloud management platform.
34. The cloud management platform according to claim 31, characterized in that, The network prefix of the global VPC is the IPv6 prefix requested by the tenant.
35. A communication system, characterized in that, The cloud management platform includes any one of claims 18-34, a global virtual private cloud (VPC), a first VPC located in a first region, and a second VPC located in a second region.
36. A computing device, characterized in that, It includes a processor and a memory, the processor executing computer program code in the memory to implement the method of any one of claims 1-17.
37. A computer-readable storage medium, characterized in that, The device stores computer program code, which, when executed by a computing device, performs the method described in any one of claims 1-17.