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?

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
  • Israel Central
  • Norte da Itália
  • Leste do Japão
  • Coreia Central
  • México 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
  • Espanha Central
  • 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

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

"resources": [
  {
    "type": "Microsoft.Web/serverfarms",
    "apiVersion": "2018-02-01",
    "name": "your-appserviceplan-name-here",
    "location": "West US 3",
    "sku": {
        "name": "P1v3",
        "tier": "PremiumV3",
        "size": "P1v3",
        "family": "Pv3",
        "capacity": 3
    },
    "kind": "app",
    "properties": {
        "zoneRedundant": true
    }
  }
]

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

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.

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

Para ambientes multilocatário usando planos Premium v2 ou Premium v3 do Serviço de Aplicativo, não há nenhum custo adicional associado à habilitação de zonas de disponibilidade, desde que você tenha três ou mais instâncias em seu plano do Serviço de Aplicativo. 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. O Ambiente do Serviço de Aplicativo v3 tem um modelo de preço diferente para zonas de disponibilidade. 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:

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 vs. recuperação de desastres

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:

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

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

4. Limite o tráfego de rede para os aplicativos Web somente da instância do Azure Front Door.

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

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

1. 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.
2. 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.
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 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.
5. Limite o tráfego de rede para os aplicativos Web somente da instância do Azure Front Door.
6. 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.
7. 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:

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

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 agendamento para seus backups de 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.

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:

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

2. Configure o backup personalizado para seu aplicativo Web. Você pode decidir definir um agendamento para seus backups de 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 Camada de desempenho Padrão e selecione redundância como armazenamento com redundância local (LRS).

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

Próximas etapas

• Tutorial: Crie um aplicativo de várias regiões altamente disponível no Serviço de Aplicativo do Azure
• Confiabilidade no Azure