Миграция ресурсов в зону ru-central1-d

В первой половине 2024 года зона ru-central1-с будет выведена из эксплуатации. Ресурсы из нее можно переместить в новую зону доступности — ru-central1-d.

Ряду ресурсов 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 и другие, не указанные ниже — мигрировать их ресурсы не требуется.

Сроки миграции из зоны ru-central1-сСроки миграции из зоны ru-central1-с

Производится поэтапный вывод ресурсов зоны ru-central1-с из эксплуатации. В первом квартале 2024 года вам на электронную почту придет рассылка или сообщение от аккаунт-менеджера, в котором будет указан дедлайн миграции ваших ресурсов.

Что будет, если я не успею?Что будет, если я не успею?

По истечении срока миграции мы осуществим принудительную релокацию ресурсов из зоны ru-central1-с:

• Создадим резервные копии данных на ваших сетевых дисках, расположенных в зоне ru-central1-с, и перенесем диски в зону ru-central1-d.
• Перенесем ваши виртуальные машины в зону доступности ru-central1-d. Перенос будет сопровождаться остановкой ваших ресурсов, изменением их сетевых настроек, подсетей, IP-адресов и FQDN и запуском ресурсов в новой зоне доступности. В некоторых случаях запуск ресурсов в новой зоне может не получиться по техническим причинам.
• При переносе ресурсов управляемых сервисов баз данных и сервиса Managed Service for Kubernetes мы осуществим резервное копирование ваших данных и перенесем ресурсы в зону доступности ru-central1-d со сменой сетевых настроек, подсетей, IP-адресов и FQDN.

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

Кроме того, в процессе принудительной миграции возможна временная недоступность ваших сервисов.

Перенесите ресурсы из зоны ru-central1-с самостоятельно до наступления дедлайна, чтобы сохранить доступность сервисов и избежать рисков.

Какие риски у принудительной миграции?Какие риски у принудительной миграции?

Иногда перенос ваших ресурсов в зону ru-central1-d в рабочем состоянии может быть невозможен по техническим причинам. Это может коснуться любых ресурсов, оставшихся в зоне ru-central1-с после дедлайна миграции.

Что произойдет с разными типами ресурсов в таком случае:

• С виртуальной машины Compute Cloud будет снят снимок, после чего ВМ будет остановлена. В дальнейшем ВМ можно будет восстановить в другой зоне из снимка.
• Кластер Managed Service for Kubernetes станет полностью недоступен для использования — в том числе в зонах доступности ru-central1-a и ru-central1-b, если использовался региональный мастер, или в этих зонах располагались группы узлов. Резервная копия настроек кластера (снимок диска с etcd) будет создана сервисом и доступна по запросу в техническую поддержку.
  • Если на момент начала принудительной миграции кластер был выключен, будет создана его резервная копия, а кластер в дальнейшем будет удален.
  • Если кластер с ресурсами в зоне ru-central1-c был остановлен в ходе принудительной миграции, также будет создана его резервная копия, а кластер в дальнейшем удален.
  • Резервная копия — это снимок данных etcd-кластера. Чтобы получить резервную копию вашего кластера, обратитесь в техническую поддержку.
• Хосты управляемых сервисов баз данных в зоне ru-central1-c будут отключены. У вас будет актуальная на момент отключения резервная копия базы данных, из которой можно восстановить кластер.
• Группа виртуальных машин в зоне ru-central1-c будет остановлена. У вас будут снимки дисков всех виртуальных машин, находившихся в этой группе.
• Репозитории Managed Service for GitLab в зоне ru-central1-c будут удалены. Сервис создаст резервную копию, которую можно получить по запросу в техническую поддержку.
• Рабочие столы Cloud Desktop в зоне ru-central1-c будут удалены. Перед этим будут созданы их образы.

Эти риски распространяются на ресурсы со следующими особенностями:

• Ресурсы на платформе standard-v1 (Intel Broadwell).
• Ресурсы, подключенные к подсетям с пользовательскими таблицами маршрутизации.

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

Как получить помощь с миграцией?Как получить помощь с миграцией?

Вы можете обратиться за помощью и консультациями к нашим партнерам.

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

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

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

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.
• Managed Service for Redis.
• 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-адрес балансировщика находился в зоне ru-central1-c — он продолжит работать, подробнее см. Особенности реализации сетевого балансировщика.

Обратите внимание: таким образом можно сохранить 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, размещенного в зоне ru-central1-c, воспользуйтесь инструкцией в разделе Миграция инстанса из зоны доступности ru-central1-c в другую зону.

Cloud DesktopCloud Desktop

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