Миграция ресурсов в другую зону

Ряду ресурсов Compute Cloud и Virtual Private Cloud в CLI добавлена команда relocate, которая позволяет переместить ресурс в другую зону. В случае переноса групп ВМ, ресурсов сервисов Network Load Balancer и Application Load Balancer, управляемых сервисов баз данных, инстансов Managed Service for GitLab, кластеров Managed Service for Kubernetes и сервисов Serverless воспользуйтесь существующими инструментами.

Если среди сервисов, которые вы используете, есть Object Storage, Cloud CDN, Cloud DNS и другие, не указанные ниже — мигрировать их ресурсы не требуется.

Рекомендуемый порядок миграцииРекомендуемый порядок миграции

1. Во всех сетях создайте новую подсеть в зоне ru-central1-d.
2. (опционально) Если вы используете сервис Cloud Interconnect, обратитесь в техническую поддержку, чтобы настроить работу с новой подсетью. Для завершения настройки подсети необходимо создать и подключить к ней любой ресурс (например, виртуальную машину), чтобы маршрутная информация, связанная с новой подсетью, корректно анонсировалась в сервисе Cloud Interconnect.
3. Перенесите ваши ресурсы в новую зону доступности:
   1. Виртуальные машины (по отдельности или с помощью расширения группы ВМ).
   2. Хосты баз данных.
   3. (опционально) Перезапустите привязанные трансферы Data Transfer.
   4. Мастера и группы узлов Managed Service for Kubernetes.
4. Если вы использовали сетевые и L7-балансировщики, добавьте перемещенные ресурсы в их целевые группы. Включите прием трафика в новой зоне у L7-балансировщиков.

Инструменты миграцииИнструменты миграции

Compute CloudCompute Cloud

Мы рекомендуем мигрировать виртуальные машины и диски с помощью снимков или сервиса Cloud Backup.

Так вы сможете сами контролировать ход миграции. Вы определяете, в какой момент выключать ВМ в исходной зоне доступности, и в какой момент она появится в конечной зоне доступности. ВМ в исходной зоне доступности может продолжать работать, пока вы не убедитесь, что созданная из снимка ВМ в новой зоне доступности работает корректно.

Если снимки не подходят вам в качестве инструмента миграции, ВМ и диски можно мигрировать с помощью команд yc compute disk relocate или yc compute instance relocate. В таком случае все равно сделайте снимок или создайте резервную копию в Cloud Backup перед выполнением команд — в ходе миграции у вашей ВМ изменится сетевое окружение, что может повлиять на ее работоспособность. Если в ходе миграции что-то пойдет не так, у вас будет снимок или резервная копия, из которых вы сможете оперативно восстановить вашу ВМ в исходной зоне доступности и попробовать мигрировать ее еще раз. После выполнения команды relocate снимки и копии можно будет удалить.

Обратите внимание, что ВМ с подключенными файловыми хранилищами мигрировать нельзя.

Группы ВМ можно расширить, добавляя ВМ в новую зону доступности. ВМ из старой зоны доступности после этого можно удалить.

Миграция групп ВМ с балансировщиками происходит в зависимости от типа используемого балансировщика.

В группу с внешним сетевым балансировщиком достаточно добавить ВМ в новой зоне доступности. В группах с внутренним балансировщиком потребуется указать новый обработчик в подсети в новой зоне доступности или мигрировать подсеть в новую зону.

Если в группе есть L7-балансировщик, нужно включить прием трафика в новой зоне доступности и добавить ВМ в целевую группу.

Управляемые сервисы баз данныхУправляемые сервисы баз данных

В большинстве случаев для миграции хостов управляемых сервисов баз данных нужно создать хост в новой зоне доступности, добавить его в кластер и указать FQDN нового хоста на бэкенде или клиенте.

См. инструкции по миграции для конкретных сервисов:

• Yandex Data Processing.
• Yandex Data Processing с файловой системой HDFS.
• 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® — для миграции нужно восстановить кластер из резервной копии.

Data TransferData Transfer

Если вы добавили в кластер с настроенным Data Transfer новый хост в зоне ru-central1-d, для продолжения работы трансфера нужно:

1. Чтобы в кластере был хотя бы один хост вне зоны ru-central1-d.
2. После изменения кластера перезапустить трансферы, находившиеся в состоянии Running, либо изменить настройки трансфера или его эндпоинтов — трансфер перезапустится и получит новую топологию кластера.

Managed Service for KubernetesManaged Service for Kubernetes

Чтобы мигрировать кластер Managed Service for Kubernetes из одной зоны доступности в другую:

• Перенесите мастер.
• Перенесите группу узлов и рабочую нагрузку в подах.

Network Load BalancerNetwork Load Balancer

При использовании сетевых балансировщиков без групп ВМ нужно перенести ВМ в новую зону доступности и добавить ее в целевую группу балансировщика.

Application Load BalancerApplication Load Balancer

Для переноса ВМ, подключенной к L7-балансировщику, нужно включить прием трафика в новой зоне доступности, перенести ВМ и добавить их в целевую группу.

Virtual Private CloudVirtual Private Cloud

Миграция подсетей позволяет сохранить адресацию и настроенные IP-адреса обработчиков внутренних балансировщиков. Обратите внимание, что переместить можно только пустые подсети, к которым не подключены никакие ресурсы: ВМ, хосты БД, узлы Managed Service for Kubernetes и другие.

Подсети можно мигрировать с помощью команды relocate.

Миграция IP-адресовМиграция IP-адресов

Перенос публичных IP-адресов между зонами невозможен. Чтобы сохранить публичный адрес для входящего трафика, зарезервируйте этот адрес и затем назначьте его обработчику сетевого балансировщика. Далее можно перенести ВМ и подключить ее к сетевому балансировщику.

Обратите внимание: таким образом можно сохранить IP-адрес только для входящего трафика. Например, если на IP-адрес ВМ выдана лицензия, вы не сможете использовать публичный IP-адрес балансировщика для ее проверки.

Если вам нужен IP-адрес с открытым портом 25 в новой зоне, заранее закажите новый такой адрес через поддержку.

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

Для миграции функций, контейнеров и API-шлюзов нужно создать подсеть в новой зоне доступности.

• Функции
• Контейнеры
• API-шлюзы

Managed Service for GitLabManaged Service for GitLab

Чтобы изменить зону доступности инстанса Managed Service for GitLab, воспользуйтесь инструкцией в разделе Миграция инстанса в другую зону доступности.

Cloud DesktopCloud Desktop

Если на рабочем столе нет ценной информации, то достаточно создать новый рабочий стол и удалить старый. Если ценная информация есть, то из старого рабочего стола нужно создать образ и создать новый рабочий стол из образа.