Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
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:
Se você ainda não fez isso, instale e entre no Azure usando a CLI do Azure:
az loginO comando
az loginconecta você à sua conta do Azure.Use este comando
az functionapp list-flexconsumption-locationscom a opção--zone-redundant=truepara 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:
- Você pode habilitar zonas de disponibilidade no plano durante a criação do aplicativo.
- Você pode habilitar ou desabilitar zonas de disponibilidade atualizando as configurações de recurso do plano.
- 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.
- Deve ser hospedado em um plano Flex Consumption.
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.
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.
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.
Selecione Consumo Flexível e, em seguida, escolha o botão Selecionar.
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 Enabledquando escolher uma região que dê suporte à redundância de zona.
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. 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:
- Examine as considerações de armazenamento.
- Crie ou identifique uma conta de armazenamento com redundância de zona para ser a conta de armazenamento de host padrão do aplicativo.
- 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. - 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.
No portal do Azure, pesquise e selecione o aplicativo de funções a ser atualizado.
Em Configurações, selecione Escala e Simultaneidade.
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.
Selecione Salvar para confirmar suas alterações e reiniciar o aplicativo.
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.
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.
Selecione Functions Premium e, em seguida, selecione o botão Selecionar.
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.
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. 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.
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.
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.