Executar uma aplicação de N camadas em várias regiões do Azure Stack Hub para elevada disponibilidade

Esta arquitetura de referência mostra um conjunto de práticas comprovadas para execução numa aplicação de N camadas em várias regiões do Azure Stack Hub, de forma a alcançar a disponibilidade e uma infraestrutura de recuperação após desastre robusta. Neste documento, o Gestor de Tráfego é utilizado para obter elevada disponibilidade. No entanto, se o Gestor de Tráfego não for uma opção preferencial no seu ambiente, também poderá ser substituído um par de balanceadores de carga de elevada disponibilidade.

Nota

Tenha em atenção que o Gestor de Tráfego utilizado na arquitetura abaixo tem de ser configurado no Azure e os pontos finais utilizados para configurar o perfil do Gestor de Tráfego têm de ser IPs encaminháveis publicamente.

Arquitetura

Esta arquitetura baseia-se na apresentada na aplicação de N camadas com SQL Server.

• Regiões primária e secundária. Utilize duas regiões para alcançar uma disponibilidade mais elevada. Uma é a região primária. A outra região destina-se a ativação pós-falha.

• Gestor de Tráfego do Azure. O Gestor de Tráfego encaminha os pedidos recebidos para uma das regiões. Durante as operações normais, este encaminha os pedidos para a região primária. Se esta região ficar indisponível, o Gestor de Tráfego efetuará a ativação pós-falha para a região secundária. Para obter mais informações, veja a secção Configuração do Gestor de Tráfego.

• Grupos de recursos. Crie grupos de recursos separados para a região primária, a região secundária. Desta forma, obtém a flexibilidade para gerir cada região como uma única coleção de recursos. Por exemplo, pode reimplementar uma região, sem ter de encerrar a outra. Ligue os grupos de recursos para que possa executar uma consulta para listar todos os recursos da aplicação.

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

• SQL Server Grupo de Disponibilidade AlwaysOn. Se estiver a utilizar o SQL Server, recomendamos Grupos de Disponibilidade AlwaysOn do SQL para elevada disponibilidade. Crie um único grupo de disponibilidade que inclua as instâncias do SQL Server em ambas as regiões.

• Ligação VNET a VNET VPN. Uma vez que o VNET Peering ainda não está disponível no Azure Stack Hub, utilize a VNET para a ligação VPN da VNET para ligar as duas VNETs. Veja 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 em comparação com a implementação de uma única região. Se uma falha regional afetar a região primária, poderá utilizar o Gestor de Tráfego para efetuar a ativação pós-falha para a região secundária. Esta arquitetura também poderá ajudar se um subsistema individual da aplicação falhar.

Existem várias abordagens gerais para assegurar elevada disponibilidade nas regiões:

• Ativo/passivo com modo de espera frequente. O tráfego segue para uma região, enquanto a outra aguarda na reserva ativa. Reserva ativa significa que as VMs na região secundária são alocadas e executadas de forma permanente.

• Ativo/passivo com reserva fria. O tráfego segue para uma região, enquanto a outra aguarda na reserva progressiva. Reserva progressiva significa que as VMs na região secundária não são atribuídas até que sejam necessárias para a ativação pós-falha. Esta abordagem tem um custo de execução inferior, mas geralmente demora mais tempo a ficar online durante uma falha.

• Ativo/ativo. Ambas as regiões estão ativas e a carga dos pedidos é balanceada entre ambas. Se uma região ficar indisponível, esta será retirada da rotação.

Esta arquitetura de referência centra-se no modo ativo/passivo com reserva ativa e utiliza o Gestor de Tráfego para a ativação pós-falha. Pode implementar um pequeno número de VMs para reserva frequente e, em seguida, aumentar horizontalmente conforme necessário.

Configuração do Gestor de Tráfego

Quando configurar o Gestor de Tráfego, considere os seguintes pontos:

• Encaminhamento. O Gestor de Tráfego suporta vários algoritmos de encaminhamento. Para o cenário descrito neste artigo, utilize o encaminhamento prioritário (anteriormente denominado encaminhamento ativação pós-falha). Com esta definição, Gestor de Tráfego envia todos os pedidos para a região primária, a menos que a região primária fique inacessível. Nessa altura, este efetua a ativação pós-falha automaticamente para a região secundária. Veja Configurar o método de encaminhamento de ativação pós-falha.

• Sonda de estado de funcionamento. O Gestor de Tráfego utiliza uma sonda HTTP (ou HTTPS) para monitorizar a disponibilidade de cada região. A sonda verifica a existência de uma resposta HTTP 200 para um caminho de URL especificado. Como melhor prática, crie um ponto final que reporte o estado de funcionamento geral da aplicação e utilize este ponto final para a sonda de estado de funcionamento. Caso contrário, a sonda pode indicar que um ponto final está em bom estado quando, na verdade, as partes críticas da aplicação estão a falhar. Para obter mais informações, veja Padrão de Monitorização de Pontos Finais de Estado de Funcionamento.

Quando o Gestor de Tráfego realiza a ativação pós-falha, existe um período de tempo durante o qual os clientes não conseguem aceder à aplicação. A duração é afetada pelos seguintes fatores:

• A sonda de estado de funcionamento tem de detetar que a região primária ficou inacessível.

• Os servidores DNS têm de atualizar os registos DNS em cache do endereço IP, o qual depende do time-to-live (TTL) do DNS. O TTL predefinido é de 300 segundos (5 minutos), mas também pode configurar este valor quando cria o perfil do Gestor de Tráfego.

Para obter detalhes, veja Acerca da Monitorização do Gestor de Tráfego.

Se o Gestor de Tráfego efetuar uma ativação pós-falha, recomendamos a execução de uma reativação pós-falha manual ao invés de implementar uma reativação pós-falha automática. Caso contrário, a aplicação pode alternar continuamente entre as regiões. Verifique se todos os subsistemas da aplicação estão em bom estado antes da reativação pós-falha.

Tenha em atenção que, por predefinição, o Gestor de Tráfego efetua a reativação pós-falha automaticamente. Para evitar esta situação, reduza manualmente a prioridade da região primária após um evento de ativação pós-falha. Por exemplo, suponha que a região primária tem uma prioridade 1 e a secundária uma prioridade 2. Após uma ativação pós-falha, defina a região primária para uma prioridade 3, para impedir a reativação pós-falha automática. Quando estiver pronto para mudar, volte atrás, 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 passa por desativar temporariamente o ponto final até estar pronto para a reativação pós-falha:

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

Dependendo do motivo de uma ativação pós-falha, pode ter de reimplementar os recursos numa região. Antes da reativação pós-falha, realize um teste de preparação operacional. O teste deve verificar fatores como:

• As VMs estão configuradas corretamente. (Todo o software necessário está instalado, o IIS está em execução, entre outros.)

• Os subsistemas da aplicação estão em bom estado.

• Teste funcional. (Por exemplo, a camada de base de dados está acessível a partir da camada Web.)

Configurar os Grupos de Disponibilidade AlwaysOn do SQL Server

Com as versões anteriores ao Windows Server 2016, os Grupos de Disponibilidade AlwaysOn do SQL Server necessitam de um controlador de domínio e todos os nós no grupo de disponibilidade têm de estar no mesmo domínio do Active Directory (AD).

Para configurar o grupo de disponibilidade:

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

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

• Crie VPN para ativar 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. Pode utilizar o seguinte comando da CLI. Para obter mais informações, veja 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 Ativação Pós-falha do Windows Server) que inclua as instâncias do SQL Server em ambas as regiões.

• Crie um Grupo de Disponibilidade AlwaysOn do SQL Server que inclua as instâncias do SQL Server tanto na região primária como na secundária. Para obter os passos seguintes, veja Extending Always On Availability Group to Remote Azure Datacenter (PowerShell) (Expandir o Grupo de Disponibilidade AlwaysOn para o Datacenter do Azure Remoto (PowerShell)).

  • 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 para utilizar a consolidação síncrona com ativação pós-falha automática.

  • Coloque uma ou mais réplicas secundárias na região secundária. Configure-as para utilizar a consolidação assíncrona, por motivos de desempenho. (Caso contrário, todas as transações T-SQL têm de esperar por um percurso de ida e volta na rede para a região secundária.)

Nota

As réplicas de consolidação assíncrona não suportam a ativação pós-falha automática.

Considerações de disponibilidade

Com uma aplicação de N camadas complexa, pode não ter de replicar toda a aplicação na região secundária. Em vez disso, pode replicar apenas um subsistema crítico necessário para suportar a continuidade do negócio.

O Gestor de Tráfego é um ponto de falha possível no sistema. Se o serviço do Gestor de Tráfego falhar, os clientes não poderão aceder à sua aplicação durante o período de indisponibilidade. Reveja o SLA do Gestor de Tráfego e determine se a utilização do Gestor de Tráfego cumpre os seus requisitos de negócio para elevada disponibilidade. Se não for o caso, pondere adicionar outra solução de gestão de tráfego para fins de reativação pós-falha. Se o serviço Gestor de Tráfego do Azure falhar, altere os registos CNAME no DNS de modo a apontar para o outro serviço de gestão de tráfego. (Este passo tem de ser realizado manualmente e a aplicação ficará indisponível até que as alterações do DNS sejam propagadas.)

Para o cluster do SQL Server, existem dois cenários de ativação pós-falha a ter em consideração:

• Todas as réplicas da base de dados do SQL Server na região primária falham. Por exemplo, tal pode ocorrer durante uma falha regional. Nesse caso, tem realizar manualmente a ativação pós-falha do grupo de disponibilidade, apesar de o Gestor de Tráfego realizar automaticamente a ativação pós-falha no front-end. Siga os passos em Executar uma Ativação Pós-falha Manual Forçada de um Grupo de Disponibilidade do SQL Server, que descreve como efetuar uma ativação pós-falha forçada com o Management Studio do SQL Server, o Transact-SQL ou o PowerShell no SQL Server 2016.

  Aviso

  A ativação pós-falha forçada acarreta um risco de perda de dados. Assim que a região primária esteja novamente online, tire um instantâneo da base de dados e utilize tablediff para encontrar as diferenças.

• O Gestor de Tráfego efetua a ativação pós-falha para a região secundária, mas a réplica primária da base de dados do SQL Server continua disponível. Por exemplo, a camada front-end pode falhar, sem afetar as VMs do SQL Server. Nesse caso, o tráfego da Internet é encaminhado para a região secundária e essa região ainda pode estabelecer uma ligação com a réplica primária. No entanto, haverá uma maior latência, uma vez que as ligações do SQL Server estão a atravessar regiões. Nesta situação, deve efetuar uma ativação pós-falha manual da seguinte forma:

  1. Ative temporariamente uma réplica da base de dados do SQL Server na região secundária para uma consolidação síncrona. Este procedimento vai assegurar a não ocorrência de perda de dados durante a ativação pós-falha.

  2. Efetue a ativação pós-falha para essa réplica.

  3. Quando efetuar a reativação pós-falha para a região primária, restaure a definição de consolidação assíncrona.

Considerações sobre a capacidade de gestão

Quando atualiza a implementação, atualize uma região de cada vez para reduzir a probabilidade de uma falha global provocada por uma configuração incorreta ou um erro na aplicação.

Teste a resiliência do sistema quanto a falhas. Seguem-se alguns cenários comuns de falha para teste:

• Encerrar as instâncias de VM.

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

• Desligar/atrasar a rede.

• Falhar os processos.

• Expirar certificados.

• Simular falhas de hardware.

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

Avalie os tempos de recuperação e verifique se cumprem os requisitos comerciais. Teste também os modos de combinações de falhas.

Passos seguintes

• Para saber mais sobre os Padrões da Cloud do Azure, veja Padrões de Conceção da Cloud.