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. For more information, see Create an Alibaba Cloud account.
  • You understand the details and limits of the hybrid migration solution. For more information, see Overview.
  • You are familiar with VPCs and relevant services. 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. The actual scenario may be more complex. You must assess the network architecture 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 and uses Server Load Balancer (SLB), Elastic Compute Service (ECS), ApsaraDB RDS, and Object Storage Service (OSS). The Internet-facing SLB instance has 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. System 2 runs in a classic network and is more complex than system 1. The Internet-facing SLB instance is associated with ECS 1 and ECS 2. Both ECS instances are required to access an internal-facing SLB instance. The internal-facing SLB instance is associated with ECS 3 and ECS 4. Both ECS instances are required to access the ApsaraDB RDS instance and the OSS bucket.

Example 1: 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.
  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 ApsaraDB RDS console or call an API operation to switch the network type of the ApsaraDB RDS instance to VPC and reserve the classic network endpoint. For more information, see Change the network type of an ApsaraDB 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. This way, the ECS instances in the classic network can still access ApsaraDB RDS without service disruptions. When the classic network endpoint expires, it is automatically deleted and ECS instances can no longer access ApsaraDB RDS 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, test whether 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 Internet-facing SLB instance.
    Add the two ECS instances in the VPC as the backend servers of the Internet-facing SLB instance. Check the health status of the ECS instances. We recommend that you set lower weights for the ECS instances. This reduces the impacts 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 Internet-facing SLB instance.
    The following figure shows how to remove the classic-network ECS instances from the backend servers of the Internet-facing SLB instance. We recommend that you set the weight of the classic-network ECS instances to 0. After the ECS instances 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 Internet-facing SLB instance supports the ECS instances in the VPC and it is not required to be migrated. Your migration is completed.
    Note The classic network endpoint of the ApsaraDB RDS instance is automatically deleted when it expires.

Example 2: 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. 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.

  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 ApsaraDB RDS console or call an API operation to switch the network type of the ApsaraDB RDS instance to VPC and reserve the classic network endpoint. For more information, see Change the network type of an ApsaraDB 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. This way, the ECS instances in the classic network can still access ApsaraDB RDS without service disruptions. When the classic network endpoint expires, it is automatically deleted and ECS instances can no longer access ApsaraDB RDS 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 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-facing SLB instance.
  4. Configure the new 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.
  5. Create an internal-facing SLB instance in the VPC to replace the internal-facing SLB instance in the classic network.
  6. Configure the internal-facing SLB instance in the VPC. Specify the two ECS instances that are created in Step 3 as backend servers.
  7. Create two ECS instances in the VPC as the migration destinations of ECS 1 and ECS 2.
  8. Configure the new ECS instances. Change the classic network endpoint of the internal SLB instance to the endpoint that is used in the VPC.
  9. Perform Step3 to Step6, as described in Example 1.