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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  При настройке кластера для зональной избыточности данные хранятся с помощью зонально избыточного хранилища Azure (ZRS), которое синхронно реплицирует не менее трех копий данных в нескольких зонах доступности.

  

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

  Это важно

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

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

  

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

Требования

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

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

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

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

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

Cost

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

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

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

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

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

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

  Замечание

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

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

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

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

• Проверьте конфигурацию зоны доступности для кластеров: Вы можете использовать свойство состояния зоны кластера ( zoneStatus свойство в REST API) для проверки конфигурации зоны доступности кластера.

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

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

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

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

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

Вычислительный слой кластера использует подход «лучшие усилия» для равномерного распределения экземпляров по выбранным вами зонам.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Надежность в Azure
• Обзор Azure Data Explorer
• Общие сведения о непрерывности бизнес-процессов и аварийном восстановлении