Надежность в фабрике данных Azure

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

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

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

Замечание

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

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

Фабрика данных состоит из нескольких компонентов инфраструктуры. Каждый компонент поддерживает надежность инфраструктуры различными способами.

К компонентам фабрики данных относятся следующие компоненты:

• Базовая служба Фабрики данных, которая управляет триггерами конвейера и контролирует координацию действий конвейера. Основная служба также управляет метаданными для каждого компонента фабрики данных. Корпорация Майкрософт управляет основной службой.

• Среды выполнения интеграции (IR), которые подключаются к хранилищам данных и выполняют действия, определенные в вашем конвейере. Существуют различные типы инфракрасных излучений.

  • Управляемые корпорацией Майкрософт IR, которые включают Azure IR и Azure-SQL Server Integration Services (Azure-SSIS) IR. Корпорация Майкрософт управляет компонентами, составляющими эти среды выполнения. В некоторых сценариях вы настраиваете параметры, влияющие на устойчивость IR.

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

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

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

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

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

Идемпотентность

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

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

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

• Используйте стратегию upsert для соединителей, поддерживающих upsert. Прежде чем происходит вставка повторяющихся записей, используйте этот подход, чтобы проверить, существует ли запись. Если он существует, обновите его. Если он не существует, вставьте его. Например, команды SQL, такие как MERGE или ON DUPLICATE KEY UPDATE, используют этот подход upsert.

• Используйте стратегии копирования. Дополнительные сведения см. в разделе "Проверка согласованности данных" в действии копирования.

Политики повторных попыток

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

• Триггеры переворачивающегося окна
• Действия выполнения

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

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

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

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

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

• Базовая служба: Корпорация Майкрософт управляет компонентами в основной службе фабрики данных и распределяет их по зонам доступности.

  Однако после сбоя зоны Microsoft не гарантирует состояние триггеров скользящего окна.

• IRs: Поддержка избыточности зон зависит от типа используемого IR.

  • Azure IR поддерживает устойчивость к отказам в зоне, и Майкрософт управляет этой функцией.

    

  • Azure-SSIS IR требует развертывания как минимум двух узлов. Эти узлы автоматически выделяются в разные зоны доступности.

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

    

  • SHIR возлагает на вас ответственность за развертывание вычислительной инфраструктуры для поддержки среды выполнения. Можно развернуть несколько узлов, таких как отдельные виртуальные машины, и настроить их для обеспечения высокой доступности. Затем эти узлы можно распределить между несколькими зонами доступности. Дополнительные сведения см. в разделе "Высокий уровень доступности и масштабируемость".

Требования

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

Себестоимость

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

• IRs: Стоимость избыточности зоны зависит от используемого типа IR.

  • Azure IR включает избыточность зоны без дополнительных затрат.

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

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

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

• Базовая служба: Конфигурация не требуется. Основная служба Data Factory автоматически поддерживает избыточность зоны.

• IRs:

  • Azure IR: Конфигурация не требуется. Azure IR автоматически обеспечивает избыточность внутри зоны.

  • Azure-SSIS IR: Конфигурация не требуется. IR Azure-SSIS автоматически включает избыточность зоны при развертывании с двумя или более узлами.

  • SHIR требует настройки собственной устойчивости, которая включает распространение узлов в нескольких зонах доступности.

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

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

• IRs:

  • Azure IR автоматически масштабируется на основе спроса, и вам не нужно планировать или управлять емкостью.

  • Для Azure-SSIS IR необходимо специально настроить количество используемых узлов. Чтобы подготовиться к отказу зоны доступности, рассмотрите возможность избыточного резервирования емкости вашего информационного ресурса. Чрезмерное подготовление позволяет решению выдерживать некоторую степень потери емкости и продолжать функционировать без снижения производительности. Дополнительные сведения см. в разделе "Управление емкостью путем избыточного выделения ресурсов".

  • SHIR требует настройки собственной емкости и масштабирования. При развертывании SHIR рассмотрите возможность избыточного обеспечения.

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

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

• Маршрутизация трафика между зонами: Во время обычных операций служба Data Factory автоматически распределяет активности конвейеров, триггеры и другие рабочие операции между здоровыми инстанциями в зонах доступности.

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

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

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

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

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

• Уведомление: Microsoft не уведомляет вас автоматически об отключении зоны. Однако вы можете использовать Azure Resource Health для отслеживания работоспособности отдельного ресурса и настроить оповещения о работоспособности ресурсов , чтобы уведомить вас о проблемах. Вы также можете использовать службу "Работоспособность служб Azure ", чтобы понять общую работоспособность службы, включая любые сбои зоны, и вы можете настроить оповещения о работоспособности служб , чтобы уведомить вас о проблемах.

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

• Ожидаемое время простоя: Во время сбоя зоны не ожидается простоя.

• Ожидаемая потеря данных: В целом Data Factory — это бессостоятая служба, поэтому во время сбоя зоны не ожидается потеря данных.

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

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

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

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

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

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

Для SHIRs, можно использовать Azure Chaos Studio, чтобы имитировать сбой зоны доступности на виртуальной машине Azure.

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

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

Переключение на резервный регион под управлением Microsoft

Отказоустойчивость обеспечивается Microsoft для Data Factory в связанных регионах, за исключением Бразилии (Юг) и Юго-Восточной Азии. В маловероятном случае длительного сбоя региона корпорация Майкрософт может инициировать переключение экземпляра Azure Data Factory на резервный регион.

Из-за требований к резидентности данных в Южной Бразилии и Юго-Восточной Азии данные Data Factory хранятся только в локальном регионе с помощью зоне-редундантного хранилища Azure. Для Юго-Восточной Азии все данные хранятся в Сингапуре. Для Южной Бразилии все данные хранятся в Бразилии.

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

Это важно

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

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

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

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

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

• Отказоустойчивость Azure-SSIS IR управляется отдельно от отказоустойчивости, управляемой корпорацией Майкрософт, в рамках фабрики данных. Для получения дополнительной информации см. Индивидуальные решения для нескольких регионов для обеспечения устойчивости.

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

Перенастройка после переключения на резервную систему

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

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

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

• Настройте систему управления версиями для Data Factory, чтобы отслеживать и проводить аудит изменений в метаданных. Этот подход можно использовать для доступа к JSON-файлам метаданных для конвейеров, наборов данных, связанных служб и триггеров. Фабрика данных поддерживает различные типы репозиториев Git, такие как Azure DevOps и GitHub. Дополнительные сведения см. в разделе "Управление версиями в Data Factory".

• Используйте систему непрерывной интеграции и непрерывной доставки (CI/CD), например Azure DevOps, для управления метаданными и развертываниями конвейера. Ci/CD можно использовать для быстрого восстановления операций в экземпляре в другом регионе. Если регион недоступен, можно подготовить новую фабрику данных вручную или с помощью автоматизации. После создания новой фабрики данных можно восстановить конвейеры, наборы данных и связанные службы JSON из существующего репозитория Git. Дополнительные сведения см. в статье "Непрерывность бизнес-процессов" и аварийное восстановление (BCDR) для конвейеров Фабрики данных и Azure Synapse Analytics.

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

• IR с номером Azure-SSIS использует базу данных, хранящуюся в Azure SQL Database или Azure SQL Managed Instance. Вы можете настроить георепликацию или группу отработки отказа для этой базы данных. База данных Azure-SSIS расположена в основном регионе Azure с доступом на чтение и запись. База данных постоянно реплицируется в дополнительный регион с доступом только для чтения. Если основной регион недоступен, включается режим отказоустойчивости, в результате чего первичная и вторичная базы данных меняются ролями.

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

  Дополнительные сведения см. в разделе "Настройка Azure-SSIS IR для BCDR".

• SHIR работает на инфраструктуре, которую вы управляете. Если SHIR развернут на виртуальной машине Azure, можно использовать Azure Site Recovery для активации переноса виртуальной машины в другой регион.

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

Фабрика данных поддерживает CI/CD с помощью интеграции с системой контроля версий для создания резервной копии метаданных экземпляра фабрики данных. Конвейеры CI/CD легко развертывают эти метаданные в новой среде. Дополнительные сведения см. в CI/CD в Data Factory.

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

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

Фабрика данных предоставляет отдельные соглашения об уровне обслуживания доступности для:

• Частота успешных вызовов API, таких как управление фабрикой данных.
• Количество запусков активности, которые начинают выполняться.

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

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

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