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

Plano de alojamento	Nível de suporte	Para mais informações...
Plano de consumo Flex	disponibilidade geral	Selecione Flex Consumption na parte superior deste artigo.
Plano Elastic Premium	disponibilidade geral	Selecione Premium na parte superior deste artigo.
Plano dedicado (Serviço de Aplicativo)	disponibilidade geral	Consulte Confiabilidade no Serviço de Aplicativo do Azure.
Plano de consumo	não aplicável	Não suportado pelo plano de consumo.

As zonas de disponibilidade são grupos fisicamente separados de centros de dados dentro de uma região Azure. Quando uma zona falha, os serviços podem ser transferidos 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 os aplicativos do plano Flex Consumption como redundantes de zona, a plataforma espalha automaticamente as instâncias do seu aplicativo de função pelas zonas na região selecionada, com regras diferentes para instâncias sempre prontas versus instâncias sob demanda.

Quando a redundância de zona é habilitada em um plano Flex Consumption, a distribuição de instâncias é determinada dentro das seguintes regras:

• As instâncias sempre prontas são distribuídas em pelo menos duas zonas de forma round-robin.
• As instâncias sob demanda, que são criadas a partir dos volumes de origem dos eventos quando o aplicativo se dimensiona além de um estado sempre preparado, são distribuídas entre zonas de disponibilidade com base no melhor esforço. Isso significa que, para instâncias sob demanda, a expansão mais rápida tem preferência sobre a distribuição uniforme entre zonas de disponibilidade. A plataforma tenta equilibrar a distribuição ao longo do tempo.
• Para garantir resiliência na zona com zonas de disponibilidade, a plataforma mantém automaticamente pelo menos duas instâncias sempre operacionais para cada função individual ou grupo de funções dimensionáveis, independentemente da configuração de prontidão contínua do aplicativo. Todas as instâncias criadas pela plataforma são gerenciadas pela plataforma, cobradas como instâncias sempre prontas e não alteram as definições de configuração sempre prontas.

Quando você configura os planos do aplicativo de função Elastic Premium como zona redundante, a plataforma distribui automaticamente as instâncias do aplicativo de função pelas zonas na região selecionada.

A distribuição de instâncias com uma implantação redundante de zona é determinada de acordo com as seguintes regras, mesmo quando o aplicativo escala para dentro e para fora.

• A contagem mínima de instâncias da aplicação de função é duas.
• Quando você especifica uma capacidade maior do 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 superior a Número de zonas * Número de instâncias, 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 App Service, os planos que hospedam aplicações que funcionam em planos 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, 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 Pequeno), são planos de hospedagem dedicados. Como não são dedicados nem Elastic Premium, os planos com nomes de SKU começando com P não são escalados dinamicamente e podem aumentar os seus custos.

Disponibilidade regional

Atualmente, nem todas as regiões suportam redundância de zona para planos Flex Consumption. Você pode usar a CLI do Azure para exibir as regiões que oferecem suporte a ela:

1. Se ainda não tiver feito isso, instale e entre no Azure usando a CLI do Azure:

   az login
   

   O az login comando inicia sessão na sua conta do Azure.

2. Use este az functionapp list-flexconsumption-locations comando com a --zone-redundant=true opção para devolver uma lista de regiões que suportam atualmente planos Flex Consumption 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 Flex Consumption no portal do Azure, a Zone redundancy seção da página Noções básicas é habilitada quando a região escolhida oferece suporte a ele.

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

Américas	Europa	Médio Oriente	África	Ásia-Pacífico
Sul do Brasil	Centro de França	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 de 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
E.U.A. Oeste 3	Sul do Reino Unido
	Europa Ocidental

Pré-requisitos

O suporte à zona de disponibilidade é uma propriedade do plano Flex Consumption. Aqui estão as considerações atuais para 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 recursos do plano.
• Você deve usar uma conta de armazenamento redundante de zona (ZRS) para a conta de armazenamento de host padrão do seu aplicativo de função. 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 para zonas de disponibilidade é uma característica 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. 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 de host padrão do seu aplicativo de função. Se você usar um tipo diferente de conta de armazenamento, seu aplicativo poderá se comportar inesperadamente durante uma interrupção zonal.
• Tanto o Windows como o Linux são suportados.
• Os aplicativos de função hospedados em um plano Premium devem ter no mínimo duas instâncias sempre prontas.
• A plataforma impõe esta contagem mínima em segundo plano se for especificada uma contagem de instâncias inferior a duas.
• 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á um medidor separado associado à ativação de zonas de disponibilidade. O preço das instâncias usadas para uma aplicação Flex Consumption com zona redundante é o mesmo de uma aplicação Flex Consumption de zona única. Para saber mais, consulte Faturação.

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. Estas novas instâncias também são faturadas como instâncias sempre disponíveis.

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

Criar uma aplicação de funções num plano com redundância de zona

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

portal do Azure

1. Para criar um aplicativo de função 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ção . Para obter mais informações sobre como criar um aplicativo de função no portal, consulte Criar um aplicativo de função.

3. Selecione Flex Consumption e, em seguida, selecione o botão Selecionar .

4. Na página Criar aplicativo de função (Consumo flexível), 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.

   Configurações	Valor sugerido	Notas sobre a redundância de zona
   Região	A sua região suportada preferida	A região na qual o seu plano Flex Consumption é criado. Você deve selecionar uma região que ofereça suporte a zonas de disponibilidade. Consulte a lista de disponibilidade da região.
   Redundância de zona	Ativado(a)	Esta definição especifica se a sua aplicação é redundante de zona. Só pode selecionar Enabled quando tiver escolhido uma região que suporte redundância de zona.

   

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

   Configurações	Valor sugerido	Notas sobre a redundância de zona
   Conta de armazenamento	Uma conta de armazenamento com redundância de zona	Conforme descrito na seção de pré-requisitos, recomendamos fortemente usar uma conta de armazenamento com redundância de zona para a sua aplicação de função com redundância de zona.

6. 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.

CLI do Azure

1. Ao criar a conta de armazenamento para a aplicação de funções, escolha uma SKU com redundância de zona, como Standard_ZRS. Por exemplo:

   az storage account create --name <STORAGE_NAME> --location <REGION> --resource-group <RESOURCE_GROUP> --sku Standard_ZRS --allow-blob-public-access false
   

2. Ao criar o plano Flex Consumption, adicione o --zone-redundant true parâmetro:

   az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage-account <STORAGE_NAME> --flexconsumption-location <REGION> --runtime <RUNTIME> --runtime-version <RUNTIME_VERSION> --zone-redundant true 
   

Modelo de bíceps

Você pode usar um modelo Bicep para implantar num plano de Consumo Flexível com redundância zonal. Para saber como implantar aplicações de função em um Flex Consumption, consulte Automatizar a implementação de recursos no Azure Functions.

As únicas propriedades a ter em consideração ao criar um plano de hospedagem com redundância de zona são a propriedade zoneRedundant. A zoneRedundant propriedade deve ser definida como true.

A seguir está um trecho de modelo Bicep para um plano Consumo Flex redundante em zonas. Ele mostra a especificação do zoneRedundant campo.

resource flexFuncPlan 'Microsoft.Web/serverfarms@2024-04-01' = {
  name: <YOUR_PLAN_NAME>
  location: <YOUR_REGION_NAME>
  kind: 'functionapp'
  sku: {
    tier: 'FlexConsumption'
    name: 'FC1'
  }
  properties: {
    reserved: true
    zoneRedundant: true
  }
}

Para saber mais sobre esses modelos, consulte Automatizar a implantação de recursos no Azure Functions.

Modelo ARM

Você pode usar um modelo ARM para implantar em um plano Flex Consumption com redundância de zona. Para saber como implantar aplicativos de função em um plano do Flex Consumption, consulte Automatizar a implantação de recursos no Azure Functions.

As únicas propriedades a ter em consideração ao criar um plano de hospedagem com redundância de zona são a propriedade zoneRedundant. A zoneRedundant propriedade deve ser definida como true.

A seguir está um excerto de modelo ARM para um plano Flex Consumption com redundância em zonas. Ele mostra a especificação do zoneRedundant campo.

"resources": [

    {
      "type": "Microsoft.Web/serverfarms",
      "apiVersion": "2024-04-01",
      "name": "<YOUR_PLAN_NAME>",
      "location": "<YOUR_REGION_NAME>",
      "kind": "functionapp",
      "sku": {
        "tier": "FlexConsumption",
        "name": "FC1"
      },
      "properties": {
        "reserved": true,
        "zoneRedundant": true
      }
    }
]

Para saber mais sobre esses modelos, consulte Automatizar a implantação de recursos no Azure Functions.

Depois de criado e implantado o plano com redundância entre zonas, a aplicação de função Flex Consumption hospedada no seu novo plano é considerada redundante entre zonas.

Atualizar um plano de consumo Flex para ter redundância de zona

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

Antes de atualizar o seu plano de Consumo Flexível para ser redundante em zonas, deve-se atualizar a conta de armazenamento padrão do host para também ser redundante em zonas. Se você usar uma conta de armazenamento separada para o contêiner de implantação do aplicativo, deverá atualizá-la para ser redundante de zona também.

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

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

Depois que as contas de armazenamento usadas pelo seu aplicativo forem atualizadas, você poderá atualizar o plano Flex Consumption para ser redundante de zona usando modelos Bicep ou ARM. Atualmente, o portal do Azure não oferece suporte para fazer atualizações de redundância de zona para o plano.

portal do Azure

1. No portal do Azure, procure e selecione o aplicativo de função a ser atualizado.

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

3. Na guia Redundância de zona , marque Adicionar redundância de zona para habilitar o recurso. Se já estiver marcada, você pode desmarcar essa caixa para desativar o recurso.

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

CLI do Azure

Atualize o aplicativo usando o --zone-redundant parâmetro do comando az functionapp plan update . Use um valor de true para habilitar a redundância da zona e false para desativar a funcionalidade. Este exemplo habilita a redundância de zona para um aplicativo existente em um plano Flex Consumption:

PLAN_RESOURCE_ID=$(az functionapp show --resource-group <RESOURCE_GROUP> --name <APP_NAME> --query "properties.serverFarmId"  -o tsv) 

az functionapp plan update --ids $PLAN_RESOURCE_ID --set zoneRedundant=true

Neste exemplo, substitua <RESOURCE_GROUP> e <APP_NAME> pelos nomes do seu grupo de recursos e aplicativo, respectivamente.

Modelo de bíceps

Você pode usar esse arquivo Bicep para adicionar a zoneRedundant propriedade a true em uma definição de plano existente:

resource existingServerFarm 'Microsoft.Web/serverfarms@2024-04-01' existing = {
  name: '<YOUR_PLAN_NAME>'
  scope: resourceGroup()
}

resource updatedServerFarm 'Microsoft.Web/serverfarms@2024-04-01' = {
  name: existingServerFarm.name
  location: '<YOUR_REGION_NAME>'
  kind: 'functionapp'
  sku: {
    tier: 'FlexConsumption'
    name: 'FC1'
  }
  properties: {
    reserved: true
    zoneRedundant: true  // Enables zone redundancy
  }
}

Neste ficheiro, substitua <YOUR_PLAN_NAME> e <YOUR_REGION_NAME> pelo nome do seu plano e região, respetivamente. Para saber como implantar um arquivo Bicep, consulte Implantar seu modelo.

Modelo ARM

Você pode usar este fragmento de modelo ARM para definir a zoneRedundant propriedade como true em uma definição de plano existente:

{
  "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "resources": [
    {
      "type": "Microsoft.Web/serverfarms",
      "apiVersion": "2024-04-01",
      "name": "<YOUR_PLAN_NAME>",
      "location": "<YOUR_REGION_NAME>",
      "kind": "functionapp",
      "sku": {
        "tier": "FlexConsumption",
        "name": "FC1"
      },
      "properties": {
        "reserved": true,
        "zoneRedundant": true
      }
    }
  ]
}

Neste modelo, substitua <YOUR_PLAN_NAME> e <YOUR_REGION_NAME> pelo nome do seu plano e região, respectivamente. Para saber como implantar um modelo ARM, consulte Implantar seu modelo.

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.

portal do Azure

1. 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.

2. Selecione Funções Premium e, em seguida, selecione o botão Selecionar .

3. 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.

   Configurações	Valor sugerido	Notas sobre a redundância de zona
   Região	A sua região suportada preferida	A região na qual seu plano Elastic Premium é 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 Enabled a menos que tenha escolhido uma região que ofereça suporte à redundância de zona, conforme descrito anteriormente.

   

4. 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.

   Configurações	Valor sugerido	Notas sobre a redundância de zona
   Conta de armazenamento	Uma conta de armazenamento com redundância de zona	Conforme descrito na seção de pré-requisitos, recomendamos fortemente usar uma conta de armazenamento com redundância de zona para a sua aplicação de função com redundância de zona.

5. 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.

CLI do Azure

1. Ao criar a conta de armazenamento para a aplicação de funções, escolha uma SKU com redundância de zona, como Standard_ZRS. Por exemplo:

   az storage account create --name <STORAGE_NAME> --location <REGION> --resource-group <RESOURCE_GROUP> --sku Standard_ZRS --allow-blob-public-access false
   

2. Ao criar o plano Premium, adicione o --zone-redundant true parâmetro:

   az functionapp plan create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage-account <STORAGE_NAME> --SKU EP1 --zone-redundant true 
   

Modelo de bíceps

Você pode usar um modelo Bicep para implantar em um plano Premium com redundância de zona. Para saber como implantar aplicativos de função em um plano Premium, consulte Automatizar a implantação de recursos no Azure Functions.

As únicas propriedades a considerar ao criar um plano de hospedagem com redundância de zona são a propriedade zoneRedundant e os campos de contagem de instâncias (capacity) do plano. A propriedade zoneRedundant deve ser definida como true e a propriedade capacity deve ser ajustada com base no requisito de carga de trabalho, mas não inferior a 3. A escolha da capacidade certa varia com base em vários fatores e estratégias de alta disponibilidade / tolerância a falhas. Uma boa regra geral é especificar instâncias suficientes para o aplicativo para garantir que a perda de uma instância de zona deixe capacidade suficiente para lidar com a carga esperada.

Importante

Os aplicativos do Azure Functions hospedados em um plano com redundância de zona do Elastic Premium devem ter uma contagem mínima de instâncias sempre prontas de 3. Esse mínimo garante que um aplicativo de função redundante de zona sempre tenha instâncias suficientes para satisfazer pelo menos um trabalhador por zona.

A seguir está um excerto de modelo Bicep para um plano Premium com redundância de zonas. Ele mostra o zoneRedundant campo e a capacity especificação.

resource EPFuncPlan 'Microsoft.Web/serverfarms@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
    }
}

Para saber mais sobre esses modelos, consulte Automatizar a implantação de recursos no Azure Functions.

Modelo ARM

Você pode usar um modelo ARM para implantar em um plano Premium com redundância de zona. Para saber como implantar aplicativos de função em um plano Premium, consulte Automatizar a implantação de recursos no Azure Functions.

As únicas propriedades a considerar ao criar um plano de hospedagem com redundância de zona são a propriedade zoneRedundant e os campos de contagem de instâncias (capacity) do plano. A propriedade zoneRedundant deve ser definida como true e a propriedade capacity deve ser ajustada com base no requisito de carga de trabalho, mas não inferior a 3. A escolha da capacidade certa varia com base em vários fatores e estratégias de alta disponibilidade / tolerância a falhas. Uma boa regra geral é especificar instâncias suficientes para o aplicativo para garantir que a perda de uma instância de zona deixe capacidade suficiente para lidar com a carga esperada.

Importante

Os aplicativos do Azure Functions hospedados em um plano com redundância de zona do Elastic Premium devem ter uma contagem mínima de instâncias sempre prontas de 3. Esse mínimo garante que um aplicativo de função redundante de zona sempre tenha instâncias suficientes para satisfazer pelo menos um trabalhador por zona.

A seguir está um trecho de modelo ARM para um plano Premium com redundância de zona. Ele mostra o zoneRedundant campo e a capacity especificação.

"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
        }
    }
]

Para saber mais sobre esses modelos, consulte Automatizar a implantação de recursos no Azure Functions.

Depois de criado e implementado o plano redundante por zona, qualquer aplicação de funções hospedada no seu novo plano é considerada redundante por 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ção 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, consulte Migrar o Serviço de Aplicativo para o suporte à zona de disponibilidade.

Experiência de redução de intensidade

Todas as instâncias de aplicativos de função disponíveis de aplicativos de plano Flex Consumption com redundância de zona são habilitadas e processam eventos. Os aplicativos Flex Consumption 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 possam ser afetados como resultado de uma interrupção em outras zonas de disponibilidade. Os comportamentos padrão do aplicativo de função que podem afetar a disponibilidade incluem:

• Escalonamento
• Criação de aplicações
• Alterações de configuração
• Implementações

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

Quando uma zona fica inativa, o Functions deteta instâncias perdidas e tenta automaticamente localizar ou criar 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 disponíveis restantes.

Todas as instâncias disponíveis de aplicações de função com redundância de zona estão habilitadas e a processar 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 para mais instâncias possam ser bem-sucedidas, já 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 não de execução possam ainda 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 tempo de atividade contínuo apenas 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 máquinas virtuais em todas as outras zonas usadas pelo plano Premium, mais ou menos uma máquina virtual.

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

A recuperação de desastres (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. 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 criar seu plano de recuperação de desastres, consulte Recomendações para projetar uma estratégia de recuperação de desastres.

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

Esta seção explica algumas das estratégias que você pode usar para implantar um aplicativo de função 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. Você deve usar um padrão ativo-ativo em combinação com o Azure Front Door para suas funções críticas ativadas por HTTP, que podem rotear e distribuir solicitações HTTP entre funções executando 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 as suas funções orientadas a eventos acionadas não-HTTP, como funções acionadas pelo Service Bus e pelos 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 um meio para que apenas uma única função processe cada mensagem, ao mesmo tempo que oferece um mecanismo para transferência para a região secundária em caso de 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.
• Geo-disaster ativado 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.
• As aplicações funcionais são implantadas nas suas regiões primária e secundária (failover), sendo que na região secundária, a aplicação permanece virtualmente inativa porque não estão a ser enviadas mensagens para lá.
• A aplicação de função é acionada na cadeia de conexão direta (sem alias) para o 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 eficaz para uma região secundária pode ser gerido completamente a partir do hub de eventos, com as funções tornando-se ativas somente quando o respetivo hub de eventos estiver ativo.

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

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

Embora seja incentivado o uso do padrão ativo-passivo para funções que não são acionadas por HTTPS, ainda pode criar implantações ativo-ativo para funções que não são acionadas 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 acionado do Service Bus implantado em duas regiões, mas acionando na mesma fila do Service Bus. Neste caso, ambas as funções atuam como consumidores concorrentes na eliminação da fila única. Embora cada mensagem só possa ser processada por uma das duas instâncias do aplicativo, isso também significa que ainda há um único ponto de falha, que é a única instância do Service Bus. Considere habilitar os recursos de recuperação de desastres geográficos e replicação geográfica do Service Bus para garantir que ele também seja resiliente.

Próximos passos

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