Confiabilidade no Serviço de Aplicativo do Azure
Este artigo descreve o suporte à confiabilidade no Serviço de Aplicativo do Azure e aborda a resiliência intra-regional com zonas de disponibilidade e recuperação de desastre entre regiões e continuidade dos negócios. Para obter uma visão geral mais detalhada dos princípios de confiabilidade no Azure, confira Confiabilidade do Azure.
O 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
- Gerenciamento automatizado
Para ver como o Serviço de Aplicativo do Azure pode reforçar a confiabilidade e a resiliência da carga de trabalho do seu aplicativo, confira Por que usar o Serviço de Aplicativo?
Recomendações de confiabilidade
Essa seção contém recomendações para obter resiliência e disponibilidade. Cada recomendação se enquadra em uma das duas categorias:
Os itens de integridade abrangem áreas como itens de configuração e a função adequada dos principais componentes que compõem a carga de trabalho do Azure, como configurações 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, teste, monitoramento, implantação e outros itens que, se deixados não resolvidos, aumentam as chances de problemas no ambiente.
Matriz de prioridade de recomendações de confiabilidade
Cada recomendação é marcada de acordo com a seguinte matriz de prioridade:
| Imagem | Prioridade | Descrição |
|---|---|---|
|
Alto | Correção imediata necessária. |
|
Médio | Correção dentro de 3 a 6 meses. |
|
Baixo | Precisa de revisão. |
Resumo das recomendações de confiabilidade
Alta disponibilidade
ASP-1 - Implantar planos do App Service redundantes por zona
Para aprimorar a resiliência e a confiabilidade de suas cargas de trabalho comercialmente críticas, é recomendável implantar novos planos do Serviço de Aplicativo com redundância de zona. Siga as etapas para reimplantar o suporte à zona de disponibilidade, configurar seus pipelines para reimplantar seu WebApp no novo Plano dos Serviços de Aplicativos e, em seguida, usar uma abordagem de implantação Azul-Verde para failover para o novo site.
Ao distribuir seus aplicativos entre várias zonas de disponibilidade, você pode garantir a continuação da operação, 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 App Service que ofereça suporte a zonas de disponibilidade
O suporte à zona de disponibilidade só está disponível em determinados planos de 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 - Criar planos separados do App Service para produção e teste
Para aprimorar a resiliência e a confiabilidade de suas cargas de trabalho comercialmente críticas, você deve migrar seus planos de Serviço de Aplicativo existentes e ambientes de Serviço de Aplicativo para o suporte à zona de disponibilidade. Ao distribuir seus aplicativos entre várias zonas de disponibilidade, você pode garantir a continuação da operação, 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 - Evitar aumentar ou reduzir a escala com frequência
É recomendável evitar escalar ou reduzir verticalmente com frequência suas instâncias de Serviço de Aplicativo do Azure. Em vez disso, escolha uma camada apropriada e um tamanho de instância que possa lidar com sua carga de trabalho típica e escale horizontalmente as instâncias para acomodar alterações no volume de tráfego. Escalar ou reduzir verticalmente pode potencialmente disparar uma reinicialização do aplicativo, o que pode resultar em interrupções de serviço.
ASP-5 - Ative o dimensionamento automático para garantir que os recursos adequados estejam disponíveis para atender às solicitações
É recomendável que você habilite o dimensionamento automático/automático para seu 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 é baseado em regra, 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 Dimensionamento automático em Serviço de Aplicativo do Azure ou introdução ao dimensionamento automático no Azure.
// under-development
Suporte à zona de disponibilidade
As zonas de disponibilidade do Azure são pelo menos três grupos de datacenters separados fisicamente em cada região do Azure. Os datacenters dentro de cada zona são equipados com energia, resfriamento e infraestrutura de rede independentes. Em caso de falha de uma zona local, as zonas de disponibilidade foram projetadas de modo que, se uma zona é afetada, os serviços regionais, a capacidade e a alta disponibilidade têm suporte nas 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 é obtida devido à redundância e ao isolamento lógico dos serviços do Azure. Para obter informações detalhadas sobre as zonas de disponibilidade no Azure, confira Regiões e zonas de disponibilidade.
Os serviços habilitados para zonas de disponibilidade do Azure foram projetados para fornecer o nível ideal de resiliência e flexibilidade. Eles podem ser configurados de duas maneiras. Eles podem ter redundância de zona, com replicação automática entre zonas, ou podem ser zonais, com instâncias fixadas em uma zona específica. Você também pode combinar essas abordagens. Para obter mais informações sobre a arquitetura zonal versus com redundância de zona, confira Recomendações para usar zonas e regiões de disponibilidade.
O Serviço de Aplicativo do Azure pode ser implantado entre AZs (zonas de disponibilidade) para ajudar a alcançar resiliência e confiabilidade para cargas de trabalho comercialmente críticas. Essa arquitetura também é conhecida como redundância de zona.
Quando você configura o Serviço de Aplicativo para que ele tenha redundância de zona, a plataforma distribui automaticamente as instâncias do Plano do Serviço de Aplicativo do Azure entre três zonas na região selecionada.
A distribuição de instâncias com uma implantação com redundância de zona é determinada com base nas seguintes regras, mesmo quando o aplicativo é reduzido ou escalado horizontalmente:
- A contagem mínima de instâncias do Plano do Serviço de Aplicativo é três.
- Se 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.
- As contagens de instâncias além de 3*N são distribuídas entre a única ou as duas zonas restantes.
O suporte a zonas de disponibilidade é uma propriedade do Plano do Serviço de Aplicativo. Planos do Serviço de Aplicativo podem ser criados em ambientes multilocatário gerenciados ou ambientes dedicados usando o Ambiente do Serviço de Aplicativo v3. Para saber mais sobre o Ambiente do Serviço de Aplicativo, consulte Visão geral do Ambiente do Serviço de Aplicativo v3.
Para os Serviços de Aplicativos que não estão configurados para ter redundância 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 nessa região.
Para obter informações sobre a arquitetura de implantação corporativa, consulte Implantação empresarial de alta disponibilidade usando Ambiente do Serviço de Aplicativo.
Pré-requisitos
Os requisitos/limitações atuais para habilitar zonas de disponibilidade são:
Há suporte para os aplicativos Windows e Linux.
As zonas de disponibilidade só têm suporte no volume mais recente do Serviço de Aplicativo. Mesmo se você estiver usando uma das regiões com suporte, receberá um erro se as zonas de disponibilidade não tiverem suporte para o grupo de recursos. Para garantir que suas cargas de trabalho cheguem em um carimbo que dê suporte a zonas de disponibilidade, talvez seja necessário criar um novo grupo de recursos, um plano do Serviço de Aplicativo e o Serviço de Aplicativo.
Seu plano dos Serviços de Aplicativo deve ser um dos seguintes planos que dão suporte a zonas de disponibilidade:
- Em um ambiente multilocatário usando planos Premium v2 ou Premium v3 do Serviço de Aplicativo.
- Em um ambiente dedicado usando o Ambiente do Serviço de Aplicativo v3, que é usado com 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 avançada. Para saber mais sobre o Ambiente do Serviço de Aplicativo v3, confira 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 v3, siga as etapas neste artigo para migrar para a nova versão.
A contagem de instância mínima de três zonas é imposta. A plataforma imporá essa contagem mínima em segundo plano se você especificar uma contagem de instâncias menor que três.
As zonas de disponibilidade só podem ser especificadas quando um Plano do Serviço de Aplicativo é criado. Um Plano do Serviço de Aplicativo preexistente não pode ser convertido para usar zonas de disponibilidade.
As seguintes regiões dão suporte aos Serviços de Aplicativos do Azure em execução em ambientes multilocatário:
- Leste da Austrália
- Brazil South
- Canadá Central
- Índia Central
- Centro dos EUA
- Leste da Ásia
- Leste dos EUA
- Leste dos EUA 2
- França Central
- Centro-Oeste da Alemanha
- Leste do Japão
- Coreia Central
- Norte da Europa
- Leste da Noruega
- Polônia Central
- Catar Central
- Norte da África do Sul
- Centro-Sul dos Estados Unidos
- Sudeste Asiático
- Suécia Central
- Norte da Suíça
- Norte dos EAU
- Sul do Reino Unido
- Europa Ocidental
- Oeste dos EUA 2
- Oeste dos EUA 3
- Microsoft Azure operado pela 21Vianet - Norte da China 3
- Azure Governamental – US Gov – Virgínia
Para ver quais regiões dão suporte a zonas de disponibilidade para Ambiente do Serviço de Aplicativo v3, consulte Regiões.
Criar um recurso com a zona de disponibilidade habilitada
Para implantar um Serviço de Aplicativo com redundância de zona multilocatário
Para habilitar as zonas de disponibilidade usando a CLI do Azure, inclua o parâmetro --zone-redundant ao criar o Plano do Serviço de Aplicativo. Você também pode incluir o parâmetro --number-of-workers para especificar a capacidade. Se você não especificar uma capacidade, a plataforma padrão será três. A capacidade deve ser definida de acordo com o requisito de carga de trabalho, mas deve ser no mínimo três. Uma boa regra geral para escolher a capacidade é garantir instâncias suficientes para o aplicativo, de forma 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
Dica
Para decidir a capacidade da instância, você pode usar o seguinte cálculo:
Como a plataforma difunde as VMs em três zonas e você precisa considerar pelo menos a falha de uma zona, multiplique a contagem de instâncias de carga de trabalho de pico por um fator de zonas/(zonas-1) ou 3/2. Por exemplo, se a carga de trabalho de pico comum exigir quatro instâncias, você deverá 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 plano do Ambiente do Serviço de Aplicativo v3 em Isolado v2, confira Criar um Ambiente do Serviço de Aplicativo.
Solução de problemas
| Mensagem de erro | Descrição | Recomendação |
|---|---|---|
| A redundância de zona não está disponível para o grupo de recursos 'RG-NAME'. Implante o plano do serviço de aplicativo 'ASP-NAME' em um novo grupo de recursos. | As zonas de disponibilidade só têm suporte no volume mais recente do Serviço de Aplicativo. Mesmo se você estiver usando uma das regiões com suporte, receberá um erro se as zonas de disponibilidade não tiverem suporte para o grupo de recursos. | Para garantir que suas cargas de trabalho cheguem em um carimbo que dê suporte a zonas de disponibilidade, crie um novo grupo de recursos, um plano do Serviço de Aplicativo e o Serviço de Aplicativo. |
Tolerância a falhas
Para se preparar para a falha da zona de disponibilidade, você deve superprovisionar a capacidade de serviço para garantir que a solução possa tolerar perda de 1/3 de capacidade e continuar funcionando sem desempenho degradado durante interrupções em toda a zona. Como a plataforma difunde as VMs em três zonas e você precisa considerar pelo menos a falha de uma zona, multiplique a contagem de instâncias de carga de trabalho de pico por um fator de zonas/(zonas-1) ou 3/2. Por exemplo, se a carga de trabalho de pico comum exigir quatro instâncias, você deverá provisionar seis instâncias: (2/3 * 6 instâncias) = 4 instâncias.
Experiência de zona inoperante
O tráfego é encaminhado para todas as instâncias disponíveis do Serviço de Aplicativo. No caso de uma zona falhar, a plataforma do Serviço de Aplicativo detectará as instâncias perdidas e tentará automaticamente localizar novas instâncias de substituição e difundir o tráfego conforme necessário. Se você tiver o dimensionamento automático configurado e se ele 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 do dimensionamento automático é independente do comportamento da plataforma do Serviço de Aplicativo e que a especificação de contagem de instâncias do dimensionamento automático não precisa ser um múltiplo de três.
Observação
Não há garantias de que as solicitações de instâncias adicionais em um cenário de zona inativa serão bem-sucedidas. O preenchimento posterior de instâncias perdidas ocorre com base no melhor esforço. A solução recomendada é criar e configurar os planos do Serviço de Aplicativo para considerar a perda de uma zona, conforme descrito na próxima seção.
Os aplicativos implantados em um Plano do Serviço de Aplicativo que tem as zonas de disponibilidade habilitadas continuarão executando e fornecendo tráfego mesmo que outras zonas na mesma região tiverem uma interrupção. Entretanto, é possível que comportamentos que não são de runtime, incluindo o dimensionamento do plano de serviço de aplicativo e a criação, configuração e publicação de aplicativos, ainda sejam afetados por uma falha temporária em outras zonas de disponibilidade. A redundância de zona para os 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 para um plano do serviço de aplicativo com redundância de zona, ela usa o melhor balanceamento de zona de esforço oferecido pelos conjuntos de dimensionamento de máquinas virtuais do Azure subjacentes. Um plano do Serviço de Aplicativo será "balanceado", 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 de Serviço de Aplicativo existentes ou recursos de ambiente do suporte à zona de não disponibilidade para o suporte à zona de disponibilidade. Para obter suporte para zonas de disponibilidade, você precisará criar recursos com as zonas de disponibilidade habilitadas.
Preços
Não há nenhum custo adicional associado à habilitação de zonas de disponibilidade. O preço de um Serviço de Aplicativo com redundância de zona é o mesmo que o de um Serviço de Aplicativo de zona única. Você será cobrado com base no SKU do plano do Serviço de Aplicativo, na capacidade especificada e nas instâncias dimensionadas de acordo com os critérios de dimensionamento automático. Se você habilitar as zonas de disponibilidade, mas especificar uma capacidade menor que três, a plataforma vai impor uma contagem de instâncias mínima de três e cobrará por essas três instâncias. Para obter informações sobre preços do Ambiente do Serviço de Aplicativo v3, consulte Preços.
Recuperação de desastre entre regiões e continuidade dos negócios
A DR (recuperação de desastre) trata da recuperação após eventos de alto impacto, como desastres naturais ou implantações com falha, que resultam em tempo de inatividade e perda de dados. Seja qual for a causa, a melhor solução para um desastre é um plano de DR bem definido e testado e um design de aplicativo que dê suporte ativo à DR. Antes de começar a pensar em criar seu plano de recuperação de desastre, confira Recomendações para criar uma estratégia de recuperação de desastre.
Quando o assunto é DR, a Microsoft usa o modelo de responsabilidade compartilhada. Em um modelo de responsabilidade compartilhada, a Microsoft garante que a infraestrutura de linha de base e os serviços de plataforma estejam disponíveis. Ao mesmo tempo, muitos serviços do Azure não replicam dados automaticamente nem retornam de uma região com falha para a replicação cruzada em outra região habilitada. Para esses serviços, você é responsável por configurar um plano de recuperação de desastre que funcione para sua carga de trabalho. A maioria dos serviços executados nas ofertas de PaaS (plataforma como serviço) do Azure fornece recursos e diretrizes para dar suporte à DR. Além disso, você pode usar recursos específicos do serviço para dar suporte a uma recuperação rápida, a fim de ajudar a desenvolver seu plano de DR.
Esta seção aborda algumas estratégias comuns para aplicativos Web implantados em 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, ele é 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 geográfica 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 último estado do aplicativo.
Para TI, os planos de continuidade de negócios são em grande parte impulsionados pelo RTO (Objetivo de Tempo de Recuperação) e RPO (Objetivo de Ponto de Recuperação). Para obter mais informações sobre RTO e RPO, consulte os objetivos de recuperação.
Normalmente, a manutenção de 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). No entanto, com o Azure, não é apenas prático, mas pode até ser simples implantar o Serviço de Aplicativo para failovers geográficos automáticos. Isso permite que você revise ainda mais seus aplicativos à prova de desastres, cuidando do RTO e do RPO.
Dependendo das métricas de RTO e RPO desejadas, três arquiteturas de recuperação de desastre geralmente são usadas para ambientes multilocatários do Serviço de Aplicativo e do Ambiente do Serviço de Aplicativo. Cada arquitetura é descrita na tabela a seguir:
| Metric | Ativo/ativo | Ativo/passivo | Passivo/frio |
|---|---|---|---|
| RTO | Tempo real ou segundos | minutos | Horas |
| RPO | Tempo real ou segundos | minutos | Horas |
| Custo | $$$ | $$ | $ |
| Cenários | Aplicativos Essenciais | Aplicativos de alta prioridade | Aplicativos de baixa prioridade |
| Capacidade de atender ao tráfego de usuário de várias regiões | Sim | Sim/talvez | Não |
| Implantação de código | Pipelines de CI/CD preferenciais | Pipelines de CI/CD preferenciais | Backup e restauração |
| Criação de novos recursos de Serviço de Aplicativo durante o tempo de inatividade | Não é necessária | Não é necessária | Obrigatório |
Observação
Seu aplicativo provavelmente depende de outros serviços de dados no Azure, como contas do Banco de Dados do SQL do Azure e Armazenamento do Microsoft Azure. É recomendável que você desenvolva estratégias de recuperação de desastre para cada um desses Serviços do Azure dependentes também. Para Banco de Dados SQL, consulte Replicação geográfica ativa para o Banco de Dados SQL do Azure. Para Armazenamento do Microsoft Azure, consulte Redundância do Armazenamento do Azure.
Recuperação de desastre na geografia de várias regiões
Há várias maneiras de replicar o conteúdo e as configurações dos 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 pontuais e, eventualmente, levam a desafios de controle de versão do aplicativo Web entre regiões. Consulte a tabela a seguir para obter uma comparação entre as orientações de retorno e restauração e as orientações de recuperação de desastres:
Backup e restauração comparados à recuperação de desastre
| Plataforma | Diretrizes de backup e restauração | Guia de recuperação de desastres |
|---|---|---|
| Aplicativos Web do Serviço de Aplicativo (Tipo de preço Gratuito e Compartilhado) |
Se você tiver aplicativos Web implantados na camada Gratuita ou Compartilhada e exigir acesso às funcionalidades de Backup e Restauração desses aplicativos Web, escale verticalmente para a camada Básica ou superior. | Coloque os recursos do Serviço de Aplicativo novamente online em outra região 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 uma falha em toda a região. Recomenda-se implementar as técnicas de recuperação de desastres comumente usadas para evitar o tempo de inatividade e a perda de dados durante um desastre regional. |
| Aplicativos Web do Serviço de Aplicativo (Tipo de Preço Básico\Standard\Premium) |
No Serviço de Aplicativo do Azure, você pode fazer backups personalizados sob demanda ou utilizar os 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 novamente online em outra região 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 uma falha em toda a região. Incentivamos que você implemente as técnicas de recuperação de desastres comumente usadas para evitar a perda de funcionalidades ou dados de seus aplicativos Web se houver um desastre regional. |
| Ambiente do Serviço de Aplicativo (V2 e V3) | No Ambiente do Serviço de Aplicativo do Azure, você pode fazer backups personalizados sob demanda ou utilizar os backups automáticos. Os backups automáticos podem ser restaurados em um aplicativo de destino dentro do mesmo ASE, não em outro ASE. Os backups personalizados podem ser restaurados em 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 do 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 as diretrizes de recuperação de desastres para os aplicativos Web implantados no Ambiente de Serviço de Aplicativo usando as técnicas de recuperação de desastres comumente usadas. |
| Azure Functions (Dedicado) | No Azure Functions, você pode fazer backups personalizados sob demanda ou utilizar os 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 aplicativo Azure Functions (dedicado) novamente online em uma região diferente do Azure durante um desastre regional estão disponíveis em Recuperar de uma 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 uma 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 as técnicas de recuperação de desastres comumente usadas para o Azure Functions dedicado. |
| Consumo do Azure Functions e Premium | O Azure Functions implantado nos 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 de Armazenamento do Microsoft 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 que você implemente a Confiabilidade e recuperação 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 Azure Pipelines ou GitHub Actions. Para obter mais informações, consulte Implantação contínua no Serviço de Aplicativo do Azure.
Detecção, notificação e gerenciamento de interrupção
É recomendável que você configure monitoramento e 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 os recursos do aplicativo no Azure, use um mecanismo de IaC (infraestrutura como código). 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 de IoC, como modelos do Resource Manager do Azure ou Terraform.
Configurar a recuperação de desastre e a detecção de interrupções
Para se preparar para a recuperação de desastre em uma geografia de várias regiões, você pode usar uma arquitetura ativo-ativo ou ativo-passivo.
Arquitetura Ativa-Ativa
Na arquitetura de recuperação de desastre ativo-ativo, aplicativos Web idênticos são implantados em duas regiões separadas e o Azure Front Door é usado para rotear o tráfego para ambas as regiões ativas.
Com este exemplo de arquitetura:
- Aplicativos Serviço de Aplicativo idênticos são implantados em duas regiões separadas, incluindo o tipo de preço e a contagem de instâncias.
- O tráfego público diretamente para os aplicativos de 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 roteia o tráfego exclusivamente para a região que permanece online. O RTO durante esse failover geográfico é próximo de 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 o aplicativo modificar ativamente o sistema de arquivos, a melhor maneira de minimizar o RPO é gravar apenas em um compartilhamento montado do Armazenamento do Microsoft Azure 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 Microsoft Azure (GZRS ou GRS) para o compartilhamento montado, que tem um RPO de cerca de 15 minutos.
As etapas para criar uma arquitetura ativa-ativa para seu aplicativo Web em Serviço de Aplicativo são resumidas da seguinte maneira:
Crie dois planos do Serviço de Aplicativo em duas regiões diferentes do Azure. Configure os dois planos de Serviço de Aplicativo de forma idêntica.
Crie duas instâncias do seu aplicativo Web, com uma em cada plano do Serviço de Aplicativo.
Crie um perfil do Azure Front Door com:
- Um ponto de extremidade.
- Dois grupos de origem, cada um com uma prioridade de 1. A prioridade igual informa ao Azure Front Door para rotear o tráfego para ambas as regiões igualmente (portanto, ativo-ativo).
- Uma rota.
Limite o tráfego de rede para os aplicativos Web somente da instância do Azure Front Door.
Instale e configure todos os outros serviços do Azure de back-end, como bancos de dados, contas de armazenamento e provedores de autenticação.
Implante o código em ambos os aplicativos Web com implantação contínua.
Tutorial: Criar um aplicativo de várias regiões 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 a prioridade como "1" para ambas as origens no grupo de origem no Azure Front Door) oferecem uma arquitetura ativa-ativa.
Arquitetura ativa-passiva.
Nessa abordagem de recuperação de desastre, aplicativos Web idênticos são implantados em duas regiões separadas e o Azure Front Door é usado para rotear o tráfego apenas para uma região (a região ativa ).
Com este exemplo de arquitetura:
Os aplicativos de Serviços de Aplicativo idênticos são implantados em duas regiões separadas.
O tráfego público diretamente para os aplicativos de Serviço de Aplicativo está bloqueado.
O Azure Front Door é usado para rotear o tráfego para a região primária.
Para economizar custos, o plano de Serviço de Aplicativo secundário é configurado para ter menos instâncias e/ou estar em um tipo de preço mais baixo. Há três abordagens possíveis:
Preferencial O plano de Serviço de Aplicativo secundário tem o mesmo tipo de preço que o primário, com o mesmo número de instâncias ou menos. Essa abordagem garante a paridade no dimensionamento do recurso e da VM para os dois planos de Serviço de Aplicativo. O RTO durante um failover geográfico depende apenas do tempo para escalar horizontalmente as instâncias.
Menos preferencial O plano de Serviço de Aplicativo secundário tem o mesmo tipo de tipo 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 de 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 escalar verticalmente e escalar horizontalmente as instâncias.
Pouco preferencial O plano de Serviço de Aplicativo secundário tem um tipo de preço diferente das instâncias primária 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 de Serviço de Aplicativo secundário 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 aplicativo Web. O RTO durante um failover geográfico depende do tempo para escalar verticalmente e escalar horizontalmente 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 dimensionamento automático semelhantes em regiões ativas e passivas.
Durante um desastre, a região primária fica inativa e a região secundária começa a receber tráfego e se torna a região ativa.
Depois que a região secundária fica ativa, a carga de rede dispara regras de dimensionamento automático pré-configuradas para escalar horizontalmente o aplicativo Web secundário.
Talvez seja necessário escalar verticalmente o tipo de preço para a região secundária manualmente, se ele ainda não tiver os recursos necessários para ser executado como a região ativa. Por exemplo, dimensionamento automático requer a camada Standard ou superior.
Quando a região primária estiver ativa novamente, o Azure Front Door direcionará automaticamente o tráfego de volta para ela e a arquitetura voltará a ser ativa-passiva 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 o aplicativo modificar ativamente o sistema de arquivos, a melhor maneira de minimizar o RPO é gravar apenas em um compartilhamento montado do Armazenamento do Microsoft Azure 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 Microsoft Azure (GZRS ou GRS) para o compartilhamento montado, que tem um RPO de cerca de 15 minutos.
As etapas para criar uma arquitetura ativa-passiva para seu aplicativo Web em Serviço de Aplicativo são resumidas da seguinte maneira:
- Crie dois planos do Serviço de Aplicativo em duas regiões diferentes do Azure. O plano de Serviço de Aplicativo secundário pode ser provisionado usando uma das abordagens mencionadas anteriormente.
- Configure regras de dimensionamento automático para o plano de 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.
- Crie duas instâncias do seu aplicativo Web, com uma em cada plano do Serviço de Aplicativo.
- Crie um perfil do Azure Front Door com:
- Um ponto de extremidade.
- Um grupo de origem com uma prioridade de 1 para a região primária.
- Um segundo grupo de origem com prioridade 2 para a região secundária. A diferença de prioridade instrui o Azure Front Door a preferir a região primária quando ela estiver online (portanto, ativa-passiva).
- Uma rota.
- Limite o tráfego de rede para os aplicativos Web somente da instância do Azure Front Door.
- Instale e configure todos os outros serviços do Azure de back-end, como bancos de dados, contas de armazenamento e provedores de autenticação.
- Implante o código em ambos os aplicativos Web com implantação contínua.
Tutorial: Criar um aplicativo de várias regiões altamente disponível no Serviço de Aplicativo do Azure mostra como configurar uma arquitetura ativa-passiva.
Arquitetura passivo-frio
Use uma arquitetura passiva/frio para criar e manter backups regulares de seus aplicativos Web em uma conta de Armazenamento do Microsoft 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 Microsoft Azure na mesma região.
A replicação entre regiões dos backups depende da configuração de redundância de dados na conta de armazenamento do Azure. Você deve definir sua conta de Armazenamento do Microsoft Azure como GZRS, se possível. O GZRS oferece redundância de zona síncrona em uma região e assíncrona em uma região secundária. Se o GZRS não estiver disponível, configure a conta como GRS. O GZRS e 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 projetar seus aplicativos para aproveitar a redundância geográfica, consulte como Usar a redundância geográfica para criar aplicativos altamente disponíveis.
Durante um desastre na região do aplicativo Web, você deve implantar manualmente todos os recursos dependentes Serviço de Aplicativo necessários usando os backups da conta de Armazenamento do Microsoft 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 guia estratégico abrangente delineando 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 passiva e fria para seu aplicativo Web em Serviço de Aplicativo são resumidas da seguinte maneira:
Crie uma conta de armazenamento do Azure na mesma região que seu aplicativo Web. Escolha 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).
Habilite RA-GRS ou RA-GZRS (acesso de leitura para a região secundária).
Configure o backup personalizado para seu aplicativo Web. Você pode decidir definir um agendamento para seus backups de aplicativo Web, como por hora.
Verifique se os arquivos de backup do aplicativo Web podem ser recuperados na região secundária da sua conta de armazenamento.
Dica
Além do Azure Front Door, o Azure fornece outras opções de balanceamento de carga, como o Gerenciador de Tráfego do Azure. Para obter uma comparação das várias opções, consulte Opções de balanceamento de carga - Centro de Arquitetura do Azure.
Recuperação de desastre na geografia de região única
Se a região do aplicativo Web não tiver armazenamento GZRS ou GRS ou se você estiver em uma região do Azure que não seja um de um par regional, você precisará utilizar o ZRS (armazenamento com redundância de zona) ou O LRS (armazenamento com redundância local) para criar uma arquitetura semelhante. Por exemplo, você pode criar manualmente uma região secundária para a conta de armazenamento da seguinte maneira:
As etapas para criar uma região passiva e fria sem GRS e GZRS são resumidas da seguinte maneira:
Crie uma conta de armazenamento do Azure na mesma região do aplicativo Web. Escolha Camada de desempenho Padrão e selecione redundância como armazenamento com redundância de zona (ZRS).
Configure o backup personalizado para seu aplicativo Web. Você pode decidir definir um agendamento para seus backups de aplicativo Web, como por hora.
Verifique se os arquivos de backup do aplicativo Web podem ser recuperados na região secundária da sua conta de armazenamento.
Crie uma segunda conta de armazenamento do Azure em uma região diferente. Escolha Camada de desempenho Padrão e selecione redundância como armazenamento com redundância local (LRS).
Usando uma ferramenta como AzCopy, replique o backup personalizado (arquivos Zip, XML e 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 Automação do Azure com um runbook do Fluxo de Trabalho do PowerShell para executar o script de replicação em um agendamento. Verifique se o agendamento de replicação segue uma agenda semelhante aos backups do aplicativo Web.