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 são grupos de datacenters fisicamente separados em cada região do Azure. Quando uma zona falha, os serviços podem fazer failover para uma das zonas restantes.
Para obter mais informações sobre as zonas de disponibilidade no Azure, confira O que são zonas 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.
Importante
O Azure Functions pode ser executado na plataforma de Serviço de Aplicativo do Azure. Na plataforma do Serviço de Aplicativo, os planos que hospedam Premium aplicativos de função de plano são chamados de planos Premium Elásticos, com nomes de SKU como EP1. Se 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 o P1V2 (Plano pequeno Premium V2), são, na verdade, Planos de hospedagem dedicados. Como eles são Dedicados e não Elásticos Premium, os planos com nomes de SKU começando com "P" não serão dimensionados dinamicamente e poderão aumentar os custos.
Disponibilidade regional
Os planos Premium com redundância de zona estão disponíveis nas seguintes regiões:
| Américas | Europa | Oriente Médio | África | Pacífico Asiático |
|---|---|---|---|---|
| Brazil South | França Central | Israel Central | Norte da África do Sul | Leste da Austrália |
| Canadá Central | Centro-Oeste da Alemanha | Catar Central | Índia Central | |
| Centro dos EUA | Norte da Itália | Norte dos EAU | Norte da China 3 | |
| Leste dos EUA | Norte da Europa | Leste da Ásia | ||
| Leste dos EUA 2 | Leste da Noruega | Leste do Japão | ||
| Centro-Sul dos Estados Unidos | Suécia Central | Sudeste Asiático | ||
| Oeste dos EUA 2 | Norte da Suíça | |||
| Oeste dos EUA 3 | Sul do Reino Unido | |||
| Europa Ocidental |
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.
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, consulte Criar um aplicativo de funções.
Selecione Functions Premium e, em seguida, selecione o botão Selecionar. 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, consulte Confiabilidade no Serviço de Aplicativo do Azure.
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 o novo aplicativo de funções é criado. Você deve escolher uma região que dê suporte a zonas de disponibilidade. Consulte a lista de disponibilidade da 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, consulte Confiabilidade no Serviço de Aplicativo do Azure. Redundância de zona Enabled 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
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 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. 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.
Para obter um exemplo, consulte a amostra de como implementar o padrão de geode implantando a API em geodes em regiões distribuídas do Azure..
Importante
Contudo, é altamente recomendável que você use o padrão ativo-passivo para funções de gatilho não HTTPS. Você pode criar implantações ativo-ativo para funções de gatilho não HTTPS. No entanto, você precisa considerar como as duas regiões ativas interagem ou coordenam uma com a outra. Quando você implanta o mesmo aplicativo de funções em duas regiões com cada um disparando na mesma fila do Barramento de Serviço, eles atuariam como consumidores concorrentes na remoção da fila. Cada mensagem seria processada por apenas uma das instâncias, mas também haveria um ponto único de falha no Barramento de Serviço de instância única.
Em vez disso, você poderia implantar duas filas de Barramento de Serviço, com uma em uma região primária, uma em uma região secundária. Nesse caso, você poderia ter dois aplicativos de função, cada um sendo apontado para a fila de Barramento de Serviço ativa em sua região. O desafio com essa topologia é como as mensagens de fila são distribuídas entre as duas regiões. Geralmente, isso significa que cada publicador tenta publicar uma mensagem em ambas as regiões, e cada mensagem é processada por ambos os aplicativos de funções ativos. O resultado é o padrão ativo/ativo desejado, mas também surgem outros desafios quanto à duplicação da computação e quando ou como os dados são consolidados.
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.