Aplicativo de n camadas de várias regiões

Azure Monitor
Gerenciador de Tráfego do Azure
Banco de Dados SQL do Azure
Máquinas Virtuais do Azure

Essa arquitetura de referência mostra um conjunto de práticas comprovadas para executar um aplicativo de N camadas em várias regiões do Azure, a fim de alcançar a disponibilidade e uma infraestrutura de recuperação de desastres robusta.

Arquitetura

Highly available network architecture for Azure N-tier applications

Baixe um Arquivo Visio dessa arquitetura.

Workflow

  • Regiões primárias e secundárias. Use duas regiões para obter alta disponibilidade. Uma delas é a região primária. A outra região destina-se ao failover.

  • Gerenciador de Tráfego do Microsoft Azure. O Gerenciador de Tráfego roteia as solicitações de entrada para uma das regiões. Durante as operações normais, ele roteia as solicitações para a região primária. Se essa região ficar indisponível, o Gerenciador de Tráfego fará failover para a região secundária. Para obter mais informações, consulte a Configuração do Gerenciador de Tráfego.

  • Grupos de recursos. Crie grupos de recursos separados para a região primária, a região secundária e para o Gerenciador de Tráfego. Esse método oferece a flexibilidade de gerenciar cada região como uma única coleção de recursos. Por exemplo, você poderia reimplantar uma região sem interromper a outra. Vincule os grupos de recursos para ser possível executar uma consulta para listar todos os recursos para o aplicativo.

  • Redes virtuais. Crie uma rede virtual separada para cada região. Verifique se os espaços de endereço não se sobrepõem.

  • Grupo de Disponibilidade Always On do SQL Server. Se você usa o SQL Server, recomendamos os Grupos de Disponibilidade do SQL Always On para alta disponibilidade. Crie um único grupo de disponibilidade que inclui instâncias do SQL Server em ambas as regiões.

    Observação

    Além disso, considere usar o Banco de Dados SQL do Azure, que fornece um banco de dados relacional como um serviço de nuvem. Com o Banco de Dados SQL, você não precisa configurar um grupo de disponibilidade ou gerenciar o failover.

  • Emparelhamento de rede virtual. Emparelhe as duas redes virtuais para permitir a replicação de dados da região primária para a região secundária. Para obter mais informações, consulte Emparelhamento de rede virtual do Azure.

Componentes

  • Os conjuntos de disponibilidade garantem que as VMs implantadas no Azure sejam distribuídas entre vários nós de hardware isolados em um cluster. Se ocorrer uma falha de hardware ou software no Azure, apenas um subconjunto de suas VMs será afetado e toda a sua solução permanecerá disponível e operacional.
  • As zonas de disponibilidade ajudam a proteger os aplicativos e os dados contra falhas no datacenter. As zonas de disponibilidade são locais físicos separados em uma região do Azure. Cada zona é composta por um ou mais datacenters equipados com energia, resfriamento e rede independentes.
  • O Gerenciador de Tráfego do Azure é um balanceador de carga de tráfego baseado em DNS que distribui o tráfego de forma otimizada. Ele fornece serviços em regiões globais do Azure, com alta disponibilidade e capacidade de resposta.
  • O Azure Load Balancer distribui o tráfego de entrada de acordo com as regras e investigações de integridade. O balanceador de carga fornece baixa latência e alta taxa de transferência e pode ser escalado verticalmente em milhões de fluxos para aplicativos TCP e UDP. Um balanceador de carga público é usado neste cenário para distribuir o tráfego de clientes para a camada da Web. Um balanceador de carga interno é usado neste cenário para distribuir o tráfego da camada de negócios para o cluster do SQL Server de back-end.
  • O Bastião do Azure fornece conectividade RDP e SSH segura para todas as VMs, na rede virtual na qual ele é provisionado. Use o Azure Bastion para proteger suas máquinas virtuais contra a exposição das portas RDP/SSH ao mundo externo, fornecendo acesso seguro usando o RDP/SSH.

Recomendações

Uma arquitetura de várias regiões pode fornecer uma disponibilidade maior que a implantação em uma única região. Se uma interrupção regional afetar a região primária, você poderá usar o Gerenciador de Tráfego para fazer failover para a região secundária. Essa arquitetura também poderá ajudar a se um subsistema individual do aplicativo falhar.

Há várias abordagens gerais para alcançar alta disponibilidade em várias regiões:

  • Ativo/passivo com espera ativa. O tráfego vai para uma região, enquanto a outra aguarda em espera ativa. O modo de espera ativo significa que as VMs na região secundária estão alocadas e estão sempre em execução.
  • Ativo/passivo com espera passiva. O tráfego vai para uma região, enquanto a outra aguarda em espera passiva. O modo de espera a frio significa que as VMs na região secundária não são alocadas até que seja necessário para failover. Essa abordagem custa menos para ser executada, mas geralmente leva mais tempo para ficar online durante uma falha.
  • Ativa/ativa. Ambas as regiões ficam ativas e a carga das solicitações é balanceada entre elas. Se uma região ficar indisponível, ela será retirada da rotação.

Essa arquitetura de referência se concentra em ativo/passivo com espera ativa, usando o Gerenciador de Tráfego para o failover. Você pode implantar algumas VMs para o modo de espera ativo e, em seguida, expandir conforme necessário.

Emparelhamento regional

Cada região do Azure é emparelhada com outra na mesma área geográfica. Em geral, escolha regiões do mesmo par regional (por exemplo, Leste dos EUA 2 e EUA Central). Os benefícios disso incluem:

  • Se houver uma interrupção ampla, a recuperação de pelo menos uma região de cada par é priorizada.
  • 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.
  • Os pares residem na mesma geografia para atender aos requisitos de residência de dados.

No entanto, verifique se ambas as regiões dão suporte a todos os serviços do Azure necessários para seu aplicativo (consulte Serviços por região). Para saber mais sobre pares regionais, consulte Continuidade dos negócios e recuperação de desastres (BCDR): Regiões Emparelhadas do Azure.

Configuração do Gerenciador de Tráfego

Considere os seguintes pontos ao configurar o Gerenciador de Tráfego:

  • Roteamento. O Gerenciador de Tráfego dá suporte a vários algoritmos de roteamento. Para o cenário descrito neste artigo, use roteamento prioritário (anteriormente chamado de roteamento de failover). Com essa configuração, o Gerenciador de Tráfego envia todas as solicitações para a região primária, a menos que ela fique inacessível. Nesse ponto, ele automaticamente faz failover para a região secundária. Consulte Configurar o método de roteamento de failover.
  • Investigação de integridade. O Gerenciador de Tráfego usa uma investigação HTTP (ou HTTPS) para monitorar a disponibilidade de cada região. A investigação verifica uma resposta HTTP 200 para um caminho de URL especificado. Como uma prática recomendada, crie um ponto de extremidade que relata a integridade geral do aplicativo e use esse ponto de extremidade para a investigação de integridade. Caso contrário, a investigação pode relatar um ponto de extremidade íntegro quando partes essenciais do aplicativo estão falhando na verdade. Para obter mais informações, consulte Padrão de monitoramento de ponto de extremidade de integridade.

Quando o Gerenciador de Tráfego faz failover, há um período em que os clientes não conseguem acessar o aplicativo. A duração é afetada pelos seguintes fatores:

  • A investigação de integridade precisa detectar que a região primária ficou inacessível.
  • Os servidores DNS precisam atualizar os registros DNS armazenados em cache para o endereço IP, dependendo da TTL (vida útil) DNS. A TTL padrão é 300 segundos (5 minutos), mas você pode configurar esse valor ao criar o perfil do Gerenciador de Tráfego.

Para saber mais, consulte Sobre o monitoramento do Gerenciador de Tráfego.

Em caso de falha do Gerenciador de Tráfego, é recomendável executar um failback manual em vez de implementar um failback automático. Caso contrário, você pode criar uma situação em que o aplicativo fica alternando entre as regiões. Verifique se todos os subsistemas de aplicativo estão íntegros antes de realizar o failback.

O Gerenciador de Tráfego falha automaticamente por padrão. Para evitar esse problema, diminua manualmente a prioridade da região primária após um evento de failover. Por exemplo, suponha que a região primária tem prioridade 1 e a secundária tem prioridade 2. Após um failover, defina a região primária para a prioridade 3, para impedir o failback automático. Quando estiver pronto para voltar, atualize a prioridade para 1.

O seguinte comando da CLI do Azure atualiza a prioridade:

az network traffic-manager endpoint update --resource-group <resource-group> --profile-name <profile>
    --name <endpoint-name> --type azureEndpoints --priority 3

Outra abordagem é desabilitar temporariamente o ponto de extremidade até que você esteja pronto para fazer failback:

az network traffic-manager endpoint update --resource-group <resource-group> --profile-name <profile>
    --name <endpoint-name> --type azureEndpoints --endpoint-status Disabled

Dependendo da causa de um failover, será necessário reimplantar os recursos dentro de uma região. Antes de fazer o failback, execute um teste de prontidão operacional. O teste deverá verificar o seguinte:

  • As VMs estão configuradas corretamente. (Todo o software necessário está instalado, o IIS está em execução e assim por diante.)
  • Os subsistemas de aplicativos estão íntegros.
  • Testes funcionais. (Por exemplo, a camada de banco de dados pode ser acessada da camada da Web.)

Configurar Grupos de Disponibilidade Always On do SQL Server

Antes do Windows Server 2016, os Grupos de Disponibilidade Always On do SQL Server exigiam um controlador de domínio e todos os nós no grupo de disponibilidade precisavam estar no mesmo domínio do AD (Active Directory).

Para configurar o grupo de disponibilidade:

  • No mínimo, coloque dois controladores de domínio em cada região.

  • Forneça um endereço IP estático para cada controlador de domínio.

  • Emparelhe as duas redes virtuais para habilitar a comunicação entre elas.

  • Para cada rede virtual, adicione os endereços IP dos controladores de domínio (de ambas as regiões) à lista de servidores DNS. Você pode usar o comando da CLI a seguir. Para obter mais informações, consulte alterar servidores DNS.

    az network vnet update --resource-group <resource-group> --name <vnet-name> --dns-servers "10.0.0.4,10.0.0.6,172.16.0.4,172.16.0.6"
    
  • Crie um cluster WSFC (Clustering de Failover do Windows Server) que inclui as instâncias do SQL Server em ambas as regiões.

  • Crie um único Grupo de Disponibilidade Always On do SQL Server que inclui instâncias do SQL Server em ambas as regiões primária e secundária. Consulte Estendendo o Grupo de Disponibilidade Always On para o Datacenter Remoto do Azure (PowerShell) para ver as etapas.

    • Coloque a réplica primária na região primária.

    • Coloque uma ou mais réplicas secundárias na região primária. Configure essas réplicas para usar confirmação síncrona com failover automático.

    • Coloque uma ou mais réplicas secundárias na região secundária. Configure essas réplicas para usar confirmação assíncrona , por motivos de desempenho. (Caso contrário, todas as transações de T-SQL precisarão aguardar uma viagem de ida e volta pela rede para a região secundária.)

      Observação

      As réplicas de confirmação assíncronas não oferecem suporte a failover automático.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios de orientação que podem ser usados para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, confira Microsoft Azure Well-Architected Framework.

Disponibilidade

Com um aplicativo complexo de N camadas, pode não ser necessário replicar o aplicativo inteiro na região secundária. Em vez disso, você pode replicar apenas um subsistema crítico que é necessário para dar suporte à continuidade de negócios.

O Gerenciador de Tráfego é um possível ponto de falha no sistema. Se o serviço Gerenciador de Tráfego falhar, os clientes não poderão acessar seu aplicativo durante o tempo de inatividade. Examine o SLA do Gerenciador de Tráfego e determine se usar apenas o Gerenciador de Tráfego atende aos seus requisitos de negócios para alta disponibilidade. Caso contrário, considere adicionar outra solução de gerenciamento de tráfego como um failback. Se o serviço do Gerenciador de Tráfego do Azure falhar, altere os registros CNAME no DNS para apontar para outro serviço de gerenciamento de tráfego. (Esta etapa deve ser executada manualmente e seu aplicativo estará indisponível até que as alterações de DNS sejam propagadas.)

Para o cluster do SQL Server, há dois cenários de failover a serem considerados:

  • Todas as réplicas de banco de dados do SQL Server na região primária falham. Por exemplo, essa falha pode acontecer durante uma interrupção regional. Nesse caso, você deve fazer failover do grupo de disponibilidade manualmente, mesmo que o Gerenciador de Tráfego faça failover automaticamente no front-end. Siga as etapas em Executar um Failover Manual Forçado de um Grupo de Disponibilidade do SQL Server, que descreve como executar um failover forçado usando o SQL Server Management Studio, o Transact-SQL ou o PowerShell no SQL Server 2016.

    Aviso

    Com o failover forçado, há um risco de perda de dados. Depois que a região principal estiver novamente online, crie um instantâneo do banco de dados e usar tablediff para encontrar as diferenças.

  • O Gerenciador de Tráfego faz failover para a região secundária, mas a réplica primária do Banco de Dados do SQL Server ainda está disponível. A camada de front-end pode falhar sem afetar as VMs do SQL Server, por exemplo. Nesse caso, o tráfego da Internet é roteado para a região secundária e essa região ainda pode se conectar à réplica primária. No entanto, haverá aumento da latência, pois as conexões do SQL Server ocorrem entre regiões. Nessa situação, você deve executar um failover manual da seguinte maneira:

    1. Alterne temporariamente uma réplica de banco de dados do SQL Server na região secundária para confirmação síncrona. Esta etapa garante que não haverá perda de dados durante o failover.
    2. Failover para essa réplica.
    3. Após realizar o failback para a região primária, restaure a configuração de confirmação assíncrona.

Capacidade de gerenciamento

Quando você atualizar a implantação, atualize uma região de cada vez para reduzir a chance de uma falha global devido a uma configuração incorreta ou um erro no aplicativo.

Teste a resiliência do sistema a falhas. Aqui estão alguns cenários comuns de falha para testar:

  • Desligamento de instâncias de VM.
  • Recursos de pressão, como CPU e memória.
  • Desconectar/atraso de rede.
  • Falha de processos.
  • Expiração de certificados.
  • Simular falhas de hardware.
  • Desligamento do serviço DNS nos controladores de domínio.

Meça o tempo de recuperação e verifique se ele cumpre seus requisitos de negócios. Teste também combinações dos modos de falha.

Otimização de custo

A otimização de custos é a análise de maneiras de reduzir as despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, confira Visão geral do pilar de otimização de custo.

Use a Calculadora de Preços do Azure para estimar os custos. Confira outras considerações.

Conjuntos de Dimensionamento de Máquinas Virtuais

Os Conjuntos de Dimensionamento de Máquina Virtual estão disponíveis em todos os tamanhos de VM do Windows. Você é cobrado apenas pelas VMs do Azure implantadas e por quaisquer recursos de infraestrutura subjacente adicionados que sejam consumidos, como armazenamento e rede. Não há cobranças incrementais para o serviço Conjuntos de Dimensionamento de Máquina Virtual.

Para obter opções de preços de VMs simples, consulte os preços das VMs do Windows.

Servidor SQL

Se você escolher DBaas do SQL do Azure, poderá economizar porque não precisará configurar um grupo de disponibilidade Always On e computadores do controlador de domínio. Há várias opções de implantação, de banco de dados individual a instância gerenciada ou pools elásticos. Para obter mais informações, consulte Preços do SQL do Azure.

Para opções de preços de VMs do SQL Server, consulte os Preços das VMs de SQL.

Balanceadores de carga

Você será cobrado apenas pelo número de regras de saída e balanceamento de carga configuradas. As regras NAT de entrada são gratuitas. Não há cobrança por hora para o Standard Load Balancer quando nenhuma regra está configurada.

Perfil de Gerenciador de Tráfego

A cobrança do Gerenciador de Tráfego é baseada no número de consultas DNS recebidas, com um desconto para serviços que recebem mais de 1 bilhão de consultas mensais. Você também é cobrado por cada ponto de extremidade monitorado.

Para obter mais informações, confira a seção de custo em Estrutura Bem Projetada do Microsoft Azure.

Preços de Emparelhamento VNET

Uma implantação de alta disponibilidade que usa várias regiões do Azure usará o emparelhamento de VNET. Há encargos diferentes para o Emparelhamento VNET dentro da mesma região e para o Emparelhamento VNET Global.

Para saber mais, confira Preços de rede virtual.

DevOps

Use um único modelo do Azure Resource Manager para provisionar os recursos do Azure e suas dependências. Use o mesmo modelo para implantar os recursos em regiões primárias e secundárias. Inclua todos os recursos na mesma rede virtual para que fiquem isolados na mesma carga de trabalho básica. Ao incluir todos os recursos, você facilita a associação dos recursos específicos da carga de trabalho a uma equipe de DevOps, para que a equipe possa gerenciar de forma independente todos os aspectos desses recursos. Esse isolamento permite que a Equipe DevOps execute a CI/CD (integração contínua e entrega contínua).

Você também pode usar diferentes modelos do Azure Resource Manager e integrá-los ao Azure DevOps Services para provisionar diferentes ambientes em minutos, por exemplo, para replicar cenários semelhantes à produção ou carregar ambientes de teste somente quando necessário, economizando custos.

Considere usar o Azure Monitor para analisar e otimizar o desempenho de sua infraestrutura e monitorar e diagnosticar problemas de rede sem fazer logon em suas máquinas virtuais. O Application Insights é um dos componentes do Azure Monitor, que fornece métricas e logs avançados para verificar o estado de seu cenário completo do Azure. O Azure Monitor ajudará você a seguir o estado da infraestrutura.

Monitore não somente os elementos de computação que dão suporte ao código do aplicativo, mas também a plataforma de dados, especialmente os bancos de dados, pois o mau desempenho da camada de dados de um aplicativo pode ter consequências sérias.

Para testar o ambiente do Azure no qual os aplicativos estão em execução, ele deve ser controlado por versão e implantado por meio dos mesmos mecanismos que o código do aplicativo e, portanto, também pode ser testado e validado usando os paradigmas de teste de DevOps.

Para obter mais informações, consulte a seção Excelência operacional em Microsoft Azure Well-Architected Framework.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Autor principal:

Para ver perfis não públicos do LinkedIn, entre no LinkedIn.

Próximas etapas

A arquitetura a seguir usa algumas das mesmas tecnologias: