Создавайте решения для обеспечения непрерывности бизнеса и аварийного восстановления с помощью Azure Data Explorer

  • Статья

В этой статье подробно описано, как подготовиться к региональному отключению Azure путем репликации ресурсов, управления и приема данных Azure Data Explorer в разных регионах Azure. Приведен пример приема данных с помощью Центров событий Azure. Оптимизация затрат также обсуждается для различных конфигураций архитектуры. Более подробные сведения об архитектуре и решениях для восстановления см. в обзоре непрерывности бизнеса.

Подготовьтесь к региональному отключению Azure, чтобы защитить свои данные

Azure Data Explorer не поддерживает автоматическую защиту от сбоя всего региона Azure. Это нарушение может произойти во время стихийного бедствия, например землетрясения. Если вам требуется решение для аварийного восстановления, выполните следующие действия, чтобы обеспечить непрерывность бизнеса. На этих шагах вы реплицируете свои кластеры, управление и прием данных в двух парных регионах Azure.

  1. Создайте два или более независимых кластера в двух парных регионах Azure.
  2. Репликация всех действий управления, таких как создание новых таблиц или управление ролями пользователей в каждом кластере.
  3. Прием данных в каждом кластере параллельно.

Создание нескольких независимых кластеров

Создайте несколько кластеров Azure Data Explorer в нескольких регионах. Убедитесь, что как минимум два из этих кластеров созданы в парных регионах Azure.

На следующем изображении показаны реплики, три кластера в трех разных регионах.

Создание независимых кластеров.

Воспроизведение управленческой деятельности

Реплицируйте действия управления, чтобы в каждой реплике была одинаковая конфигурация кластера.

  1. Создайте на каждой реплике одно и то же:

  2. Управляйте аутентификацией и авторизацией на каждой реплике.

    Повторяющиеся действия по управлению.

Решение для аварийного восстановления с использованием концентратора событий

После того как вы завершите Подготовку к региональному отключению Azure для защиты ваших данных, ваши данные и управление будут распределены по нескольким регионам. Если произойдет сбой в одном регионе, Azure Data Explorer сможет использовать другие реплики.

Настройка трансляции с помощью концентратора событий

Чтобы принимать данные из Центров событий Azure в кластер Azure Data Explorer каждого региона, сначала реплицируйте конфигурацию Центров событий Azure в каждом регионе. Затем настройте реплику Azure Data Explorer каждого региона для приема данных из соответствующих Центров событий.

Примечание

Прием через Центр событий Azure, центр Интернета вещей и хранилище является надежным. Если кластер недоступен в течение определенного периода времени, он наверстает упущенное позже и вставляет все ожидающие сообщения или большие двоичные объекты. Этот процесс основан на контрольных точках.

Прием с помощью Центры событий Azure.

Как показано на схеме ниже, ваши источники данных создают события для концентраторов событий во всех регионах и каждая реплика Azure Data Explorer потребляет события. Компоненты визуализации данных, такие как Power BI, Grafana или веб-приложения на базе SDK, могут запрашивать одну из реплик.

Источники данных для визуализации данных.

Оптимизация затрат

Теперь вы готовы оптимизировать свои реплики, используя некоторые из следующих методов.

Создание конфигурации восстановления данных по требованию

Как показано на схеме ниже, ваши источники данных создают события для концентратора событий, настроенного для отработки отказа, и каждая реплика Azure Data Explorer использует события. Чтобы оптимизировать затраты, вы можете реализовать архитектурный вариант, чтобы сбалансировать время, отработку отказа и стоимость. В конфигурации восстановления данных по требованию была реализована оптимизация затрат за счет внедрения пассивных реплик Azure Data Explorer. Эти реплики включаются только в случае аварии в основном регионе (например, регионе A). Реплики в регионах B и C не должны быть активными 24/7, что значительно снижает стоимость. Однако в большинстве случаев производительность этих реплик будет ниже, чем у первичного кластера. Дополнительные сведения см. в разделе Конфигурация "Восстановление данных по требованию".

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

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

Запуск и остановка реплик

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

az kusto cluster stop --name=<clusterName> --resource-group=<rgName> --subscription=<subscriptionId>”

Реализация службы приложений высокой доступности

Создание клиента BCDR службы приложений Azure

В этом разделе показано, как создать службу приложений Azure, которая поддерживает подключение к одному первичному и нескольким вторичным кластерам Azure Data Explorer. На следующем изображении показана установка службы приложений Azure.

Создайте службу приложений Azure.

Совет

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

  1. Используйте этот шаблонный код для службы приложения. Для реализации мультикластерного клиента был создан класс AdxBcdrClient. Каждый запрос, выполняемый с помощью этого клиента, будет отправлен сначала в первичный кластер. В случае сбоя запрос будет отправлен на вторичные реплики.

  2. Используйте настраиваемые метрики аналитики приложений для измерения производительности и распределения запросов в первичный и вторичный кластеры.

Тестирование клиента BCDR службы приложений Azure

Мы провели тест с использованием нескольких реплик Azure Data Explorer. После смоделированного сбоя основного и дополнительного кластеров вы можете увидеть, что клиент BCDR службы приложений ведет себя должным образом.

Проверьте клиент службы приложений BCDR.

Кластеры Azure Data Explorer распределены по Западной Европе (2xD14v2 основных), Юго-Восточной Азии и Востоку США (2xD11v2).

Время отклика на межпланетный запрос.

Примечание

Более медленное время ответа связано с разными артикулами и межпланетными запросами.

Выполните динамическую или статическую маршрутизацию

Используйте методы маршрутизации диспетчера трафика Azure для динамической или статической маршрутизации запросов. Диспетчер трафика Azure — это балансировщик нагрузки трафика на основе DNS, который позволяет распределять трафик службы приложений. Этот трафик оптимизируется для служб в глобальных регионах Azure, обеспечивая при этом высокую доступность и скорость реакции.

Вы также можете использовать маршрутизацию Azure Front Door. Для сравнения этих двух методов см. Балансировка нагрузки с помощью пакета доставки приложений Azure.

Оптимизация затрат в конфигурации "активный — активный"

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

Используйте оптимизированное автомасштабирование для оптимизации затрат

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

Использование оптимизированного автомасштабирования в этом примере позволило сэкономить примерно 50 % затрат по сравнению с одинаковым масштабом по горизонтали и вертикали на всех репликах.

См. также