Share via

Обзор непрерывности бизнес-процессов и аварийного восстановления

  • Статья

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

Уменьшение рисков возникновения нарушающих работу событий

Ошибка из-за действий человека

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

Случайное удаление кластера или базы данных

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

Случайное удаление таблицы

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

Случайное удаление внешней таблицы

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

Высокий уровень доступности Azure Data Explorer

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

Слой сохранения

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

Слой вычислений

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

Кластер конфигурации "ведущий — читатель"

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

Сбой зоны доступности Azure

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

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

Примечание

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

Сбой центра обработки данных Azure

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

Отказ региона Azure

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

Конфигурации аварийного восстановления

В этом разделе описаны несколько конфигураций аварийного восстановления в зависимости от требований к устойчивости (RPO и RTO), необходимых трудозатрат и стоимости.

RTO — это время, необходимое на восстановление после сбоя. Например, RTO в 2 часа значит, что приложение должно вернуться к работоспособному состоянию и запуститься в течение двух часов после сбоя. Целевая точка восстановления (RPO) — это интервал времени, которое может пройти во время сбоя, прежде чем количество данных, утерянных за этот период, превысит допустимый порог. Например, если RPO составляет 24 часа, а в приложении есть данные 15-летней давности, они все еще находятся в пределах параметров согласованного RPO.

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

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

Конфигурация "Активный — активный — активный"

Эта конфигурация также называется always-on. Для развертывания критически важных приложений, которые не допускают перебоев в работе, следует использовать несколько кластеров Azure Data Explorer в парных регионах Azure. Настройте прием, обработку и проверку параллельно для всех кластеров. Номер SKU кластера должен быть одинаковым во всех регионах. Azure обеспечит развертывание и поэтапное внедрение обновлений в парных регионах Azure. В таком случае отказ региона Azure не приведет к сбою приложения. Возможными последствиями сбоя станут задержка или снижение производительности.

Конфигурация

Конфигурация RPO RTO Трудозатраты Стоимость
Активный — активный — активный 0 часов 0 часов Ниже Наивысшая

Конфигурация "Активный — активный"

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

Конфигурация

Конфигурация RPO RTO Трудозатраты Стоимость
Активный — активный 0 часов 0 часов Ниже Высокий

Конфигурация "Активный — сервер горячей замены"

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

Конфигурация

Конфигурация RPO RTO Трудозатраты Стоимость
Активный — сервер горячей замены 0 часов Низкий Средний Средн.

Конфигурация "Восстановление данных по требованию"

Это решение предоставляет наименьшую устойчивость (наивысшее значение RPO и RTO), имеет наименьшую стоимость, однако требует наибольших трудозатрат. В этой конфигурации кластер восстановления данных отсутствует. Настройте непрерывный экспорт курированных данных (если нет необходимости в необработанных и промежуточных данных) в учетную запись хранения, настроенную на использование GRS (геоизбыточное хранилище). Кластер восстановления данных запускается при наличии сценария аварийного восстановления. В это время применяются языки описания данных DDL, конфигурация, политики и процессы. Данные поступают из хранилища со свойством kustoCreationTime, чтобы изменить время приема, которое по умолчанию соответствует системному времени.

Конфигурация кластера

Конфигурация RPO RTO Трудозатраты Стоимость
Кластер "Восстановление данных по требованию" Наивысшая Наивысшая Наивысшая Наименьшая

Сводка вариантов конфигураций аварийного восстановления

Конфигурация Устойчивость RPO RTO Трудозатраты Стоимость
Активный — активный — активный Наивысшая 0 часов 0 часов Ниже Наивысшая
Активный — активный Высокий 0 часов 0 часов Ниже Высокий
Активный — сервер горячей замены Средний 0 часов Низкий Средний Средн.
Кластер "Восстановление данных по требованию" Наименьшая Наивысшая Наивысшая Наивысшая Наименьшая

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

Следуйте приведенным ниже рекомендациям независимо от выбранной конфигурации аварийного восстановления.

  • Все объекты, политики и конфигурации базы данных следует сохранять в системе управления версиями, что позволит внедрить их в кластер из вашего средства автоматизации выпуска. Дополнительные сведения см. в документации по поддержке Azure DevOps для Azure Data Explorer.
  • Разрабатывайте, создавайте и внедряйте подпрограммы проверки, чтобы обеспечить синхронизацию всех кластеров с точки зрения данных. Azure Data Explorer поддерживает объединение между кластерами. Простой подсчет или подсчет строк в таблицах может помочь в проверке.
  • Процедуры выпуска должны содержать проверки и распределения системы управления, обеспечивающие зеркальное отображение кластеров.
  • Узнайте обо всех ресурсах, требуемых для создания кластера с нуля.
  • Создайте контрольный список единиц развертывания. Хотя составленный список будет соответствовать вашим потребностям, он должен обязательно включать в себя: сценарии развертывания, подключения для приема, средства BI и другие важные конфигурации.

Следующий шаг

Создание решений для обеспечения непрерывности бизнес-процессов и аварийного восстановления