Cloud environment access method and apparatus

Abstract

The embodiment of the present application provides a kind of cloud environment access method and device, the method comprises: configuring first routing information in the second cloud environment, first routing information is used to indicate that the request of access first cloud environment is sent to gateway virtual machine.Establish the virtual link between routing virtual machine and gateway virtual machine, and virtual link is used for data transmission between routing virtual machine and gateway virtual machine.Configuration second routing information, second routing information is used to indicate that gateway virtual machine sends access request to routing virtual machine, and indicates that routing virtual machine sends access request to target service, and access request is used to request access target service in first cloud environment.According to first routing information, second routing information and virtual link, access request is forwarded to routing virtual machine by gateway virtual machine, and access request is sent to target service by routing virtual machine.The technical scheme of the present application can effectively realize the mutual access of second cloud environment and first cloud environment.

Description

Technical Field

[0001] This application relates to computer technology, and more particularly to a cloud environment access method and apparatus. Background Technology

[0002] There is currently a technology that allows private clouds to be deployed on public clouds to address the strong coupling limitations of private clouds to physical devices.

[0003] In a private cloud, multiple cloud environments are typically deployed to meet user needs for product deployment. If a private cloud is deployed on top of physical devices, communication between different cloud environments can be achieved through the communication links of those physical devices. However, in implementations where a private cloud is deployed on a public cloud, the lack of physical devices prevents different cloud environments from communicating with each other, and there is currently no effective solution to this problem. Summary of the Invention

[0004] This application provides a cloud environment access method and apparatus to overcome the problem that different cloud environments cannot access each other.

[0005] In a first aspect, embodiments of this application provide a cloud environment access method, applied to a first cloud platform, the first cloud platform being deployed on a second cloud platform, the first cloud platform including a first cloud environment and a second cloud environment, a routing virtual machine created in the first cloud environment, and a gateway virtual machine created in the second cloud environment, including:

[0006] Configure first routing information in the second cloud environment, the first routing information being used to indicate that requests to access the first cloud environment should be sent to the gateway virtual machine;

[0007] A virtual link is established between the routing virtual machine and the gateway virtual machine, and the virtual link is used for data transmission between the routing virtual machine and the gateway virtual machine;

[0008] Configure second routing information, which is used to instruct the gateway virtual machine to send the access request to the routing virtual machine and to instruct the routing virtual machine to send the access request to the target service, wherein the access request is used to request access to the target service in the first cloud environment;

[0009] Based on the first routing information, the second routing information, and the virtual link, the access request is forwarded to the routing virtual machine via the gateway virtual machine, and then the routing virtual machine sends the access request to the target service.

[0010] Secondly, embodiments of this application provide a cloud environment access method applied to a first cloud platform, the first cloud platform being deployed on a second cloud platform. The first cloud platform includes a first cloud environment and a second cloud environment. A routing virtual machine and an SLB virtual machine are created in the first cloud environment, and a gateway virtual machine is created in the second cloud environment. The method includes:

[0011] Configure first routing information in the first cloud environment. The first routing information is used to instruct the intermediate component in the SLB virtual machine to send an access request to the routing virtual machine. The access request is used to request access to the target service in the second cloud environment.

[0012] A virtual link is established between the routing virtual machine and the gateway virtual machine, and the virtual link is used for data transmission between the routing virtual machine and the gateway virtual machine;

[0013] Configure second routing information, which is used to instruct the routing virtual machine to send the access request to the gateway virtual machine;

[0014] Based on the first routing information, the second routing information, and the virtual link, the access request is forwarded to the gateway virtual machine via the routing virtual machine, and the gateway virtual machine sends the access request to the target service.

[0015] Thirdly, embodiments of this application provide a cloud environment access device, including:

[0016] The configuration module is used to configure first routing information in the second cloud environment, wherein the first routing information is used to indicate that the request to access the first cloud environment is sent to the gateway virtual machine;

[0017] The processing module is used to establish a virtual link between the routing virtual machine and the gateway virtual machine, and the virtual link is used for data transmission between the routing virtual machine and the gateway virtual machine;

[0018] The configuration module is further configured to configure second routing information, which is used to instruct the gateway virtual machine to send an access request to the routing virtual machine and to instruct the routing virtual machine to send an access request to the target service. The access request is used to request access to the target service in the first cloud environment.

[0019] The sending module is used to forward the access request to the routing virtual machine through the gateway virtual machine according to the first routing information, the second routing information and the virtual link, and the routing virtual machine sends the access request to the target service.

[0020] Fourthly, embodiments of this application provide a cloud environment access device, including:

[0021] The configuration module is used to configure first routing information in the first cloud environment. The first routing information is used to instruct the intermediate component in the SLB virtual machine to send an access request to the routing virtual machine. The access request is used to request access to the target service in the second cloud environment.

[0022] The processing module is used to establish a virtual link between the routing virtual machine and the gateway virtual machine, the virtual link being used for data transmission between the routing virtual machine and the gateway virtual machine;

[0023] The configuration module is further configured to configure second routing information, which instructs the routing virtual machine to send the access request to the gateway virtual machine.

[0024] The sending module is used to forward the access request to the gateway virtual machine through the routing virtual machine according to the first routing information, the second routing information and the virtual link, and the gateway virtual machine sends the access request to the target service.

[0025] Fifthly, embodiments of this application provide an electronic device, including:

[0026] Memory, used to store programs;

[0027] A processor for executing the program stored in the memory, wherein, when the program is executed, the processor is configured to perform the method described in the first aspect above and any of the various possible designs of the first aspect.

[0028] In a sixth aspect, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on a computer, cause the computer to perform the methods described in the first aspect above and any of the various possible designs of the first aspect.

[0029] In a seventh aspect, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the method described in the first aspect above and any of the various possible designs of the first aspect.

[0030] This application provides a cloud environment access method and apparatus. The method involves configuring a second cloud environment to send requests for access to a first cloud environment to a gateway virtual machine, establishing a corresponding virtual link between the gateway virtual machine in the second cloud environment and the routing virtual machine in the first cloud environment, and configuring corresponding second routing rules. This enables access requests for a target service initiated in the second cloud environment to be sent to the target service in the first cloud environment via the gateway virtual machine and the routing virtual machine. By configuring the routing and links described above, access from the second cloud environment to the target service in the first cloud environment can be effectively achieved. Similarly, by configuring the first cloud environment to send access requests to a routing virtual machine, establishing a corresponding virtual link between the gateway virtual machine in the second cloud environment and the routing virtual machine in the first cloud environment, and configuring corresponding second routing rules, access requests for a target service initiated in the first cloud environment can be sent to the target service in the second cloud environment via the routing virtual machine and the gateway virtual machine. By configuring the routing and links described above, access from the first cloud environment to the target service in the second cloud environment can be effectively achieved. Attached Figure Description

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

[0032] Figure 1 A schematic diagram of the architecture of the proprietary cloud platform provided in the embodiments of this application;

[0033] Figure 2 A flowchart illustrating the cloud environment access method provided in this application embodiment;

[0034] Figure 3 The flow of the cloud environment access method provided in the embodiments of this application Figure 2 ;

[0035] Figure 4 A schematic diagram of the transmission of access requests provided in the embodiments of this application. Figure 1 ;

[0036] Figure 5 A schematic diagram of the transmission of access requests provided in the embodiments of this application. Figure 2 ;

[0037] Figure 6 The flow of the cloud environment access method provided in the embodiments of this application Figure 3 ;

[0038] Figure 7 A schematic diagram of the transmission of access requests provided in the embodiments of this application. Figure 3 ;

[0039] Figure 8 A schematic diagram of the software architecture of the cloud environment access method provided in the embodiments of this application;

[0040] Figure 9 Schematic diagram of the cloud environment access device provided in the embodiments of this application Figure 1 ;

[0041] Figure 10 Schematic diagram of the cloud environment access device provided in the embodiments of this application Figure 2 ;

[0042] Figure 11 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

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

[0044] To better understand the technical solution of this application, the relevant concepts involved in this application will be explained first.

[0045] Public cloud: Public cloud is a model based on standard cloud computing, in which service providers create resources such as applications and storage, which the public can access through the network.

[0046] Private Cloud: While public clouds can meet the computing needs of most customers, they may not be sufficient for some specific needs. In such cases, dedicated cloud computing services, or private clouds, are provided. This solution typically involves deploying various cloud computing applications offered by a cloud service provider within the user's own data center. A private cloud platform can be understood as a platform that provides virtualized resource services entirely to a single organization.

[0047] Classic cloud environment: also known as classic network or classic environment, it is a public network area shared by all users in the cloud. There is no logical isolation between users. The internal network IP of users is uniformly assigned by the system, and the same internal network IP cannot be assigned to different users.

[0048] Private cloud environment: also known as Virtual Private Cloud (VPC), is an isolated network area built on the cloud using underlying technologies.

[0049] VXLAN: Virtual Extensible Local Area Network, is a network isolation technology based on User Datagram Protocol (UDP), which encapsulates raw data link layer network data in UDP packets for transmission.

[0050] VLAN: Virtual Local Area Network, is a virtual LAN technology commonly used to isolate data link layer networks.

[0051] veth: Virtual Ethernet is a pair of virtual network cards whose transmitting and receiving ends are directly connected together. Assuming there is a pair of veth network cards: A and B, packets sent by A are directly received by B, and vice versa.

[0052] Virtual machine: Also known as a cloud service instance, a virtual machine is a complete computer system with full hardware system functions simulated by software and running in an isolated environment, including the most basic computer components such as vCPU (virtual CPU), memory, operating system, network, and disk.

[0053] SLB Virtual Machine: Server Load Balancer virtual machine, used to provide load balancing services in classic cloud environments and perform corresponding address translation and data transmission and reception processing. The number of SLB virtual machines in a classic cloud environment can be adjusted according to actual load requirements.

[0054] Based on the above introduction, the relevant technologies involved in this application will be further described in detail below.

[0055] Currently, there is an implementation solution for private clouds that can be deployed on public clouds using technologies such as VXLAN and simulated routers. This is equivalent to deploying a cloud platform on the cloud. This technology can solve the strong coupling restrictions of private clouds on physical devices and meet the needs of many upper-layer products.

[0056] However, many products are not only deployed in the classic network of the private cloud, but also need to create their own dedicated VPC through the ECS (Elasticity Cloud Server) and VPC services provided by the private cloud, and then deploy infrastructure such as vSwitch (Virtual Switch) and virtual machines on these VPCs to deploy the products.

[0057] Therefore, a dedicated cloud platform deployed on a public cloud platform needs to include both a classic cloud environment and a private cloud environment (VPC). The following section will combine... Figure 1 To understand the system architecture presented here, Figure 1 This is a schematic diagram of the architecture of the proprietary cloud platform provided in the embodiments of this application.

[0058] like Figure 1 As shown, a private cloud platform is deployed within a public cloud platform. In actual implementation, one or more private cloud platforms can be deployed within a public cloud platform, depending on the number and needs of customers who require the private cloud.

[0059] Furthermore, this applies to any dedicated cloud platform, including a classic cloud environment and at least one private cloud environment. The classic cloud environment is the public network environment within the dedicated cloud, and therefore only one exists. However, private cloud environments can be created according to the user's actual needs, and therefore multiple private cloud environments can exist.

[0060] In one possible implementation, when creating a private cloud environment in a dedicated cloud, a mock service in a classic cloud environment can hijack the upper-layer interface for creating a VPC. When the VPC creation request is hijacked, the adaptation layer logic can be used to create the VPC.

[0061] In this context, a mock service can be understood as one or more virtual machines used to perform corresponding control and processing operations. In this application, the mock service can send configuration information to the proxy units of the gateway virtual machine, the routing virtual machine, and the SLB virtual machine, enabling each virtual machine to complete the corresponding routing configuration.

[0062] Because the design of deploying a private cloud platform on a public cloud platform does not actually rebuild a real ECS and VPC infrastructure, the requests of users to create new VPCs and ECSs can be implemented by building a series of adaptation and simulation layers on the basic services of the public cloud platform.

[0063] Based on the above Figure 1As the introduction suggests, the classic cloud environment and private cloud environment in a private cloud are actually nested concepts relative to the public cloud. That is to say, the private cloud itself is deployed on the cloud, and further, the classic cloud environment and private cloud environment need to be deployed on the private cloud.

[0064] Meanwhile, the following application scenarios exist for classic cloud environments and private cloud environments: at least one client in a private cloud environment needs to access basic services in a classic cloud environment, and at least one client, server, container, etc., in a classic cloud environment needs to access basic services in a private cloud environment. The client mentioned in this application can be understood as an instance created in the environment (such as an ECS instance, or a virtual machine), or as a software unit within an instance.

[0065] In other words, private cloud environments and classic cloud environments need to be able to access each other to expand the application scope of cloud environments within the private cloud. However, due to the lack of infrastructure support, mutual access between different environments can only be achieved through simulation. In the public cloud, multiple simulated VPCs can exist. The existing rules for network isolation, address overlap, and network access restrictions between different VPCs greatly limit mutual access between different types of environments in the private cloud. Therefore, currently, there is no effective solution for achieving mutual access between the classic cloud environment and the private cloud environment of a private cloud deployed on a public cloud.

[0066] To address the problems in the existing technology, this application proposes the following technical concept: creating a routing virtual machine in a classic cloud environment and a gateway virtual machine in a private cloud environment, then establishing a logical link between the two virtual machines, and by configuring corresponding routing rules, effectively avoiding the limitations of mutual isolation, address overlap, and network access between VPCs mentioned above, so as to effectively realize mutual access between the classic cloud environment and the private cloud environment.

[0067] The cloud environment access method provided in this application will be described in detail below with reference to specific embodiments. Before the detailed description, it should be noted that the execution subject of each embodiment in this application can be understood as a computing device or processing device that builds a public cloud platform. Based on these devices, corresponding cloud services are carried out to realize the technical solution described in this application.

[0068] Furthermore, the cloud environment access method provided in this application includes services accessed by instances in a private cloud environment to services in a classic cloud environment, as well as services accessed by instances in a classic cloud environment to services in a private cloud environment. The implementation of these two access directions will be described below.

[0069] Before proceeding, it should be noted that in the following embodiments, the first cloud platform can be understood as the proprietary cloud platform described above, and the second cloud platform can be understood as the public cloud platform described above. However, it is not limited to these two platforms. As long as an implementation method of deploying another cloud platform on top of one cloud platform, the cloud platform used to carry the deployment can be understood as the second cloud platform in this application, and the cloud platform deployed on the cloud can be understood as the first cloud platform in this application.

[0070] Furthermore, in the following description, the first cloud environment can be understood as the classic cloud environment described above, and the second cloud environment can be understood as the private cloud environment described above. However, it is not limited to these two environments. A cloud platform can include a variety of different environments. Any two environments that need to access each other but cannot directly access each other due to the architecture of the cloud platform deployed on the cloud can be understood as the first cloud environment and the second cloud environment described in this application.

[0071] Based on the above introduction, the following section describes how instances in the second cloud environment access services in the first cloud environment. Figure 2 A flowchart illustrating the cloud environment access method provided in this application embodiment.

[0072] like Figure 2 As shown, the method includes:

[0073] S201. Configure the first routing information in the second cloud environment. The first routing information is used to indicate that requests to access the first cloud environment should be sent to the gateway virtual machine.

[0074] In this embodiment, a gateway virtual machine is created in the second cloud environment, which is used to implement data transmission with the classic environment. It is understood that multiple virtual machines can be created in the second cloud environment according to actual needs, each of which can perform corresponding functions. In this embodiment, the gateway virtual machine is specifically designed for data transmission.

[0075] Furthermore, first routing information can be configured in the second cloud environment. The routing information can indicate the direction of data flow. In the second cloud environment, data needs to be transmitted between the gateway virtual machine and the first cloud environment. Therefore, in this embodiment, the first routing information is configured to indicate that the request to access the first cloud environment is sent to the gateway virtual machine.

[0076] In one possible implementation, a client or instance in the second cloud environment can initiate an access request to the first cloud environment. The access request may include a source address and a destination address. If the destination address belongs to a preset network segment corresponding to the first cloud environment, the access request can be sent to the gateway virtual machine in the second cloud environment according to the first routing information.

[0077] S202. Establish a virtual link between the routing virtual machine and the gateway virtual machine. The virtual link is used for data transmission between the routing virtual machine and the gateway virtual machine.

[0078] In this embodiment, a routing virtual machine is created in the first cloud environment. It is understood that there is only one first cloud environment, but there may be multiple second cloud environments. Therefore, the routing virtual machine in the first cloud environment can be used to perform corresponding routing processing on the access requests received from the second cloud environment, and then send them to the corresponding address.

[0079] Therefore, data transmission is required between the routing virtual machine and the gateway virtual machine in this embodiment. In order to effectively realize data transmission, a virtual link needs to be established between the routing virtual machine and the gateway virtual machine. The virtual link is used to realize the data transmission described above.

[0080] S203. Configure the second routing information. The second routing information is used to instruct the gateway virtual machine to send the access request to the routing virtual machine and to instruct the routing virtual machine to send the access request to the target service. The access request is used to request access to the target service in the first cloud environment.

[0081] In this embodiment, second routing information also needs to be configured so that after receiving an access request, the gateway virtual machine can determine the next hop of the access request, which is the routing virtual machine. The routing virtual machine exists in the first cloud environment, so access to the target service by the routing virtual machine is quite convenient. Furthermore, the second routing information instructs the routing virtual machine to send the access request to the target service.

[0082] S204. Based on the first routing information, the second routing information, and the virtual link, the access request is forwarded to the routing virtual machine via the gateway virtual machine, and the routing virtual machine sends the access request to the target service.

[0083] After completing the relevant configurations described above, access requests initiated in the second cloud environment can be forwarded to the routing virtual machine via the gateway virtual machine based on the first routing information, the second routing information, and the virtual link described above. The routing virtual machine then sends the access requests to the corresponding target service, thereby effectively enabling the second cloud environment to access the target service in the first cloud environment.

[0084] The cloud environment access method provided in this application includes: configuring first routing information in a second cloud environment, wherein the first routing information is used to instruct the request to access the first cloud environment to be sent to the gateway virtual machine; establishing a virtual link between the routing virtual machine and the gateway virtual machine, wherein the virtual link is used for data transmission between the routing virtual machine and the gateway virtual machine; configuring second routing information, wherein the second routing information is used to instruct the gateway virtual machine to send the access request to the routing virtual machine and to instruct the routing virtual machine to send the access request to the target service, wherein the access request is used to request access to the target service in the first cloud environment; and forwarding the access request to the routing virtual machine via the gateway virtual machine according to the first routing information, the second routing information, and the virtual link, wherein the routing virtual machine sends the access request to the target service. By configuring the request to access the first cloud environment to be sent to the gateway virtual machine in the second cloud environment, establishing a corresponding virtual link between the gateway virtual machine in the second cloud environment and the routing virtual machine in the first cloud environment, and configuring corresponding second routing rules, it is possible to send the access request for the target service initiated in the second cloud environment to the target service in the first cloud environment via the gateway virtual machine and the routing virtual machine. By configuring the routing and link described above, access from the second cloud environment to the target service in the first cloud environment can be effectively realized.

[0085] Based on the above introduction, the following will combine... Figures 3 to 4 The implementation of creating virtual links in the cloud environment access method provided in this application will be described in further detail. Figure 3 The flow of the cloud environment access method provided in the embodiments of this application Figure 2 , Figure 4 A schematic diagram of the transmission of access requests provided in the embodiments of this application. Figure 1 .

[0086] like Figure 3 As shown, the method includes:

[0087] S301. In the gateway virtual machine, create a VXLAN tunnel based on the IP address of the routing virtual machine.

[0088] In this embodiment, both the gateway virtual machine and the routing virtual machine have their own IP addresses, which can be EIPs (Elastic Internet Protocols), which are IPs that can be accessed on the public Internet.

[0089] Furthermore, when creating a VXLAN tunnel, it is possible to specify which target the peer should interconnect with to achieve interoperability based on the VXLAN tunnel. Therefore, in this embodiment, a VXLAN tunnel based on the EIP of the routing virtual machine can be created in the gateway virtual machine.

[0090] Additionally, a VXLAN tunnel based on the EIP of the gateway virtual machine is also created in the routing virtual machine. The creation of VXLAN tunnels based on the peer's EIP is performed in both the gateway virtual machine and the routing virtual machine, thereby enabling the establishment of a VXLAN tunnel between the gateway virtual machine and the routing virtual machine, achieving a point-to-point VXLAN tunnel connection based on the peer's EIP.

[0091] Furthermore, the underlying FDB (Forwarding Database) table of the VXLAN tunnel can be populated in the gateway virtual machine to indicate which packets can be transmitted and which packets need to be dropped.

[0092] S302. Create the first bridge, where the interface of the VXLAN tunnel in the gateway virtual machine is logically connected to the first bridge.

[0093] Furthermore, a first bridge can be created within the gateway virtual machine. In this embodiment, the created bridge can be understood as a virtual bridge. The bridge's function is to receive data, filter addresses, and forward data, thereby enabling data exchange between multiple network systems. In this embodiment, the first bridge can be, for example, a br-vpn bridge, where br is an abbreviation for Bridge.

[0094] Based on the above, it can be confirmed that a VXLAN tunnel has been established between the gateway virtual machine and the routing virtual machine. This VXLAN tunnel has an interface within the gateway virtual machine, which can be referenced for example... Figure 4 The interface vxlan1 in the gateway virtual machine and the interface for the vxlan tunnel also exist in the routing virtual machine. For example, you can refer to... Figure 4 The interface vxlan1 is located in the routing virtual machine.

[0095] To ensure that data transmitted through the VXLAN tunnel reaches the first bridge, the VXLAN tunnel interface in the gateway virtual machine needs to be logically connected to the first bridge. (Refer to...) Figure 4 A first bridge 1 was created in the gateway virtual machine, and the interface vxlan1 in the gateway virtual machine can be logically connected to bridge 1.

[0096] S303. Create a gateway interface pair including a first interface and a second interface, wherein the first interface is logically connected to the first bridge and the second interface is assigned a first IP address.

[0097] Furthermore, within the gateway virtual machine, gateway interface pairs can be created, including a first interface and a second interface. The first and second interfaces are inherently interconnected, essentially acting as the two ends of a pipe. The first interface can then be logically connected to the first bridge, allowing data transmitted through the first bridge to reach the second interface via the first interface.

[0098] In this embodiment, a first IP address is assigned to the second interface so that relevant routing information can be set according to the IP address of the second interface, thereby effectively realizing data flow.

[0099] For example, it can be combined Figure 4 To understand this, assume that a gateway interface pair is created in the gateway virtual machine, including a first interface 1 and a second interface 2. The first interface 1 is logically connected to the first bridge, and the second interface 2 is assigned a first IP address: 172.255.1.x / 24.

[0100] In one possible implementation, the gateway virtual machine may include a VPN (Virtual Private Network) agent unit. The creation of VXLAN tunnels, population of FDB tables, creation of bridges, establishment of logical connections, and allocation of IP addresses to interfaces described above can all be completed by the VPN agent in the gateway virtual machine.

[0101] S304. Determine the first sub-channel. The first sub-channel transmits data sequentially through the second interface, the first interface, the first bridge, and the interface of the VXLAN tunnel in the gateway virtual machine.

[0102] Based on the work done above, the first sub-channel can be determined, for example, by referring to... Figure 4 Understandably, the first sub-channel in the gateway virtual machine can transmit data sequentially through the second interface 2, the first interface 1, the first bridge, and the VXLAN tunnel via the interface VXLAN1 in the gateway virtual machine.

[0103] and reference Figure 4 It is certain that the gateway virtual machine also includes two network cards, namely eth1 and eth0. The data transmitted in the first sub-channel will actually reach the routing virtual machine through eth1, because the VXLAN tunnel is established based on the peer's EIP, so it can reach the routing virtual machine through the network card.

[0104] S305. In the routing virtual machine, create a VXLAN tunnel based on the IP address of the gateway virtual machine.

[0105] The above describes a series of creation operations in the gateway virtual machine. In fact, similar creation operations will also be performed in the routing virtual machine. The content of S305 has been explained in S301 above, and will not be repeated here.

[0106] S306. Create a second bridge, where the interface of the VXLAN tunnel in the routing virtual machine is logically connected to the second bridge.

[0107] Furthermore, the operation of the routing virtual machine in creating a second bridge is similar to the implementation of the gateway virtual machine mentioned above.

[0108] You can refer to Figure 4 To understand further, Figure 4 In this embodiment, the vxlan1 interface in the routing virtual machine is logically connected to the second bridge to ensure that data transmitted through the vxlan tunnel can reach the second bridge. Similarly, the second bridge in this embodiment can be, for example, a br-vpn bridge.

[0109] S307. Create a gateway interface pair including a third interface and a fourth interface, wherein the third interface is logically connected to the second bridge, and the fourth interface is assigned a second IP address.

[0110] Furthermore, the operations related to creating gateway interface pairs in the routing virtual machine are similar to the implementation of the gateway virtual machine described above. This can be combined with... Figure 4 To understand this further, suppose a gateway interface pair is created in the routing virtual machine, including a third interface 3 and a fourth interface 4. The third interface 3 is logically connected to the second bridge, and the fourth interface 4 is assigned a second IP address: 172.255.1.1 / 24.

[0111] In one possible implementation, a VPN agent unit can also be included in the routing virtual machine. The creation of VXLAN tunnels, population of FDB tables, creation of bridges, establishment of logical connections, and allocation of IP addresses to interfaces described above can all be completed by the VPN agent in the routing virtual machine.

[0112] S308. Determine the second sub-channel. The second sub-channel transmits data sequentially through the interface of the VXLAN tunnel in the routing virtual machine, the second bridge, the third interface, and the fourth interface.

[0113] Based on the work done above, the second sub-channel can be determined, for example, by referring to... Figure 4 As you can understand, the second sub-channel in the routing virtual machine can transmit data sequentially through the VXLAN tunnel to the interfaces vxlan1, the second bridge, the third interface 3, and the fourth interface 4 in the routing virtual machine.

[0114] and reference Figure 4It is certain that the routing virtual machine also includes two network cards, namely eth1 and eth0. The data transmitted in the second sub-channel will actually reach the routing virtual machine through eth1, because the VXLAN tunnel is established based on the EIP of the peer, so it can reach the routing virtual machine through the network card.

[0115] S309. Determine the virtual link based on the first sub-channel and the second sub-channel.

[0116] Based on the first and second sub-channels described above, a virtual link for data transmission between the routing virtual machine and the gateway virtual machine can be constructed. In actual implementation, the order in which the first and second sub-channels are created can be determined according to actual needs; this embodiment does not impose any restrictions on their execution order.

[0117] In this embodiment, by performing the series of creation tasks described above in the gateway virtual machine and the routing virtual machine respectively, a virtual link can be effectively established between the routing virtual machine and the gateway virtual machine to construct a virtual topology structure that enables data transmission between the routing virtual machine and the gateway virtual machine, thus providing virtual topology support for subsequent data transmission.

[0118] The above describes how to create a virtual link. However, a virtual link only provides a link for data transmission. How the data is actually transmitted still requires configuring the corresponding routing information. The following section will discuss this in conjunction with... Figure 4 The first routing information and the second routing information in this embodiment will be described in further detail.

[0119] Before introducing the routing information, the following additional information needs to be explained:

[0120] When a client in the second cloud environment needs to access a target service in the first cloud environment, it typically needs to initiate a service configuration request. The mock service in the first cloud environment can then assign a virtual IP address to the target service within a predefined network segment corresponding to the first cloud environment, based on this service configuration request. The client in the second cloud environment can then access the target service using this virtual IP address.

[0121] In one possible implementation, the service configuration request described above can also be understood as requesting the creation of a Single Tunnel. The purpose of a Single Tunnel is to enable an instance in a specified VPC to access services in the first cloud environment through this tunnel. Therefore, the virtual IP address described above can be understood as creating a Single Tunnel, and then configuring a virtual IP address for the Single Tunnel.

[0122] Based on the virtual IP addresses introduced so far, the following will combine... Figure 4 Understand the first and second routing information.

[0123] In this embodiment, the first routing information is used to instruct that requests to access the first cloud environment be sent to the gateway virtual machine. The client in the second cloud environment can initiate an access request to the target service in the first cloud environment; based on the above description, it can be determined that the access request is initiated based on the virtual IP address.

[0124] The first routing information can be further interpreted as a request whose destination address is an address within a preset network segment corresponding to the first cloud environment, and whose next hop points to the gateway virtual machine. Specifically, the next hop could be a network interface card (NIC) pointing to the gateway virtual machine (e.g., ...). Figure 4 The IP address of either eth1 or eth0.

[0125] The virtual IP address is determined within the preset network segment corresponding to the first cloud environment. Therefore, based on the virtual IP address of the access request, it can be determined that the access request was initiated to the first cloud environment. Then, in the second cloud environment, the access request will be naturally forwarded to the gateway virtual machine.

[0126] And, in this embodiment, the second routing information is:

[0127] If the destination address of the access request reaching the gateway virtual machine is a virtual IP address, then the next hop of the access request is determined to be the IP address of the fourth interface in the routing virtual machine;

[0128] If the destination address of the access request reaching the routing virtual machine is a virtual IP address, then the next hop of the access request is determined to be the real IP address of the target service, or the IP address of the target interface of the SLB virtual machine.

[0129] The second routing information can be understood as being configured for a virtual IP address (or single tunnel). For example, the mock service can configure the second routing information to the proxy unit of the gateway virtual machine and the proxy unit of the routing virtual machine to complete the configuration of the second routing information in the corresponding virtual machine.

[0130] Specifically, in the gateway virtual machine, if the access request is to access the target service, the access request can be directly forwarded to the fourth interface in the routing virtual machine through the virtual link described above. Similarly, in the routing virtual machine, if the access request is to access the target service, the access request can be directly forwarded to the real IP address of the target service, or the IP address of the target interface of the SLB virtual machine.

[0131] Based on the first and second routing information described above, the following section combines... Figure 4This document provides a detailed explanation of the data flow process for clients accessing target services in the first cloud environment from the second cloud environment. For ease of understanding, the first cloud environment is a classic cloud environment, and the second cloud environment is a private cloud environment, as examples. When the first and second cloud environments are implemented in other ways, the specific implementation is similar.

[0132] like Figure 4 As shown, the data flow process can include steps 1 through 5, which will be described in turn below:

[0133] 1. A client in a private cloud environment initiates an access request, which is then forwarded to the gateway virtual machine.

[0134] Reference Figure 4 The source IP address of the access request initiated by the client in the private cloud environment is 192.168.1.x, which is... Figure 4 The diagram illustrates the IP address of a VPC, where CIDR stands for Classless Inter-Domain Routing, a method used to assign IP addresses to users and routes.

[0135] The target IP address of the access request is 10.202.aa.x, which is assumed to be the virtual IP address assigned to the target service as described above. Based on the first routing information described above, the access request will be forwarded to the gateway virtual machine.

[0136] 2. The gateway virtual machine forwards access requests to the routing virtual machine based on the virtual link and the second routing information.

[0137] If the second routing information indicates that the target address of the access request is a virtual IP address, then the next hop for the access request is determined to be the IP address of the fourth interface in the routing virtual machine. Figure 4 The IP address of interface 4 in the code.

[0138] Reference Figure 4 The gateway virtual machine will forward access requests to the fourth interface 4 in the routing virtual machine through the path of interface 2, interface 1, bridge 1, vxlan tunnel (vxlan1 in the gateway virtual machine, eth1 in the gateway virtual machine, eth1 in the routing virtual machine, vxlan1 in the routing virtual machine), bridge 2, interface 3, and interface 4.

[0139] In one implementation, the gateway virtual machine is also configured with SNAT (Source Network Address Translation) rules. The SNAT rules instruct that the source address of data destined for the classic cloud environment be disguised as the IP address of the second interface in the gateway virtual machine. This ensures that when data is returned later, it can successfully reach the gateway virtual machine.

[0140] In other words, based on SNAT rules, the gateway virtual machine will modify the source address of the access request to the IP address of interface 2: 172.255.1.x, to ensure that the data returned by the target service can reach interface 2.

[0141] 3. Based on IP forwarding in the routing virtual machine, the access request is forwarded to the interface bond0.9.

[0142] In the routing virtual machine, you can enable IP forwarding (or IP routing). IP forwarding is configured to show how data is forwarded between different interfaces. (See reference...) Figure 4 For example, based on IP forword, access requests can be forwarded from interface 4 to interface bond0.9. A brief explanation of the bond interface (or port, network card) is needed here. bondx is not a physical port; it uses physical port bonding technology to achieve network interface redundancy and load balancing, thereby achieving high availability of the network interface. In other words, network card bonding binds multiple network cards into a single logical network card, achieving local network card redundancy, bandwidth expansion, and load balancing.

[0143] Reference Figure 4 It is understandable that during the forwarding process in step 3, the source address of the access request is the IP address of the disguised interface 2 described above, and the target address is still the virtual IP address of the target service.

[0144] 4. The routing virtual machine forwards access requests to interface bond0 in the slb virtual machine based on the virtual link between it and the slb virtual machine and the second routing configuration.

[0145] The virtual link between the routing virtual machine and the SLB virtual machine is similar to that described above and will not be repeated here. Based on a similar approach, access requests can be forwarded to interface bond0 in the SLB virtual machine. Interface bond0 can be understood as the target interface of the SLB virtual machine, for example, as the end interface of the virtual link between the routing virtual machine and the SLB virtual machine within the SLB virtual machine. In actual implementation, the target interface in the SLB virtual machine can be selected according to actual needs. This embodiment does not impose any restrictions on this, as long as it can achieve the goal of forwarding access requests from the routing virtual machine to the SLB virtual machine.

[0146] Since both the routing virtual machine and the SLB virtual machine are in a classic cloud environment, the bridge in the virtual link between the routing virtual machine and the SLB virtual machine can be, for example, a br-ece bridge.

[0147] Similarly, before forwarding, the routing virtual machine also disguises the source address of the access request based on SNAT rules. Specifically, it disguises it as the IP address of the fourth interface 4 of the routing virtual machine: 172.255.1.x, to ensure that the data returned by the target service can be successfully returned through the routing virtual machine.

[0148] 5. The access request is forwarded to the middleware of the SLB virtual machine via the interface bond0.

[0149] The intermediate component can be, for example, an nginx server set up in an SLB virtual machine, or its implementation can be chosen according to actual needs, as long as the intermediate component can perform address translation and data sending and receiving.

[0150] Reference Figure 4 Inside the SLB virtual machine, access requests can be forwarded to intermediate components via the bond0 interface, and the specific forwarding rules can also be determined based on the configured routing information.

[0151] 6. The intermediate component determines the real IP address corresponding to the virtual IP address and forwards the access request to the real IP address.

[0152] The intermediate component can determine the mapping between virtual IP addresses and the real IP addresses of the target service. Therefore, it can identify the real IP address corresponding to the virtual IP address in the access request. Then, for example, it can modify the target address of the access request to the real IP address and forward the access request to the real IP address based on the modified target address, thus sending the access request to the target service. The real IP address can be understood as the IP address of the server corresponding to the target service.

[0153] Similar to the above, source address masquerading is also required in the SLB virtual machine, see [reference]. Figure 4 In access requests sent to the real IP address, the source address is disguised as the IP address of the intermediate component, and the target address is modified to the real IP address.

[0154] In this embodiment, the access request is forwarded to the gateway virtual machine using the first routing information. Then, the gateway virtual machine forwards the access request to the routing virtual machine based on the second routing information and the virtual link. Since both the routing virtual machine and the target service reside in the classic cloud environment, the routing virtual machine can easily forward the access request to the target service through the intermediate components in the SLB, thus effectively enabling access from the private cloud environment to services in the classic cloud environment. Furthermore, when forwarding access requests, the gateway virtual machine, the routing virtual machine, and the SLB virtual machine all masquerade the source address of the access request to ensure that when the target service returns data to the private cloud environment, it can send the data to the client in the private cloud environment through the series of links described above.

[0155] The above is based on Figure 4 The description explains that after the routing virtual machine forwards the access request, an intermediate component needs to determine the corresponding real IP address from the virtual IP address in the access request. Then, it initiates access to the target service based on the real IP address. This scenario typically involves one virtual IP address corresponding to one or more real IP addresses; that is, a correspondence exists between the virtual and real IP addresses, but these two IP addresses are not identical. Therefore, in such cases, an intermediate component is often needed to determine the real IP address corresponding to the virtual IP address before initiating access to the target service based on that real IP address.

[0156] However, there is a special case: when accessing basic services in a classic cloud environment, it's not necessary to distinguish between products deployed in the classic cloud environment or modify the products. In this case, the virtual IP address and the real IP address must be the same. In practice, a field is set on the mock service that allows the business side to clearly distinguish between the two IP addresses, enabling the mock SLB virtual machine to differentiate them. However, the routing virtual machine and the gateway virtual machine are unaware of this distinction. When the virtual IP address and the real IP address are the same, the routing virtual machine can directly send access requests to the target service based on the virtual IP address without relying on the SLB virtual machine. The following section will explain... Figure 5 Let's provide a more detailed explanation of the current situation.

[0157] Figure 5 A schematic diagram of the transmission of access requests provided in the embodiments of this application. Figure 2 ,like Figure 5As shown, the method also includes steps 1 to 5.

[0158] Steps 1 through 4 are the same as those described in the above embodiments, and will not be repeated here.

[0159] Steps 4 and 5, which differ from those described above, will be explained separately below.

[0160] Step 4: The routing virtual machine forwards access requests to the bond0 interface of the virtual machine where the real server resides, based on the virtual link between the virtual machine and the real server and the second routing configuration.

[0161] When the routing virtual machine sends access requests to the real server, it also transmits the data through a virtual link between the routing virtual machine and the virtual machine where the real server resides. The configuration of the virtual link and the second route is similar to that described above. Based on a similar implementation method, refer to... Figure 5 The access request can first be forwarded to the bond0 interface of the virtual machine where the real server is located.

[0162] The interface bond0 can be understood as the end interface of the virtual link between the routing virtual machine and the SLB virtual machine in the SLB virtual machine. Therefore, when forwarding access requests to the real server, the access requests can be forwarded to the interface bond0 first, and then data can be transmitted through the virtual link.

[0163] Step 5: Forward the access request to the real IP address via the bond0 interface.

[0164] The access request can then be forwarded to the real IP address via the bond0 interface. In this embodiment, the real IP address and the virtual IP address are the same, therefore refer to... Figure 5 The target IP address of the access request in step 5 is 10.202.aa.x, which is the IP address of the real server.

[0165] In this embodiment, when the real IP address and virtual IP address of the target service are the same, the IP address mapping process can be skipped by the SLB virtual machine. Instead, the routing virtual machine directly forwards the access request to the real IP address, thus enabling convenient and effective access to the target service in this scenario.

[0166] The above Figure 4 and Figure 5The embodiments described above illustrate an implementation method where a virtual IP address is allocated to a target service in response to a service configuration request. Subsequently, an access request initiated based on the virtual IP address can effectively enable service access from the second cloud environment to the first cloud environment. The service configuration request described in the above embodiments can be understood as a request to create a Single Tunnel. The role of the Single Tunnel is to allow a specific instance in the VPC to access services in the first cloud environment through this channel; that is, a Single Tunnel is created for that specific instance to enable access to the target service.

[0167] In another possible implementation, the service configuration request can also be a request to create an AnyTunnel. The purpose of AnyTunnel is to enable any instance in any VPC created by the user to access the service in the first cloud environment through this channel. In other words, it can be understood that the user has created a corresponding channel to achieve access to the target service.

[0168] For service configuration requests that request the creation of Any Tunnel, the above-described configuration operations need to be performed on all existing VPCs of the current user, and also on any newly added VPCs of the user. This will enable effective access to basic services in the First Cloud environment from any VPC.

[0169] In addition to the cloud environment access method provided in this application, there is another application scenario, namely, accessing services in a second cloud environment from a first cloud environment. This scenario will be further described in detail below with reference to specific embodiments.

[0170] First, combine Figure 6 To introduce, Figure 6 The flow of the cloud environment access method provided in the embodiments of this application Figure 3 .

[0171] like Figure 6 As shown, the method includes:

[0172] S601. Configure first routing information in the first cloud environment. The first routing information is used to instruct that access requests be sent to the routing virtual machine. The access request is used to request access to the target service in the second cloud environment.

[0173] In this embodiment, a routing virtual machine is created in the first cloud environment, which is used to implement data transmission between the second cloud environment and the first cloud environment. It is understood that multiple virtual machines can be created in the first cloud environment according to actual needs, each of which can perform corresponding functions. In this embodiment, the routing virtual machine is specifically designed for implementing data transmission.

[0174] Furthermore, first routing information can be configured in the first cloud environment. The routing information can indicate the direction of data flow. In the first cloud environment, data needs to be transmitted through the routing virtual machine and the second cloud environment. Therefore, in this embodiment, the first routing information is configured to indicate that the access request for the target service in the second cloud environment is sent to the routing virtual machine.

[0175] In one possible implementation, a processing node in the first cloud environment can initiate an access request to the second cloud environment. The processing node can be a client, server, container, etc., which can be selected according to actual needs.

[0176] The access request may include a source address and a destination address. If the destination address is the IP address assigned to the target service, then in the first cloud environment, the access request can be sent to the routing virtual machine based on the first routing information.

[0177] S602. Establish a virtual link between the routing virtual machine and the gateway virtual machine. The virtual link is used for data transmission between the routing virtual machine and the gateway virtual machine.

[0178] S603. Configure the second routing information. The second routing information is used to instruct the routing virtual machine to send the access request to the gateway virtual machine.

[0179] The implementation methods of S602 and S603 are similar to those of S202 and S203 described above. The specific implementation methods of the virtual link can be referred to the description of the above embodiments, and will not be repeated here.

[0180] The difference is that, since this embodiment describes the access of the first cloud environment to the second cloud environment, the second routing information is used to instruct the routing virtual machine to send the access request to the gateway virtual machine.

[0181] S604. Based on the first routing information, the second routing information, and the virtual link, the access request is forwarded to the gateway virtual machine via the routing virtual machine, and the gateway virtual machine sends the access request to the target service.

[0182] After completing the relevant configurations described above, the access requests initiated in the first cloud environment can be forwarded to the gateway virtual machine through the routing virtual machine based on the first routing information, the second routing information, and the virtual link described above. The gateway virtual machine then sends the access requests to the corresponding target service, thereby effectively enabling the first cloud environment to access the target service in the second cloud environment.

[0183] The cloud environment access method provided in this application includes: configuring first routing information in a first cloud environment, wherein the first routing information is used to instruct the access request to be sent to a routing virtual machine, and the access request is used to request access to a target service in a second cloud environment; establishing a virtual link between the routing virtual machine and the gateway virtual machine, wherein the virtual link is used for data transmission between the routing virtual machine and the gateway virtual machine; configuring second routing information, wherein the second routing information is used to instruct the routing virtual machine to send the access request to the gateway virtual machine; and, based on the first routing information, the second routing information, and the virtual link, forwarding the access request through the routing virtual machine to the gateway virtual machine, and then having the gateway virtual machine send the access request to the target service. By configuring the sending of the access request to the routing virtual machine in the first cloud environment, establishing a corresponding virtual link between the gateway virtual machine in the second cloud environment and the routing virtual machine in the first cloud environment, and configuring corresponding second routing rules, it is possible to send access requests for a target service initiated in the first cloud environment to the target service in the second cloud environment via the routing virtual machine and the gateway virtual machine. By configuring the routing and link described above, access from the first cloud environment to the target service in the second cloud environment can be effectively achieved.

[0184] In this embodiment, the method for establishing the virtual link between the routing virtual machine and the gateway virtual machine is similar to that described above, and will not be repeated here.

[0185] Furthermore, the following is combined with Figure 7 This application provides a more detailed description of the implementation of the first and second routing information in the cloud environment access method provided, specifically in the application scenario where the first cloud environment accesses the second cloud environment. Figure 7 A schematic diagram of the transmission of access requests provided in the embodiments of this application. Figure 3 .

[0186] Before introducing the routing information, the following additional information needs to be explained:

[0187] When a processing node in the first cloud environment needs to access a target service in the second cloud environment, it is usually the processing node in the first cloud environment that initiates a service configuration request. Then, the mock-service in the first cloud environment can assign a virtual IP address to the target service in response to the service configuration request, and determine the relay IP address corresponding to the virtual IP address in the preset network segment of the second cloud environment.

[0188] The virtual IP address is similar to that described above. Processing nodes in the first cloud environment will use this virtual IP address to access the target service. However, in this embodiment, it is also necessary to determine the corresponding relay IP address for the virtual IP address because the various VPCs are isolated from each other, and address overlap may occur. In this case, the correspondence between the virtual IP address and the real IP address of the target service is not unique, which may lead to access errors.

[0189] For example, in VPC1, the real IP of service 1 is IP1, and in VPC2, the real IP of service 2 is also IP1. Then, assuming that a virtual IP address of IP3 is assigned to service 1, then IP3 and IP1 have a corresponding relationship. However, based on this correspondence, it is impossible to determine whether the corresponding IP1 is service 1 in VPC1 or service 2 in VPC2.

[0190] Therefore, this embodiment introduces a relay IP pool. For example, 172.200.0.0 / 16 can be used as the relay IP pool. Each VPC can be allocated a dedicated preset network segment within this pool, such as 172.200.0.0 / 24 for a specific VPC. Then, within each VPC's corresponding preset network segment, appropriate relay IPs are assigned to their respective services, ensuring a one-to-one relationship between the relay IP and the real IP. Furthermore, because each VPC determines its relay IP within its own preset network segment, it is guaranteed that the relay IPs will not overlap.

[0191] The relay IP can be understood as an IP address that is assigned to the real IP of the service and will not overlap with it. Based on the correspondence between the virtual IP address and the relay IP address, it can be guaranteed that the correct service can be accessed and that access errors will not occur.

[0192] The relationship between a virtual IP address and a relay IP address can be one-to-one. For example, if a service configuration request is used to request the allocation of a virtual IP address for a target service, then a virtual IP address and a corresponding relay IP address can be allocated to this target service. In this case, the virtual IP address and the relay IP address are also in a one-to-one relationship.

[0193] Alternatively, the relationship between virtual IP addresses and relay IP addresses can also be one-to-many. For example, if a service configuration request is used to request the allocation of virtual IP addresses for multiple target services, then a single virtual IP address can be allocated to all these target services. However, each target service has its own separate relay IP address. In this case, the relationship between virtual IP addresses and relay IP addresses is also one-to-many.

[0194] In one possible implementation, the service configuration request described above can also be understood as requesting the creation of a reverse VPC access channel. The purpose of the reverse VPC access channel is to enable servers, virtual machines, and containers in the first cloud environment to access services in the second cloud environment through this channel. Therefore, the virtual IP address described above can be understood as creating a reverse VPC access channel, and then configuring a virtual IP address for the reverse VPC access channel.

[0195] Based on the virtual IP addresses introduced so far, the following will combine... Figure 7 To understand the second routing information.

[0196] In this embodiment, the first routing information is used to instruct the intermediate component in the SLB virtual machine to send the access request to the routing virtual machine. Specifically, the processing node in the first cloud environment can initiate an access request to the target service in the second cloud environment. Based on the above description, it can be determined that the access request is initiated based on the virtual IP address.

[0197] The first routing information can be further interpreted as follows: for requests whose destination address is a virtual IP address, the next hop is directed to the routing virtual machine. Specifically, the next hop can be the network interface card (NIC) of the routing virtual machine (e.g., ...). Figure 7 The IP address of either eth1 or eth0.

[0198] Furthermore, in this embodiment, the second routing information is used to instruct the routing virtual machine to send the access request to the gateway virtual machine. It can be further understood as follows: if the destination address of the access request arriving at the routing virtual machine is a relay IP address, then the next hop of the access request is determined to be the IP address of the second interface in the gateway virtual machine.

[0199] Based on the first and second routing information described above, the following section combines... Figure 7 This document provides a detailed explanation of the data flow process for processing nodes in the first cloud environment to access target services in the second cloud environment. For ease of understanding, the first cloud environment is a classic cloud environment, and the second cloud environment is a private cloud environment. The specific implementation is similar when the first and second cloud environments are implemented in other ways.

[0200] like Figure 7As shown, the data flow process can include steps 1 through 5, which will be described in turn below:

[0201] 1. In a classic cloud environment, the processing node initiates an access request, and the intermediate component in the SLB virtual machine obtains the access request by listening.

[0202] In this embodiment, the front-end listening address of the intermediate component (e.g., nginx) in the SLB virtual machine is the virtual IP address for access requests. When the processing node in the classic cloud environment initiates an access request, the intermediate component can obtain the access request by listening.

[0203] In one possible implementation, the SLB virtual machine can also include an SLB agent unit. In this embodiment, all configuration operations of the SLB virtual machine can be completed by the SLB agent unit.

[0204] Reference Figure 7 In a classic cloud environment, the source IP address of the access request initiated by the processing node is 10.202.xx, which is... Figure 7 The diagram illustrates the IP address of the processing node in a classic cloud environment. The target IP address of the access request is the virtual IP assigned to the target service. Based on the first routing information described above, the access request will be forwarded to the routing gateway virtual machine.

[0205] 2. The intermediate component forwards the access request to the interface bond0 in the SLB virtual machine based on the first routing information.

[0206] In this embodiment, the first routing information indicates that the access request should be sent to the routing virtual machine. The virtual link between the routing virtual machine and the SLB virtual machine and the corresponding routing configuration are similar to those described above. Based on a similar approach, the intermediate component can first forward the access request to the interface bond0 in the SLB virtual machine based on the first routing information. The bond0 interface is the end interface of the virtual link between the routing virtual machine and the SLB virtual machine in the SLB virtual machine.

[0207] In one possible implementation, the intermediate component can determine the correspondence between the virtual IP, the relay IP, and the real IP. In order to ensure that the corresponding service can be accessed correctly, this embodiment also sets that if the destination address of the access request arriving at the intermediate component is the virtual IP address, the intermediate component will modify the destination address of the access request to the relay IP address.

[0208] In other words, the target address of the access request is modified to the relay IP corresponding to the virtual IP in the intermediate component. When the virtual IP corresponds to multiple relay IPs, the target address is modified to multiple relay IPs.

[0209] Reference Figure 7 The intermediate component modifies the target IP in the access request to a relay IP: 172.200.0.xx / 32. Furthermore, to ensure that the data from the VPC's response to the access request successfully reaches the corresponding processing node, the SLB virtual machine also performs source address masquerading. (See reference...) Figure 7 The intermediate component will modify the source IP in the access request to the IP of the intermediate component.

[0210] 3. The access request is forwarded to the routing virtual machine via the bond0 interface.

[0211] In this embodiment, the virtual link between the routing virtual machine and the SLB virtual machine is similar to that described above, and will not be repeated here. Based on a similar approach, access requests can be forwarded to bond0.9 of the routing virtual machine via the bond0 interface through the virtual link. The specific forwarding rules can also be determined based on the configured routing information.

[0212] 4. Based on IP forwarding in the routing virtual machine, forward the access request to interface 4.

[0213] You can enable IP forwarding in the router virtual machine. IP forwarding configures how data is forwarded between different interfaces. (See reference...) Figure 7 For example, based on the IP forword, access requests can be forwarded from interface bond0.9 to interface bond4.

[0214] 5. The routing server forwards access requests to the gateway virtual machine based on the virtual link configured with the second routing information.

[0215] The second routing information indicates that if the destination address of the access request arriving at the routing virtual machine is a transit IP address, then the next hop of the access request is determined to be the IP address of the second interface in the gateway virtual machine. In other words... Figure 7 The IP address of interface 1 in the system.

[0216] Reference Figure 7 The routing virtual machine will forward access requests to the second interface 2 in the gateway virtual machine through the path of interface 4, interface 3, bridge 2, vxlan tunnel (vxlan1 in the routing virtual machine, eth1 in the routing virtual machine, eth1 in the gateway virtual machine, vxlan1 in the gateway virtual machine), bridge 1, interface 1 and interface 2.

[0217] In one implementation, the routing virtual machine is also configured with SNAT rules. The SNAT rules instruct the source address of data destined for the private cloud environment to be disguised as the IP address of the fourth interface in the routing virtual machine. This ensures that when data is returned later, it can successfully reach the routing virtual machine.

[0218] In other words, based on the SNAT rules, the routing virtual machine will modify the source address of the access request to the IP address of interface 4: 172.255.1.1 / 24, to ensure that the data returned by the target service can reach interface 4.

[0219] 6. The gateway virtual machine modifies the target address of the access request to the real IP address corresponding to the relay IP address, and forwards the access request to the real IP address.

[0220] In this embodiment, the relay IP and the real IP have a one-to-one relationship, so the real IP address corresponding to the relay IP address in the access request can be determined. A DNAT (Destination Network Address Translation) rule can be configured in the gateway virtual machine. This DNAT rule instructs the target address in the access request to be modified to the real IP address, which is the IP address of the server corresponding to the target service.

[0221] Similar to the above, the gateway virtual machine also needs to be configured with SNAT rules to masquerade the source address. The SNAT rule can be: to masquerade the source IP of the data that needs to be sent out via eth0 as the IP address of the gateway virtual machine's eth0.

[0222] Then refer to Figure 7 In access requests sent to the real IP address, since the access request needs to be sent through eth0, the source address is disguised as the IP address of eth0 to ensure that the subsequent reply data can reach eth0 and return along the original link.

[0223] It is understandable that the SNAT and DNAT rules mentioned above are rules configured for access requests initiated in classic cloud environments. They specify how to masquerade or modify the address when the access request enters the VPC from the gateway virtual machine.

[0224] Furthermore, the target service in the VPC can also return response information corresponding to the access request to the classic cloud environment. When the gateway virtual machine sends the response information, the corresponding SNAT rules also need to be configured. In this case, the SNAT rule can be: if a data packet with the source address of the target service's real IP is received, its source address is modified to the relay IP corresponding to that real IP. Based on such an SNAT rule, it can be ensured that the processing node that initiated the access request can determine that the response information comes from the relay IP it accessed.

[0225] Then refer to Figure 7 The gateway virtual machine will forward access requests to the target service through eth0. The source IP is the IP of eth0, and the destination IP is the real IP of the target service.

[0226] In this embodiment, an intermediate component listens for access requests and forwards them to a routing virtual machine using first routing information. The routing virtual machine then forwards the access requests to a gateway virtual machine based on second routing information and virtual links. Since both the gateway virtual machine and the target service reside in the second cloud environment, the gateway virtual machine can easily forward access requests to the target service, effectively enabling access from the first cloud environment to services in the second cloud environment. Furthermore, when forwarding access requests, the gateway virtual machine, routing virtual machine, and intermediate component all masquerade the source address of the access request to ensure that when the target service returns data to the first cloud environment, it can send the data to the processing module in the first cloud environment through the aforementioned series of links.

[0227] Based on the various embodiments described above, the following will be combined with Figure 8 The software architecture involved in this application will be further described below. Figure 8 A schematic diagram of the software architecture of the cloud environment access method provided in the embodiments of this application.

[0228] like Figure 8 As shown, the upper-level main entry point can be understood as the entry point of the entire software architecture. It can implement functions such as UI interface, log aggregation, and data storage. For example, the creation of a private cloud environment can be triggered in the upper-level main entry point, as well as the destruction of resources when the environment is released.

[0229] The service provider (SP) is responsible for starting the mock service, injecting the basic configuration of the first cloud platform, and starting the various components on the mock server to ensure its proper functioning. (See also...) Figure 8SP services can also release resources. For example, resources in the main VPC can be released through the corresponding interface in the public cloud, or all resources related to the private cloud environment can be directly destroyed. The specific resource destruction method can be selected and set according to actual needs.

[0230] The control unit provides rapid operation and maintenance as well as query capabilities. Specifically, the mock service collects log and status data from each virtual machine and reports component status and log information to the control unit. The software architecture may also include public cloud databases and object storage to provide support for upper-layer data and the control unit.

[0231] Among them, mock-service is responsible for intercepting the open API (Open Application Programming Interface) of ECS, VPC, and SLB of private cloud, and after internal logic adaptation, it redirects the corresponding operations of the actual new resources to the open API of public cloud, so as to realize the CRUD operations of basic resources.

[0232] Combination Figure 8 To understand the specific implementation of mock-service, suppose a product or platform calls the ECS or VPC interface to create an ECS or VPC. The HTTP (Hypertext Transfer Protocol) server within the mock-service can intercept this creation request and, through the CRUD (Create, Read, Update, Delete) functionalities of the ECS or VPC within the mock-service, redirect the actual operations for creating the new resource to the public cloud's ECS or VPC interface. Here, the public cloud's ECS interface can be understood as the public cloud's ECS SDK (Software Development Kit) / OpenAPI, and the public cloud's VPC interface can be understood as the public cloud's VPC SDK / OpenAPI.

[0233] Furthermore, within mock-servic, the creation status of VPCs and ECSs can be monitored, and the public cloud's OpenAPI interface can be called at appropriate times to create gateway virtual machines and SLB virtual machines. VPN agent units and SLB agent units are then deployed on the corresponding virtual machines. These units are responsible for making actual configuration changes when relevant configurations change, ensuring that the actual functions are available.

[0234] The following can be combined Figure 8This section describes how to implement configuration changes for agent units deployed on various virtual machines.

[0235] like Figure 8 As shown, the SLB virtual machine configuration distribution component in the mock-service can send configuration files to the SLB agent unit of the SLB virtual machine. The SLB agent unit can then read the configuration files and perform corresponding configurations in the SLB virtual machine, such as the routing configuration described above.

[0236] Furthermore, the gateway virtual machine configuration distribution component in the mock-service can send configuration files to the VPN agent unit of the gateway virtual machine. The VPN agent unit can then read the configuration file and perform corresponding configurations within the gateway virtual machine, such as the routing configuration described above. Optionally, an FDB agent unit can also exist within the gateway virtual machine. This FDB agent unit can also read the configuration file and execute the FDB table configurations described above.

[0237] Furthermore, the routing virtual machine configuration distribution component in the mock-service can send configuration files to the VPN agent unit of the routing virtual machine. The VPN agent unit can then read the configuration file and perform corresponding configurations within the routing virtual machine, such as the routing configuration described above. The configuration indicated by the configuration file can be understood as the routing configuration described in the above embodiments, and will not be elaborated upon further here.

[0238] In summary, the cloud environment access method provided in this application, by deploying a routing virtual machine in the first cloud environment and a gateway virtual machine in the VPC, and establishing a virtual link between the gateway virtual machine and the routing virtual machine, effectively ensures the communication feasibility between the first and second cloud environments. It also effectively avoids the impact of network isolation, address overlap, and network access restrictions between different VPCs. Furthermore, by configuring corresponding routing information, it ensures that data can be forwarded orderly and correctly between various units, thereby effectively enabling the second cloud environment to access services of the first cloud environment, expanding the application scope of the VPC in the first cloud platform. This method can effectively implement the corresponding configuration for both single-channel and arbitrary-channel scenarios. Simultaneously, it can also effectively enable the first cloud environment to access services of the second cloud environment, expanding the application scope of the first cloud platform deployed on the second cloud platform.

[0239] Figure 9 Schematic diagram of the cloud environment access device provided in the embodiments of this application Figure 1 .like Figure 9As shown, the device 90 includes: a configuration module 901, a processing module 902, and a transmission module 903.

[0240] Configuration module 903 is used to configure first routing information in the second cloud environment, wherein the first routing information is used to indicate that the request to access the first cloud environment is sent to the gateway virtual machine;

[0241] Processing module 902 is used to establish a virtual link between the routing virtual machine and the gateway virtual machine, the virtual link being used for data transmission between the routing virtual machine and the gateway virtual machine;

[0242] The configuration module 903 is further configured to configure second routing information, which is used to instruct the gateway virtual machine to send an access request to the routing virtual machine and to instruct the routing virtual machine to send an access request to the target service. The access request is used to request access to the target service in the first cloud environment.

[0243] The sending module 903 is used to forward the access request to the routing virtual machine through the gateway virtual machine according to the first routing information, the second routing information and the virtual link, and the routing virtual machine sends the access request to the target service.

[0244] In one possible design, the processing module 902 is specifically used to: create a first sub-channel corresponding to the gateway virtual machine in the gateway virtual machine; create a second sub-channel corresponding to the routing virtual machine in the routing virtual machine; and determine the virtual link based on the first sub-channel and the second sub-channel.

[0245] In one possible design, the processing module 902 is specifically configured to: create a virtual extended LAN (VXLAN) tunnel based on the Internet Protocol (IP) address of the routing virtual machine in the gateway virtual machine; create a first bridge, wherein the interface of the VXLAN tunnel in the gateway virtual machine is logically connected to the first bridge; create a gateway interface pair including a first interface and a second interface, wherein the first interface is logically connected to the first bridge and the second interface is assigned a first IP address; determine a first sub-channel, wherein the first sub-channel transmits data sequentially through the second interface, the first interface, the first bridge, and the interface of the VXLAN tunnel in the gateway virtual machine.

[0246] In one possible design, the processing module 902 is specifically configured to: create a VXLAN tunnel based on the IP address of the gateway virtual machine in the routing virtual machine; create a second bridge, wherein the interface of the VXLAN tunnel in the routing virtual machine is logically connected to the second bridge; create a gateway interface pair including a third interface and a fourth interface, wherein the third interface is logically connected to the second bridge and the fourth interface is assigned a second IP address; determine a second sub-channel, wherein the second sub-channel transmits data sequentially through the interface of the VXLAN tunnel in the routing virtual machine, the second bridge, the third interface, and the fourth interface.

[0247] In one possible design, a server load balancer virtual machine (SLB) is also created in the first cloud environment; the processing module 902 is further configured to: allocate a virtual IP address for the target service in a preset network segment corresponding to the first cloud environment according to the service configuration request in the second cloud environment;

[0248] The second routing information includes:

[0249] If the destination address of the access request reaching the gateway virtual machine is the virtual IP address, then the next hop of the access request is determined to be the IP address of the fourth interface in the routing virtual machine; if the destination address of the access request reaching the routing virtual machine is the virtual IP address, then the next hop of the access request is determined to be the real IP address of the target service, or the IP address of the target interface of the SLB virtual machine.

[0250] In one possible design, the sending module 903 is specifically used for: the gateway virtual machine obtaining an access request initiated in the second cloud environment based on the first routing information, wherein the destination address of the access request is the virtual IP address; and the gateway virtual machine sending the access request to the fourth interface in the routing virtual machine based on the second routing information and the virtual link.

[0251] In one possible design, the sending module 903 is specifically used for:

[0252] If the virtual IP address is the same as the real IP address of the target service, the routing virtual machine sends the access request to the target service according to the second routing information; or, if the virtual IP address is not the same as the real IP address of the target service, the routing virtual machine sends the access request to the target interface of the SLB virtual machine according to the second routing information.

[0253] The SLB virtual machine sends the access request to the intermediate component in the SLB virtual machine via the target interface; the intermediate component modifies the target address of the access request to the real IP address, and sends the access request to the target service according to the modified target address.

[0254] The apparatus provided in this embodiment can be used to execute the technical solutions of the above method embodiments. Its implementation principle and technical effects are similar, and will not be described again here.

[0255] Figure 10 Schematic diagram of the cloud environment access device provided in the embodiments of this application Figure 2 .like Figure 10 As shown, the device 100 includes: a configuration module 1001, a processing module 1002, and a transmission module 1003.

[0256] Configuration module 1001 is used to configure first routing information in the first cloud environment. The first routing information is used to instruct the intermediate component in the SLB virtual machine to send an access request to the routing virtual machine. The access request is used to request access to the target service in the second cloud environment.

[0257] Processing module 1002 is used to establish a virtual link between the routing virtual machine and the gateway virtual machine, the virtual link being used for data transmission between the routing virtual machine and the gateway virtual machine;

[0258] The configuration module 1003 is further configured to configure second routing information, which instructs the routing virtual machine to send the access request to the gateway virtual machine.

[0259] The sending module is used to forward the access request to the gateway virtual machine through the routing virtual machine according to the first routing information, the second routing information and the virtual link, and the gateway virtual machine sends the access request to the target service.

[0260] In one possible design, the processing module 1002 is specifically used to: create a first sub-channel corresponding to the gateway virtual machine in the gateway virtual machine; create a second sub-channel corresponding to the routing virtual machine in the routing virtual machine; and generate the virtual link based on the first sub-channel and the second sub-channel.

[0261] In one possible design, the processing module 1002 is specifically configured to: create a VXLAN tunnel based on the IP address of the routing virtual machine in the gateway virtual machine; create a first bridge, wherein the interface of the VXLAN tunnel in the gateway virtual machine is logically connected to the first bridge; create a gateway interface pair including a first interface and a second interface, wherein the first interface is logically connected to the first bridge and the second interface is assigned a first IP address; determine a first sub-channel, wherein the first sub-channel transmits data sequentially through the second interface, the first interface, the first bridge, and the interface of the VXLAN tunnel in the gateway virtual machine.

[0262] In one possible design, the processing module 1002 is specifically configured to: create a VXLAN tunnel based on the IP address of the gateway virtual machine in the routing virtual machine; create a second bridge, wherein the interface of the VXLAN tunnel in the routing virtual machine is logically connected to the second bridge; create a gateway interface pair including a third interface and a fourth interface, wherein the third interface is logically connected to the second bridge and the fourth interface is assigned a second IP address; determine a second sub-channel, wherein the second sub-channel transmits data sequentially through the interface of the VXLAN tunnel in the routing virtual machine, the second bridge, the third interface, and the fourth interface.

[0263] In one possible design, the processing module 1002 is further configured to: allocate a virtual IP address to the target service according to the service configuration request in the first cloud environment, and determine the relay IP address corresponding to the virtual IP address in a preset network segment corresponding to the second cloud environment; and if the destination address of the access request arriving at the intermediate component is the virtual IP address, the intermediate component modifies the destination address of the access request to the relay IP address.

[0264] The second routing information includes: if the destination address of the access request arriving at the routing virtual machine is the transit IP address, then the next hop of the access request is determined to be the IP address of the second interface in the gateway virtual machine.

[0265] In one possible design, the sending module 1003 is specifically used for: the intermediate component listening to obtain the access request; the intermediate component forwarding the access request to the routing virtual machine according to the first routing information; and the routing virtual machine sending the access request to the gateway virtual machine through a virtual link configured with the second routing information.

[0266] In one possible design, the sending module 1003 is specifically used for: the gateway virtual machine modifying the target address of the access request to the real IP address corresponding to the relay IP address; and the gateway virtual machine sending the access request to the target service according to the modified target address.

[0267] The apparatus provided in this embodiment can be used to execute the technical solutions of the above method embodiments. Its implementation principle and technical effects are similar, and will not be described again here.

[0268] Figure 11 A schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application, such as... Figure 11 As shown, the electronic device 110 of this embodiment includes: a processor 1101 and a memory 1102; wherein

[0269] Memory 1102 is used to store computer-executed instructions;

[0270] The processor 1101 is used to execute computer execution instructions stored in the memory to implement the various steps performed by the cloud environment access method in the above embodiments. For details, please refer to the relevant descriptions in the foregoing method embodiments.

[0271] Alternatively, the memory 1102 can be either standalone or integrated with the processor 1101.

[0272] When the memory 1102 is set up independently, the electronic device also includes a bus 1103 for connecting the memory 1102 and the processor 1101.

[0273] This application also provides a computer-readable storage medium storing computer-executable instructions. When a processor executes the computer-executable instructions, it implements the cloud environment access method executed by the above-mentioned electronic device.

[0274] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with relevant laws, regulations and standards, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0275] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some interfaces, devices, or modules, and may be electrical, mechanical, or other forms.

[0276] The integrated modules implemented as software functional modules described above can be stored in a computer-readable storage medium. These software functional modules, stored in a storage medium, include several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute some steps of the methods described in the various embodiments of this application.

[0277] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this invention can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0278] The memory may include high-speed RAM, and may also include non-volatile storage (NVM), such as at least one disk storage device, and may also be a USB flash drive, external hard drive, read-only memory, disk or optical disc, etc.

[0279] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of illustration, the buses shown in the accompanying drawings are not limited to a single bus or a single type of bus.

[0280] The aforementioned storage medium can be implemented from any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. The storage medium can be any available medium accessible to general-purpose or special-purpose computers.

[0281] Those skilled in the art will understand that all or part of the steps of the above-described method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When executed, the program performs the steps of the above-described method embodiments; and the aforementioned storage medium includes various media capable of storing program code, such as ROM, RAM, magnetic disks, or optical disks.

[0282] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A cloud environment access method, characterized in that, The method is applied to a first cloud platform, which is deployed on a second cloud platform. The first cloud platform includes a first cloud environment and a second cloud environment. The first cloud environment is a classic cloud environment, and the second cloud environment is a private cloud environment. The first cloud platform is a dedicated cloud platform, and the second cloud platform is a public cloud platform. A routing virtual machine is created in the first cloud environment, and a gateway virtual machine is created in the second cloud environment. The method includes: Configure first routing information in the second cloud environment, the first routing information being used to indicate that requests to access the first cloud environment should be sent to the gateway virtual machine; A virtual link is established between the routing virtual machine and the gateway virtual machine, and the virtual link is used for data transmission between the routing virtual machine and the gateway virtual machine; Configure second routing information, which is used to instruct the gateway virtual machine to send the access request to the routing virtual machine and to instruct the routing virtual machine to send the access request to the target service, wherein the access request is used to request access to the target service in the first cloud environment; Based on the first routing information, the second routing information, and the virtual link, the access request is forwarded to the routing virtual machine via the gateway virtual machine, and then the routing virtual machine sends the access request to the target service.

2. The method according to claim 1, characterized in that, Establishing the virtual link between the routing virtual machine and the gateway virtual machine includes: In the gateway virtual machine, create the first sub-channel corresponding to the gateway virtual machine; In the routing virtual machine, create the second sub-channel corresponding to the routing virtual machine; The virtual link is determined based on the first sub-channel and the second sub-channel.

3. The method according to claim 2, characterized in that, The step of creating a first sub-channel corresponding to the gateway virtual machine in the gateway virtual machine includes: In the gateway virtual machine, a virtual extended local area network (VXLAN) tunnel based on the Internet Protocol (IP) address of the routing virtual machine is created; Create a first bridge, wherein the interface of the VXLAN tunnel in the gateway virtual machine is logically connected to the first bridge; Create a gateway interface pair including a first interface and a second interface, wherein the first interface is logically connected to the first bridge, and the second interface is assigned a first IP address; The first sub-channel is determined, and the first sub-channel transmits data sequentially through the second interface, the first interface, the first bridge, and the interface of the VXLAN tunnel in the gateway virtual machine.

4. The method according to claim 2, characterized in that, The step of creating a second sub-channel corresponding to the routing virtual machine in the routing virtual machine includes: In the routing virtual machine, a VXLAN tunnel based on the IP address of the gateway virtual machine is created; Create a second bridge, wherein the interface of the VXLAN tunnel in the routing virtual machine is logically connected to the second bridge; Create a gateway interface pair including a third interface and a fourth interface, wherein the third interface is logically connected to the second bridge, and the fourth interface is assigned a second IP address; The second sub-channel is determined, and the second sub-channel transmits data sequentially through the interface of the VXLAN tunnel in the routing virtual machine, the second bridge, the third interface, and the fourth interface.

5. The method according to claim 4, characterized in that, The first cloud environment also contains a server load balancer (SLB) virtual machine. The method further includes: Based on the service configuration request in the second cloud environment, a virtual IP address is allocated for the target service in the preset network segment corresponding to the first cloud environment; The second routing information includes: If the destination address of the access request reaching the gateway virtual machine is the virtual IP address, then the next hop of the access request is determined to be the IP address of the fourth interface in the routing virtual machine; If the destination address of the access request reaching the routing virtual machine is the virtual IP address, then the next hop of the access request is determined to be the real IP address of the target service or the IP address of the target interface of the SLB virtual machine.

6. The method according to any one of claims 1-5, characterized in that, The step of forwarding the access request to the routing virtual machine via the gateway virtual machine based on the first routing information, the second routing information, and the virtual link includes: The gateway virtual machine obtains the access request initiated in the second cloud environment based on the first routing information, and the destination address of the access request is the virtual IP address; The gateway virtual machine sends the access request to the fourth interface in the routing virtual machine based on the second routing information and the virtual link.

7. The method according to claim 6, characterized in that, The step of sending the access request to the target service by the routing virtual machine includes: If the virtual IP address is the same as the real IP address of the target service, then the routing virtual machine sends the access request to the target service according to the second routing information; or, If the virtual IP address is not the same as the real IP address of the target service, the routing virtual machine will send the access request to the target interface of the SLB virtual machine according to the second routing information. The SLB virtual machine sends the access request to the intermediate component in the SLB virtual machine via the target interface; The intermediate component modifies the target address of the access request to the real IP address, and sends the access request to the target service according to the modified target address.

8. A cloud environment access method, characterized in that, The method is applied to a first cloud platform, which is deployed on a second cloud platform. The first cloud platform includes a first cloud environment and a second cloud environment. The first cloud environment is a classic cloud environment, and the second cloud environment is a private cloud environment. The first cloud platform is a dedicated cloud platform, and the second cloud platform is a public cloud platform. Router virtual machines and SLB virtual machines are created in the first cloud environment, and gateway virtual machines are created in the second cloud environment. The method includes: Configure first routing information in the first cloud environment. The first routing information is used to instruct the intermediate component in the SLB virtual machine to send an access request to the routing virtual machine. The access request is used to request access to the target service in the second cloud environment. A virtual link is established between the routing virtual machine and the gateway virtual machine, and the virtual link is used for data transmission between the routing virtual machine and the gateway virtual machine; Configure second routing information, which is used to instruct the routing virtual machine to send the access request to the gateway virtual machine; Based on the first routing information, the second routing information, and the virtual link, the access request is forwarded to the gateway virtual machine via the routing virtual machine, and the gateway virtual machine sends the access request to the target service.

9. The method according to claim 8, characterized in that, Establishing the virtual link between the routing virtual machine and the gateway virtual machine includes: In the gateway virtual machine, create the first sub-channel corresponding to the gateway virtual machine; In the routing virtual machine, create the second sub-channel corresponding to the routing virtual machine; The virtual link is generated based on the first sub-channel and the second sub-channel.

10. The method according to claim 9, characterized in that, The step of creating a first sub-channel corresponding to the gateway virtual machine in the gateway virtual machine includes: In the gateway virtual machine, a VXLAN tunnel based on the IP address of the routing virtual machine is created; Create a first bridge, wherein the interface of the VXLAN tunnel in the gateway virtual machine is logically connected to the first bridge; Create a gateway interface pair including a first interface and a second interface, wherein the first interface is logically connected to the first bridge, and the second interface is assigned a first IP address; The first sub-channel is determined, and the first sub-channel transmits data sequentially through the second interface, the first interface, the first bridge, and the interface of the VXLAN tunnel in the gateway virtual machine.

11. The method according to claim 9, characterized in that, The step of creating a second sub-channel corresponding to the routing virtual machine in the routing virtual machine includes: In the routing virtual machine, a VXLAN tunnel based on the IP address of the gateway virtual machine is created; Create a second bridge, wherein the interface of the VXLAN tunnel in the routing virtual machine is logically connected to the second bridge; Create a gateway interface pair including a third interface and a fourth interface, wherein the third interface is logically connected to the second bridge, and the fourth interface is assigned a second IP address; The second sub-channel is determined, and the second sub-channel transmits data sequentially through the interface of the VXLAN tunnel in the routing virtual machine, the second bridge, the third interface, and the fourth interface.

12. The method according to claim 11, characterized in that, The method further includes: Based on the service configuration request in the first cloud environment, a virtual IP address is allocated to the target service, and a relay IP address corresponding to the virtual IP address is determined in a preset network segment corresponding to the second cloud environment; as well as, If the destination address of the access request arriving at the intermediate component is the virtual IP address, then the intermediate component will modify the destination address of the access request to the relay IP address; The second routing information includes: If the destination address of the access request arriving at the routing virtual machine is the transit IP address, then the next hop of the access request is determined to be the IP address of the second interface in the gateway virtual machine.

13. The method according to any one of claims 8-12, characterized in that, The step of forwarding the access request to the gateway virtual machine via the routing virtual machine based on the first routing information, the second routing information, and the virtual link includes: The intermediate component listens for and receives the access request. The intermediate component forwards the access request to the routing virtual machine based on the first routing information; The routing virtual machine sends the access request to the gateway virtual machine through a virtual link configured with the second routing information.

14. The method according to claim 13, characterized in that, The step of sending the access request to the target service by the gateway virtual machine includes: The gateway virtual machine modifies the target address of the access request to the real IP address corresponding to the relay IP address; The gateway virtual machine sends the access request to the target service based on the modified target address.

15. A cloud environment access device, applied to a first cloud platform, the first cloud platform being deployed on a second cloud platform, the first cloud platform including a first cloud environment and a second cloud environment, the first cloud environment being a classic cloud environment, the second cloud environment being a private cloud environment, the first cloud platform being a dedicated cloud platform, the second cloud platform being a public cloud platform, a routing virtual machine being created in the first cloud environment, and a gateway virtual machine being created in the second cloud environment, characterized in that... include: The configuration module is used to configure first routing information in the second cloud environment, wherein the first routing information is used to indicate that the request to access the first cloud environment is sent to the gateway virtual machine; The processing module is used to establish a virtual link between the routing virtual machine and the gateway virtual machine, and the virtual link is used for data transmission between the routing virtual machine and the gateway virtual machine; The configuration module is further configured to configure second routing information, which is used to instruct the gateway virtual machine to send the access request to the routing virtual machine and to instruct the routing virtual machine to send the access request to the target service. The access request is used to request access to the target service in the first cloud environment. The sending module is used to forward the access request to the routing virtual machine through the gateway virtual machine according to the first routing information, the second routing information and the virtual link, and the routing virtual machine sends the access request to the target service.

16. A cloud environment access device, characterized in that, This is applied to a first cloud platform, which is deployed on a second cloud platform. The first cloud platform includes a first cloud environment and a second cloud environment. The first cloud environment is a classic cloud environment, and the second cloud environment is a private cloud environment. The first cloud platform is a dedicated cloud platform, and the second cloud platform is a public cloud platform. Router virtual machines and SLB virtual machines are created in the first cloud environment, and gateway virtual machines are created in the second cloud environment. (The last part, "including:", appears to be an error and can be omitted.) The configuration module is used to configure first routing information in the first cloud environment. The first routing information is used to instruct the intermediate component in the SLB virtual machine to send an access request to the routing virtual machine. The access request is used to request access to the target service in the second cloud environment. The processing module is used to establish a virtual link between the routing virtual machine and the gateway virtual machine, the virtual link being used for data transmission between the routing virtual machine and the gateway virtual machine; The configuration module is further configured to configure second routing information, which instructs the routing virtual machine to send the access request to the gateway virtual machine. The sending module is used to forward the access request to the gateway virtual machine through the routing virtual machine according to the first routing information, the second routing information and the virtual link, and the gateway virtual machine sends the access request to the target service.

17. An electronic device, characterized in that, include: Memory, used to store programs; A processor for executing the program stored in the memory, wherein when the program is executed, the processor is configured to perform the method as described in any one of claims 1 to 14.

18. A computer-readable storage medium, characterized in that, Includes instructions that, when executed on a computer, cause the computer to perform the method as described in any one of claims 1 to 14.

19. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the method described in any one of claims 1 to 14.

Images