Recuperação de desastres e geodistribuição em Durable Functions

A Microsoft esforça-se por garantir que os serviços do Azure estejam sempre disponíveis. No entanto, interrupções de serviço não planejadas podem acontecer. Quando seu aplicativo requer resiliência, você deve configurá-lo para redundância geográfica.

Você também deve ter um plano de recuperação de desastres para lidar com uma interrupção de serviço regional. Uma parte importante de um plano de recuperação de desastres está sendo preparada para fazer failover para as réplicas secundárias do seu aplicativo e da sua conta de armazenamento quando as réplicas primárias ficarem indisponíveis.

Este artigo descreve exemplos de cenários para configurar recuperação de desastres e geodistribuição utilizando a funcionalidade Durable Functions do Funções do Azure.

Descrição geral do cenário

Este artigo aborda três configurações de recuperação de desastres ativa/passiva. Escolha o cenário que corresponda à sua tolerância a falhas e aos seus requisitos de custo:

Contexto geral

No Durable Functions, todo o estado é mantido num backend de armazenamento, como o Durable Task Scheduler, Armazenamento do Azure ou uma base de dados do SQL Server. Um hub de tarefas é um contentor lógico para os recursos de armazenamento usados para orquestrações e entidades. As funções de orquestrador, atividade e entidade podem interagir entre si somente quando pertencem ao mesmo hub de tarefas. Este artigo refere-se aos centros de tarefas ao descrever cenários para manter estes recursos de armazenamento altamente disponíveis.

Orquestrações e entidades podem ser acionadas via funções cliente que são ativadas via HTTP ou outro dos tipos de gatilho Funções do Azure suportados. Orquestrações e entidades também podem ser acionadas por meio de APIs HTTP integradas. Para simplificar, este artigo foca-se em cenários que envolvem disparadores de funções baseados no Armazenamento do Azure e em HTTP, juntamente com opções para aumentar a disponibilidade e minimizar o tempo de inatividade durante a recuperação de desastres. Este artigo não aborda explicitamente outros tipos de gatilhos, como os gatilhos do Azure Service Bus ou do Azure Cosmos DB.

Os cenários deste artigo baseiam-se em configurações ativas/passivas, que melhor suportam a utilização do Armazenamento do Azure. Esse padrão consiste na implantação de um aplicativo de função de backup (passivo) em uma região diferente. Gestor de Tráfego do Azure monitoriza a aplicação principal (ativa) para a disponibilidade de HTTP. Ele realiza o failover para a aplicação de função de backup quando a aplicação principal falha. Para obter mais informações, consulte Método de roteamento de tráfego prioritário.

Considerações gerais

Tenha estas considerações em mente ao configurar uma configuração de failover ativo/passivo para Durable Functions:

• Este artigo parte do princípio de que está a usar o fornecedor Armazenamento do Azure para armazenar o estado de execução do Durable Functions. Também pode configurar fornecedores de armazenamento alternativos que armazenem o estado noutros locais, como numa base de dados do SQL Server. Provedores de armazenamento alternativos podem exigir diferentes estratégias de recuperação de desastres e distribuição geográfica. Para mais informações, consulte fornecedores de armazenamento do Durable Functions.
• A configuração ativa/passiva proposta garante que um cliente possa sempre acionar novas orquestrações via HTTP. No entanto, quando dois aplicativos de função compartilham o mesmo hub de tarefas no armazenamento, algumas transações de armazenamento em segundo plano podem ser distribuídas entre os aplicativos. Como resultado dessa distribuição, essa configuração pode resultar em custos adicionais de saída para o aplicativo de função secundária.
• A conta de armazenamento subjacente e o hub de tarefas são criados na região primária. Os aplicativos de função compartilham essa conta de armazenamento e hub de tarefas.
• Todos os aplicativos de função implantados de forma redundante devem compartilhar as mesmas teclas de acesso de função quando são ativados via HTTP. O runtime do Funções do Azure expõe uma API de gestão que pode usar para adicionar, eliminar e atualizar programaticamente chaves de função. Também pode gerir chaves usando APIs Azure Resource Manager.

Cenário 1: Computação com balanceamento de carga com armazenamento compartilhado

Para reduzir a possibilidade de tempo de inatividade se os recursos do aplicativo de função ficarem indisponíveis, esse cenário usa dois aplicativos de função implantados em regiões diferentes. Recomendamos esse cenário como uma solução para failovers.

O Gerenciador de Tráfego está configurado para detetar problemas no aplicativo de função principal e redirecionar automaticamente o tráfego para o aplicativo de função na região secundária. Esta aplicação de funções partilha a mesma conta do Armazenamento do Azure e o mesmo hub de tarefas. O estado dos aplicativos de função não é perdido e o trabalho pode ser retomado normalmente. Depois de a saúde ser restaurada na região principal, o Gestor de Tráfego do Azure começa a encaminhar automaticamente os pedidos para essa aplicação funcional.

Há vários benefícios em usar esse cenário de implantação:

• Se a infraestrutura de computação falhar, o trabalho poderá ser retomado na região de failover sem perda de dados.
• O Gerenciador de Tráfego cuida do failover automático para o aplicativo de função íntegro.
• O Gestor de Tráfego restabelece automaticamente o tráfego para a aplicação de função principal após o fim da interrupção.

Considerações específicas do cenário

• Se implementar a aplicação de função usando um plano dedicado do Serviço de Aplicações do Azure, replicar a infraestrutura de computação no datacenter de failover aumenta os custos.

• Esse cenário cobre interrupções na infraestrutura de computação, mas a conta de armazenamento continua a ser o único ponto de falha para o aplicativo de função. Se ocorrer uma falha no Armazenamento do Azure, a aplicação sofre de inatividade.

• Se o aplicativo de função for submetido a failover, a latência aumenta porque o aplicativo acessa sua conta de armazenamento entre regiões.

• Quando a aplicação de funções está em modo de failover, ela acede ao serviço de armazenamento na região original. O tráfego de saída da rede pode resultar em custos mais elevados.

• Este cenário depende do Gestor de Tráfego. Uma aplicação cliente pode demorar algum tempo antes de precisar solicitar novamente o endereço da aplicação de funções ao Gerenciador de Tráfego. Para obter mais informações, consulte Como funciona o Gerenciador de Tráfego.

• A partir da versão 2.3.0 da extensão Durable Functions, pode executar em segurança duas aplicações de funções ao mesmo tempo com a mesma conta de armazenamento e configuração do hub de tarefas. A primeira aplicação a iniciar adquire um blob lease ao nível da aplicação que impede outras aplicações de processarem mensagens das filas do hub de tarefas. Se esse primeiro aplicativo parar de ser executado, sua concessão expirará. Um segundo aplicativo pode adquirir a concessão e começar a processar mensagens do hub de tarefas.

  Para versões de extensão anteriores à 2.3.0, os aplicativos de função configurados para usar a mesma conta de armazenamento processam mensagens e atualizam artefatos de armazenamento simultaneamente. Esta atividade simultânea resulta em latências gerais e custos de saída mais elevados. Se os aplicativos primários e de réplica tiverem códigos diferentes implantados neles, mesmo temporariamente, as orquestrações também poderão falhar na execução correta devido a inconsistências na função do orquestrador nos dois aplicativos.

  Todas as aplicações que necessitem de geodistribuição para recuperação de desastres devem usar a versão 2.3.0 ou posterior da extensão Durable Functions.

Cenário 2: Computação balanceada de carga com armazenamento regional

O cenário anterior cobre apenas falhas limitadas à infraestrutura de computação. Pode também ocorrer uma falha da aplicação de funções quando o serviço de armazenamento ou o Planificador de Tarefas Duráveis falham.

Para garantir o funcionamento contínuo das Durable Functions, o segundo cenário implementa uma conta de armazenamento dedicada ou Durable Task Scheduler em cada região onde as aplicações de funções estão alojadas. Atualmente recomendamos esta abordagem de recuperação de desastres quando estiver a usar o Durable Task Scheduler.

Essa abordagem adiciona melhorias ao cenário anterior:

• Isolamento de estado regional: Cada aplicação de função está ligada à sua própria conta regional de armazenamento ou ao Durable Task Scheduler. Se o aplicativo de função falhar, o Gerenciador de Tráfego redirecionará o tráfego para a região secundária. Como a aplicação de funções em cada região utiliza o seu armazenamento local ou Durable Task Scheduler, as Durable Functions podem continuar a processar usando o estado local.
• Sem latência adicional no failover: Durante um failover, uma aplicação de funções e um fornecedor de estado (conta de armazenamento ou Durable Task Scheduler) estão co-localizados, pelo que não há latência adicional na região de failover.
• Resiliência a falhas no suporte de backend: Se a conta de armazenamento ou o Planificador de Tarefas Duráveis numa região falharem, o Durable Functions falha nessa região. A falha das Durable Functions desencadeia o desvio para a região secundária. Como tanto o estado de computação como o estado da aplicação estão isolados por região, as Durable Functions na região de failover mantêm-se operacionais.

Considerações específicas do cenário

• Se você implantar a aplicação de funções usando um plano dedicado do Serviço de Aplicativo, reproduzir a infraestrutura de computação no datacenter de failover aumentará os custos.
• O estado atual não sofreu failover. As orquestrações e entidades existentes são efetivamente pausadas e indisponíveis até que a região primária se recupere. Se essa compensação para preservar a latência e minimizar os custos de saída é aceitável depende dos requisitos do aplicativo.
• Se estiver a usar o Durable Task Scheduler, considere configurar endpoints privados para isolamento de rede entre a sua aplicação de funções e o agendador regional.

Cenário 3: Computação com balanceamento de carga com GRS compartilhado

Este cenário é uma modificação do primeiro cenário (implementação de uma conta de armazenamento compartilhado). A principal diferença é que a conta de armazenamento é criada com a replicação geográfica habilitada.

Esse cenário oferece as mesmas vantagens funcionais do primeiro cenário, mas também permite outras vantagens de recuperação de dados:

• O armazenamento com redundância geográfica (GRS) e o armazenamento geográfico de acesso de leitura (RA-GRS) maximizam a disponibilidade da sua conta de armazenamento.
• Se houver uma falha regional no serviço Armazenamento do Azure, pode iniciar manualmente um failover para a réplica secundária. Em circunstâncias extremas em que uma região é perdida devido a um desastre, a Microsoft pode iniciar um failover regional. Neste caso, você não precisa tomar nenhuma medida.
• Quando ocorre um failover, o estado das Durable Functions é preservado até à última replicação da conta de armazenamento. A replicação normalmente ocorre a cada poucos minutos.

Para obter mais informações, consulte Planeamento da recuperação de desastres e failover do armazenamento do Azure.

Considerações específicas do cenário

• Um failover para a réplica pode levar algum tempo. Até que o failover termine e os registos DNS do Armazenamento do Azure sejam atualizados, a aplicação de funções continua inacessível.
• Há um custo maior para o uso de contas de armazenamento replicadas geograficamente.
• A replicação GRS copia seus dados de forma assíncrona. Algumas das transações mais recentes podem ser perdidas devido à latência do processo de replicação.
• Como descrito no primeiro cenário, recomendamos que as aplicações de funções implementadas nesta estratégia utilizem a versão 2.3.0 ou posterior da extensão Durable Functions.

Conteúdo relacionado

• Design de aplicações altamente disponíveis com Armazenamento do Azure
• Provedores de armazenamento do Durable Functions
• Visão geral do Agendador de Tarefas Durável
• Gestor de Tráfego do Azure visão geral
• Planeamento e failover de recuperação de desastres do Armazenamento do Azure