All Products
Search
Document Center

Elastic Compute Service:Description of the events related to instance migration due to upgrades at the underlying layer and recommended migration solutions

Last Updated:Jun 19, 2024

This topic describes the events that are related to instance migration due to upgrades at the underlying layer. This topic also describes the recommended migration solutions.

Events

To ensure and improve the stability and performance of Elastic Compute Service (ECS) instances, Alibaba Cloud plans to upgrade and improve the physical infrastructure in specific existing regions and zones. To prevent impacts on existing instances in the regions and zones, Alibaba Cloud generates system events and notifies you by phone calls, text messages, emails, and internal messages. If you receive such notifications, migrate your instances as prompted.

The system events have an event code of SystemUpgrade.Migrate. Perform the following steps to handle a SystemUpgrade.Migrate event:

  1. Check the event notification to identify which instances need to be migrated.

  2. Select a suitable time period to migrate your instances.

Migration solutions and considerations

Note

If you encounter issues when you migrate ECS instances, refer to the FAQ topic in the relevant documentation or contact your account manager.

Instances that reside in virtual private clouds (VPCs) and in the classic network cannot communicate with each other over the internal network. To allow communication between the instances over the internal network, use the recommended migration solutions in the following table to migrate instances during a suitable time period.

Scenario

Recommended migration solution and consideration

ECS instances reside in the classic network.

Use the following migration solutions to migrate ECS instances to VPCs:

  • Solution 1: Click Migrate Based on Migration Plans. For Ensure interconnections between the migrated instances and the classic network-type instances specified in the migration plan over the internal network, select Yes. Add all ECS instances that require mutual access to the same migration plan. You can specify different migration times to migrate the instances. For more information, see Migrate ECS instances from the classic network to a VPC.

  • Scenario 2: Migrate instances based on snapshots and images. After you migrate the instances, you must establish ClassLink connections on the new instances. For more information, see Use OOS to migrate ECS instances and Overview of ClassicLink.

ECS instances reside in VPCs.

  • Scenario 1: Click Clone Based on Snapshots and Images to automatically clone instances by using the ACS-ECS-BulkyCloneInstances public template provided by CloudOps Orchestration Service. Before you release the original instances, make sure that the new instances run as expected and traffic is diverted to the new instances.

  • Solution 2: Manually migrate ECS instances in the ECS console. Before you release the original instances, make sure that the new instances run as expected and traffic is diverted to the new instances. For more information, see Use a custom image to migrate ECS instance data.

Other cloud resources, such as ApsaraDB RDS instances or ApsaraDB for Redis instances, reside in the classic network.

ECS instances that reside in VPCs cannot directly connect to RDS instances in the classic network over the internal network. You must change the network type of the RDS instances from the classic network to VPC and enable the hybrid access mode. This way, the ECS instances that reside in the classic network or VPCs can connect to the RDS instances over the internal network. For more information, see Best practices for migrating all instances from the classic network to a VPC and Hybrid access to ApsaraDB services.

The ECS instances use images of earlier versions, such as Windows Server 2003 and earlier and CentOS 5.8 and earlier.

After you migrate ECS instances that use images of earlier versions, such as Windows Server 2003 and earlier and CentOS 5.8 and earlier, issues such as kernel panic failures, blue-screen errors, and INACCESSIBLE_BOOT_DEVICE errors may occur. For information about how to resolve the preceding issues, see How do I resolve downtime issues that occur on migrated instances?

Query events related to instance migration due to upgrades at the underlying layer

  1. Log on to the ECS console.

  2. In the left-side navigation pane, choose Instances & Images > Instances.

  3. In the top navigation bar, select the region and resource group to which the resource belongs. 地域

  4. In the left-side navigation pane, click Events.

  5. View events related to instance migration due to upgrades at the underlying layer.

    If a specific number of events need to be handled, the corresponding number is displayed on the Instance Migration Events Due to Upgrades at Underlying Layer tab, as shown in the following figure.to-be-migrated

  6. Select a solution to migrate instances based on your business requirements.

    For information about how to select a migration solution, see the Migration solutions and considerations section of this topic.

What to do next

FAQ

Does the migration cause the security groups that are associated with the migrated ECS instances to change?

No, the migration does not cause the security groups that are associated with the migrated ECS instances to change.

Does the migration cause the private and public IP addresses of the migrated ECS instances to change?

  • Public IP address: After you migrate an ECS instance, the public IP address of the instance remains unchanged.

    Important

    ECS instances that reside in VPCs do not have public network interfaces, and use NAT devices for Internet access. You can find only private IP addresses in the instances. If you require a public IP address that can be viewed in the instance operating system for your applications, determine whether to migrate your instance from the classic network to a VPC.

  • Private IP address: You can specify whether to retain the private IP address of an ECS instance when you create a migration plan to migrate the instance. You can also change the private IP address of an instance after you migrate the instance. For more information, see Modify the private IP address of an instance.

Does a migration plan automatically run after the migration plan is created? What is the amount of time required to migrate an ECS instance?

Approximately 15 minutes are required from the time when an ECS instance in the classic network is stopped until the time when the instance is migrated to and started in a specific VPC.

Important
  • If an ECS instance is started in the VPC, the computing and network resources of the instance are migrated to the VPC, and you can use the instance as expected.

  • If the ECS instance is migrated across zones, the system continues to migrate disk data after the instance is started. In most cases, approximately 4 hours are required to migrate 100 GiB of disk data. During the migration of disk data, the I/O performance of disks degrades, and you cannot perform snapshot-related and disk-related operations. You can use the instance as expected when the disk data is being migrated.

Are the original system-level settings, such as external services and database services, affected by the migration?

No, the services and data in the system are not affected.

For information about the impacts of the migration, see the Step 1: Familiarize yourself with the impacts of the classic network-to-VPC migration section of the "Migrate ECS instances from the classic network to a VPC" topic.