Связаться с намиПодключиться

Миграция хостов кластера Apache Kafka® в другую зону доступности

Статья создана
Обновлена 3 декабря 2024 г.

Примечание

В регионе Казахстан доступна только зона доступности kz1-a.

Хосты кластера 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® в другую зону доступности:

  1. Создайте подсеть в зоне доступности, в которую вы переносите кластер.

  2. Если группа безопасности кластера настроена для подсети в зоне доступности, из которой переносится кластер, перенастройте группу для новой подсети. Для этого в правилах группы безопасности замените CIDR исходной подсети на CIDR новой подсети.

  3. Измените зону доступности у кластера и его хоста Apache Kafka®:

    1. Перейдите на страницу каталога и выберите сервис Managed Service for Kafka.
    2. В строке с нужным кластером нажмите на значок , затем выберите Редактировать.
    3. В разделе Сетевые настройки укажите новую зону доступности.
    4. Укажите подсеть в новой зоне доступности, если в ней находится больше одной подсети.
    5. Нажмите кнопку Сохранить.

    Если у вас еще нет интерфейса командной строки Yandex Cloud, установите и инициализируйте его.

    По умолчанию используется каталог, указанный в профиле CLI. Вы можете указать другой каталог с помощью параметра --folder-name или --folder-id.

    Чтобы изменить зону доступности у кластера и его хоста Apache Kafka®, выполните команду:

    yc managed-kafka cluster update <имя_или_идентификатор_кластера> \
   --zone-ids <зона_доступности> \
   --subnet-ids <идентификатор_подсети>

    Если в новой зоне доступности находится только одна подсеть, параметр --subnet-ids указывать не обязательно.

    1. Откройте актуальный конфигурационный файл Terraform с планом инфраструктуры.

      О том, как создать такой файл, см. в разделе Создание кластера Apache Kafka®.

    2. Укажите в описании кластера Managed Service for Apache Kafka® новую подсеть в параметре subnet_ids и новую зону доступности в параметре zones:

      resource "yandex_mdb_kafka_cluster" "<имя_кластера>" {
  ...
  subnet_ids = ["<подсеть>"]
  config {
    ...
    zones = ["<зона_доступности>"]
  }
  ...
}

      Если в новой зоне доступности находится только одна подсеть, параметр subnet_ids указывать не обязательно.

    3. Проверьте корректность настроек.

      1. В командной строке перейдите в каталог, в котором расположены актуальные конфигурационные файлы Terraform с планом инфраструктуры.

      2. Выполните команду:

        terraform validate

        Если в файлах конфигурации есть ошибки, Terraform на них укажет.

    4. Подтвердите изменение ресурсов.

      1. Выполните команду для просмотра планируемых изменений:

        terraform plan

        Если конфигурации ресурсов описаны верно, в терминале отобразится список изменяемых ресурсов и их параметров. Это проверочный этап: ресурсы не будут изменены.

      2. Если вас устраивают планируемые изменения, внесите их:

        1. Выполните команду:

          terraform apply

        2. Подтвердите изменение ресурсов.

        3. Дождитесь завершения операции.

    Подробнее см. в документации провайдера 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 (одной строкой через запятую).

  4. Чтобы успешно выполнять подключение к топикам после миграции, укажите FQDN нового брокера в вашем бэкенде или клиенте (например, в коде или графической IDE). Удалите FQDN прежнего брокера в первоначальной зоне доступности.

    Чтобы узнать FQDN, получите список хостов в кластере:

    1. В консоли управления перейдите в нужный каталог.
    2. В списке сервисов выберите Managed Service for Kafka.
    3. Нажмите на имя нужного кластера, затем выберите вкладку Хосты.
    yc managed-kafka cluster list-hosts <имя_или_идентификатор_кластера>

    FQDN указан в выводе команды, в столбце NAME.

    Воспользуйтесь методом REST API listHosts для ресурса Cluster или вызовом gRPC API ClusterService/ListHosts и передайте в запросе идентификатор требуемого кластера в параметре clusterId. Чтобы узнать идентификатор, получите список кластеров в каталоге.

    FQDN указан в ответе в поле hosts[].name.

Миграция кластера с одним хостом с помощью вспомогательных инструментов

Чтобы в кластере Managed Service for Apache Kafka® перенести хост Apache Kafka® в другую зону доступности:

  1. Создайте подсеть в зоне доступности, в которую вы переносите кластер.

  2. Если группа безопасности кластера настроена для подсети в зоне доступности, из которой переносится кластер, перенастройте группу для новой подсети. Для этого в правилах группы безопасности замените CIDR исходной подсети на CIDR новой подсети.

  3. Создайте кластер Managed Service for Apache Kafka®, конфигурация которого отличается от конфигурации первоначального кластера только подсетью и группой безопасности.

  4. Перенесите данные из первоначального кластера в новый с помощью одного из двух инструментов:

    • MirrorMaker — подойдет как встроенный в Managed Service for Apache Kafka® MirrorMaker-коннектор, так и утилита MirrorMaker.
    • Data Transfer.

  5. Чтобы успешно выполнять подключение к топикам после миграции, укажите FQDN брокера нового кластера в вашем бэкенде или клиенте (например, в коде или графической IDE). Удалите FQDN брокера прежнего кластера в первоначальной зоне доступности.

    Чтобы узнать FQDN, получите список хостов в кластере:

    1. В консоли управления перейдите в нужный каталог.
    2. В списке сервисов выберите Managed Service for Kafka.
    3. Нажмите на имя нужного кластера, затем выберите вкладку Хосты.
    yc managed-kafka cluster list-hosts <имя_или_идентификатор_кластера>

    FQDN указан в выводе команды, в столбце NAME.

    Воспользуйтесь методом REST API listHosts для ресурса Cluster или вызовом gRPC API ClusterService/ListHosts и передайте в запросе идентификатор требуемого кластера в параметре clusterId. Чтобы узнать идентификатор, получите список кластеров в каталоге.

    FQDN указан в ответе в поле hosts[].name.

  6. Удалите первоначальный кластер Managed Service for Apache Kafka®.

Миграция кластера с несколькими хостами

Если создать кластер из более чем одного хоста Apache Kafka®, в кластер автоматически добавляются три выделенных хоста ZooKeeper. Каждому из хостов назначается подсеть из разных зон доступности. После создания кластера для него нельзя сменить подсеть в зоне доступности.

Процесс миграции зависит от того, в каких зонах доступности располагаются хосты Apache Kafka® и ZooKeeper до миграции и сколько подсетей находится в каждой зоне доступности. Ознакомьтесь с частными случаями в примерах, чтобы лучше понять особенности миграции.

Чтобы в кластере перенести хосты Apache Kafka® в другую зону доступности:

  1. Узнайте, в каких зонах доступности располагаются хосты Apache Kafka® и ZooKeeper:

    1. В консоли управления перейдите в нужный каталог.
    2. В списке сервисов выберите Managed Service for Kafka.
    3. Нажмите на имя нужного кластера, затем выберите вкладку Хосты. Зона доступности каждого хоста указана в столбце Зона доступности.
    yc managed-kafka cluster list-hosts <имя_или_идентификатор_кластера>

    Зона доступности указана в выводе команды, в столбце ZONE ID.

    Воспользуйтесь методом REST API listHosts для ресурса Cluster или вызовом gRPC API ClusterService/ListHosts и передайте в запросе идентификатор требуемого кластера в параметре clusterId. Чтобы узнать идентификатор, получите список кластеров в каталоге.

    Зона доступности указана в ответе в поле hosts[].zoneId.

  2. Если в списке нет целевой зоны доступности, куда вы переносите хосты Apache Kafka®, создайте подсеть в этой зоне.

    Если в списке есть целевая зона доступности, во время миграции хосты Apache Kafka® будут перенесены в подсеть, в которой уже располагаются хосты Apache Kafka® или ZooKeeper в этой зоне доступности.

  3. Проверьте группу безопасности кластера. Если она настроена для подсети в исходной зоне доступности, перенастройте группу для подсети в целевой зоне доступности. Для этого в правилах группы безопасности замените CIDR исходной подсети на CIDR целевой подсети.

  4. Измените зону доступности у кластера и его хостов Apache Kafka®:

    1. Перейдите на страницу каталога и выберите сервис Managed Service for Kafka.

    2. В строке с нужным кластером нажмите на значок , затем выберите Редактировать.

    3. В разделе Сетевые настройки укажите новый набор зон доступности. Их количество не должно уменьшиться.

      Важно

      Добавив новую зону доступности, снимите выбор с одной из старых. Если этого не сделать, после сохранения настроек вы не сможете удалить старую зону доступности.

    4. Укажите подсеть в новой зоне доступности, если:

      • выполняется миграция в зону доступности, где хосты Apache Kafka® или ZooKeeper ранее не размещались;
      • в целевой зоне доступности находится больше одной подсети.

    5. Нажмите кнопку Сохранить.

    Если у вас еще нет интерфейса командной строки 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.

    1. Откройте актуальный конфигурационный файл Terraform с планом инфраструктуры.

      О том, как создать такой файл, см. в разделе Создание кластера Apache Kafka®.

    2. Измените в описании кластера Managed Service for Apache Kafka® список зон доступности в параметре zones:

      resource "yandex_mdb_kafka_cluster" "<имя_кластера>" {
  ...
  config {
    ...
    zones = ["<зоны_доступности>"]
  }
  ...
}

      Количество зон доступности не должно уменьшиться.

      Важно

      Добавив новую зону доступности, удалите из списка одну из старых. Если этого не сделать, после сохранения настроек вы не сможете удалить старую зону доступности.

    3. Измените в параметре subnet_ids список подсетей, если выполняются два условия:

      • вы переносите хосты Apache Kafka® в зону доступности, где хосты ZooKeeper ранее не размещались;
      • в целевой зоне доступности находится больше одной подсети.

      Если хосты кластера размещаются в зонах доступности ru-central1-a и ru-central1-b и вы меняете зоны доступности на ru-central1-a, ru-central1-b и ru-central1-d, укажите подсеть, только если в зоне ru-central1-d несколько подсетей. Иначе подсеть указывать не нужно.

      resource "yandex_mdb_kafka_cluster" "<имя_кластера>" {
  ...
  subnet_ids = ["<подсети>"]
  ...
}

    4. Проверьте корректность настроек.

      1. В командной строке перейдите в каталог, в котором расположены актуальные конфигурационные файлы Terraform с планом инфраструктуры.

      2. Выполните команду:

        terraform validate

        Если в файлах конфигурации есть ошибки, Terraform на них укажет.

    5. Подтвердите изменение ресурсов.

      1. Выполните команду для просмотра планируемых изменений:

        terraform plan

        Если конфигурации ресурсов описаны верно, в терминале отобразится список изменяемых ресурсов и их параметров. Это проверочный этап: ресурсы не будут изменены.

      2. Если вас устраивают планируемые изменения, внесите их:

        1. Выполните команду:

          terraform apply

        2. Подтвердите изменение ресурсов.

        3. Дождитесь завершения операции.

    Подробнее см. в документации провайдера 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 ранее не размещались;
      • в целевой зоне доступности находится больше одной подсети.

      Если хосты кластера размещаются в зонах доступности ru-central1-a и ru-central1-b и вы меняете зоны доступности на ru-central1-a, ru-central1-b и ru-central1-d, укажите подсеть, только если в зоне ru-central1-d несколько подсетей. Иначе подсеть указывать не нужно.

    • Список настроек, которые необходимо изменить, в параметре updateMask.

    Важно

    Метод API переопределит все параметры изменяемого объекта, которые не были явно переданы в запросе, на значения по умолчанию. Чтобы избежать этого, перечислите настройки, которые вы хотите изменить, в параметре updateMask (одной строкой через запятую).

  5. Чтобы успешно выполнять подключение к топикам после миграции, укажите FQDN нового брокера в вашем бэкенде или клиенте (например, в коде или графической IDE). Удалите FQDN прежнего брокера в первоначальной зоне доступности.

    Чтобы узнать FQDN, получите список хостов в кластере:

    1. В консоли управления перейдите в нужный каталог.
    2. В списке сервисов выберите Managed Service for Kafka.
    3. Нажмите на имя нужного кластера, затем выберите вкладку Хосты.
    yc managed-kafka cluster list-hosts <имя_или_идентификатор_кластера>

    FQDN указан в выводе команды, в столбце NAME.

    Воспользуйтесь методом REST API listHosts для ресурса Cluster или вызовом gRPC API ClusterService/ListHosts и передайте в запросе идентификатор требуемого кластера в параметре clusterId. Чтобы узнать идентификатор, получите список кластеров в каталоге.

    FQDN указан в ответе в поле hosts[].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 в другую зону доступности.

Пример переноса данных с помощью сервиса Data Transfer см. в практическом руководстве.

Предыдущая
Получение списка хостов кластера
Следующая
Удаление кластера