Aplicação de N camadas do Windows no Azure Stack Hub com SQL Server

Esta arquitetura de referência mostra como implementar máquinas virtuais (VMs) e uma rede virtual configurada para uma aplicação de N camadas, utilizando SQL Server no Windows para a camada de dados.

Arquitetura

A arquitetura é composta pelos seguintes componentes:

Geral

• Grupo de recursos. Os grupos de recursos são utilizados para agrupar recursos do Azure para que possam ser geridos por duração, proprietário ou outros critérios.

• Conjunto de Disponibilidade. O conjunto de disponibilidade é uma configuração do datacenter para fornecer redundância e disponibilidade da VM. Esta configuração num carimbo do Azure Stack Hub garante que, durante um evento de manutenção planeada ou não planeada, pelo menos uma máquina virtual está disponível. As VMs são colocadas num conjunto de disponibilidade que as espalha por vários domínios de falha (anfitriões do Azure Stack Hub)

Rede e balanceamento de carga

• Rede virtual e sub-redes. Todas as VMs do Azure são implementadas numa rede virtual que pode ser segmentada em sub-redes. Crie uma sub-rede separada para cada camada.

• Camada 7 Balanceador de Carga. Como Gateway de Aplicação ainda não está disponível no Azure Stack Hub, existem alternativas disponíveis no mercado do Azure Stack Hub, como: KEMP LoadMaster Balanceador de Carga ADC Content Switch/ f5 Big-IP Virtual Edition ou A10 vThunder ADC

• Balanceadores de carga. Utilize Balanceador de Carga do Azure para distribuir o tráfego de rede da camada Web para o escalão de negócio e do escalão de negócio para SQL Server.

• Grupos de segurança de rede (NSGs). Utilize NSGs para restringir o tráfego de rede na rede virtual. Por exemplo, na arquitetura de três camadas apresentada aqui, a camada de base de dados não aceita tráfego do front-end web, apenas a partir do escalão de negócio e da sub-rede de gestão.

• DNS. O Azure Stack Hub não fornece o seu próprio serviço de alojamento DNS, pelo que utilize o servidor DNS no seu ADDS.

Máquinas virtuais

• SQL Server Grupo de Disponibilidade AlwaysOn. Fornece uma elevada disponibilidade na camada de dados ao ativar a replicação e a ativação pós-falha. Utiliza a tecnologia Cluster de Ativação Pós-falha do Windows Server (WSFC) para ativação pós-falha.

• Servidores do Active Directory Domain Services (AD DS). Os objetos de computador para o cluster de ativação pós-falha e as respetivas funções agrupadas associadas são criados no Active Directory Domain Services (AD DS). Configurar servidores do AD DS em VMs na mesma rede virtual são o método preferencial para associar outras VMs ao AD DS. Também pode associar as VMs ao Enterprise AD DS existente ao ligar a rede virtual à rede Enterprise com ligação VPN. Com ambas as abordagens, tem de alterar o DNS da rede virtual para o servidor DNS do AD DS (na rede virtual ou na rede Enterprise existente) para resolver o FQDN do domínio do AD DS.

• Testemunha de Cloud. Um cluster de ativação pós-falha requer que mais de metade dos nós estejam em execução, o que é conhecido como tendo quórum. Se o cluster tiver apenas dois nós, uma partição de rede pode fazer com que cada nó pense que é o nó do plano de controlo. Nesse caso, precisa de uma testemunha para quebrar laços e estabelecer quórum. Um testemunho é um recurso como um disco partilhado que pode funcionar como um disjuntor para estabelecer quórum. O Testemunho de Cloud é um tipo de testemunha que utiliza Armazenamento de Blobs do Azure. Para saber mais sobre o conceito de quórum, veja Compreender o quórum do cluster e do conjunto. Para obter mais informações sobre o Testemunho de Cloud, veja Deploy a Cloud Witness for a Failover Cluster (Implementar um Testemunho de Cloud para um Cluster de Ativação Pós-falha). No Azure Stack Hub, o ponto final do Cloud Witness é diferente do Azure global.

Pode ter o seguinte aspeto:

• Para o Azure global:
  https://mywitness.blob.core.windows.net/

• Para o Azure Stack Hub:
  https://mywitness.blob.<region>.<FQDN>

• Jumpbox. Também denominada anfitrião de bastião. Uma VM segura na rede que os administradores utilizam para ligar as outras VMs. A jumpbox tem um NSG que permite tráfego remoto apenas a partir de endereços IP públicos numa lista segura. O NSG deve permitir tráfego de ambiente de trabalho remoto (RDP).

Recomendações

Os requisitos podem ser diferentes da arquitetura descrita aqui. Utilize estas recomendações como um ponto de partida.

Máquinas virtuais

Para obter recomendações sobre como configurar as VMs, veja Executar uma VM do Windows no Azure Stack Hub.

Rede virtual

Quando criar a rede virtual, determine quantos endereços IP os seus recursos em cada sub-rede necessitam. Especifique uma máscara de sub-rede e um intervalo de endereços de rede suficientemente grande para os endereços IP necessários, com notação CIDR . Utilize um espaço de endereços contido nos blocos de endereços IP privados padrão, que são 10.0.0.0/8, 172.16.0.0/12 e 192.168.0.0/16.

Escolha um intervalo de endereços que não se sobreponha à sua rede no local, caso precise de configurar um gateway entre a rede virtual e a sua rede no local mais tarde. Depois de criar a rede virtual, não pode alterar o intervalo de endereços.

Crie sub-redes com requisitos de funcionalidade e segurança em mente. Todas as VMs dentro da mesma camada ou função devem passar pela mesma sub-rede, a qual pode ser um limite de segurança. Para obter mais informações sobre a conceção de redes virtuais e sub-redes, veja Planear e estruturar Redes Virtuais do Azure.

Balanceadores de carga

Não exponha as VMs diretamente à Internet, mas dê a cada VM um endereço IP privado. Os clientes ligam-se com o endereço IP público associado à Camada 7 Balanceador de Carga.

Defina as regras do balanceador de carga para direcionar o tráfego de rede para as VMs. Por exemplo, para ativar o tráfego HTTP, mapeie a porta 80 da configuração de front-end para a porta 80 no conjunto de endereços de back-end. Quando um cliente envia um pedido HTTP para a porta 80, o balanceador de carga seleciona um endereço IP de back-end com um algoritmo hash que inclui o endereço IP de origem. Os pedidos de cliente são distribuídos por todas as VMs no conjunto de endereços de back-end.

Grupos de segurança de rede

Utilize as regras do NSG para restringir o tráfego entre as camadas. Na arquitetura de três camadas mostrada acima, a camada Web não comunica diretamente com a camada da base de dados. Para impor esta regra, a camada de base de dados deve bloquear o tráfego de entrada da sub-rede da camada Web.

1. Negar todo o tráfego de entrada da rede virtual. (Utilize a etiqueta VIRTUAL_NETWORK na regra.)

2. Permitir tráfego de entrada a partir da sub-rede do escalão de negócio.

3. Permitir o tráfego de entrada a partir da própria sub-rede da camada de base de dados. Esta regra permite a comunicação entre as VMs da base de dados, que é necessária para a replicação da base de dados e a ativação pós-falha.

4. Permitir tráfego RDP (porta 3389) a partir da sub-rede jumpbox. Esta regra permite aos administradores estabelecer ligação com o escalão da base de dados a partir da jumpbox.

Crie regras 2 a 4 com prioridade superior à primeira regra, para que a substituam.

Grupos de Disponibilidade Always On do SQL Server

Recomendamos Grupos de Disponibilidade AlwaysOn para a elevada disponibilidade do SQL Server. Com as versões anteriores ao Windows Server 2016, os Grupos de Disponibilidade AlwaysOn 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 AD.

Para elevada disponibilidade da camada de VM, todas as VMs do SQL devem estar num Conjunto de Disponibilidade.

As outras camadas ligam-se à base de dados através de um serviço de escuta do grupo de disponibilidade. O serviço de escuta permite que um cliente do SQL se ligue sem saber o nome da instância física do SQL Server. As VMs com acesso à base de dados têm de estar associadas ao domínio. O cliente (neste caso, a outra camada) utiliza o DNS para resolver o nome da rede virtual do serviço de escuta nos endereços IP.

Configure os Grupos de Disponibilidade AlwaysOn do SQL Server da seguinte forma:

1. Crie um cluster WSFC (Clustering de Ativação Pós-falha do Windows Server), um Grupo de Disponibilidade AlwaysOn do SQL Server e uma réplica primária. Para obter mais informações, veja Getting Started with Always On Availability Groups (Introdução aos Grupos de Disponibilidade AlwaysOn).

2. Crie um balanceador de carga interno com um endereço IP privado estático.

3. Criar um serviço de escuta do grupo de disponibilidade e mapeie o nome DNS do serviço de escuta do endereço IP de um balanceador de carga interno.

4. Crie uma regra de balanceador de carga para a porta de escuta do SQL Server (porta TCP 1433, por predefinição). A regra de balanceador de carga tem de ativar o IP flutuante, também denominado Devolução Direta do Servidor. Esta ação faz com que a VM responda diretamente ao cliente, o que permite uma ligação direta à réplica primária.

Nota

Quando o IP flutuante é ativado, o número de porta do front-end tem de ser igual ao número de porta do back-end na regra de balanceador de carga.

Quando um cliente do SQL tenta estabelecer ligação, o balanceador de carga encaminha o pedido de ligação para a réplica primária. Se existir uma ativação pós-falha para outra réplica, o balanceador de carga encaminha automaticamente novos pedidos para uma nova réplica primária. Para obter mais informações, veja Configurar um serviço de escuta ILB para os Grupos de Disponibilidade AlwaysOn do SQL Server.

Durante a ativação pós-falha, as ligações de cliente existentes são fechadas. Após a conclusão da ativação pós-falha, as novas ligações serão encaminhadas para a nova réplica primária.

Se a sua aplicação fizer mais leituras do que escritas, pode descarregar algumas das consultas só de leitura para uma réplica secundária. Veja Using a Listener to Connect to a Read-Only Secondary Replica (Read-Only Routing) (Utilizar um Serviço de Escuta para Ligar a uma Réplica Secundária Só de Leitura (Encaminhamento Só de Leitura)).

Teste a sua implementação ao forçar uma ativação pós-falha manual do grupo de disponibilidade.

Para otimização do desempenho do SQL, também pode consultar o artigo Melhores práticas do SQL Server para otimizar o desempenho no Azure Stack Hub.

Jumpbox

Não permita o acesso RDP da Internet pública às VMs que executam a carga de trabalho da aplicação. Em vez disso, todo o acesso RDP a estas VMs deve passar pela jumpbox. Um administrador inicia sessão na jumpbox e, em seguida, inicia sessão noutra VM a partir da jumpbox. A jumpbox permite tráfego RDP através da Internet, mas apenas a partir de endereços IP conhecidos e seguros.

A jumpbox tem requisitos de desempenho mínimos, por isso, selecione um tamanho de VM pequeno. Crie um endereço IP público para a jumpbox. Coloque a jumpbox na mesma rede virtual que as outras VMs, mas numa sub-rede de gestão separada.

Para proteger a jumpbox, adicione uma regra NSG que permita ligações RDP apenas a partir de um conjunto seguro de endereços IP públicos. Configure os NSGs para as outras sub-redes para permitir o tráfego RDP da sub-rede de gestão.

Considerações de escalabilidade

Conjuntos de dimensionamento

Para os escalões Web e empresarial, considere utilizar conjuntos de dimensionamento de máquinas virtuais em vez de implementar VMs separadas. Um conjunto de dimensionamento facilita a implementação e gestão de um conjunto de VMs idênticas. Considere os conjuntos de dimensionamento se precisar de aumentar horizontalmente as VMs rapidamente.

Existem duas formas básicas de configurar as VMs implementadas num conjunto de dimensionamento:

• Utilize extensões para configurar a VM depois de ser implementada. Com esta abordagem, as novas instâncias de VM podem demorar mais tempo a iniciar em comparação com uma VM sem extensões.

• Implementar um disco gerido com uma imagem de disco personalizada. Esta opção pode ser mais rápida de implementar. No entanto, requer que mantenha a imagem atualizada.

Para obter mais informações, veja Considerações de design para conjuntos de dimensionamento. Esta consideração de design é principalmente verdadeira para o Azure Stack Hub. No entanto, existem algumas limitações:

• Os conjuntos de dimensionamento de máquinas virtuais no Azure Stack Hub não suportam o aprovisionamento excessivo ou atualizações sem interrupção.

• Não pode dimensionar automaticamente conjuntos de dimensionamento de máquinas virtuais no Azure Stack Hub.

• Recomendamos vivamente a utilização de discos geridos no Azure Stack Hub em vez de discos não geridos para o conjunto de dimensionamento de máquinas virtuais

• Atualmente, existe um limite de 700 VMs no Azure Stack Hub, que representa todas as VMs de infraestrutura do Azure Stack Hub, VMs individuais e instâncias de conjuntos de dimensionamento.

Limites da subscrição

Cada subscrição de inquilino do Azure Stack Hub tem limites predefinidos, incluindo um número máximo de VMs por região configuradas pelo operador do Azure Stack Hub. Para obter mais informações, veja Descrição geral dos serviços, planos, ofertas e subscrições do Azure Stack Hub. Veja também Tipos de quota no Azure Stack Hub.

Considerações de segurança

As redes virtuais são um limite de isolamento de tráfego no Azure. Por predefinição, as VMs numa rede virtual não conseguem comunicar diretamente com VMs numa rede virtual diferente.

NSGs. Utilize grupos de segurança de rede (NSGs) para restringir o tráfego de e para a Internet. Para obter mais informações, veja Serviços cloud da Microsoft e segurança de rede.

DMZ. Considere adicionar uma aplicação virtual de rede (NVA) para criar uma rede de Perímetro entre a Internet e a rede virtual do Azure. A NVA é um termo genérico para uma aplicação virtual que pode realizar tarefas relacionadas com a rede, tais como firewall, inspeção de pacotes, auditoria e encaminhamento personalizado.

Encriptação. Encripte dados confidenciais inativos e utilize Key Vault no Azure Stack Hub para gerir as chaves de encriptação da base de dados. Para obter mais informações, consulte o artigo Configurar a Integração do Cofre de Chaves do Azure para o SQL Server em VMs do Azure. Também é recomendado armazenar segredos da aplicação, como cadeias de ligação de base de dados, em Key Vault.

Passos seguintes

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