Confiabilidade no Azure Functions

Este artigo descreve o suporte à confiabilidade no Azure Functions e aborda a resiliência intra-regional com zonas de disponibilidade e recuperação entre regiões e continuidade dos negócios. Para obter uma visão geral mais detalhada dos princípios de confiabilidade no Azure, confira Confiabilidade do Azure.

O suporte à zona de disponibilidade para o Azure Functions está disponível nos planos Premium (Elástico Premium) e Dedicado (Serviço de Aplicativo). Este artigo enfatiza o suporte à redundância de zona para planos Premium. Para redundância de zona em Planos dedicados, consulte Migrar o Serviço de Aplicativo para o suporte à zona de disponibilidade.

Suporte à zona de disponibilidade

As zonas de disponibilidade do Azure são pelo menos três grupos de datacenters separados fisicamente em cada região do Azure. Os datacenters dentro de cada zona são equipados com energia, resfriamento e infraestrutura de rede independentes. Em caso de falha de uma zona local, as zonas de disponibilidade foram projetadas de modo que, se uma zona é afetada, os serviços regionais, a capacidade e a alta disponibilidade têm suporte nas duas zonas restantes.

As falhas podem variar de falhas de software e hardware a eventos como terremotos, inundações e incêndios. A tolerância a falhas é obtida devido à redundância e ao isolamento lógico dos serviços do Azure. Para obter informações detalhadas sobre as zonas de disponibilidade no Azure, confira Regiões e zonas de disponibilidade.

Os serviços habilitados para zonas de disponibilidade do Azure foram projetados para fornecer o nível ideal de resiliência e flexibilidade. Eles podem ser configurados de duas maneiras. Eles podem ter redundância de zona, com replicação automática entre zonas, ou podem ser zonais, com instâncias fixadas em uma zona específica. Você também pode combinar essas abordagens. Para obter mais informações sobre a arquitetura zonal versus com redundância de zona, confira Recomendações para usar zonas e regiões de disponibilidade.

O Azure Functions dá suporte a uma implantação com redundância de zona.

Quando você configura o Functions para ter redundância de zona, a plataforma espalha automaticamente as instâncias de aplicativo de funções em três zonas na região selecionada.

A distribuição de instâncias com uma implantação com redundância de zona é determinada com base nas seguintes regras, mesmo quando o aplicativo é reduzido ou escalado horizontalmente:

• A contagem mínima de instâncias do aplicativo de funções é três.
• Quando você especifica uma capacidade maior que três, as instâncias são distribuídas uniformemente somente quando a capacidade é um múltiplo de 3.
• Para um valor de capacidade superior a 3*N, instâncias extras são distribuídas por uma ou duas zonas restantes.

Disponibilidade regional

Os planos Premium com redundância de zona estão disponíveis nas seguintes regiões:

Pré-requisitos

O suporte a zonas de disponibilidade é uma propriedade do plano Premium. Estes são os requisitos e as limitações atuais para a habilitação das zonas de disponibilidade:

• Você só pode habilitar zonas de disponibilidade ao criar um plano Premium para o aplicativo de funções. Você não pode converter um plano Premium existente para usar zonas de disponibilidade.
• Você deve usar uma conta de armazenamento com redundância de zona para a conta de armazenamento do aplicativo de funções. Se você usar um tipo diferente de conta de armazenamento, o Functions poderá apresentar um comportamento inesperado durante uma interrupção de zona.
• Há suporte para os aplicativos Windows e Linux.
• Deve ser hospedado em um plano de hospedagem Elástico Premium ou Dedicado. Para saber como usar a redundância de zona com um plano Dedicado, confira Migrar o Serviço de Aplicativo para o suporte à zona de disponibilidade.
  • No momento, o suporte à zona de disponibilidade não está disponível para aplicativos de funções em planos de Consumo.
• Os aplicativos de funções hospedados em um plano Premium precisam ter uma contagem mínima de três instâncias sempre prontas.
  • A plataforma vai impor essa contagem mínima em segundo plano se você especificar uma contagem de instâncias menor que três.
• Se você não estiver usando o plano Premium ou uma unidade de escala que dê suporte a zonas de disponibilidade, se estiver em uma região sem suporte ou se estiver em dúvida, confira as diretrizes sobre migração.

Preços

Não há nenhum custo extra associado à habilitação de zonas de disponibilidade. O preço de um plano do Serviço de Aplicativo Premium com redundância de zona é igual ao preço de um plano Premium de zona única. Para cada plano do Serviço de Aplicativo usado, você será cobrado com base no SKU escolhido, na capacidade especificada e em quaisquer instâncias dimensionadas de acordo com seus critérios de dimensionamento automático. Se você habilitar zonas de disponibilidade, mas especificar uma capacidade inferior a três para um plano do Serviço de Aplicativo, a plataforma vai impor uma contagem mínima de três instâncias para esse plano do Serviço de Aplicativo e vai cobrar você por essas três instâncias.

Criar um plano Premium com redundância de zona e um aplicativo de funções

No momento, há duas maneiras de implantar um plano Premium com redundância de zona e um aplicativo de funções. Você pode usar o portal do Azure ou um modelo do ARM.

"resources": [
    {
        "type": "Microsoft.Web/serverfarms",
        "apiVersion": "2021-01-15",
        "name": "<YOUR_PLAN_NAME>",
        "location": "<YOUR_REGION_NAME>",
        "sku": {
            "name": "EP1",
            "tier": "ElasticPremium",
            "size": "EP1",
            "family": "EP", 
            "capacity": 3
        },
        "kind": "elastic",
        "properties": {
            "perSiteScaling": false,
            "elasticScaleEnabled": true,
            "maximumElasticWorkerCount": 20,
            "isSpot": false,
            "reserved": false,
            "isXenon": false,
            "hyperV": false,
            "targetWorkerCount": 0,
            "targetWorkerSizeId": 0, 
            "zoneRedundant": true
        }
    }
]

Depois que o plano com redundância de zona for criado e implantado, qualquer aplicativo de funções hospedado em seu novo plano será considerado com redundância de zona.

Migração da zona de disponibilidade

Atualmente, os aplicativos de funções do Azure não dão suporte à migração no local de instâncias de aplicativos de funções existentes. Para obter informações de como migrar o plano Premium multilocatário público do suporte sem zona de disponibilidade para suporte com zona de disponibilidade, confira Migrar o Serviço de Aplicativo para o suporte com zona de disponibilidade.

Experiência de zona inoperante

Todas as instâncias de aplicativos de funções disponíveis de aplicativos de funções com redundância de zona estão habilitadas e processando eventos. Quando uma zona falha, o Functions detecta as instâncias perdidas e tenta localizar automaticamente as novas instâncias de substituição, se necessário. O comportamento de escala elástica ainda se aplica. No entanto, em um cenário de zona inoperante, não há garantia de que as solicitações para instâncias adicionais terão sucesso, pois há um esforço de retornar às instâncias perdidas. Os aplicativos implantados em um plano Premium habilitado para uma zona de disponibilidade continuarão sendo executados mesmo que outras zonas na mesma região sofram interrupção. No entanto, é possível que comportamentos que não sejam de tempo de execução ainda sejam afetados por uma interrupção em outras zonas de disponibilidade. Esses comportamentos podem incluir dimensionamento do plano Premium, criação de aplicativos, configuração de aplicativos e publicação de aplicativos. A redundância de zona para os planos Premium garante apenas o tempo de atividade contínuo para aplicativos implantados.

Quando o Functions aloca instâncias para um plano Premium com redundância de zona, ele usa o melhor balanceamento de zona possível oferecido pelos conjuntos de dimensionamento de máquinas virtuais do Azure subjacentes. Um plano Premium é considerado balanceado quando cada zona tem o mesmo número de VMs (± 1 VM) em todas as outras zonas usadas pelo plano Premium.

Recuperação de desastre entre regiões e continuidade dos negócios

A DR (recuperação de desastre) trata da recuperação após eventos de alto impacto, como desastres naturais ou implantações com falha, que resultam em tempo de inatividade e perda de dados. Seja qual for a causa, a melhor solução para um desastre é um plano de DR bem definido e testado e um design de aplicativo que dê suporte ativo à DR. Antes de começar a pensar em criar seu plano de recuperação de desastre, confira Recomendações para criar uma estratégia de recuperação de desastre.

Quando o assunto é DR, a Microsoft usa o modelo de responsabilidade compartilhada. Em um modelo de responsabilidade compartilhada, a Microsoft garante que a infraestrutura de linha de base e os serviços de plataforma estejam disponíveis. Ao mesmo tempo, muitos serviços do Azure não replicam dados automaticamente nem retornam de uma região com falha para a replicação cruzada em outra região habilitada. Para esses serviços, você é responsável por configurar um plano de recuperação de desastre que funcione para sua carga de trabalho. A maioria dos serviços executados nas ofertas de PaaS (plataforma como serviço) do Azure fornece recursos e diretrizes para dar suporte à DR. Além disso, você pode usar recursos específicos do serviço para dar suporte a uma recuperação rápida, a fim de ajudar a desenvolver seu plano de DR.

Esta seção explica algumas das estratégias que você pode usar para implantar o Functions para permitir a recuperação de desastre.

Para recuperação de desastre para o Durable Functions, confira Recuperação de desastre e distribuição geográfica no Azure Durable Functions.

Recuperação de desastre de várias regiões

Como não há nenhuma redundância interna disponível, as funções são executadas em um aplicativo de funções em uma região específica do Azure. Para evitar a perda de execução durante interrupções, você pode implantar de forma redundante as mesmas funções para aplicativos de funções em várias regiões. Para saber mais sobre implantações em várias regiões, confira as diretrizes em Aplicativo Web de várias regiões altamente disponível.

Quando você executa o mesmo código de função em várias regiões, há dois padrões a serem considerados, ativo-ativo e ativo-passivo.

Padrão ativo-ativo para funções de gatilho HTTP

Com um padrão ativo-ativo, as funções em ambas as regiões estão em execução ativa e processando eventos, seja de maneira duplicada ou em rotação. É recomendável que você use um padrão ativo-ativo em combinação com Azure Front Door para suas funções críticas disparadas por HTTP, que podem rotear e fazer uma distribuição equilibrada de solicitações HTTP entre funções em execução em várias regiões. O front door também pode verificar periodicamente a integridade de cada ponto de extremidade. Quando uma função em uma região para de responder às verificações de integridade, a Azure Front Door a retira da rotação e só encaminha o tráfego para as funções íntegras restantes.

Padrão ativo-passivo para funções de gatilho não HTTPS

É recomendável que você use o padrão ativo-passivo para suas funções de gatilho não HTTP acionadas por eventos, como Barramento de Serviço e funções de gatilho dos Hubs de Eventos.

Para criar redundância em funções de gatilho não HTTP, use o padrão ativo-passivo. Com um padrão ativo-passivo, as funções são executadas ativamente na região que está recebendo eventos, enquanto as mesmas funções em uma segunda região permanecem ociosas. O padrão ativo-passivo oferece apenas uma função para processar cada mensagem enquanto fornece um mecanismo de failover para a região secundária em um desastre. Os aplicativos de funções funcionam com os comportamentos de failover dos serviços de parceiros, como o recuperação geográfica do Barramento de Serviço e a recuperação geográfica dos Hubs de Eventos do Azure.

Considere uma topologia de exemplo usando um gatilho de Hubs de Eventos do Azure. Nesse caso, o padrão ativo/passivo requer o envolvimento dos seguintes componentes:

• Hubs de Eventos do Azure implantados nas regiões primária e secundária.
• Desastre geográfico habilitado para emparelhar os hubs de eventos primário e secundário. Isso também cria um alias que você pode usar para se conectar aos Hubs de Eventos e trocar do primário para o secundário sem alterar as informações de conexão.
• Os aplicativos de funções são implantados na região primária e secundária (failover), com o aplicativo na região secundária, essencialmente ocioso, porque as mensagens não estão sendo enviadas lá.
• O aplicativo de funções dispara na cadeia de conexão direta (sem alias) do respectivo Hub de Eventos.
• Os editores do Hub de Eventos devem publicar na cadeia de conexão do alias.

Antes do failover, os publicadores que enviarem ao alias compartilhado encaminham para o Hub de Eventos primário. O aplicativo de funções primário está ouvindo exclusivamente o Hub de Eventos primário. O aplicativo de funções secundário é passivo e ocioso. Assim que o failover for iniciado, os publicadores que enviarem ao alias compartilhado são encaminhados para o Hub de Eventos secundário. O aplicativo de funções secundário agora fica ativo e começa a disparar automaticamente. O failover efetivo para a região secundária pode ser totalmente controlado pelo hub de eventos. As funções são ativadas apenas quando o respectivo hub de eventos é ativado.

Leia mais sobre informações e considerações sobre failover com o Barramento de Serviço e os Hubs de Eventos.

Próximas etapas

• Recuperação de desastre e distribuição geográfica nas Azure Durable Functions
• Criar o Azure Front Door
• Considerações sobre failover do Hubs de Eventos
• Guia do Centro de Arquitetura do Azure sobre zonas de disponibilidade
• Confiabilidade no Azure