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 são grupos fisicamente separados de datacenters dentro de 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 zonas de disponibilidade no Azure, consulte 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 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.
Importante
O Azure Functions pode ser executado na plataforma do Serviço de Aplicativo do Azure. Na plataforma do Serviço de Aplicativo, os planos que hospedam aplicativos de função de plano Premium são chamados de planos Elastic Premium, com nomes de SKU como EP1. Se você optar por executar seu aplicativo de função em um plano Premium, certifique-se de criar 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 Pequeno), são, na verdade , planos de hospedagem dedicados. Por serem Dedicados e não Elastic Premium, os planos com nomes de SKU começando com "P" não serão dimensionados dinamicamente e poderão aumentar seus custos.
Disponibilidade regional
Os planos Premium com redundância de zona estão disponíveis nas seguintes regiões:
| Américas | Europa | Médio Oriente | África | Ásia-Pacífico |
|---|---|---|---|---|
| Sul do Brasil | França Central | Israel Central | Norte da África do Sul | Leste da Austrália |
| Canadá Central | Alemanha Centro-Oeste | Catar Central | Índia Central | |
| E.U.A. Central | Norte da Itália | Norte dos E.A.U. | Norte da China 3 | |
| E.U.A. Leste | Europa do Norte | Ásia Leste | ||
| E.U.A. Leste 2 | Leste da Noruega | Leste do Japão | ||
| E.U.A. Centro-Sul | Suécia Central | Sudeste Asiático | ||
| E.U.A. Oeste 2 | Norte da Suíça | |||
| EUA Oeste 3 | Sul do Reino Unido | |||
| Europa Ocidental |
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.
No portal do Azure, vá para a página Criar Aplicativo de Função. Para obter mais informações sobre como criar um aplicativo de função no portal, consulte Criar um aplicativo de função.
Selecione Funções Premium e, em seguida, selecione o botão Selecionar . Este artigo descreve como criar um aplicativo redundante de zona em um plano Premium. A redundância de zona não está atualmente disponível nos planos de consumo. Para obter informações sobre redundância de zona em planos de serviço de aplicativo, consulte Confiabilidade no Serviço de Aplicativo do Azure.
Na página Criar aplicativo de função (Functions Premium), na guia Noções básicas, insira as configurações do seu aplicativo de função. Preste especial atenção às configurações na tabela a seguir (também destacadas na captura de tela a seguir), que têm requisitos específicos para redundância de zona.
Definição Valor sugerido Notas para redundância de zona Região A sua região suportada preferida A região sob a qual o novo aplicativo de função é criado. Você deve escolher uma região que ofereça suporte a zonas de disponibilidade. Consulte a lista de disponibilidade da região. Plano de preços Um dos planos Elastic Premium. Para obter mais informações, consulte SKUs de instância disponíveis. Este artigo descreve como criar um aplicativo redundante de zona em um plano Premium. A redundância de zona não está atualmente disponível nos planos de consumo. Para obter informações sobre redundância de zona em planos do Serviço de Aplicativo, consulte Confiabilidade no Serviço de Aplicativo do Azure. Redundância de zona Ativado(a) Esta definição especifica se a sua aplicação é redundante de zona. Você não poderá selecionar Enableda menos que tenha escolhido uma região que ofereça suporte à redundância de zona, conforme descrito anteriormente.
Na guia Armazenamento, insira as configurações da sua conta de armazenamento de aplicativo funcional. Preste especial atenção à configuração na tabela a seguir, que tem requisitos específicos para redundância de zona.
Definição Valor sugerido Notas para redundância de zona Conta de armazenamento Uma conta de armazenamento com redundância de zona Conforme descrito na seção de pré-requisitos , é altamente recomendável usar uma conta de armazenamento com redundância de zona para seu aplicativo de função com redundância de zona. Para o resto do processo de criação do aplicativo de função, crie seu aplicativo de função 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 é 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.
Para obter um exemplo, consulte o exemplo sobre como implementar o padrão geode implantando a API em geodes em regiões distribuídas do Azure..
Importante
No entanto, é altamente recomendável que você use o padrão ativo-passivo para funções de gatilho não-HTTPS. Você pode criar implantações ativas-ativas para funções acionadas não HTTP. No entanto, você precisa considerar como as duas regiões ativas interagem ou se coordenam uma com a outra. Quando você implanta o mesmo aplicativo de função em duas regiões com cada um acionando na mesma fila do Service Bus, eles agem como consumidores concorrentes na eliminação da fila dessa fila. Embora isso signifique que cada mensagem está sendo processada apenas por uma das instâncias, também significa que ainda há um único ponto de falha na única instância do Service Bus.
Em vez disso, você pode implantar duas filas do Service Bus, com uma em uma região primária e outra em uma região secundária. Nesse caso, você pode ter dois aplicativos de função, com cada um apontado para a fila do Service Bus ativa em sua região. O desafio com essa topologia é como as mensagens de fila são distribuídas entre as duas regiões. Muitas vezes, isso significa que cada editor tenta publicar uma mensagem em ambas as regiões, e cada mensagem é processada por ambos os aplicativos de função ativa. Embora isso crie o padrão ativo/ativo desejado, também cria outros desafios em torno da duplicação de 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 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.