This document provides an example of hybrid access and hybrid addition.
Before migrating to VPC, ensure that:
You are familiar with the VPC and the related products. VPC and the classic network are very different. Apart from the network isolation, VPC enables you to control your private network by using other related products together.
The migration system in this example is quite simple. Many systems are more complex than the example. Before the migration, you need to carefully evaluate the migration system and sort out dependencies of the system.
As shown in the following figure, the system to be migrated consists of SLB, ECS, RDS and OSS. The Internet SLB instances adds two ECS instances as the backend servers and the applications deployed on these two ECS instances have to access RDS and OSS.
The system 2 is relatively complex. As shown in the following figure, the Internet SLB instance adds two ECS instances (ECS 1 and ECS 2) as the backend servers. And these two ECS instances have to access the service of an intranet SLB instance. Similarly, the intranet SLB instance also adds two ECS instances (ECS 3 and ECS 4), on which the applications have to access RDS and OSS.
Prepare the VPC environment.
Firstly, you have to create a VPC and VSwitch to which the system is migrated.
For details, see Build VPC.
Obtain the VPC access endpoint of OSS and RDS.
You can migrate the RDS instance to the VPC either by the API or the console and reserve the classic network endpoint at the same time. For details, see Hybrid access of ApsaraDB for RDS.
After the migration, the classic network endpoint will not be changed. Therefore, the service is not interrupted during the migration. Additionally, the classic network endpoint will be released once the reservation time is reached.
OSS itself has two endpoints, no need to migrate. To obtain the VPC endpoint, see Regions and endpoints.
Create two ECS instances in the VPC and configure the ECS.
As shown in the following figure, set the access endpoint for the applications on the ECS to the VPC endpoint of the RDS and OSS. After configuring, test if the application in the VPC ECS can access the RDS and OSS.
Add the VPC ECS instances to the Internet SLB instance as the backend servers.
Check the health check status of the VPC ECS instances. You can set a smaller weight for the VPC ECS instances to avoid the service interruption due to other exceptions which are not captured by the health check.
Remove the classic ECS instances from the Internet SLB instance.
You can set the weight values of the classic ECS instances to 0 and then remove the classic ECS instances when no more traffic is distributed to them.
Release the classic link ECS instances.
When the system has run smoothly for a while, release the classic ECS instances. Because the SLB instance can add VPC ECS instances as the backend server, no need to migrate SLB. The whole migration process is completed for now.
Note: The classic endpoint of the RDS instance will be automatically deleted when the reservation time is reached.
When migrating a relative complex system as shown in the following figure, if use the same procedure as migrating the system 1, the VPC ECS instances cannot access the classic intranet SLB instance because the SLB does not support hybrid access.
The steps for migrating the system 2 is as follows:
Create two ECS instances in the VPC to migrate the applications deployed in the ECS 3 and ECS 4 in the classic network.
Configure the newly created VPC ECS instances using the VPC endpoints of RDS and OSS.
Create an intranet SLB instance in the VPC used to replace the intranet SLB in the classic network.
Add the VPC ECS instances created in step 1 to the intranet SLB instance as the backend server.
Create another two ECS instances in the VPC to migrate the applications deployed in the ECS 1 and ECS 2 in the classic network.
Configure these two ECS instances created in step 5, replacing the SLB IP address to the IP address of the intranet SLB instance in the VPC.
The following steps are similar to the migration of the system 1.