Миграция хостов кластера Apache Kafka® в другую зону доступности
Хосты кластера Managed Service for Apache Kafka® располагаются в зонах доступности Yandex Cloud. Хосты Apache Kafka® можно перенести из одной зоны в другую. Процесс переноса различается для кластеров с одним и несколькими хостами.
Примечание
Для кластеров, хосты которых располагаются в зоне доступности ru-central1-d
, недоступно:
- использование платформы Intel Broadwell;
- хранилище на локальных SSD-дисках при использовании платформы Intel Cascade Lake.
Если кластер Managed Service for Apache Kafka® является эндпоинтом в сервисе Yandex Data Transfer, перезапустите трансфер для его корректной работы. Подробнее о том, какие трансферы нужно перезапускать и как это сделать, см. в разделе Особенности миграции в сервисе Yandex Data Transfer.
Миграция кластера с одним хостом
Есть несколько способов провести миграцию:
-
Воспользоваться интерфейсами Yandex Cloud. В этом случае меняется зона доступности в конфигурации кластера. Создавать дополнительный кластер не нужно.
Этот вариант проще в реализации, но во время миграции кластер будет простаивать, пока его зона доступности будет меняться. Это может занять несколько минут.
-
Воспользоваться вспомогательными инструментами MirrorMaker или Yandex Data Transfer. В этом случае создается новый кластер, в который переносятся данные из первоначального кластера.
Этот вариант сложнее в реализации, так как требует создания и настройки инфраструктуры. Но он позволяет избежать простоя: вы можете поддерживать два кластера с актуальными данными, пока не удалите первоначальный кластер.
Миграция кластера с одним хостом с помощью интерфейсов Yandex Cloud
Чтобы в кластере Managed Service for Apache Kafka® перенести хост Apache Kafka® в другую зону доступности:
-
Создайте подсеть в зоне доступности, в которую вы переносите кластер.
-
Если группа безопасности кластера настроена для подсети в зоне доступности, из которой переносится кластер, перенастройте группу для новой подсети. Для этого в правилах группы безопасности замените CIDR исходной подсети на CIDR новой подсети.
-
Измените зону доступности у кластера и его хоста Apache Kafka®:
Консоль управленияCLITerraformAPI- Перейдите на страницу каталога
и выберите сервис Managed Service for Kafka. - В строке с нужным кластером нажмите на значок
, затем выберите Изменить кластер. - В разделе Сетевые настройки укажите новую зону доступности.
- Укажите подсеть в новой зоне доступности, если в ней находится больше одной подсети.
- Нажмите кнопку Сохранить.
Если у вас еще нет интерфейса командной строки Yandex Cloud, установите и инициализируйте его.
По умолчанию используется каталог, указанный в профиле CLI. Вы можете указать другой каталог с помощью параметра
--folder-name
или--folder-id
.Чтобы изменить зону доступности у кластера и его хоста Apache Kafka®, выполните команду:
yc managed-kafka cluster update <имя_или_идентификатор_кластера> \ --zone-ids <зона_доступности> \ --subnet-ids <идентификатор_подсети>
Если в новой зоне доступности находится только одна подсеть, параметр
--subnet-ids
необязательный.-
Откройте актуальный конфигурационный файл Terraform с планом инфраструктуры.
О том, как создать такой файл, см. в разделе Создание кластера Apache Kafka®.
-
Укажите в описании кластера Managed Service for Apache Kafka® новую подсеть в параметре
subnet_ids
и новую зону доступности в параметреzones
:resource "yandex_mdb_kafka_cluster" "<имя_кластера>" { ... subnet_ids = ["<подсеть>"] config { ... zones = ["<зона_доступности>"] } ... }
Если в новой зоне доступности находится только одна подсеть, параметр
subnet_ids
необязательный. -
Проверьте корректность настроек.
-
В командной строке перейдите в каталог, в котором расположены актуальные конфигурационные файлы Terraform с планом инфраструктуры.
-
Выполните команду:
terraform validate
Если в файлах конфигурации есть ошибки, Terraform на них укажет.
-
-
Подтвердите изменение ресурсов.
-
Выполните команду для просмотра планируемых изменений:
terraform plan
Если конфигурации ресурсов описаны верно, в терминале отобразится список изменяемых ресурсов и их параметров. Это проверочный этап: ресурсы не будут изменены.
-
Если вас устраивают планируемые изменения, внесите их:
-
Выполните команду:
terraform apply
-
Подтвердите изменение ресурсов.
-
Дождитесь завершения операции.
-
-
Подробнее см. в документации провайдера Terraform
.Ограничения по времени
Провайдер Terraform ограничивает время на выполнение всех операций с кластером Managed Service for Apache Kafka® 60 минутами.
Операции, длящиеся дольше указанного времени, прерываются.
Как изменить эти ограничения?Добавьте к описанию кластера блок
timeouts
, например:resource "yandex_mdb_kafka_cluster" "<имя_кластера>" { ... timeouts { create = "1h30m" # Полтора часа update = "2h" # 2 часа delete = "30m" # 30 минут } }
Чтобы изменить зону доступности у кластера и его хоста Apache Kafka®, воспользуйтесь методом REST API update для ресурса Cluster или вызовом gRPC API ClusterService/Update и передайте в запросе:
- Идентификатор кластера в параметре
clusterId
. Чтобы узнать идентификатор, получите список кластеров в каталоге. - Новую зону доступности в параметре
configSpec.zoneId
. - Новую подсеть в параметре
subnetIds
, если в новой зоне доступности находится больше одной подсети. - Список настроек, которые необходимо изменить, в параметре
updateMask
.
Важно
Этот метод API переопределит все параметры изменяемого объекта, которые не были явно переданы в запросе, на значения по умолчанию. Чтобы избежать этого, перечислите настройки, которые вы хотите изменить, в параметре
updateMask
(одной строкой через запятую). - Перейдите на страницу каталога
-
Чтобы успешно выполнять подключение к топикам после миграции, укажите FQDN нового брокера в вашем бэкенде или клиенте (например, в коде или графической IDE). Удалите FQDN прежнего брокера в первоначальной зоне доступности.
Чтобы узнать FQDN, получите список хостов в кластере:
yc managed-kafka cluster list-hosts <имя_или_идентификатор_кластера>
FQDN указан в выводе команды, в столбце
NAME
.
Миграция кластера с одним хостом с помощью вспомогательных инструментов
Чтобы в кластере Managed Service for Apache Kafka® перенести хост Apache Kafka® в другую зону доступности:
-
Создайте подсеть в зоне доступности, в которую вы переносите кластер.
-
Если группа безопасности кластера настроена для подсети в зоне доступности, из которой переносится кластер, перенастройте группу для новой подсети. Для этого в правилах группы безопасности замените CIDR исходной подсети на CIDR новой подсети.
-
Создайте кластер Managed Service for Apache Kafka®, конфигурация которого отличается от конфигурации первоначального кластера только подсетью и группой безопасности.
-
Перенесите данные из первоначального кластера в новый с помощью одного из двух инструментов:
- MirrorMaker — подойдет как встроенный в Managed Service for Apache Kafka® MirrorMaker-коннектор, так и утилита MirrorMaker.
- Data Transfer.
-
Чтобы успешно выполнять подключение к топикам после миграции, укажите FQDN брокера нового кластера в вашем бэкенде или клиенте (например, в коде или графической IDE). Удалите FQDN брокера прежнего кластера в первоначальной зоне доступности.
Чтобы узнать FQDN, получите список хостов в кластере:
yc managed-kafka cluster list-hosts <имя_или_идентификатор_кластера>
FQDN указан в выводе команды, в столбце
NAME
. -
Удалите первоначальный кластер Managed Service for Apache Kafka®.
Миграция кластера с несколькими хостами
Если создать кластер из более чем одного хоста Apache Kafka®, в кластер автоматически добавляются три выделенных хоста ZooKeeper. Каждому из хостов назначается подсеть из разных зон доступности. После создания кластера для него нельзя сменить подсеть в зоне доступности.
Процесс миграции зависит от того, в каких зонах доступности располагаются хосты Apache Kafka® и ZooKeeper до миграции и сколько подсетей находится в каждой зоне доступности. Ознакомьтесь с частными случаями в примерах, чтобы лучше понять особенности миграции.
Чтобы в кластере перенести хосты Apache Kafka® в другую зону доступности:
-
Узнайте, в каких зонах доступности располагаются хосты Apache Kafka® и ZooKeeper:
Консоль управления- В консоли управления
перейдите в нужный каталог. - В списке сервисов выберите Managed Service for Kafka.
- Нажмите на имя нужного кластера, затем выберите вкладку Хосты.
- Посмотрите список зон доступности.
- В консоли управления
-
Если в списке нет целевой зоны доступности, куда вы переносите хосты Apache Kafka®, создайте подсеть в этой зоне.
Если в списке есть целевая зона доступности, во время миграции хосты Apache Kafka® будут перенесены в подсеть, в которой уже располагаются хосты Apache Kafka® или ZooKeeper в этой зоне доступности.
-
Проверьте группу безопасности кластера. Если она настроена для подсети в исходной зоне доступности, перенастройте группу для подсети в целевой зоне доступности. Для этого в правилах группы безопасности замените CIDR исходной подсети на CIDR целевой подсети.
-
Измените зону доступности у кластера и его хостов Apache Kafka®:
Консоль управленияCLITerraformAPI-
Перейдите на страницу каталога
и выберите сервис Managed Service for Kafka. -
В строке с нужным кластером нажмите на значок
, затем выберите Изменить кластер. -
В разделе Сетевые настройки укажите новый набор зон доступности. Их количество не должно уменьшиться.
Важно
Добавив новую зону доступности, снимите выбор с одной из старых. Если этого не сделать, после сохранения настроек вы не сможете удалить старую зону доступности.
-
Укажите подсеть в новой зоне доступности, если:
- выполняется миграция в зону доступности, где хосты Apache Kafka® или ZooKeeper ранее не размещались;
- в целевой зоне доступности находится больше одной подсети.
-
Нажмите кнопку Сохранить.
Если у вас еще нет интерфейса командной строки Yandex Cloud, установите и инициализируйте его.
По умолчанию используется каталог, указанный в профиле CLI. Вы можете указать другой каталог с помощью параметра
--folder-name
или--folder-id
.Чтобы изменить набор зон доступности у кластера и его хостов Apache Kafka®, выполните команду:
yc managed-kafka cluster update <имя_или_идентификатор_кластера> \ --zone-ids <зоны_доступности> \ --subnet-ids <идентификаторы_подсетей>
В параметре
--zone-ids
перечислите зоны доступности через запятую. Их количество не должно уменьшиться.Важно
Добавив новую зону доступности, удалите из списка одну из старых. Если этого не сделать, после выполнения команды вы не сможете удалить старую зону доступности.
В параметре
--subnet-ids
через запятую перечислите подсети для зон доступностиru-central1-a
,ru-central1-b
иru-central1-d
. Подсети для этих зон должны быть указаны, даже если хосты Apache Kafka® размещаются в меньшем количестве зон. Все три зоны доступности нужны для хостов ZooKeeper.-
Откройте актуальный конфигурационный файл Terraform с планом инфраструктуры.
О том, как создать такой файл, см. в разделе Создание кластера Apache Kafka®.
-
Измените в описании кластера Managed Service for Apache Kafka® список зон доступности в параметре
zones
:resource "yandex_mdb_kafka_cluster" "<имя_кластера>" { ... config { ... zones = ["<зоны_доступности>"] } ... }
Количество зон доступности не должно уменьшиться.
Важно
Добавив новую зону доступности, удалите из списка одну из старых. Если этого не сделать, после сохранения настроек вы не сможете удалить старую зону доступности.
-
Измените в параметре
subnet_ids
список подсетей, если:- выполняется миграция в зону доступности, где хосты Apache Kafka® или ZooKeeper ранее не размещались;
- в целевой зоне доступности находится больше одной подсети.
resource "yandex_mdb_kafka_cluster" "<имя_кластера>" { ... subnet_ids = ["<подсети>"] ... }
Убедитесь, что параметр
subnet_ids
содержит подсети для зон доступностиru-central1-a
,ru-central1-b
иru-central1-d
. Подсети для этих зон должны быть указаны, даже если хосты Apache Kafka® размещаются в меньшем количестве зон. Все три зоны доступности нужны для хостов ZooKeeper. -
Проверьте корректность настроек.
-
В командной строке перейдите в каталог, в котором расположены актуальные конфигурационные файлы Terraform с планом инфраструктуры.
-
Выполните команду:
terraform validate
Если в файлах конфигурации есть ошибки, Terraform на них укажет.
-
-
Подтвердите изменение ресурсов.
-
Выполните команду для просмотра планируемых изменений:
terraform plan
Если конфигурации ресурсов описаны верно, в терминале отобразится список изменяемых ресурсов и их параметров. Это проверочный этап: ресурсы не будут изменены.
-
Если вас устраивают планируемые изменения, внесите их:
-
Выполните команду:
terraform apply
-
Подтвердите изменение ресурсов.
-
Дождитесь завершения операции.
-
-
Подробнее см. в документации провайдера Terraform
.Ограничения по времени
Провайдер Terraform ограничивает время на выполнение всех операций с кластером Managed Service for Apache Kafka® 60 минутами.
Операции, длящиеся дольше указанного времени, прерываются.
Как изменить эти ограничения?Добавьте к описанию кластера блок
timeouts
, например:resource "yandex_mdb_kafka_cluster" "<имя_кластера>" { ... timeouts { create = "1h30m" # Полтора часа update = "2h" # 2 часа delete = "30m" # 30 минут } }
Чтобы изменить набор зон доступности у кластера и его хостов Apache Kafka®, воспользуйтесь методом REST API update для ресурса Cluster или вызовом gRPC API ClusterService/Update и передайте в запросе:
-
Идентификатор кластера в параметре
clusterId
. Чтобы узнать идентификатор, получите список кластеров в каталоге. -
Новый набор зон доступности в параметре
configSpec.zoneId
. Их количество не должно уменьшиться. -
Новый набор подсетей в параметре
subnetIds
, если:- выполняется миграция в зону доступности, где хосты Apache Kafka® или ZooKeeper ранее не размещались;
- в целевой зоне доступности находится больше одной подсети.
Убедитесь, что параметр
subnetIds
содержит подсети для зон доступностиru-central1-a
,ru-central1-b
иru-central1-d
. Подсети для этих зон должны быть указаны, даже если хосты Apache Kafka® размещаются в меньшем количестве зон. Все три зоны доступности нужны для хостов ZooKeeper. -
Список настроек, которые необходимо изменить, в параметре
updateMask
.
Важно
Этот метод API переопределит все параметры изменяемого объекта, которые не были явно переданы в запросе, на значения по умолчанию. Чтобы избежать этого, перечислите настройки, которые вы хотите изменить, в параметре
updateMask
(одной строкой через запятую). -
-
Чтобы успешно выполнять подключение к топикам после миграции, укажите FQDN нового брокера в вашем бэкенде или клиенте (например, в коде или графической IDE). Удалите FQDN прежнего брокера в первоначальной зоне доступности.
Чтобы узнать FQDN, получите список хостов в кластере:
yc managed-kafka cluster list-hosts <имя_или_идентификатор_кластера>
FQDN указан в выводе команды, в столбце
NAME
.
Примеры миграции кластера с несколькими хостами
Примеры ниже позволяют понять, в каких ситуациях нужно указывать подсеть, чтобы выполнить миграцию кластера Managed Service for Apache Kafka® с несколькими хостами в другую зону доступности.
Хост ZooKeeper уже расположен в целевой зоне доступности
Допустим, кластер содержит следующий набор хостов:
- хост Apache Kafka® №1 — в зоне доступности
ru-central1-a
; - хост Apache Kafka® №2 — в зоне доступности
ru-central1-c
; - хост ZooKeeper №1 — в зоне доступности
ru-central1-a
; - хост ZooKeeper №2 — в зоне доступности
ru-central1-b
; - хост ZooKeeper №3 — в зоне доступности
ru-central1-d
.
Нужно перенести хосты Apache Kafka® в зоны доступности ru-central1-a
и ru-central1-d
.
Так как хост ZooKeeper №3 уже расположен в зоне ru-central1-d
, значит, он размещается в определенной подсети в этой же зоне доступности. Эта подсеть будет использована при миграции, так как после создания кластера его подсети изменить нельзя. В результате при миграции не нужно указывать подсеть.
В целевой зоне доступности не располагается ни один хост, и есть одна подсеть
Допустим, кластер содержит следующий набор хостов:
- хост Apache Kafka® №1 — в зоне доступности
ru-central1-a
; - хост Apache Kafka® №2 — в зоне доступности
ru-central1-b
; - хост Apache Kafka® №3 — в зоне доступности
ru-central1-c
; - хост ZooKeeper №1 — в зоне доступности
ru-central1-a
; - хост ZooKeeper №2 — в зоне доступности
ru-central1-b
; - хост ZooKeeper №3 — в зоне доступности
ru-central1-c
.
Нужно перенести хосты Apache Kafka® в зоны доступности ru-central1-a
, ru-central1-b
и ru-central1-d
.
Ни один хост до миграции не размещается в зоне доступности ru-central1-d
. Но в ней находится только одна подсеть, поэтому при миграции не нужно указывать подсеть.
В целевой зоне доступности не располагается ни один хост, и в ней находятся несколько подсетей
Допустим, кластер содержит следующий набор хостов:
- хост Apache Kafka® №1 — в зоне доступности
ru-central1-a
; - хост Apache Kafka® №2 — в зоне доступности
ru-central1-b
; - хост Apache Kafka® №3 — в зоне доступности
ru-central1-c
; - хост ZooKeeper №1 — в зоне доступности
ru-central1-a
; - хост ZooKeeper №2 — в зоне доступности
ru-central1-b
; - хост ZooKeeper №3 — в зоне доступности
ru-central1-c
.
Нужно перенести хосты Apache Kafka® в зоны доступности ru-central1-a
, ru-central1-b
и ru-central1-d
.
Ни один хост до миграции не размещается в зоне доступности ru-central1-d
. В ней находится несколько подсетей, поэтому при миграции нужно указать подсеть.
Особенности миграции в сервисе Yandex Data Transfer
Если кластер выступает в роли эндпоинта при передаче данных с помощью сервиса Data Transfer и используется тип трансфера Репликация или Копирование и репликация, перезапустите трансфер после миграции кластера. Так трансфер получит сведения о новой топологии кластера.
Трансферы типа Копирование перезапускать не нужно, так как во время их активации информация о новой топологии передается автоматически.
Чтобы перезапустить трансфер, выберите один из двух способов:
- Деактивируйте трансфер и дождитесь его перехода в статус Остановлен. Затем активируйте трансфер и дождитесь его перехода в статус Реплицируется.
- Измените какую-либо настройку трансфера или эндпоинта.
Подробнее см. в разделе Миграция эндпоинтов и трансфера Data Transfer в другую зону доступности.