Поделиться через


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

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

Надежность — это общая ответственность между вами и корпорацией Майкрософт. Это руководство позволяет определить, какие варианты надежности соответствуют конкретным бизнес-целям и целям простоя.

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

  • Конвейеры Data Factory.

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

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

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

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

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

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

  • Среды выполнения интеграции (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. При сбое одной зоны службы могут переключаться на одну из оставшихся зон.

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

Поддерживаемые регионы

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

Соображения

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

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

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

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

  • 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 автоматически распределяет активности конвейеров, триггеры и другие рабочие операции между здоровыми инстанциями в зонах доступности.

Опыт понижения зоны

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

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

Возврат к исходной системе

Когда зона доступности восстанавливается, 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 описывает ожидаемую доступность службы. Это соглашение также описывает условия, необходимые для достижения этого ожидания. Чтобы понять эти условия, убедитесь, что вы просматриваете соглашения об уровне обслуживания (SLA) для веб-служб.