Continuidade dos negócios e recuperação de desastres para os Aplicativos Lógicos do Azure

  • Artigo

Para ajudar a reduzir o impacto e os efeitos que os eventos imprevisíveis têm em seus negócios e clientes, certifique-se de que você tenha uma solução de DR ( recuperação de desastres ) em vigor para que possa proteger os dados, restaurar rapidamente os recursos que dão suporte a funções comerciais críticas e manter as operações em execução para manter a continuidade dos negócios (BC). Por exemplo, as interrupções podem incluir interrupções, perdas em infraestrutura subjacente ou componentes como recursos de armazenamento, rede ou computação, falhas de aplicativos irrecuperáveis ou até mesmo uma perda completa do datacenter. Com uma solução de BCDR (continuidade de negócios e recuperação de desastre) pronta, sua empresa ou organização pode responder mais rapidamente a interrupções, planejadas ou não planejadas, além de reduzir o tempo de inatividade para seus clientes.

Este artigo fornece diretrizes e estratégias de BCDR que você pode aplicar ao criar fluxos de trabalho automatizados usando os Aplicativos Lógicos do Azure. Os fluxos de trabalho do aplicativo lógico ajudam você a integrar e orquestrar dados com mais facilidade entre aplicativos, serviços de nuvem e sistemas locais, reduzindo a quantidade de código que você precisa gravar. Ao planejar o BCDR, certifique-se de considerar não apenas seus aplicativos lógicos, mas também os recursos do Azure que você usa com eles:

Locais primários e secundários

Cada aplicativo lógico precisa especificar o local que você deseja usar para implantação, como uma região do Azure, por exemplo, "Oeste dos EUA". Essa estratégia de recuperação de desastres concentra-se na configuração do aplicativo lógico primário para fazer failover em um aplicativo lógico de backup ou em espera em um local alternativo no qual os Aplicativos Lógicos do Azure também estejam disponíveis. Dessa forma, se o primário sofrer perdas, interrupções ou falhas, o secundário poderá assumir o trabalho. Essa estratégia requer que o aplicativo lógico secundário e os recursos dependentes já estejam implantados e prontos no local alternativo.

Observação

Se seu aplicativo lógico também trabalhar com artefatos B2B, como parceiros comerciais, contratos, esquemas, mapas e certificados, que são armazenados em uma conta de integração, a conta de integração e os aplicativos lógicos deverão usar o mesmo local.

Se você seguir as boas práticas de DevOps, já estará usando os modelos do Azure Resource Manager para definir e implantar seus aplicativos lógicos e os recursos dependentes. Os modelos do Resource Manager oferecem a capacidade de usar uma única definição de implantação e, em seguida, usar arquivos de parâmetro para fornecer os valores de configuração a serem usados para cada destino de implantação. Essa capacidade significa que você pode implantar o mesmo aplicativo lógico em ambientes diferentes, por exemplo, desenvolvimento, teste e produção. Você também pode implantar o mesmo aplicativo lógico em diferentes regiões do Azure, que dão suporte a estratégias de recuperação de desastres que utilizam regiões emparelhadas.

Para a estratégia de failover, seus aplicativos lógicos e locais devem atender a esses requisitos:

  • A instância do aplicativo lógico secundária ter acesso aos mesmos aplicativos, serviços e sistemas que a instância do aplicativo lógico primária.

  • Ambas as instâncias do aplicativo lógico terem o mesmo tipo de host. Assim, ambas as instâncias são implantadas em regiões nos Aplicativos Lógicos do Azure multilocatário global ou em regiões nos Aplicativos Lógicos do Azure de locatário único. Para obter as práticas recomendadas e obter mais informações sobre regiões emparelhadas para BCDR, consulte Replicação entre regiões no Azure: Continuidade dos negócios e recuperação de desastres.

Exemplo: Azure multilocatário

Este exemplo mostra as instâncias de aplicativo lógico primária e secundária, que são implantadas para separar regiões no Azure multilocatário global para esse cenário. Um único modelo do Resource Manager define as instâncias do aplicativo lógico e os recursos dependentes exigidos por esses aplicativos lógicos. Arquivos de parâmetro separados especificam os valores de configuração a serem usados para cada local de implantação:

Instâncias de aplicativo lógico primária e secundária em locais separados

Conexões com recursos

Os Aplicativos Lógicos do Azure fornecem muitas centenas de operações de conectores que o fluxo de trabalho do aplicativo lógico pode usar para trabalhar com outros aplicativos, serviços, sistemas e outros recursos, como contas do Armazenamento do Azure, bancos de dados do SQL Server, contas de email corporativas ou de estudante e assim por diante. Se seu aplicativo lógico precisar de acesso a esses recursos, você criará conexões que autenticam o acesso a eles. Cada conexão é um recurso do Azure separado que existe em um local específico e não pode ser usado por recursos em outros locais.

Para sua estratégia de recuperação de desastres, considere os locais onde os recursos dependentes existem em relação às instâncias do aplicativo lógico:

  • A instância primária e os recursos dependentes existem em locais diferentes. Nesse caso, sua instância secundária pode se conectar aos mesmos recursos ou pontos de extremidade dependentes. No entanto, você deve criar especificamente conexões para a instância secundária. Dessa forma, se o local primário ficar indisponível, as conexões secundárias não serão afetadas.

    Por exemplo, suponha que o aplicativo lógico primário se conecte a um serviço externo, como o Salesforce. Normalmente, a disponibilidade e o local do serviço externo são independentes da disponibilidade do aplicativo lógico. Nesse caso, a instância secundária pode se conectar ao mesmo serviço, mas deve ter sua própria conexão.

  • A instância primária e os recursos dependentes existem em um mesmo local. Nesse caso, os recursos dependentes devem ter backups ou versões replicadas em um local diferente, para que a instância secundária ainda possa acessar esses recursos.

    Por exemplo, suponha que o aplicativo lógico primário se conecte a um serviço que esteja no mesmo local ou região, por exemplo, Banco de Dados SQL do Azure. Se toda a região ficar indisponível, o serviço do Banco de Dados SQL do Azure nessa região provavelmente também ficará indisponível. Nesse caso, seria bom que a instância secundária usasse um banco de dados replicado ou de backup em conjunto com uma conexão separada para esse banco de dados.

Gateway de dados local

Se seu aplicativo lógico for executado no Azure multilocatário e precisar de acesso a recursos locais, como bancos de dados do SQL Server, você precisará instalar o gateway de dados local em um computador local. Em seguida, você pode criar um recurso de gateway de dados no portal do Azure, para que o aplicativo lógico possa usar o gateway quando você criar uma conexão para o recurso.

O recurso de gateway de dados é associado a um local ou a uma região do Azure, assim como o recurso de aplicativo lógico. Na sua estratégia de recuperação de desastres, certifique-se de que o gateway de dados permaneça disponível para uso pelo o aplicativo lógico. Você pode habilitar a alta disponibilidade para o gateway quando tiver várias instalações de gateway.

Funções ativo-ativo versus ativo-passivo

Você pode configurar os locais primários e secundários para que as instâncias do aplicativo lógico nesses locais possam desempenhar essas funções:

Primária-secundária Descrição
Ativo-ativo As instâncias do aplicativo lógico primária e secundária em ambos os locais manipulam solicitações ativamente seguindo qualquer um destes padrões:

- Balanceamento de carga: você pode fazer com que ambas as instâncias escutem um ponto de extremidade e equilibre o tráfego de carga para cada instância, conforme necessário.

- Consumidores concorrentes: você pode fazer com que ambas as instâncias atuem como consumidores concorrentes, para que as instâncias concorram pelas mensagens de uma fila. Se uma instância falhar, a outra assumirá a carga de trabalho.
Ativo-passivo A instância do aplicativo lógico primário manipula ativamente toda a carga de trabalho, enquanto a instância secundária permanece passiva (desabilitada ou inativa). A secundária aguarda um sinal informando que a primária está indisponível ou não está funcionando devido à interrupção ou falha e assume a carga de trabalho como a instância ativa.
Combinação Alguns aplicativos lógicos desempenham uma função ativo-ativo, enquanto outros desempenham uma função ativo-passivo.

Exemplos de ativo-ativo

Esses exemplos mostram a configuração ativo-ativo na qual ambas as instâncias do aplicativo lógico manipulam ativamente as solicitações ou mensagens. Algum outro sistema ou serviço distribui as solicitações ou mensagens entre as instâncias, por exemplo, uma destas opções:

  • Um balanceador de carga "físico", como uma parte do hardware que roteia o tráfego

  • Um balanceador de carga "soft", como o Azure Load Balancer ou o Gerenciamento de API do Azure. Com o Gerenciamento de API, você pode especificar políticas que determinam como balancear a carga do tráfego de entrada. Ou você pode usar um serviço que dá suporte ao controle de estado, por exemplo, o Barramento de Serviço do Azure.

    Embora este exemplo mostre principalmente o Azure Load Balancer, você pode usar a opção que melhor atender às necessidades do seu cenário:

    Configuração

  • Cada instância de aplicativo lógico atua como um consumidor e ambas as instâncias concorrem pelas mensagens de uma fila:

    Configuração

Exemplos ativo-passivo

Este exemplo mostra a configuração ativo-passivo na qual a instância do aplicativo lógico primária está ativa em um local, enquanto a instância secundária permanece inativa em outro local. Se a primária sofrer uma interrupção ou falha, você poderá fazer com que um operador execute um script que ative a secundária para assumir a carga de trabalho.

Configuração

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

Este exemplo mostra uma configuração combinada na qual o local primário tem ambas as instâncias de aplicativo lógico ativo, enquanto o local secundário tem instâncias de aplicativo lógico ativo-passivo. Se o local primário sofrer uma interrupção ou falha, o aplicativo lógico ativo no local secundário, que já está manipulando uma carga de trabalho parcial, poderá assumir toda a carga de trabalho.

  • No local primário, um aplicativo lógico ativo escuta uma fila do Barramento de Serviço do Azure em busca de mensagens, enquanto outro verifica emails usando um gatilho de sondagem do Outlook do Office 365.

  • No local secundário, um aplicativo lógico ativo funciona com o aplicativo lógico no local primário ouvindo e competindo pelas mensagens da mesma fila do Barramento de Serviço. Enquanto isso, um aplicativo lógico inativo passivo aguarda em espera para verificar emails quando o local primário ficar indisponível, mas está desabilitado para evitar a releitura de emails.

Combinação

Estado e histórico do aplicativo lógico

Quando o aplicativo lógico é disparado e começa a ser executado, o estado do aplicativo é armazenado no mesmo local em que o aplicativo foi iniciado e não pode ser transferido para outro local. Se ocorrer uma falha ou interrupção, qualquer instância de fluxo de trabalho em andamento será abandonada. Quando você tem um local primário e secundário configurado, novas instâncias de fluxo de trabalho começam a ser executadas no local secundário.

Reduzir instâncias em andamento abandonadas

Para minimizar o número de instâncias de fluxo de trabalho em andamento abandonadas, você pode escolher entre vários padrões de mensagem que podem ser implementados, por exemplo:

  • Padrão de guia de roteamento fixo

    Esse padrão de mensagem empresarial que divide um processo de negócios em estágios menores. Para cada estágio, você configura um aplicativo lógico que manipula a carga de trabalho para esse estágio. Para se comunicarem entre si, seus aplicativos lógicos usam um protocolo de mensagens assíncrono, como filas ou tópicos do Barramento de Serviço do Azure. Ao dividir um processo em estágios menores, você reduz o número de processos de negócios que podem ficar presos em uma instância de aplicativo lógico com falha. Para obter mais informações gerais sobre esse padrão, consulte Padrões de integração empresarial - guia de roteamento.

    Este exemplo mostra um padrão de guia de roteamento no qual cada aplicativo lógico representa um estágio e usa uma fila do Barramento de Serviço para se comunicar com o próximo aplicativo lógico no processo.

    Dividir um processo comercial em estágios representados por aplicativos lógicos, que se comunicam entre si usando filas do Barramento de Serviço do Azure

    Se as instâncias de aplicativo lógico primária e secundária seguirem o mesmo padrão de guia de roteamento em seus locais, você poderá implementar o padrão de consumidores concorrentes configurando funções ativo-ativo para essas instâncias.

  • Padrão do Gerenciador de processos (agente)

  • Bloqueio de inspeção sem o padrão de tempo limite

Acessar o histórico de execução e gatilhos

Para obter mais informações sobre as execuções de fluxo de trabalho anteriores do aplicativo lógico, você pode examinar o gatilho do aplicativo e o histórico de execuções. O histórico de execução de um aplicativo lógico é armazenado no mesmo local ou na mesma região em que o aplicativo lógico foi executado, o que significa que não é possível migrar esse histórico para outro local. Se a instância primária fizer failover para uma instância secundária, você só poderá acessar o gatilho de cada instância e o histórico de execuções nos locais respectivos em que essas instâncias foram executadas. No entanto, você pode obter informações independentes de local sobre o histórico do aplicativo lógico, configurando seus aplicativos lógicos para enviarem eventos de diagnóstico para um espaço de trabalho do Log Analytics do Azure. Então você poderá examinar a integridade e o histórico entre aplicativos lógicos que são executados em vários locais.

Diretrizes do tipo de gatilho

O tipo de gatilho que você usa em seus aplicativos lógicos determina suas opções de como poderá configurar aplicativos lógicos entre locais na sua estratégia de recuperação de desastre. Aqui estão os tipos de gatilho disponíveis que você pode usar em aplicativos lógicos:

Gatilho de recorrência

O Gatilho de recorrência é independente de qualquer serviço ou ponto de extremidade específico e é acionado exclusivamente com base em um agendamento especificado e em nenhum outro critério, por exemplo:

  • Uma frequência fixa e um intervalo, como a cada 10 minutos
  • Um agendamento mais avançado, como a última segunda-feira de cada mês às 17h

Quando seu aplicativo lógico começa com um gatilho de recorrência, você precisa configurar suas instâncias de aplicativo lógico primária e secundária com as funções ativo-passivo. Para reduzir o RTO ( objetivo de tempo de recuperação ), que se refere à duração de destino da restauração de um processo de negócios após uma interrupção ou desastre, você pode configurar suas instâncias de aplicativo lógico com uma combinação de funções ativo-passivo e funções passivo-ativo. Nessa configuração, você divide o agendamento entre locais.

Por exemplo, suponha que você tenha um aplicativo lógico que precisa ser executado a cada 10 minutos. Você pode configurar seus aplicativos lógicos e locais para que, se o local primário ficar indisponível, o local secundário possa assumir o trabalho:

Combinação

  • No local primário, configure funções ativo-passivo para esses aplicativos lógicos:

    • Para o aplicativo lógico habilitado ativo, defina o gatilho de recorrência para começar no início da hora e repetir a cada 20 minutos, por exemplo, 9h, 9h20 e assim por diante.

    • Para o aplicativo lógico desabilitado passivo, defina o gatilho de recorrência para o mesmo agendamento, mas comece com 10 minutos após a hora e repita a cada 20 minutos, por exemplo, 9h10, 9h30 e assim por diante.

  • No local secundário, configure passivo-ativo para estes aplicativos lógicos:

    • Para o aplicativo lógico desabilitado passivo, defina o gatilho de recorrência para o mesmo agendamento do aplicativo lógico ativo no local primário, que é no início da hora e repita a cada 20 minutos, por exemplo, 9h, 9h10 e assim por diante.

    • Para o aplicativo lógico desabilitado ativo, defina o gatilho de recorrência para o mesmo agendamento do aplicativo lógico passivo no local primário, que começa 10 minutos após a hora e repita a cada 20 minutos, por exemplo, 9h10, 9h20 e assim por diante.

Agora, se ocorrer um evento de interrupção no local primário, ative o aplicativo lógico passivo no local alternativo. Dessa forma, se demorar para encontrar a falha, essa configuração limitará o número de recorrências perdidas durante esse atraso.

Gatilho de sondagem

Para verificar regularmente se novos dados para processamento estão disponíveis em um serviço ou ponto de extremidade específico, seu aplicativo lógico poderá usar um gatilho de sondagem que chame repetidamente o serviço ou o ponto de extremidade, com base em um agendamento de recorrência definido. Os dados que o serviço ou o ponto de extremidade fornece podem ter um destes tipos:

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

Para evitar a leitura repetida dos mesmos dados, seu aplicativo lógico precisa se lembrar de quais dados foram lidos anteriormente, mantendo o estado no lado do cliente ou no lado do servidor, serviço ou sistema.

  • Aplicativos lógicos que funcionam com gatilhos de uso de estado do lado do cliente que podem manter o estado.

    Por exemplo, um gatilho que lê uma nova mensagem em uma caixa de entrada de email exige que o gatilho possa se lembrar da mensagem lida mais recentemente. Dessa forma, o gatilho inicia o aplicativo lógico somente quando chega a próxima mensagem não lida.

  • Os aplicativos lógicos que funcionam com o servidor, serviço ou estado do lado do sistema usam valores de propriedade ou configurações que estão no servidor, no serviço ou no lado do sistema.

    Por exemplo, um gatilho baseado em consulta que lê uma linha de um banco de dados exige que a linha tenha uma isRead coluna definida como FALSE. Toda vez que o gatilho lê uma linha, o aplicativo lógico atualiza essa linha alterando a isRead coluna de FALSE para TRUE.

    Essa abordagem do lado do servidor funciona de forma semelhante para filas ou tópicos do Barramento de Serviço que têm semântica de enfileiramento na qual um gatilho pode ler e bloquear uma mensagem enquanto o aplicativo lógico processa a mensagem. Quando o aplicativo lógico conclui o processamento, o gatilho exclui a mensagem da fila ou do tópico.

Na perspectiva de recuperação de desastres, quando você configurar as instâncias primária e secundária do aplicativo lógico, certifique-se de considerar esses comportamentos tendo como base se o aplicativo lógico controla o estado no lado do cliente ou no lado do servidor:

  • Para um aplicativo lógico que funciona com o estado do lado do cliente, certifique-se de que seu aplicativo lógico não leia a mesma mensagem mais de uma vez. Apenas um local pode ter uma instância de aplicativo lógico ativo em qualquer momento específico. Verifique se a instância do aplicativo lógico no local alternativo está inativa ou desabilitada até que a instância primária faça failover para o local alternativo.

    Por exemplo, o gatilho do Outlook do Office 365 mantém o estado do lado do cliente e controla o carimbo de data/hora para o email lido mais recentemente, para evitar a leitura de uma duplicata.

  • Para um aplicativo lógico que funciona com o estado do lado do servidor, você pode configurar as instâncias do aplicativo lógico para reproduzir as funções ativo-ativo em que funcionam como consumidores concorrentes ou funções ativo-passivo em que a instância alternativa aguarda até que a instância primária faça failover para o local alternativo.

    Por exemplo, a leitura de uma fila de mensagens, como uma fila do Barramento de Serviço do Azure, usa o estado do lado do servidor, pois o serviço de enfileiramento mantém bloqueios nas mensagens para impedir que outros clientes leiam as mesmas mensagens.

    Observação

    Se seu aplicativo lógico precisar ler mensagens em uma ordem específica, por exemplo, em uma fila do Barramento de Serviço, você poderá usar o padrão de consumidor concorrente, mas somente quando combinado com sessões do Barramento de Serviço, que também é conhecido como o padrão de comboio sequencial. Caso contrário, você deve configurar suas instâncias de aplicativo lógico com as funções ativo-passivo.

Gatilho de solicitação

O Gatilho de solicitação faz com que o seu aplicativo lógico possa ser chamado de outros aplicativos, serviços e sistemas e é normalmente usado para fornecer esses recursos:

  • Uma API REST direta para seu aplicativo lógico que outros podem chamar

    Por exemplo, use o gatilho de solicitação para iniciar seu aplicativo lógico, para que outros aplicativos lógicos possam chamar o gatilho usando a ação Chamar o fluxo de trabalho - Aplicativos Lógicos.

  • Um webhook ou mecanismo de retorno de chamada para seu aplicativo lógico

  • Uma maneira de executar manualmente operações ou rotinas de usuário para chamar seu aplicativo lógico, por exemplo, usando um script do PowerShell que executa uma tarefa específica

Na perspectiva de recuperação de desastres, o gatilho de solicitação é um receptor passivo, porque o aplicativo lógico não realiza qualquer trabalho e aguarda até que algum outro serviço ou sistema chame explicitamente o gatilho. Como um ponto de extremidade passivo, você pode configurar suas instâncias primárias e secundárias das seguintes maneiras:

  • Ativo-ativo: ambas as instâncias manipulam ativamente solicitações ou chamadas. O chamador ou o roteador equilibra ou distribui o tráfego entre essas instâncias.

  • Ativo-passivo: somente a instância primária fica ativa e manipula todo o trabalho, enquanto a instância secundária aguarda até que a primária sofra uma interrupção ou falha. O chamador ou o roteador determina o momento de chamar a instância secundária.

Como arquitetura recomendada, você pode usar o Gerenciamento de API do Azure como um proxy para os aplicativos lógicos que usam gatilhos de solicitação. O Gerenciamento de API fornece resiliência interna entre regiões e a capacidade de rotear o tráfego entre vários pontos de extremidade.

Gatilho de webhook

Um gatilho de webhook fornece a capacidade para seu aplicativo lógico assinar um serviço passando umaURL de retorno de chamada para esse serviço. Seu aplicativo lógico pode escutar e esperar que um evento específico aconteça nesse ponto de extremidade de serviço. Quando o evento acontecer, o serviço chama o gatilho de webhook usando a URL de retorno de chamada, que então executa o aplicativo lógico. Quando habilitado, o gatilho de webhook assina o serviço. Quando desabilitado, o gatilho cancela a assinatura do serviço.

Na perspectiva de recuperação de desastre, configure as instâncias primárias e secundárias que usam gatilhos de webhook para reproduzirem funções ativo-passivo porque apenas uma instância deve receber eventos ou mensagens do ponto de extremidade assinado.

Avaliar a integridade da instância primária

Para que sua estratégia de recuperação de desastre funcione, sua solução precisa de maneiras de executar essas tarefas:

Esta seção descreve uma solução que você pode usar por completo ou como base para seu próprio design. Aqui está uma visão geral de alto nível para esta solução:

Criar aplicativo lógico de watchdog que monitora um aplicativo lógico de verificação de integridade no local primário

Verificar disponibilidade da instância primária

Para determinar se a instância primária está disponível, em execução e capaz de funcionar, você pode criar um aplicativo lógico de "verificação de integridade" que fique no mesmo local que a instância primária. Então, você pode chamar esse aplicativo de verificação de integridade de um local alternativo. Se o aplicativo de verificação de integridade responder com êxito, a infraestrutura subjacente para o serviço Aplicativos Lógicos do Azure nessa região estará disponível e funcionando. Se o aplicativo de verificação de integridade não responder, você poderá pressupor que o local não está mais íntegro.

Para essa tarefa, crie um aplicativo lógico de verificação de integridade básica que execute estas tarefas:

  1. Receber uma chamada do aplicativo de watchdog usando o gatilho de solicitação.

  2. Responder com um status que indique se o aplicativo lógico selecionado ainda funciona usando a ação de resposta.

    Importante

    O aplicativo lógico de verificação de integridade deve usar uma ação de resposta para que o aplicativo responda de forma síncrona e não assíncrona.

  3. Como opção, para melhor determinar se o local primário está íntegro, você pode considerar a integridade de qualquer outro serviço que interaja com o aplicativo lógico de destino neste local. Basta expandir o aplicativo lógico de verificação de integridade para avaliar também a integridade desses outros serviços.

Criar um aplicativo lógico de watchdog

Para monitorar a integridade da instância primária e chamar o aplicativo lógico de verificação de integridade, crie um aplicativo lógico de "watchdog" em um local alternativo. Por exemplo, se a chamada da lógica de verificação de integridade falhar, você poderá configurar o aplicativo lógico de watchdog para que ele possa enviar um alerta para sua equipe de operações investigar a falha e o motivo de a instância primária não responder.

Importante

Verifique se o aplicativo de lógica de watchdog está em um local diferente do local primário. Se os Aplicativos Lógicos do Azure no local principal apresentarem problemas, o fluxo de trabalho do seu aplicativo lógico watchdog pode não ser executado.

Para essa tarefa, no local secundário, crie um aplicativo lógico de watchdog que execute estas tarefas:

  1. Executar baseado em uma recorrência fixa ou agendada usando o gatilho de recorrência.

    Você pode definir a recorrência para um valor que esteja abaixo do nível de tolerância para seu RTO (objetivo de tempo de recuperação).

  2. Chame o fluxo de trabalho do aplicativo de lógica de verificação de integridade no local principal usando a ação HTTP.

Você também pode criar um aplicativo lógico watchdog mais sofisticado, que, após várias falhas, chama outro aplicativo lógico que lida automaticamente com a mudança para o local secundário quando o primário falha.

Ativar sua instância secundária

Para ativar automaticamente a instância secundária, você pode criar um aplicativo lógico que chama a API de gerenciamento, como o conector do Azure Resource Manager para ativar os aplicativos lógicos apropriados no local secundário. Você pode expandir seu aplicativo de watchdog para chamar esse aplicativo lógico de ativação após ocorrer um número específico de falhas.

Redundância de zona com zonas de disponibilidade

As zonas de disponibilidade do Azure são locais fisicamente separados em cada região do Azure que são tolerantes a falhas locais. Essas falhas podem variar de falhas de software e hardware a eventos como terremotos, inundações e incêndios. Essas zonas obtêm tolerância por meio da redundância e do isolamento lógico dos serviços do Azure.

Para fornecer resiliência e disponibilidade distribuída, há pelo menos três zonas de disponibilidade separadas em qualquer região do Azure que dê suporte e habilite a redundância de zona. A plataforma de Aplicativos Lógicos do Azure distribui essas zonas e as cargas de trabalho do aplicativo lógico entre elas. Essa funcionalidade é um requisito fundamental para habilitar arquiteturas resilientes e fornecer alta disponibilidade em caso de falhas de datacenter em uma região.

Atualmente, essa funcionalidade está em versão prévia e disponível para novos aplicativos lógicos de consumo em regiões específicas. Para saber mais, confira a seguinte documentação:

Coletar dados de diagnóstico

Você pode configurar o registro no log para suas execuções de aplicativo lógico e enviar os dados de diagnóstico resultantes para serviços como o Armazenamento do Azure, Hubs de Eventos do Azure e Log Analytics do Azure para manipulação e processamento adicionais.

Próximas etapas