Аварии могут быть сбоями оборудования, стихийными бедствиями или сбоями программного обеспечения. Процесс подготовки и восстановления после аварии называется аварийное восстановление (аварийное восстановление). В этой статье рассматриваются рекомендации по обеспечению непрерывности бизнес-процессов и аварийного восстановления (BCDR) для Фабрика данных Azure и конвейеров Azure Synapse Analytics.
Стратегии BCDR включают избыточность зоны доступности, автоматическое восстановление, предоставляемое Azure аварийное восстановление, и управляемое пользователем восстановление с помощью непрерывной интеграции и непрерывной доставки (CI/CD).
Архитектура
Скачайте файл Visio для этой архитектуры.
Рабочий процесс
Конвейеры Фабрики данных и Azure Synapse обеспечивают устойчивость с помощью регионов Azure и зон доступности Azure.
- В каждом регионе Azure есть набор центров обработки данных, развернутых в пределах определенного задержкой периметра.
- Зоны доступности Azure — это физически разделенные расположения в пределах одного региона Azure, которые устойчивы к локальным сбоям.
- Все регионы Azure и зоны доступности подключены через выделенную, региональную сеть с низкой задержкой и высокопроизводительной сетью.
- Все регионы с поддержкой зоны доступности имеют по крайней мере три отдельных зоны доступности, чтобы обеспечить устойчивость.
Когда центр обработки данных, часть центра обработки данных или зона доступности в регионе исчезает, отработка отказа происходит с нулевым временем простоя для отказоустойчивой зоны фабрики данных и конвейеров Azure Synapse.
Компоненты
Подробности сценария
Фабрика данных и конвейеры Azure Synapse хранят артефакты, содержащие следующие данные:
Метаданные
- Pipeline
- Наборы данных
- Связанные службы
- Среда выполнения интеграции
- Триггеры
Мониторинг данных
- Pipeline
- Триггеры
- Выполнение действия
Аварии могут ударяться различными способами, такими как сбои оборудования, стихийные бедствия или сбои программного обеспечения, которые возникают из-за человеческой ошибки или кибератаки. В зависимости от типов сбоев их географическое влияние может быть региональным или глобальным. При планировании стратегии аварийного восстановления рассмотрите как характер аварии, так и его географическое влияние.
BCDR в Azure работает над моделью общей ответственности. Многие службы Azure требуют, чтобы клиенты явно настраивали стратегию аварийного восстановления, а Azure предоставляет базовую инфраструктуру и службы платформы по мере необходимости.
Для достижения bcDR для фабрики данных и конвейеров Azure Synapse можно использовать следующие рекомендации в различных сценариях сбоя. Сведения о реализации см. в разделе "Развертывание этого сценария".
Автоматическое восстановление с помощью аварийного восстановления Azure
При автоматическом восстановлении azure Backup и аварийном восстановлении при полном сбое региона Azure с парным регионом, фабрикой данных или конвейерами Azure Synapse автоматически выполняется отработка отказа в парный регион при настройке автоматического восстановления. Исключения представляют собой юго-восточную Азию и регионы Бразилии, где требования к месту расположения данных требуют, чтобы данные оставались в этих регионах.
При отработке отказа аварийного восстановления фабрика данных восстанавливает рабочие конвейеры. Если вам нужно проверить восстановленные конвейеры, можно создать резервную копию шаблонов Azure Resource Manager для рабочих конвейеров в хранилище секретов и сравнить восстановленные конвейеры с резервными копиями.
Глобальная команда Azure проводит регулярные детализации BCDR, а Фабрика данных Azure и Azure Synapse Analytics участвуют в этих детализациях. Детализация BCDR имитирует сбой региона и выполняет отработку отказа служб Azure в парном регионе без участия клиента. Дополнительные сведения о детализации BCDR см. в разделе "Тестирование служб".
Избыточность, управляемая пользователем, с помощью CI/CD
Чтобы достичь BCDR в случае сбоя всего региона, вам потребуется фабрика данных или рабочая область Azure Synapse в дополнительном регионе. В случае случайной фабрики данных или удаления конвейера Azure Synapse, сбоев или внутренних событий обслуживания можно использовать Git и CI/CD для восстановления конвейеров вручную.
При необходимости можно использовать активную или пассивной реализацию. Основной регион обрабатывает обычные операции и остается активным, в то время как дополнительный регион аварийного восстановления требует предварительно запланированных шагов, в зависимости от конкретной реализации, для повышения до первичного. В этом случае все необходимые конфигурации инфраструктуры доступны в дополнительном регионе, но они не подготовлены.
Потенциальные варианты использования
Избыточность, управляемая пользователем, полезна в таких сценариях:
- Случайное удаление артефактов конвейера с помощью человеческой ошибки.
- Расширенные сбои или события обслуживания, которые не активируют BCDR, так как не сообщается об аварии.
Рабочие нагрузки можно быстро переместить в другие регионы и не затронуть.
Рекомендации
Эти рекомендации реализуют основные принципы платформы Azure Well-Architected Framework, которая является набором руководящих принципов, которые можно использовать для улучшения качества рабочей нагрузки. Дополнительные сведения см. в статье Microsoft Azure Well-Architected Framework.
Надежность
Надежность гарантирует, что ваше приложение позволит вам выполнить ваши обязательства перед клиентами. Дополнительные сведения см. в разделе "Обзор основы надежности".
Фабрики данных и конвейеры Azure Synapse являются основными службами Azure, поддерживающими зоны доступности, и они предназначены для обеспечения правильного уровня устойчивости и гибкости, а также ультра-низкой задержки.
Подход к восстановлению, управляемый пользователем, позволяет продолжать работу, если в основном регионе имеются события обслуживания, сбои или человеческие ошибки. С помощью CI/CD фабрика данных и конвейеры Azure Synapse могут интегрироваться в репозиторий Git и развернуть его в дополнительном регионе для немедленного восстановления.
Оптимизация затрат
Оптимизация затрат заключается в поиске способов уменьшения ненужных расходов и повышения эффективности работы. Дополнительные сведения см. в разделе Обзор критерия "Оптимизация затрат".
Восстановление, управляемое пользователем, интегрирует Фабрику данных с Git с помощью CI/CD и при необходимости использует дополнительный регион аварийного восстановления, имеющий все необходимые конфигурации инфраструктуры в качестве резервной копии. Этот сценарий может привести к дополнительным затратам. Чтобы оценить затраты, используйте калькулятор цен Azure.
Примеры цен на Фабрику данных и Azure Synapse Analytics см. в следующих примерах:
Эффективность работы
Оперативное превосходство охватывает процессы операций, которые развертывают приложение и продолжают работать в рабочей среде. Дополнительные сведения см. в разделе "Общие сведения о принципах эффективности работы".
С помощью подхода восстановления CI/CD, управляемого пользователем, вы можете интегрироваться в Azure Repos или GitHub. Дополнительные сведения о лучших методиках CI/CD см. в рекомендациях по CI/CD.
Развертывание этого сценария
Выполните следующие действия, чтобы настроить автоматизированное или управляемое пользователем аварийное восстановление для фабрики данных и конвейеров Azure Synapse.
Настройка автоматического восстановления
В фабрике данных можно задать регион среды выполнения интеграции Azure (IR) для выполнения действия или отправки в настройке среды выполнения интеграции. Чтобы включить автоматическую отработку отказа в случае полного регионального сбоя, задайте для региона значение Auto Resolve.
В контексте сред выполнения интеграции ir выполняется автоматический отработка отказа в парный регион при выборе автоматического разрешения в качестве региона IR. Для других регионов расположения можно создать вторичную фабрику данных в другом регионе и использовать CI/CD для подготовки фабрики данных из репозитория Git.
Для управляемых виртуальных сетей пользователям необходимо вручную переключиться на дополнительный регион.
Автоматическая отработка отказа Azure не применяется к локальной среде выполнения интеграции (SHIR), так как инфраструктура управляется клиентом. Рекомендации по настройке нескольких узлов для повышения доступности с помощью SHIR см. в статье "Создание и настройка локальной среды выполнения интеграции".
Сведения о настройке BCDR для Azure-SSIS IR см. в статье Настройка среды выполнения интеграции Azure-SSIS для обеспечения непрерывности бизнес-процессов и аварийного восстановления (BCDR).
Связанные службы не полностью включены после отработки отказа из-за ожидающих частных конечных точек в новой сети региона. Необходимо настроить частные конечные точки в восстановленном регионе. Вы можете автоматизировать создание частной конечной точки с помощью API утверждения.
Настройка управляемого пользователем восстановления с помощью CI/CD
Вы можете использовать Git и CI/CD для восстановления конвейеров вручную в случае удаления или сбоя конвейера Azure Synapse.
Сведения об использовании конвейера CI/CD фабрики данных см. в статье о непрерывной интеграции и доставке в Фабрика данных Azure и системе управления версиями в Фабрика данных Azure.
Сведения об использовании CI/CD конвейера Azure Synapse см. в статье "Непрерывная интеграция и доставка" для рабочей области Azure Synapse Analytics. Сначала инициализировать рабочую область Azure Synapse. Дополнительные сведения см. в статье Система управления версиями в Synapse Studio.
При развертывании управляемой пользователем избыточности с помощью CI/CD выполните следующие действия:
Отключение триггеров
Отключите триггеры в исходной основной фабрике данных после возвращения в сеть. Триггеры можно отключить вручную или реализовать автоматизацию для периодической проверки доступности исходного первичного элемента. Отключите все триггеры исходной фабрики данных сразу после восстановления фабрики.
Сведения об использовании Azure PowerShell для включения или отключения триггеров фабрики данных см. в разделе Примеры сценариев предварительного и после развертывания и улучшения CI/CD, связанных с развертыванием триггеров конвейера.
Обработка повторяющихся операций записи
Большинство конвейеров извлечения, преобразования, загрузки (ETL) предназначены для обработки повторяющихся операций записи, так как требуется обратная заполнение и повторная обработка. Приемники данных, поддерживающие прозрачную отработку отказа, могут обрабатывать повторяющиеся записи с слиянием записей или удалять и вставлять все записи в определенный диапазон времени.
Для приемников данных, изменяющих конечные точки после отработки отказа, основное и дополнительное хранилище может иметь повторяющиеся или частичные данные. Необходимо вручную объединить данные.
Проверьте следящий сервер и управляйте потоком конвейера (необязательно)
Как правило, необходимо разработать конвейеры для включения действий, таких как сбои и действия подстановки, для перезапуска неудачных конвейеров с точки интереса.
Добавьте глобальный параметр в фабрику данных, чтобы указать регион, например
region='EastUS'в первичной иregion='CentralUS'вторичной фабрике данных.Создайте свидетеля в третьем регионе. Свидетель может быть вызовом REST или любым типом хранилища. Свидетель возвращает текущий основной регион, например
'EastUS'по умолчанию.При возникновении аварии вручную обновите свидетеля, чтобы вернуть новый основной регион, например
'CentralUS'.Добавьте действие в конвейер для поиска следящего сервера и сравнения текущего основного значения с глобальным параметром.
- Если параметры соответствуют, этот конвейер выполняется в основном регионе. Продолжайте реальную работу.
- Если параметры не соответствуют, этот конвейер выполняется в дополнительном регионе. Просто верните результат.
Примечание.
Этот подход представляет зависимость от подстановки следящего сервера в конвейере. Сбой чтения следящего сервера останавливает все запуски конвейера.
Соавторы
Эта статья поддерживается корпорацией Майкрософт. Первоначально он был написан следующими участниками.
Основные авторы:
Кришнакумар Рукмангатхан | Старший руководитель программы — команда Фабрика данных Azure
Сунил Сабат | Главный руководитель программы — команда Фабрика данных Azure
Другие участники:
Марио Циммерманн | Главный менеджер по разработке программного обеспечения — команда Фабрика данных Azure
Wee Hyong Tok | Главный директор PM - команда Фабрика данных Azure
Чтобы просмотреть недоступные профили LinkedIn, войдите в LinkedIn.
Следующие шаги
- Управление непрерывностью бизнес-процессов в Azure
- Устойчивость в Azure
- Терминология устойчивости Azure
- Регионы и зоны доступности
- Репликация между регионами в Azure
- Руководство по решениям для регионов Azure
- Службы Azure, поддерживающие зоны доступности
- Разделение ответственности в облаке
- Избыточность данных в Фабрике данных Azure
- Среда выполнения интеграции в Фабрике данных Azure
- Конвейеры и действия в Фабрике данных Azure и Azure Synapse Analytics
- Интеграция данных в Azure Synapse Analytics и Фабрика данных Azure