Надежность в Azure Data Explorer

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

При использовании Azure надежность является общей ответственностью. Корпорация Майкрософт предоставляет ряд возможностей для поддержки устойчивости и восстановления. Вы несете ответственность за понимание того, как работают эти возможности во всех используемых вами службах, а также за выбор возможностей, необходимых для достижения бизнес-целей и целей бесперебойной работы.

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

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

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

• Развертывание полного кластера. Azure Data Explorer предоставляет бесплатные кластеры для пробной версии. Для промышленных нагрузок разверните полный кластер.

• Включите поддержку зоны доступности. Azure Data Explorer поддерживает зоны доступности. При включении поддержки зон доступности служба распределяет вычислительные узлы по нескольким зонам доступности и хранит данные в хранилище с зональной избыточностью (ZRS). Эта конфигурация повышает устойчивость к сбоям зоны доступности.

Обзор архитектуры надежности

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

Логическая архитектура

Основной ресурс, который вы развертываете, — это кластер, представляющий инфраструктуру, необходимую для приема, хранения и запроса данных. С помощью кластера создаются базы данных и эти базы данных содержат таблицы.

Схема, на котором показан кластер Azure Data Explorer, содержащий два раздела базы данных, расположенные рядом. Слева находится блок с надписью «database», а внутри него — три отдельных блока таблиц, расположенных вертикально друг над другом, каждый с надписью «table». Справа находится второй блок с надписью «database», а внутри него расположены два блока таблиц друг над другом, каждый из которых также имеет надпись «table». На схеме показана иерархия, в которой кластер является контейнером верхнего уровня, каждая база данных является дочерним контейнером в кластере, а таблицы — дочерними объектами в каждой базе данных. В левой и правой базах данных находятся параллельные одноранговые узлы в одном кластере, и они могут содержать разные числа таблиц.

Кластеры выполняют прием данных из других источников данных и загружают их в таблицу в кластере. Затем можно запрашивать данные с помощью синтаксиса языка запросов Kusto (KQL). Кластеры также имеют набор операций управления, которые можно выполнить.

Физическая архитектура

Кластер Azure Data Explorer имеет два основных уровня, которые применимы к конфигурации надежности:

• Вычислительный уровень: Azure Data Explorer — это платформа распределённых вычислений, которая может иметь от двух до множества виртуальных машин узлов (VM) в зависимости от масштаба и типа роли узла. Узлы обрабатывают прием данных и обработку запросов. Вы не видите и не управляете виртуальными машинами узла напрямую. Платформа автоматически управляет созданием экземпляров, мониторингом работоспособности и заменой неработоспособных узлов. При настройке кластера для использования нескольких зон доступности узлы распределяются между различными центрами обработки данных.

• Уровень хранилища: Azure Data Explorer использует службу хранилища Azure в качестве устойчивого уровня сохраняемости. Хранилище автоматически обеспечивает отказоустойчивость с параметром по умолчанию, предлагающим локально избыточное хранилище (LRS) в центре обработки данных. Сохраняются три реплики. Если во время использования реплика теряется, будет немедленно запущена другая, без прерывания работы. При настройке кластера для использования нескольких зон доступности реплики распределяются между различными центрами обработки данных.

Схема, показывющая кластер Azure Data Explorer с логической архитектурой двух слоев. На верхнем уровне, обозначенном как вычислительный слой, два блока узлов расположены рядом, чтобы показать, что вычислительная нагрузка распределяется между несколькими узлами в кластере. Нижний слой обозначен как слой хранения (с избыточностью между зонами), в котором три блока копий хранилища расположены слева направо как копия 1, копия 2 и копия 3. На схеме представлена многоуровневая связь: уровень вычислений обрабатывает операции приема и запроса.

Дополнительные сведения см. в статье о работе Azure Data Explorer.

Устойчивость к временным сбоям

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

Все облачные приложения должны следовать рекомендациям по обработке временных ошибок Azure при обмене данными с любыми размещенными в облаке API, базами данных и другими компонентами. Дополнительные сведения см. в Рекомендациях по обработке временных сбоев.

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

• При использовании приема в очереди полагайтесь на встроенное поведение повторных попыток.

• Используйте клиентские библиотеки и пакеты SDK, предоставляемые Microsoft, которые автоматически повторяют попытку при временных сбоях.

• Если вы используете Azure Data Explorer REST API напрямую, повторите все запросы и операции управления, которые завершаются сбоем из-за временной ошибки.

Устойчивость к сбоям зоны доступности

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

Azure Data Explorer поддерживает два типа конфигурации зоны доступности:

• Избыточность между зонами (рекомендуется): При включении зон доступности в кластере узлы кластера распределяются по нескольким зонам. Корпорация Майкрософт управляет распределением узлов между выбранными зонами доступности и обрабатывает обнаружение и реагирование на сбои зоны доступности. Кластер, избыточный по зонам, устойчив к сбою зоны доступности.

  При настройке кластера с резервированием по зонам Storage ZRS синхронно реплицирует как минимум три копии ваших данных между несколькими зонами доступности.

  

  Схема, на которую показан кластер Azure Data Explorer, использующий несколько зон доступности. Три вертикальных столбца : зона доступности 1, зона доступности 2 и зона доступности 3. Большой прямоугольник с надписью «кластер Azure Data Explorer» занимает все три столбца. Блок разделён по горизонтали на два слоя. Верхняя половина — это слой вычислений. Один узел находится в зоне доступности 1, а другой узел находится в зоне доступности 2. Нижняя часть — это уровень хранения (с резервированием между зонами). Три реплики хранилища показаны как копия 1 — слева, копия 2 — в центре и копия 3 — справа, при этом каждая соотнесена с отдельной зоной доступности. Один кластер Azure Data Explorer охватывает несколько зон, при этом вычислительные ресурсы распределены по этим зонам, а данные реплицируются в три копии, размещенные в разных зонах.

• Зональный: Вы можете по выбору выбрать одну зону при включении зон доступности на вашем кластере. Microsoft помещает все вычислительные узлы в ту зону. Эта конфигурация является зональным (однозонным) кластером. Зональный кластер может снизить задержку для необычно чувствительных к задержкам рабочих нагрузок, так как все вычислительные узлы выполняются в одной зоне, но не обеспечивают устойчивость к сбоям зон.

  Это важно

  Фиксация ресурсов в одной зоне доступности рекомендуется только в том случае, если задержка между зонами слишком велика для ваших нужд и после подтверждения, что она не соответствует вашим требованиям. По себе зональный ресурс не обеспечивает устойчивость к сбоям зоны доступности. Чтобы повысить устойчивость зонального ресурса, необходимо явно развернуть ресурсы в нескольких зонах доступности и настроить маршрутизацию трафика и аварийное переключение. Дополнительные сведения см. в разделе "Зональные ресурсы" и "Устойчивость зоны".

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

  

  Схема с Azure Data Explorer кластером, использующим одну зону доступности. Три вертикальных столбца : зона доступности 1, зона доступности 2 и зона доступности 3. Большой блок с надписью «Azure Data Explorer cluster» занимает только один столбец. Блок разделён по горизонтали на два слоя. Верхняя половина — это уровень вычислений: оба узла находятся в зоне доступности 1. В нижней половине находится слой хранения (с локальной избыточностью), с тремя репликами в одной зоне доступности. Один кластер Azure Data Explorer ограничен одной зоной с вычислительными ресурсами и хранилищем, расположенными в этой зоне.

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

Требования

• Поддержка региона: Поддержка зоны доступности доступна в регионах Azure, поддерживающих зоны доступности.

  Однако некоторые типы и размеры вычислительных узлов доступны только в определенных регионах или определенных зонах в пределах региона.

• Полные кластеры: Поддержка зоны доступности доступна с полными кластерами. Он недоступен с бесплатными кластерами.

Рекомендации

Выбор зоны: Для вычислительных узлов можно выбрать, какие зоны доступности следует использовать. Microsoft управляет размещением зоны хранения, а реплики хранилища могут находиться в разных зонах от вычислительных узлов.

Cost

Включение поддержки зон доступности влечет дополнительные расходы, поскольку ZRS тарифицируется по более высокой ставке, чем LRS. Дополнительные сведения см. в разделе о ценах на службу хранилища Azure.

Вычислительные узлы оплачиваются по той же ставке, независимо от того, используете ли вы поддержку зоны доступности или нет. Дополнительные сведения см. в разделе о ценах Azure Data Explorer.

Настройка поддержки зоны доступности

• Создайте новый кластер с поддержкой зоны доступности. Вы можете включить поддержку зоны доступности при создании нового кластера Azure Data Explorer. Дополнительные сведения см. в разделе "Создание кластера и базы данных".

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

  Чтобы выбрать зоны самостоятельно или создать зональный кластер, используйте другой подход к развертыванию, например API Azure Resource Manager или Bicep. В большинстве случаев создайте зонально-избыточный кластер и используйте все зоны в регионе.

  Замечание

  При выборе используемых зон доступности вы фактически выбираете логическую зону доступности. При развертывании других компонентов рабочей нагрузки в другой подписке Azure они могут использовать другой номер логической зоны доступности для доступа к той же физической зоне доступности. Дополнительные сведения см. в разделе "Физические и логические зоны доступности".

• Включите зоны доступности в существующем кластере (предварительная версия). Вы можете перенести существующий незональный кластер для использования зон доступности. Эта возможность доступна в предварительной версии. Дополнительные сведения см. в статье "Миграция кластера для поддержки нескольких зон доступности".

• Перенастройка зон доступности в существующем кластере (предварительная версия). Вы можете изменить зоны, используемые для кластера. Эта возможность доступна в предварительной версии. Дополнительные сведения см. в статье "Миграция кластера для поддержки нескольких зон доступности".

• Отключите поддержку зоны доступности в существующем кластере. После настройки кластера с зонами доступности невозможно изменить кластер, чтобы не использовать зоны доступности.

• Проверьте конфигурацию зоны доступности для кластеров. Используйте свойство состояния зоны кластера ( zoneStatus свойство в REST API), чтобы проверить конфигурацию зоны доступности кластера. Значение Zonal означает, что кластер использует зоны доступности, но это не означает, что кластер работает только в одной зоне.

  Чтобы определить, является ли кластер зональным или избыточным в зоне, используйте zones свойство. Если список зон содержит одну зону, кластер зональный (однозонный). Если у него есть несколько зон, это избыточность зоны.

Планирование ресурсов и управление ими

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

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

Распределение экземпляров между зонами

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

Поведение, когда все зоны работоспособны

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

• Операция между зонами: Во время нормальной работы Azure Data Explorer использует все доступные вычислительные узлы для приема, обработки запросов и других операций. Работа распределяется по узлам независимо от их зоны доступности.

• Репликация данных между зонами: Поведение репликации данных между зонами зависит от конфигурации зоны доступности, используемой кластером.

  • Избыточность между зонами: Данные синхронно реплицируются в зонах доступности с помощью хранилища ZRS, что обеспечивает высокий уровень согласованности данных и снижает риск потери данных во время сбоя зоны.

  • Зональное размещение: Данные хранятся с использованием Storage LRS, что означает, что все три копии могут храниться в одной зоне доступности.

Поведение во время сбоя зоны

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

• Обнаружение и ответ: Ответственность за обнаружение и ответ зависит от конфигурации зоны доступности, используемой кластером.

  • Избыточность между зонами: Корпорация Майкрософт обнаруживает сбои зоны доступности и управляет ответом для Azure Data Explorer. Вам не нужно ничего делать, чтобы инициировать переключение зоны.

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

• Уведомление: Корпорация Майкрософт не уведомляет вас об отключении зоны. Однако вы можете использовать Работоспособность служб Azure для понимания общего состояния службы, включая любые сбои зоны, и настроить оповещения Service Health для уведомления о проблемах.

• Активные запросы: Активные запросы, использующие вычислительные ресурсы или ресурсы хранилища в зоне сбоя, могут быть завершены и должны быть извлечены клиентом. Убедитесь, что приложения подготовлены, следуя инструкциям по обработке временных ошибок.

• Ожидаемая потеря данных: Ожидаемая потеря данных зависит от конфигурации зоны доступности, используемой кластером.

  • Избыточность между зонами: Во время сбоя зоны доступности не ожидается потеря данных, так как данные синхронно реплицируются между зонами.

  • Зональный: Данные будут недоступны до тех пор, пока зона не восстановится. В маловероятном случае постоянной потери зоны, содержащей все реплики хранилища, данные могут быть окончательно потеряны.

• Ожидаемое время простоя: Ожидаемое время простоя зависит от конфигурации зоны доступности, используемой кластером.

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

  • Зональный: Вычислительные узлы кластера недоступны до восстановления зоны доступности. Вы также не сможете получить доступ к данным кластера во время сбоя зоны.

• Перераспределение: Поведение перенаправки трафика зависит от конфигурации зоны доступности, используемой кластером.

  • Избыточность между зонами: Azure Data Explorer направляет новые запросы к вычислительным ресурсам и ресурсам хранилища в оставшихся здоровых зонах.

  • Зональный: Кластер недоступен до восстановления зоны доступности.

Восстановление зоны

Когда не удалось восстановить зону доступности, корпорация Майкрософт повторно создает узлы кластера и реплики хранилища в этой зоне и восстанавливает нормальное распределение трафика во всех зонах. Вам не нужно предпринимать никаких действий.

Тестирование на сбои в зоне

Опции тестирования сбоев зоны зависят от конфигурации зоны доступности, которую использует кластер.

• С избыточностью между зонами: Microsoft полностью управляет переключением при сбое и восстановлением в зонах доступности для Azure Data Explorer. Не нужно инициировать или проверять процессы сбоя зоны доступности.

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

Устойчивость к сбоям на уровне региона

Кластер Azure Data Explorer развертывается в одном регионе Azure. Если этот регион становится недоступным, кластер и его данные недоступны.

Кастомные многорегиональные решения для повышения отказоустойчивости

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

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

Резервное копирование и восстановление

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

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

• Непрерывный экспорт периодически экспортирует данные во внешнее хранилище и обеспечивает точно один раз экспорт для поддерживаемых типов данных.

• Экспорт данных в облачное хранилище поддерживает ручной экспорт данных во внешнее хранилище.

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

Устойчивость к случайному удалению

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

• Случайное удаление кластера или базы данных: Случайное удаление кластера или базы данных — это безвозвратное действие. Предотвращение потери данных путем включения блокировки удаления в кластере или ресурсе базы данных.

• Случайное удаление таблицы: Пользователи с разрешениями администратора таблицы или более поздних версий могут удалять таблицы. Если один из этих пользователей случайно удаляет таблицу, ее можно восстановить с помощью команды отмены удаления таблицы . Для успешной выполнения этой команды необходимо сначала включить свойство восстановления в политике хранения.

• Случайное удаление внешней таблицы:Внешние таблицы — это сущности схемы запросов Kusto, которые ссылаются на данные, хранящиеся за пределами базы данных. Удаление внешней таблицы приводит к удалению только метаданных таблицы. Его можно восстановить, выполнив команду создания таблицы еще раз.

  Для хранилища BLOB-объектов Azure и внешних таблиц Azure Data Lake используйте возможность мягкого удаления для защиты от случайного удаления или перезаписи большого двоичного объекта в течение времени, заданного пользователем.

Устойчивость к обслуживанию служб

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

Чтобы узнать о предстоящем плановом обслуживании, используйте Работоспособность служб Azure.

Соглашение об уровне обслуживания

Соглашение об уровне обслуживания (SLA) для служб Azure описывает ожидаемую доступность каждой службы и условия, которые должно соответствовать вашему решению для достижения этого ожидания доступности. Для получения дополнительной информации см. Соглашения об уровне обслуживания для онлайн-сервисов.

Чтобы иметь право на доступность Azure Data Explorer, приложение должно обрабатывать временные ошибки, повторяя неудачные запросы.

Связанный контент

• Надежность в Azure
• Обзор Azure Data Explorer
• Обзор BCDR