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

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

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

В этой статье описаны основные понятия и рекомендации по успешному аварийному восстановлению решения для платформы Databricks.

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

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

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

• Большинство служб плоскости управления выполняются в кластерах Kubernetes и будут обрабатывать потери виртуальных машин в определенном AZ автоматически.
• Данные рабочей области хранятся в базах данных с хранилищем класса Premium, реплицируемым по всему региону. Хранилище базы данных (один сервер) не реплицируется в разных AZ или регионах. Если сбой зоны влияет на хранилище базы данных, база данных восстанавливается путем создания нового экземпляра из резервной копии.
• Учетные записи хранения, используемые для обслуживания образов DBR, также являются избыточными внутри региона, а все регионы имеют вторичные учетные записи хранения, которые используются при отключении основного. Ознакомьтесь с регионами Azure Databricks.
• Как правило, функции плоскости управления должны быть восстановлены в течение около 15 минут после восстановления зоны доступности.

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

• Доступность рабочей области зависит от доступности плоскости управления (как описано выше).
• Данные о корневом каталоге DBFS не влияют, если учетная запись хранения для корня DBFS настроена с помощью ZRS или GZRS (по умолчанию — GRS).
• Узлы для кластеров извлекаются из разных зон доступности, запрашивая узлы от поставщика вычислений Azure (если требуется достаточная емкость в оставшихся зонах для выполнения запроса). Если узел потерян, диспетчер кластеров запрашивает узлы замены от поставщика вычислений Azure, который извлекает их из доступных AZ. Единственным исключением является то, что узел драйвера потерян. В этом случае задание или диспетчер кластеров перезапускает их.

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

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

Перед реализацией плана аварийного восстановления важно понимать разницу между аварийным восстановлением (DR) и высоким уровнем доступности (HA).

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

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

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

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

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

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

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

• Геоизбыточное хранилище: Azure имеет геоизбыточное хранилище в разных регионах для сохраняемого хранилища с помощью асинхронного процесса репликации хранилища.

  Внимание

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

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

В этой статье используются приведенные ниже определения состояния развертывания.

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

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

  Внимание

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

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

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

Существует два важных широко распространенных термина, которые ваша команда должна хорошо понимать:

• Целевая точка восстановления(RPO) — это максимальный целевой период, в течение которого данные (транзакции) в ИТ-службе могут теряться по причине серьезного происшествия. В развертывании Azure Databricks основные данные клиента не хранятся. Это хранится в отдельных системах, таких как ADLS 2-го поколения (для рабочих областей, созданных до 6 марта 2023 г., Хранилище BLOB-объектов Azure) или других источников данных под вашим контролем. Некоторые объекты, например задания и записные книжки, частично или полностью хранятся на уровне управления Azure Databricks. Для Azure Databricks значение RPO определяется как максимальный целевой период, в течение которого могут теряться такие объекты, как задания и записные книжки. Кроме того, вы несете ответственность за определение RPO для собственных данных клиента в ADLS 2-го поколения (для рабочих областей, созданных до 6 марта 2023 г., Хранилище BLOB-объектов Azure) или других источников данных под вашим контролем.

• Целевое время восстановления(RTO) — это целевой период (и уровень обслуживания), в течение которого бизнес-процесс должен быть восстановлен после аварии.

  

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

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

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

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

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

2. Вы изучаете ситуацию вместе с поставщиком облачных услуг.

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

4. Убедитесь, что та же проблема не затрагивает дополнительный регион.

5. Выполните отработку отказа в дополнительный регион.

   1. Остановите всю работу в рабочей области. Пользователи останавливают рабочие нагрузки. Пользователям или администраторам предлагается создать резервную копию последних изменений, если это возможно. Задания завершаются, если это еще не произошло из-за сбоя.
   2. Запустите процедуру восстановления в дополнительном регионе. Процедура восстановления изменит маршруты, имена подключений и параметры сетевого трафика для работы в дополнительном регионе.
   3. После тестирования объявите о переводе операций в дополнительный регион. Теперь выполнение рабочих нагрузок можно возобновить. Пользователи могут входить в активное развертывание. Вы можете активировать запланированные или отложенные задания.

   Подробные инструкции в контексте Azure Databricks см. в разделе "Тестовая отработка отказа".

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

7. Выполните восстановление после сбоя в основном регионе.

   1. Остановите все операции в дополнительном регионе.
   2. Запустите процедуру восстановления в основном регионе. Процедура восстановления изменит маршруты, имена подключений и параметры сетевого трафика для возврата в основной регион.
   3. При необходимости выполните репликацию данных обратно в основной регион. Чтобы снизить сложность этой процедуры, можно минимизировать объем данных, которые требуется реплицировать. Например, если при выполнении в дополнительном развертывании некоторые задания доступны только для чтения, то, возможно, вам не потребуется реплицировать эти данные обратно в основное развертывание в основном регионе. Однако у вас может быть одно рабочее задание, которое необходимо запустить, и для этого может потребоваться выполнить репликацию данных в основной регион.
   4. Протестируйте развертывание в основном регионе.
   5. Объявите о работоспособности основного региона и о переводе туда активного развертывания. Возобновите выполнение рабочих нагрузок.

   Дополнительные сведения о восстановлении в основном регионе см. в разделе Тестовое восстановление (восстановление размещения).

Внимание

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

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

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

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

Составьте схему всех точек интеграции Azure Databricks, влияющих на ваш бизнес:

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

Определите средства или стратегии распространения информации для своего плана аварийного восстановления:

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

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

Решение должно реплицировать правильные данные в плоскости управления, плоскости вычислений и источниках данных. Избыточные рабочие области для аварийного восстановления должны быть связаны с различными уровнями управления в разных регионах. Необходимо периодически синхронизировать эти данные с помощью решения на основе скриптов: средства синхронизации или рабочего процесса CI/CD. Не требуется синхронизировать данные из самой сети вычислительной плоскости, например из рабочих ролей Databricks Runtime.

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

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

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

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

1. Узнайте, какие процессы являются критически важными для вашей компании и должны выполняться при аварийном восстановлении.

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

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

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

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

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

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

Выбор стратегии решения для восстановления

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

Стратегия решения "активный — пассивный"

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

Существует два основных варианта этой стратегии:

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

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

Стратегия "активный — активный"

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

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

Как и в случае со стратегией "активный — пассивный", ее можно реализовать как единое общекорпоративное решение или распределить по отделам.

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

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

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

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

На схеме ниже представлены различия этих двух подходов.

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

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

Description	Как работать с инструментами CI/CD	Как работать со средством синхронизации
Исходный код: экспортированный исходный код записных книжек и исходный код упакованных библиотек	Проведите совместное развертывание в основном и дополнительном развертываниях.	Синхронизируйте исходный код из основного в дополнительное развертывание.
Пользователи и группы	Управляйте метаданными в качестве конфигурации в Git. Кроме того, для обеих рабочих областей можно использовать один поставщик удостоверений (IdP). Проведите совместное развертывание данных пользователей и групп в основном и дополнительном развертываниях.	Используйте SCIM или другие средства автоматизации для обоих регионов. Создавать эти объекты вручную не рекомендуется, но при необходимости они должны создаваться одновременно в обоих развертываниях. Если вы выполняете установку вручную, создайте запланированный автоматизированный процесс для сравнения списка пользователей и групп между двумя развертываниями.
Конфигурации пула	Можно использовать шаблоны в Git. Проведите совместное развертывание в основном и дополнительном развертываниях. При этом значение min_idle_instances в дополнительном развертывании должно быть равно нулю до возникновения события аварийного восстановления.	Пулы, создаваемые с любым значением min_idle_instances, при синхронизации с дополнительным развертыванием с помощью API или интерфейса командной строки.
Job configurations (Конфигурация заданий)	Можно использовать шаблоны в Git. Для основного развертывания разверните определение задания в исходном виде. Для дополнительного развертывания разверните задание и установите для параметра параллельных запусков значение 0. В результате задание в этом развертывании будет отключено, а дополнительные запуски — запрещены. Измените значение параллельных запусков после того, как дополнительное развертывание станет активным.	Если задания по какой-либо причине выполняются в существующих кластерах <interactive>, клиент синхронизации должен быть сопоставлен с соответствующим идентификатором cluster_id в дополнительной рабочей области.
Списки управления доступом (ACL)	Можно использовать шаблоны в Git. Проведите совместное развертывание записных книжек, папок и кластеров в основном и дополнительном развертываниях. При этом не развертывайте данные заданий до возникновения события аварийного восстановления.	API разрешений может задать элементы управления доступом для кластеров, заданий, пулов, записных книжек и папок. Клиент синхронизации должен сопоставить идентификаторы объектов для каждого объекта в дополнительной рабочей области. Databricks рекомендует сопоставить идентификаторы объектов из основной в дополнительную рабочую область и синхронизировать эти объекты перед репликацией механизмов управления доступом.
Библиотеки	Включите их в исходный код и шаблоны кластеров и заданий.	Синхронизируйте пользовательские библиотеки из централизованных репозиториев, DBFS или облачного хранилища (его можно подключить).
Скрипты инициализации кластера	При необходимости включите их в исходный код.	Чтобы упростить синхронизацию, по возможности храните скрипты инициализации в основной рабочей области в общей папке или в небольшом количестве папок.
Точки подключения	Включите их в исходный код, если для создания использовались только задания на основе записных книжек или Command API.	Используйте задания, которые могут выполняться как действия Фабрики данных Azure (ADF). Обратите внимание, что конечные точки хранилища могут меняться, так как рабочие области будут находиться в разных регионах. Свою роль также играет стратегия аварийного восстановления данных.
Метаданные таблицы	Включите их в исходный код, если для создания использовались только задания на основе записных книжек или Command API. Это относится как к внутреннему хранилищу метаданных Azure Databricks, так и к настроенному внешнему хранилищу метаданных.	Сравните определения метаданных между хранилищами с использованием Spark Catalog API или метода "Отображение создания таблицы" с помощью записной книжки или скриптов. Обратите внимание, что таблицы базового хранилища могут быть связаны с различными регионами и быть разными в разных экземплярах хранилища метаданных.
Секреты	Включите их в исходный код, если для создания использовался только Command API. Обратите внимание, что некоторые секреты в основной и дополнительной рабочей области могут быть разными.	Секреты создаются в обеих рабочих областях через API. Обратите внимание, что некоторые секреты в основной и дополнительной рабочей области могут быть разными.
Конфигурации кластера	Можно использовать шаблоны в Git. Выполните совместное развертывание в основном и дополнительном развертываниях, однако работа кластеров в дополнительном развертывании должна быть завершена до возникновения события аварийного восстановления.	Кластеры создаются после их синхронизации с дополнительной рабочей областью с помощью API или интерфейса командной строки. При необходимости их можно завершить явным образом в зависимости от настроек автоматического завершения.
Разрешения для записных книжек, заданий и папок	Можно использовать шаблоны в Git. Проведите совместное развертывание в основном и дополнительном развертываниях.	Репликация с помощью API разрешений.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Внимание

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

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

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

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

Спланируйте и протестируйте изменения в средствах настройки.

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

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

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

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

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

1. Запустите проверки, чтобы убедиться, что платформа обновлена.
2. Отключите пулы и кластеры в основном регионе, чтобы в случае восстановления службы, завершившей работу сбоем, основной регион не начал обработку новых данных.
3. Процесс восстановления:
   1. Проверьте дату последней синхронизации данных. См. терминологию аварийного восстановления. Конкретные особенности этого шага зависят от того, как вы синхронизируете данные и каковы ваши уникальные бизнес-потребности.
   2. Стабилизируйте свои источники данных и обеспечьте их доступность. Включите все внешние источники данных, такие как Azure Cloud SQL, а также Delta Lake, Parquet и другие файлы.
   3. Найдите точку восстановления потоковой передачи. Подготовьте процедуру перезапуска с этой точки и разработайте процесс, позволяющий выявлять и устранять дубликаты (Delta Lake упрощает эту задачу).
   4. Завершите процесс потока данных и проинформируйте своих пользователей.
4. Запустите соответствующие пулы (или увеличьте значение min_idle_instances до соответствующего уровня).
5. Запустите соответствующие кластеры (если они не завершены).
6. Измените число параллельных запусков для заданий и запустите соответствующие задания. Это могут быть однократные или периодические запуски.
7. Для внешних средств, использующих URL-адрес или доменное имя рабочей области Azure Databricks, обновите конфигурации с учетом нового уровня управления. Например, обновите URL-адреса для REST API и подключений JDBC/ODBC. URL-адрес интерфейсного веб-приложения Azure Databricks меняется при изменении уровня управления, поэтому передайте этот новый адрес пользователям своей организации.

Тестирование восстановление (восстановление размещения)

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

1. Получите подтверждение восстановления основного региона.
2. Отключите пулы и кластеры в дополнительном регионе, чтобы он не начал обработку новых данных.
3. Синхронизируйте новые или измененные ресурсы в дополнительной рабочей области обратно в основное развертывание. В зависимости от структуры скриптов отработки отказа одни и те же скрипты можно выполнять для синхронизации объектов из дополнительного региона (региона аварийного восстановления) с основным (рабочим) регионом.
4. Синхронизируйте новые изменения данных с основным развертыванием. Чтобы гарантировать отсутствие потери данных, можно использовать журналы аудита журналов и разностных таблиц.
5. Завершите работу всех рабочих нагрузок в регионе аварийного восстановления.
6. Измените URL-адреса заданий и пользователей на основной регион.
7. Запустите проверки, чтобы убедиться, что платформа обновлена.
8. Запустите соответствующие пулы (или увеличьте значение min_idle_instances до соответствующего уровня).
9. Запустите соответствующие кластеры (если они не завершены).
10. Измените число параллельных запусков для заданий и запустите соответствующие задания. Это могут быть однократные или периодические запуски.
11. При необходимости настройте дополнительный регион для последующего аварийного восстановления.

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

Скрипты автоматизации, которые можно использовать в проектах аварийного восстановления:

• Для создания собственного процесса синхронизации Databricks рекомендует использовать поставщик Databricks Terraformа.
• Примеры и прототипы скриптов также см. в разделе Средства миграции рабочей области Databricks. Помимо объектов Azure Databricks, реплицируйте все соответствующие конвейеры Фабрики данных Azure, чтобы они ссылались на связанную службу, сопоставленную с дополнительной рабочей областью.
• Проект Databricks Sync (DBSync) — это средство синхронизации объектов, которое выполняет резервное копирование, восстановление и синхронизацию рабочих областей Databricks.