This topic describes how to use the hybrid migration solution to migrate cloud resources from a classic network to a virtual private cloud (VPC).

Prerequisites

Before you start the hybrid migration, make sure that the following requirements are met:
  • An Alibaba Cloud account is created. If you do not have an Alibaba Cloud account, create one. To create an Alibaba Cloud account, clickCreate an Alibaba Cloud account.
  • You are aware of the details and limits of the hybrid migration solution. For more information, see Overview of migration solutions.
  • You are familiar with VPCs and the related products. VPCs are isolated private networks that allow you to manage your cloud resources by using relevant cloud services.
  • The migration examples in this topic are for reference only. Systems in multiple use cases are more complex. You must assess the network architecture and system dependencies before you create a migration plan.

Systems to be migrated

The following two systems are used in the hybrid migration examples.

  • System 1

    The following figure shows System 1. This system runs in a classic network system and integrates the Server Load Balancer (SLB), Elastic Compute Service (ECS), ApsaraDB RDS, and Object Storage Service (OSS) services. The Internet SLB instance uses two ECS instances as backend servers. The applications deployed on the two ECS instances are required to access the ApsaraDB RDS instance and the OSS bucket.

  • System 2

    The following figure shows System 2. This system runs in a classic network. The architecture of System 2 is more complex than that of System 1. A public-facing SLB instance and an internal SLB instance are used. The ECS instances, ECS 1 and ECS 2, are specified as the backend servers of the public-facing SLB instance. Both ECS instances are required to access the internal SLB instance. Another two ECS instances, ECS 3 and ECS 4, are specified as the backend servers of the internal SLB instance. Both ECS instances are required to access the ApsaraDB RDS and the OSS.

Migrate System 1 to a VPC

To migrate System 1 to a VPC, perform the following steps:

  1. Prepare the network environment.
    Create a VPC to which the system is migrated and create a VSwitch for the VPC.
    For more information, see Create an IPv4 VPC network.
  2. Obtain the internal endpoints of the ApsaraDB RDS instance and the OSS bucket that you want to access in the VPC.
    • You can use the RDS console or call the required API operation to switch the network type of the ApsaraDB RDS instance to VPC and reserve the classic network endpoint. For more information, see Switch the network type of an RDS instance.

      After System 1 is migrated, the classic network endpoint remains unchanged. An internal endpoint that can be accessed within the VPC is added. Therefore, the ECS instances in the classic network can still access can still access ApsaraDB RDS without service disruptions. After the classic network endpoint expires, it is automatically deleted. Then, ApsaraDB RDS can no longer be accessed through the classic network endpoint.

    • The OSS bucket provides a classic network endpoint and a VPC endpoint. You do not need to switch the network type. To obtain the VPC endpoint of the OSS bucket, see Regions and endpoints.
  3. Create and configure two ECS instances in the VPC.
    Create two ECS instances in the VPC, deploy applications on the ECS instances, and then change the endpoints of the ApsaraDB RDS instance and OSS bucket to the endpoints that can be accessed within the VPC. After you complete the configuration, you must conduct a test to verify that the ECS instances can access the OSS bucket and the ApsaraDB RDS instance.
  4. Specify the ECS instances in the VPC as the backend servers of the public-facing SLB instance.
    Add the two ECS instances in the VPC as the backend servers of the public-facing SLB instance. Check the health status of the ECS instances. We recommend that you set a lower weight for the ECS instances. This can reduce the impact of unexpected faults on the system. Check the system status, traffic monitoring, and health check logs.
  5. Remove the classic-network ECS instances from the backend servers of the public-facing SLB instance.
    The following figure shows how to remove the classic-network ECS instances from the backend servers of the public-facing SLB instance. We recommend that you set the weight of the classic-network ECS instances to 0. After these ECS instance no longer receive requests, remove them from the backend servers of the SLB instance.
  6. Release the classic-network ECS instances.
    Release the classic-network ECS instances after the system runs as expected for a specific period. The public-facing SLB instance supports the ECS instances in the VPC and it is not required to be migrated. Your migration is complete.
    Note The classic network endpoint of the ApsaraDB RDS instance will be automatically deleted after it expires.

Migrate System 2 to a VPC

When you migrate System 2 to a VPC, the preceding procedure does not apply. If you use the preceding procedure, the ECS instances in the VPC cannot access the ECS instances in the classic network. This is because the SLB instances that use these ECS instances as backend servers do not support hybrid access.

To migrate System 2 to a VPC, perform the following steps:

  1. Create two ECS instances in the VPC to migrate ECS 3 and ECS 4 in the classic network to these ECS instances in the VPC. ECS 3 and ECS 4 are specified as the backend servers of the internal SLB instance.
  2. Configure the ECS instances in the VPC, and change the endpoints of the ApsaraDB RDS instance and the OSS bucket to the endpoints that can be accessed within the VPC.
  3. Create an internal SLB instance in the VPC to replace the internal SLB instance in the classic network.
  4. Configure the internal SLB instance in the VPC. Add the two ECS instances that are created in Step 1 as backend servers.
  5. Create another two ECS instances in the VPC as the migration destinations of ECS 1 and ECS 2 that are specified as the backend servers of the public-facing SLB instance.
  6. Configure the ECS instances that are created in Step 5. Change the classic network endpoint of the internal SLB instance to the endpoint that is used in the VPC.
  7. Repeat Steps 4 to 6 that are described in the migration solution of System 1 to migrate System 2.