Compartilhar via


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 a zonas de disponibilidade para o Azure Functions depende do plano de hospedagem do Functions:

Plano de hospedagem Nível de suporte Para obter mais informações...
Plano de Consumo Flexível GA Selecione Consumo Flexível na parte superior deste artigo.
Plano Elastic Premium GA Selecione Premium na parte superior deste artigo.
Plano dedicado (Serviço de Aplicativo) GA Consulte Confiabilidade no Serviço de Aplicativo do Azure.
Plano de Consumo Não disponível Não há suporte para o plano de Consumo.

As zonas de disponibilidade são grupos fisicamente separados de datacenters em cada região do Azure. Quando uma zona falha, os serviços podem passar para uma das zonas restantes.

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

Suporte a zonas de disponibilidade

Quando você configura aplicativos do plano de Consumo Flex como redundantes de zona, a plataforma automaticamente distribui instâncias do seu aplicativo de funções entre as zonas da região selecionada, com métricas diferentes para instâncias sempre prontas em comparação às instâncias sob demanda.

Quando a redundância de zona é habilitada em um plano de Consumo Flex, a distribuição de instâncias é determinada de acordo com as seguintes regras:

  • Instâncias Sempre prontas são distribuídas por pelo menos duas zonas de forma round-robin.
  • As instâncias sob demanda, que são criadas como resultado dos volumes de origem de eventos à medida que o aplicativo é escalado além de Sempre prontas, são distribuídas entre as zonas de disponibilidade com base no melhor esforço. Isso significa que, para instâncias sob demanda, prioriza-se a expansão mais rápida em vez de uma distribuição uniforme entre zonas de disponibilidade. A plataforma tenta fazer a distribuição uniforme ao longo do tempo.
  • Para garantir a resiliência de zona com zonas de disponibilidade, a plataforma mantém automaticamente pelo menos duas instâncias sempre prontas para cada função ou grupo de dimensionamento por função, independentemente da configuração sempre pronta para o aplicativo. Todas as instâncias criadas pela plataforma são gerenciadas pela plataforma, cobradas como instâncias sempre prontas e não alteram as configurações sempre prontas.

Quando você configura os planos do aplicativo de funções Elastic Premium com redundância de zona, a plataforma distribui automaticamente as instâncias do aplicativo de funções pelas 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 é duas.
  • Quando você especifica uma capacidade maior que o número de zonas, as instâncias são distribuídas uniformemente somente quando a capacidade é um múltiplo do número de zonas.
  • Para um valor de capacidade maior que Número de Zonas * Número de instâncias, instâncias extras são distribuídas entre as zonas restantes.

Importante

O Azure Functions pode ser executado na plataforma do Serviço de Aplicativo do Azure. Na plataforma App Service, os planos que hospedam aplicativos de funções do plano Premium são chamados de planos Elastic Premium, com nomes de SKU como EP1. Se você optar por executar seu aplicativo de funções em um plano Premium, crie um plano com um nome de SKU que comece com E, como EP1. Os nomes de SKU do plano do Serviço de Aplicativo que começam com P, como P1V2 (plano Premium V2 Small), são planos de hospedagem dedicados. Como eles são Dedicados e não Elástico Premium, os planos com os nomes de SKU que começam com P não são escalados dinamicamente e podem aumentar os custos.

Disponibilidade regional

Atualmente, nem todas as regiões dão suporte à redundância de zona para planos de consumo flex. Você pode usar a CLI do Azure para exibir as regiões que dão suporte a ela:

  1. Se você ainda não fez isso, instale e entre no Azure usando a CLI do Azure:

    az login
    

    O comando az login conecta você à sua conta do Azure.

  2. Use este comando az functionapp list-flexconsumption-locations com a opção --zone-redundant=true para retornar uma lista das regiões que atualmente dão suporte aos planos de Consumo Flexível com redundância de zona:

    az functionapp list-flexconsumption-locations --zone-redundant=true --query "sort_by(@, &name)[].{Region:name}" -o table
    

Quando você cria um aplicativo de Consumo Flex no portal do Azure, a Zone redundancy seção da página Básico é habilitada quando sua região escolhida dá suporte a ela.

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

Américas Europa Oriente Médio África Pacífico Asiático
Sul do Brasil França Central Israel Central Norte da África do Sul Leste da Austrália
Canadá Central Centro-oeste da Alemanha Catar Central Índia Central
EUA Central Norte da Itália Norte dos EAU Norte da China 3
Leste dos EUA Europa Setentrional Ásia Oriental
Leste dos EUA 2 Leste da Noruega Leste do Japão
Centro-Sul dos EUA Suécia Central Sudeste Asiático
Oeste dos EUA 2 Norte da Suíça
Oeste dos EUA 3 Sul do Reino Unido
Oeste da Europa

Pré-requisitos

O suporte à zona de disponibilidade é uma característica do plano Flex de consumo. Aqui estão as considerações atuais sobre como usar zonas de disponibilidade:

O suporte a zonas de disponibilidade é uma propriedade do plano Premium. Aqui estão as considerações atuais para zonas de disponibilidade:

  • Você só pode habilitar zonas de disponibilidade no plano ao criar seu aplicativo. 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 (ZRS) para a conta de armazenamento de host padrão do aplicativo de funções. Se você usar um tipo diferente de conta de armazenamento, seu aplicativo poderá se comportar inesperadamente durante uma interrupção zonal.
  • Há suporte para os aplicativos Windows e Linux.
  • Os aplicativos de funções hospedados em um plano Premium devem ter um mínimo de duas instâncias sempre prontas.
  • A plataforma impõe essa contagem mínima automaticamente se você especificar uma contagem de instâncias inferior a duas.
  • 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 medidor separado associado à habilitação de zonas de disponibilidade. O preço das instâncias usadas para um aplicativo de Consumo Flexível com redundância de zona é o mesmo que um aplicativo de Consumo Flexível de zona única. Para saber mais, confira Cobrança.

Quando você habilita zonas de disponibilidade em um aplicativo com configuração de instância sempre pronta de menos de duas instâncias para cada função ou grupo de dimensionamento por função, a plataforma cria automaticamente duas instâncias do tipo sempre pronto para cada função ou grupo de dimensionamento por função. Essas novas instâncias também são cobradas como instâncias sempre prontas.

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 é o mesmo que 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 em um plano com menos de duas instâncias, a plataforma imporá uma contagem mínima de duas instâncias para esse plano do Serviço de Aplicativo e você será cobrado por ambas as instâncias.

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

Atualmente, há várias maneiras de implantar um aplicativo de Consumo Flexível com redundância de zona.

  1. Para criar um aplicativo de funções em um plano com redundância de zona, você deve ter uma conta de armazenamento com redundância de zona existente. Se você ainda não tiver uma conta de armazenamento com redundância de zona, crie uma antes de continuar.

  2. No portal do Azure, vá para a página Criar Aplicativo de Funções. Para obter mais informações sobre como criar um aplicativo de funções no portal, confira Criar um aplicativo de funções.

  3. Selecione Consumo Flexível e, em seguida, escolha o botão Selecionar.

  4. Na página Criar Aplicativo de Funções (Consumo Flexível), na guia Informações Básicas, insira as configurações do aplicativo de funções. Preste atenção especial às configurações da tabela a seguir (também realçadas na captura de tela a seguir), que têm requisitos específicos para redundância de zona.

    Configuração Valor sugerido Notas sobre redundância de zona
    Região Sua região com suporte preferencial A região na qual seu plano de Consumo Flex é criado. Você deve selecionar uma região que dê suporte a zonas de disponibilidade. Confira a lista de disponibilidade por região.
    Redundância de zona Habilitado Essa configuração especifica se o aplicativo é com redundância de zona. Você só pode selecionar Enabled quando escolher uma região que dê suporte à redundância de zona.

    Captura de tela da guia Informações básicas da página de criação do aplicativo de funções de Consumo Flexível.

  5. Na guia Armazenamento , selecione a conta de armazenamento com redundância de zona para seu aplicativo de funções. Preste atenção especial à configuração na tabela a seguir, que tem requisitos específicos para redundância de zona.

    Configuração Valor sugerido Notas sobre redundância de zona
    Conta de armazenamento Uma conta de armazenamento com redundância de zona Conforme descrito na seção pré-requisitos, é altamente recomendável usar uma conta de armazenamento com redundância de zona para seu aplicativo de funções com redundância de zona.
  6. Para o restante do processo de criação do aplicativo de funções, crie seu aplicativo de funções normalmente. Não há configurações no restante do processo de criação que afetem a redundância de zona.

Depois que o plano com redundância de zona for criado e implantado, o aplicativo de funções de Consumo Flexível no seu novo plano será considerado com redundância de zona.

Atualizar um plano de Consumo Flexível para ter redundância de zona

Alterar a redundância de zona do aplicativo requer uma reinicialização, o que causa tempo de inatividade em seu aplicativo.

Antes de atualizar seu plano de Consumo Flexível para ter redundância de zona, você deve atualizar a conta de armazenamento de host padrão para também ter redundância de zona. Se você usar uma conta de armazenamento separada para o contêiner de implantação do aplicativo, atualize-a para ser redundante de zona também.

Use estas etapas para preparar suas contas de armazenamento para a alteração:

  1. Examine as considerações de armazenamento.
  2. Crie ou identifique uma conta de armazenamento com redundância de zona para ser a conta de armazenamento de host padrão do aplicativo.
  3. Atualize as configurações de aplicativo relacionadas ao armazenamento do aplicativo, como AzureWebJobsStorage, para referenciar a conta de armazenamento com redundância de zona. Consulte Trabalhar com as configurações do aplicativo.
  4. Atualize a conta de armazenamento de implantação do aplicativo, que pode ser a mesma ou diferente da conta de armazenamento associada ao aplicativo. Consulte Definir configurações de implantação.

Depois que as contas de armazenamento usadas pelo aplicativo forem atualizadas, atualize o plano de Consumo Flexível para ter redundância de zona usando modelos do Bicep ou do ARM. No momento, o portal do Azure não dá suporte à criação de atualizações de redundância de zona para o plano.

  1. No portal do Azure, pesquise e selecione o aplicativo de funções a ser atualizado.

  2. Em Configurações, selecione Escala e Simultaneidade.

  3. Na guia Redundância de zona , verifique Adicionar redundância de zona para habilitar o recurso. Se já estiver marcado, você poderá desmarcar essa caixa para desabilitar o recurso.

  4. Selecione Salvar para confirmar suas alterações e reiniciar o aplicativo.

Captura de tela da guia Escala e Simultaneidade de um aplicativo de funções Flex Consumption.

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.

  1. No portal do Azure, vá para a página Criar Aplicativo de Funções. Para obter mais informações sobre como criar um aplicativo de funções no portal, confira Criar um aplicativo de funções.

  2. Selecione Functions Premium e, em seguida, selecione o botão Selecionar.

  3. Na página Criar Aplicativo de Funções (Functions Premium), na guia Noções básicas, insira as configurações do aplicativo de funções. Preste atenção especial às configurações da tabela a seguir (também realçadas na captura de tela a seguir), que têm requisitos específicos para redundância de zona.

    Configuração Valor sugerido Notas sobre redundância de zona
    Região Sua região com suporte preferencial A região na qual seu plano Elastic Premium é criado. Você deve escolher uma região que dê suporte a zonas de disponibilidade. Confira a lista de disponibilidade por região.
    Plano de preços Um dos planos do Elastic Premium. Para obter mais informações, consulte SKUs de instância disponíveis. Este artigo descreve como criar um aplicativo com redundância de zona em um plano Premium. No momento, a redundância de zona não está disponível nos planos de Consumo. Para obter informações sobre redundância de zona nos planos do Serviço de Aplicativo, confira Confiabilidade no Serviço de Aplicativo do Azure.
    Redundância de zona Habilitado Essa configuração especifica se o aplicativo é com redundância de zona. Você não poderá selecionar Enabled, a menos que tenha escolhido uma região que dê suporte à redundância de zona, conforme descrito anteriormente.

    Captura de tela da guia Noções básicas da página de criação do aplicativo de funções.

  4. Na guia Armazenamento, insira as configurações da conta de armazenamento do aplicativo de funções. Preste atenção especial à configuração na tabela a seguir, que tem requisitos específicos para redundância de zona.

    Configuração Valor sugerido Notas sobre redundância de zona
    Conta de armazenamento Uma conta de armazenamento com redundância de zona Conforme descrito na seção pré-requisitos, é altamente recomendável usar uma conta de armazenamento com redundância de zona para seu aplicativo de funções com redundância de zona.
  5. Para o restante do processo de criação do aplicativo de funções, crie seu aplicativo de funções normalmente. Não há configurações no restante do processo de criação que afetem a redundância de zona.

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

No momento, não é possível alterar o suporte à zona de disponibilidade de um plano Elastic Premium para um aplicativo de funções existente. Para obter informações sobre como migrar o plano Premium público multilocatário da zona sem disponibilidade para o suporte à zona de disponibilidade, veja Migrar o Serviço de Aplicativo para o suporte à zona de disponibilidade.

Experiência de zona inoperante

Todas as instâncias do aplicativo de funções disponíveis de aplicativos do plano de Consumo Flexível com redundância de zona estão habilitadas e processando eventos. Os aplicativos de Consumo Flex continuam sendo executados mesmo quando outras zonas na mesma região sofrem uma interrupção. No entanto, é possível que comportamentos não relacionados ao tempo de execução possam ser afetados devido a uma interrupção em outras zonas de disponibilidade. Os comportamentos do aplicativo de funções padrão que podem afetar a disponibilidade incluem:

  • Escalonamento
  • Criação de aplicativo
  • Alterações de configuração
  • Implantações

A redundância de zona para planos do Consumo Flexível garante apenas o tempo de atividade contínuo para aplicativos implantados que estão em execução.

Quando uma zona é inoperante, o Functions detecta instâncias perdidas e tenta localizar ou criar automaticamente instâncias de substituição, conforme necessário, nas zonas disponíveis. Durante a interrupção zonal, a plataforma tenta restaurar o equilíbrio nas zonas restantes.

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 mais instâncias 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 runtime 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 Microsoft Azure subjacentes. Um plano Premium é considerado equilibrado quando cada zona tem o mesmo número de máquinas virtuais em todas as outras zonas usadas pelo plano Premium, mais ou menos uma máquina virtual.

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

Recuperação de desastre (DR) refere-se a práticas que as organizações usam para se recuperar de 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 criar seu plano de recuperação de desastre, veja Recomendações para a elaboração de uma estratégia de recuperação de desastre.

Para a DR, a Microsoft usa o modelo de responsabilidade compartilhada. Nesse modelo, a Microsoft garante que a infraestrutura de linha de base e os serviços de plataforma estejam disponíveis. No entanto, muitos serviços do Azure não replicam automaticamente dados nem fazem fallback de uma região com falha para replicação entre outras regiões habilitadas. 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 PaaS (plataforma como serviço) do Azure fornece recursos e diretrizes para dar suporte à DR. Você pode usar recursos específicos do serviço para dar suporte à recuperação rápida para ajudar a desenvolver seu plano de recuperação de desastre.

Esta seção explica algumas das estratégias que você pode usar para implantar um aplicativo de funções 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. Use um padrão ativo/ativo em combinação com o Azure Front Door para suas funções críticas disparadas por HTTP, que podem rotear e fazer uma distribuição round robin 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.

Arquitetura do Azure Front Door e do Function

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 do Azure 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.

Exemplo de arquitetura ativo-passivo

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.

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

Embora você seja incentivado a usar o padrão ativo-passivo para funções de gatilho não HTTPS, você ainda pode criar implantações ativas-ativas para funções não disparadas por HTTP. Antes de implementar esse padrão, você deve considerar como as duas regiões ativas interagem ou se coordenam entre si e com a origem do gatilho.

Por exemplo, considere ter o mesmo código de função disparado pelo Barramento de Serviço implantado em duas regiões, mas disparando na mesma fila do Barramento de Serviço. Nesse caso, ambas as funções funcionam como consumidores concorrentes na remoção da fila única. Embora cada mensagem só possa ser processada por uma das duas instâncias do aplicativo, isso significa também que ainda existe um único ponto de falha, que é a instância única do Barramento de Serviço. Considere habilitar os recursos recuperação de desastre geográfico e replicação geográfica do Barramento de Serviço para garantir que ele também seja resiliente.

Próximas etapas