Перенос кластера для поддержки нескольких зон доступности (предварительная версия)
Многие регионы Azure предоставляют зоны доступности, которые разделены группами центров обработки данных в пределах региона. Зоны доступности располагаются достаточно близко для установления подключений с низкой задержкой к другим зонам доступности. Они подключены высокопроизводительной сетью с задержкой кругового пути менее 2 мс. Однако зоны доступности расположены достаточно далеко друг от друга, чтобы снизить вероятность воздействия локальных сбоев или погода сразу не несколько из них. Зоны доступности имеют независимую инфраструктуру питания, охлаждения и сетевую инфраструктуру. Они разработаны таким образом, чтобы региональные службы, емкость и высокий уровень доступности поддерживались остальными зонами, если одна зона испытывает сбой. Дополнительные сведения см. в Зоны доступности Azure.
Кластеры Azure Data Explorer можно настроить для использования зон доступности в поддерживаемых регионах. Используя зоны доступности, кластер может лучше противостоять сбою одного центра обработки данных в регионе для поддержки сценариев непрерывности бизнес-процессов.
При создании кластера в портал Azure или программно можно настроить зоны доступности с помощью одного из следующих методов:
- REST API
- Пакет SDK для C#
- Пакет SDK для Python
- PowerShell
- Шаблон ARM
Внимание
- После настройки кластера с зонами доступности невозможно изменить кластер, чтобы не использовать зоны доступности.
- Несколько зон не поддерживаются во всех регионах. Поэтому кластеры, расположенные в этих регионах, не могут быть настроены для использования зон доступности.
- Использование зон доступности несет дополнительные затраты.
Примечание.
- Прежде чем продолжить, убедитесь, что вы знакомы с процессом миграции и рекомендациями.
- Эти действия также можно использовать для изменения зон существующего кластера, использующего зоны доступности.
В этой статье раскрываются следующие темы:
Необходимые компоненты
Убедитесь, что кластер находится в регионе, где поддерживается миграция в несколько зон доступности.
Для переноса кластера для поддержки зон доступности требуется кластер, который был развернут без каких-либо зон доступности.
Для изменения зон кластера требуется кластер, настроенный с зонами доступности.
Для REST API ознакомьтесь с управлением ресурсами Azure с помощью REST API.
Сведения о других программных методах см. в разделе "Предварительные требования".
Получение списка зон доступности для региона кластера
Список зон доступности для кластера можно получить следующим образом:
Настройка кластера для поддержки зон доступности
Чтобы добавить зоны доступности в существующий кластер, необходимо обновить атрибут кластера zones
со списком целевых зон доступности. Следуйте инструкциям для предпочтительного метода, используя сведения в следующей таблице:
Параметр | Значение |
---|---|
subscriptionId |
Идентификатор подписки кластера |
resourceGroupName |
Имя группы ресурсов кластера |
clusterName |
Имя кластера |
apiVersion |
2023-05-02 или более поздней версии. |
Внимание
Изменение зон доступности для существующего кластера изменяет только зоны доступности для вычислительных ресурсов. Постоянное хранилище не изменяется.
Следуйте инструкциям по развертыванию шаблона.
Вызов REST API к следующей конечной точке, в которой вы замените параметры значениями:
PUT https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Kusto/clusters/{clusterName}?api-version={apiVersion}
Укажите зоны доступности в тексте запроса. Например, чтобы настроить кластер для использования зон доступности 1, 2 и 3, задайте текст следующим образом:
{ "zones": [ "{zone1}", "{zone2}", "{zone3}" ] }
Во время миграции на странице обзора кластера появится следующее сообщение в портал Azure. Сообщение удаляется после завершения миграции.
Изменение зональности для хранилища этого кластера выполняется. Время обновления может отличаться в зависимости от объема данных.
Архитектура кластеров с зонами доступности
При настройке зон доступности ресурсы кластера развертываются следующим образом:
Вычислительный уровень: Azure Data Explorer — это платформа распределенных вычислений с двумя или более узлами. Если зоны доступности настроены, вычислительные узлы распределяются по определенной зоне доступности для максимальной устойчивости внутри региона. Сбой зоны может снизить производительность кластера, пока не будут развернуты неисправные вычислительные ресурсы в выживших зонах. Мы рекомендуем настроить максимальные доступные зоны в регионе.
Примечание.
- В некоторых случаях из-за ограничений емкости вычислений для уровня вычислений будут доступны только частичные зоны доступности.
- Вычислительный слой кластера реализует оптимальный подход к равномерному распространению экземпляров между выбранными зонами.
Постоянный уровень хранения. Кластеры используют служба хранилища Azure в качестве устойчивого уровня сохраняемости. Если зоны доступности настроены, ZRS включен, разместите реплики хранилища во всех трех зонах доступности для максимальной устойчивости внутри региона.
Примечание.
- ZRS несет дополнительную стоимость.
- Если зоны доступности не настроены, ресурсы хранилища развертываются с параметром по умолчанию локально избыточного хранилища (LRS), размещение всех 3 реплик является одной зоной.
Процесс миграции
Когда существующий кластер, который был развернут без зон доступности, настроен для поддержки зон доступности, в процессе миграции необходимо выполнить следующие действия.
Вычислительные ресурсы распределены в определенных зонах доступности
Процесс распространения вычислительных ресурсов включает этап подготовки, в котором прогреется зональный кэш вычислительных ресурсов. На этапе подготовки вычислительные ресурсы существующего кластера продолжают функционировать, обеспечивая непрерывную работу службы. Этот этап подготовки может занять до десятков минут. Переход к новым вычислительным ресурсам происходит только после полной подготовки и эксплуатации. Этот подход параллельной обработки обеспечивает относительно простой опыт работы, при этом в процессе переключения обычно выполняется только минимальное нарушение работы службы, обычно продолжительность от одного до трех минут. Однако важно отметить, что производительность запросов может повлиять на производительность во время миграции SKU. Степень влияния может отличаться в зависимости от конкретных шаблонов использования.
Исторические данные сохраняемого хранилища переносятся в ZRS
Процесс миграции зависит от региональной поддержки перехода от LRS к хранилищу ZRS, а также доступной емкости учетных записей хранения в выбранных зонах. Передача исторических данных может быть длительным процессом, потенциально занимает несколько часов или даже расширяется до нескольких недель.
Все новые данные записываются в ZRS
После запуска запроса на миграцию в зоны доступности все новые данные реплицируются и хранятся в конфигурации ZRS.
Примечание.
- После запроса миграции может возникнуть задержка до нескольких минут до начала записи всех новых данных в конфигурации ZRS.
- Если в кластере есть прием потоковой передачи, повторное использование новых данных для записи в виде данных ZRS может занять до 30 дней.
Рекомендации
Запрос на миграцию в зоны доступности может оказаться не успешным из-за ограничений емкости. Для успешной миграции должно быть достаточно вычислительных ресурсов и хранилища для поддержки миграции. При наличии ограничений емкости вы получите сообщение об ошибке, указывающее на проблему.