Esta arquitetura de referência mostra um conjunto de práticas comprovadas para a execução de uma aplicação de N camadas em várias regiões do Azure, para obter disponibilidade e uma infraestrutura de recuperação após desastre robusta.
Arquitetura
Transfira um ficheiro do Visio desta arquitetura.
Fluxo de trabalho
Esta arquitetura baseia-se na mostrada na aplicação n-tier 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.
Gerente de Tráfego 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 e o Gestor de Tráfego. Este método dá-lhe a flexibilidade para gerir cada região como uma única recolha 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. Criar uma rede virtual separada para cada região. Certifique-se de que os espaços de endereço não se sobrepõem.
SQL Server Sempre No Grupo de Disponibilidade. Se utilizar SQL Server, recomendamos grupos SQL Always On Availability para uma elevada disponibilidade. Crie um único grupo de disponibilidade que inclua as instâncias do SQL Server em ambas as regiões.
Nota
Considere também a Base de Dados SQL do Azure, que fornece uma base de dados relacional como um serviço cloud. Com a Base de Dados SQL Server, não precisa de configurar um grupo de disponibilidade ou gerir a ativação pós-falha.
Olhando a rede virtual. Par as duas redes virtuais para permitir a replicação de dados da região primária para a região secundária. Para mais informações, consulte o estado de observação da rede Virtual.
Componentes
- Os conjuntos de disponibilidade garantem que os VMs que implementa no Azure são distribuídos por múltiplos nós de hardware isolados num cluster. Se ocorrer uma falha de hardware ou software dentro do Azure, apenas um subconjunto dos seus VMs são afetados, e toda a sua solução permanece disponível e operacional.
- As zonas de disponibilidade protegem as suas aplicações e dados contra falhas no datacenter. As zonas de disponibilidade são locais físicos separados dentro de uma região de Azure. Cada zona é composta por um ou mais datacenters equipados com potência independente, arrefecimento e networking.
- Azure Traffic Manager é um equilibrador de carga baseado em DNS que distribui o tráfego da melhor forma. Presta serviços em todas as regiões globais do Azure, com elevada disponibilidade e capacidade de resposta.
- Balanceador de Carga do Azure distribui o tráfego de entrada, de acordo com regras definidas e sondas de saúde. Um equilibrador de carga proporciona baixa latência e alta produção, aumentando até milhões de fluxos para todas as aplicações TCP e UDP. Neste cenário é utilizado um equilibrador de carga pública para distribuir o tráfego de clientes que chega ao nível web. Neste cenário, é utilizado um equilibrador de carga interno para distribuir o tráfego do nível de negócio para o cluster de SQL Server de fundo.
- O Azure Bastion fornece conectividade secure RDP e SSH a todos os VMs, na rede virtual em que é alojada. Utilize o Azure Bastion para proteger as suas máquinas virtuais de expor portas RDP/SSH ao mundo exterior, ao mesmo tempo que fornece acesso seguro utilizando RDP/SSH.
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:
- Modo ativo/passivo com reserva ativa. O tráfego segue para uma região, enquanto a outra aguarda na reserva ativa. Hot standby significa que os VMs na região secundária são atribuídos e estão sempre em execução.
- Modo ativo/passivo com reserva progressiva. O tráfego segue para uma região, enquanto a outra aguarda na reserva progressiva. A espera fria significa que os VM na região secundária não são atribuídos até que seja necessário para o failover. Esta abordagem tem um custo de execução inferior, mas geralmente demora mais tempo a ficar online durante uma falha.
- Modo ativo/ativo. Ambas as regiões estão ativas e a carga dos pedidos é balanceada entre ambas. Se uma região ficar indisponível, é 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 colocar alguns VMs para espera quente e depois escalar se necessário.
Emparelhamento regional
Cada região do Azure é emparelhada com outra região na mesma geografia. Em geral, escolha regiões do mesmo par regional (por exemplo, E.U.A. Leste 2 e E.U.A. Central). Benefícios desta opção:
- Se houver uma paragem geral, a recuperação de pelo menos uma região de cada par é prioritária.
- As atualizações planeadas do sistema Azure são implementadas em regiões emparelhadas sequencialmente, para minimizar a possibilidade de períodos de indisponibilidade.
- Os pares residem na mesma área geográfica para satisfazer os requisitos de residência dos dados.
No entanto, verifique se ambas as regiões suportam todos os serviços do Azure necessários para a sua aplicação (veja Serviços por região). Para obter mais informações sobre pares regionais, veja Continuidade de negócio e recuperação após desastre (BCDR): Regiões Emparelhadas do Azure.
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 saúde. 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, consulte o padrão de monitorização do ponto final da saúde.
Quando o Gestor de Tráfego falha, há um período de tempo em que os clientes não conseguem chegar à 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.
O Gestor de Tráfego falha automaticamente por defeito. Para evitar este problema, reduza manualmente a prioridade da região primária após um evento de insuportância. 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 voltar a mudar, 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 é desativar temporariamente o ponto final até estar pronto para falhar:
az network traffic-manager endpoint update --resource-group <resource-group> --profile-name <profile>
--name <endpoint-name> --type azureEndpoints --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.
Pares as duas redes virtuais para permitir 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. Pode utilizar o seguinte comando da CLI. Para obter mais informações, consulte os servidores DO 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 estas réplicas para usar o compromisso sincronizado com a falha automática.
Coloque uma ou mais réplicas secundárias na região secundária. Configure estas réplicas para usar compromisso assíncronos , por razões 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
Réplicas de compromisso assíncronos não suportam falha automática.
Considerações
Estas considerações implementam os pilares do Quadro Azure Well-Architected, que é um conjunto de princípios orientadores que podem ser utilizados para melhorar a qualidade de uma carga de trabalho. Para mais informações, consulte o Microsoft Azure Well-Architected Framework.
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 de Gerente de Tráfego falhar, os clientes não podem aceder à sua aplicação durante o tempo de inatividade. 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, esta falha pode acontecer durante uma paragem 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
Com o fracasso forçado, há o 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:
- Ative temporariamente uma réplica da base de dados do SQL Server na região secundária para uma consolidação síncrona. Este passo garante que não haverá perda de dados durante a falha.
- Efetue a ativação pós-falha para essa réplica.
- Quando efetuar a reativação pós-falha para a região primária, restaure a definição de consolidação assíncrona.
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.
Otimização de custos
A otimização de custos tem a ver com formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para mais informações, consulte a visão geral do pilar de otimização de custos.
Utilize a Calculadora de Preços Azure para estimar os custos. Aqui estão outras considerações.
Conjuntos de Dimensionamento de Máquinas Virtuais
Conjuntos de Dimensionamento de Máquinas Virtuais estão disponíveis em todos os tamanhos Windows VM. Você só é cobrado pelos VMs Azure que você implanta e quaisquer recursos de infraestrutura subjacentes adicionados que são consumidos, tais como armazenamento e networking. Não há encargos incrementais para o serviço Conjuntos de Dimensionamento de Máquinas Virtuais.
Para opções de preços individuais de VMs, consulte os preços do Windows VMs.
Servidor SQL
Se escolher SQL do Azure DBaas, pode economizar a custo porque não precisa de configurar um Grupo Sempre Disponível e máquinas de controlador de domínio. Existem várias opções de implementação a partir de uma única base de dados até casos geridos, ou piscinas elásticas. Para mais informações, consulte SQL do Azure preços.
Para opções de preços de VMs de servidor SQL, consulte os preços dos VMs SQL.
Balanceadores de carga
Só é cobrado pelo número de regras configuradas de equilíbrio de carga e saída. As regras da NAT de entrada são gratuitas. Não há taxa de hora para o Balanceador de Carga Standard quando não há regras configuradas.
Preços do Gestor de Tráfego
A faturação do Gestor de Tráfego baseia-se no número de consultas de DNS recebidas, com desconto para serviços que recebem mais de mil milhões de consultas mensais. Também é cobrado por cada ponto final monitorizado.
Para obter mais informações, veja a secção de custos Well-Architected Framework do Microsoft Azure.
preços VNET-Peering
Uma implementação de alta disponibilidade que utiliza várias Regiões Azure utilizará o VNET-Peering. Existem diferentes encargos para VNET-Peering na mesma região e para a Global VNET-Peering.
Para mais informações, consulte Rede Virtual Preços.
DevOps
Utilize um modelo único de Resource Manager Azure para o fornecimento dos recursos Azure e das suas dependências. Utilize o mesmo modelo para implantar os recursos nas regiões primárias e secundárias. Inclua todos os recursos na mesma rede virtual para que estejam isolados na mesma carga de trabalho básica. Ao incluir todos os recursos, torna-se mais fácil associar os recursos específicos da carga de trabalho a uma equipa de DevOps, para que a equipa possa gerir de forma independente todos os aspetos desses recursos. Este isolamento permite à Equipa e Serviços da DevOps realizar integração contínua e entrega contínua (CI/CD).
Além disso, você pode usar diferentes modelos de Resource Manager Azure e integrá-los com Azure DevOps Services para fornecer diferentes ambientes em minutos, por exemplo para replicar produção como cenários ou ambientes de teste de carga apenas quando necessário, economizando custos.
Considere utilizar o Azure Monitor para analisar e otimizar o desempenho da sua infraestrutura, monitorizar e diagnosticar problemas de rede sem iniciar sessão nas suas máquinas virtuais. Application Insights é na verdade um dos componentes do Azure Monitor, que lhe dá métricas e registos ricos para verificar o estado da sua paisagem completa do Azure. O Azure Monitor irá ajudá-lo a seguir o estado da sua infraestrutura.
Certifique-se não só de monitorizar os elementos computativos que suportam o seu código de aplicação, mas também da sua plataforma de dados, em particular das suas bases de dados, uma vez que um baixo desempenho do nível de dados de uma aplicação pode ter consequências graves.
Para testar o ambiente Azure onde as aplicações estão em execução, deve ser controlado pela versão e implementado através dos mesmos mecanismos que o código de aplicação, então pode ser testado e validado usando paradigmas de teste de DevOps também.
Para mais informações, consulte a secção de Excelência Operacional no Quadro de Well-Architected Microsoft Azure.
Contribuidores
Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuintes.
Autor principal:
- Donnie Trumpower | Arquiteto sénior de solução de nuvem
Para ver perfis não públicos do LinkedIn, inscreva-se no LinkedIn.
Passos seguintes
Recursos relacionados
A seguinte arquitetura utiliza algumas das mesmas tecnologias: