Executar uma aplicação de N níveis em várias regiões do Azure Stack Hub para alta disponibilidade
Essa arquitetura de referência mostra um conjunto de práticas comprovadas para execução em um aplicativo de N camadas em várias regiões do Azure Stack Hub, a fim de obter disponibilidade e uma infraestrutura robusta de recuperação de desastres. Neste documento, o Gerenciador de Tráfego é usado para obter alta disponibilidade, no entanto, se o Gerenciador de Tráfego não for uma escolha preferida em seu ambiente, um par de balanceadores de carga altamente disponíveis também poderá ser substituído.
Observação
Observe que o Gerenciador de Tráfego usado na arquitetura abaixo precisa ser configurado no Azure e os pontos de extremidade usados para configurar o perfil do Gerenciador de Tráfego precisam ser IPs roteáveis publicamente.
Arquitetura
Esta arquitetura baseia-se na mostrada em aplicação de N camadas com SQL Server.
Regiões primárias e secundárias. Use duas regiões para obter maior disponibilidade. Uma é a região primária. A outra região é utilizada como alternativa em caso de falha.
Azure Traffic Manager. Traffic Manager encaminha as solicitações recebidas para uma das regiões. Durante as operações normais, ele encaminha solicitações para a região primária. Se essa região ficar indisponível, o Gestor de Tráfego passará 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, a região secundária. Isso lhe dá a flexibilidade de gerenciar cada região como uma única coleção de recursos. Por exemplo, você pode reimplantar uma região, sem derrubar a outra. Vincule os grupos de recursos, para que você possa executar uma consulta para listar todos os recursos para o aplicativo.
Redes virtuais. Crie uma rede virtual separada para cada região. Certifique-se de que os espaços de endereço não se sobrepõem.
Grupo de Disponibilidade Always On do SQL Server. Se estiver a usar o SQL Server, recomendamos Grupos de Disponibilidade Always On do SQL Server para alta disponibilidade. Crie um único grupo de disponibilidade que inclua as instâncias do SQL Server em ambas as regiões.
Conexão VPN de VNET para VNET. Como o Emparelhamento VNET ainda não está disponível no Azure Stack Hub, use a ligação VPN de VNET para VNET a fim de ligar as duas VNETs. Consulte VNET para VNET no Azure Stack Hub para obter mais informações.
Recomendações
Uma arquitetura de várias regiões pode fornecer maior disponibilidade do que a implantação em uma única região. Se uma interrupção regional afetar a região primária, pode usar o Gerenciador de Tráfego para alternar para a região secundária. Essa arquitetura também pode ajudar se um subsistema individual do aplicativo falhar.
Existem várias abordagens gerais para alcançar a alta disponibilidade entre regiões:
Ativo/passivo comde standby quente. O tráfego vai para uma região, enquanto a outra aguarda em standby ativo. Hot standby significa que as VMs na região secundária são alocadas e executadas em todos os momentos.
Ativo/passivo comde espera a frio. O tráfego vai para uma região, enquanto a outra aguarda em modo de 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.
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 é retirada da rotação.
Esta arquitetura de referência concentra-se no ativo/passivo com hot standby, usando o Gerenciador de Tráfego para failover. Você pode implantar um pequeno número de VMs para espera ativa e, em seguida, expandir conforme necessário.
Configuração do Traffic Manager
Considere os seguintes pontos ao configurar o Gerenciador de Tráfego:
Roteamento. O Traffic Manager suporta 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 fique inacessível. Nesse ponto, ele automaticamente faz failover para a região secundária. Consulte Configurar método de roteamento de failover.
Sonda de saúde. O Gerenciador de Tráfego usa um de investigação de HTTP (ou HTTPS) para monitorar a disponibilidade de cada região. O teste verifica se há uma resposta HTTP 200 para um caminho de URL especificado. Como prática recomendada, crie um ponto de extremidade que relate a integridade geral do aplicativo e use esse ponto de extremidade para a sonda de integridade. Caso contrário, a sonda pode relatar um endpoint saudável quando partes críticas da aplicação na realidade estiverem realmente falhando. Para obter mais informações, consulte o padrão de monitorização de endpoint de saúde .
Quando o Gerenciador de Tráfego faz failover, há um período de tempo em que os clientes não conseguem acessar o aplicativo. A duração é afetada pelos seguintes fatores:
A sonda de saúde deve detetar que a região primária se tornou inacessível.
Os servidores DNS devem atualizar os registros DNS armazenados em cache para o endereço IP, que depende do tempo de vida útil (TTL) do DNS. O TTL padrão é de 300 segundos (5 minutos), mas você pode configurar esse valor ao criar o perfil do Gerenciador de Tráfego.
Para obter detalhes, consulte Sobre a monitorização 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ê pode criar uma situação em que o aplicativo alterna entre regiões. Verifique se todos os subsistemas de aplicativos estão íntegros antes de fazer failback.
Observe que o Gerenciador de Tráfego faz failover automaticamente por padrão. Para evitar isso, diminua manualmente a prioridade da região primária após um evento de failover. Por exemplo, suponha que a região primária é prioridade 1 e a secundária é prioridade 2. Após um failover, defina a região primária como prioridade 3, para evitar failback automático. Quando estiver pronto para mudar, volte atrás e 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 externalEndpoints --priority 3
Outra abordagem é desativar temporariamente o ponto de extremidade até que estejas pronto para a recuperação:
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 numa região. Antes de falhar novamente, execute um teste de prontidão operacional. O teste deve verificar coisas como:
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 a partir da camada da Web.)
Configurar Grupos de Disponibilidade do SQL Server Always On
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 do grupo de disponibilidade deveriam estar no mesmo domínio do Ative 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 permitir 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 seguinte comando da CLI. 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 Windows Server Failover Clustering (WSFC), que inclua as instâncias do SQL Server em ambas as regiões.
Crie um Grupo de Disponibilidade Always On do SQL Server que inclua as instâncias do SQL Server nas regiões primária e secundária. Consulte Estendendo o Grupo de Disponibilidade Always On para o Datacenter Remoto do Azure (PowerShell) para obter as etapas.
Posicione 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 estes para usar confirmação assíncrona, por motivos de desempenho. (Caso contrário, todas as transações T-SQL terão que aguardar em uma viagem de ida e volta pela rede até a região secundária.)
Observação
As réplicas de confirmação assíncronas não suportam falha automática.
Considerações sobre disponibilidade
Com um aplicativo complexo de N camadas, talvez não seja necessário replicar o aplicativo inteiro na região secundária. Em vez disso, você pode apenas replicar um subsistema crítico necessário para dar suporte à continuidade de negócios.
O Traffic Manager é 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. Analise o SLA do Traffic Managere determine se o uso exclusivo do Traffic Manager atende aos seus requisitos de negócios para alta disponibilidade. Caso contrário, considere adicionar outra solução de gerenciamento de tráfego como reserva. Se o serviço Azure Traffic Manager 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 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, isso pode acontecer durante uma interrupção regional. Nesse caso, você deve fazer failover manual 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 do SQL Server, que descreve como executar um failover forçado usando o SQL Server Management Studio, Transact-SQL ou PowerShell no SQL Server 2016.
O Gerenciador de Tráfego realiza failover para a região secundária, mas a réplica do banco de dados primário do SQL Server ainda está disponível. Por exemplo, a camada front-end pode falhar, sem afetar as VMs do 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, haverá maior latência, porque as conexões do SQL Server estão indo 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. Isso garante que não haverá perda de dados durante o failover.
Faça failover para essa réplica.
Ao fazer failback para a região primária, restaure a configuração de confirmação assíncrona.
Considerações sobre 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 um erro no aplicativo.
Teste a resiliência do sistema a falhas. Aqui estão alguns cenários de falha comuns para testar:
Desligue instâncias de VM.
Recursos de pressão, como CPU e memória.
Desconecte/atrase a rede.
Processos em colapso.
Certificados de expiração.
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 requisitos do seu negócio. Teste também combinações de modos de falha.
Próximos passos
- Para saber mais sobre os Padrões de Nuvem do Azure, consulte Padrões de Design de Nuvem.