Fiabilidade no Azure Functions

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

O suporte à zona de disponibilidade para o Azure Functions está disponível nos planos Premium (Elastic Premium) e Dedicado (Serviço de Aplicativo). Este artigo se concentra no suporte de 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 fisicamente separados de datacenters em cada região do Azure. Os datacenters dentro de cada zona são equipados com infraestrutura independente de energia, resfriamento e rede. No caso de uma falha de zona local, as zonas de disponibilidade são projetadas de modo que, se uma zona for afetada, os serviços regionais, a capacidade e a alta disponibilidade sejam suportados pelas 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 é alcançada com redundância e isolamento lógico dos serviços do Azure. Para obter informações mais detalhadas sobre zonas de disponibilidade no Azure, consulte Regiões e zonas de disponibilidade.

Os serviços habilitados para zonas de disponibilidade do Azure são projetados para fornecer o nível certo de confiabilidade e flexibilidade. Eles podem ser configurados de duas maneiras. Eles podem ser redundantes de zona, com replicação automática entre zonas, ou zonais, com instâncias fixadas a uma zona específica. Você também pode combinar essas abordagens. Para obter mais informações sobre arquitetura zonal versus arquitetura com redundância de zona, consulte 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 como zona redundante, a plataforma distribui automaticamente as instâncias do aplicativo de função por três zonas na região selecionada.

A distribuição de instâncias com uma implantação redundante de zona é determinada dentro das seguintes regras, mesmo quando o aplicativo é dimensionado para dentro e para fora:

• A contagem mínima de instâncias do aplicativo de função é 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, as instâncias extras são distribuídas pelas zonas restantes.

Disponibilidade regional

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

Pré-requisitos

O suporte da zona de disponibilidade é uma propriedade do plano Premium. A seguir estão os requisitos/limitações atuais para habilitar zonas de disponibilidade:

• Você só pode habilitar zonas de disponibilidade ao criar um plano Premium para seu aplicativo funcional. Não é possível converter um plano Premium existente para usar zonas de disponibilidade.
• Você deve usar uma conta de armazenamento redundante de zona (ZRS) para a conta de armazenamento do seu aplicativo de função. Se você usar um tipo diferente de conta de armazenamento, o Functions poderá mostrar um comportamento inesperado durante uma interrupção zonal.
• Tanto o Windows como o Linux são suportados.
• Deve ser hospedado em um plano de hospedagem Elastic Premium ou dedicado. Para saber como usar a redundância de zona com um plano Dedicado, consulte Migrar o Serviço de Aplicativo para o suporte à zona de disponibilidade.
  • O suporte à zona de disponibilidade não está atualmente disponível para aplicações funcionais nos planos de consumo .
• Os aplicativos de função hospedados em um plano Premium devem ter uma contagem mínima de instâncias sempre prontas de três.
  • A plataforma impõe essa contagem mínima nos bastidores se você especificar uma contagem de instâncias inferior a três.
• Se você não estiver usando o plano Premium ou uma unidade de escala que ofereça suporte a zonas de disponibilidade, estiver em uma região sem suporte ou não tiver certeza, consulte as diretrizes de migração.

Preços

Não há nenhum custo extra associado à ativação de zonas de disponibilidade. O preço de um plano Premium do Serviço de Aplicativo Premium redundante de zona é o mesmo de um plano Premium de zona única. Para cada plano do Serviço de Aplicativo que você usa, você é cobrado com base na SKU escolhida, na capacidade especificada e em todas as instâncias para as quais você dimensiona com base em 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 imporá uma contagem mínima de instâncias de três para esse plano do Serviço de Aplicativo e cobrará por essas três instâncias.

Criar um plano Premium com redundância de zona e uma aplicação funcional

Atualmente, há duas maneiras de implantar um plano Premium com redundância de zona e um aplicativo funcional. Você pode usar o portal do Azure ou um modelo 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 é criado e implantado, qualquer aplicativo de função hospedado em seu novo plano é considerado redundante de zona.

Migração da zona de disponibilidade

Atualmente, os Aplicativos de Função do Azure não oferecem suporte à migração in-loco de instâncias de aplicativos de função existentes. Para obter informações sobre como migrar o plano Premium multilocatário público da zona de indisponibilidade para o suporte à zona de disponibilidade, consulte Migrar o Serviço de Aplicativo para o suporte à zona de disponibilidade.

Experiência de zoneamento

Todas as instâncias de aplicativos de função disponíveis de aplicativos de função com redundância de zona são habilitadas e processam eventos. Quando uma zona fica inativa, o Functions deteta instâncias perdidas e tenta encontrar automaticamente novas instâncias de substituição, se necessário. O comportamento da escala elástica ainda se aplica. No entanto, em um cenário de zone-down, não há garantia de que as solicitações de instâncias adicionais possam ser bem-sucedidas, uma vez que o preenchimento de instâncias perdidas ocorre com base no melhor esforço. Os aplicativos implantados em uma zona de disponibilidade habilitada para o plano Premium continuam a ser executados mesmo quando outras zonas na mesma região sofrem uma interrupção. No entanto, é possível que comportamentos sem tempo de execução ainda possam ser afetados por uma interrupção em outras zonas de disponibilidade. Esses comportamentos afetados podem incluir o dimensionamento do plano Premium, a criação de aplicativos, a configuração de aplicativos e a publicação de aplicativos. A redundância de zona para planos Premium garante apenas um tempo de atividade contínuo para aplicativos implantados.

Quando o Functions aloca instâncias a um plano Premium redundante de zona, ele usa o melhor balanceamento de zona de esforço oferecido pelos Conjuntos de Escala de Máquina Virtual do Azure subjacentes. Um plano Premium é considerado equilibrado quando cada zona tem o mesmo número de VMs (± 1 VM) em todas as outras zonas usadas pelo plano Premium.

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

A recuperação de desastres (DR) consiste na recuperação de eventos de alto impacto, como desastres naturais ou implantações com falha que resultam em tempo de inatividade e perda de dados. Independentemente da causa, a melhor solução para um desastre é um plano de DR bem definido e testado e um design de aplicativo que suporte ativamente a DR. Antes de começar a pensar em criar seu plano de recuperação de desastres, consulte Recomendações para projetar uma estratégia de recuperação de desastres.

Quando se trata de 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 da plataforma estejam disponíveis. Ao mesmo tempo, muitos serviços do Azure não replicam dados automaticamente ou recorrem de uma região com falha para replicação cruzada para outra região habilitada. Para esses serviços, você é responsável por configurar um plano de recuperação de desastres que funcione para sua carga de trabalho. A maioria dos serviços executados nas ofertas de plataforma como serviço (PaaS) do Azure fornecem recursos e orientação para dar suporte à DR e você pode usar recursos específicos do serviço para dar suporte à recuperação rápida para 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 desastres.

Para recuperação de desastres para funções duráveis, consulte Recuperação de desastres e distribuição geográfica no Azure Durable Functions.

Recuperação de desastres em várias regiões

Como não há redundância interna disponível, as funções são executadas em um aplicativo de função em uma região específica do Azure. Para evitar a perda de execução durante interrupções, você pode implantar redundantemente as mesmas funções para aplicativos funcionais em várias regiões. Para saber mais sobre implantações de várias regiões, consulte as orientações em Aplicativo Web multirregião 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 ativamente executando e processando eventos, seja de forma duplicada ou em rotação. É recomendável que você use um padrão ativo-ativo em combinação com o Azure Front Door para suas funções críticas acionadas por HTTP, que podem rotear e round-robin solicitações HTTP entre funções em execução em várias regiões. A porta da frente também pode verificar periodicamente a integridade de cada ponto final. Quando uma função em uma região para de responder a verificações de integridade, o Azure Front Door a tira da rotação e só encaminha o tráfego para as funções saudáveis restantes.

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

É recomendável usar o padrão ativo-passivo para suas funções acionadas não HTTP orientadas a eventos, como funções acionadas pelo Service Bus e Hubs de Eventos.

Para criar redundância para funções de gatilho não-HTTP, use um 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 fornece uma maneira para apenas uma única função processar cada mensagem, enquanto fornece um mecanismo para failover para a região secundária em um desastre. Os aplicativos de função funcionam com os comportamentos de failover dos serviços de parceiros, como a recuperação geográfica do Barramento de Serviço do Azure e a recuperação geográfica dos Hubs de Eventos do Azure.

Considere um exemplo de topologia usando um gatilho de Hubs de Eventos do Azure. Neste caso, o padrão ativo/passivo requer envolver os seguintes componentes:

• Hubs de Eventos do Azure implantados em uma região primária e secundária.
• Desastre geográfico habilitado para emparelhar os hubs de eventos primários e secundários. Isso também cria um alias que você pode usar para se conectar a hubs de eventos e alternar de primário para secundário sem alterar as informações de conexão.
• Os aplicativos de função 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 para lá.
• O aplicativo de função é acionado na cadeia de conexão direta (sem alias) para seu respetivo hub de eventos.
• Os editores do hub de eventos devem publicar na cadeia de conexão de alias.

Antes do failover, os editores enviam para a rota de alias compartilhada para o hub de eventos principal. O aplicativo de função principal está ouvindo exclusivamente o hub de eventos principal. O aplicativo de função secundária é passivo e ocioso. Assim que o failover é iniciado, os editores que enviam para o alias compartilhado são roteados para o hub de eventos secundário. O aplicativo de função secundária agora fica ativo e começa a ser acionado automaticamente. O failover efetivo para uma região secundária pode ser conduzido inteiramente a partir do hub de eventos, com as funções ficando ativas somente quando o respetivo hub de eventos estiver ativo.

Leia mais sobre informações e considerações para failover com Service Bus e Hubs de Eventos.

Próximos passos

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