Развертывания в нескольких регионах для аварийного восстановления в Azure Logic Apps

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

Дополнительные сведения о функциях надежности в Azure Logic Apps, включая устойчивость внутри региона через зоны доступности, см. в статье "Надежность" в Azure Logic Apps.

Рекомендации

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

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

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

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

Дополнительные сведения о надежности в Azure Logic Apps, включая устойчивость внутри региона через зоны доступности и развертывания в нескольких регионах, см. в статье "Надежность" в Azure Logic Apps.

Основное и дополнительное развертывание

Мультирегиональное развертывание состоит из основного и вторичного приложения логики. Основное приложение логики настроено на переключение при отказе на вторичное приложение логики в другом регионе, где служба Azure Logic Apps также доступна. Таким образом, при отказе или сбое основного приложения, его функции берет на себя вспомогательное приложение. Эта стратегия развертывания требует, чтобы вторичное приложение логики и зависимые ресурсы уже были развернуты и готовы во вторичном регионе.

Если вы следуйте рекомендациям DevOps, вы уже используете шаблоны Bicep или Azure Resource Manager для определения и развертывания приложений логики и их зависимых ресурсов. Шаблоны Bicep и Resource Manager позволяют использовать одно определение развертывания, а затем использовать файлы параметров для предоставления значений конфигурации для каждого назначения развертывания. Это означает, что одно и то же приложение логики можно развернуть в разных средах, например для разработки, тестирования и реального применения. Вы также можете развернуть одно приложение логики в разных регионах Azure, которые поддерживают развертывания с несколькими регионами, например для стратегий аварийного восстановления.

Чтобы аварийное переключение прошло успешно, ваши приложения логики и регионы должны соответствовать этим требованиям:

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

• У обоих экземпляров приложения логики должен быть одинаковый тип узла. Таким образом, оба экземпляра развертываются в регионах в глобальных мультитенантных Azure Logic Apps или регионах в одном клиенте Azure Logic Apps. Рекомендации и дополнительные сведения об использовании нескольких регионов для обеспечения непрерывности бизнес-процессов и аварийного восстановления (BC/DR) см. в статье репликация между регионами в Azure: непрерывность бизнес-процессов и аварийное восстановление.

Пример: мультитенантная Azure

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

Подключения к ресурсам

Azure Logic Apps предоставляет операции для более чем 1 000 соединителей, которые рабочий процесс логического приложения может использовать для взаимодействия с другими приложениями, службами, системами и другими ресурсами, такими как учетные записи службы хранилища Azure, базы данных SQL Server, рабочие или учебные почтовые учетные записи и т. д. Если приложению логики требуется доступ к этим ресурсам, нужно создать соответствующие подключения с проверкой подлинности. Каждое подключение — это отдельный ресурс Azure, который существует в определенном расположении и не может использоваться ресурсами в других расположениях.

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

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

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

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

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

Локальные шлюзы данных

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

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

Роли «активный-активный» и «активный-пассивный»

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

Примеры конфигурации «активный — активный»

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

• "Физическая" подсистема балансировки нагрузки, например устройство, которое маршрутизирует трафик.

• "Программная" подсистема балансировки нагрузки, например Azure Load Balancer или Azure API Management. С помощью API Management можно задать политики, обеспечивающие распределение входящего трафика. Также можно использовать службу, поддерживающую отслеживание состояния, например Служебную шину Azure.

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

  

• Каждый экземпляр приложения логики выступает в качестве потребителя, и оба экземпляра конкурируют за сообщения из очереди:

  

Примеры активного и пассивного залога

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

Комбинация шаблонов "активный — активный" и "активный — пассивный"

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

• В основном расположении одно активное приложение логики отслеживает сообщения в очереди Служебная шина Azure, а другое активное приложение логики проверяет электронную почту с помощью триггера опроса Office 365 Outlook.

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

Состояние и история приложения логики

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

Сократите количество брошенных экземпляров в процессе выполнения

Чтобы свести к минимуму количество незавершённых экземпляров процесса, можно выбрать различные шаблоны сообщений, которые можно реализовать, например:

• Фиксированный шаблон маршрутного листа

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

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

  

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

• Шаблон диспетчера процессов (брокера)

• Шаблон предварительной блокировки без времени ожидания

Доступ к журналу триггеров и запусков

Чтобы получить более подробные сведения о предыдущих запусках рабочих процессов приложения логики, вы можете просмотреть журнал триггеров и выполнения этого приложения. Журнал выполнения приложения логики хранится в том же расположении или регионе, где запущено это приложение логики, что означает, что этот журнал нельзя перенести в другое расположение. Если основной экземпляр переключается на вторичный экземпляр при сбое, вы можете получить доступ к журналу триггеров и истории запусков каждого экземпляра только в соответствующих регионах, в которых эти экземпляры выполнялись. Однако сведения об истории приложения логики, не зависящие от расположения, можно получить, настроив приложения логики на отправку диагностических событий в рабочую область Azure Log Analytics. Это позволит просматривать работоспособность и историю в приложениях логики, которые выполняются в разных расположениях.

Руководство по типам триггеров

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

• Триггер повторения
• Опрашивающий триггер
• Триггер запросов
• Триггер вебхука

Триггер повторения

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

• с фиксированной частотой и интервалом, например каждые 10 минут;
• Более сложное расписание, например в последний понедельник каждого месяца в 17:00

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

Предположим, например, что есть приложение логики, которое должно выполняться каждые 10 минут. Вы можете настроить приложения Logic Apps и регионы так, чтобы, если основной регион станет недоступен, вторичный регион взял на себя рабочую нагрузку:

• В основном расположении настройте для этих приложений логики роли "активный — пассивный":

  • Для активного (включенного) приложения логики задайте триггер повторения для запуска в начале часа с повторением каждые 20 минут, например в 9:00, 9:20 и т. д.

  • Для пассивного (отключенного) приложения логики задайте триггер повторения с тем же расписанием, но с запуском через 10 минут после начала часа с повторением каждые 20 минут, например в 9:10, 9:30 и т. д.

• В дополнительном регионе настройте для этих приложений логики конфигурацию пассивный — активный:

  • Для пассивного (отключенного) приложения логики задайте триггер повторения с тем же расписанием, что и для активного в основном расположении, т. е. с запуском в начале часа с повторением каждые 20 минут, например в 9:00, 9:20 и т. д.

  • Для активного (включенного) приложения логики задайте триггер повторения с тем же расписанием, что и для пассивного в основном расположении, т. е. с запуском через 10 минут после начала часа с повторением каждые 20 минут, например в 9:10, 9:30 и т. д.

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

Триггер опроса

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

• статические, т. е. данные, которые всегда доступны для чтения;
• Энергозависимые данные, то есть данные, которые после чтения становятся недоступными.

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

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

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

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

  Например, триггеру на основе запроса, считывающему строку из базы данных, необходимо, чтобы в строке был столбец isRead со значением FALSE. Каждый раз, когда триггер считывает строку, приложение логики обновляет ее, меняя значение в столбце isRead с FALSE на TRUE.

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

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

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

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

• Для приложения логики, работающего с состоянием на стороне сервера, можно настроить экземпляры приложения логики для выполнения либо ролей «активный — активный», где они работают как конкурирующие потребители, либо ролей «активный — пассивный», где резервный экземпляр ожидает, пока основной экземпляр не переключится после сбоя на альтернативное расположение.

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

  Примечание.

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

Триггер запросов

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

• Прямой интерфейс REST API для приложения логики, к которому могут обращаться другие субъекты

  Например, используйте триггер Request, чтобы запускать приложение логики, чтобы другие приложения логики могли вызывать этот триггер с помощью действия Call workflow - Logic Apps.

• Вебхук или механизм обратного вызова для приложения логики

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

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

• Активный-активный: оба экземпляра одновременно обрабатывают запросы или вызовы. Вызывающая сторона или маршрутизатор балансирует или распределяет трафик между этими экземплярами.

• Активный — пассивный: активен только основной экземпляр, который выполняет всю работу, в то время как дополнительный экземпляр ожидает, пока на основном не возникнет сбой или неполадка. Вызывающий объект или маршрутизатор определяет, когда следует вызывать вторичный экземпляр.

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

Триггер вебхука

Триггер вебхука позволяет приложению логики подписываться на службу, передавая этой службе URL-адрес обратного вызова. Затем приложение логики может отслеживать и ждать, когда в конечной точке сервиса произойдет определенное событие. Когда происходит это событие, служба использует URL-адрес обратного вызова, чтобы вызвать триггер webhook, который затем запускает приложение логики. Если этот параметр включён, триггер вебхука подписывается на сервис. При ее отключении триггер отменяет подписку на службу.

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

Оценить состояние основного экземпляра

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

• Проверка доступности основного экземпляра
• Отслеживайте состояние основного экземпляра
• Активация дополнительного экземпляра

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

Проверьте доступность основного экземпляра

Чтобы определить, доступен ли основной экземпляр, запущен ли он и готов ли к работе, можно создать приложение логики для проверки работоспособности в том же регионе, что и основной экземпляр. Затем к этому приложению для проверки работоспособности можно обращаться из другого местоположения. Если приложение проверки работоспособности успешно отвечает, то базовая инфраструктура службы Azure Logic Apps в этом регионе доступна и работает. Если приложение для проверки состояния не отвечает, можно считать, что этот узел больше не работает нормально.

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

1. Принимает вызов от watchdog-приложения с использованием триггера Request.

2. С помощью действия Response верните состояние, указывающее, по-прежнему ли работает проверяемое приложение логики.

   Внимание

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

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

Создание приложения логики для наблюдения

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

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

1. Запускается в фиксированное время или по расписанию с помощью триггера повторения.

   Можно задать интервал повторения меньше допустимого уровня для целевого времени восстановления (RTO).

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

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

Активация дополнительного экземпляра

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

Сбор диагностических данных

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

• Если вы хотите использовать эти данные в Azure Log Analytics, их можно сделать доступными как для основного, так и для дополнительного расположения, настроив параметры диагностики приложения логики и отправку данных в разные рабочие области Log Analytics. Дополнительные сведения см. в статье Настройка журналов Azure Monitor и сбор диагностических данных для Azure Logic Apps.

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

  • Аварийное восстановление и отработка отказа учетных записей в хранилище BLOB-объектов Azure
  • Геоаварийное восстановление Центры событий Azure

Следующие шаги

• Проектирование надежных приложений Azure
• Контрольный список для обеспечения устойчивости конкретных служб Azure
• Управление данными для обеспечения устойчивости в Azure
• Резервное копирование и аварийное восстановление для приложений Azure
• Восстановление после нарушения работы службы на уровне региона
• Соглашения об уровне обслуживания (SLA) Майкрософт для служб Azure