Migrating resources to the ru-central1-d availability zone

The ru-central1-c availability zone will be discontinued in the first six months of 2024. You can migrate resources from it to the new ru-central1-d 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.

Timeline for migrating resources from the ru-central1-c zoneTimeline for migrating resources from the ru-central1-c zone

We will be discontinuing the ru-central1-c zone in multiple steps. In Q1 2024, you will receive a newsletter or message from your account manager with a deadline for migrating your resources.

What happens if I do not make it in time?What happens if I do not make it in time?

As soon as the migration due date is reached, we will forcibly migrate your resources from the ru-central1-c zone. This will include:

• Creating backups on your network disks located in the ru-central1-c zone and migrating your disks to the ru-central1-d zone.
• Migrating your VMs to the ru-central1-d availability zone. When being migrated, your resources will be stopped, and their network settings, subnets, IP addresses, and FQDNs will change. Then, they will be launched in the new availability zone. Sometimes, your resources may not start correctly in the new zone due to technical reasons.
• When migrating Managed Service for Kubernetes and managed database resources: backing up your data and migrating your resources to ru-central1-d with reconfiguration of network settings, subnets, IP addresses, and FQDNs.

During this forced migration, your resources will get new public and internal IP addresses. This may lead to losing network access to the resources through the previous IP addresses; you may also have to update your firewall and DNS configuration, as well as other settings that depend on the addresses your resources refer to.

During the forced migration, your services may also become unavailable.

To keep your services available and minimize your risks, make sure to migrate your resources from the ru-central1-c zone on your own before the deadline.

What are the risks of forced migration?What are the risks of forced migration?

Sometimes, we may not be able to correctly migrate your resources to ru-central1-d due to technical reasons. This may apply to any resources that still reside in ru-central1-c once the migration deadline is over.

This, in its turn, will trigger the following, depending on the resource type:

• For your Compute Cloud VMs, we will create snapshots and then stop them. You will then be able to restore your VMs from snapshots in another availability zone.
• Managed Service for Kubernetes clusters will become fully unavailable, including in ru-central1-a and ru-central1-b, in case you use a regional master or have node groups in such zones. We will back up your cluster settings (technically, take the etcd disk snapshot), which you will be able to request from our tech support.
  • If a cluster was inactive when forced migration started, the cluster will be backed up and later deleted.
  • If a cluster with resources located in the ru-central1-c zone was stopped during forced migration, the cluster will be backed up and later deleted.
  • A backup is a snapshot of etcd cluster data. To get a backup copy of your cluster, contact support.
• Managed database hosts residing in ru-central1-c will be disabled. Before doing so, we will create database backups from which you can restore your cluster.
• Instance groups residing in ru-central1-c will be stopped. You will get backups of all VM instances that were part of the relevant groups.
• Managed Service for GitLab repositories located in ru-central1-c will be deleted. We will create a backup you will be able to request from our tech support.
• Cloud Desktops located in ru-central1-c will be deleted. Before doing so, we will create their images.

These risks apply to resources with the following characteristics:

• Resources on the standard-v1 platform (Intel Broadwell).
• Resources connected to subnets with custom routing tables.

The above list is not exhaustive. Migrate your resources yourself by the specified deadline.

How do I get help with migration?How do I get help with migration?

You can contact our partners for assistance and advice.

Recommended migration processRecommended migration process

1. For all networks, create a new subnet in the ru-central1-d zone.
2. Optionally, if you are 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.
5. Make sure the subnets in ru-central1-c have no resources left. Delete any remaining resources.

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 by running the yc compute instance relocate or yc compute disk 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 done running.

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.

See these 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.
• Managed Service for Redis.
• 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 that has Data Transfer configured, to resume the transfer, you will need to:

1. Have at least one host in the cluster that is outside ru-central1-d.
2. After changing the cluster, restart the transfers that were previously in the Running status or change the settings of the transfer or its endpoints: this way, the transfer will restart 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 VM instances, database hosts, and Managed Service for Kubernetes nodes.

You can migrate subnets by running 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. If the public IP address of the balancer was in the ru-central1-c zone, it will continue working; see Implementation specifics of the network balancer for details.

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 by contacting 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 of a Managed Service for GitLab instance located in ru-central1-c, see Migrating a ru-central1-c 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.