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
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 flexibilidade para 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ê usar o SQL Server, recomendamos usar os Grupos de Disponibilidade Always On do SQL para ter 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, somente um subconjunto das VMs será afetado e toda a 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 Azure Bastion fornece conectividade segura de RDP e SSH a todas as VMs na rede virtual em que 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 frequente. O tráfego vai para uma região, enquanto a outra aguarda em espera frequente. A espera frequente significa que as VMs na região secundária sã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. A espera passiva significa que as VMs na região secundária não são alocadas até que sejam necessárias para o 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 frequente, usando o Gerenciador de Tráfego para o failover. Você pode implantar algumas VMs para no modo de espera frequente 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 prioridade será recuperar pelo menos uma região em cada par.
- 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 podem 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 faz failback 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 você estiver pronto para retornar para ela, 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 as réplicas para usar a confirmação síncrona com o failover automático.
Coloque uma ou mais réplicas secundárias na região secundária. Configure as réplicas para usar a 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íncrona não dão suporte a failover automático.
Considerações
Estas 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 do 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. Essa falha pode acontecer durante uma interrupção regional, por exemplo. 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:
- Alterne temporariamente uma réplica de banco de dados do SQL Server na região secundária para confirmação síncrona. Essa etapa garante que não haja perda de dados durante o failover.
- Failover para essa réplica.
- 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áquinas Virtuais estão disponíveis em todos os tamanhos de VM do Windows. Você só é cobrado pelas VMs do Azure implantadas e pelos recursos adicionais de infraestrutura subjacentes que tiverem sido consumidos, como armazenamento e rede. Não há cobranças incrementais para o serviço de Conjuntos de Dimensionamento de Máquinas Virtuais.
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, confira os preços de 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ê é 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 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 que estejam na mesma rede virtual, de forma 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 maneira 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:
- Donnie Trumpower | Arquiteto sênior de soluções de nuvem
Para ver perfis não públicos do LinkedIn, entre no LinkedIn.
Próximas etapas
Recursos relacionados
A arquitetura a seguir usa algumas das mesmas tecnologias: