Migrating resources to a different availability zone

We added the relocate CLI command for a number of Compute Cloud and Virtual Private Cloud resources, which allows you to migrate resources to a different zone. If migrating instance groups, Network Load Balancer and Application Load Balancer resources, managed databases, Managed Service for GitLab instances, Managed Service for Kubernetes clusters, and serverless services, use the existing tools.

If among your services there are Object Storage, Cloud CDN, Cloud DNS and others not listed below, you do not need to migrate their resources.

Recommended migration processRecommended migration process

1. In all networks, create a new subnet in the ru-central1-d zone.
2. Optionally, if using Cloud Interconnect, contact support to configure the new subnet. To complete the subnet configuration, you must create any resource (e.g., a VM) and connect it to the subnet to correctly announce the new subnet's routing information in Cloud Interconnect.
3. Migrate your resources to the new availability zone:
   1. VM instances (one by one or by expanding the instance group).
   2. Database hosts.
   3. Optionally, restart the linked Data Transfer transfers.
   4. Managed Service for Kubernetes master hosts and node groups.
4. If you were using network or L7 load balancers, add the resources you want to migrate to their target groups. Enable ingress traffic in the new availability zone for the L7 load balancers.

Migration toolsMigration tools

Compute CloudCompute Cloud

To migrate VM instances and disks, we recommend using snapshots or Cloud Backup.

These solutions help you manage the migration process on your own. You can decide when to shut down the VM instance in the source availability zone and when to make it available in the target zone. The VM in the source availability zone may continue to run until you make sure that the VM you created from a snapshot works properly in the new availability zone.

If using snapshots as a migration tool is not an option, you can migrate VM instances and disks using the yc compute disk relocate or yc compute instance relocate command, respectively. In this case, you should still take a snapshot or make a backup in Cloud Backup before running the commands. This is because the migration process will change your VM's network environment, which may impact its performance. In addition, if something goes wrong during migration, you will be able to quickly restore your VM to the original availability zone from the snapshot or backup and attempt the migration again. You can delete the snapshots and backups once the relocate command is completed.

Note that you cannot migrate VM instances with attached file storages.

You can expand instance groups by adding VM instances to the new availability zone. You can then delete the VM instances from the old availability zone.

The migration process for instance groups with load balancers depends on the type of load balancer you use.

For a group with an external network load balancer, all you need to do is add the VM instances to the new availability zone. For a group with an internal load balancer, you need to specify a new listener created on a subnet in the new availability zone or migrate the existing subnet to the new zone.

If your group has an L7 load balancer, you need to enable traffic in the new availability zone and add the VM instances to the target group.

Managed database servicesManaged database services

In most cases, to migrate a managed database service host, you need to create a host in the new availability zone, add it to the cluster, and specify the FQDN of the new host in the backend or client.

Refer to service-specific migration guides:

• Yandex Data Processing.
• HDFS-based Yandex Data Processing.
• Managed Service for Apache Kafka®.
• Managed Service for ClickHouse®.
• Managed Service for MongoDB.
• Managed Service for MySQL®.
• Managed Service for OpenSearch.
• Managed Service for PostgreSQL.
• Yandex Managed Service for Valkey™.
• Managed Service for YDB.
• Managed Service for Greenplum®: To migrate, restore the cluster from a backup.

Data TransferData Transfer

If you added a new host in the ru-central1-d zone to a cluster with Data Transfer configured, to resume the transfer, you have to:

1. Have at least one host outside the ru-central1-d zone in the cluster.
2. After updating the cluster, restart the transfers that were previously in the Running status or change the settings of the transfer or its endpoints: this will restart the transfer with a new cluster topology.

Managed Service for KubernetesManaged Service for Kubernetes

To move a Managed Service for Kubernetes cluster between availability zones:

• Migrate a master host.
• Migrate the node group and the pod workloads.

Network Load BalancerNetwork Load Balancer

When using network load balancers without instance groups, you need to migrate the VM to the new availability zone and add it to the load balancer's target group.

Application Load BalancerApplication Load Balancer

To migrate a VM that is connected to an L7 load balancer, you need to enable traffic in the new availability zone, migrate the VM, and add it to the target group.

Virtual Private CloudVirtual Private Cloud

Subnet migration allows you to maintain the original addressing and the IP addresses configured for the listeners of the internal load balancers. Note that you can only migrate empty subnets that do not have any connected resources, such as VMs, DB hosts, Managed Service for Kubernetes nodes, etc.

You can migrate subnets using the relocate command.

IP address migrationIP address migration

You cannot migrate public IP addresses between zones. To save the public address for incoming traffic, reserve this address and then assign it to the network balancer handler. Next, you can migrate the VM and connect it to a network balancer.

Note: This way, you can save the IP address for incoming traffic only. For example, if the IP address of a VM is licensed, you cannot use the public IP address of the balancer to check it.

If you need an IP address with open port 25 in a new zone, order a new one in advance through support.

API Gateway, Cloud Functions, Serverless ContainersAPI Gateway, Cloud Functions, Serverless Containers

To migrate functions, containers, and API gateways, you need to create a subnet in the new availability zone.

• Functions
• Containers
• API gateways

Managed Service for GitLabManaged Service for GitLab

To change the availability zone for a Managed Service for GitLab instance, follow the guide in Migrating an instance to a different availability zone.

Cloud DesktopCloud Desktop

If your desktop contains no valuable information, it is enough to create a new desktop and delete the old one. If there is valuable information, create an image from the old desktop and then create a new desktop from that image.