Непрерывность бизнес-процессов и аварийное восстановление для Azure Logic Apps

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

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

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

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

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

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

Каждое приложение логики должно указать расположение, которое вы хотите использовать для развертывания, например регион Azure, например "Западная часть США". Ключевой элемент этой стратегии аварийного восстановления — настройка основного приложения логики для отработки отказа в резервное приложение логики в альтернативном расположении, где также доступна служба Azure Logic Apps. Таким образом, при отказе или сбое основного приложения, его функции берет на себя вспомогательное приложение. Для этой стратегии требуется, чтобы вспомогательное приложение логики и зависимые ресурсы были развернуты в альтернативном расположении и готовы к работе.

Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Роли "активный — активный" и "активный — пассивный"

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

Основная и дополнительная роль	Description
Шаблон "активный — активный"	Экземпляры основного и дополнительного приложения логики в обоих расположениях активно обрабатывают запросы, выполнив один из следующих шаблонов: - Балансировка нагрузки: при необходимости оба экземпляра могут прослушивать конечную точку, а нагрузка может распределяться между ними. - Конкурирующие потребители: оба экземпляра могут работать в роли конкурирующих потребителей, конкурируя за сообщения в очереди. Если в одном экземпляр возникает сбой, второй принимает на себя рабочую нагрузку.
Активный пассивный	Основной экземпляр приложения логики активно обрабатывает всю рабочую нагрузку, а дополнительный экземпляр является пассивным (отключенным или неактивным). Дополнительный экземпляр ожидает сигнала о том, что основной экземпляр стал недоступен или не работает из-за неполадки либо сбоя, и в этом случае принимает на себя рабочую нагрузку в качестве активного экземпляра.
Комбинация	Некоторые приложения логики работают в роли "активный — активный", в то время как другие — в роли "активный — пассивный".

Примеры использования шаблона "активный — активный"

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

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

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

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

  

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

  

Примеры шаблона "активный — пассивный"

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

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

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

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

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

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

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

Уменьшение числа прерванных выполняющихся экземпляров

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

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

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

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

  

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

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

• Шаблон просмотра-блокировки без тайм-аута

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  Примечание.

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

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

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

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

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

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

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

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

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

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

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

Триггер веб-перехватчика

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

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

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

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

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

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

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

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

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

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

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

   Внимание

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

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

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

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

Внимание

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

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

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

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

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

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

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

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

Избыточность между зонами с зонами доступности

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

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

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

• Защита приложений логики категории "Потребление" от сбоев регионов с помощью избыточности между зонами и зон доступности
• Регионы и зоны доступности Azure

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

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