Aplicativo Web de várias regiões altamente disponível

Serviço de Aplicativo
Cosmos DB
Front Door
Armazenamento
Banco de Dados SQL

Essa arquitetura de referência mostra como executar um aplicativo do Serviço de Aplicativo do Azure em várias regiões para obter alta disponibilidade.This reference architecture shows how to run an Azure App Service application in multiple regions to achieve high availability.

Arquitetura de referência para um aplicativo Web com alta disponibilidade

Baixe um Arquivo Visio dessa arquitetura.Download a Visio file of this architecture.

ArquiteturaArchitecture

Essa arquitetura baseia-se naquela mostrada em Melhorar a escalabilidade em um aplicativo Web.This architecture builds on the one shown in Improve scalability in a web application. As principais diferenças são:The main differences are:

  • Regiões primárias e secundárias.Primary and secondary regions. Essa arquitetura usa duas regiões para obter alta disponibilidade.This architecture uses two regions to achieve higher availability. O aplicativo está implantado em cada região.The application is deployed to each region. Durante as operações normais, o tráfego de rede é roteado para a região primária.During normal operations, network traffic is routed to the primary region. Se a região primária ficar indisponível, o tráfego será roteado para a região secundária.If the primary region becomes unavailable, traffic is routed to the secondary region.
  • Porta frontal.Front Door. A porta frontal roteia as solicitações de entrada para a região primária.Front Door routes incoming requests to the primary region. Se o aplicativo que executa essa região ficar indisponível, a porta frontal passará por failover para a região secundária.If the application running that region becomes unavailable, Front Door fails over to the secondary region.
  • Replicação geográfica do banco de dados SQL e/ou cosmos DB.Geo-replication of SQL Database and/or Cosmos DB.

Uma arquitetura de várias regiões pode fornecer uma disponibilidade maior que a implantação em uma única região.A multi-region architecture can provide higher availability than deploying to a single region. Se uma interrupção regional afetar a região primária, você poderá usar a porta frontal para fazer failover para a região secundária.If a regional outage affects the primary region, you can use Front Door to fail over to the secondary region. Essa arquitetura também poderá ajudar a se um subsistema individual do aplicativo falhar.This architecture can also help if an individual subsystem of the application fails.

Há várias abordagens gerais para alcançar alta disponibilidade em várias regiões:There are several general approaches to achieving high availability across regions:

  • Ativo/passivo com espera ativa.Active/passive with hot standby. O tráfego vai para uma região, enquanto a outra aguarda em espera ativa.Traffic goes to one region, while the other waits on hot standby. A espera ativa significa que as VMs na região secundária são alocadas e ficam em execução a todo momentos.Hot standby means the VMs in the secondary region are allocated and running at all times.
  • Ativo/passivo com espera passiva.Active/passive with cold standby. O tráfego vai para uma região, enquanto a outra aguarda em espera passiva.Traffic goes to one region, while the other waits on cold standby. A espera passiva significa que as VMs na região secundária não são alocadas até serem necessárias para failover.Cold standby means the VMs in the secondary region are not allocated until needed for failover. Essa abordagem custa menos para ser executada, mas geralmente leva mais tempo para ficar online durante uma falha.This approach costs less to run, but will generally take longer to come online during a failure.
  • Ativa/ativa.Active/active. Ambas as regiões ficam ativas e a carga das solicitações é balanceada entre elas.Both regions are active, and requests are load balanced between them. Se uma região ficar indisponível, ela será retirada da rotação.If one region becomes unavailable, it is taken out of rotation.

Essa arquitetura de referência se concentra em ativo/passivo com espera ativa, usando a porta frontal para failover.This reference architecture focuses on active/passive with hot standby, using Front Door for failover.

RecomendaçõesRecommendations

Seus requisitos podem ser diferentes dos requisitos da arquitetura descrita aqui.Your requirements might differ from the architecture described here. Use as recomendações nesta seção como um ponto inicial.Use the recommendations in this section as a starting point.

Emparelhamento regionalRegional pairing

Cada região do Azure é emparelhada com outra na mesma área geográfica.Each Azure region is paired with another region within the same geography. Em geral, escolha regiões do mesmo par regional (por exemplo, Leste dos EUA 2 e EUA Central).In general, choose regions from the same regional pair (for example, East US 2 and Central US). Os benefícios de se fazer isso são:Benefits of doing so include:

  • No caso de uma interrupção ampla, a recuperação de pelo menos uma região de cada par é priorizada.If there is a broad outage, recovery of at least one region out of every pair is prioritized.
  • As atualizações planejadas do sistema do Azure são distribuídas em regiões emparelhadas sequencialmente para minimizar o possível tempo de inatividade.Planned Azure system updates are rolled out to paired regions sequentially to minimize possible downtime.
  • Na maioria dos casos, pares regionais residem na mesma geografia para atender aos requisitos de residência de dados.In most cases, regional pairs reside within the same geography to meet data residency requirements.

No entanto, verifique se ambas as regiões dão suporte a todos os serviços do Azure necessários para seu aplicativo.However, make sure that both regions support all of the Azure services needed for your application. Confira Serviços por região.See Services by region. Para saber mais sobre pares regionais, confira Continuidade dos negócios e recuperação de desastres (BCDR): Regiões Combinadas do Azure.For more information about regional pairs, see Business continuity and disaster recovery (BCDR): Azure Paired Regions.

Grupos de recursosResource groups

Considere a possibilidade de colocar a região primária, a região secundária e o Gerenciador de Tráfego em grupos de recursos separados.Consider placing the primary region, secondary region, and Traffic Manager into separate resource groups. Isso permite que você gerencie os recursos implantados para cada região como uma única coleção.This lets you manage the resources deployed to each region as a single collection.

Configuração de porta frontalFront Door configuration

Roteamento.Routing. A porta frontal dá suporte a vários mecanismos de roteamento.Front Door supports several routing mechanisms. Para o cenário descrito neste artigo, use roteamento de prioridade .For the scenario described in this article, use priority routing. Com essa configuração, a porta da frente envia todas as solicitações para a região primária, a menos que o ponto de extremidade dessa região fique inacessível.With this setting, Front Door sends all requests to the primary region unless the endpoint for that region becomes unreachable. Nesse ponto, ele automaticamente faz failover para a região secundária.At that point, it automatically fails over to the secondary region. Defina o pool de back-end com valores de prioridade diferentes, 1 para a região ativa e 2 ou superior para a região de espera ou passiva.Set the backend pool with different priority values, 1 for the active region and 2 or higher for the standby or passive region.

Investigação de integridade.Health probe. A porta frontal usa uma investigação HTTP (ou HTTPS) para monitorar a disponibilidade de cada back-end.Front Door uses an HTTP (or HTTPS) probe to monitor the availability of each back end. A investigação dá ao front door um teste de aprovação/reprovação para fazer failover para a região secundária.The probe gives Front Door a pass/fail test for failing over to the secondary region. Ele funciona com o envio de uma solicitação para um caminho de URL especificado.It works by sending a request to a specified URL path. Se ele obtiver uma resposta não 200 dentro de um período de tempo limite, o teste falhará.If it gets a non-200 response within a timeout period, the probe fails. Você pode configurar a frequência da investigação de integridade, o número de amostras necessárias para avaliação e o número de amostras bem-sucedidas necessárias para que o back-end seja marcado como íntegro.You can configure the health probe frequency, number of samples required for evaluation, and the number of successful samples required for the backend to be marked as healthy. Se a porta frontal marcar o back-end como degradado, ele fará failover para o outro back-end.If Front Door marks the backend as degraded, it fails over to the other backend. Para obter detalhes, consulte investigações de integridade.For details, see Health Probes.

Como prática recomendada, crie um caminho de investigação de integridade no back-end do aplicativo que relata a integridade geral do aplicativo.As a best practice, create a health probe path in your application backend that reports the overall health of the application. Essa investigação de integridade deve verificar dependências críticas, como os aplicativos do serviço de aplicativo, a fila de armazenamento e o banco de dados SQL.This health probe should check critical dependencies such as the App Service apps, storage queue, and SQL Database. Caso contrário, a investigação poderá relatar um back-end íntegro quando partes críticas do aplicativo estiverem realmente falhando.Otherwise, the probe might report a healthy backend when critical parts of the application are actually failing. Por outro lado, não use a investigação de integridade para verificar os serviços de baixa prioridade.On the other hand, don't use the health probe to check lower priority services. Por exemplo, se um serviço de email ficar inativo, o aplicativo poderá mudar para um segundo provedor ou apenas enviar emails mais tarde.For example, if an email service goes down the application can switch to a second provider or just send emails later. Para obter mais informações sobre esse padrão de design, consulte padrão de monitoramento do ponto de extremidade de integridade.For further discussion of this design pattern, see Health Endpoint Monitoring Pattern.

Banco de Dados SQLSQL Database

Use a Replicação Geográfica Ativa para criar uma réplica secundária legível em uma região diferente.Use Active Geo-Replication to create a readable secondary replica in a different region. Você pode ter até quatro réplicas secundárias legíveis.You can have up to four readable secondary replicas. Faça failover para um banco de dados secundário se o banco de dados primário falhar ou precisar ser deixado offline.Fail over to a secondary database if your primary database fails or needs to be taken offline. A replicação geográfica ativa pode ser configurada para qualquer banco de dados em qualquer pool de banco de dados elástico.Active Geo-Replication can be configured for any database in any elastic database pool.

Cosmos DBCosmos DB

O Cosmos DB dá suporte à replicação geográfica entre regiões no padrão ativo-ativo com várias regiões de gravação.Cosmos DB supports geo-replication across regions in active-active pattern with multiple write regions. Como alternativa, você pode designar uma região como a região gravável e outras como réplicas somente leitura.Alternatively, you can designate one region as the writable region and the others as read-only replicas. Se houver uma interrupção regional, será possível fazer failover selecionando outra região para ser a região de gravação.If there is a regional outage, you can fail over by selecting another region to be the write region. O SDK do cliente envia automaticamente solicitações de gravação para a região de gravação atual, portanto você não precisa atualizar a configuração do cliente após um failover.The client SDK automatically sends write requests to the current write region, so you don't need to update the client configuration after a failover. Para obter mais informações, confira Distribuição de dados global com o Azure Cosmos DB.For more information, see Global data distribution with Azure Cosmos DB.

Observação

Todas as réplicas de pertencem ao mesmo grupo de recursos.All of the replicas belong to the same resource group.

ArmazenamentoStorage

Para o Armazenamento do Azure, use RA-GRS armazenamento com redundância geográfica com acesso de leitura.For Azure Storage, use read-access geo-redundant storage (RA-GRS). Com o armazenamento de RA-GRS, os dados são replicados para uma região secundária.With RA-GRS storage, the data is replicated to a secondary region. Você tem acesso somente leitura aos dados na região secundária por meio de um ponto de extremidade separado.You have read-only access to the data in the secondary region through a separate endpoint. Se houver uma interrupção ou desastre regional, a equipe do Armazenamento do Azure pode decidir executar um failover geográfico para a região secundária.If there is a regional outage or disaster, the Azure Storage team might decide to perform a geo-failover to the secondary region. Nenhuma ação do cliente é necessária para este failover.There is no customer action required for this failover.

Para o Armazenamento de Filas, crie uma fila de backup na região secundária.For Queue storage, create a backup queue in the secondary region. Durante o failover, o aplicativo pode usar a fila de backup até que a região principal fique disponível novamente.During failover, the app can use the backup queue until the primary region becomes available again. Dessa forma, o aplicativo ainda poderá processar novas solicitações.That way, the application can still process new requests.

Considerações sobre disponibilidadeAvailability considerations

Considere esses pontos ao projetar para alta disponibilidade entre regiões.Consider these points when designing for high availability across regions.

Porta da frente do AzureAzure Front Door

A porta de início do Azure fará failover automaticamente se a região primária ficar indisponível.Azure Front Door automatically fails over if the primary region becomes unavailable. Quando a porta frontal falha, há um período de tempo (geralmente cerca de 20-60 segundos) quando os clientes não podem acessar o aplicativo.When Front Door fails over, there is a period of time (usually about 20-60 seconds) when clients cannot reach the application. A duração é afetada pelos seguintes fatores:The duration is affected by the following factors:

  • Frequência de investigações de integridade.Frequency of health probes. Quanto mais frequentes as investigações de integridade forem enviadas, a porta frontal mais rápida poderá detectar o tempo de inatividade ou o back-end voltado para a íntegra.The more frequent the health probes are sent, the faster Front Door can detect downtime or the backend coming back healthy.
  • Configuração de tamanho de exemplo.Sample size configuration. Essa configuração controla quantas amostras são necessárias para que a investigação de integridade detecte que o back-end primário tornou-se inacessível.This configuration controls how many samples are required for the health probe to detect that the primary backend has become unreachable. Se esse valor for muito baixo, você poderá obter falsos positivos de problemas intermitentes.If this value is too low, you could get false positives from intermittent issues.

O Front Door é um possível ponto de falha no sistema.Front Door is a possible failure point in the system. Se o serviço falhar, os clientes não poderão acessar seu aplicativo durante o tempo de inatividade.If the service fails, clients cannot access your application during the downtime. Examine o SLA (contrato de nível de serviço) do Front Door e determine se usar apenas o Front Door atende aos seus requisitos de negócios para alta disponibilidade.Review the Front Door service level agreement (SLA) and determine whether using Front Door alone meets your business requirements for high availability. Caso contrário, considere adicionar outra solução de gerenciamento de tráfego como um fallback.If not, consider adding another traffic management solution as a fallback. Caso o serviço do Front Door falhe, altere os registros CNAME (nome canônico) no DNS para apontar para outro serviço de gerenciamento de tráfego.If the Front Door service fails, change your canonical name (CNAME) records in DNS to point to the other traffic management service. Esta etapa deve ser executada manualmente e seu aplicativo estará indisponível até que as alterações de DNS sejam propagadas.This step must be performed manually, and your application will be unavailable until the DNS changes are propagated.

Banco de Dados SQLSQL Database

O RPO (objetivo de ponto de recuperação) e o ERT (tempo de recuperação estimado) para o Banco de Dados SQL estão documentados na Visão geral de continuidade de negócios com o Banco de Dados SQL do Azure.The recovery point objective (RPO) and estimated recovery time (ERT) for SQL Database are documented in Overview of business continuity with Azure SQL Database.

Cosmos DBCosmos DB

O RPO e o RTO (objetivo de tempo de recuperação) para Cosmos DB são configuráveis por meio dos níveis de consistência usados, que fornecem compensações entre disponibilidade, durabilidade dos dados e taxa de transferência.RPO and recovery time objective (RTO) for Cosmos DB are configurable via the consistency levels used, which provide trade-offs between availability, data durability, and throughput. Cosmos DB fornece um RTO mínimo de 0 para um nível de consistência relaxado com vários mestres ou um RPO de 0 para consistência forte com um mestre único.Cosmos DB provides a minimum RTO of 0 for a relaxed consistency level with multi-master or an RPO of 0 for strong consistency with single-master. Para saber mais sobre os níveis de consistência de Cosmos DB, consulte níveis de consistência e durabilidade de dados em Cosmos DB.To learn more about Cosmos DB consistency levels, see Consistency levels and data durability in Cosmos DB.

ArmazenamentoStorage

O armazenamento de RA-GRS fornece armazenamento durável, mas é importante entender o que pode ocorrer durante uma interrupção:RA-GRS storage provides durable storage, but it's important to understand what can happen during an outage:

  • Se ocorrer uma interrupção de armazenamento, haverá um período em que você não terá acesso de gravação aos dados.If a storage outage occurs, there will be a period of time when you don't have write-access to the data. Você ainda poderá ler do ponto de extremidade secundário durante a interrupção.You can still read from the secondary endpoint during the outage.

  • Se uma interrupção ou desastre regional afetar o local primário e os dados não puderem ser recuperados, a equipe do Armazenamento do Azure poderá optar por executar um failover geográfico para a região secundária.If a regional outage or disaster affects the primary location and the data there cannot be recovered, the Azure Storage team may decide to perform a geo-failover to the secondary region.

  • A replicação de dados para a região secundária é executada de forma assíncrona.Data replication to the secondary region is performed asynchronously. Portanto, se um failover geográfico for executado, é possível que haja certa perda de dados se eles não podem ser recuperados da região primária.Therefore, if a geo-failover is performed, some data loss is possible if the data can't be recovered from the primary region.

  • Falhas transitórias, como uma interrupção da rede, não disparam um failover de armazenamento.Transient failures, such as a network outage, will not trigger a storage failover. Projete seu aplicativo para ser resiliente a falhas transitórias.Design your application to be resilient to transient failures. As opções de mitigação incluem:Mitigation options include:

    • Ler de uma região secundária.Read from the secondary region.
    • Alternar temporariamente para outra conta de armazenamento para novas operações de gravação (por exemplo, para colocar mensagens na fila).Temporarily switch to another storage account for new write operations (for example, to queue messages).
    • Copiar dados da região secundária para outra conta de armazenamento.Copy data from the secondary region to another storage account.
    • Fornecer funcionalidade reduzida até a conclusão do failback do sistema.Provide reduced functionality until the system fails back.

Para obter mais informações, consulte O que fazer se ocorrer uma interrupção do Armazenamento do Azure.For more information, see What to do if an Azure Storage outage occurs.

Considerações de custoCost considerations

Use a calculadora de preços para estimar os custos.Use the pricing calculator to estimate costs. Essas recomendações nesta seção podem ajudá-lo a reduzir o custo.These recommendations in this section may help you to reduce cost.

Porta da frente do AzureAzure Front Door

A cobrança de porta frontal do Azure tem três tipos de preço: transferências de dados de saída, transferências de dados de entrada e regras de roteamento.Azure Front Door billing has three pricing tiers: outbound data transfers, inbound data transfers, and routing rules. Para obter mais informações, consulte preços de porta frontal do Azure.For more info See Azure Front Door Pricing. O gráfico de preços não inclui o custo de acessar dados dos serviços de back-end e transferir para a porta frontal.The pricing chart does not include the cost of accessing data from the backend services and transferring to Front Door. Esses custos são cobrados com base nos encargos de transferência de dados, descritos em detalhes de preços de largura de banda.Those costs are billed based on data transfer charges, described in Bandwidth Pricing Details.

Azure Cosmos DBAzure Cosmos DB

Há dois fatores que determinam Azure Cosmos DB preço:There are two factors that determine Azure Cosmos DB pricing:

  • A taxa de transferência provisionada ou as unidades de solicitação por segundo (ru/s).The provisioned throughput or Request Units per second (RU/s).

    Há dois tipos de taxa de transferência que podem ser provisionadas em Cosmos DB, padrão e dimensionamento automático.There are two types of throughput that can be provisioned in Cosmos DB, standard and autoscale. A taxa de transferência padrão aloca os recursos necessários para garantir as RU/s que você especificar.Standard throughput allocates the resources required to guarantee the RU/s that you specify. Para dimensionamento automático, você provisiona a taxa de transferência máxima e Cosmos DB aumenta ou reduz verticalmente, dependendo da carga, com um mínimo de 10% da taxa de transferência máxima de dimensionamento automático.For autoscale, you provision the maximum throughput, and Cosmos DB instantly scales up or down depending on the load, with a minimum of 10% of the maximum autoscale throughput. A taxa de transferência padrão é cobrada pela taxa de transferência provisionada por hora.Standard throughput is billed for the throughput provisioned hourly. A taxa de transferência de autoescala é cobrada pela taxa de transferência máxima consumida por hora.Autoscale throughput is billed for the maximum throughput consumed hourly.

  • Armazenamento consumido.Consumed storage. será cobrada uma taxa fixa para a quantidade total de armazenamento (GBs) consumida em dados e para os índices de determinada hora.You are billed a flat rate for the total amount of storage (GBs) consumed for data and the indexes for a given hour.

Para obter mais informações, confira a seção de custo em Estrutura Bem Projetada do Microsoft Azure.For more information, see the cost section in Microsoft Azure Well-Architected Framework.

Considerações sobre capacidade de gerenciamentoManageability considerations

Se o banco de dados primário falhar, realize um failover manual para o banco de dados secundário.If the primary database fails, perform a manual failover to the secondary database. Consulte restaurar um banco de dados SQL do Azure ou fazer failover para um secundário.See Restore an Azure SQL Database or failover to a secondary. O banco de dados secundário permanece somente leitura até você fazer o failover.The secondary database remains read-only until you fail over.

Considerações de DevOpsDevOps considerations

Essa arquitetura segue a recomendação de implantação de várias regiões, descrita na seção DevOps da estrutura bem projetada do Azure.This architecture follows the multi region deployment recommendation, described in the DevOps section of the Azure Well Architected Framework.

Essa arquitetura é criada sobre aquela mostrada em melhorar a escalabilidade em um aplicativo Web, consulte a seção considerações de DevOps.This architecture builds on the one shown in Improve scalability in a web application, see DevOps considerations section.