Continuidade de negócio e recuperação após desastre para o Azure Logic Apps

  • Artigo

Para ajudar a reduzir o impacto e os efeitos que os eventos imprevisíveis têm na sua empresa e clientes, certifique-se de que tem uma solução de recuperação após desastre (DR) implementada para que possa proteger os dados, restaurar rapidamente os recursos que suportam funções empresariais críticas e manter as operações em execução para manter a continuidade do negócio (BC). Por exemplo, as interrupções podem incluir falhas, perdas na infraestrutura ou componentes subjacentes, tais como armazenamento, rede ou recursos de computação, falhas de aplicações irrecuperáveis ou até mesmo uma perda total do datacenter. Ao ter uma solução de continuidade de negócio e recuperação após desastre (BCDR) pronta, a sua empresa ou organização pode responder mais rapidamente a interrupções, planeadas ou não planeadas e reduzir o tempo de inatividade para os seus clientes.

Este artigo fornece orientações e estratégias BCDR que pode aplicar quando cria fluxos de trabalho automatizados com o Azure Logic Apps. Os fluxos de trabalho de aplicações lógicas ajudam-no a integrar e orquestrar mais facilmente dados entre aplicações, serviços cloud e sistemas no local ao reduzir a quantidade de código que tem de escrever. Quando planear o BCDR, certifique-se de que considera não só as suas aplicações lógicas, mas também estes recursos do Azure que utiliza com as suas aplicações lógicas:

Localizações primárias e secundárias

Cada aplicação lógica tem de especificar a localização que pretende utilizar para a implementação. Esta localização é uma região pública no Azure multi-inquilino global, como "E.U.A. Oeste" ou um ambiente de serviço de integração (ISE) que criou e implementou anteriormente numa rede virtual do Azure. Executar aplicações lógicas num ISE é semelhante à execução de aplicações lógicas numa região global do Azure, o que significa que a estratégia de recuperação após desastre pode aplicar-se a ambos os cenários. No entanto, os ISEs têm outras considerações, como configurar o acesso a recursos que estão disponíveis apenas para ISEs.

Nota

Se a sua aplicação lógica também funcionar com artefactos B2B, como parceiros comerciais, contratos, esquemas, mapas e certificados, que são armazenados numa conta de integração, tanto a sua conta de integração como as aplicações lógicas têm de especificar a mesma localização.

Esta estratégia de recuperação após desastre centra-se na configuração da sua aplicação lógica primária para ativação pós-falha numa aplicação lógica de reserva ou cópia de segurança numa localização alternativa onde o Azure Logic Apps também está disponível. Desta forma, se o primário sofrer perdas, perturbações ou falhas, o secundário pode assumir o trabalho. Esta estratégia requer que a sua aplicação lógica secundária e os recursos dependentes já estejam implementados e prontos na localização alternativa.

Se seguir boas práticas do DevOps, já utiliza modelos do Azure Resource Manager para definir e implementar as suas aplicações lógicas e os respetivos recursos dependentes. Resource Manager modelos dão-lhe a capacidade de utilizar uma única definição de implementação e, em seguida, utilizar ficheiros de parâmetros para fornecer os valores de configuração a utilizar para cada destino de implementação. Esta capacidade significa que pode implementar a mesma aplicação lógica em diferentes ambientes, por exemplo, desenvolvimento, teste e produção. Também pode implementar a mesma aplicação lógica em diferentes regiões ou ISEs do Azure, que suportam estratégias de recuperação após desastre que utilizam regiões emparelhadas.

Para a estratégia de ativação pós-falha, as aplicações lógicas e as localizações têm de cumprir estes requisitos:

Exemplo: Azure multi-inquilino

Este exemplo mostra instâncias de aplicações lógicas primárias e secundárias, que são implementadas em regiões separadas no Azure multi-inquilino global para este cenário. Um único modelo de Resource Manager define as instâncias da aplicação lógica e os recursos dependentes necessários para essas aplicações lógicas. Os ficheiros de parâmetros separados especificam os valores de configuração a utilizar para cada localização de implementação:

Instâncias de aplicações lógicas primárias e secundárias em localizações separadas

Exemplo: Ambiente do serviço de integração

Este exemplo mostra as instâncias de aplicações lógicas primárias e secundárias anteriores, mas implementadas em ISEs separados. Um único modelo de Resource Manager define ambas as instâncias da aplicação lógica, os recursos dependentes exigidos por essas aplicações lógicas e os ISEs como as localizações de implementação. Os ficheiros de parâmetros separados definem os valores de configuração a utilizar para a implementação em cada localização:

Aplicações lógicas primárias e secundárias em diferentes localizações

Ligações a recursos

O Azure Logic Apps fornece muitas centenas de operações de conector que o fluxo de trabalho da aplicação lógica pode utilizar para trabalhar com outras aplicações, serviços, sistemas e outros recursos, como contas de Armazenamento do Azure, bases de dados SQL Server, contas de e-mail escolares ou profissionais, etc. Se a sua aplicação lógica precisar de acesso a estes recursos, crie ligações que autenticem o acesso a estes recursos. Cada ligação é um recurso do Azure separado que existe numa localização específica e não pode ser utilizado pelos recursos noutras localizações.

Para a sua estratégia de recuperação após desastre, considere as localizações onde existem recursos dependentes relativamente às instâncias da aplicação lógica:

  • A instância principal e os recursos dependentes existem em localizações diferentes. Neste caso, a instância secundária pode ligar-se aos mesmos recursos ou pontos finais dependentes. No entanto, deve criar ligações especificamente para a instância secundária. Desta forma, se a sua localização primária ficar indisponível, as ligações secundárias não serão afetadas.

    Por exemplo, suponha que a sua aplicação lógica primária se liga a um serviço externo, como o Salesforce. Normalmente, a disponibilidade e a localização do serviço externo são independentes da disponibilidade da sua aplicação lógica. Neste caso, a instância secundária pode ligar-se ao mesmo serviço, mas deve ter a sua própria ligação.

  • A instância primária e os recursos dependentes existem na mesma localização. Neste caso, os recursos dependentes devem ter cópias de segurança ou versões replicadas numa localização diferente para que a instância secundária ainda possa aceder a esses recursos.

    Por exemplo, suponha que a sua aplicação lógica primária se liga a um serviço que está na mesma localização ou região, por exemplo, SQL do Azure Base de Dados. Se toda esta região ficar indisponível, é provável que o serviço base de dados SQL do Azure nessa região também esteja indisponível. Neste caso, pretende que a instância secundária utilize uma base de dados replicada ou de cópia de segurança juntamente com uma ligação separada a essa base de dados.

Gateways de dados no local

Se a sua aplicação lógica for executada no Azure multi-inquilino e precisar de acesso a recursos no local, como bases de dados SQL Server, terá de instalar o gateway de dados no local num computador local. Em seguida, pode criar um recurso de gateway de dados no portal do Azure para que a sua aplicação lógica possa utilizar o gateway quando criar uma ligação ao recurso.

O recurso do gateway de dados está associado a uma localização ou região do Azure, tal como o recurso da aplicação lógica. Na sua estratégia de recuperação após desastre, certifique-se de que o gateway de dados permanece disponível para a sua aplicação lógica utilizar. Pode ativar a elevada disponibilidade do gateway quando tiver várias instalações de gateway.

Nota

Se a sua aplicação lógica for executada num ambiente de serviço de integração (ISE) e utilizar apenas conectores com versão ISE para origens de dados no local, não precisa do gateway de dados porque os conectores ISE fornecem acesso direto ao recurso no local.

Se não estiver disponível nenhum conector com versão ISE para o recurso no local pretendido, a sua aplicação lógica ainda pode criar a ligação com um conector não ISE, que é executado no Azure multi-inquilino global e não no SEU ISE. No entanto, esta ligação requer o gateway de dados no local.

Funções ativas e ativas passivas

Pode configurar as suas localizações primárias e secundárias para que as instâncias da aplicação lógica nestas localizações possam desempenhar estas funções:

Função primária-secundária Descrição
Ativo-ativo As instâncias da aplicação lógica primária e secundária em ambas as localizações processam ativamente os pedidos ao seguir um destes padrões:

- Balanceamento de carga: pode fazer com que ambas as instâncias ouçam um ponto final e o tráfego de balanceamento de carga para cada instância, conforme necessário.

- Consumidores concorrentes: pode ter ambas as instâncias a funcionar como consumidores concorrentes para que as instâncias compitam por mensagens de uma fila. Se uma instância falhar, a outra instância assume a carga de trabalho.
Ativo-passivo A instância da aplicação lógica primária processa ativamente toda a carga de trabalho, enquanto a instância secundária é passiva (desativada ou inativa). O secundário aguarda um sinal de que o principal está indisponível ou não está a funcionar devido a interrupção ou falha e assume a carga de trabalho como a instância ativa.
Combinação Algumas aplicações lógicas desempenham uma função ativa-ativa, enquanto outras aplicações lógicas desempenham uma função ativa-passiva.

Exemplos ativos-ativos

Estes exemplos mostram a configuração ativa-ativa em que ambas as instâncias de aplicações lógicas processam ativamente pedidos ou mensagens. Outro sistema ou serviço distribui os pedidos ou mensagens entre instâncias, por exemplo, uma destas opções:

  • Um balanceador de carga "físico", como uma peça de hardware que encaminha o tráfego

  • Um balanceador de carga "suave", como Balanceador de Carga do Azure ou Gestão de API do Azure. Com Gestão de API, pode especificar políticas que determinam como fazer o balanceamento de carga do tráfego de entrada. Em alternativa, pode utilizar um serviço que suporte o controlo de estado, por exemplo, Azure Service Bus.

    Embora este exemplo mostre principalmente Balanceador de Carga do Azure, pode utilizar a opção mais adequada às necessidades do seu cenário:

    Configuração

  • Cada instância de aplicação lógica atua como consumidor e tem ambas as instâncias a competir por mensagens de uma fila:

    Configuração

Exemplos ativos-passivos

Este exemplo mostra a configuração ativa-passiva em que a instância da aplicação lógica primária está ativa numa localização, enquanto a instância secundária permanece inativa noutra localização. Se a primária sofrer uma interrupção ou falha, pode fazer com que um operador execute um script que ative o secundário para assumir a carga de trabalho.

Configuração

Combinação com ativo-ativo e ativo-passivo

Este exemplo mostra uma configuração combinada em que a localização primária tem instâncias de aplicações lógicas ativas, enquanto a localização secundária tem instâncias de aplicações lógicas ativas-passivas. Se a localização primária sofrer uma interrupção ou falha, a aplicação lógica ativa na localização secundária, que já está a processar uma carga de trabalho parcial, pode assumir toda a carga de trabalho.

  • Na localização primária, uma aplicação lógica ativa escuta uma fila de Azure Service Bus de mensagens, enquanto outra aplicação lógica ativa verifica a existência de e-mails com um Office 365 acionador de consulta do Outlook.

  • Na localização secundária, uma aplicação lógica ativa funciona com a aplicação lógica na localização primária ao escutar e competir por mensagens da mesma fila do Service Bus. Entretanto, uma aplicação lógica passiva inativa aguarda em modo de espera para verificar se existem e-mails quando a localização primária fica indisponível, mas está desativada para evitar a releção de e-mails.

Combinação

Estado e histórico da aplicação lógica

Quando a aplicação lógica é acionada e começa a ser executada, o estado da aplicação é armazenado na mesma localização onde a aplicação foi iniciada e não é transferível para outra localização. Se ocorrer uma falha ou interrupção, quaisquer instâncias de fluxo de trabalho em curso serão abandonadas. Quando tem uma localização primária e secundária configurada, as novas instâncias de fluxo de trabalho começam a ser executadas na localização secundária.

Reduzir instâncias abandonadas em curso

Para minimizar o número de instâncias de fluxo de trabalho em curso abandonadas, pode escolher entre vários padrões de mensagens que pode implementar, por exemplo:

  • Padrão de deslize de encaminhamento fixo

    Este padrão de mensagem empresarial que divide um processo de negócio em fases mais pequenas. Para cada fase, vai configurar uma aplicação lógica que processa a carga de trabalho para essa fase. Para comunicar entre si, as suas aplicações lógicas utilizam um protocolo de mensagens assíncrona, como Azure Service Bus filas ou tópicos. Quando divide um processo em fases mais pequenas, reduz o número de processos empresariais que podem ficar bloqueados numa instância de aplicação lógica falhada. Para obter informações mais gerais sobre este padrão, veja Padrões de integração empresarial – Deslize de encaminhamento.

    Este exemplo mostra um padrão de deslize de encaminhamento em que cada aplicação lógica representa uma fase e utiliza uma fila do Service Bus para comunicar com a próxima aplicação lógica no processo.

    Dividir um processo de negócio em fases representadas por aplicações lógicas, que comunicam entre si com Azure Service Bus filas

    Se as instâncias de aplicações lógicas primárias e secundárias seguirem o mesmo padrão de deslize de encaminhamento nas respetivas localizações, pode implementar o padrão de consumidores concorrentes ao configurar funções ativas-ativas para essas instâncias.

  • Padrão do gestor de processos (mediador)

  • Pré-bloqueio sem padrão de tempo limite

Acesso ao histórico de acionadores e execuções

Para obter mais informações sobre as execuções de fluxos de trabalho anteriores da sua aplicação lógica, pode rever o acionador e o histórico de execuções da aplicação. O histórico de execuções de uma aplicação lógica é armazenado na mesma localização ou região onde essa aplicação lógica foi executada, o que significa que não pode migrar este histórico para uma localização diferente. Se a instância primária efetuar a ativação pós-falha para uma instância secundária, só poderá aceder ao acionador de cada instância e executar o histórico nas respetivas localizações onde essas instâncias foram executadas. No entanto, pode obter informações sobre o histórico da sua aplicação lógica ao configurar as suas aplicações lógicas para enviar eventos de diagnóstico para uma área de trabalho do Azure Log Analytics. Em seguida, pode rever o estado de funcionamento e o histórico em aplicações lógicas que são executadas em várias localizações.

Documentação de orientação sobre o tipo de acionador

O tipo de acionador que utiliza nas suas aplicações lógicas determina as suas opções para configurar aplicações lógicas em várias localizações na sua estratégia de recuperação após desastre. Eis os tipos de acionadores disponíveis que pode utilizar nas aplicações lógicas:

Acionador de periodicidade

O acionador Periodicidade é independente de qualquer serviço ou ponto final específico e é acionado apenas com base numa agenda especificada e sem outros critérios, por exemplo:

  • Uma frequência e intervalo fixos, como a cada 10 minutos
  • Uma agenda mais avançada, como a última segunda-feira de cada mês às 17:00

Quando a aplicação lógica começa com um acionador Periodicidade, tem de configurar as instâncias da aplicação lógica primária e secundária com as funções ativa-passiva. Para reduzir o objetivo de tempo de recuperação (RTO), que se refere à duração de destino para restaurar um processo de negócio após uma interrupção ou desastre, pode configurar as instâncias da aplicação lógica com uma combinação de funções ativas-passivas e funções passiva-ativas. Nesta configuração, irá dividir a agenda entre localizações.

Por exemplo, suponha que tem uma aplicação lógica que precisa de ser executada a cada 10 minutos. Pode configurar as suas aplicações lógicas e localizações para que, se a localização primária ficar indisponível, a localização secundária possa assumir o trabalho:

Combinação

  • Na localização primária, configure funções ativas-passivas para estas aplicações lógicas:

    • Para a aplicação lógica ativada ativada , defina o acionador Periodicidade para iniciar na parte superior da hora e repita a cada 20 minutos, por exemplo, 9:00, 9:20 e assim sucessivamente.

    • Para a aplicação lógica passiva desativada, defina o acionador Periodicidade para a mesma agenda, mas comece a 10 minutos após a hora e repita a cada 20 minutos, por exemplo, 9:10, 9:30 e assim sucessivamente.

  • Na localização secundária, configure o modo passivo-ativo para estas aplicações lógicas:

    • Para a aplicação lógica passiva desativada, defina o acionador Periodicidade para a mesma agenda que a aplicação lógica ativa na localização primária, que está na parte superior da hora e se repete a cada 20 minutos, por exemplo, 9:00, 9:10 e assim sucessivamente.

    • Para a aplicação lógica ativada ativada , defina o acionador Periodicidade para a mesma agenda que a aplicação lógica passiva na localização primária, que é começar a 10 minutos após a hora e repetir a cada 20 minutos, por exemplo, 9:10, 9:20 e assim sucessivamente.

Agora, se ocorrer um evento disruptivo na localização primária, ative a aplicação lógica passiva na localização alternativa. Desta forma, se encontrar a falha demorar algum tempo, esta configuração limita o número de periodicidades perdidas durante esse atraso.

Acionador de consulta

Para verificar regularmente se estão disponíveis novos dados para processamento a partir de um serviço ou ponto final específico, a sua aplicação lógica pode utilizar um acionador de consulta que chama repetidamente o serviço ou ponto final com base numa agenda de periodicidade fixa. Os dados fornecidos pelo serviço ou ponto final podem ter um destes tipos:

  • Dados estáticos, que descrevem dados que estão sempre disponíveis para leitura
  • Dados voláteis, que descrevem dados que já não estão disponíveis após a leitura

Para evitar ler repetidamente os mesmos dados, a aplicação lógica tem de se lembrar dos dados que foram lidos anteriormente ao manter o estado no lado do cliente ou no servidor, serviço ou lado do sistema.

  • As aplicações lógicas que funcionam com o estado do lado do cliente utilizam acionadores que podem manter o estado.

    Por exemplo, um acionador que lê uma nova mensagem a partir de uma caixa de entrada de e-mail requer que o acionador se lembre da mensagem lida mais recentemente. Dessa forma, o acionador inicia a aplicação lógica apenas quando é apresentada a próxima mensagem não lida.

  • As aplicações lógicas que funcionam com o servidor, o serviço ou o estado do lado do sistema utilizam valores de propriedade ou definições que se encontram no servidor, serviço ou lado do sistema.

    Por exemplo, um acionador baseado em consultas que lê uma linha de uma base de dados requer que a linha tenha uma isRead coluna definida como FALSE. Sempre que o acionador lê uma linha, a aplicação lógica atualiza essa linha ao alterar a isRead coluna de FALSE para TRUE.

    Esta abordagem do lado do servidor funciona da mesma forma para filas ou tópicos do Service Bus que têm semântica de fila onde um acionador pode ler e bloquear uma mensagem enquanto a aplicação lógica processa a mensagem. Quando a aplicação lógica concluir o processamento, o acionador elimina a mensagem da fila ou tópico.

Do ponto de vista da recuperação após desastre, quando configurar as instâncias primárias e secundárias da sua aplicação lógica, certifique-se de que contabiliza estes comportamentos com base no facto de a sua aplicação lógica controlar o estado no lado do cliente ou no lado do servidor:

  • Para uma aplicação lógica que funcione com o estado do lado do cliente, certifique-se de que a aplicação lógica não lê a mesma mensagem mais do que uma vez. Apenas uma localização pode ter uma instância de aplicação lógica ativa em qualquer altura específica. Confirme que a instância da aplicação lógica na localização alternativa está inativa ou desativada até que a instância primária efetue a ativação pós-falha para a localização alternativa.

    Por exemplo, o acionador Office 365 Outlook mantém o estado do lado do cliente e controla o carimbo de data/hora do e-mail lido mais recentemente para evitar ler um duplicado.

  • Para uma aplicação lógica que funcione com o estado do lado do servidor, pode configurar as instâncias da aplicação lógica para desempenhar funções ativas-ativas onde funcionam como consumidores concorrentes ou funções ativas-passivas em que a instância alternativa aguarda até a instância primária efetuar a ativação pós-falha para a localização alternativa.

    Por exemplo, a leitura a partir de uma fila de mensagens, como uma fila de Azure Service Bus, utiliza o estado do lado do servidor porque o serviço de fila mantém bloqueios nas mensagens para impedir que outros clientes leiam as mesmas mensagens.

    Nota

    Se a sua aplicação lógica precisar de ler mensagens por uma ordem específica, por exemplo, a partir de uma fila do Service Bus, pode utilizar o padrão de consumidor concorrente, mas apenas quando combinado com sessões do Service Bus, que também é conhecido como o padrão de comboio sequencial. Caso contrário, tem de configurar as instâncias da aplicação lógica com as funções active-passive.

Acionador de pedido

O acionador Pedido torna a sua aplicação lógica callable a partir de outras aplicações, serviços e sistemas e é normalmente utilizado para fornecer estas capacidades:

  • Uma API REST direta para a sua aplicação lógica que outras pessoas podem chamar

    Por exemplo, utilize o acionador Pedir para iniciar a aplicação lógica para que outras aplicações lógicas possam chamar o acionador através da ação Fluxo de trabalho de chamadas – Logic Apps .

  • Um webhook ou mecanismo de chamada de retorno para a sua aplicação lógica

  • Uma forma de executar manualmente operações ou rotinas de utilizador para chamar a sua aplicação lógica, por exemplo, através de um script do PowerShell que executa uma tarefa específica

Do ponto de vista da recuperação após desastre, o Acionador de pedidos é um recetor passivo porque a aplicação lógica não funciona e aguarda até que outro serviço ou sistema chame explicitamente o acionador. Como ponto final passivo, pode configurar as instâncias primária e secundária das seguintes formas:

  • Ativo-ativo: ambas as instâncias processam ativamente pedidos ou chamadas. O autor da chamada ou router equilibra ou distribui o tráfego entre essas instâncias.

  • Ativo-passivo: apenas a instância primária está ativa e processa todo o trabalho, enquanto a instância secundária aguarda até que a instância primária sofra interrupções ou falhas. O autor da chamada ou router determina quando deve chamar a instância secundária.

Como arquitetura recomendada, pode utilizar o Azure Gestão de API como um proxy para as aplicações lógicas que utilizam acionadores de Pedido. Gestão de API fornece resiliência entre regiões incorporada e a capacidade de encaminhar o tráfego através de vários pontos finais.

Acionador de webhook

Um acionador de webhook fornece a capacidade de a aplicação lógica subscrever um serviço ao transmitir um URL de chamada de retorno para esse serviço. Em seguida, a sua aplicação lógica pode escutar e aguardar que um evento específico ocorra nesse ponto final de serviço. Quando o evento acontece, o serviço chama o acionador do webhook com o URL de chamada de retorno, que, em seguida, executa a aplicação lógica. Quando ativado, o acionador do webhook subscreve o serviço. Quando desativado, o acionador anula a subscrição do serviço.

Do ponto de vista da recuperação após desastre, configure instâncias primárias e secundárias que utilizem acionadores de webhook para desempenhar funções ativa-passivas porque apenas uma instância deve receber eventos ou mensagens do ponto final subscrito.

Avaliar o estado de funcionamento da instância primária

Para que a sua estratégia de recuperação após desastre funcione, a solução precisa de formas de executar estas tarefas:

Esta secção descreve uma solução que pode utilizar diretamente ou como base para a sua própria estrutura. Eis uma descrição geral do elemento visual de alto nível para esta solução:

Criar uma aplicação lógica watchdog que monitoriza uma aplicação lógica de verificação de estado de funcionamento na localização primária

Verificar a disponibilidade da instância primária

Para determinar se a instância primária está disponível, em execução e capaz de funcionar, pode criar uma aplicação lógica de "verificação de estado de funcionamento" que esteja na mesma localização que a instância primária. Em seguida, pode chamar esta aplicação de verificação de estado de funcionamento a partir de uma localização alternativa. Se a aplicação de verificação de estado de funcionamento responder com êxito, a infraestrutura subjacente do serviço Azure Logic Apps nessa região está disponível e a funcionar. Se a aplicação de verificação de estado de funcionamento não responder, pode assumir que a localização já não está em bom estado de funcionamento.

Para esta tarefa, crie uma aplicação lógica básica de verificação de estado de funcionamento que efetue estas tarefas:

  1. Recebe uma chamada da aplicação watchdog com o acionador Pedir.

  2. Responda com um estado que indica se a aplicação lógica verificada ainda funciona com a ação Resposta.

    Importante

    A aplicação lógica de verificação de estado de funcionamento tem de utilizar uma ação resposta para que a aplicação responda de forma síncrona e não assíncrona.

  3. Opcionalmente, para determinar se a localização primária está em bom estado de funcionamento, pode considerar o estado de funcionamento de quaisquer outros serviços que interajam com a aplicação lógica de destino nesta localização. Basta expandir a aplicação lógica de verificação de estado de funcionamento para avaliar o estado de funcionamento destes outros serviços também.

Criar uma aplicação lógica watchdog

Para monitorizar o estado de funcionamento da instância primária e chamar a aplicação lógica de verificação de estado de funcionamento, crie uma aplicação lógica "watchdog" numa localização alternativa. Por exemplo, pode configurar a aplicação lógica watchdog para que, se a chamada da lógica de verificação de estado de funcionamento falhar, o watchdog possa enviar um alerta à equipa de operações para que possa investigar a falha e por que motivo a instância primária não responde.

Importante

Certifique-se de que a aplicação lógica watchdog está numa localização diferente da localização primária. Se o Azure Logic Apps na localização primária tiver problemas, o fluxo de trabalho da aplicação lógica watchdog poderá não ser executado.

Para esta tarefa, na localização secundária, crie uma aplicação lógica watchdog que efetue estas tarefas:

  1. Execute com base numa periodicidade fixa ou agendada com o acionador Periodicidade.

    Pode definir a periodicidade para um valor abaixo do nível de tolerância para o objetivo de tempo de recuperação (RTO).

  2. Chame o fluxo de trabalho da aplicação lógica de verificação de estado de funcionamento na localização primária com a ação HTTP.

Também pode criar uma aplicação lógica de watchdog mais sofisticada, que após várias falhas, chama outra aplicação lógica que processa automaticamente a mudança para a localização secundária quando a primária falha.

Ativar a instância secundária

Para ativar automaticamente a instância secundária, pode criar uma aplicação lógica que chama a API de gestão, como o conector Resource Manager do Azure, para ativar as aplicações lógicas adequadas na localização secundária. Pode expandir a sua aplicação watchdog para chamar esta aplicação lógica de ativação depois de ocorrer um número específico de falhas.

Redundância entre zonas com zonas de disponibilidade

Em cada região do Azure, as zonas de disponibilidade são localizações fisicamente separadas que são tolerantes a falhas locais. Tais falhas podem ir desde falhas de software e hardware a eventos como terramotos, inundações e incêndios. Estas zonas alcançam tolerância através da redundância e isolamento lógico dos serviços do Azure.

Para fornecer resiliência e disponibilidade distribuída, existem pelo menos três zonas de disponibilidade separadas em qualquer região do Azure que suporte e ative a redundância entre zonas. A plataforma do Azure Logic Apps distribui estas zonas e cargas de trabalho de aplicações lógicas por estas zonas. Esta capacidade é um requisito fundamental para ativar arquiteturas resilientes e fornecer elevada disponibilidade se ocorrerem falhas do datacenter numa região.

Atualmente, esta capacidade é de pré-visualização e está disponível para novas aplicações lógicas de Consumo em regiões específicas. Para obter mais informações, veja a seguinte documentação:

Recolher dados de diagnóstico

Pode configurar o registo para as execuções da sua aplicação lógica e enviar os dados de diagnóstico resultantes para serviços como o Armazenamento do Azure, o Hubs de Eventos do Azure e o Log Analytics do Azure para processamento e processamento adicionais.

Passos seguintes