Migrate an ECS instance across zones

Use cases

• Change the instance type of an ECS instance

  If the current configuration of your ECS instance does not meet your business needs and the required instance type is sold out in the current zone, you can migrate the instance to another zone while changing its vCPU and memory specifications within the same instance family. For example, you can change an ecs.g6e.large instance with 2 vCPUs and 8 GiB of memory to an ecs.g6e.xlarge instance with 4 vCPUs and 16 GiB of memory.

• Change the zone of an ECS instance

  Deploying application instances in different zones within the same region improves overall system availability and stability. If one zone fails, services can quickly fail over to another zone to continue running. For example, you can migrate an instance from Hangzhou Zone H to Hangzhou Zone K.

Limitations

• Preemptible instances do not support cross-zone migration.

• When you change an instance type, you can only select a new type within the same instance family (vCPUs and memory). For more information about instance families, see Instance families.

  Note

  If you want to change to an instance type in a different instance family, first migrate the instance across zones and then change the instance type. For more information, see Change the instance type of a subscription instance or Change the instance type of a pay-as-you-go instance.

• You can migrate a maximum of 5 instances at a time in the ECS console. To increase this limit, contact technical support.

• The following instance families do not support cross-zone migration:

  • Heterogeneous computing

  • ECS Bare Metal Instance

  • Super Computing Cluster (SCC)

  • General-purpose compute-optimized instance family u2a

  • Some burstable instance families e (only e-c1m1, e-c1m2, and e-c1m4 are supported)

  • x86-based computing

    • Big data

    • Local SSDs

    • Security-enhanced

  • Some 8th-generation instance families (only hfr8i, hfc8i, hfg8i, r8ae, g8ae, c8ae, r8y, c8y, g8y, r8a, g8a, c8a, g8i, r8i, and c8i are supported)

  • Some 9th-generation instance families (only r9i, g9i, and c9i are supported)

Migration impact

Billing

• No fees are incurred if you do not change the instance type during migration.

• If you change the instance type during migration, the following billing rules apply:

  • Downgrading a subscription instance: Downgrading the instance type may result in a refund. The refund is the difference between the remaining value of the original configuration and the price of the new configuration. For more information, see Rules for unsubscribing from resources with a downgrade.

    Important

    A monthly quota applies to instance type downgrades. Your historical spending determines this quota, and the page displays the specific amount. You cannot perform further downgrades after you exhaust your monthly quota. The quota is automatically reset on the first day of the next month. For more information, see Unsubscription rules.

  • Upgrading a subscription instance: You must pay the price difference for the remainder of the current billing cycle. The console displays the actual fee.

  • Changing a pay-as-you-go instance: After the migration, the instance is billed based on the new instance type.

Procedure

1. Go to the Cross-Availability Zone Migration page in the SMC console.

2. Click Start Migration or Migrate Now.

3. In the Cross-zone Migration dialog box, select a region, select the ECS instances you want to migrate, and then click Configure Parameters.

4. In the dialog box, configure the parameters and click Create.

   The following table describes the parameters.

   Parameter	Description
   Migration Job Type	ECS Instance Migration is selected by default and cannot be changed.
   Current Region	The region where the source ECS instance is located.
   Preferred Destination Zone	Select a destination zone based on your requirements.
   Preferred Network Settings	Specify a destination vSwitch. After the migration, the instance is randomly assigned a private IP address from the CIDR block of the vSwitch. You must create a VPC and a vSwitch in the destination zone beforehand. For more information, see Create a VPC and a vSwitch. Important Cross-zone migration does not preserve the instance's private IP address. Make sure that no applications depend on the current private IP address. You can modify the private IP address after the migration is complete. For more information, see Modify the primary private IPv4 address of an existing instance.
   Instance Type	Select whether to change the instance type based on your requirements. Use Current Instance Type: The instance type remains the same. Change Instance Type: Allows you to select a new instance type. For information about supported instance types and other limitations, see Limitations. Important You can change an instance type only to another type within the same instance family.
   Preferred New Instance Type	Select a destination instance type. Note This parameter is displayed only if you select Change Instance Type. The system automatically displays a list of supported instance types. If your desired instance type is not listed, it may be sold out in the destination zone.
   Instance to Be Migrated	Displays the selected Instance ID/Name, Destination Zone, Destination instance type, and Destination vSwitch.
   Note	Select I have backed up data.

5. In the dialog box that appears, click Pay and follow the on-screen instructions to complete the payment.

Result verification

• The migration is successful if the Real-time Migration Status is Completed.

  After the cross-zone migration is complete, you can check whether the zone and instance type have changed:

  1. In the Actions column of the migration source, click View Destination Instance.

  2. On the Instance Details tab, check the Zone and Instance Specifications.

• The migration failed if the Real-time Migration Status is InError.

  Troubleshoot the issue and retry the migration:

  1. In the Actions column, click Troubleshoot Errors. Use the error code and error message to resolve the issue. For more information, see SMC FAQ and Troubleshooting.

  2. After resolving the issue, click Retry Migration Job in the Actions column. The migration resumes from where it left off.

FAQ

Why do I see the message "The private IP address of the current instance has reverse dependencies or route dependencies, such as from services like Workbench or DTS. For Workbench, you can find and delete the dependency under Workbench > Instances > Private Network Link. For route dependencies, you can find and delete the route entry that depends on this instance in the VPC console > Route Tables" during a cross-zone migration?

If this issue occurs, perform the following troubleshooting steps:

1. Check for Workbench private network links.

   Go to the Workbench console and choose Instance > Private Links to check whether a private network link exists for the ECS instance.

   Note

   When you log on to the Workbench console, open the Workbench menu.

   • If a link exists, click Release Link and proceed to the next step.

     In the top menu bar, click Instances and select Private Network Link from the drop-down menu. On the Private Network Link page, you can find Release Link in the Actions column for the target instance.

   • If no link exists, proceed to the next step.

2. Check for custom route entries whose next hop is the ECS instance.

   Go to the Route Tables console. Find the route table used by the ECS instance based on its VPC. Check whether a custom route entry exists whose next hop is the ECS instance.

   • If a custom route entry exists, delete it and proceed to the next step.

     In the left-side navigation pane of the VPC console, click Route Tables. Go to the details page of the target route table. On the Route Entries > Custom tab, identify the route entry whose Next hop is the ECS instance, and then click Delete in the Actions column.

   • If no such entry exists, proceed to the next step.

3. Check for Data Transmission Service (DTS) migration tasks whose source is a Self-managed Database on ECS.

   Go to the Data Transmission Service (DTS) console and check whether a DTS migration task exists whose source is a Self-managed Database on ECS.

   • If such a task exists, delete it and proceed to the next step.

     Important

     Before you delete a DTS task, make sure that the data transfer is complete and the data is backed up.

   • If no such task exists, proceed to the next step.

4. Check for associated VPC resources.

   Go to the VPC console and check for associated VPC resources, including a DHCP options set, network ACL, route table, or IPv4 gateway. If any of these resources exist, delete them before you proceed.

   For more information, see DHCP options sets and DNS hostnames, Delete a network ACL, Delete a custom route table, and Delete an IPv4 gateway.

   On the Basic Information tab of the target VPC, check the DHCP options set field. If a DHCP options set is associated, click Disassociate.