Executar um aplicativo de N camadas em várias regiões de Azure Stack Hub para alta disponibilidade

Essa arquitetura de referência mostra um conjunto de práticas comprovadas para executar um aplicativo de N camadas em várias regiões Azure Stack Hub para obter disponibilidade e uma infraestrutura de recuperação de desastre robusta. Nessa arquitetura, Gerenciador de Tráfego do Azure é usado para obter alta disponibilidade. No entanto, se o Gerenciador de Tráfego não for uma opção preferencial em seu ambiente, você poderá substituir um par de balanceadores de carga altamente disponíveis.

Architecture

Essa arquitetura se baseia na mostrada no aplicativo de N camadas com SQL Server.

• Regiões primárias e secundárias. Use duas regiões para obter maior disponibilidade. Uma região é a região primária. Use a outra região para failover.

• Gerenciador de Tráfego do Azure. O Gerenciador de Tráfego roteia solicitações de entrada para uma das regiões. Durante operações normais, ele roteia 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 seção Configuração do Gerenciador de Tráfego.

• Grupos de recursos. Crie grupos de recursos separados para a região primária e a região secundária. Essa abordagem oferece a flexibilidade para gerenciar cada região como uma única coleção de recursos. Por exemplo, você pode reimplantar uma região sem derrubar a outra região. Vincule os grupos de recursos para que você possa executar uma consulta para listar todos os recursos do 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 AlwaysOn do SQL Server. Se você estiver usando SQL Server, use Grupos de Disponibilidade AlwaysOn do SQL para alta disponibilidade. Crie um único grupo de disponibilidade que inclua as instâncias de SQL Server em ambas as regiões.

• Conexão VPN VNET para VNET. Como o emparelhamento VNET ainda não está disponível no Azure Stack Hub, use a conexão DE VPN VNET para VNET para conectar os dois VNETs. Consulte a VNET para VNET no Azure Stack Hub para obter mais informações.

Recommendations

Uma arquitetura de várias regiões pode fornecer maior disponibilidade do que implantar 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 pode ajudar se um subsistema individual do aplicativo falhar.

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

• Ativo/passivo com espera ativa. O tráfego vai para uma região, enquanto a outra aguarda em espera ativa. Espera ativa significa que as VMs na região secundária são alocadas e em execução o tempo todo.

• Ativo/passivo com espera a frio. O tráfego vai para uma região, enquanto a outra aguarda em espera fria. 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 levará mais tempo para ficar online durante uma falha.

• Ativo/ativo. Ambas as regiões estão ativas e as solicitações têm balanceamento de carga 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 failover. Você pode implantar um pequeno número de VMs para espera ativa e, em seguida, escalar horizontalmente conforme necessário.

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 o roteamento de prioridade (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 a região primária se torne inacessível. Nesse ponto, ele faz failover automaticamente 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 sonda verifica uma resposta HTTP 200 para um caminho de URL especificado. Como 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 poderá relatar um ponto de extremidade íntegro quando partes críticas do aplicativo estiverem realmente falhando. Para obter mais informações, consulte Padrão de Monitoramento de Ponto de Extremidade para Saúde.

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 deve detectar que a região primária tornou-se inacessível.

• Os servidores DNS devem atualizar os registros DNS armazenados em cache para o endereço IP, que depende do TTL (tempo de vida útil) do 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 obter detalhes, consulte Sobre o Monitoramento do Gerenciador de Tráfego.

Se o Gerenciador de Tráfego falhar, recomendamos executar um failback manual em vez de implementar um failback automático. Caso contrário, você poderá criar uma situação em que o aplicativo inverte entre regiões. Verifique se todos os subsistemas de aplicativo estão íntegros antes de fazer failback.

Observe que o Gerenciador de Tráfego faz failback automaticamente por padrão. Para evitar isso, reduza manualmente a prioridade da região primária após um evento de failover. Por exemplo, suponha que a região primária seja a prioridade 1 e a secundária seja a prioridade 2. Após um failover, defina a região primária como prioridade 3, para evitar o failback automático. Quando estiver pronto para alternar, volte, atualize a prioridade para 1.

O seguinte comando CLI do Azure atualiza a prioridade:

az network traffic-manager endpoint update --resource-group <resource-group> --profile-name <profile>
    --name <endpoint-name> --type externalEndpoints --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 externalEndpoints --endpoint-status Disabled

Dependendo da causa de um failover, talvez seja necessário reimplantar os recursos em uma região. Antes de fazer failback, execute um teste de preparação operacional. O teste deve verificar coisas como:

• As VMs estão configuradas corretamente. (Todos os softwares necessários estão instalados, o IIS está em execução e assim por diante.)

• Os subsistemas de aplicativo são íntegros.

• Teste funcional. (Por exemplo, a camada de banco de dados pode ser acessada na camada da Web.)

Configurar SQL Server Grupos de Disponibilidade AlwaysOn

Antes de Windows Server 2016, SQL Server Grupos de Disponibilidade AlwaysOn exigem um controlador de domínio e todos os nós no grupo de disponibilidade devem estar no mesmo domínio Active Directory (AD).

Para configurar o grupo de disponibilidade:

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

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

• Crie VPN para habilitar a comunicação entre duas redes virtuais.

• 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) Windows Server que inclua as instâncias de SQL Server em ambas as regiões.

• Crie uma SQL Server Grupo de Disponibilidade AlwaysOn que inclua as instâncias de SQL Server nas regiões primária e secundária. Consulte Estender o Grupo de Disponibilidade AlwaysOn para o Datacenter de Azure Remoto (PowerShell) para obter 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-os para usar a confirmação síncrona com failover automático.

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

Considerações sobre disponibilidade

Com um aplicativo complexo de N camadas, talvez você não precise replicar todo o aplicativo na região secundária. Em vez disso, você pode replicar apenas um subsistema crítico necessário para dar suporte à continuidade dos 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 o Gerenciador de Tráfego sozinho 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 Gerenciador de Tráfego do Azure falhar, altere seus registros CNAME no DNS para apontar para o outro serviço de gerenciamento de tráfego. (Esta etapa deve ser executada manualmente e seu aplicativo ficará indisponível até que as alterações de DNS sejam propagadas.)

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

• Todas as réplicas de banco de dados SQL Server na região primária falham. Por exemplo, essa falha pode ocorrer durante uma interrupção regional. Nesse caso, você deve fazer failover manualmente do grupo de disponibilidade, 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 SQL Server, que descreve como executar um failover forçado usando SQL Server Management Studio, Transact-SQL ou PowerShell no SQL Server 2016.

  Warning

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

• O Gerenciador de Tráfego faz failover para a região secundária, mas a réplica de banco de dados principal SQL Server ainda está disponível. Por exemplo, a camada front-end pode falhar, sem afetar as VMs SQL Server. 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, há uma latência maior, pois as conexões SQL Server passam por regiões. Nessa situação, execute um failover manual da seguinte maneira:

  1. Alterne temporariamente uma réplica de banco de dados SQL Server na região secundária para a confirmação síncrona. Essa alteração garante que não haja perda de dados durante o failover.

  2. Faça failover para essa réplica.

  3. Quando você fizer failback para a região primária, restaure a configuração de confirmação assíncrona.

Considerações sobre a capacidade de gerenciamento

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

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

• Desligue as instâncias de VM.

• Recursos de pressão, como CPU e memória.

• Desconectar ou atrasar a rede.

• Processos de falha.

• Expirar certificados.

• Simule falhas de hardware.

• Desligue o serviço DNS nos controladores de domínio.

Meça os tempos de recuperação e verifique se eles atendem aos seus requisitos de negócios. Teste também combinações de modos de falha.

Próximas Etapas 

• Para saber mais sobre os Padrões de Nuvem do Azure, consulte Padrões de Design de Nuvem.