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?

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

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 Ambiente do Serviço de Aplicativo v3 no plano Isolado v2, consulte Criar um Ambiente do Serviço de Aplicativo.

Resolução de Problemas

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.

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

Para ambientes multilocatários que usam os planos App Service Premium v2 ou Premium v3, não há 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 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. O Ambiente do Serviço de Aplicativo v3 tem um modelo de preços diferente para zonas de disponibilidade. 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:

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

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

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.

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:

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

• Tutorial: Criar um aplicativo multirregião altamente disponível no Serviço de Aplicativo do Azure
• Fiabilidade no Azure