Share via


Fiabilidade no Serviço de Aplicações do Azure

Este artigo descreve o suporte à confiabilidade no Serviço de Aplicativo do Azure e aborda a resiliência intrarregional com zonas de disponibilidade e a recuperação de desastres 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 Serviço de Aplicativo do Azure é um serviço baseado em HTTP para hospedar aplicativos Web, APIs REST e back-ends móveis; e adiciona o poder do Microsoft Azure ao seu aplicativo, como:

  • Segurança
  • Balanceamento de carga
  • Dimensionamento automático
  • Gestão automatizada

Para explorar como o Serviço de Aplicativo do Azure pode reforçar a confiabilidade e a resiliência da carga de trabalho do seu aplicativo, consulte Por que usar o Serviço de Aplicativo?

Recomendações de fiabilidade

Esta seção contém recomendações para alcançar resiliência e disponibilidade. Cada recomendação enquadra-se numa de duas categorias:

  • Os itens de integridade abrangem áreas como itens de configuração e a função adequada dos principais componentes que compõem sua Carga de Trabalho do Azure, como definições de configuração de Recursos do Azure, dependências de outros serviços e assim por diante.

  • Os itens de risco abrangem áreas como requisitos de disponibilidade e recuperação, testes, monitoramento, implantação e outros itens que, se não forem resolvidos, aumentam as chances de problemas no ambiente.

Matriz de prioridades de recomendações de fiabilidade

Cada recomendação é assinalada de acordo com a seguinte matriz de prioridades:

Imagem Prioridade Description
Alto Correção imediata necessária.
Médio Corrigir dentro de 3-6 meses.
Baixo Precisa ser revisto.

Resumo das recomendações de fiabilidade

Categoria Prioridade Recomendação
Elevada Disponibilidade ASP-1 - Implantar planos do Serviço de Aplicativo com redundância de zona
Resiliência ASP-2 -Use um plano do Serviço de Aplicativo que ofereça suporte a zonas de disponibilidade
ASP-4 - Crie planos separados do Serviço de Aplicativo para produção e teste
Escalabilidade ASP-3 - Evite escalar frequentemente para cima ou para baixo
ASP-5 - Habilite o dimensionamento automático/automático para garantir que os recursos adequados estejam disponíveis para solicitações de serviço

Elevada disponibilidade

ASP-1 - Implantar planos do Serviço de Aplicativo com redundância de zona

Para melhorar a resiliência e a confiabilidade de suas cargas de trabalho críticas para os negócios, é recomendável implantar seus novos Planos do Serviço de Aplicativo com redundância de zona. Siga as etapas para reimplantar o suporte à zona de disponibilidade, configure seus pipelines para reimplantar seu WebApp no novo Plano de Serviços de Aplicativo e use uma abordagem de implantação Azul-Verde para failover para o novo site.

Ao distribuir seus aplicativos em várias zonas de disponibilidade, você pode garantir sua operação contínua mesmo no caso de uma falha no nível do datacenter. Para obter mais informações sobre o suporte à zona de disponibilidade no Serviço de Aplicativo do Azure, consulte Suporte à zona de disponibilidade.

// Azure Resource Graph Query
// The query filters the qualified App Service Plans that do not have Zone Redundancy enabled.
// Its important to check regions that support availability zones for Azure App Services running on multi-tenant and App Service Environments https://learn.microsoft.com/en-us/azure/reliability/reliability-app-service?tabs=graph%2Ccli#:~:text=The%20following%20regions%20support%20Azure%20App%20Services%20running%20on%20multi%2Dtenant%20environments%3A

resources
| where type =~ 'microsoft.web/serverfarms'
| extend zoneRedundant = tobool(properties.zoneRedundant)
| extend sku_tier = tostring(sku.tier)
| where (tolower(sku_tier) contains "isolated" or tolower(sku_tier) contains "premium") and zoneRedundant == false
| project recommendationid="asp-1", name, id, tags, param1=sku_tier, param2="Not Zone Redundant"

Resiliência

ASP-2 -Use um plano do Serviço de Aplicativo que ofereça suporte a zonas de disponibilidade

O suporte à zona de disponibilidade só está disponível em determinados planos do Serviço de Aplicativo. Para ver qual plano você precisa para usar zonas de disponibilidade, consulte Pré-requisitos da zona de disponibilidade.

// Azure Resource Graph Query
// Provides a list of Azure App Service Plans that are not in the "Standard", "Premium", or "IsolatedV2" SKU tiers.

resources
| where type =~ 'microsoft.web/serverfarms'
| extend sku_tier = tostring(sku.tier)
| where tolower(sku_tier) !contains "standard" and
        tolower(sku_tier) !contains "premium" and
        tolower(sku_tier) !contains "isolatedv2"
| project recommendationid="asp-2", name, id, tags, param1= strcat("SKU=",sku_tier)

ASP-4 - Crie planos separados do Serviço de Aplicativo para produção e teste

Para melhorar a resiliência e a confiabilidade de suas cargas de trabalho críticas para os negócios, você deve migrar seus planos existentes do Serviço de Aplicativo e os Ambientes do Serviço de Aplicativo para o suporte à zona de disponibilidade. Ao distribuir seus aplicativos em várias zonas de disponibilidade, você pode garantir sua operação contínua mesmo no caso de uma falha no nível do datacenter. Para obter mais informações sobre o suporte à zona de disponibilidade no Serviço de Aplicativo do Azure, consulte Suporte à zona de disponibilidade.

Escalabilidade

ASP-3 - Evite escalar frequentemente para cima ou para baixo

É recomendável evitar escalar frequentemente para cima ou para baixo suas instâncias do Serviço de Aplicativo do Azure. Em vez disso, escolha uma camada e um tamanho de instância apropriados que possam lidar com sua carga de trabalho típica e dimensione as instâncias para acomodar alterações no volume de tráfego. A expansão para cima ou para baixo pode potencialmente desencadear uma reinicialização do aplicativo, o que pode resultar em interrupções do serviço.

ASP-5 - Habilite o dimensionamento automático/automático para garantir que os recursos adequados estejam disponíveis para solicitações de serviço

É recomendável habilitar o dimensionamento automático/automático para o Serviço de Aplicativo do Azure para garantir que recursos suficientes estejam disponíveis para lidar com solicitações de entrada. O dimensionamento automático é o dimensionamento baseado em regras, enquanto o dimensionamento automático executa o dimensionamento automático de entrada e saída com base no tráfego HTTP. Para obter mais informações, consulte o dimensionamento automático no Serviço de Aplicativo do Azure ou comece a usar o dimensionamento automático no Azure.

// under-development

Suporte à zona de disponibilidade

As zonas de disponibilidade do Azure são pelo menos três grupos fisicamente separados de datacenters em cada região do Azure. Os datacenters dentro de cada zona são equipados com infraestrutura independente de energia, resfriamento e rede. No caso de uma falha de zona local, as zonas de disponibilidade são projetadas de modo que, se uma zona for afetada, os serviços regionais, a capacidade e a alta disponibilidade sejam suportados pelas duas zonas restantes.

As falhas podem variar de falhas de software e hardware a eventos como terremotos, inundações e incêndios. A tolerância a falhas é alcançada com redundância e isolamento lógico dos serviços do Azure. Para obter informações mais detalhadas sobre zonas de disponibilidade no Azure, consulte Regiões e zonas de disponibilidade.

Os serviços habilitados para zonas de disponibilidade do Azure são projetados para fornecer o nível certo de confiabilidade e flexibilidade. Eles podem ser configurados de duas maneiras. Eles podem ser redundantes de zona, com replicação automática entre zonas, ou zonais, com instâncias fixadas a uma zona específica. Você também pode combinar essas abordagens. Para obter mais informações sobre arquitetura zonal versus arquitetura com redundância de zona, consulte Recomendações para usar zonas e regiões de disponibilidade.

O Serviço de Aplicativo do Azure pode ser implantado em zonas de disponibilidade (AZ) para ajudá-lo a obter resiliência e confiabilidade para suas cargas de trabalho críticas para os negócios. Essa arquitetura também é conhecida como redundância de zona.

Quando você configura o Serviço de Aplicativo como zona redundante, a plataforma distribui automaticamente as instâncias do plano do Serviço de Aplicativo do Azure 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 Plano do Serviço de Aplicativo é três.
  • Se você especificar uma capacidade maior que três e o número de instâncias for divisível por três, as instâncias serão distribuídas uniformemente.
  • Qualquer contagem de instâncias além de 3*N está espalhada pelas zonas restantes.

O suporte à zona de disponibilidade é uma propriedade do plano do Serviço de Aplicativo. Os planos do Serviço de Aplicativo podem ser criados em ambiente gerenciado multilocatário ou ambiente dedicado usando o Ambiente do Serviço de Aplicativo v3. Para saber mais sobre o Ambiente do Serviço de Aplicativo v3, consulte Visão geral do Ambiente do Serviço de Aplicativo v3.

Para os Serviços de Aplicativo que não estão configurados para serem redundantes de zona, as instâncias de VM não são resilientes à zona e podem enfrentar tempo de inatividade durante uma interrupção em qualquer zona dessa região.

Para obter informações sobre a arquitetura de implantação corporativa, consulte Implantação corporativa de alta disponibilidade usando o Ambiente do Serviço de Aplicativo.

Pré-requisitos

Os requisitos/limitações atuais para habilitar zonas de disponibilidade são:

  • Tanto o Windows como o Linux são suportados.

  • As zonas de disponibilidade só são suportadas na pegada mais recente do Serviço de Aplicativo. Mesmo que esteja a utilizar uma das regiões suportadas, receberá um erro se as zonas de disponibilidade não forem suportadas para o seu grupo de recursos. Para garantir que suas cargas de trabalho cheguem a um carimbo que ofereça suporte a zonas de disponibilidade, talvez seja necessário criar um novo grupo de recursos, um plano do Serviço de Aplicativo e um Serviço de Aplicativo.

  • Seu plano dos Serviços de Aplicativo deve ser um dos seguintes planos que oferecem suporte a zonas de disponibilidade:

    • Em um ambiente multilocatário usando os planos do Serviço de Aplicativo Premium v2 ou Premium v3.
    • Em um ambiente dedicado usando o Ambiente do Serviço de Aplicativo v3, que é usado com os planos do Serviço de Aplicativo Isolado v2.
  • Para ambientes dedicados, seu Ambiente do Serviço de Aplicativo deve ser v3.

    Importante

    O Ambiente do Serviço de Aplicativo v2 e v1 será desativado em 31 de agosto de 2024. O Ambiente do Serviço de Aplicativo v3 é mais fácil de usar e é executado em uma infraestrutura mais poderosa. Para saber mais sobre o Ambiente do Serviço de Aplicativo v3, consulte Visão geral do Ambiente do Serviço de Aplicativo. Se você estiver usando o Ambiente do Serviço de Aplicativo v2 ou v1 e quiser atualizar para a v3, siga as etapas neste artigo para migrar para a nova versão.

  • A contagem mínima de instâncias de três zonas é imposta. A plataforma aplicará essa contagem mínima nos bastidores se você especificar uma contagem de instâncias inferior a três.

  • As zonas de disponibilidade só podem ser especificadas ao criar um novo plano do Serviço de Aplicativo. Um plano do Serviço de Aplicativo pré-existente não pode ser convertido para usar zonas de disponibilidade.

  • As seguintes regiões dão suporte aos Serviços de Aplicativo do Azure executados em ambientes multilocatário:

    • Leste da Austrália
    • Sul do Brasil
    • Canadá Central
    • Índia Central
    • E.U.A. Central
    • Ásia Leste
    • E.U.A. Leste
    • E.U.A. Leste 2
    • França Central
    • Alemanha Centro-Oeste
    • Leste do Japão
    • Coreia do Sul Central
    • Europa do Norte
    • Leste da Noruega
    • Polónia Central
    • Catar Central
    • Norte da África do Sul
    • E.U.A. Centro-Sul
    • Sudeste Asiático
    • Suécia Central
    • Norte da Suíça
    • Norte dos E.A.U.
    • Sul do Reino Unido
    • Europa Ocidental
    • E.U.A. Oeste 2
    • EUA Oeste 3
    • Microsoft Azure operado pela 21Vianet - China North 3
    • Azure Government - Governo dos EUA Virgínia
  • Para ver quais regiões oferecem suporte a zonas de disponibilidade para o Ambiente do Serviço de Aplicativo v3, consulte Regiões.

Criar um recurso com a zona de disponibilidade ativada

Para implantar um Serviço de Aplicativo com redundância de zona multilocatário

Para habilitar zonas de disponibilidade usando a CLI do Azure, inclua o --zone-redundant parâmetro ao criar seu plano do Serviço de Aplicativo. Você também pode incluir o parâmetro para especificar a --number-of-workers capacidade. Se você não especificar uma capacidade, o padrão da plataforma será três. A capacidade deve ser definida com base no requisito de carga de trabalho, mas não inferior a três. Uma boa regra geral para escolher a capacidade é garantir instâncias suficientes para o aplicativo, de modo que a perda de uma zona de instâncias deixe capacidade suficiente para lidar com a carga esperada.

az appservice plan create --resource-group MyResourceGroup --name MyPlan --sku P1v2 --zone-redundant --number-of-workers 6

Gorjeta

Para decidir a capacidade da instância, você pode usar o seguinte cálculo:

Como a plataforma distribui VMs por três zonas e você precisa levar em conta pelo menos a falha de uma zona, multiplique a contagem de instâncias de pico de carga de trabalho por um fator de zonas/(zonas-1) ou 3/2. Por exemplo, se sua carga de trabalho de pico típica requer quatro instâncias, você deve provisionar seis instâncias: (2/3 * 6 instâncias) = 4 instâncias.

Implantar um Serviço de Aplicativo com redundância de zona usando um ambiente dedicado

Para saber como criar um Ambiente do Serviço de Aplicativo v3 no plano Isolado v2, consulte Criar um Ambiente do Serviço de Aplicativo.

Resolução de Problemas

Mensagem de erro Description Recomendação
A redundância de zona não está disponível para o grupo de recursos 'RG-NAME'. Implante o plano de serviço de aplicativo 'ASP-NAME' em um novo grupo de recursos. As zonas de disponibilidade só são suportadas na pegada mais recente do Serviço de Aplicativo. Mesmo que esteja a utilizar uma das regiões suportadas, receberá um erro se as zonas de disponibilidade não forem suportadas para o seu grupo de recursos. Para garantir que suas cargas de trabalho cheguem a um carimbo que ofereça suporte a zonas de disponibilidade, crie um novo grupo de recursos, um plano do Serviço de Aplicativo e um Serviço de Aplicativo.

Tolerância a falhas

Para se preparar para falhas na zona de disponibilidade, você deve provisionar excessivamente a capacidade de serviço para garantir que a solução possa tolerar 1/3 de perda de capacidade e continuar a funcionar sem desempenho degradado durante interrupções em toda a zona. Como a plataforma distribui VMs por três zonas e você precisa levar em conta pelo menos a falha de uma zona, multiplique a contagem de instâncias de pico de carga de trabalho por um fator de zonas/(zonas-1) ou 3/2. Por exemplo, se sua carga de trabalho de pico típica requer quatro instâncias, você deve provisionar seis instâncias: (2/3 * 6 instâncias) = 4 instâncias.

Experiência de zoneamento

O tráfego é roteado para todas as instâncias disponíveis do Serviço de Aplicativo. No caso de uma zona ficar inativa, a plataforma do Serviço de Aplicativo detetará instâncias perdidas e tentará automaticamente encontrar novas instâncias de substituição e espalhar o tráfego conforme necessário. Se você tiver configurado o dimensionamento automático e decidir que mais instâncias são necessárias, o dimensionamento automático também emitirá uma solicitação ao Serviço de Aplicativo para adicionar mais instâncias. Observe que o comportamento de dimensionamento automático é independente do comportamento da plataforma do Serviço de Aplicativo e que sua especificação de contagem de instâncias de dimensionamento automático não precisa ser um múltiplo de três.

Nota

Não há garantia de que as solicitações de instâncias adicionais em um cenário de zone-down sejam bem-sucedidas. O preenchimento de instâncias perdidas ocorre com base no melhor esforço. A solução recomendada é criar e configurar seus planos do Serviço de Aplicativo para contabilizar a perda de uma zona, conforme descrito na próxima seção.

Os aplicativos implantados em um plano do Serviço de Aplicativo com zonas de disponibilidade habilitadas continuarão a ser executados e a atender tráfego mesmo que outras zonas na mesma região sofram uma interrupção. No entanto, é possível que comportamentos sem tempo de execução, incluindo o dimensionamento do plano do Serviço de Aplicativo, a criação de aplicativos, a configuração de aplicativos e a publicação de aplicativos, ainda possam ser afetados por uma interrupção em outras zonas de disponibilidade. A redundância de zona para planos do Serviço de Aplicativo garante apenas o tempo de atividade contínuo para aplicativos implantados.

Quando a plataforma do Serviço de Aplicativo aloca instâncias a um plano de Serviço de Aplicativo redundante de zona, ela usa o melhor balanceamento de zona de esforço oferecido pelos Conjuntos de Escala de Máquina Virtual do Azure subjacentes. Um plano do Serviço de Aplicativo será "equilibrado" se cada zona tiver o mesmo número de VMs ou +/- uma VM em todas as outras zonas usadas pelo plano do Serviço de Aplicativo.

Migração da zona de disponibilidade

Não é possível migrar instâncias existentes do Serviço de Aplicativo ou recursos de ambiente do suporte à zona de indisponibilidade para o suporte à zona de disponibilidade. Para obter suporte para zonas de disponibilidade, você precisará criar seus recursos com as zonas de disponibilidade habilitadas.

Preços

Não há custo adicional associado à ativação de zonas de disponibilidade. O preço de um Serviço de Aplicativo redundante de zona é o mesmo de um Serviço de Aplicativo de zona única. Você será cobrado com base na SKU do seu plano do Serviço de Aplicativo, na capacidade especificada e em todas as instâncias para as quais você dimensionar com base em seus critérios de dimensionamento automático. Se você habilitar zonas de disponibilidade, mas especificar uma capacidade inferior a três, a plataforma imporá uma contagem mínima de instâncias de três e cobrará por essas três instâncias. Para obter informações sobre preços para o Ambiente do Serviço de Aplicativo v3, consulte Preços.

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 aborda algumas estratégias comuns para aplicativos Web implantados no Serviço de Aplicativo.

Quando você cria um aplicativo Web no Serviço de Aplicativo e escolhe uma região do Azure durante a criação de recursos, é um aplicativo de região única. Quando a região fica indisponível durante um desastre, seu aplicativo também fica indisponível. Se você criar uma implantação idêntica em uma região secundária do Azure usando uma arquitetura de geografia de várias regiões, seu aplicativo se tornará menos suscetível a um desastre de região única, o que garante a continuidade dos negócios. Qualquer replicação de dados entre as regiões permite recuperar o estado do último aplicativo.

Para a TI, os planos de continuidade de negócios são em grande parte orientados pelo RTO (Recovery Time Objetive, objetivo de tempo de recuperação) e pelo RPO (Recovery Point Objetive, objetivo de ponto de recuperação). Para obter mais informações sobre RTO e RPO, consulte Objetivos de recuperação.

Normalmente, manter um SLA em torno do RTO é impraticável para desastres regionais, e você normalmente projetaria sua estratégia de recuperação de desastres apenas em torno do RPO (ou seja, concentre-se na recuperação de dados e não na minimização da interrupção). Com o Azure, no entanto, não é apenas prático, mas pode até ser simples implantar o Serviço de Aplicativo para failover geográfico automático. Isso permite que você proteja ainda mais seus aplicativos contra desastres, cuidando tanto do RTO quanto do RPO.

Dependendo das métricas de RTO e RPO desejadas, três arquiteturas de recuperação de desastres são comumente usadas para ambientes multilocatários e de Serviço de Aplicativo do Serviço de Aplicativo. Cada arquitetura é descrita na tabela a seguir:

Metric Ativo-Ativo Ativo-Passivo Passivo/Frio
RTO Em tempo real ou segundos Minutos Horas
RPO Em tempo real ou segundos Minutos Horas
Custo $$$ $$ $
Cenários Aplicativos de missão crítica Aplicativos de alta prioridade Aplicativos de baixa prioridade
Capacidade de atender ao tráfego de usuários de várias regiões Sim Sim/talvez Não
Implementação de código Pipelines de CI/CD preferidos Pipelines de CI/CD preferidos Cópia de segurança e restauro
Criação de novos recursos do Serviço de Aplicativo durante o tempo de inatividade Não obrigatório Não obrigatório Necessário

Nota

Seu aplicativo provavelmente depende de outros serviços de dados no Azure, como o Banco de Dados SQL do Azure e as contas de Armazenamento do Azure. É recomendável que você desenvolva estratégias de recuperação de desastres para cada um desses Serviços do Azure dependentes. Para Banco de Dados SQL, consulte Replicação geográfica ativa para o Banco de Dados SQL do Azure. Para o Armazenamento do Azure, consulte Redundância do Armazenamento do Azure.

Recuperação de desastres em geografia de várias regiões

Há várias maneiras de replicar o conteúdo e as configurações de seus aplicativos Web em regiões do Azure em uma arquitetura ativa-ativa ou ativa-passiva, como usar o backup e a restauração do Serviço de aplicativo. No entanto, o backup e a restauração criam instantâneos point-in-time e, eventualmente, levam a desafios de controle de versão de aplicativos Web entre regiões. Consulte a tabela a seguir para obter uma comparação entre as diretrizes de retorno e restauração versus as diretrizes de recuperação de diaster:

Backup e restauração vs. recuperação de desastres

Plataforma Orientação de backup e restauração Documentação de orientação da recuperação após desastre
Aplicações Web do Serviço de Aplicações
(Nível de Preços Partilhados e Gratuitos)
Se você tiver aplicativos Web implantados na camada Gratuita ou Compartilhada e precisar de acesso aos recursos de Backup e Restauração para esses aplicativos Web, aumente para a camada Básica ou superior. Coloque os recursos do Serviço de Aplicativo online novamente em uma região diferente do Azure durante um desastre regional.

A partir de 31 de março de 2025, os aplicativos do Serviço de Aplicativo não serão colocados no modo de recuperação de desastres durante um desastre em uma região do Azure, conforme explicado no artigo Recuperar de falha em toda a região. Recomenda-se implementar técnicas de recuperação de desastres comumente usadas para evitar tempo de inatividade e perda de dados durante um desastre regional.
Aplicações Web do Serviço de Aplicações
(Nível de preços Básico\Padrão\Premium)
No Serviço de Aplicativo do Azure, você pode fazer backups personalizados sob demanda ou utilizar backups automáticos. Você pode restaurar um backup substituindo um aplicativo existente restaurando para um novo aplicativo ou slot.

Consulte Fazer backup e restaurar seu aplicativo no Serviço de Aplicativo do Azure para obter mais informações.
As diretrizes atuais sobre como colocar os recursos do Serviço de Aplicativo online novamente em uma região diferente do Azure durante um desastre regional estão disponíveis em Recuperar de falha em toda a região - Serviço de Aplicativo do Azure.

A partir de 31 de março de 2025, os aplicativos Web do Serviço de Aplicativo do Azure não serão mais colocados no modo de recuperação de desastres durante um desastre em uma região do Azure, conforme explicado no artigo Recuperar de falha em toda a região. Recomendamos que você implemente técnicas de recuperação de desastres comumente usadas para evitar a perda de funcionalidade ou dados para seus aplicativos Web se houver um desastre regional.
Ambiente do Serviço de Aplicativo (V2 & V3) No Ambiente do Serviço de Aplicativo do Azure, você pode fazer backups personalizados sob demanda ou utilizar backups automáticos. Os backups automáticos podem ser restaurados para um aplicativo de destino dentro do mesmo ASE, não em outro ASE. Os backups personalizados podem ser restaurados para um aplicativo de destino em outro ASE (como de um ASE V2 para um ASE V3). Os backups podem ser restaurados para o aplicativo de destino da mesma plataforma de sistema operacional que o aplicativo de origem.

Consulte Fazer backup e restaurar seu aplicativo no Serviço de Aplicativo do Azure para obter mais detalhes.
Recomendamos que você implemente diretrizes de recuperação de desastres para aplicativos Web implantados no Ambiente do Serviço de Aplicativo usando técnicas de recuperação de desastres comumente usadas.
Azure Functions (dedicado) No Azure Functions, você pode fazer backups personalizados sob demanda ou utilizar backups automáticos. Você pode restaurar um backup substituindo um aplicativo existente restaurando para um novo aplicativo ou slot.

Consulte Fazer backup e restaurar seu aplicativo no Serviço de Aplicativo do Azure para obter mais informações.
As diretrizes atuais sobre como colocar os recursos (dedicados) do aplicativo Azure Functions online novamente em uma região diferente do Azure durante um desastre regional estão disponíveis em Recuperar de falha em toda a região - Serviço de Aplicativo do Azure.

A partir de 31 de março de 2025, os aplicativos do Serviço de Aplicativo não serão colocados no modo de recuperação de desastres durante um desastre em uma região do Azure, conforme explicado no artigo Recuperar de falha em toda a região. Em vez disso, implemente a recuperação de desastres geográficos do Azure Functions.

Além disso, você também pode consultar técnicas de recuperação de desastres comumente usadas para o Azure Functions dedicado.
Consumo do Azure Functions & Premium As funções do Azure implantadas em planos de consumo e premium não fornecem acesso a backups personalizados e automáticos. O conteúdo do aplicativo de função está em uma conta de armazenamento do Azure. Use as opções de redundância do Armazenamento do Azure para garantir que sua conta de armazenamento atenda às metas de disponibilidade e durabilidade durante uma interrupção.

Se você criou suas funções usando o editor no portal do Azure, também poderá baixar seu projeto de aplicativo de função existente como um arquivo .zip.
Recomendamos vivamente que implemente a recuperação e fiabilidade de desastres geográficos do Azure Functions.

Para evitar as limitações dos métodos de backup e restauração, configure seus pipelines de CI/CD para implantar código em ambas as regiões do Azure. Considere usar o Azure Pipelines ou as Ações do GitHub. Para obter mais informações, consulte Implantação contínua no Serviço de Aplicativo do Azure.

Deteção, notificação e gerenciamento de interrupções

  • É recomendável que você configure o monitoramento e os alertas para seus aplicativos Web para notificações oportunas durante um desastre. Para obter mais informações, consulte Testes de disponibilidade do Application Insights.

  • Para gerenciar seus recursos de aplicativo no Azure, use um mecanismo de infraestrutura como código (IaC). Em uma implantação complexa em várias regiões, gerenciar as regiões de forma independente e manter a configuração sincronizada entre regiões de maneira confiável requer um processo previsível, testável e repetível. Considere uma ferramenta IaC, como modelos do Azure Resource Manager ou Terraform.

Configurar a recuperação de desastres e a deteção de interrupções

Para se preparar para a recuperação de desastres em uma geografia de várias regiões, você pode usar uma arquitetura ativa-ativa ou ativa-passiva.

Arquitetura Ativo-Ativo

Na arquitetura de recuperação de desastres ativo-ativo, aplicativos Web idênticos são implantados em duas regiões separadas e a porta frontal do Azure é usada para rotear o tráfego para ambas as regiões ativas.

Diagrama que mostra uma implantação ativa-ativa do Serviço de Aplicativo.

Com este exemplo de arquitetura:

  • Aplicativos idênticos do Serviço de Aplicativo são implantados em duas regiões separadas, incluindo a camada de preços e a contagem de instâncias.
  • O tráfego público diretamente para os aplicativos do Serviço de Aplicativo está bloqueado.
  • O Azure Front Door é usado para rotear o tráfego para ambas as regiões ativas.
  • Durante um desastre, uma das regiões fica offline e o Azure Front Door encaminha o tráfego exclusivamente para a região que permanece online. O RTO durante esse failover geográfico é quase zero.
  • Os arquivos de aplicativo devem ser implantados em ambos os aplicativos Web com uma solução de CI/CD. Isso garante que o RPO seja praticamente zero.
  • Se seu aplicativo modifica ativamente o sistema de arquivos, a melhor maneira de minimizar o RPO é gravar apenas em um compartilhamento de Armazenamento do Azure montado em vez de gravar diretamente no compartilhamento de conteúdo /home do aplicativo Web. Em seguida, use os recursos de redundância do Armazenamento do Azure (GZRS ou GRS) para seu compartilhamento montado, que tem um RPO de cerca de 15 minutos.

As etapas para criar uma arquitetura ativa-ativa para seu aplicativo Web no Serviço de Aplicativo são resumidas da seguinte forma:

  1. Crie dois planos do Serviço de Aplicativo em duas regiões diferentes do Azure. Configure os dois planos do Serviço de Aplicativo de forma idêntica.

  2. Crie duas instâncias do seu aplicativo Web, com uma em cada plano do Serviço de Aplicativo.

  3. Crie um perfil do Azure Front Door com:

    • Um ponto final.
    • Dois grupos de origem, cada um com uma prioridade de 1. A prioridade igual diz ao Azure Front Door para rotear o tráfego para ambas as regiões igualmente (portanto, ativo-ativo).
    • Uma rota.
  4. Limite o tráfego de rede para os aplicativos Web somente da instância do Azure Front Door.

  5. Configure todos os outros serviços back-end do Azure, como bancos de dados, contas de armazenamento e provedores de autenticação.

  6. Implante código em ambos os aplicativos Web com implantação contínua.

Tutorial: Criar um aplicativo multirregião altamente disponível no Serviço de Aplicativo do Azure mostra como configurar uma arquitetura ativa-passiva . As mesmas etapas com alterações mínimas (definindo prioridade como "1" para ambas as origens no grupo de origem no Azure Front Door) oferecem uma arquitetura ativa-ativa.

Arquitetura ativo-passivo

Nessa abordagem de recuperação de desastres, aplicativos Web idênticos são implantados em duas regiões separadas e a porta frontal do Azure é usada para rotear o tráfego para apenas uma região (a região ativa ).

Um diagrama mostrando uma arquitetura ativo-passivo do Serviço de Aplicativo do Azure.

Com este exemplo de arquitetura:

  • Aplicativos idênticos do Serviço de Aplicativo são implantados em duas regiões separadas.

  • O tráfego público diretamente para os aplicativos do Serviço de Aplicativo está bloqueado.

  • O Azure Front Door é usado para rotear o tráfego para a região principal.

  • Para economizar custos, o plano secundário do Serviço de Aplicativo é configurado para ter menos instâncias e/ou estar em uma camada de preço mais baixa. Existem três abordagens possíveis:

    • Preferencial O plano secundário do Serviço de Aplicativo tem o mesmo nível de preço do principal, com o mesmo número de instâncias ou menos. Essa abordagem garante paridade no dimensionamento de recursos e VMs para os dois planos do Serviço de Aplicativo. O RTO durante um failover geográfico depende apenas do tempo de dimensionamento das instâncias.

    • Menos preferido O plano secundário do Serviço de Aplicativo tem o mesmo tipo de camada de preço (como PremiumV3), mas dimensionamento de VM menor, com instâncias menores. Por exemplo, a região primária pode estar na camada P3V3 enquanto a região secundária está na camada P1V3. Essa abordagem ainda garante a paridade de recursos para os dois planos do Serviço de Aplicativo, mas a falta de paridade de tamanho pode exigir uma expansão manual quando a região secundária se tornar a região ativa. O RTO durante um failover geográfico depende do tempo para aumentar e expandir as instâncias.

    • Menos preferido O plano secundário do Serviço de Aplicativo tem um nível de preço diferente das instâncias principal e menor. Por exemplo, a região primária pode estar na camada P3V3 enquanto a região secundária está na camada S1. Verifique se o plano secundário do Serviço de Aplicativo tem todos os recursos de que seu aplicativo precisa para ser executado. Diferenças na disponibilidade de recursos entre os dois podem causar atrasos na recuperação do seu aplicativo Web. O RTO durante um failover geográfico depende do tempo para aumentar e expandir as instâncias.

  • O dimensionamento automático é configurado na região secundária caso a região ativa fique inativa. É aconselhável ter regras de escala automática semelhantes em regiões ativas e passivas.

  • Durante um desastre, a região primária torna-se inativa e a região secundária começa a receber tráfego e torna-se a região ativa.

  • Quando a região secundária se torna ativa, a carga de rede aciona regras de dimensionamento automático pré-configuradas para expandir o aplicativo Web secundário.

  • Talvez seja necessário aumentar manualmente o nível de preços para a região secundária, se ela ainda não tiver os recursos necessários para ser executada como a região ativa. Por exemplo, o dimensionamento automático requer a camada Standard ou superior.

  • Quando a região primária está ativa novamente, o Azure Front Door direciona automaticamente o tráfego de volta para ela, e a arquitetura volta para ativo-passivo como antes.

  • Os arquivos de aplicativo devem ser implantados em ambos os aplicativos Web com uma solução de CI/CD. Isso garante que o RPO seja praticamente zero.

  • Se seu aplicativo modifica ativamente o sistema de arquivos, a melhor maneira de minimizar o RPO é gravar apenas em um compartilhamento de Armazenamento do Azure montado em vez de gravar diretamente no compartilhamento de conteúdo /home do aplicativo Web. Em seguida, use os recursos de redundância do Armazenamento do Azure (GZRS ou GRS) para seu compartilhamento montado, que tem um RPO de cerca de 15 minutos.

As etapas para criar uma arquitetura ativo-passivo para seu aplicativo Web no Serviço de Aplicativo são resumidas da seguinte forma:

  1. Crie dois planos do Serviço de Aplicativo em duas regiões diferentes do Azure. O plano secundário do Serviço de Aplicativo pode ser provisionado usando uma das abordagens mencionadas anteriormente.
  2. Configure regras de dimensionamento automático para o plano do Serviço de Aplicativo secundário para que ele seja dimensionado para a mesma contagem de instâncias que o primário quando a região primária ficar inativa.
  3. Crie duas instâncias do seu aplicativo Web, com uma em cada plano do Serviço de Aplicativo.
  4. Crie um perfil do Azure Front Door com:
    • Um ponto final.
    • Um grupo de origem com prioridade de 1 para a região primária.
    • Um segundo grupo de origem com prioridade de 2 para a região secundária. A diferença de prioridade diz ao Azure Front Door para preferir a região principal quando está online (portanto, ativo-passivo).
    • Uma rota.
  5. Limite o tráfego de rede para os aplicativos Web somente da instância do Azure Front Door.
  6. Configure todos os outros serviços back-end do Azure, como bancos de dados, contas de armazenamento e provedores de autenticação.
  7. Implante código em ambos os aplicativos Web com implantação contínua.

Tutorial: Criar um aplicativo multirregião altamente disponível no Serviço de Aplicativo do Azure mostra como configurar uma arquitetura ativa-passiva .

Arquitetura passiva-fria

Use uma arquitetura passiva/fria para criar e manter backups regulares de seus aplicativos Web em uma conta de Armazenamento do Azure localizada em outra região.

Com este exemplo de arquitetura:

  • Um único aplicativo Web é implantado em uma única região.

  • O backup do aplicativo Web é feito regularmente em uma conta de Armazenamento do Azure na mesma região.

  • A replicação entre regiões de seus backups depende da configuração de redundância de dados na conta de armazenamento do Azure. Você deve definir sua conta de Armazenamento do Azure como GZRS , se possível. O GZRS oferece redundância de zona síncrona dentro de uma região e assíncrona em uma região secundária. Se GZRS não estiver disponível, configure a conta como GRS. Tanto o GZRS quanto o GRS têm um RPO de cerca de 15 minutos.

  • Para garantir que você possa recuperar backups quando a região primária da conta de armazenamento ficar indisponível, habilite o acesso somente leitura à região secundária (tornando a conta de armazenamento RA-GZRS ou RA-GRS, respectivamente). Para obter mais informações sobre como projetar seus aplicativos para aproveitar a redundância geográfica, consulte Usar redundância geográfica para projetar aplicativos altamente disponíveis.

  • Durante um desastre na região do aplicativo Web, você deve implantar manualmente todos os recursos dependentes do Serviço de Aplicativo necessários usando os backups da conta de Armazenamento do Azure, provavelmente da região secundária com acesso de leitura. O RTO pode ser de horas ou dias.

  • Para minimizar o RTO, é altamente recomendável que você tenha um manual abrangente descrevendo todas as etapas necessárias para restaurar o backup do aplicativo Web para outra Região do Azure.

As etapas para criar uma região fria passiva para seu aplicativo Web no Serviço de Aplicativo são resumidas da seguinte forma:

  1. Crie uma conta de armazenamento do Azure na mesma região do seu aplicativo Web. Escolha a camada de desempenho padrão e selecione redundância como armazenamento com redundância geográfica (GRS) ou armazenamento com redundância de zona geográfica (GZRS).

  2. Habilite RA-GRS ou RA-GZRS (acesso de leitura para a região secundária).

  3. Configure o backup personalizado para seu aplicativo Web. Você pode decidir definir um cronograma para os backups do seu aplicativo Web, como por hora.

  4. Verifique se os arquivos de backup do aplicativo Web podem ser recuperados na região secundária da sua conta de armazenamento.

Gorjeta

Além do Azure Front Door, o Azure fornece outras opções de balanceamento de carga, como o Azure Traffic Manager. Para obter uma comparação das várias opções, consulte Opções de balanceamento de carga - Central de Arquitetura do Azure.

Recuperação de desastres em geografia de uma única região

Se a região do seu aplicativo Web não tiver armazenamento GZRS ou GRS ou se você estiver em uma região do Azure que não faça parte de um par regional, precisará utilizar o armazenamento com redundância de zona (ZRS) ou o armazenamento com redundância local (LRS) para criar uma arquitetura semelhante. Por exemplo, você pode criar manualmente uma região secundária para a conta de armazenamento da seguinte maneira:

Diagrama que mostra como criar uma região passiva ou fria sem GRS ou GZRS.

As etapas para criar uma região de frio passivo sem GRS e GZRS são resumidas da seguinte forma:

  1. Crie uma conta de armazenamento do Azure na mesma região do seu aplicativo Web. Escolha a camada de desempenho padrão e selecione redundância como armazenamento com redundância de zona (ZRS).

  2. Configure o backup personalizado para seu aplicativo Web. Você pode decidir definir um cronograma para os backups do seu aplicativo Web, como por hora.

  3. Verifique se os arquivos de backup do aplicativo Web podem ser recuperados na região secundária da sua conta de armazenamento.

  4. Crie uma segunda conta de armazenamento do Azure em uma região diferente. Escolha a camada de desempenho padrão e selecione redundância como LRS (armazenamento com redundância local).

  5. Usando uma ferramenta como o AzCopy, replique seu backup personalizado (Zip, XML e arquivos de log) da região primária para o armazenamento secundário. Por exemplo:

    azcopy copy 'https://<source-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>' 'https://<destination-storage-account-name>.blob.core.windows.net/<container-name>/<blob-path>'
    

    Você pode usar a Automação do Azure com um runbook de fluxo de trabalho do PowerShell para executar seu script de replicação em uma agenda. Certifique-se de que o agendamento de replicação siga um cronograma semelhante aos backups do aplicativo Web.

Próximos passos