Аварийное восстановление

Аварийное восстановление (DR) в Azure Databricks реплицирует рабочие области, данные и конфигурации между облачными регионами, чтобы ваши команды могли продолжать работу, когда сбой в регионе выводит из строя основное развертывание. Полный план аварийного восстановления охватывает не только Azure Databricks, но и источники данных, инструменты загрузки данных, BI-инструменты и планировщики, с которыми он взаимодействует.

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

Впервые занимаетесь планированием аварийного восстановления? Начните с терминологии отрасли аварийного восстановления для определений RPO и RTO.

Внимание

Используйте управляемое аварийное восстановление. Azure Databricks рекомендует управляемое аварийное восстановление для аварийного восстановления между регионами в AWS и Azure. Решение реплицирует метаданные Unity Catalog, данные управляемых таблиц и ресурсы рабочей области по непрерывному расписанию, предоставляет стабильный URL-адрес, который сохраняется после переключения при отказе, и позволяет инициировать переключение при отказе из консоли учетной записи. Не нужно писать или поддерживать скрипты репликации. Используйте инструкции по самостоятельной настройке на этой странице только для ресурсов, которые не реплицируются с помощью Managed DR, либо если вам требуются топологии active-active, межоблачная репликация или детальный контроль над процессом репликации.

Гарантии высокой доступности внутри региона

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

Высокий уровень доступности и аварийное восстановление решают различные проблемы:

HA использует избыточность в зоне доступности (AZ) в пределах региона. Если одна зона выходит из строя, сервисы продолжают работать в других зонах.
DR использует межрегиональную репликацию. Вы запускаете вторичные рабочие пространства Azure Databricks в другом регионе и реплицируете в них данные и конфигурации, а затем переключаетесь на них в случае сбоя в регионе.

Если вам не требуется многорегиональное аварийное восстановление, высокой доступности Azure Databricks может быть достаточно. Высокий уровень доступности избегает сложности между регионами, но не защищает от сбоя в полном регионе. Если вы полагаетесь только на HA (высокую доступность) для DR (аварийного восстановления), проверьте изолированность и резервирование вашего облачного региона.

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

Доступность плоскости управления Azure Databricks

Плоскость управления Azure Databricks устойчива к сбоям зоны и автоматически восстанавливается в течение примерно 15 минут после сбоя зоны. Это подтверждается регулярным тестированием на отказ зоны.

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

Note

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

Некоторые регионы Azure используют плоскость управления, развернутую в парном им регионе. Ознакомьтесь с регионами Azure Databricks.

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

Доступность плоскости вычислений

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

Корневые данные DBFS не подвержены влиянию, если учетная запись хранилища настроена на использование хранилища с избыточностью между зонами (ZRS) или геозонально-избыточного хранилища (GZRS). По умолчанию используется геоизбыточное хранилище (GRS).

Узлы кластера выводятся из разных зон доступности путём запроса узлов у поставщика вычислительных ресурсов Azure при наличии достаточной ёмкости в остальных зонах. Если узел потерян, диспетчер кластеров запрашивает узлы замены от поставщика вычислений Azure, который извлекает их из доступных AZ. Исключение составляет случай, когда узел-драйвер теряется. В этом случае диспетчер кластера перезапускает задание и кластер.

Чтобы проверить наличие поддержки нескольких зон доступности, см. список регионов Azure. Для обеспечения устойчивости вычислительной плоскости с несколькими зонами доступности (AZ) используйте зонально-избыточное хранилище.

Терминология

Используйте эти определения единообразно при обсуждении DR в команде.

Терминология региона

Терминология регионов

На этой странице используются следующие определения регионов:

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

Геоизбыточное хранилище между регионами (Azure).

Внимание

Не полагайтесь на геоизбыточное хранилище для дублирования корневого хранилища Azure Databricks (например, ADLS, а для рабочих областей, созданных до 6 марта 2023 г., — Хранилище BLOB-объектов Azure, которое Azure Databricks создает для каждой рабочей области) между регионами. Для репликации данных управляемых таблиц используйте Delta Deep Clone, а для данных не в формате Delta сначала по возможности преобразуйте их в формат Delta.

Терминология состояния развертывания

На этой странице используются следующие определения состояния развертывания:

Активное развертывание (иногда называется горячим развертыванием): пользователи подключаются к нему и выполняют рабочие нагрузки. Задания и потоки данных выполняются здесь по расписанию.
Пассивное развертывание (иногда называется холодным развертыванием): процессы не выполняются здесь. ИТ-команды поддерживают его в готовом состоянии, автоматизируя развертывание кода, конфигурации и других объектов Azure Databricks. Пассивное развертывание становится активным только если активное развертывание выходит из строя.

Внимание

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

Большинство команд используют только одно активное развертывание за раз — стратегию активно-пассивного развертывания. Менее распространённая стратегия активная-активная предполагает два одновременных активных развертывания.

Терминология отрасли аварийного восстановления

Терминология аварийного восстановления

Определите эти два отраслевых термина в команде:

Целевой показатель точки восстановления (RPO): максимальный период потери данных, который ваш сервис может допустить во время крупного инцидента. См. RPO.

Azure Databricks не хранит данные основного клиента. Они хранятся в ADLS (для рабочих областей, созданных до 6 марта 2023 г., — в Хранилище BLOB-объектов Azure) или в других системах, которыми вы управляете. Плоскость управления Azure Databricks сохраняет некоторые объекты (например, задания и записные книжки), поэтому Azure Databricks RPO — это максимальный период, в течение которого изменения этих объектов могут быть потеряны. Вы несете ответственность за определение RPO для данных клиента в ADLS (для рабочих областей, созданных до 6 марта 2023 г., Хранилище BLOB-объектов Azure) и других источников данных, которые вы управляете.
Цель времени восстановления (RTO) — максимальное время, в течение которого бизнес-процесс должен быть восстановлен после аварии. См. RTO.

Аварийное восстановление и повреждение данных

Решение аварийного восстановления не устраняет повреждение данных. Поврежденные данные в первичном регионе реплицируются во вторичный регион, в результате чего данные оказываются повреждены в обоих регионах. Чтобы снизить риск такого сбоя, используйте Delta time travel, аналогичные инструменты или средства резервного копирования данных.

Типичный процесс восстановления

Сценарий аварийного восстановления Azure Databricks обычно выполняется следующим образом:

Сбой затрагивает критически важную службу в вашем основном регионе: источник данных, сеть или другую зависимость, от которой зависит развертывание Azure Databricks.
Вы проводите расследование вместе с вашим облачным провайдером.
Если ожидание неприемлемо, вы решаете переключиться на вторичный регион.
Убедитесь, что эта же проблема не затрагивает ваш вторичный регион.
Переключение при отказе (подробные инструкции см. в разделе Тестирование переключения при отказе):
1. Остановить всю активность в рабочей области. Пользователи останавливают рабочие нагрузки и по возможности создают резервные копии последних изменений. Задания завершаются (если сбой еще не завершился).
2. Выполните процедуру восстановления дополнительного региона для обновления маршрутизации и перенаправления подключений и сетевого трафика.
3. Перенастройте зависимые системы (средства бизнес-аналитики, планировщики, сторонние интеграции) на вторичное рабочее пространство и возобновите их подключения.
4. После тестирования объявите вторичный регион работоспособным. Пользователи входят в текущее активное развертывание, а вы повторно запускаете запланированные или отложенные задания.
После устранения проблемы с основным регионом подтвердите исправление.
Обратное переключение (подробные сведения см. в разделе Тестовое восстановление (обратное переключение)):
1. Остановите всю работу во вторичном регионе.
2. Выполните процедуру восстановления основного региона, чтобы перенаправить маршрутизацию обратно.
3. Реплицируйте все новые данные обратно в основной регион. Свести к минимуму то, что необходимо реплицировать. Например, задания в режиме только чтения, выполнявшиеся во вторичном развертывании, могут не требовать записи обратно.
4. Протестируйте развертывание в основном регионе.
5. Объявите основной регион активным и возобновите продукционные нагрузки.

Внимание

Некоторые потери данных могут возникать во время этих действий. Определите, сколько потерь приемлемо для вашей организации, и как ее уменьшить.

Шаг 1. Понимание бизнес-потребностей

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

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

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

Точки интеграции для сопоставления

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

Средства и обмен данными для планирования

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

Шаг 2. Выбор процесса, соответствующего бизнес-потребностям

По умолчанию используется управляемое аварийное восстановление. Обеспечивает репликацию рабочей области, метаданные Unity Catalog, данные управляемых таблиц и оркестрацию аварийного переключения без использования пользовательских скриптов. Используйте приведенное ниже DIY-руководство только в том случае, если ваш сценарий выходит за рамки его области применения, например если вам нужно реплицировать ресурсы, которые Managed DR не поддерживает, использовать топологии active-active, выполнять межоблачную репликацию или иметь детальный контроль над конвейером репликации.

Самостоятельное решение должно обеспечивать репликацию корректных данных между плоскостью управления, вычислительной плоскостью и источниками данных. Резервные рабочие области относятся к разным плоскостям управления в разных регионах, поэтому вы поддерживаете их синхронизацию с помощью решения на основе сценариев, например инструмента синхронизации или конвейера CI/CD. Для самих данных большинство команд используют задания Azure Databricks (часто запланированные) или Delta Deep Clone для копирования таблиц между регионами. Вам не нужно синхронизировать данные изнутри плоскости вычислений (например, с рабочих узлов Databricks Runtime).

Если вы используете функцию внедрения виртуальной сети (недоступно для всех типов подписок и развертываний), последовательно развертывайте сети в обоих регионах с помощью инструментов на основе шаблонов, таких как Terraform.

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

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

Общие рекомендации

Рекомендации по успешной разработке плана аварийного восстановления включают следующее:

Определите, какие процессы критически важны для бизнеса и должны продолжать работать в среде аварийного восстановления.
Четко определите, какие службы участвуют, какие данные обрабатываются, что такое поток данных и где он хранится.
Изолируйте службы и данные, насколько это возможно. Например, создайте специальный контейнер облачного хранилища для данных аварийного восстановления или переместите объекты Azure Databricks, необходимые во время аварии в отдельную рабочую область.
Вы несете ответственность за обеспечение целостности между основными и вторичными развертываниями для объектов, не хранящихся в плоскости управления Azure Databricks.
Для источников данных по возможности используйте встроенные средства Azure для репликации данных в ваши регионы аварийного восстановления (DR).

Предупреждение

Не сохраняйте данные в корневых ADLS (для рабочих областей, созданных до 6 марта 2023 г., Хранилище BLOB-объектов Azure), используемых для корневого доступа DBFS. Корневое хранилище DBFS не поддерживается для рабочих данных клиента. Azure Databricks также не рекомендует хранить там библиотеки, файлы конфигурации или скрипты инициализации.

Стратегия активного пассивного решения

Стратегия активного-пассивного решения

В этом разделе основное внимание уделяется активно-пассивной стратегии, так как это наиболее распространенная, простейшая и наиболее эффективная. Активно-пассивное решение синхронизирует данные и изменения объектов из активного развертывания с пассивным развертыванием во вторичном регионе. При аварийном переключении пассивное развертывание становится активным.

Два распространенных варианта:

Унифицированный (корпоративный): один набор активных и пассивных развертываний поддерживает всю организацию.
По подразделению или проекту: каждый домен поддерживает собственное решение для аварийного восстановления со своими основным и резервным регионами, адаптированными к его потребностям.

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

Стратегия решения «активный-активный»

Стратегия «активный-активный»

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

Активный-активный режим является самой сложной стратегией и обходится дороже, поскольку задания выполняются в обоих регионах, но он обеспечивает самые низкие показатели RTO и RPO.

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

Выбор инструментов

Существует два основных подхода к синхронизации данных между рабочими областями в основных и вторичных регионах:

Клиент синхронизации, который копирует данные из основного региона в дополнительный: клиент синхронизации отправляет рабочие данные и ресурсы из основного региона в дополнительный. Как правило, это выполняется по расписанию, а частота выполнения зависит от целевых значений RTO и RPO.
Инструменты CI/CD для параллельного развертывания: для рабочего кода и ресурсов используйте средства CI/CD, которые отправляют изменения в рабочие системы одновременно в оба региона. Например, при отправке кода и ресурсов из промежуточной среды/среды разработки в рабочую среду система CI/CD делает их доступными в обоих регионах одновременно. Основная идея состоит в том, чтобы рассматривать все артефакты в рабочей области Azure Databricks как инфраструктуру как код. Большинство артефактов можно развернуть одновременно как в основных, так и во вторичных рабочих областях, тогда как некоторые артефакты следует развертывать только после аварии, требующей восстановления. Описание инструментов и средств см. в разделе Скрипты автоматизации, примеры и прототипы.

В зависимости от потребностей можно объединить подходы. Например, используйте CI/CD для исходного кода записной книжки, но используйте синхронизацию для конфигурации, таких как пулы и элементы управления доступом.

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

Описание	Как работать с инструментами CI/CD	Как работать со средством синхронизации
Исходный код: экспортированный исходный код записных книжек и исходный код упакованных библиотек	Проведите совместное развертывание в основном и дополнительном развертываниях.	Синхронизируйте исходный код с основного на вторичный.
Пользователи и группы	Управляйте метаданными как конфигурацией в Git. В качестве альтернативы для обеих рабочих областей можно использовать одного поставщика удостоверений (IdP). Совместно разверните данные пользователей и групп на основных и дополнительных платформах.	Используйте SCIM или другие средства автоматизации для обоих регионов. Создавать вручную не рекомендуется, но если необходимо, это должно быть сделано одновременно для обоих. При использовании ручной настройки создайте запланированный автоматизированный процесс для сравнения списка пользователей и групп между двумя развертываниями.
Конфигурации пула	Можно использовать шаблоны в Git. Проведите совместное развертывание в основном и дополнительном развертываниях. Однако `min_idle_instances` во вторичном экземпляре должен быть равен нулю до события аварийного переключения.	Пулы, созданные с любым `min_idle_instances`, синхронизированные с вторичной рабочей областью через API или CLI.
Job configurations (Конфигурация заданий)	Используйте Databricks Asset Bundles с отдельными целями для каждой среды (например, `prod` и `dr`), чтобы развернуть одно и то же определение задания в обоих регионах. Для вторичного развертывания установите уровень параллелизма равным нулю, чтобы задание было подготовлено, но не запускалось. Измените значение конкуренции после того, как дополнительное развертывание станет активным.	Если задания по какой-либо причине выполняются в существующих кластерах `<interactive>`, клиент синхронизации должен сопоставить с соответствующим `cluster_id` во вторичной рабочей области.
Списки управления доступом (ACL)	Можно использовать шаблоны в Git. Проведите совместное развертывание записных книжек, папок и кластеров в основном и дополнительном развертываниях. Однако сохраняйте данные по заданиям до наступления события аварийного восстановления.	API разрешений может задать элементы управления доступом для кластеров, заданий, пулов, записных книжек и папок. Клиент синхронизации должен сопоставить идентификаторы объектов для каждого объекта во вторичной рабочей области. Databricks рекомендует создать карту идентификаторов объектов из основной в дополнительную рабочую область и синхронизировать эти объекты перед репликацией управления доступом.
Библиотеки	Включите их в исходный код и шаблоны кластеров и заданий.	Синхронизируйте пользовательские библиотеки из централизованных репозиториев, DBFS или облачного хранилища (его можно подключить).
Скрипты инициализации кластера	Включите в исходный код, если вы предпочитаете.	Чтобы упростить синхронизацию, по возможности храните скрипты инициализации в основной рабочей области в общей папке или в небольшом количестве папок.
Точки подключения	Включите их в исходный код, если для создания использовались только задания на основе записных книжек или Command API.	Используйте задания, которые могут выполняться как действия Фабрики данных Azure (ADF). Обратите внимание, что конечные точки хранилища могут меняться, так как рабочие области будут находиться в разных регионах. Это также во многом зависит от вашей стратегии аварийного восстановления данных.
Метаданные таблицы	Для объектов Unity Catalog (каталогов, схем, таблиц, томов и разрешений) выполняйте совместное развертывание с поставщиком Databricks Terraform или Databricks Asset Bundles. Для устаревших таблиц хранилища метаданных Hive включите инструкции create-table с исходным кодом при создании заданий на основе записных книжек или API команд.	Для объектов каталога Unity считывайте исходные метаданные из системных таблиц или `information_schema` реплицируйте их в вторичную рабочую область с помощью пакета SDK Databricks. Для устаревших таблиц хранилища метаданных Hive сравнивайте определения метаданных между хранилищами метаданных с помощью API каталога Spark или `SHOW CREATE TABLE` записной книжки или скриптов. Базовые пути к хранилищу могут быть основаны на регионах и могут отличаться между экземплярами хранилища метаданных.
Секреты	Включите их в исходный код, если для создания использовался только Command API. Обратите внимание, что содержание некоторых секретов может потребовать изменений между основной и второстепенной частью.	Секреты создаются в обеих рабочих областях через API. Обратите внимание, что содержание некоторых секретов может потребовать изменений между основной и второстепенной частью.
Конфигурации кластера	Можно использовать шаблоны в Git. Выполняйте совместное развертывание в основном и резервном развертываниях, хотя развертывания в резервном контуре должны оставаться остановленными до наступления события аварийного восстановления (DR).	Кластеры создаются после их синхронизации с дополнительной рабочей областью с помощью API или интерфейса командной строки. При необходимости их можно завершить явным образом в зависимости от настроек автоматического завершения.
Разрешения для записных книжек, заданий и папок	Можно использовать шаблоны в Git. Проведите одновременное развертывание в основном и дополнительном развертываниях.	Создайте копию с помощью API разрешений.

Выбор регионов и нескольких дополнительных рабочих областей

Выберите регионы и несколько второстепенных рабочих областей.

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

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

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

Шаг 3. Подготовка рабочих пространств и одноразовое копирование

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

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

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

Репликация данных: используйте решение для репликации облака или Delta Deep Clone.
Создание маркеров: автоматизация репликации и будущих рабочих нагрузок с созданными маркерами.
Репликация рабочей области: Выполните репликацию с помощью методов, описанных в шаге 4: Подготовка источников данных. Подробные рекомендации по экспорту ресурсов рабочей области, данных и машинного обучения см. в статье "Экспорт данных рабочей области".
Проверка рабочей области: проверьте рабочую область и процесс, чтобы убедиться, что они успешно выполняются и создают ожидаемые результаты.

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

Шаг 4. Подготовка источников данных

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

Пакетная обработка из источников данных

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

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

Потоки данных

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

Очередь сообщений, например Kafka
Поток отслеживания изменений данных базы данных
Файловая непрерывная обработка
Файловая обработка по расписанию, также известная как однократный триггер

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

Модуль записи потока хранит контрольную точку со сведениями об обработанных данных. Эта контрольная точка может содержать расположение данных (обычно это облачное хранилище), которое требуется изменить, чтобы обеспечить успешный перезапуск потока. Например, подпапка source в папке контрольной точки может содержать файловую облачную папку.

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

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

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

Шаг 5. Реализация и тестирование решения

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

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

Внимание

Регулярно тестируйте решение для аварийного восстановления в реальных условиях.

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

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

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

Планируйте и тестируйте изменения в ваших инструментах управления конфигурацией.

Изменения конфигурации для планирования и тестирования

Для каждого из следующих пунктов подготовьте план аварийного переключения и проверьте все предположения:

Приём данных: Определите, где находятся ваши источники данных и откуда эти источники получают данные. По возможности параметризируйте источник и используйте отдельный шаблон конфигурации для дополнительного развертывания и региона.
Изменения в выполнении. Если у вас есть планировщик для запуска заданий или других действий, может потребоваться отдельный планировщик, который работает с дополнительным развертыванием или его источниками данных.
Интерактивное подключение. Рассмотрим, как конфигурация, проверка подлинности и сетевые подключения могут повлиять на региональные нарушения для любого использования REST API, средств CLI или других служб, таких как JDBC/ODBC.
Изменения в службе автоматизации: для всех средств автоматизации.
Выходные данные: для любых средств, создающих выходные данные или журналы.
Последующие изменения: для инструментов BI, панелей мониторинга, планировщиков и сторонних интеграций, которые читают данные из Azure Databricks или записывают данные в Azure Databricks, спланируйте, как перенаправить их на вторичное рабочее пространство, и уведомите их владельцев.

Тестовая отработка отказа

Тестируйте отработку отказа

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

Чтобы проверить переключение при отказе, подключитесь к системе и выполните завершение работы. Убедитесь, что все задачи завершены, а кластеры остановлены.

Клиент синхронизации (или средства CI/CD) реплицирует соответствующие объекты и ресурсы Azure Databricks в вторичную рабочую область. Чтобы активировать вторичную рабочую область, процесс может включать некоторые или все из следующих элементов:

Запустите проверки, чтобы убедиться, что платформа обновлена.
Отключите пулы и кластеры в основном регионе, чтобы, если восстановится работа службы после сбоя, основной регион не начал обработку новых данных.
Запустите процесс восстановления для источников данных (см. ниже).
Запустите соответствующие пулы (или увеличьте min_idle_instances до соответствующей цифры).
Запустите соответствующие кластеры (если они не завершены).
Измените режим параллельного выполнения заданий и запустите необходимые задания. Это могут быть однократные или периодические запуски.
Для внешних средств, использующих URL-адрес или доменное имя рабочей области Azure Databricks, обновите конфигурации с учетом нового уровня управления. Например, обновите URL-адреса для REST API и подключений JDBC/ODBC. URL-адрес веб-приложения Azure Databricks для клиента изменяется при изменении уровня управления, поэтому уведомляйте пользователей вашей организации о новом URL-адресе.

Сведения о процессе восстановления

Проверьте дату последней синхронизации данных. См. терминологию отрасли аварийного восстановления. Сведения об этом шаге зависят от способа синхронизации данных и уникальных бизнес-потребностей.
Стабилизируйте свои источники данных и обеспечьте их доступность. Включите все внешние источники данных, такие как Azure Cloud SQL, и Delta Lake, Parquet или другие файлы.
Найдите точку восстановления потокового вещания. Настройте процесс, чтобы перезапустить его и подготовить процесс для выявления и устранения потенциальных дубликатов (Delta Lake упрощает этот процесс).
Завершите процесс потока данных и проинформируйте своих пользователей.

Тестирование восстановления (обратное переключение)

Тестирование восстановления (откат)

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

Получите подтверждение, что основной регион восстановлен.
Отключите пулы и кластеры в дополнительном регионе, чтобы не начать обработку новых данных.
Синхронизируйте новые или измененные ресурсы в дополнительной рабочей области обратно в основное развертывание. В зависимости от реализации ваших скриптов аварийного переключения, возможно, вы сможете запускать те же скрипты для синхронизации объектов из вторичного региона (аварийное восстановление, DR) в основной регион (продуктивная среда).
Синхронизируйте новые изменения данных с основным развертыванием. Чтобы гарантировать отсутствие потери данных, можно использовать аудиторские следы журналов и Delta таблиц.
Остановите все нагрузки в регионе DR.
Измените URL-адрес заданий и пользователей на основной регион и переназначите подчиненные подключения (средства бизнес-аналитики, планировщики, сторонние интеграции) к нему.
Запустите проверки, чтобы убедиться, что платформа обновлена.
Запустите соответствующие пулы (или увеличьте min_idle_instances до соответствующей цифры).
Запустите соответствующие кластеры (если они не завершены).
Измените параллельные запуски заданий и выполняйте соответствующие задания. Это могут быть однократные или периодические запуски.
При необходимости повторно настройте вторичный регион для будущих сценариев аварийного восстановления.

Скрипты автоматизации, примеры и прототипы

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

Для DR-конвейеров DIY используйте провайдер Terraform Databricks для управления ресурсами рабочей области как кодом и одновременного развертывания в основном и резервном регионах.

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

Дополнительные ресурсы

Обратная связь

Были ли сведения на этой странице полезными?

Last updated on 2026-06-24